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

Return codes not tied to MUST statements

    XMLWordPrintable

    Details

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

      Tie down a core set of return codes with MUST conditions in the spec narrative so that it's clear when a return code is used. Implementers can then code around these.

      Some flexibility is required where a set of error conditions happen at the same time or where the implementation wishes to be vague for security reasons.

      Show
      Tie down a core set of return codes with MUST conditions in the spec narrative so that it's clear when a return code is used. Implementers can then code around these. Some flexibility is required where a set of error conditions happen at the same time or where the implementation wishes to be vague for security reasons.
    • Resolution:
      Hide

      No action

      Show
      No action

      Description

      There are a number of places in the spec where we associate return codes to error conditions but don't go as far as to make it a MUST condition.

      For example:

      A Topic Alias value of 0 or greater than the Maximum Topic Alias is a protocol error, the receiver uses DISCONNECT with Return Code of 0x94 (Topic Alias invalid) as described in section 4.13.

      It's not clear what would happen if the receiver didn't use 0x94, would that still be a conformant implementation ?

      In other places we define an appropriate return code around the boundary of 128 (pick a code ...less than or greater than).

      Some of the codes listed in the tables are not referenced in the narrative. As such it's up to the implementer to evaluate and pick the best the code and for a given condition. One concern is that this could lead to implementers making different decisions and, as a result, writing code to handle certain conditions may or may not get triggered depending on the client:server pairing.

      One approach is to view the codes more generally e.g., <128 is OK >=128 is bad, but this doesn't seem to improve much on what's gone before.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              coppen Richard Coppen
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: