Re: [iot-wg-integration] [Fwd: [hono-dev] MQTT Command and Control Topic

["Hudalla Kai (INST/ECS4)" <kai.hudalla@xxxxxxxxxxxx>]

On Mon, 2018-08-06 at 10:04 +0200, Marc Pellmann wrote:
> 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.
> 

It is ok to use the "+" characters FMPOV. However, we need to make sure that
everybody is clear about the fact that it doesn't mean "any device of any
tenant", i.e. this needs to be documented in the HTTP adapter user guide.

> 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.

I see, makes sense. My understanding is that all these characters are in fact
subject to URL encoding, i.e. when I use a standard method for URL encoding then
these characters will end up being encoded using the "hash sign notation", right?

>  
> > > 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
> 
> _______________________________________________
> 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