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

WD9: Inconsistencies/Overlaps in Return Codes

    XMLWordPrintable

    Details

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

      There is no statement in the WD that Return Code values are "global" rather than being specific to a particular control packet?

      >>> Each packet now makes it clear that only the return codes listed are to be used.

      From Roger Light on mqtt-comment:

      In table 3.13 for disconnect codes, the code 139 is "server shutting
      down". In table 3.6 for pubrec return codes, the code 139 is "topic
      invalid". This looks to be a typo in table 3.6 because code 144
      already exists for "topic invalid".

      >>>> Removed RC=139.

      The description of the return codes is a bit inconsistent. Sticking
      with the invalid topic case, it is variously described as

      Topic invalid : The topic is invalid
      Topic Filter not valid : The topic filter is correctly formed, but is
      not allowed for this client
      Topic name or filter not valid : The topic name or filter is valid,
      but it is not accepted by this client or server.

      I see that these apply to different scenarios, but the different
      descriptions are confusing. Should I take "the topic is invalid" to
      mean that it is not correctly formed? What is the difference between
      "is correctly formed" and "is valid"?

      >>>> Changed the description of the PubRec and PubAck cases to say "Topic Name"
      >>>> and say that the topic name is correctly formed but not allowed by the client or server,
      >>>> consistent with the SubAck Unsuback and disconnect cases.

      I don't think descriptions of a term should just repeat the same words
      as the term itself, it doesn't clarify anything.

      I've spotted some more overlaps in return codes.

      Return code 154 is used by both pubrec and puback as "qos level not
      supported", and disconnect as "alias not supported".

      >>>> 155 Maximum Qos is now a Disconnect return code and not used pun PubAck or PubRec.

      Return code 159 is used by subscribe as "subscription identifiers not
      supported" and connack as "connection rate exceeded".

      161 is no used for "subscription identifiers not
      supported" in SubAck.

      Some return codes aren't used - 141, 147, 148.

      >>>> Did not fix this...

      Show
      There is no statement in the WD that Return Code values are "global" rather than being specific to a particular control packet? >>> Each packet now makes it clear that only the return codes listed are to be used. From Roger Light on mqtt-comment: In table 3.13 for disconnect codes, the code 139 is "server shutting down". In table 3.6 for pubrec return codes, the code 139 is "topic invalid". This looks to be a typo in table 3.6 because code 144 already exists for "topic invalid". >>>> Removed RC=139. The description of the return codes is a bit inconsistent. Sticking with the invalid topic case, it is variously described as Topic invalid : The topic is invalid Topic Filter not valid : The topic filter is correctly formed, but is not allowed for this client Topic name or filter not valid : The topic name or filter is valid, but it is not accepted by this client or server. I see that these apply to different scenarios, but the different descriptions are confusing. Should I take "the topic is invalid" to mean that it is not correctly formed? What is the difference between "is correctly formed" and "is valid"? >>>> Changed the description of the PubRec and PubAck cases to say "Topic Name" >>>> and say that the topic name is correctly formed but not allowed by the client or server, >>>> consistent with the SubAck Unsuback and disconnect cases. I don't think descriptions of a term should just repeat the same words as the term itself, it doesn't clarify anything. I've spotted some more overlaps in return codes. Return code 154 is used by both pubrec and puback as "qos level not supported", and disconnect as "alias not supported". >>>> 155 Maximum Qos is now a Disconnect return code and not used pun PubAck or PubRec. Return code 159 is used by subscribe as "subscription identifiers not supported" and connack as "connection rate exceeded". 161 is no used for "subscription identifiers not supported" in SubAck. Some return codes aren't used - 141, 147, 148. >>>> Did not fix this...

      Description

      There is no statement in the WD that Return Code values are "global" rather than being specific to a particular control packet?

      From Roger Light on mqtt-comment:

      In table 3.13 for disconnect codes, the code 139 is "server shutting
      down". In table 3.6 for pubrec return codes, the code 139 is "topic
      invalid". This looks to be a typo in table 3.6 because code 144
      already exists for "topic invalid".

      The description of the return codes is a bit inconsistent. Sticking
      with the invalid topic case, it is variously described as

      Topic invalid : The topic is invalid
      Topic Filter not valid : The topic filter is correctly formed, but is
      not allowed for this client
      Topic name or filter not valid : The topic name or filter is valid,
      but it is not accepted by this client or server.

      I see that these apply to different scenarios, but the different
      descriptions are confusing. Should I take "the topic is invalid" to
      mean that it is not correctly formed? What is the difference between
      "is correctly formed" and "is valid"?

      I don't think descriptions of a term should just repeat the same words
      as the term itself, it doesn't clarify anything.

      I've spotted some more overlaps in return codes.

      Return code 154 is used by both pubrec and puback as "qos level not
      supported", and disconnect as "alias not supported".

      Return code 159 is used by subscribe as "subscription identifiers not
      supported" and connack as "connection rate exceeded".

      Some return codes aren't used - 141, 147, 148.

        Attachments

          Activity

            People

            • Assignee:
              ken.borgendale Ken Borgendale (Inactive)
              Reporter:
              brianraymor Brian Raymor [X] (Inactive)
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: