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

3.10.1 Fixed Header - malformed? (4)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: None
    • Component/s: core
    • Labels:
      None
    • Environment:

      Normative

    • Proposal:
      Hide

      Remove lines 430-431 in Chapter 2 , which deal with protocol violations.

      Add terminology definitions;

      Protocol Violation: A Control Packet that is not constructed or flowed in a way which conforms to this specification.

      Transient Error: A transient error is an error which may not re occur if the action that caused it is repeated.
      Non Normative comment.
      For example, an authorization failure of a PUBLISH Packet might not re occur the next time a similar PUBLISH Packet
      is received, if the administrator has authorized the client to make the publication in the mean time.

      Rewrite Section 4.8 line 1557 on as follows:

      4.8 Handling errors.

      Unless stated otherwise, if either the Server or Client encounters a Protocol Violation, it MUST close the Network Connection on which it received that Control Packet which caused the Protocol Violation. [MQTT-4.8.0-1].

      If the Client or Server encounters a Transient Error while processing an inbound Control Packet it MUST close the Network Connection on which it received that Control Packet [MQTT-4.8.0-2]. If a Server detects a transient error it SHOULD NOT disconnect or have any other affect on its interactions with any other Client.

      Show
      Remove lines 430-431 in Chapter 2 , which deal with protocol violations. Add terminology definitions; Protocol Violation: A Control Packet that is not constructed or flowed in a way which conforms to this specification. Transient Error: A transient error is an error which may not re occur if the action that caused it is repeated. Non Normative comment. For example, an authorization failure of a PUBLISH Packet might not re occur the next time a similar PUBLISH Packet is received, if the administrator has authorized the client to make the publication in the mean time. Rewrite Section 4.8 line 1557 on as follows: 4.8 Handling errors. Unless stated otherwise, if either the Server or Client encounters a Protocol Violation, it MUST close the Network Connection on which it received that Control Packet which caused the Protocol Violation. [MQTT-4.8.0-1] . If the Client or Server encounters a Transient Error while processing an inbound Control Packet it MUST close the Network Connection on which it received that Control Packet [MQTT-4.8.0-2] . If a Server detects a transient error it SHOULD NOT disconnect or have any other affect on its interactions with any other Client.

      Description

      A few comments ago I mused about whether 4.8 Handling protocol violations listed all the protocol violations in the draft.

      Turns out it doesn't.

      Looking under 3.10.1, a value can be malformed and the server MUST close the network connection. That sounds like a protocol violation to me.

      On looking further, similar "malformed" statement occur at: 3.8.3 Payload, 3.8.1 Fixed Header, 3.6.1 Fixed header.

      If those are protocol violations and as normative statements I can't see them being anything else, then they should be reported under 4.8.

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          Section 4.8 should describe general error handling. Currently title does not match content.

          Many conformance statement state - in line - what to do if a specific condition is not met, often this results in 'close the connection'

          It would be clearer to build simple normative statements around error handling in within Section 4.8 (consuming statement [2.0.0.1]). We can then link to the described behavior without duplicating the detail of the correct action in each statement. The format would be 'if this happens, then the result is a protocol violation' etc.

          See issue MQTT-193 - Currently inconsistent on how we describe 'disconnect behavior' some control packets are lacking a description, some spell it out and some link to 4.8 which doesn't always say what the right thing to do is. There are a number of missing conformance statements.

          Show
          coppen Richard Coppen (Inactive) added a comment - Section 4.8 should describe general error handling. Currently title does not match content. Many conformance statement state - in line - what to do if a specific condition is not met, often this results in 'close the connection' It would be clearer to build simple normative statements around error handling in within Section 4.8 (consuming statement [2.0.0.1] ). We can then link to the described behavior without duplicating the detail of the correct action in each statement. The format would be 'if this happens, then the result is a protocol violation' etc. See issue MQTT-193 - Currently inconsistent on how we describe 'disconnect behavior' some control packets are lacking a description, some spell it out and some link to 4.8 which doesn't always say what the right thing to do is. There are a number of missing conformance statements.
          Hide
          Permalink
          andrew_banks Andrew Banks (Inactive) added a comment -

          Resloved in WD18

          Show
          andrew_banks Andrew Banks (Inactive) added a comment - Resloved in WD18

            People

            • Assignee:
              Unassigned
              Reporter:
              patrick Patrick Durusau
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: