[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=62909#comment-62909 ] 

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

I understand the desire to get this JIRA to closure, even if there is still some work to do.  I think however that we should deal with a couple of the significant issues around metadata in this round as otherwise it complicates the next round of function:

1. Terminology: what do we call metadata?  There seems to be a consensus not to use metadata.  In the proposals these are called optional values, id/value pairs, and identifier/value pairs in various case.  I still like "optional fields" but whatever we chose we should use consistently.  I would also say that the metadata consists of a variable length integer, followed by zero or more pairs of identifiers and values.  That is, metadata is itself a type, and the initial length is a type within it.

2. I am concerned about the statement that the message format MUST be sent unaltered to all subscribers at this version of MQTT or higher.  This is setting a new precedent where the spec is describing how an implementation handles multiple versions of MQTT.  It also prohibits any future version of MQTT from altering the format of the metadata.  We need to scope this version of the spec to only deal with this version of the spec.  We could have some non-normative text on this subject.

3. I am concerned about the requirement of the receiver to always validate the message format (or other metadata).  What we should say is that the sender MUST only send valid metadata.  This essentially requires the server to validate the metadata before sending it on.  However, a client who does not use the message format should be free to ignore it other than to skip over it.  For other metadata items, there are cases where both client and server may wish to ignore some fields. 

4. We should clarify that the sender may not use the same identifier more than once in the same control packet.  This clarifies any ambiguity of such usage.

> 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: 5
>            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)