Hi Kai,
thanks for your comments! My answers are below in the text.
> as I work on the implementation of Command and Control for MQTT right now, I
> would like to summarize some changes to the concept so far, that for my
> understanding follows the discussions in Toulouse and on the mailing list. The
> definitions are below. The important changes are:
> The structure of the topic always reflects the parts for tenant and device-id.
> They might be empty, if the device is authenticated.
> The command is at the end of the topic to allow following parts, that will not
> be used or parsed by Hono.
> To allow a property bag for future additions the ? is not allowed as the
> beginning character of a topic part.
> The res and req parts are now behind tenant and device-id, so we have always
> the same starting scheme with <endpoint>/[tenant]/[device-id]. As a consequence
> the subscription (the only one accepted right now) changes to
> control/+/+/req/#.
Shouldn't this be "control///req/#" instead, based on the discussions we had
regarding omitting the tenant and device ID for authenticated devices?
Using the "+" sign in an MQTT topic filter usually means "any single path
segment", which FMPOV could make a client to believe that it subscribes to all
commands sent to "any device" of "any tenant".
It could be done without the '+'. What we win is the possibility to answer the same way as with unauthenticated devices if needed (not the default). I can also image that we could use this for commands by e.g. other tenants that has been authorized to send commands to this device.
You are right, that this subscription has the additional policy, that the devices at the moment just gets there own messages. But I do not think this is a problem.
> The control part can have the short version with c.
> Request:
> Devices receive commands on topic:
> control/[tenant]/[device-id]/req/<req-id>/<command>[/*][/property-bag]
> this means it subscribes to:
> control/+/+/req/#
> Examples:
> control/DEFAULT_TENANT/4711/req/xyz/light
> control///req/xyz/light (tenant and device from auth)
> control///req/xyz/light/switch/on (additional segments are allowed)
>
> The property-bag at the end is in optional bag of properties, that starts with
> a ? (so this is not allowed in additional topic segments as a starting
> character) and is followed by pairs of URL encoded property names and values,
> which are separated by &:
> <url-encoded-name>=<url-encoded-value>
MQTT 3.1.1 defines topic names to consist of UTF-8 characters, so I do not quite
see why we should URL encode the properties.
At least we need to encode the critical MQTT characters ('/', '+', '#') and if we encode I think it is much easier to use such an widely used standard for this.
> Examples:
> control///req/xyz/light/?myId=42&imperator=mouse&a=b
> control///req/xyz/light/switch/on/?myId=42&imperator=mouse&a=b
> Response
> Devices sends response to command on topic:
> control/[tenant]/[device-id]/res/<req-id>/<status>
> Examples:
> control/DEFAULT_TENANT/4711/res/xyz/200
> control///res/xyz/200 (tenant and device from auth)
> _______________________________________________
> hono-dev mailing list
> hono-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/hono-dev
_______________________________________________
iot-wg-integration mailing list
iot-wg-integration@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/iot-wg-integration
