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

Should the CONNECT packet Protocol Name and Protocol Version fields be changed?

    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

      The Protocol Name field will be referred to as an immutable string, following the standard convention of two prefix bytes indicating length followed by the content 'MQTT'.
      The Protocol Version field will be renamed Protocol Level, specified as an unsigned 8bit integer, and for this release of the specification set as the value 4.

      Show
      The Protocol Name field will be referred to as an immutable string, following the standard convention of two prefix bytes indicating length followed by the content 'MQTT'. The Protocol Version field will be renamed Protocol Level, specified as an unsigned 8bit integer, and for this release of the specification set as the value 4.

      Description

      The draft specification states that the Bytes 1 to 9 of the variable header section of the CONNECT packet are currently a spec encoded string (2 prefix bytes indicating the string length followed by the string data) containing the letters 'MQIsdp' followed by the number 3. Changing these fields would be an easy way to differentiate between old and OASIS spec compliant clients.

      Reasons for wanting to differentiate between clients include using discrimination of access to MQTT servers and understanding/implementing behavioural differences.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          raphcohn Raphael Cohen (Inactive) added a comment -

          Some observations:-

          • Whilst it's nice to have this string use the same generic encoding, simple deep packet inspectors (eg firewalls) will want the offset of this version string to be constant, and the size to be constant
          • It may be worth considering that the size and offset should remain constant even between major versions
          • I'd suggest we end the differentiation in the spec between the letters and the number - and just make the whole thing a 'version token'. After all, any inspector is simply going to do a 'string switch' or hash map like dispatch. That's not to say that the value could be 'MQTT311' or whatever, just that there's no separation (ie it's opaque).
          Show
          raphcohn Raphael Cohen (Inactive) added a comment - Some observations:- Whilst it's nice to have this string use the same generic encoding, simple deep packet inspectors (eg firewalls) will want the offset of this version string to be constant, and the size to be constant It may be worth considering that the size and offset should remain constant even between major versions I'd suggest we end the differentiation in the spec between the letters and the number - and just make the whole thing a 'version token'. After all, any inspector is simply going to do a 'string switch' or hash map like dispatch. That's not to say that the value could be 'MQTT311' or whatever, just that there's no separation (ie it's opaque).
          Hide
          Permalink
          al.s-m Allan Stockdill-Mander (Inactive) added a comment -

          I have no issue with removing the first two bytes that indicate the size of the Protocol Name string, and agree its size should be constant between versions.
          I would however want there to be a notional difference between the Protocol Name and the Protocol Level, the latter remaining a single integer rather than a character representation of the version number. It would be simpler to programatically determine whether a client Protocol Level is a supported one.

          Show
          al.s-m Allan Stockdill-Mander (Inactive) added a comment - I have no issue with removing the first two bytes that indicate the size of the Protocol Name string, and agree its size should be constant between versions. I would however want there to be a notional difference between the Protocol Name and the Protocol Level, the latter remaining a single integer rather than a character representation of the version number. It would be simpler to programatically determine whether a client Protocol Level is a supported one.
          Hide
          Permalink
          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
          Permalink
          andrew_banks Andrew Banks (Inactive) added a comment -

          Resolved in Draft 06 lines 449-607

          Show
          andrew_banks Andrew Banks (Inactive) added a comment - Resolved in Draft 06 lines 449-607
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          Addressed in WD06 (529)

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

            People

            • Assignee:
              andrew_banks Andrew Banks (Inactive)
              Reporter:
              al.s-m Allan Stockdill-Mander (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: