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

      i) Flag bits in all MQTT flows must be zero unless specified otherwise.
      ii) Server MUST check that they are zero and disconnect the client if they are not zero.
      iii) All of these bits are reserved for future use.

      Show
      i) Flag bits in all MQTT flows must be zero unless specified otherwise. ii) Server MUST check that they are zero and disconnect the client if they are not zero. iii) All of these bits are reserved for future use.

      Description

      This extends issue 5 to all other commands.

        Attachments

          Activity

          Hide
          ragupta2 Rahul Gupta (Inactive) added a comment -

          This issue is an extension of problem described in MQTT-5 for CONNECT command message.

          Command Fixed header DUP, QOS, RETAIN Flags used
          ------------------ ---------------------------------------------------------------
          CONNECT NO -----> Issue discussed in MQTT-5
          CONNACK NO
          PUBLISH YES ------> not an issue
          PUBACK NO
          PUBREC NO
          PUBREL YES ------> not an issue
          PUBCOMP NO
          SUSCRIBE YES ------> not an issue
          SUBACK NO
          UNSUBSCRIBE YES ------> not an issue
          UNSUBACK NO
          PINGREQ NO
          PINGRESP NO
          DISCONNECT NO

          The issue is opened in general for fixed header flags (DUP, QOS, RETAIN) in nine other command messages.

          Also what should the receiver of these command messages do in case the bits are not set to zero and are malformed ? Do we need to discuss this as a separate JIRA issue for different command messages ?

          Documentation currently done in WD-04 for CONNECT command message :
          "Bits 3,2,1,0 are reserved for future use and MUST be set to zero by the client. The server MUST check that these bits are set to zero and disconnect the client if they are not set to zero."

          Suggestions welcome .

          Show
          ragupta2 Rahul Gupta (Inactive) added a comment - This issue is an extension of problem described in MQTT-5 for CONNECT command message. Command Fixed header DUP, QOS, RETAIN Flags used ------------------ --------------------------------------------------------------- CONNECT NO -----> Issue discussed in MQTT-5 CONNACK NO PUBLISH YES ------> not an issue PUBACK NO PUBREC NO PUBREL YES ------> not an issue PUBCOMP NO SUSCRIBE YES ------> not an issue SUBACK NO UNSUBSCRIBE YES ------> not an issue UNSUBACK NO PINGREQ NO PINGRESP NO DISCONNECT NO The issue is opened in general for fixed header flags (DUP, QOS, RETAIN) in nine other command messages. Also what should the receiver of these command messages do in case the bits are not set to zero and are malformed ? Do we need to discuss this as a separate JIRA issue for different command messages ? Documentation currently done in WD-04 for CONNECT command message : "Bits 3,2,1,0 are reserved for future use and MUST be set to zero by the client. The server MUST check that these bits are set to zero and disconnect the client if they are not set to zero." Suggestions welcome .
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          discussed on call 20.06.2013

          Show
          coppen Richard Coppen (Inactive) added a comment - discussed on call 20.06.2013
          Hide
          andrew_banks Andrew Banks (Inactive) added a comment -

          Resolved in draft 06

          Show
          andrew_banks Andrew Banks (Inactive) added a comment - Resolved in draft 06
          Hide
          coppen Richard Coppen (Inactive) added a comment -

          Addressed in WD06

          Show
          coppen Richard Coppen (Inactive) added a comment - Addressed in WD06

            People

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

              Dates

              • Created:
                Updated:
                Resolved: