Timetravel 2024-08-08 snapshot

[sthagen]

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

[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-${pts}.md" "mqtt-sn-v2.0-wd-snapshot-${tts}.md"

--- mqtt-sn-v2.0-wd-snapshot-20240807T182800Z.md    2024-08-07 20:28:05
+++ mqtt-sn-v2.0-wd-snapshot-20240808T201000Z.md    2024-08-08 22:11:00
@@ -1362,7 +1362,7 @@

 The Client can send PINGREQ at any time, irrespective of the Keep Alive value, and check for a corresponding PINGRESP to determine that the network and the Gateway are available.

-If the Gateway does not receive an MQTT-SN Control Packet from the Client within one and a half times the Keep Alive time period, it MUST consider the session ‘LOST’ (see state description in table 3.6).
+If the Gateway does not receive an MQTT-SN Control Packet from the Client within one and a half times the Keep Alive time period, it MUST consider the Client session ‘LOST’ (see state description in table 3.6).

 If a Client does not receive a PINGRESP packet within a *Tretry* amount of time after it has sent a PINGREQ, it SHOULD retry the transmission according to [section 4.24](\#4.4.1-unacknowledged-packets) up to the maximum number of attempts. If a PINGRESP is still not received it MUST close the Session to the Gateway by way of a DISCONNECT, with the understanding that the GW may no longer be reachable.

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

 #### **3.1.11.3 Topic Data** {#3.1.11.3-topic-data}

-Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or normal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
+Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.

 #### **3.1.11.4 Data** {#3.1.11.4-data}

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

 #### **3.1.12.5 Topic Data** {#3.1.12.5-topic-data}

-Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or normal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.
+Contains 2 bytes of topic length (if the topic type is Full Topic Name) or the topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic which this payload will be published to.

 #### **3.1.12.6 Data** {#3.1.12.6-data}

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

 #### **3.1.17.4 Topic Data or Topic Filter** {#3.1.17.4-topic-data-or-topic-filter}

-Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or normal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.
+Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.

 #### **3.1.17.5 SUBSCRIBE Actions** {#3.1.17.5-subscribe-actions}

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

 #### **3.1.19.4 Topic Data or Topic Filter** {#3.1.19.4-topic-data-or-topic-filter}

-Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or normal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.
+Contains Fixed Length UTF-8 Encoded String topic filter, topic alias (predefined or session topic aliasnormal), or short topic name as indicated in the *Topic Type* field in flags. Determines the topic names which this subscription is interested in.

 #### **3.1.19.4 UNSUBSCRIBE Actions** {#3.1.19.4-unsubscribe-actions}

\ No newline at end of file
@@ -2638,7 +2638,8 @@
 The Session State in the Client consists of:

 * QoS 1 and QoS 2 PUBLISH Packets which have been sent to the Server, but have not been completely acknowledged.
-* QoS 2 PUBLISH Packets which have been received from the Server, but have not been completely acknowledged.
+* QoS 2 PUBLISH Packets which have been received from the Server, but have not been completely acknowledged.
+* Session topic alias mapping

 The Session State in the Server consists of:

\ No newline at end of file
@@ -2648,7 +2649,8 @@
 * 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 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.
+* If the Session is currently not connected, the time at which the Session will end and Session State will be discarded.
+* Session topic alias mapping

 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
@@ -3024,9 +3026,9 @@

 ## **4.8 Subscriptions** {#4.8-subscriptions}

-A Subscription is associated only with the Session that created it. Each Subscription includes a Topic Filter, indicating the topic(s) for which messages are to be delivered on that Session, and Subscription Options. The Server is responsible for collecting messages that match the filter and transmitting them on the Session's Virtual Connection if and when that Virtual Connection exists.
+A Subscription is associated only with the Session that created it. Each Subscription includes a Topic Data or a Topic Filter, indicating the topic(s) for which messages are to be delivered on that Session, and Subscription Options. The Server is responsible for collecting messages that match the subscription filter and transmitting them on the Session's Virtual Connection if and when that Virtual Connection exists.

-A Session cannot have more than one Subscription with the same Topic Filter, so the Topic Filter can be used as a key to identify the subscription within that Session.
+A Session cannot have more than one Subscription with the same Topic Data or Topic Filter, so the Topic Data or Topic Filter can be used as a key to identify the subscription within that Session.

 If there are multiple Clients, each with its own Subscription to the same Topic, each Client gets its own copy of the Application Messages that are published on that Topic. This means that the Subscriptions cannot be used to load-balance Application Messages across multiple consuming Clients as in such cases every message is delivered to every subscribing Client.

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

 The Authentication Method is commonly a SASL mechanism, and using such a registered name aids interchange. However, the Authentication Method is not constrained to using registered SASL mechanisms.

-If the Authentication Method selected by the Client specifies that the Client sends data first, the Client SHOULD include an Authentication Data property in the CONNECT packet. This property can be used to provide data as specified by the Authentication Method. The contents of the Authentication Data are defined by the authentication method.
+If the Authentication Method selected by the Client specifies that the Client sends data first, the Client SHOULD include the an Authentication Data property in the CONNECT packet. This property can be used to provide data as specified by the Authentication Method. The contents of the Authentication Data are defined by the authentication method.

-If the Server requires additional information to complete the authentication, it can send an AUTH packet to the Client. This packet MUST contain a Reason Code of 0x18 (Continue authentication)  \[MQTT-SN-4.10-2\]. If the authentication method requires the Server to send authentication data to the Client, it is sent in the Authentication Data.
+If the Server requires additional information to complete the authentication, it can send an AUTH packet to the Client. This packet MUST contain a Reason Code of 0x18 (Continue authentication)  \[MQTT-SN-4.10-2\]. If the authentication method requires the Server to send authentication data to the Client, it is sent in the Authentication Data field of the AUTH packet.

-The Client responds to an AUTH packet from the Server by sending a further AUTH packet. This packet MUST contain a Reason Code of 0x18 (Continue authentication)  \[MQTT-SN-4.10-3\]. If the authentication method requires the Client to send authentication data for the Server, it is sent in the Authentication Data.
+The Client responds to an AUTH packet from the Server by sending a further AUTH packet. This packet MUST contain a Reason Code of 0x18 (Continue authentication)  \[MQTT-SN-4.10-3\]. If the authentication method requires the Client to send authentication data for the Server, it is sent in the Authentication Data field of the AUTH packet.

-The Client and Server exchange AUTH packets as needed until the Server accepts the authentication by sending a CONNACK with a Reason Code of 0\. If the acceptance of the authentication requires data to be sent to the Client, it is sent in the Authentication Data.
+The Client and Server exchange AUTH packets as needed until the Server accepts the authentication by sending a CONNACK with a Reason Code of 0\. If the acceptance of the authentication requires data to be sent to the Client, it is sent in the Authentication Data field of the CONNACK packet.

 The Client can terminate the Virtual Connection at any point in this process by sending a DISCONNECT packet. The Server can reject the authentication at any point in this process. It MUST send a CONNACK with a Reason Code of 0x80 or above as described in [section 4.13](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html\#S4\_13\_Errors), \[MQTT-SN-4.10-4\].

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

 The implementation of enhanced authentication is OPTIONAL for both Clients and Servers. If the Client does not include an Authentication Method in the CONNECT, the Server MUST NOT send an AUTH packet, and it MUST NOT send an Authentication Method in the CONNACK packet \[MQTT-SN-4.10-6\]. If the Client does not include an Authentication Method in the CONNECT, the Client MUST NOT send an AUTH packet to the Server \[MQTT-SN-4.10-7\].

-If the Client does not include an Authentication Method in the CONNECT packet, the Server SHOULD authenticate using some or all of the information in the CONNECT packet in conjunction with the underlying transport layer..
+If the Client does not include an Authentication Method in the CONNECT packet, the Server SHOULD authenticate using some or all of the information in the CONNECT packet in conjunction with the underlying transport layer or in alternative use the Protection Encapsulation packet..

 **Informative example showing a SCRAM challenge**

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

 ### **4.11.1 Re-authentication** {#4.11.1-re-authentication}

-If the Client supplied an Authentication Method in the CONNECT packet it can initiate a re-authentication at any time after receiving a CONNACK. It does this by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication). The Client MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Virtual Connection \[MQTT-SN-4.10.1-1\]. If the authentication method requires Client data first, this AUTH packet contains the first piece of authentication data as the Authentication Data.
+If the Client supplied an Authentication Method in the CONNECT packet, it can initiate a re-authentication at any time after receiving a CONNACK. It does this by sending an AUTH packet with a Reason Code of 0x19 (Re-authentication). The Client MUST set the Authentication Method to the same value as the Authentication Method originally used to authenticate the Virtual Connection \[MQTT-SN-4.10.1-1\]. If the authentication method requires Client data first, this AUTH packet contains the first piece of authentication data inas  the Authentication Data field.

 The Server responds to this re-authentication request by sending an AUTH packet to the Client with a Reason Code of 0x00 (Success) to indicate that the re-authentication is complete, or a Reason Code of 0x18 (Continue authentication) to indicate that more authentication data is needed. The Client can respond with additional authentication data by sending an AUTH packet with a Reason Code of 0x18 (Continue authentication). This flow continues as with the original authentication until the re-authentication is complete or the re-authentication fails.

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

 ## **4.13 Example MQTT-SN Architectures** {#4.13-example-mqtt-sn-architectures}

-There are three kinds of MQTT-SN components, MQTT-SN *clients*, MQTT-SN *gateways*, and MQTT-SN *forwarders*. MQTT-SN clients connect themselves to an MQTT server/broker via an MQTT-SN Gateway using the MQTT-SN protocol. An MQTT-SN Gateway may or may not be integrated with a MQTT server. Where an MQTT broker is involved, the MQTT protocol is used between the MQTT broker and the MQTT-SN Gateway. Its main function is the translation between MQTT and MQTT-SN.
+There are three kinds of MQTT-SN components, MQTT-SN *clients*, MQTT-SN *gateways*, and MQTT-SN *forwarders*. MQTT-SN clients connect themselves to an MQTT-SN Gateway or to an MQTT server/broker via an MQTT-SN Gateway using the MQTT-SN protocol. An MQTT-SN Gateway may or may not be integrated with a MQTT server. Where an MQTT broker is involved, the MQTT protocol is used between the MQTT broker and the MQTT-SN Gateway. Its main function is the translation between MQTT and MQTT-SN.

 MQTT-SN clients can also access a Gateway via a forwarder in case the Gateway is not directly attached to their network. The forwarder simply encapsulates the MQTT-SN frames it receives on the wireless side and forwards them unchanged to the Gateway; in the opposite direction, it decapsulates the frames it receives from the gateway and sends them to the clients, unchanged too.

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

 ### **4.13.2 Aggregating Gateway** {#4.13.2-aggregating-gateway}

-Instead of having a MQTT connection for each connected client, an aggregating Gateway will have only one MQTT connection to the Server. All packet exchanges between a MQTT-SN client and an aggregating Gateway end at the Gateway. The Gateway then decides which information will be given further to the Server. Although its implementation is more complex than the one of a transparent Gateway, an aggregating Gateway may be helpful in case of WSNs with a very large number of SAs because it reduces the number of MQTT connections that the Gateway must support concurrently.
+Instead of having a MQTT connection for each connected client, an aggregating Gateway will have only one MQTT connection to the Server. All packet exchanges between a MQTT-SN client and an aggregating Gateway end at the Gateway. The Gateway then decides which information will be given further to the MQTT BrokerServer. Although its implementation is more complex than the one of a transparent Gateway, an aggregating Gateway may be helpful in case of WSNs with a very large number of SAs because it reduces the number of MQTT connections that the Gateway must support concurrently.

 ![][image7]

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

 A Gateway may announce its presence by periodically sending an ADVERTISE packet to some or all devices that are currently parts of the network. A gateway should only advertise its presence if it is connected to a server, or is itself a server.

-Multiple Gateways may be active at the same time in the same network. In this case they will have different identifiers. It is up to the Client to decide to which Gateway it wants to connect. At any point in time a Client is allowed to be connected to only one Gateway on the same network.
+Multiple Gateways may be active at the same time in the same network. In this case they will have different identifiers. It is up to the Client to decide to which Gateway it wants to connect. At any point in time a Client is allowed to have a Virtual Connectionbe connected to only one Gateway on the same network.

 A client should maintain a list of active gateways together with their network addresses. This list is populated by means of the ADVERTISE and GWINFO packets received.

\ No newline at end of file
@@ -3227,19 +3229,19 @@

 ## **4.15 Client states** {#4.15-client-states}

-At any given point in time, a client may be in one of **5 different states**. Transition through these states is governed by a strictly coordinated sequence of packets between client and server/gateway and further mediated by timers resident on the gateway. A client is in the *active* state when the server/gateway receives a CONNECT packet from that client. This state is supervised by the server/gateway with the “keep alive” timer. If the server/gateway does not receive any packet from the client for a period longer than the keep alive duration (indicated in the CONNECT packet), the gateway will consider that client as *lost* and activate for example the Will feature for that client. A client goes to the *disconnected* state when the server/gateway receives a DISCONNECT without a *session expiry interval* field. This state is not time-supervised by the server/gateway. A client moves into the asleep state by issuing a DISCONNECT with a *session expiry interval* field. For more information on the sleep state, please refer to the “Sleeping clients” section.
+At any given point in time, a client may be in one of **5 different states** from the perspective of the gateway. Transition through these states is governed by a strictly coordinated sequence of packets between client and server/gateway and further mediated by timers resident on the gateway. A client is in the *active* state when the server/gateway receives a CONNECT packet from that client. This state is supervised by the server/gateway with the “keep alive” timer. If the server/gateway does not receive any packet from the client for a period longer than the keep alive duration (indicated in the CONNECT packet), the gateway will consider that client as *lost* and activate for example the Will feature for that client. A client goes to the *disconnected* state when the server/gateway receives a DISCONNECT without a *session expiry interval* field. This state is not time-supervised by the server/gateway. A client moves into the asleep state by issuing a DISCONNECT with a *session expiry interval* field. For more information on the sleep state, please refer to the “Sleeping clients” section.

 | State | State Description | Possible Transitions |
 | ----- | ----- | ----- |
 | **DISCONNECTED** | The client is considered offline. The gateway may or may not have a previous session state for this client. From here a client may transition ONLY to the **ACTIVE** state. | **ACTIVE** |
-| **ACTIVE** | The client is actively engaged in the session. It should be able to send and receive packets. Its state is supervised by the gateway with the associated “keep alive” timers. From here the client may transition to **ASLEEP** (by way of DISCONNECT with a session expiry interval \> 0), **DISCONNECTED** (by way of DISCONNECT with a session expiry of 0\) or **LOST** (by way of supervised gateway timers). | **ASLEEP DISCONNECTED LOST** |
+| **ACTIVE** | The client is actively engaged in the session. It should be able to send and receive packets. Its state is supervised by the gateway with the associated “keep alive” timers. From here the client may transition to **ASLEEP** (by way of DISCONNECT with a session expiry interval \> 0), **DISCONNECTED** (by way of DISCONNECT with a session expiry of 0\) or **LOST** (by way of supervised “keep alive” gateway timers). | **ASLEEP DISCONNECTED LOST** |
 | **ASLEEP** | The client is engaged in an ongoing session. It cannot receive packets; it can send packets. The gateway should not expect a response from the client in this state until further packets are received from the client. From here the client may transition to **AWAKE** (by way of PINGREQ), **ACTIVE** by way of CONNECT, **DISCONNECTED** (by way of DISCONNECT with a session expiry of 0\) or **LOST** (by way of supervised gateway timers). | **AWAKE ACTIVE DISCONNECTED LOST** |
-| **AWAKE** | The client is partially engaged in an ongoing session; it is obliged to not send ANY packets other than those involved in the receipt of PUBLISH packets (PUBACK, PUBREC, PUBCOMP, REGACK) or a DISCONNECT to transition to **DISCONNECTED**. The client transitions back to the **ASLEEP** state on receipt of a PINGRESP packet or **LOST** (by way of supervised gateway timers). | **ASLEEP DISCONNECTED LOST** |
-| **LOST** | The client is considered offline and not able to receive packets until it has re-established a session with the GW by way of a CONNECT. The gateway **must not** attempt to send packets to a client in the **LOST** state**.** Any packets received from a client whose state is **LOST** should not be processed and a DISCONNECT with error should be sent in response, unless the packets received are PUBLISH WITHOUT SESSION or PUBLISH \-1. Session state may exist on the GW for a client in the **LOST** state. | **ACTIVE** |
+| **AWAKE** | The client is partially engaged in an ongoing session; it is obliged to not send ANY packets other than those involved in the receipt of PUBLISH packets (PUBACK, PUBREC, PUBCOMP, REGACK) or a DISCONNECT to transition to **DISCONNECTED**. The client transitions back to the **ASLEEP** state on receipt of a PINGRESP packet or **LOST** (by way of supervised gateway timers for the possible PUBACK, PUBREC, PUBCOMP or REGACK packets to be received from the Client). | **ASLEEP DISCONNECTED LOST** |
+| **LOST** | The client is considered offline and not able to receive packets until it has re-established a session with the GW by way of a CONNECT. The gateway **must not** attempt to send packets to a client in the **LOST** state**.** Any packets received from a client whose state is **LOST** should not be processed and a DISCONNECT with error should be sent in response, unless the packets received are PUBLISH WITHOUT SESSION or PUBLISH QoS \-1. Session state may exist on the GW for a client in the **LOST** state. | **ACTIVE** |

 ![][image11]

-Figure 4:  The Server View of the Client State
+Figure 4:  The Server vView of the Client State

 ### **4.15.1 Gateway timers** {#4.15.1-gateway-timers}

\ No newline at end of file
@@ -3248,19 +3250,21 @@
 * “Keep Alive” timer based on the value defined in the CONNECT packet. If expired, a Client is moved from Active to Lost state or from Asleep to Lost state or from Awake to Lost state.
 * “Session Expiry” timer based on the value defined in the CONNECT or the DISCONNECT packet. If expired, the session state associated with the Client can be removed.

+* Retransmission timers for the packets not yet acknowledged.
+
 ## **4.16 Clean start** {#4.16-clean-start}

-When a client disconnects, its subscriptions are retained for no less than the session expiration interval. They are persistent and valid for new (non clean start) sessions, until either they are explicitly un-subscribed by the client, or the client establishes a new session with the “clean start” flag set or their idle time exceeds the session expiry interval associated with the session.
+When a client disconnects, its session state subscriptions areis retained for no less than the session expiration interval. The session state isThey are persistent and valid for new (non clean start) sessions, until either they are explicitly un-subscribed by the client, or the client establishes a new session with the “clean start” flag set or the their idle time exceeds the session expiry interval associated with the session.

 The two flags “CleanStart” and “Will” in the CONNECT Packet have the following meanings:

-* CleanStart=true, Will=true: The Gateway will delete all Session data related to the client, including Will data if present, and it will set the Will data in the Session state with the content of the CONNECT Will fields and will return CONNACK.
+* CleanStart=true, Will=true: The Gateway will delete all sSession state data related to the client, including Will data if present, and it will set the Will data in the Session state with the content of the CONNECT Will fields and will return CONNACK.

-* CleanStart=true, Will=false: The gateway will delete all subscriptions and Will data, if present, related to the client and it will return CONNACK.
+* CleanStart=true, Will=false: The gateway will delete all session state data subscriptions and Will data, if present, related to the client and it will return CONNACK.

-* CleanStart=false, Will=true: The gateway will keep all the client’s data and it will overwrite, if present, or add the Will data related to the client with the content of the CONNECT Will optional fields and it will return CONNACK.
+* CleanStart=false, Will=true: The gateway will keep all the client’s session state data and it will overwrite, if present, or add the Will data related to the client with the content of the CONNECT Will optional fields and it will return CONNACK.

-* CleanStart=false, Will=false: The Gateway will keep all the client’s subscriptions and it will delete any Will data, if present, and it will return CONNACK.
+* CleanStart=false, Will=false: The Gateway will keep all the client’s session state datasubscriptions and it will delete any Will data, if present, and it will return CONNACK.

 Note that if a client wants to delete only its Will data at Virtual Connection creation, it could send a CONNECT packet with “CleanStart=false” and “Will=false”.

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

 To register a topic name a client sends a REGISTER packet to the Server. If the registration could be accepted, the gateway assigns a *topic alias* to the received topic name and returns it with a REGACK packet to the client.

-If the client initiates a REGISTER against a topic which is known by the Server to have a predefined topic alias associated with it, it is an error case, but one which should not be terminal to the session since gateway updates could lead to this scenario. The gateway will specify its topic alias type to be predefined and set the topic alias value to match that defined on the gateway in the REGACK, it will also set a reason code on the REGACK to indicate the issue. The client can then choose to update its registry of predefined topic aliases if it so wishes.
+If the client initiates a REGISTER against a topic which is known by the Server to have a predefined topic alias associated with it, it is an error case, but one which should not be terminal to the session since gateway updates could lead to this scenario. The gateway will specify in the REGACK its topic alias type to be predefined and set the topic alias value to match that predefined on the gateway in the REGACK, it will also set a reason code on the REGACK to indicate the issue. The client can then choose to update its registry of predefined topic aliases if it so wishes.

-If a Client sends a PUBLISH to a predefined topic alias, which is not defined on the Server, this is considered a protocol violation.  \[MQTT-SN-???\]
+If a Client sends a PUBLISH to a predefined topic alias, which is not defined on the Server, this is considered a protocol errorviolation.  \[MQTT-SN-???\]

-If there are no predefined topic aliases, the gateway will pass back a SESSION topic alias type. If the registration can not be accepted, a REGACK is also returned to the client with the failure reason encoded in the *ReasonCode* field.
+If there are no predefined topic aliases, the gateway will pass back a Session SESSION topic alias type. If the registration can not be accepted, a REGACK is also returned to the client with the failure reason encoded in the *ReasonCode* field.

-After having received the REGACK packet with *ReasonCode \=“accepted”*, the client shall use the assigned *topicId* to publish data of the corresponding topic name. If, however, the REGACK contains a rejection code, the client may try to register later again. If the Reason Code was *“Congestion”*, the client should wait for a time *TWAIT* before restarting the registration procedure.
+After having received the REGACK packet with *ReasonCode \=“accepted”*, the client shall use the assigned *topic aliasId* to publish data of the corresponding topic name. If, however, the REGACK contains a rejection code, the client may try to register later again. If the Reason Code was *“Congestion”*, the client should wait for a time *TWAIT* before restarting the registration procedure.

 At any point in time a client may have only one REGISTER packet outstanding, i.e., it must wait for a REGACK packet before it can register another topic name.

\ No newline at end of file
@@ -3290,23 +3294,23 @@

 ## **4.18 Topic Mapping and Aliasing** {#4.18-topic-mapping-and-aliasing}

-On the gateway the mapping table between registered topic ids and topic names MUST be implemented per client (and not by a single shared pool between all clients), to reduce the risk of an incorrect topic id from a client matching another client’s valid topic.
+On the gateway the mapping table between registered session topic alias ids and topic names MUST be implemented per client (and not by a single shared pool between all clients), to reduce the risk of an incorrect topic alias id from a client matching another client’s valid topic.

-For performance and efficiency reasons the broker may choose to align topic aliases for registered normal topic aliases between multiple clients. The mapping table of predefined topic aliases is separate from normal registered aliases. It is global and shared between all clients and gateways and may overlap with registered aliases, since it is in a different pool.
+For performance and efficiency reasons the broker may choose to align topic aliases for registered session normal topic aliases between multiple clients. The mapping table of predefined topic aliases is separate from session normal registered aliases. It is global and shared between all clients and gateways and may overlap with session registered aliases, since it is in a different pool.

 ## **4.19 Predefined topic aliases and short topic names** {#4.19-predefined-topic-aliases-and-short-topic-names}

-A “predefined” topic alias is a topic alias whose mapping to a topic name is known in advance by both the client’ application and the gateway. This is indicated in the *Flags* field of the packet. When using pre-defined topic aliases, both sides can start immediately with the sending of PUBLISH packets; there is no need for the REGISTER procedure as in the case of ”normal” topic aliases. When receiving a PUBLISH packet with a predefined topic alias, of which the mapping to a topic name is unknown, the receiver should return a PUBACK with the *ReasonCode= “*Unknown Topic Alias*”*.
+A “predefined” topic alias is a topic alias whose mapping to a topic name is known in advance by both the client’ application and the gateway. This is indicated in the *Flags* field of the packet. When using pre-defined topic aliases, both sides can start immediately with the sending of PUBLISH packets; there is no need for the REGISTER procedure as in the case of Session”normal” topic aliases. When receiving a PUBLISH packet with a predefined topic alias, of which the mapping to a topic name is unknown, the receiver should return a PUBACK with the *ReasonCode= “*Unknown Topic Alias*”*.

 The presence of a pre-defined topic alias does not imply any other meaning onto the topic name / topic filter itself. All lifecycle operations, for example SUBSCRIBE / UNSUBSCRIBE may still be used in the use of these aliases except for REGISTER.

-A “short” topic name is a topic name that has a fixed length of two bytes. It could be carried together with the data within a PUBLISH packet, thus no REGISTER procedure is needed for a short topic name. Otherwise, all rules that apply to normal topic names also apply to short topic names. Note however that it does not make sense to do wildcarding in subscriptions to short topic names, because it is not possible to define a meaningful name hierarchy with only two characters.
+A “short” topic name is a topic name that has a fixed length of two bytes. It could be carried together with the data within a PUBLISH packet, thus no REGISTER procedure is needed for a short topic name. Otherwise, all rules that apply to session normal topic names also apply to short topic names. Note however that it does not make sense to do wildcarding in subscriptions to short topic names, because it is not possible to define a meaningful name hierarchy with only two characters.

 ## **4.20 Client’s Topic Subscribe/Unsubscribe Procedure** {#4.20-client’s-topic-subscribe/unsubscribe-procedure}

 To subscribe to a topic name, a client sends a SUBSCRIBE packet to the gateway with the topic name included in that packet. If the gateway is able accept the subscription, it assigns a topic alias to the received topic name and returns it within a SUBACK packet to the client. If the subscription cannot be accepted, then a SUBACK packet is also returned to the client with the rejection cause encoded in the *ReasonCode* field. If the rejection cause is *“Congestion”*, the client should wait for the time *TWAIT* before resending the SUBSCRIBE packet to the gateway.

-If the client subscribes to a topic name which contains a wildcard character, the returning SUBACK packet will contain the topic alias value 0x0000. The gateway will use the registration procedure to inform the client about the to-be-used topic alias value when it has the first PUBLISH packet with a matching topic name to be sent to the client.
+If the client subscribes to a topic name which contains a wildcard character, the returning SUBACK packet will contain the topic data alias value 0x0000. The gateway will use the registration procedure to inform the client about the to-be-used topic alias value when it has the first PUBLISH packet with a matching topic name to be sent to the client.

 Similar to the client’s PUBLISH procedure, topic aliases may also be pre-defined for certain topic names. Short topic names may be used as well. In those two cases the client still needs to subscribe to those pre-defined topic aliases or short topic names.

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

 * The *ReasonCode= “Congestion”*: in this the client shall stop publishing toward the gateway for at least the time *TWAIT*.

-A Client or Gateway processes a single outbound QoS 1 or QoS 2 message at a time.
+A Client or Gateway processes a single outbound QoS 1 or QoS 2 message at a time but it is possible to publish QoS 0 or PUBWOS or PUBLISH QoS \-1 packets in the middle of a QoS 1 or QoS 2 exchange. packets in the midlle of a QoS 1 or QoS 2 exchange.

 This prevents retransmitted Qos 1 and Qos 2 messages from being received out of order.

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

 Like the client publish procedure described in [Section 4.21](\#4.21-client-publish-procedure), the gateway sends PUBLISH packets with the topic alias value that was returned in the SUBACK packet to the client.

-Preceding the PUBLISH packet the gateway may send a REGISTER packet to inform the client about the topic name and its assigned topic alias value. This will happen for example when the client re-connects without clean start or has subscribed to topic names with wildcard characters. Upon receiving a REGISTER packet the client replies with a REGACK packet. The gateway will wait for the REGACK packet before it sends the PUBLISH packet to the client.
+Preceding the PUBLISH packet the gateway may send a REGISTER packet to inform the client about the topic name and its assigned topic alias value. This will happen for example when the client re-connects without a clean start or has subscribed to topic names with wildcard characters. Upon receiving a REGISTER packet the client replies with a REGACK packet. The gateway will wait for the REGACK packet before it sends the PUBLISH packet to the client.

 The client could reject the REGISTER packet with a REGACK packet indicating the rejection reason; this corresponds to an unsubscribe to the topic name indicated in the REGISTER packet. Note that unsubscribe to a topic name with wildcard characters can only be done with the unsubscribe procedure and not with the rejection of a REGISTER packet, since a REGISTER packet never contains a topic name with wildcard characters.

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

 ## **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 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 set to 1 in a PUBLISH or PUBWOS or PUBLISH QoS-1 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\].

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

 ## **4.27 Optional Features** {#4.27-optional-features}

-Support for the ADVERTISE, SEARCHGW, GWINFO and PUBWOS packet types is optional.
+Support for the ADVERTISE, SEARCHGW, GWINFO, PUBLISH QoS \-1 and PUBWOS packet types is optional.

 The Forwarder Encapsulation packet type support is optional. For instance, it is not required if the MQTT-SN Clients are able to directly reach a MQTT-SN Gateway.

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

 #### **B.1.3 Topic Id** {#b.1.3-topic-id}

-Contains the topic id value or the short topic name for which the data is published.
+Contains the topic aliasid value or the short topic name for which the data is published.

 #### **B.1.4 Data** {#b.1.4-data}

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

 The MQTT SN protocol is optimized for implementation on low-cost, battery-powered devices with limited processing and storage resources. The capabilities are kept simple and the specification allows for partial implementations. Device identities are typically created at manufacturing, eliminating the need for special configuration at deployment. MQTT-SN can work in isolation from other networks or in conjunction with MQTT.

-MQTT-SN Client and Gateway/Server implementations SHOULD offer Authentication and Authorization options. Furthermore, the confidentiality and authenticity of the MQTT-SN messages can be provided by the underlying transport or can be obtained by encapsulating the MQTT-SN messages into the PROTECTION packet.
+MQTT-SN Client and Gateway/Server implementations SHOULD offer Authentication and Authorization options. Furthermore, the confidentiality and authenticity of the MQTT-SN messages can be provided by the underlying transport or can be obtained by encapsulating the MQTT-SN messages into the ProtectionROTECTION Encapsulation packet.

 Applications concerned with critical infrastructure, personally identifiable information, or other personal or sensitive information are strongly advised to use these security capabilities.

\ No newline at end of file