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

Andrew Banks commented on MQTT-256:
-----------------------------------

Notes on points raised in technical committee meeting 7th January 2016.

It might be safer to use a non zero delimiter, to aid in avoiding parsing problems.

Disconnecting the TCP connection clears the cache of templates.

It would be preferable if the receiver can give an indication of how much caching it would be
willing to do.

It is necessary for the receiver to know all of the types and be able to compute the lengths
of the values in order to successfully parse the packet.

The specification would need to be unambiguous in stating whether a template update had taken effect.
For instance if the publish packet is nack'd.

A sender would need to reset the cache after a TCP disconnect. Hence a sender could not simply
reflow the buffered packets. The initial packet at least for each template would need to establish 
the full set of cached values.

In a network where packet loss is possible this scheme would need to be modified in case a packet 
containing a cache update is lost.


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