[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=59234#comment-59234 ] David Locke commented on MQTT-256: ---------------------------------- Register could be good way to keep with the design goals of MQTT yet provide additional flexibility. Rather than sending the metadata with every event, the meta data can be established once per topic. If no meta-data is registered then fall back to todays world, The ability to register an alias for a topic per MQTT-SN enables long meaningful topic names to be used but for the publisher to use a very short alias. When publishing to the same topic on a regular basis this can dramatically reduce bytes over the wire. Of course the devil is in the detail but register at initial glance looks like a good approach. > 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]