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

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

Hi,

I just wanted to cross post the mail below in order to keep everybody up to date
on the latest discussions around topic structure for command & control in Hono.

I have made some comments below ...

-- 
Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Ullsteinstr. 128
12109 Berlin
GERMANY
www.bosch-si.com

Registered Office: Berlin, Registration Court: Amtsgericht Charlottenburg; HRB
148411 B
Chairman of the Supervisory Board: Dr.-Ing. Thorsten Lücke; Managing Directors:
Dr. Stefan Ferber, Michael Hahn


-------- Forwarded Message --------
From: Marc Pellmann <pellmann@xxxxxxxxx>
Reply-To: hono developer discussions <hono-dev@xxxxxxxxxxx>
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: [hono-dev] MQTT Command and Control Topics
Date: Tue, 10 Jul 2018 16:16:29 +0200

> Hi, 
> 
> 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".

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

> 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