[OASIS Issue Tracker] (MQTT-253) Subscription identification

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

     [ https://issues.oasis-open.org/browse/MQTT-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicholas O'Leary updated MQTT-253:
----------------------------------

    Proposal: 
## High level description
Each subscription is assigned a subscription identifier at the time it is made. Within each session, the subscription identifiers are unique. The subscription identifiers are part of the session state which is preserved across network disconnection for CleanSession=0 sessions.
When a client is successfully granted a subscription, the server sends back the subscription identifier in the SUBACK packet.
When a message is published whose topic string matches multiple subscriptions in a session, the server is permitted to send the client either one message or one message for each subscription. In the first case, the server should annotate the message sent to the client with the subscription identifiers of all matching subscriptions. In the second case, the server should annotate each message sent to the client with the subscription identifier for the subscription for that copy of the message.

The client can use the Subscription Identifier to unsubscribe - or use the Topic Filter as can currently do.

Open questions:

 - Section 3.8.4 says:
     The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet.
   That means a client may receive a publish with a subscription ID it does not yet know about (because the suback hasn't arrived). Is that a problem?

 - Does this require a new UNSUBACK return code (invalid sub id), or does 0x11: "No subscription existed" cover it.


Spec changes based on wd06:

 PUBLISH
  - 3.3.2.7 Matching Subscription List
       If set, it identifies the Subscriptions that caused this Publish to be sent
       to the receiver.
        - M (0x0M) Byte, Identifier of the Matching Subscriptions List.
        - Variable Byte Integer (N) - the number of matching subscriptions
        - Followed by N further Variable Byte Integers that identify the matching
          Subscription Identifiers


 SUBACK
  - 3.9.3 Payload
         Current:
           The payload contains a list of Return Codes. Each Return code 
           corresponds to a Topic Filter in the SUBSCRIBE Packet being acknowledged.
           The order of return codes in the SUBACK Packet MUST match the order of
           Topic Filters in the SUBSCRIBE Packet.

          Proposed:
           The payload contains a list of Return Codes (single byte) and Subscription
           Identifies (Variable Byte Integer) entries.
           Each entry corresponds to a Topic Filter in the SUBSCRIBE Packet being
           acknowledged. The order of entries in the SUBACK Packet MUST match the
           order of Topic Filters in the SUBSCRIBE Packet.

           If a subscription is accepted, the Subscription Identifier MUST be a
           non-zero value that is unique to the current Session.
           If a subscription is not accepted, the Subscription Identified MUST be 0.



UNSUBSCRIBE
  - 3.10.3 Payload
          Current:
            The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters
            that the Client wishes to unsubscribe from. The Topic Filters in an
            UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in
            Section 1.5.3, packed contiguously.
            The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic
            Filter. An UNSUBSCRIBE packet with no payload is a protocol violation.
            See section 4.8 for information about handling errors. 

          Proposed:
            The payload for the UNSUBSCRIBE Packet contains the list of Topic Filters
            or Subscription Identifiers that the Client wishes to unsubscribe from.
            The Topic Filters are UTF-8 encoded strings as defined in Section 1.5.3.
            If the length of a Topic Filter string is zero (0) it is followed by a
            Subscription Identifier encoded as a Variable Byte Integer.
            The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic
            Filter or Subscription Identifier. An UNSUBSCRIBE packet with no
            payload is a protocol violation. See section 4.8 for information about
            handling errors. 


  was:
Each subscription is assigned a subscription identifier at the time it is made. Within each session, the subscription identifiers are unique. The subscription identifiers are part of the session state which is preserved across network disconnection for CleanSession=0 sessions.
When a client is successfully granted a subscription, the server sends back the subscription identifier in the SUBACK packet. The client can then use this to unsubscribe.
When a message is published whose topic string matches multiple subscriptions in a session, the server is permitted to send the client either one message or one message for each subscription. In the first case, the server could annotate the message sent to the client with the subscription identifiers of all matching subscriptions. In the second case, the server could annotate each message sent to the client with the subscription identifier for the subscription for that copy of the message.


> Subscription identification
> ---------------------------
>
>                 Key: MQTT-253
>                 URL: https://issues.oasis-open.org/browse/MQTT-253
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 5
>            Reporter: Andrew Schofield
>            Assignee: Nicholas O'Leary
>            Priority: Minor
>
> Subscribe and unsubscribe operations are performed on topic filters in MQTT 3.1.1. Adding subscription identifiers would enable unambiguous identification of subscriptions.



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