OASIS Message Queuing Telemetry Transport (MQTT) TCIcon indicating the project type

OASIS Message Queuing Telemetry Transport (MQTT) TC

Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-65

Should the QoS flag for PUBREL, SUBSCRIBE and UNSUBSCRIBE be reserved ?

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.1
    • Component/s: core
    • Labels:
      None
    • Proposal:
      Hide

      bits 2,1 (the QoS flag) of the fixed header for PUBREL, SUBSCRIBE and UNSUBSCRIBE are reserved and must be set to 0,1. The server MUST treat any other value as malformed and close the TCP Connection.

      Show
      bits 2,1 (the QoS flag) of the fixed header for PUBREL, SUBSCRIBE and UNSUBSCRIBE are reserved and must be set to 0,1. The server MUST treat any other value as malformed and close the TCP Connection.
    • Resolution:
      Hide

      Resolved in WD10 Lines 868, 992, 1033

      Show
      Resolved in WD10 Lines 868, 992, 1033

      Description

      The current spec is ambiguous with respect to the acceptable values of the QoS flag for PUBREL, SUBSCRIBE and UNSUBSCRIBE operations.
      It could be interpreted that QoS must be set to 1 to force an appropriate ACK. However the ACK behavior is described independently.

      do we accept only one value ?
      if so, should it be 0, 1 or 2?
      Are other values be treated as malformed?

      Forcing 0 would change the protocol flow on the wire.
      Forcing 1 is consistent with the spirit of the input spec, but we need some clarity. The intended ACK behavior is not really related to QoS.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          coppen Richard Coppen (Inactive) created issue -
          Hide
          Permalink
          raphcohn Raphael Cohen (Inactive) added a comment -

          I'm going to argue there's no one completely right answer. However, for consistency, I'd go with forcing 1. If we leave it 'woolly', then we create difficulties down the road if we ever do want to use any of these values for something else.

          Does any one know what current implementations of clients do?

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - I'm going to argue there's no one completely right answer. However, for consistency, I'd go with forcing 1. If we leave it 'woolly', then we create difficulties down the road if we ever do want to use any of these values for something else. Does any one know what current implementations of clients do?
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          Agreed Raph. I think it makes sense to define clearly what the client must flow and what the server must reject.

          Show
          coppen Richard Coppen (Inactive) added a comment - Agreed Raph. I think it makes sense to define clearly what the client must flow and what the server must reject.
          Hide
          Permalink
          raphcohn Raphael Cohen (Inactive) added a comment -

          On Behalf of Roger Light:-

          Hello,

          The mosquitto broker and clients set the fixed header QoS bits to 1
          for PUBREL, SUBSCRIBE and UNSUBSCRIBE. On receipt of one of those
          messages they don't verify if QoS is set to 1 however, because it's
          already clear what needs to be done.

          It feels as though specifying the QoS here is more notional/for
          completeness than in the PUBLISH case. It doesn't provide any extra
          information.

          Cheers,

          Roger

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - On Behalf of Roger Light:- Hello, The mosquitto broker and clients set the fixed header QoS bits to 1 for PUBREL, SUBSCRIBE and UNSUBSCRIBE. On receipt of one of those messages they don't verify if QoS is set to 1 however, because it's already clear what needs to be done. It feels as though specifying the QoS here is more notional/for completeness than in the PUBLISH case. It doesn't provide any extra information. Cheers, Roger
          Hide
          Permalink
          raphcohn Raphael Cohen (Inactive) added a comment -

          Ta Roger for the comments.

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - Ta Roger for the comments.
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          discussed at scrub call on 08.08.2013. Proposal updated for TC vote on next call

          Show
          coppen Richard Coppen (Inactive) added a comment - discussed at scrub call on 08.08.2013. Proposal updated for TC vote on next call
          andrew_banks Andrew Banks (Inactive) made changes -
          Field Original Value New Value
          Resolution Resolved in WD10 Lines 868, 992, 1033
          Status New [ 10000 ] Open [ 1 ]
          andrew_banks Andrew Banks (Inactive) made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          TC approve at TC call 15.08.2013

          Show
          coppen Richard Coppen (Inactive) added a comment - TC approve at TC call 15.08.2013
          coppen Richard Coppen (Inactive) made changes -
          Status Resolved [ 5 ] Applied [ 10002 ]
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          checked WD12

          Show
          coppen Richard Coppen (Inactive) added a comment - checked WD12
          coppen Richard Coppen (Inactive) made changes -
          Status Applied [ 10002 ] Closed [ 6 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              coppen Richard Coppen (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: