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

Editorial comments on 2.1.3 (Remaining Length) and 2.1.4 (Multibyte Length)

    XMLWordPrintable

    Details

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

      Multibyte length removed and Remaining length section at Line 380 updated.

      Show
      Multibyte length removed and Remaining length section at Line 380 updated.
    • Resolution:
      Hide

      Resolved in WD09

      Show
      Resolved in WD09

      Description

      1. In WD04, there's a short paragraph - 2.1.3 that describes the Remaining Length field. It contains only two important facts
      i) The remaining length doesn't include its own length
      ii) It is encoded as a "Multibyte Length"

      There's a much longer section 2.1.4, which describes the "Multibyte Length" encoding. However seeing as this encoding is only used for the Remaining Length field, there doesn't seem much point having two separate sections and the concept of a "Multibyte Length". . I suggest that we merge 2.1.3 and 2.1.4 and we stop talking about "Multibyte Lengths". This means that the references to 2.1.4 that appear throughout section 3 would then simply point you to 2.1.3 for all information about the Remaining Length field. If you really want to refer to the encoding format independently from its use for Remaining Length it should be something like "Multi Byte Integer".

      2. The non-normative encode and decode algorithms refer to something they call "digits", when I think they mean "bytes" or "octets". In particular in line 412 it says "digit = 'next digit from stream' ".

      3. The termination check in the decode algorithm is not safe. It will continue reading bytes until it encounters one < 128, so if you feed it malformed input it could end up processing more than 4 b ytes of input data. I realize this is non-normative, but we should be encouraging developers to code defensively and raise an error if they encounter 4 successive bytes all > 127.

        Attachments

          Activity

            People

            • Assignee:
              ragupta2 Rahul Gupta (Inactive)
              Reporter:
              peterniblett Peter Niblett (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: