sthagen
commented
1 month ago The corresponding diff from the freshly (since 2024-JUL-24 in our snapshot process) 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-20240724T212400Z.md mqtt-sn-v2.0-wd-snapshot-20240725T200000Z.md
--- mqtt-sn-v2.0-wd-snapshot-20240724T212400Z.md 2024-07-24 23:25:13
+++ mqtt-sn-v2.0-wd-snapshot-20240725T200000Z.md 2024-07-25 22:00:21
@@ -20,18 +20,18 @@
[OASIS Message Queuing Telemetry Transport (MQTT) TC](https://www.oasis-open.org/committees/mqtt/)
**Chairs:**
-Ian Craggs ([icraggs@gmail.com](mailto:icraggs@gmail.com)), Individual member
+Ian Craggs ([icraggs@gmail.com](mailto:icraggs@gmail.com)), Individual
Simon Johnson (simon.johnson@hivemq.com), HiveMQ
**Editors:**
Andrew Banks ([Andrew\_Banks@uk.ibm.com](mailto:Andrew\_Banks@uk.ibm.com)), [IBM](http://www.ibm.com)
+Andy Stanford-Clark (andysc@uk.ibm.com), IBM
Davide Lenzarini ([davide.lenzarini@u-blox.com](mailto:davide.lenzarini@u-blox.com)), u-blox
-Ian Craggs ([icraggs@gmail.com](mailto:icraggs@gmail.com)), Individual member
+Ian Craggs ([icraggs@gmail.com](mailto:icraggs@gmail.com)), Individual
Rahul Gupta ([rahul.gupta@us.ibm.com](mailto:rahul.gupta@us.ibm.com)), [IBM](http://www.ibm.com)
Simon Johnson ([simon](mailto:simon622@gmail.com).johnson@hivemq.com), HiveMQ
-Stefan Hagen ([stefan@hagen.link](mailto:stefan@hagen.link)), Individual member
-Tara E. Walker ([tara.walker@microsoft.com](mailto:tara.walker@microsoft.com)), [Microsoft](http://www.microsoft.com)
-Andy Stanford-Clark (andysc@uk.ibm.com, IBM UK
+Stefan Hagen ([stefan@hagen.link](mailto:stefan@hagen.link)), Individual
+Tara E. Walker ([tara.walker@microsoft.com](mailto:tara.walker@microsoft.com)), [Microsoft](http://www.microsoft.com)
**Related work:**
This specification is related to:
\ No newline at end of file
@@ -404,42 +404,42 @@
[3.1.23.6 DISCONNECT Actions 62](\#3.1.23.6-disconnect-actions)
-[3.1.24 Forwarder Encapsulation 62](\#3.1.24-forwarder-encapsulation)
+[3.1.24 Forwarder Encapsulation 62](\#3.1.25-forwarder-encapsulation)
-[3.1.24.1 Length 63](\#3.1.24.1-length)
+[3.1.24.1 Length 63](\#3.1.25.1-length)
-[3.1.24.2 Packet Type 63](\#3.1.24.2-packet-type)
-
-[3.1.24.3 Ctrl 63](\#3.1.24.3-ctrl)
+[3.1.24.2 Packet Type 63](\#3.1.25.2-packet-type)
-[3.1.24.4 Radius 63](\#3.1.24.4-radius)
+[3.1.24.3 Ctrl 63](\#3.1.25.3-ctrl)
-[3.1.24.5 Wireless Node Id 63](\#3.1.24.5-wireless-node-id)
+[3.1.24.4 Radius 63](\#3.1.25.4-radius)
-[3.1.24.6 MQTT SN Packet 63](\#3.1.24.6-mqtt-sn-packet)
+[3.1.24.5 Wireless Node Id 63](\#3.1.25.5-wireless-node-id)
-[3.1.25 Protection Encapsulation 63](\#3.1.25-protection-encapsulation)
+[3.1.24.6 MQTT SN Packet 63](\#3.1.25.6-mqtt-sn-packet)
+
+[3.1.25 Protection Encapsulation 63](\#3.1.26-protection-encapsulation)
+
+[3.1.25.1 Length 65](\#3.1.26.1-length)
-[3.1.25.1 Length 65](\#3.1.25.1-length)
+[3.1.25.2 Packet Type 65](\#3.1.26.2-packet-type)
-[3.1.25.2 Packet Type 65](\#3.1.25.2-packet-type)
+[3.1.25.3 Protection Flags 65](\#3.1.26.3-protection-flags)
-[3.1.25.3 Protection Flags 65](\#3.1.25.3-protection-flags)
+[3.1.25.4 Protection Scheme 65](\#3.1.26.4-protection-scheme)
-[3.1.25.4 Protection Scheme 65](\#3.1.25.4-protection-scheme)
+[3.1.25.5 Sender Identifier 67](\#3.1.26.5-sender-identifier)
-[3.1.25.5 Sender Identifier 67](\#3.1.25.5-sender-identifier)
+[3.1.25.6 Random 67](\#3.1.26.6-random)
-[3.1.25.6 Random 67](\#3.1.25.6-random)
-
-[3.1.25.7 Crypto Material 68](\#3.1.25.7-crypto-material)
+[3.1.25.7 Crypto Material 68](\#3.1.26.7-crypto-material)
+
+[3.1.25.8 Monotonic Counter 68](\#3.1.26.8-monotonic-counter)
-[3.1.25.8 Monotonic Counter 68](\#3.1.25.8-monotonic-counter)
+[3.1.25.9 Protected MQTT-SN Packet 68](\#3.1.26.9-protected-mqtt-sn-packet)
-[3.1.25.9 Protected MQTT-SN Packet 68](\#3.1.25.9-protected-mqtt-sn-packet)
+[3.1.25.10 Authentication Tag 68](\#3.1.26.10-authentication-tag)
-[3.1.25.10 Authentication Tag 68](\#3.1.25.10-authentication-tag)
-
[4 Operational behavior 69](\#4-operational-behavior)
[4.1 Session state 69](\#4.1-session-state)
\ No newline at end of file
@@ -642,9 +642,17 @@
Multicast Address as used in this specification also includes the concept of broadcast addresses, for brevity.
+**Network Identity:**
+
+The identity used to establish that a sequence of datagrams originates from the same network source. This could be, for example:
+
+* A Network Address
+* A DTLS connection ID
+* An MQTT-SN Protection Packet sender ID
+
**Virtual Connection:**
-An MQTT-SN construct corresponding to the network connection in MQTT. It associates a Unicast Address with an MQTT-SN endpoint.
+An MQTT-SN construct corresponding to the network connection in MQTT. It associates a Network Identity with an MQTT-SN endpoint.
**Application Message:**
\ No newline at end of file
@@ -755,8 +763,12 @@
**Will Message:**
-An Application Message which is published by the Server after the Virtual Connection is closed in cases where the Virtual Connection is not closed normally. Refer to [section 3.1.4.9](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)) for information about Will Messages.
+An Application Message which is published by the Server after the Virtual Connection is deleted in cases where the Virtual Connection is not deleted normally. Refer to [section 3.1.4.9](\#3.1.4.9-connect-will-flags-(optional,-only-with-will-flag-set)) for information about Will Messages.
+**Retained Message:**
+
+An Application Message which is stored by the Server for a topic on the receipt of a Publish Packet with the retained flag set. When a Client subscribes to a topic with a Retained Message set, the Server sends the Retained Message to the Client, depending on the setting of the Retain Handling Subscribe Flags. Refer to [section 3.1.17.2](\#3.1.17.2-subscribe-flags) and [section 4.26](\#4.26-retained-messages) for more information about Retained Messages.
+
**Disallowed Unicode code point:**
The set of Unicode Control Codes and Unicode Noncharacters which should not be included in a UTF-8 Encoded String. Refer to [section 1.7.4](\#1.7.4-utf-8-encoded-string) for more information about the Disallowed Unicode code points.
\ No newline at end of file
@@ -962,7 +974,7 @@
| **PINGREQ** | 0x16 | Client to Gateway | PING request |
| **PINGRESP** | 0x17 | Gateway to Client | PING response |
| **DISCONNECT** | 0x18 | Client to Gateway or Gateway to Client | Disconnect notification |
-| **\- Reserved \-** | 0x19 | | Forbidden |
+| **WAKEUP** | 0x19 | | Wake up request |
| **\- Reserved \-** | 0x1A-0x1D | | Forbidden (Old Will Range) |
| **\- Reserved \-** | 0x1E-0xFD | | Forbidden |
| **FORWARDER ENCAPSULATION** | 0xFE | Forwarder to Client or Forwarder to Gateway | Encapsulated MQTT-SN packet |
\ No newline at end of file
@@ -1429,7 +1441,7 @@
* An I/O error or network failure detected by the Server.
* The Client fails to communicate within the Keep Alive time.
-* The Server closes the Network Connection because of a protocol error.
+* The Server deletes the Virtual Connection because of a protocol error.
If the Will Flag is set to 1, the Will Topic, and Will Payload fields MUST be present in the Packet \[MQTT-SN-3.1.4.9-3\]. The Will Message MUST be removed from the stored Session State in the Server once it has been published or the Server has received a DISCONNECT packet with a Reason Code of 0x00 (Normal disconnection) from the Client \[MQTT-SN-3.1.4.9-4\].
\ No newline at end of file
@@ -1523,7 +1535,7 @@
Table 16: CONNACK packet
-The CONNACK packet is sent by the Gateway in response to a Virtual Connection request from a client.
+The CONNACK packet is sent by the Gateway in response to a CONNECT request from a client.
#### **3.1.5.1 Length & Packet Type** {#3.1.5.1-length-&-packet-type}
\ No newline at end of file
@@ -1877,7 +1889,7 @@
For a detailed description of the various Quality Of Service levels refer to [section 4.3](\#4.3-quality-of-service-levels-and-protocol-flows).
* **DUP**: 1 bit field stored in Bit 7 and has the same meaning as with MQTT. It notes the duplicate delivery of packets. If the DUP flag is set to “0”, it signifies that the packet is sent for the first time. If the DUP flag is set to “1”, it signifies that the packet was retransmitted or retried.
-* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether the existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
+* **Retain**: 1 bit field stored in Bit 4 and has the same meaning as with MQTT. The field signifies whether an existing Retained Message for this topic is replaced or kept. For a detailed description of Retained Messages see [section 4.26](\#4.26-retained-messages).
#### **3.1.12.4 Packet Identifier** {#3.1.12.4-packet-identifier}
\ No newline at end of file
@@ -2242,10 +2254,8 @@
| Byte 3 | Packet Identifier MSB | | | | | | | |
| Byte 4 | Packet Identifier LSB | | | | | | | |
| Byte 5…N | Client Identifier (optional) | | | | | | | |
-
-Table 42: PINGREQ packet
-As with MQTT, the PINGREQ packet is an ”are you alive” packet that is sent from or received by a connected client.
+The PINGREQ packet is an ”are you alive” packet that is sent from or received by a connected client.
#### **3.1.21.1 Length & Packet Type** {#3.1.21.1-length-&-packet-type}
\ No newline at end of file
@@ -2279,9 +2289,9 @@
Table 43: PINGRESP packet
-As with MQTT, 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 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.
-Moreover, a PINGRESP packet is 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 CLient 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
@@ -2384,12 +2394,31 @@
* SHOULD delete the Virtual Connection.
-### **3.1.24 Forwarder Encapsulation** {#3.1.24-forwarder-encapsulation}
+### **3.1.24 WAKEUP \- Wake up request**
| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Byte 1 | Length | | | | | | | |
| Byte 2 | Packet Type | | | | | | | |
+
+Table ??: WAKEUP packet
+
+The wakeup packet is a signal sent from the gateway to a client. It is an indication from the gateway that the client should wake up. The client is not obliged to honor this request, nor may it even receive the packet. It can choose to ignore the request, or undertake one of the sequences outlined in the [4.25 Sleeping clients](\#4.25-sleeping-clients) section. The client need not respond to this packet.
+
+#### **3.1.24.1 Length & Packet Type**
+
+The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](https://docs.google.com/document/d/1Q\_l-TOttOqktQmnupRv7Un1Y8KzULIxc/edit?pli=1\#heading=h.23ckvvd) for a detailed description.
+
+#### **3.1.24.2 WAKEUP Actions**
+
+The Client MAY choose to follow the AWAKE procedure in response to receiving a WAKEUP packet \[MQTT-SN-3.1.21.4-2\].
+
+### **3.1.25 Forwarder Encapsulation** {#3.1.25-forwarder-encapsulation}
+
+| Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+| ----- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
+| Byte 1 | Length | | | | | | | |
+| Byte 2 | Packet Type | | | | | | | |
| Byte 3 | Ctrl | | | | | | | |
| Byte 4 .. N | Wireless Node Id | | | | | | | |
| Byte (N \+ 1 ,,, M) | MQTT SN packet | | | | | | | |
\ No newline at end of file
@@ -2398,15 +2427,15 @@
As detailed in Section 4, MQTT-SN clients can also access a gateway via a forwarder in case the gateway is not directly attached to their WSNs. The forwarder simply encapsulates the MQTT-SN Packets it receives on the wireless side and forwards them unchanged to the gateway; in the opposite direction, it decapsulates the Packets it receives from the gateway and sends them to the clients, unchanged too.
-#### **3.1.24.1 Length** {#3.1.24.1-length}
+#### **3.1.25.1 Length** {#3.1.25.1-length}
1-byte long, specifies the number of bytes up to the end of the “Wireless Node Id” field (incl. the Length byte itself)
-#### **3.1.24.2 Packet Type** {#3.1.24.2-packet-type}
+#### **3.1.25.2 Packet Type** {#3.1.25.2-packet-type}
Coded “0xFE”, see Table 6
-#### **3.1.24.3 Ctrl** {#3.1.24.3-ctrl}
+#### **3.1.25.3 Ctrl** {#3.1.25.3-ctrl}
The Ctrl byte contains control information exchanged between the GW and the forwarder.
\ No newline at end of file
@@ -2417,19 +2446,19 @@
Table 54: Format of the ctrl byte
-#### **3.1.24.4 Radius** {#3.1.24.4-radius}
+#### **3.1.25.4 Radius** {#3.1.25.4-radius}
Transmission radius (only relevant in direction gateway to forwarder)
-#### **3.1.24.5 Wireless Node Id** {#3.1.24.5-wireless-node-id}
+#### **3.1.25.5 Wireless Node Id** {#3.1.25.5-wireless-node-id}
Identifies the wireless node which has sent or should receive the encapsulated MQTT-SN packet. The mapping between this Id and the address of the wireless node is implemented by the forwarder, if needed.
-#### **3.1.24.6 MQTT SN Packet** {#3.1.24.6-mqtt-sn-packet}
+#### **3.1.25.6 MQTT SN Packet** {#3.1.25.6-mqtt-sn-packet}
The MQTT-SN packet, encoded according to the packet type.
-### **3.1.25 Protection Encapsulation** {#3.1.25-protection-encapsulation}
+### **3.1.26 Protection Encapsulation** {#3.1.26-protection-encapsulation}
###
\ No newline at end of file
@@ -2468,15 +2497,15 @@
If the GW is not enrolled to the Client (so the Client has no access to a key shared with it on the basis of its GwId) and the Client and GW are not in a private network, it is recommended for the Client to open a DTLS session and process only MQTT-SN packets received over it.
-#### **3.1.25.1 Length** {#3.1.25.1-length}
+#### **3.1.26.1 Length** {#3.1.26.1-length}
The first 2 or 4 bytes of the packet are encoded according to the variable length packet header format. Refer to [section 2.1](\#2.1-structure-of-an-mqtt-sn-control-packet) for a detailed description.
-#### **3.1.25.2 Packet Type** {#3.1.25.2-packet-type}
+#### **3.1.26.2 Packet Type** {#3.1.26.2-packet-type}
Coded “0x1E”, see Table 63
-#### **3.1.25.3 Protection Flags** {#3.1.25.3-protection-flags}
+#### **3.1.26.3 Protection Flags** {#3.1.26.3-protection-flags}
The PROTECTION Flags is 1 byte field in Byte position 3 of the packet, specifying the properties of the PROTECTION.
\ No newline at end of file
@@ -2506,7 +2535,7 @@
* if 0x1, a monotonic counter field of 16 bits (2 bytes) is present;
* if 0x0, the monotonic counter field is not present.
-#### **3.1.25.4 Protection Scheme** {#3.1.25.4-protection-scheme}
+#### **3.1.26.4 Protection Scheme** {#3.1.26.4-protection-scheme}
A (1 byte) field located at byte 4 should contain one of the not Reserved indexes in the following table. In general two types of protection scheme are considered: **Authentication only** (like HMAC or CMAC) and **AEAD** (Authenticated Encryption with Associated Data, like GCM, CCM or ChaCha20/Poly1305).
\ No newline at end of file
@@ -2544,7 +2573,7 @@
1. Reference: https://www.rfc-editor.org/rfc/rfc7539 and security considerations on https://www.rfc-editor.org/rfc/rfc8152\#section-10.3.1
1. ChaCha20/Poly1305 requires a 12 bytes nonce as indicated in https://www.rfc-editor.org/rfc/rfc8152\#section-10.3 obtained by performing SHA256 truncated to 96 bit of the sequence Byte 1 to Byte R (all packet fields until Protected MQTT-SN Packet)
-#### **3.1.25.5 Sender Identifier** {#3.1.25.5-sender-identifier}
+#### **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:
\ No newline at end of file
@@ -2569,7 +2598,7 @@
*In order to create a whitelist of authorized senders, the MQTT-SN Gateway should store a map of ClientID and SHA256(ClientID) truncated to the leftmost 64 bits (8 bytes for each registered ClientID) for the clients having an active session and store a list of authorized Sender Ids for the clients not capable to establish sessions.*
-#### **3.1.25.6 Random** {#3.1.25.6-random}
+#### **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 .
\ No newline at end of file
@@ -2577,20 +2606,20 @@
*In case of CCM, in the worst case scenario where the “Crypto Material” and the “Monotonic Counter” optional fields are not present, the recommended nonce on 13 bytes will be calculated as SHA256 truncated to 104 bits of the sequence Byte 1 to Byte 16 (all packet fields until Protected MQTT-SN Packet). So considering the same Sender Id, the same nonce can be generated with a probability of 1/2^32=2.33x10\-10. With a shorter Random field of 2 bytes, the same nonce would be calculated with a probability of only 1/2^16=1.53x10\-5. As CCM is a derivation of CTR (see [https://en.wikipedia.org/wiki/CCM\_mode](https://en.wikipedia.org/wiki/CCM\_mode)), the nonce should never be reused for the same key so the probability to generate two identical nonces should be kept as low as possible. Same for GCM and ChaCha20/Poly1305, the security depends on choosing a unique IV of 12 bytes for every encryption performed with the same key ([https://en.wikipedia.org/wiki/Galois/Counter\_Mode](https://en.wikipedia.org/wiki/Galois/Counter\_Mode)).*
-#### **3.1.25.7 Crypto Material** {#3.1.25.7-crypto-material}
+#### **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 .
-#### **3.1.25.8 Monotonic Counter** {#3.1.25.8-monotonic-counter}
+#### **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.
-#### **3.1.25.9 Protected MQTT-SN Packet** {#3.1.25.9-protected-mqtt-sn-packet}
+#### **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.
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.25.10 Authentication Tag** {#3.1.25.10-authentication-tag}
+#### **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.
\ No newline at end of file
@@ -2817,7 +2846,7 @@
There are two situations when packets that require acknowledgement are resent by the sender:
-1. when a Virtual Connection ends before the acknowledgement is received by the requester (and clean start is false)
+1. when a Virtual Connection is deleted before the acknowledgement is received by the requester (and clean start is false)
1. when no acknowledgment is received by the by the requester within a configured timeout period during the existence of a Virtual Connection
These two situations are described in the following two sections.
\ No newline at end of file
@@ -2856,9 +2885,9 @@
The Client or Gateway will start a retransmission retry timer, Tretry, when 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 delete the Virtual Connection.
+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 Gateway MUST retransmit PUBLISH Qos1, PUBLISH Qos2, PUBREL Packets, including a PROTECTION encapsulation if there is one, after Tretry has passed or delete the Virtual Connection.
+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.
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
@@ -2874,7 +2903,7 @@
The value of the retry interval Tretry is not specified by the protocol, however, to be useful it ought to be longer than the network round trip time. If it is excessively long, the time taken to detect and retransmit lost Packets will also be excessively long. Implementers need to take care not to use a retry interval that might cause the network to become congested with retried Packets.
-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.
+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)\]
\ No newline at end of file
@@ -3008,7 +3037,7 @@
* SUBSCRIBE
* UNSUBSCRIBE
-If a Client or Server receives an MQTT-SN request and there is already a request outstanding within the same Virtual Connection then it MUST issue a DISCONNECT with Reason Code 147 (Receive Maximum Exceeded) and terminate the Virtual Connection \[MQTT-SN-4.9-1\].
+If a Client or Server receives an MQTT-SN request and there is already a request outstanding within the same Virtual Connection then it MUST issue a DISCONNECT with Reason Code 147 (Receive Maximum Exceeded) and delete the Virtual Connection \[MQTT-SN-4.9-1\].
Refer to [section 3.1.12.7](\#3.1.12.7-publish-actions) for a description of how Clients and Servers react if they are sent more than one unacknowledged packet.
\ No newline at end of file
@@ -3325,7 +3354,7 @@
## **4.24 Client’s Disconnect Procedure** {#4.24-client’s-disconnect-procedure}
-A client sends a DISCONNECT packet to the gateway to indicate that it is about to delete its Virtual Connection. After this point, the client is then required to establish a new Virtual Connection with the gateway before it can exchange information with that gateway again. Like MQTT, sending the DISCONNECT packet does not affect existing subscriptions and Will data. They are persistent until they are either expired or explicitly un-subscribed, or deleted, or modified by the client, or if the client establishes a new Virtual Connection with the CleanStart flag set. The gateway acknowledges the receipt of the DISCONNECT packet by returning a DISCONNECT to the client.
+A client sends a DISCONNECT packet to the gateway to indicate that it is about to delete its Virtual Connection. After this point, the client is then required to create a new Virtual Connection with the gateway before it can exchange information with that gateway again. Like MQTT, sending the DISCONNECT packet does not affect existing subscriptions and Will data. They are persistent until they are either expired or explicitly un-subscribed, or deleted, or modified by the client, or if the client creates a new Virtual Connection with the CleanStart flag set. The gateway acknowledges the receipt of the DISCONNECT packet by returning a DISCONNECT to the client.
A client may also receive an unsolicited DISCONNECT sent by the gateway. This may happen for example when the gateway, due to an error, cannot identify the client to which a received packet belongs. Upon receiving such a DISCONNECT packet a client should try to setup the Virtual Connection again by sending a CONNECT packet to the gateway.
\ No newline at end of file
@@ -3367,9 +3396,9 @@
## **4.26 Retained Messages** {#4.26-retained-messages}
-If the RETAIN flag is set to 1 in a PUBLISH or PUBWOS packet received by a Server, the Server MUST replace any existing retained message for this topic and store the Application Message \[MQTT-SN-4.26-1\], so that it can be delivered to future subscribers whose subscriptions match its Topic Name. If the Payload contains zero bytes it is processed normally by the Server but any retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message \[MQTT-SN-4.26-2\]. A retained message with a Publish Data containing zero bytes MUST NOT be stored as a retained message on the Server \[MQTT-SN-4.26-3\].
+If the RETAIN flag is set to 1 in a PUBLISH or PUBWOS packet received by a Server, the Server MUST replace any existing Retained Message for this topic and store the Application Message \[MQTT-SN-4.26-1\], so that it can be delivered to future subscribers whose subscriptions match its Topic Name. If the Publish Data contains zero bytes it is processed normally by the Server but any retained message with the same topic name MUST be removed and any future subscribers for the topic will not receive a retained message \[MQTT-SN-4.26-2\]. A Retained Message with a Publish Data containing zero bytes MUST NOT be stored as a Retained Message on the Server \[MQTT-SN-4.26-3\].
-If the RETAIN flag is 0 in a PUBLISH packet sent by a Client to a Server, the Server MUST NOT store the message as a retained message and MUST NOT remove or replace any existing retained message \[MQTT-SN-4.26-4\].
+If the RETAIN flag is 0 in a PUBLISH packet sent by a Client to a Server, the Server MUST NOT store the message as a Retained Message and MUST NOT remove or replace any existing Retained Message \[MQTT-SN-4.26-4\].
When a new Subscription is made, the last retained message, if any, on each matching topic name is sent to the Client as directed by the Retain Handling Subscribe Flag. These messages are sent with the RETAIN flag set to 1\. Which retained messages are sent is controlled by the Retain Handling Subscribe Flag. At the time of the Subscription:
\ No newline at end of file
Next warp 2024-07-25 ← 2024-07-24