[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:comment-tabpanel&focusedCommentId=61782#comment-61782 ]
Andrew Banks edited comment on MQTT-256 at 2/18/16 12:09 PM:
-------------------------------------------------------------
The following is a summary of the conclusions reached at the January 2016 MQTT face to face meeting.
Updated in light of David Horton's comment about Request Response.
The following are the currently known metadata values under consideration for inclusion in
an MQTT VNext specification.
1. Message Format: byte, indicating the type of payload, eg Bytes, String, JSON.
2. Publication time to live: four byte unsigned long, indicating the number of seconds during which
message delivery will be attempted.
3. Correlator: four byte unsigned long, identifier carried in request and response which messages so
that the request message can be associated with its response message.
4.ReplyTo: UTF-8 String which is the structured topic name carried in a request
and which the response is sent to.
5. User metadata: two byte unsigned length + bytes, unspecified data for use by the client application.
PUBLISH Packet encoding schemes.
Existing MQTT 3.1.1 PUBLISH packet
Pub(3),Flags,RL TopicName,Packet Identifier(if Qos 1,2) Payload
RL is the RemainingLength of the packet.
Scheme 1 PUBLISH packet
Pub(3),Flags,RL TopicName,Packet Identifier(if Qos 1,2),[Id,Value [...]],Delimiter Payload
Id(byte),Value pairs follow the Packet Identifier in the variable header, terminated by a delimiter byte.
Scheme 2 PUBLISH packet
Pub(3),Flags,RL TopicName,Packet Identifier (if Qos 1,2),Metadata flags,[Value [...]] Payload
Metadata flags(byte) follow the Packet Identifier in the variable header.
Each 1 bit in the flags represents a metadata value which follows the flags in the same order as the bits.
Same approach as is used for the Connect flags, except that the values are in the variable header
rather than the payload.
Payload format types.
The default payload format is bytes, no format indicator is needed in this case.
Payload format 1(byte), indicates that the payload is a valid UTF-8 string.
Payload format 2(byte), indicates that the payload is valid JSON.
was (Author: andrew_banks):
The following is a summary of the conclusions reached at the January 2016 MQTT face to face meeting.
Updated in light of David Horton's comment about Request Response.
The following are the currently known metadata values under consideration for inclusion in
an MQTT VNext specification.
1. Message Format: byte, indicating the type of payload, eg Bytes, String, JSON.
2. Publication time to live: four byte unsigned long, indicating the number of seconds during which
message delivery will be attempted.
3. Correlator: four byte unsigned long, identifier carried in request and response which messages so
that the request message can be associated with its response message.
4.ReplyTo: UTF-8 String which is the structured topic name carried in a request
and which the response is sent to.
4. User metadata: two byte unsigned length + bytes, unspecified data for use by the client application.
PUBLISH Packet encoding schemes.
Existing MQTT 3.1.1 PUBLISH packet
Pub(3),Flags,RL TopicName,Packet Identifier(if Qos 1,2) Payload
RL is the RemainingLength of the packet.
Scheme 1 PUBLISH packet
Pub(3),Flags,RL TopicName,Packet Identifier(if Qos 1,2),[Id,Value [...]],Delimiter Payload
Id(byte),Value pairs follow the Packet Identifier in the variable header, terminated by a delimiter byte.
Scheme 2 PUBLISH packet
Pub(3),Flags,RL TopicName,Packet Identifier (if Qos 1,2),Metadata flags,[Value [...]] Payload
Metadata flags(byte) follow the Packet Identifier in the variable header.
Each 1 bit in the flags represents a metadata value which follows the flags in the same order as the bits.
Same approach as is used for the Connect flags, except that the values are in the variable header
rather than the payload.
Payload format types.
The default payload format is bytes, no format indicator is needed in this case.
Payload format 1(byte), indicates that the payload is a valid UTF-8 string.
Payload format 2(byte), indicates that the payload is valid JSON.
> 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]