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-313

MQTT 5.0 WD07 CONNACK code Incompatible with MQTT 3.1 and MQTT 3.1.1

    Details

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

      Should the TC decide it is desirable to maintain cross version interoperability in this case, I think the following would be required.

      1.) All versions use the same return value (1) to signify incorrect protocol version.

      2) MQTT 5.0 should require that that if a connect can be processed to the point that the version can be established, the first validation check should be the version, and the value 1 SHOULD be returned and the connection closed. The server MAY choose not to send a CONNACK.

      Show
      Should the TC decide it is desirable to maintain cross version interoperability in this case, I think the following would be required. 1.) All versions use the same return value (1) to signify incorrect protocol version. 2) MQTT 5.0 should require that that if a connect can be processed to the point that the version can be established, the first validation check should be the version, and the value 1 SHOULD be returned and the connection closed. The server MAY choose not to send a CONNACK.

      Description

      The interoperability of CONNACK(unsupported protocol level) between MQTT 5.0 WD07 and MQTT 3.1.1 and MQTT 3.1 seems to be broken. My questions are 'is this a defect' and 'should it be changed'.

      MQTT 5.0 WD07 uses a different CONNACK return code for this condition as summarized be low

      Ver retval retval
      0x01 0x84
      3.1 unsupported prot. level UNDEFINED-RESERVED
      3.1.1 unsupported prot. level UNDEFINED-RESERVED
      5.0 WD07 UNDEFINED-RESERVED unsupported protocol level

      As a consequence, the following useful exchanges no longer work

      3.1 or 3.1.1 Client 5.0 WD07 Server
      CONNECT 3.1 ->
      <- CONNACK 0x84
      UNSPECIFIED

      • - -

      3.1 or 3.1.1 Client 5.0 WD07 Server
      CONNECT 3.1.1 ->
      <- CONNACK 0x84
      UNSPECIFIED

      5.0 WD07 Client MQTT 3.1 or 3.1.1 Server
      CONNECT 5.0 ->
      <- CONNACK 1
      UNSPECIFIED

      Comments

      I submit interoperability is necessary in this ONE particular case.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          ken.borgendale Ken Borgendale (Inactive) added a comment -

          I do not understand the issue. We did recognize that in changing the Connect Return Code values we create some extra work for a client which supports multiple version of the spec. If the client only supports one version of the spec, there is very little it can do if it receives a return code of Unsupported version regardless of what the encoding of that return code is.

          If a client supports both V3.1.1 and V5 then it should understand both return codes and from that be able to determine its retry with an alternate version.

          In reality, most servers will not respond with this return code at all as they will consider a CONNECT with a version they do not support as malformed as they cannot extract the authentication information.

          Show
          ken.borgendale Ken Borgendale (Inactive) added a comment - I do not understand the issue. We did recognize that in changing the Connect Return Code values we create some extra work for a client which supports multiple version of the spec. If the client only supports one version of the spec, there is very little it can do if it receives a return code of Unsupported version regardless of what the encoding of that return code is. If a client supports both V3.1.1 and V5 then it should understand both return codes and from that be able to determine its retry with an alternate version. In reality, most servers will not respond with this return code at all as they will consider a CONNECT with a version they do not support as malformed as they cannot extract the authentication information.
          Hide
          Permalink
          edbriggs Ed Briggs [X] (Inactive) added a comment -

          Hi Ken
          I think the error code should help support staff/users determine they have incompatible versions. That doesn't see to work in the cases I depicted above.

          Show
          edbriggs Ed Briggs [X] (Inactive) added a comment - Hi Ken I think the error code should help support staff/users determine they have incompatible versions. That doesn't see to work in the cases I depicted above.
          Hide
          Permalink
          edbriggs Ed Briggs [X] (Inactive) added a comment -

          Closing based on feedback from the TC.

          Show
          edbriggs Ed Briggs [X] (Inactive) added a comment - Closing based on feedback from the TC.
          Hide
          Permalink
          ken.borgendale Ken Borgendale (Inactive) added a comment -

          Issue included in MQTTv5.0 CS01 December 25, 2017

          Show
          ken.borgendale Ken Borgendale (Inactive) added a comment - Issue included in MQTTv5.0 CS01 December 25, 2017

            People

            • Assignee:
              edbriggs Ed Briggs [X] (Inactive)
              Reporter:
              edbriggs Ed Briggs [X] (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: