[OASIS Issue Tracker] Created: (MQTT-31) Clarification of 2.2.1 (Message Identifiers)

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Clarification of 2.2.1 (Message Identifiers)
--------------------------------------------

                 Key: MQTT-31
                 URL: http://tools.oasis-open.org/issues/browse/MQTT-31
             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
          Issue Type: Improvement
          Components: edits
            Reporter: Peter Niblett
            Priority: Minor


I found the discussion of the presence/absence of MessageIDs, and the presence of a messageID of 0 to be rather confusing.  Also there is no definition of "complete" as used in line 438. Finally as this is an opaque field, there's no need to describe it as an integer, and thus the table showing it as MSB / LSB in line 464 is redundant.

I suggest rewording it as follows..

The variable header component of many of the Control Packet types includes a 2 byte Message Identifier (MessageId) field. These Control Packets are PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBSCRIBE, UNSUBSCRIBE, UNSUBACK.

A PUBACK, PUBREC, PUBREL packet MUST contain the same MessageId as the PUBLISH control packet that initiated the flow. Similarly SUBACK and UNSUBACK MUST contain the MessageID that was used in the corresponding SUBSCRIBE or UNSUBSCRIBE packet. 

A PUBLISH control packet MUST contain a MessageId of 0x0000 if its QoS value is set to 0.

SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) MUST contain a non-zero 16-bit value MessageId. Each time a client sends a new packet of one of these types it MUST assign it a distinct MessageId.  If a client resends a particular control packet, then it MUST use the same MessageId in subsequent resends of that packet. The client MUST NOT reuse a MessageId value until it has processed an acknowledgement packet (PUBREC in the case of QoS 2)  that contains that MessageId.  The same conditions apply to a server when it sends a PUBLISH with QoS > 0. 

The client and server assign MessageIds independently of each other. It is possible for a client to send a PUBLISH with MessageID 0x0001 and then receive a different PUBLISH with MessageId 0x0001 from its server before it receives a PUBACK for the PUBLISH that it sent.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira