[OASIS Issue Tracker] (MQTT-287) Clarify text to insure unified packet identifier space

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

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

Ken Borgendale commented on MQTT-287:
-------------------------------------

What are the imperatives you would write as part of this?  I assume that the client MUST NOT reuse a packet identifier for any PUBLISH, SUBSCRIBE, or UNSUBSCRIBE until it is freed from it previous use.  For the server this is no different from the current restriction that it MUST NOT reuse the packet identifier for a PUBLISH until it is freed.  Is the receiving client or server required to check that the packet identifier is already in use?

As I mentioned in Bellevue, the product I work on only persists packet IDs for QoS=2 publishes, and only checks for duplicates in that case.  In all other cases it just sends back the packet ID it was given in the ACK.  I can see why the creator of a packet ID might want to apply this uniqueness rule.  I do not see that it matters to the receiver except in the QoS=2 case.  Even for flow control the only concern is the count, not the value of the in-fight packet IDs.

If the receiver is not required to enforce this imperative I do not see a problem with it, but then I do not see much value either., 



> Clarify text to insure unified packet identifier space
> ------------------------------------------------------
>
>                 Key: MQTT-287
>                 URL: https://issues.oasis-open.org/browse/MQTT-287
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>            Reporter: Ed Briggs
>            Priority: Minor
>
> The text in the MQTT 3.1.1 specification is not clear that packet identifiers used for PUBLISH (and related ACKs) are taken from the same set of packet identifiers as those used for SUBSCRIBE related operations.   I brought this up in the face-to-face meeting in Redmond, and both Andy Stanford-Clark and Ian Cragg responded that a single, unified packet id space was the intent of the specification.
> Ken Borgendale commented that it was possible for implementations to operate successfully without using a unified packet identifier space, if they were careful to avoid ambiguity arising from a  PUBLISH related command carrying the same packet identifier as a a SUBSCRIBE related command.
> Ian Cragg observed that having separate spaces made it more likely for implementations to get into difficulties.  I myself have seen several implementations in which some of these difficulties occurred.
> I feel the text should be clarified to say the following two things:.
> 1. All packet identifiers are taken from a single set of packet identifiers, regardless of whether the message is a PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, UNSUBSCRIBE, SUBACK or UNSUBACK.   (All packet identifiers refers to the set of packet identifiers used by either a client or a server when initiating transmission of commands carrying packet identifiers)
> 2. The receipt of a SUBACK or UNSUBACK MUST free the packet identifier for re-use, in the same sense that PUBACK and PUBCOMP free the packet identifier assigned to a PUBLISH.
> The precise workding is a topic for further study.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)