Timetravel 2024-08-07 snapshot

[sthagen]

Next warp 2024-08-06 ← 2024-08-07

[sthagen]

The corresponding diff from the freshly available download as markdown route is even more to the point (because the vendor platform has stable image identifiers and a line length limit of 512 🙈 it seems):

❯ diff -u mqtt-sn-v2.0-wd-snapshot-20240806T182800Z.md mqtt-sn-v2.0-wd-snapshot-20240807T182800Z.md
--- mqtt-sn-v2.0-wd-snapshot-20240806T182800Z.md	2024-08-06 20:30:03
+++ mqtt-sn-v2.0-wd-snapshot-20240807T182800Z.md	2024-08-07 20:28:05
@@ -1389,7 +1389,7 @@

 **Informative comment**

-The client and gateway between them should negotiate a reasonable and practical session expiry interval according to the network and infrastructure environment in which they are deployed. For example, it would not be practical to set a session – expiry – interval of many months on a gateway whose hardware is only capable of storing a few client sessions.
+The client and gateway between them should negotiate a reasonable and practical session expiry interval according to the network and infrastructure environment in which they are deployed. For example, it would not be practical to set a session expiry interval of many months on a gateway whose hardware is only capable of storing a few client sessions.

 #### **3.1.4.7 Maximum Packet Size** {#3.1.4.7-maximum-packet-size}

\ No newline at end of file
@@ -1401,7 +1401,7 @@

 The packet size is the total number of bytes in an MQTT-SN Control Packet, as defined in [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet). The Client uses the Maximum Packet Size to inform the Server that it will not process packets exceeding this limit.

- The Gateway MUST NOT send packets exceeding Maximum Packet Size to the Client. If a Client receives a packet whose size exceeds this limit, this is a Protocol Error, the Client uses DISCONNECT with Reason Code 0x95 (Packet too large).
+The Gateway MUST NOT send packets exceeding Maximum Packet Size to the Client. If a Client receives a packet whose size exceeds this limit, this is a Protocol Error, the Client uses DISCONNECT with Reason Code 0x95 (Packet too large).

 Where a Packet is too large to send, the Gateway MUST discard it without sending it and then behave as if it had completed sending that Application Message.

\ No newline at end of file
@@ -1417,7 +1417,7 @@

 A Client Identifier can be between 0 \- 65,521 bytes. We advise for practicality, ClientID’s are restricted to a reasonable size (less than 243 bytes to fit within a small CONNECT packet).

-When the CclientID is present (greater than 0 bytes), the Gateway MUST allow values which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”.
+When the ClientID is present (greater than 0 bytes), the Gateway MUST allow values which are between 1 and 23 UTF-8 encoded bytes in length, and that contain only the characters "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ”.

 The Gateway may choose to allow more than 23 bytes.

\ No newline at end of file
@@ -1433,13 +1433,13 @@

 * **Will QoS**: Stored in Bit 2 and 3, these two bits specify the QoS level to be used. The value of Will QoS can be 0 (0x00), 1 (0x01), or 2 (0x02). A value of 3 (0x03) is a Malformed Packet.

-* **Will Retain**: Stored in Bit 4, this bit specifies if the Will Message is to be retained when it is published.
+* **Will Retain**: Stored in Bit 4, this bit specifies if the Will Message is to be retained when it is published. The Will Message will be retained for a time defined by the server.

 If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session \[MQTT-SN-3.1.4.9-1\]. The Will Message consists of the Will Topic, and Will Payload fields in the CONNECT Packet. The Will Message MUST be published after the Virtual Connection is deleted or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) \[MQTT-SN--3.1.4.9-2\].

 Situations in which the Will Message is published include, but are not limited to:

-* An I/O error or network failure detected by the Server.
+* The Server deletes the Virtual Connection as a result of an I/O error or network failure it has detected.
 * The Client fails to communicate within the Keep Alive time.
 * The Server deletes the Virtual Connection because of a protocol error.

\ No newline at end of file
@@ -2199,7 +2199,7 @@

 The UNSUBSCRIBE Flags field includes the following flag:

-* **Topic Type.** This is a 2-bit field in Bit 0 and 1 which determines the format of the topic Id value. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.
+* **Topic Type.** This is a 2-bit field in Bit 0 and 1 which determines the format of the topic dataId value. Refer to [Table 10](\#2.4-topic-types) for the definition of the various topic types.

 #### **3.1.19.3 Packet Identifier** {#3.1.19.3-packet-identifier}

\ No newline at end of file
@@ -2217,7 +2217,7 @@

 * It MUST stop adding any new Application Messages which match the Topic Filters, for delivery to the Client \[MQTT-SN-3.1.19.4-2\].
 * It MUST complete the delivery of any QoS 1 or QoS 2 Application Messages which match the Topic Filters and it has started to send to the Client \[MQTT-SN-3.1.19.4-3\].
-* It MAY continue to deliver any existing Application Messages buffered for delivery to the Client.
+* It MAY continue to deliver any existing Application Messages which match the Topic Filters buffered for delivery to the Client.

 The Server MUST respond to an UNSUBSCRIBE request by sending an UNSUBACK packet \[MQTT-3.1.19.4-4\]. The UNSUBACK packet MUST have the same Packet Identifier as the UNSUBSCRIBE packet. Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK \[MQTT-3.1.19.4-5\].

\ No newline at end of file
@@ -2293,7 +2293,7 @@

 A PINGRESP packet is the response to a PINGREQ packet and means ”yes I am alive”. PINGREQ packets flow in either direction, sent either by a connected client or the gateway. it has only a header and no variable part.

-A PINGRESP packet is also sent by a Gateway to inform a sleeping CLient that it has no more buffered packets for that Client.
+A PINGRESP packet is also sent by a Gateway to inform a sleeping ClLient that it has no more buffered packets for that Client.

 #### **3.1.22.1 Length & Packet Type** {#3.1.22.1-length-&-packet-type}

\ No newline at end of file
@@ -2333,7 +2333,7 @@

 Table 45: DISCONNECT packet

-As with MQTT, the DISCONNECT packet is sent by a client to indicate that it wants to delete the Virtual connection. The gateway will acknowledge the receipt of that packet by returning a DISCONNECT to the client. A server or gateway may also send a DISCONNECT to a client, e.g. in case a gateway, due to an error, cannot map a received packet to a client. Upon receiving such a DISCONNECT packet, a client should try to create another Virtual Connection by sending a CONNECT packet to the gateway or server.
+As with MQTT, the DISCONNECT packet is sent by a client to indicate that it wants to delete the Virtual connection. The gateway will acknowledge the receipt of that packet by returning a DISCONNECT to the client. A server or gateway may also send a DISCONNECT to a client, e.g. in case a gateway, due to an error when for instance it, cannot map a received packet to thea client. Upon receiving such a DISCONNECT packet, a client should try to create another Virtual Connection by sending a CONNECT packet to the gateway or server.

 A Server MUST NOT send a DISCONNECT until after it has sent a CONNACK with Reason Code of less than 0x80 \[MQTT-SN-3.1.23-1\].

\ No newline at end of file
@@ -2365,7 +2365,7 @@

 #### **3.1.23.4 Session Expiry Interval** {#3.1.23.4-session-expiry-interval}

-The Session Expiry Interval is a four-byte integer time interval measured in seconds. If the Session Expiry Interval is set to 0 or omitted, the Session is transitioned to the “***disconnected***” state. When the value of this field is greater than zero, it is deemed to be sent by a client that wants to transition to the “***asleep***” state, see Section 3.19 for further details. At this point the keep alive timer becomes obsolete until the device issues a new CONNECT.
+The Session Expiry Interval is a four-byte integer time interval measured in seconds. If the Session Expiry Interval is set to 0 or omitted, the Session is transitioned to the “***disconnected***” state. When the value of this field is greater than zero, it is deemed to be sent by a client that wants to transition to the “***asleep***” state, see Section 4.153.19 for further details. At this point the keep alive timer becomes obsolete until the device issues a new CONNECT.

 The Session Expiry Interval MUST NOT be sent on a DISCONNECT by the Server \[MQTT–SN-3.1.23.4-1\].

\ No newline at end of file
@@ -2577,7 +2577,7 @@

 #### **3.1.26.5 Sender Identifier** {#3.1.26.5-sender-identifier}

-Located at Bytes 5 \- 12 the Sender Id field (8 bytes) should contain:
+TLocated at Bytes 5 \- 12 the Sender Id field (8 bytes) should contain:

 If the message is originated by the ***Gateway***:

\ No newline at end of file
@@ -2602,7 +2602,7 @@

 #### **3.1.26.6 Random** {#3.1.26.6-random}

-**Located at Byte 13 \- 16** , the “**Random**” field (4 bytes) should contain a random number (not guessable) generated at the PROTECTION packet creation .
+T**Located at Byte 13 \- 16 , t**he “**Random**” field (4 bytes) should contain a random number (not guessable) generated at the PROTECTION packet creation .

 * **Informative comment**

\ No newline at end of file
@@ -2610,20 +2610,20 @@

 #### **3.1.26.7 Crypto Material** {#3.1.26.7-crypto-material}

-Located at Byte (17 \- P), the optional field “**Crypto Material**” contains 0, 2, 4 or 12 bytes of crypto material that when defined it can be used to derive, from a shared master secret, the same keys on the two endpoints and/or, when filled partially or totally with a random value, to further reduce the probability of IV/nonce reuse for CCM or GCM or ChaCha20/Poly1305. For instance when the Crypto material length is set to 0x03, the Crypto Material field can be partially filled with a random value of 9 bytes (the remaining 3 bytes can be set to 0 if not used) in order to reach the 13 bytes used only once recommended for the nonce used by CCM or it can be partially filled with a random value of 8 bytes in order to reach the 12 bytes used only once recommended for the IV/nonce used by GCM or ChaCha20/Poly1305 .
+TLocated at Byte (17 \- P), the optional field “**Crypto Material**” contains 0, 2, 4 or 12 bytes of crypto material that when defined it can be used to derive, from a shared master secret, the same keys on the two endpoints and/or, when filled partially or totally with a random value, to further reduce the probability of IV/nonce reuse for CCM or GCM or ChaCha20/Poly1305. For instance when the Crypto material length is set to 0x03, the Crypto Material field can be partially filled with a random value of 9 bytes (the remaining 3 bytes can be set to 0 if not used) in order to reach the 13 bytes used only once recommended for the nonce used by CCM or it can be partially filled with a random value of 8 bytes in order to reach the 12 bytes used only once recommended for the IV/nonce used by GCM or ChaCha20/Poly1305 .

 #### **3.1.26.8 Monotonic Counter** {#3.1.26.8-monotonic-counter}

-Located at Byte Byte (Q \- R), the optional field “**Monotonic Counter**” contains 0, 2 or 4 byte number that when defined, is increased by the Client or GW for every packet sent. The counters should be considered independent of session or destination. E.g. The UE will keep a counter independently from the GW.
+TLocated at Byte Byte (Q \- R), the optional field “**Monotonic Counter**” contains 0, 2 or 4 byte number that when defined, is increased by the Client or GW for every packet sent. The counters should be considered independent of session or destination. E.g. The UE will keep a counter independently from the GW.

 #### **3.1.26.9 Protected MQTT-SN Packet** {#3.1.26.9-protected-mqtt-sn-packet}

-Located at Byte (S \- T), the field  “**Protected MQTT-SN Packet**” contains the MQTT-SN packet that is being secured, encoded as per its packet type.
+TLocated at Byte (S \- T), the field  “**Protected MQTT-SN Packet**” contains the MQTT-SN packet that is being secured, encoded as per its packet type.
 The “Protected MQTT-SN Packet” should not be a “Forwarder-Encapsulation packet” as the shared key used directly or after derivation for the protection must belong to the originator of the content and not to a Forwarder that, in general, is not able to securely identify the originator.

 #### **3.1.26.10 Authentication Tag** {#3.1.26.10-authentication-tag}

-Located at Byte (U \- N), the field “**Authentication tag**” field has a length depending on the “Authentication tag length” flag and it is calculated, on the basis of the “Protection scheme” selected in Byte 4, on ALL the preceding fields.
+TLocated at Byte (U \- N), the field “**Authentication tag**” field has a length depending on the “Authentication tag length” flag and it is calculated, on the basis of the “Protection scheme” selected in Byte 4, on ALL the preceding fields.

 # **4 Operational behavior** {#4-operational-behavior}

\ No newline at end of file
@@ -2647,7 +2647,7 @@
 * QoS 1 and QoS 2 PUBLISH Packets which have been sent to the Client, but have not been completely acknowledged.
 * QoS 1 and QoS 2 PUBLISH Packets pending transmission to the Client and OPTIONALLY QoS 0 PUBLISH Packets pending transmission to the Client.
 * QoS 2 PUBLISH Packets which have been received from the Client, but have not been completely acknowledged.
-* The Will Message and the Will Topic (Will data).
+* The Will PayloadMessage and the Will Topic (Will data).
 * If the Session is currently not connected, the time at which the Session will end and Session State will be discarded.

 Retained messages do not form part of the Session State in the Server, they are not deleted as a result of a Session ending.
\ No newline at end of file
@@ -2686,23 +2686,23 @@

 ## **4.2 Networks and Virtual Connections** {#4.2-networks-and-virtual-connections}

-The MQTT-SN protocol requires an Underlying Network to create a Virtual Connection. This carries Packets from a Client to a Gateway and a Gateway to a Client. The Underlying Network may also multicast Packets from a Client to more than one Gateway, and from a Gateway to more than one Client.
+The MQTT-SN protocol requires an Underlying Network to create a Virtual Connection. This carries Packets from a Client to a Gateway and from a Gateway to a Client. The Underlying Network may also multicast Packets from a Client to more than one Gateway, and from a Gateway to more than one Client.

-MQTT-SN Packets which are received must be unaltered and complete.
+MQTT-SN Packets which are received must be unaltered and complete and delivered only once.

 * The underlying transport does not need to be reliable, it is expected that Packets will be lost or delivered out of order.
 * If the network might deliver a Packet more than once, then it is highly recommended that the PROTECTION ENCAPSULATION Monotonic Counter is used to eliminate the duplicates.
-* The MQTT-SN protocol will tolerate out of order Packets and it will retransmit lost Packets.
+* The MQTT-SN protocol will tolerate out of order Packets and it will retransmit lost Packets (so Packets for which an expected acknowledgement has not been received).
 * There is no packet error correction in MQTT-SN. If a corrupted or partial packet is received it will cause a protocol error.
-* The MQTT-SN implementation may use either the origin network address or the sender identifier in the PROTECTION ENCAPSULATION to determine the identity of the Virtual Connection.
+* The MQTT-SN implementation may use either the origin network address, or the DTLS connection ID or the sender identifier in the PROTECTION ENCAPSULATION to determine the identity of the Virtual Connection.
 * The Underlying Network may be connectionless. Virtual Connections do not need to have an Underlying Network event that signals their creation or deletion.
 * The Underlying Network may be a radio network.

 **Informative comment**

-UDP as defined in \[RFC0768\] can be used for MQTT-SN if the Maximum Transmission Unit is configured to be more than the maximum MQTT-SN Packet size used and no Packet fragmentation occurs. Depending on the network configuration, UDP can duplicate Packets. If this can happen, the PROTECTION ENCAPSULATION monotonic counter should be used.
+UDP as defined in \[RFC0768\] can be used for MQTT-SN if the Maximum Transmission Unit is configured to be more than the maximum MQTT-SN Packet size used and no Packet fragmentation occurs. Depending on the network configuration, UDP can duplicate Packets. If this can happen, the MQTT-SN should not be usedthe PROTECTION ENCAPSULATION monotonic counter should be used.

-Examples of possible consequences of not removing duplicate Packets are:
+Examples of possible consequences of allowingnot removing duplicate Packets are:
  – DISCONNECT Packet applied to the wrong Virtual Connection
  – SUBSCRIBE and UNSUBSCRIBE Packets applied to the wrong Virtual Connection
  – PUBLISH QOS=2 published more than once
\ No newline at end of file
@@ -2736,7 +2736,7 @@

 ## **4.3 Quality of Service levels and protocol flows** {#4.3-quality-of-service-levels-and-protocol-flows}

-MQTT delivers Application Messages according to the Quality of Service (QoS) levels defined in the following sections. The delivery protocol is symmetric, in the description below the Client and Server & Gateway can each take the role of either sender or receiver. When the Gateway is delivering an Application Message to more than one Client, each Client is treated independently. The QoS level used to deliver an Application Message outbound to the Client could differ from that of the inbound Application Message.
+MQTT-SN delivers Application Messages according to the Quality of Service (QoS) levels defined in the following sections. The delivery protocol is symmetric, in the description below the Client and Server & Gateway can each take the role of either sender or receiver. When the Gateway is delivering an Application Message to more than one Client, each Client is treated independently. The QoS level used to deliver an Application Message outbound to the Client could differ from that of the inbound Application Message.

 ### **4.3.1 Publish without session: Any number of deliveries** {#4.3.1-publish-without-session:-any-number-of-deliveries}

\ No newline at end of file
@@ -2782,7 +2782,7 @@

 * MUST assign an unused Packet Identifier each time it has a new Application Message to publish \[MQTT-SN-4.3.3-1\].

-* MUST send a PUBLISH packet containing this Packet Identifier with QoS 1 and DUP flag set to 0 \[MQTT-SN-4.3.3-2\].
+* MUST send a PUBLISH packet containing this Packet Identifier with QoS 1 and DUP flag set to 0 \[MQTT-SN-4.3.3-2\]..

 * The DUP flag must be set to 0 the first time the PUBLISH QoS 1

\ No newline at end of file
@@ -2846,7 +2846,7 @@

 ## **4.4 Packet delivery retry** {#4.4-packet-delivery-retry}

-There are two situations when packets that require acknowledgement are resent by the sender:
+There are two situations when packets that require acknowledgement (CONNECT, REGISTER, PUBLISH QoS 1 and 2, SUBSCRIBE, UNSUBSCRIBE, PUBREC, PUBREL, PINGREQ, AUTH) are resent by the sender:

 1. when a Virtual Connection is deleted before the acknowledgement is received by the requester (and clean start is false)
 2. when no acknowledgment is received by the by the requester within a configured timeout period during the existence of a Virtual Connection
\ No newline at end of file
@@ -2859,7 +2859,7 @@

 If PUBACK or PUBREC is received containing a Reason Code of 0x80 or greater the corresponding PUBLISH packet is treated as acknowledged, and MUST NOT be retransmitted \[MQTT-SN-4.4-2\].

-The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver or retransmit a PUBLISH packet. The DUP flag must be set to 0 for all QoS 0 packets.  \[MQTT-SN-4.4-3\].
+The DUP flag MUST be set to 1 by the Client or Server when it attempts to re-deliver or retransmit a PUBLISH QoS 2 packet. The DUP flag must be set to 0 for all QoS 10 packets.  \[MQTT-SN-4.4-3\].

 Figure 4.3 – QoS 2 protocol flow diagram, non-normative example

\ No newline at end of file
@@ -2885,11 +2885,11 @@

 ### **4.4.1 Unacknowledged Packets** {#4.4.1-unacknowledged-packets}

-The Client or Gateway will start a retransmission retry timer, Tretry, when one of the following Packets is sent.
+The Client or Gateway will start a retransmission retry timer, Tretry, when in the following use cases.one of the following Packets is sent.

-A Client MUST retransmit AUTH, REGISTER, PUBLISH Qos1, PUBLISH Qos2, PUBREL, SUBSCRIBE, UNSUBSCRIBE Packets, including a PROTECTION encapsulation if there is one, after Tretry has passed or the Virtual Connection deleted.
+A Client MUST retransmit AUTH, REGISTER, PUBLISH Qos1, PUBLISH Qos2, PUBREL, SUBSCRIBE, PINGREQ, UNSUBSCRIBE Packets, including a PROTECTION encapsulation if there is one, after Tretry has passed or the Virtual Connection deleted.

-A Gateway MUST retransmit PUBLISH Qos1, PUBLISH Qos2, PUBREL Packets, including a PROTECTION encapsulation if there is one, after Tretry has passed or the Virtual Connection deleted.
+A Gateway MUST retransmit PUBLISH Qos1, PUBLISH Qos2, REGISTER, AUTH, PUBREL Packets, including a PROTECTION encapsulation if there is one, after Tretry has passed or the Virtual Connection deleted.

 The timer is canceled if the corresponding acknowledgement packet is received. The Client or Gateway MUST retransmit the Packet after Tretry has passed or delete the Virtual Connection.

\ No newline at end of file
@@ -2897,7 +2897,7 @@

 If a Packet is retransmitted it MUST be identical to the previously transmitted Packet, the PROTECTION encapsulation need not be identical.

-PUBLISH (used for QoS 0\) and PUBLISH WITHOUT SESSION Packets MUST NOT be retransmitted.
+PUBLISH (used for QoS 0\) and PUBLISH WITHOUT SESSION and PUBLISH QoS \-1 Packets MUST NOT be retransmitted.

 If the Virtual Connection is deleted, the protocol will restart when a new CONNECT packet flows from the Client.

\ No newline at end of file
@@ -2907,7 +2907,7 @@

 The PINGREQ Packet described in \[[3.1.21 PINGREQ](\#3.1.21-pingreq---ping-request)\] can also be used to determine whether the Virtual Connection is alive.

-An example of a retry algorithm is described in \[[Appendix E.F4](\#f.4-exponential-backoff)\]
+An example of a retry algorithm is described in \[[Appendix F.4Appendix E.F4](\#f.4-exponential-backoff)\]

 ## **4.5 Application Message receipt** {#4.5-application-message-receipt}

\ No newline at end of file```