[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-256) Message Format indication and message metadata in general.
[ https://issues.oasis-open.org/browse/MQTT-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrew Banks updated MQTT-256:
------------------------------
Proposal:
We will consider making a unified and organised set of Metadata Id's
for use across all packet types in a separate Jira once the complete set of
values is known. We will also consider moving existing values into the optional metadata in Jira MQTT-282. Further Message format types such as JSON and Base64 may also be added in future.
1) Make Remaining Length a defined data type so that it can be used to
encode optional metadata values into PUBLISH and potentially other
packets. Add a four byte integer type.
- Move the description of Remaining Length from section "2 MQTT
Control Packet format" to "1.5 Data representations" as a datatype
called Variable Byte Integer.
- Add a separate data type for a Four Byte integer value, in addition to the
existing Two Byte Integer value.
2) Update the description of the PUBLISH Packet to include the optional
metadata Identifier/Value pairs.
- Update 3.3.2 Variable header as follows:
The variable header contains the following fields in the order:
Topic Name, Packet Identifier, Remaining Length, Identifier/Value pairs.
- After "3.3.2.2 Packet Identifier" add:
3.3.2.3 Optional PUBLISH values.
The Remaining Length of optional Identifier/Value pairs in the PUBLISH
Packet variable header. The remaining Length does not include the
bytes used to encode the Remaining Length. A remaining length of
zero indicates that there are no optional Identifier/Value pairs in the
PUBLISH packet.
3.3.2.4 Optional Payload Format Indicator.
If absent the PUBLISH payload consists of unspecified bytes.
Byte 1 (0x01) Identifier of the Payload Format Indicator.
Followed by the Value of the Payload Format Indicator, either of:
Byte 1 (0x01) Indicates that the payload is a UTF8 String encoded as
described in section 1.5.3.
A server MUST send the Payload Format Indicator unaltered to all
subscribers receiving the publication, using this version of MQTT or
higher. The receiver is not required to validate that the payload is of
the format indicated, however it MAY close the network connection if it
discovers that the payload does not match the Payload Format
Indicator.
On receipt of any other Identifier or Value, the receiver MUST close the
network connection.
- Update 3.3.2.3 Variable header non normative example to show zero
length metadata.
was:
We will consider making a unified and organised set of Metadata Id's
for use across all packet types in a separate Jira once the complete set of
values is known. We will also consider moving existing values into the optional
metadata in Jira MQTT-282.
1) Make Remaining Length a defined data type so that it can be used to
encode optional metadata values into PUBLISH and potentially other
packets. Add a four byte integer type.
- Move the description of Remaining Length from section "2 MQTT
Control Packet format" to "1.5 Data representations" as a datatype
called Variable Byte Integer.
- Add a separate data type for a Four Byte integer value, in addition to the
existing Two Byte Integer value.
2) Update the description of the PUBLISH Packet to include the optional
metadata Identifier/Value pairs.
- Update 3.3.2 Variable header as follows:
The variable header contains the following fields in the order:
Topic Name, Packet Identifier, Remaining Length, Identifier/Value pairs.
- After "3.3.2.2 Packet Identifier" add:
3.3.2.3 Optional PUBLISH values.
The Remaining Length of optional Identifier/Value pairs in the PUBLISH
Packet variable header. The remaining Length does not include the
bytes used to encode the Remaining Length. A remaining length of
zero indicates that there are no optional Identifier/Value pairs in the
PUBLISH packet.
3.3.2.4 Optional Payload Format Indicator.
If absent the PUBLISH payload consists of unspecified bytes.
Byte 1 (0x01) Identifier of the Payload Format Indicator.
Followed by the Value of the Payload Format Indicator, either of:
Byte 1 (0x01) Indicates that the payload is a UTF8 String encoded as
described in section 1.5.3.
Byte 2 (0x02) Indicates that the payload is JSON as encoded as
specified in http://docs.oasis-open.org/odata/odata-json-format/v4.0/cs01/odata-json-.
A server MUST send the Payload Format Indicator unaltered to all
subscribers receiving the publication, using this version of MQTT or
higher. The receiver is not required to validate that the payload is of
the format indicated, however it MAY close the network connection if it
discovers that the payload does not match the Payload Format
Indicator.
On receipt of any other Identifier or Value, the receiver MUST close the
network connection.
- Update 3.3.2.3 Variable header non normative example to show zero
length metadata.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]