Details

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

      Description

      WD11 Notes.

      660 1.5.6 Binary Data

      663 Where used the data consists only of the data portion of the field,

      This is unnecessary.

      666 1.5.7 UTF-8 String Pair

      667 A UTF-8 String pair

      Should be UTF-8 String Pair

      668 . The first string serves as the name, and the second string contains the value.

      should be:
      The first string is the name, and the second string is the value.

      680 1.7 Editing convention etc.

      Should be moved to before 1.5 Data representation

      813 3 MQTT Control Packets

      815 3.1 CONNECT - Connection Request

      824 Will Topic, Will Message, User Name and Password.
      All but the Client identifier are optional and their

      We should not use the word "optional" use something else.
      Will messages etc are not OPTIONAL, they MUST be supported.

      eg use:All but the Client Identifier can be omitted.

      831 This is the length of the Variable Header plus the length of the Payload
      encoded as a Variable Byte Integer.

      should be:
      This is the length of the Variable Header plus the length of the Payload.
      It is encoded as a Variable Byte Integer.

      835 The Variable Header for the CONNECT Packet contains the following fields in the order:
      Protocol Name, Protocol Level, Connect Flags, Keep Alive, Property Length, and Properties.
      The rules for encoding Properties are described in section 2.2.3.

      Should be:
      The Variable Header for the CONNECT Packet contains the following fields in this order:
      Protocol Name, Protocol Level, Connect Flags, Keep Alive, Property Length, and Properties.
      The rules for encoding Properties are described in section 2.2.3.

      Redefine "Property Length, and Properties" to be Properies throuought the spec
      so it includes the length. section 3.2.1 Properties needs to be clear that the term "Properties"
      means the Properties and their length, and that a length of 0 means that there are no properties.

      844 A Server which supports multiple protocols uses the Protocol Name
      to verify that it has received a CONNECT packet.
      If the Server does not want to process the data and wishes
      to reveal that it is an MQTT Server it MAY send a CONNACK packet with Return Code of 0x84
      (Unsupported Protocol Version)
      as described in section 4.13 Handling errors, and then close the Network Connection.

      Should be:
      The protocol name MUST be the UTF-8 String "MQTT".
      If the Server does not want to accept the CONNECT, and wishes to reveal
      that it is an MQTT Server it MAY send a CONNACK packet with Return Code of 0x84
      (Unsupported Protocol Version),
      and then it MUST close the Network Connection.

      857 A Server which supports multiple versions of the MQTT protocol uses the
      Protocol Version to verify that it has received a
      Version 5 CONNECT packet. If the Protocol Version is not 5 and the
      Server does not want to process the data, the Server MAY send
      a CONNACK packet with Return Code 0x84 (Unsupported Protocol Version)
      as described in section 4.13 Handling errors,
      and then close the Network Connection.

      Should be:

      A Server which supports multiple versions of the MQTT protocol uses the
      Protocol Version to determine which version of MQTT the Client is using.
      If the Protocol Version is not 5 and the
      Server does not want to accept the CONNECT packet, the Server MAY send
      a CONNACK packet with Return Code 0x84 (Unsupported Protocol Version)
      and then MUST close the Network Connection.

      865 the . [space to next letter] format seems to change
      Session state is introduced as "Session State" and then referred to as "Session state"

      866 the reserved flag is not zero

      Should be;
      the reserved flag is not 0

      866 Refer to section 4.13

      Should be:
      Refer to section 4.13.1

      881 If the Will Flag is set to 1 this indicates that,
      if the CONNECT packet is accepted, a Will Message MUST

      should be;
      If the Will Flag is set to 1 this indicates that a Will Message MUST

      844 deleted by the Server on receipt of a DISCONNECT packet with Return Code 0x00 (Success)
      or 0x04 (Disconnect with Will Message) [MQTT-3.1.2-4].

      The 0x04 should go. (the will is published).
      Also delete 0x04 on lines 889 and 891.

      922 3.1.2.7 Will Retain

      928 If the Will Flag is set to 1:
      " If Will Retain is set to 0, the Server MUST publish the Will Message as a non-retained message. [MQTT-3.1.2-12]
      " If Will Retain is set to 1, the Server MUST publish the Will Message as a retained message. [MQTT-3.1.2-13]

      The conformance clauses need to contain "If the Will Flag is set to 1:"

      938 3.1.2.9 Password Flag

      Add a non normative comment to say that you can now send password with no user name
      unlke in 3.1.1.

      975 3.1.2.11 Property Length

      Shoulkd look like...

      3.1.2.11 Properties
      3.1.2.11.1 Property Length
      3.1.2.11.2 Session Expiry interval
      etc.

      985 3.1.2.12.1 Session State
      Should be in section 4 and refered to from elsewhere. except for ...

      986 The Client and Server are required to store Session state so that reliable
      messaging can continue across a sequence of Network Connections.
      After the Network Connection is closed and the Session Expiry Interval
      has elapsed without a new connection being made, the Client and Server
      MUST delete the Session state they hold [MQTT-3.1.2-21].

      Belongs with Session Expiry.

      See the change to Session Present checking on CONNACK .
      It should become:
      The Client and Server MUST store Session state so that reliable
      messaging can continue across a sequence of Network Connections.
      If a Network Connection is closed and the Session Expiry Interval
      has elapsed without a new connection being made, the Client and Server
      are allowed to delete the Session state they hold [MQTT-3.1.2-21].

      986 If a new Network Connection is made before the Session has expired,
      the Server MUST resume communications with the Client based on state from
      the current Session (as identified by the Client identifier) [MQTT-3.1.2-22].
      If there is no Session associated with the Client identifier the
      Server MUST create a new Session [MQTT-3.1.2-23]. The Client and Server MUST store
      the Session after the Network Connection is closed [MQTT-3.1.2-24].

      Should be in Clean Start as:
      If Clean Start is set to 0 before a Session has expired,
      the Server MUST resume communications with the Client based on state
      from the current Session (as identified by the Client identifier) [MQTT-3.1.2-22].
      If there is no Session associated with the Client identifier the
      Server MUST create a new Session [MQTT-3.1.2-23].

      And the following should be added to the Session state paragraph in section 4.
      The Client and Server MUST store the Session
      after the Network Connection is closed [MQTT-3.1.2-24].

      1029 Non-Normative comment
      Typically, a Client will always connect using the same Session Expiry Interval.
      The choice will depend on the application. A Client that has its Session Expiry
      Interval always set to 0 will not receive old Application Messages and has to
      subscribe afresh to any topics that it is interested in each time it connects.
      A Client using a non-zero Session Expiry Interval will receive all QoS 1 or QoS 2
      messages that were published while it was disconnected provided that its Session has not expired.

      Recast this to describe the session expiry zero transient case.
      The other cases are described in the next non normative comments. eg.

      A Client that only wants to process messages while connected will set the Session Expiry
      Interval set to 0. It will not receive Application Messages published before it connected and has to
      subscribe afresh to any topics that it is interested in each time it connects.

      1047 Non-Normative comment
      If the Client connects using this protocol,
      then reconnects using the MQTT V3.1.1 protocol using CleanStart 0
      before the Session has expired, the Session state is kept indefinitely.

      This should go. While helpful, it's an unusual case to downgrage back to
      V3.1.1 and hence might confuse the reader.

      1110 It is the responsibility of the application to select a suitable Maximum packet size value if it

      should be:

      It is the responsibility of the application to select a suitable Maximum Packet Size value if it

      1125 but other Clients can receive it, the Server can choose either discard the message without sending the
      message to any of the Clients, or send the message to one of the Clients that can receive it.

      Should be:
      but other Clients can receive it, the Server can choose either to discard the message without sending the
      message to any of the Clients, or to send the message to one of the Clients that can receive it.

      1178 UTF-8 String

      Followed by a UTF-8 string pair.

      1286 being used to serve

      "used to process" avoids the double use of serve

      1309 3.2 CONNACK - Connect acknowledgement

      1333 Bit 0 (SP1) is the Session Present Flag.

      Not sure what the SP^1 means

      1337 If the Server accepts a connection with Session Expiry Interval set to 0

      Should be:
      If the Server accepts a connection with Clean Start set to 1

      1341 If the Server accepts a connection with non-zero Session Expiry Interval,

      Should be:
      If the Server accepts a connection with Clean Start set to 0,

      1349 view about whether there is already stored Session state.

      Should be Session State ?

      1351 Once the initial setup of a Session is complete,
      a Client with stored Session state will expect the
      Server to maintain its stored Session state.
      If the value of Session Present received by the Client
      from the Server is not as expected,
      the Client can choose whether to proceed with the
      Session or to close the Network Connection.
      The Client can discard the Session state on both Client and Server by
      sending a DISCONNECT packet with Session Expiry set to 0.

      Should be:
      The session Present flag allows the Client to validate that the Session state
      is as expected.

      If the value of Session Present received by the Client
      is 1 when it expected 0, the Client MUST disconnect.
      It can then then reconnect using Clean Start set to 1.

      If the value of Session Present received by the Client
      is 0 when it expected 1, the Client MUST delete its Session state
      if it wishes to continue with the connection.

      1453 Followed by a Byte field. If present,

      Is there double space between . and If ?

      1608 3.3 PUBLISH - Publish message

      1740 A Server MUST send the Payload Format Indicator unaltered to all subscribers
      receiving the publication [MQTT-3.3.2-4].
      The receiver MUST validate that the Payload is of the format indicated,
      and if it is not send a PUBACK, PUBREC, or DISCONNECT with Return Code of 0x99
      (Payload format invalid) as described in section 4.13 [MQTT-3.3.2-5].

      So both clients and server MUST validate that the string is correct UTF-8!
      This should be a MAY validate.

      1805 Refer to section 4.10 for more information about how Request / Response works."

      is in several places. It sounds a bit ugly. Can we can say:
      Refer to section 4.10 for more information on Request / Response."

      1964 3.4 PUBACK - Publish acknowledgement

      1981 Byte 3 in the Variable Header is the PACK Return Code.

      Should be:
      Byte 3 in the Variable Header is the PUBACK Return Code.

      1986 If the Server does not know if there are any matching subscribers,
      it MUST use the 0x00 (Success) Return Code [MQTT-3.4.2-1].

      If the server wants to use the minumum packet size with remaining length 2
      is it allowed to imply rc=0x00?

      Use:
      If the Server wishes to inform the Client that thre are no matching subscribers,
      it MAY use the 0x10 (No matching subscribers)
      as an altrnative to 0x00 (Success) [MQTT-3.4.2-1].

      1986 The payload format does not match the specified Payload Format Indicator.

      Can the receiver send DISCONNECT rc 0x99 and disconnect in place of PUBACK and PUBREC rc 0x99?

      1989 The Return Code 0x00 (Success) may be sent by using a Remaining Length of 2.

      This should say:
      The Return Code 0x00 (Success) and no properies may be sent by using a Remaining Length of 2.
      Also applies to other packets.

      1997 String is a human readable string designed for diagnostics and SHOULD NOT be parsed by the receiver.

      This is not testable instead we should say:
      String is a human readable string designed for diagnostics it is not intended be parsed by the receiver.

      2006 The sender MUST NOT send this property if it would increase the size of the
      PUBACK beyond the Maximum Packet Size specified by the session partner

      This is true for all packets, EG Publish.
      Does this really mean that the sender must still send the PUBACK but without the property.
      What if the property is doing something useful?
      The sender might prefer to disconnect and sort out the small packet size.

      A better way to handle this is to allow the sender to send
      CONNACK, PUBACK, PUBREC, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT 0x??
      (Maximum Packet size too small).
      so that it can inform the publisher that it needs to send a large packet but cannot.

      2014 3.5 PUBREC - Publish received (QoS 2 delivery part 1)

      2037 If the Server is does not know if there are any matching subscribers,
      it MUST use the 0x00 (Success) Return Code

      See comment on PUBACK line 1986. If disconnected the sender MUST reconnect and resend the
      PUBLISH, which will have to succeed so that t ccan free up the PacketId.

      2037 This might indicate a mismatch in the session state between the Client and Server.

      This is a failure of this PUBACK, but might mean that the previous use of the packet id
      succeeded. We should be clear that if the sender believes that the session state is
      good, then it needs to continue the protocol and send PUBREL.

      2037 The payload format does not match the specified Payload Format Indicator

      See comment on PUBACK line 1986.

      2040 The Return Code 0x00 (Success) may be sent by using a Remaining Length of 2.

      See comment on PUBREC line 1989.

      2030 Bit 3 of the Subscription Options represent Retain As Published option.

      Should say:
      Bit 3 of the Subscription Options represents the Retain As Published option.

      3.8 SUBSCRIBE - Subscribe request

      2236 If there are no retained messages matching the Topic Filter all of these values act the same.

      Add a comma:
      If there are no retained messages matching the Topic Filter, all of these values act the same.

      2258 Add a note.
      RAP means Retain as Published.
      NL means No Local.

      2420 3.9 SUBACK - Subscribe acknowledgement

      2440 If the Remaining Length is less than 4, there is no Property Length and the value of 0 is used.

      Should be:
      If the Remaining Length is less than 3 there are no Properties.

      2453 The sender MUST NOT send this property if it would
      increase the size of the SUBACK beyond
      the Maximum Packet Size specified by the session partner [MQTT-3.9.2-2].

      A better way to handle this is to allow the sender to send DISCONNECT 0x??
      so that it can inform the subscriber that it needs to send a large packet but cannot.

      2530 3.11 UNSUBACK - Unsubscribe acknowledgement

      2550 If the Remaining Length is less than 4 there is no Property Length and the value of 0 is used.

      Should be:
      If the Remaining Length is less than 3 there are no Properties.

      2576 3.12 PINGREQ - PING request

      2583 This packet is used in Keep Alive processing. Refer to section 0 for more details.

      Replace section 0 with the correct section number.

      2597 3.13 PINGRESP - PING response

      2601 This packet is used in Keep Alive processing. Refer to section 0 for more details.

      Insert the correct section number.

        Attachments

          Activity

            People

            • Assignee:
              Andrew_Banks Andrew Banks
              Reporter:
              Andrew_Banks Andrew Banks
            • Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: