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

Should the unused DUP, QoS, and RETAIN flags be zero in the CONNECT message?

    Details

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

      The client MUST set DUP, QoS, and RETAIN flags be zero in the Connect message but the server is not required to check that they are zero.

      Show
      The client MUST set DUP, QoS, and RETAIN flags be zero in the Connect message but the server is not required to check that they are zero.
    • Resolution:
      Hide

      i) Flag bits in the Connect header must be zero .
      ii) Server MUST check that they are zero.
      iii) All of these bits are reserved for future use.

      Show
      i) Flag bits in the Connect header must be zero . ii) Server MUST check that they are zero. iii) All of these bits are reserved for future use.

      Description

      Should the unused DUP, QoS, and RETAIN flags be zero in the MQTT Connect message? The current mqtt.org specification leaves this open. By
      specifying that they must be zero we make it possible to put them to some use in the future.
      See Draft 04.

        Attachments

          Activity

          Hide
          raphcohn Raphael Cohen (Inactive) added a comment -

          +1 for specifying them as zero. It makes things unambiguous.

          Can anybody else think of any other places where similar restriction might be desired?

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - +1 for specifying them as zero. It makes things unambiguous. Can anybody else think of any other places where similar restriction might be desired?
          Hide
          locke David Locke (Inactive) added a comment -

          I might go one step further and mark the 3 bits as reserved for future use.

          The implication:-
          the input doc has the a header on every command with three bits for DUP, QOS and RETAIN. On connect and other commands these may be meaningless. If meaningless why not make the use of the bits unique to each command. In the case of Connect this could be "reserved for future use".

          This would then provide flexibility for adding features in the future such as flowing additional properties on connect...

          Show
          locke David Locke (Inactive) added a comment - I might go one step further and mark the 3 bits as reserved for future use. The implication:- the input doc has the a header on every command with three bits for DUP, QOS and RETAIN. On connect and other commands these may be meaningless. If meaningless why not make the use of the bits unique to each command. In the case of Connect this could be "reserved for future use". This would then provide flexibility for adding features in the future such as flowing additional properties on connect...
          Hide
          raphcohn Raphael Cohen (Inactive) added a comment -

          I agree they should be reserved

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - I agree they should be reserved
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          Discussed on TC Meeting (23.05.2013): assigned to Andy to implement proposal
          i) Bits must be zero
          ii) Server MUST check them, Names are removed, except in the commands that use them

          Show
          coppen Richard Coppen (Inactive) added a comment - Discussed on TC Meeting (23.05.2013): assigned to Andy to implement proposal i) Bits must be zero ii) Server MUST check them, Names are removed, except in the commands that use them
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          See WD04 lines 514 and 515.
          Scheduled for review at next TC call (06.06.2013)

          Show
          coppen Richard Coppen (Inactive) added a comment - See WD04 lines 514 and 515. Scheduled for review at next TC call (06.06.2013)
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          closed following TC call 06.06.2013

          Show
          coppen Richard Coppen (Inactive) added a comment - closed following TC call 06.06.2013

            People

            • Assignee:
              andrew_banks Andrew Banks (Inactive)
              Reporter:
              andrew_banks Andrew Banks (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: