[OASIS Issue Tracker] (MQTT-256) Message Format indication and message metadata in general.

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62192#comment-62192 ] 

Ken Borgendale commented on MQTT-256:
-------------------------------------

We also want to look at metadata on the CONNECT and CONNACK packets.  I seems to make most sense to use whatever method we choose for PUBLISH and apply it to CONNECT and CONNACK as well.  A number of these items are on both CONNECT and CONNACK as both the client and server wish to inform the other side.  

Based on the existing set of JIRAs, the potential list look something like:
CONNECT:
- Max inflight messages
- Max message length
- Max message rate
- Requested security mechanism
- Unspecified user data
- Delete client state
- Session timeout

CONNACK
- Max inflight messages
- Max message length
- Max message rate
- Requested security mechanism
- Unspecified user data
- Delete client state
- Session timeout
- Maximum QoS (or perhaps QoS=2 supported)
- Retained message supported 
- Cleansession=false supported
- Max keepalive supported
- Shared subs supported
- Security domain
- Returned ClientID

All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values.  Unlike PUBLISH where the remainder of the packet is the payload, on CONNECT and CONNACK we could just use the remaining length of the packet as key-value pair metadata.

Some of the existing CONNECT data fields could be re-encoded as key=value metadata, or we could encode the existing values as today and add any new items as key=value metadata.  When the same field is passed on CONNECT and CONNACK, it would seem strange to pass them in different ways.

> Message Format indication and message metadata in general.
> ----------------------------------------------------------
>
>                 Key: MQTT-256
>                 URL: https://issues.oasis-open.org/browse/MQTT-256
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: futures
>    Affects Versions: 3.1.1
>            Reporter: Peter Niblett
>            Priority: Critical
>
> MQTT 3.1.1 does not provide an architected way of indicating the format of the payload that is passed in a PUBLISH packet. We need to avoid the risk of spec or data bloat, and I'm not advocating adding a complicated header structure that passes schemas, messageType indicators, MIME type strings or the like, but at the moment there is no standard way for a receiver even to be able to tell whether the payload is binary or string. 
> There are three ways that this can be dealt with today:
> 1. The Receiver already knows. It's implementing some bigger standard or program design which has dictated the encoding format (e.g. someone decides that all messages will be JSON)
> 2. There is an indicator embedded somewhere in the Topic name (The Topic name is  the only header we have in MQTT 3.1.1). There isn't a standard convention for this, so topic space designers have to choose their own way of doing it.
> 3. The Receiver assumes one format and has a go parsing it. If that doesn't look right it tries another



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)