OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-256) Message Format indication


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

Rick Bullotta commented on MQTT-256:
------------------------------------

Metadata is an essential part of any truly interoperable protocol.  This includes the ability to infer payload type(s) and, ideally, the ability to do discovery on topics, semantics, and data types and formats.  Publishers and subscribers (or servers and clients or whatever) need to be able to be more "loosely coupled" for dynamic and adaptive applications.  

We have developed a relatively simple yet powerful data and metadata representation for ThingWorx that we'd be happy to share.  It has binary, JSON, and XML representations, as well as a rich set of foundational data types. Those "base types" include all the usual suspects (boolean, string, float, integer) as well as richer types (datetime, image, blob, XML, JSON, HTML, hyperlink, imagelink, location) and even complex types (infotable, which is a composite of the other types, and can be multi-row and/or complex nested structures).

I have long considered the lack of discovery, metadata, and strong typing to be one of the core weaknesses of MQTT.  Let's address it and then MQTT can achieve its true potential in the IoT.


> Message Format indication
> -------------------------
>
>                 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
>
> 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)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]