Details

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

      i) At the moment we don't have any normative requirements on underlying transport protocols.
      That looks a bit odd, but I am ok with that (I think this was a decision we made in 3.1.1).
      However TLS and WebSocket are listed as Normative references

      >>>TLS is now a non normative reference. Websocket is normative because we
      >>>specify some constraints on how it is used.

      ii) 4.10.2 (determining a response topic) is shown as Non-Normative,
      but I think it makes sense to have it Normative,
      as it includes the statement that the Response Info property is OPTIONAL.

      >>>The OPTIONAL response info on CONNACK is now part of the normative definition of the property,
      >>>The description in 4.10.2 is still non normative.

      iii)4.11 (Server redirection) includes Normative language,
      e.g. "the Server MAY also send a Server Reference to indicate the location of the
      Server or Servers the Client SHOULD use.".
      However the format of Server Reference is vendor-specific,
      so I don't see how we can make normative statements about it.

      >>> This requires a TC decision to change this to MUST.

      3. Error handling on QoS 2.

      i) We don't say anything about errors in 4.3.3.
      Should the sender abandon the flow if it gets an error on PUBREC?

      ii) When does a packet id become available for reuse if an error occurs?

      >>> 4.3.3 says
      The Packet Identifier becomes available for reuse
      once the sender has received the PUBCOMP packet or a PUBREL with a Return Code
      of 0x80 or greater.

      iii) What is the meaning of 0x91 - Packet identifier in use? When should it be used,
      and what should you do if you receive a packet that contains it?

      >>>> I added

      Non-Normative comment
      For Return Code 0x91 (Packet identifier in use),
      the response to this is either to try to fix the state,
      or to reset the Session state by connecting using Clean Start set to 1,
      or to decide if the Client or Server implementations are defective.

      4. Flow control paragraph

      Simplify description

      >>>>> This now reads as:

      4.9 Flow Control
      Clients and Servers control the number of unacknowledged PUBLISH packets they
      receive by using a Receive Maximum value as described in section 3.1.2.14 and
      3.2.2.5. The Receive Maximum establishes a send quota which is used to limit
      the number of PUBLISH QOS > 0 packets which can be sent without receiving an
      PUBACK (for QoS 1) or PUBCOMP (for QoS 2). The PUBACK and PUBCOMP replenish
      the quota in the manner described below.

      The Client or Server MUST set its initial send quota to a non-zero value not
      exceeding the Receive Maximum [MQTT-4.9.0-1].

      Each time the Client or Server sends a PUBLISH packet at QoS > 0, it
      decrements the send quota. If the send quota reaches zero, the Client
      or Server MUST NOT send any more PUBLISH packets with QoS > 0 [MQTT-4.9.0-2].
      It MAY continue to send PUBLISH packets with QoS 0, or it MAY choose
      to suspend sending these as well. The Client and Server MUST continue
      to process and respond to all other MQTT Control Packets even if the quota
      is zero [MQTT-4.9.0-3].

      Each time a PUBACK or PUBCOMP packet is received,
      the send quota is incremented by 1. The increment is applied regardless of
      whether the PUBACK or PUBCOMP carried an error code.
      The send quota is not incremented if it is already equal to the
      initial send quota. The attempt to increment above the initial
      send quota might be caused by the retransmission of a PUBREL packet
      after a new Network Connection is established.

      Refer to section 3.3.4 for a description of how Clients
      and Servers react if they are sent more PUBLISH packets
      than the Receive Maximum allows.

      The send quota and Receive Maximum value are not preserved across
      Network Connections, and are re-initialized with each new Network Connection
      as described above. They are not part of the session state.

      Show
      i) At the moment we don't have any normative requirements on underlying transport protocols. That looks a bit odd, but I am ok with that (I think this was a decision we made in 3.1.1). However TLS and WebSocket are listed as Normative references >>>TLS is now a non normative reference. Websocket is normative because we >>>specify some constraints on how it is used. ii) 4.10.2 (determining a response topic) is shown as Non-Normative, but I think it makes sense to have it Normative, as it includes the statement that the Response Info property is OPTIONAL. >>>The OPTIONAL response info on CONNACK is now part of the normative definition of the property, >>>The description in 4.10.2 is still non normative. iii)4.11 (Server redirection) includes Normative language, e.g. "the Server MAY also send a Server Reference to indicate the location of the Server or Servers the Client SHOULD use.". However the format of Server Reference is vendor-specific, so I don't see how we can make normative statements about it. >>> This requires a TC decision to change this to MUST. 3. Error handling on QoS 2. i) We don't say anything about errors in 4.3.3. Should the sender abandon the flow if it gets an error on PUBREC? ii) When does a packet id become available for reuse if an error occurs? >>> 4.3.3 says The Packet Identifier becomes available for reuse once the sender has received the PUBCOMP packet or a PUBREL with a Return Code of 0x80 or greater. iii) What is the meaning of 0x91 - Packet identifier in use? When should it be used, and what should you do if you receive a packet that contains it? >>>> I added Non-Normative comment For Return Code 0x91 (Packet identifier in use), the response to this is either to try to fix the state, or to reset the Session state by connecting using Clean Start set to 1, or to decide if the Client or Server implementations are defective. 4. Flow control paragraph Simplify description >>>>> This now reads as: 4.9 Flow Control Clients and Servers control the number of unacknowledged PUBLISH packets they receive by using a Receive Maximum value as described in section 3.1.2.14 and 3.2.2.5. The Receive Maximum establishes a send quota which is used to limit the number of PUBLISH QOS > 0 packets which can be sent without receiving an PUBACK (for QoS 1) or PUBCOMP (for QoS 2). The PUBACK and PUBCOMP replenish the quota in the manner described below. The Client or Server MUST set its initial send quota to a non-zero value not exceeding the Receive Maximum [MQTT-4.9.0-1] . Each time the Client or Server sends a PUBLISH packet at QoS > 0, it decrements the send quota. If the send quota reaches zero, the Client or Server MUST NOT send any more PUBLISH packets with QoS > 0 [MQTT-4.9.0-2] . It MAY continue to send PUBLISH packets with QoS 0, or it MAY choose to suspend sending these as well. The Client and Server MUST continue to process and respond to all other MQTT Control Packets even if the quota is zero [MQTT-4.9.0-3] . Each time a PUBACK or PUBCOMP packet is received, the send quota is incremented by 1. The increment is applied regardless of whether the PUBACK or PUBCOMP carried an error code. The send quota is not incremented if it is already equal to the initial send quota. The attempt to increment above the initial send quota might be caused by the retransmission of a PUBREL packet after a new Network Connection is established. Refer to section 3.3.4 for a description of how Clients and Servers react if they are sent more PUBLISH packets than the Receive Maximum allows. The send quota and Receive Maximum value are not preserved across Network Connections, and are re-initialized with each new Network Connection as described above. They are not part of the session state.

      Description

      Review comments from Peter (wd14)

      1. Normative / non-Normative

      i) At the moment we don't have any normative requirements on underlying transport protocols. That looks a bit odd, but I am ok with that (I think this was a decision we made in 3.1.1). However TLS and WebSocket are listed as Normative references

      ii) 4.10.2 (determining a response topic) is shown as Non-Normative, but I think it makes sense to have it Normative, as it includes the statement that the Response Info property is OPTIONAL.

      iii) 4.11 (Server redirection) includes Normative language, e.g. "the Server MAY also send a Server Reference to indicate the location of the Server or Servers the Client SHOULD use.". However the format of Server Reference is vendor-specific, so I don't see how we can make normative statements about it.

      3. Error handling on QoS 2.

      i) We don't say anything about errors in 4.3.3. Should the sender abandon the flow if it gets an error on PUBREC?

      ii) When does a packet id become available for reuse if an error occurs?

      iii) What is the meaning of 0x91 - Packet identifier in use? When should it be used, and what should you do if you receive a packet that contains it?

      4. Flow control paragraph

      Simplify description

        Attachments

          Activity

            People

            • Assignee:
              Andrew_Banks Andrew Banks
              Reporter:
              coppen Richard Coppen
            • Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: