Timetravel 2024-06-29 snapshot

mqtt-sn-2.0/prose/editorial-content-timetravel/content-autobahn.md

@@ -1272,7 +1272,7 @@ exchanges using the same Packet Identifiers.
 > It is possible for a Client to send a PUBLISH packet with Packet Identifier 0x1234 and then receive a different PUBLISH packet with Packet
 > Identifier 0x1234 from its Server before it receives a PUBACK for the PUBLISH packet that it sent.
 >
-> ![](media/image8.png){width="3.5502898075240594in" height="2.7864588801399823in"}
+> ![](media/image7.png){width="3.5502898075240594in" height="2.7864588801399823in"}
 
 ## 2.3 MQTT-SN Packet Fields
 
@@ -2502,7 +2502,7 @@ The PUBWOS Flags includes the following flags:
     the definition of the various topic types. **NOTE: only predefined topic alias, short topic or full topic types are allowed in PUBWOS packets.**
 
 -   **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.27]{.underline}](#retained-messages).
+    topic is replaced or kept. For a detailed description of retained messages see [[section 4.26]{.underline}](#retained-messages).
 
 #### 3.1.10.3 Topic Data
 
@@ -2573,7 +2573,7 @@ The PUBLISH Flags includes the following flags:
     4.3]{.underline}](#quality-of-service-levels-and-protocol-flows).
 
 -   **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.27]{.underline}](#retained-messages).
+    topic is replaced or kept. For a detailed description of retained messages see [[section 4.26]{.underline}](#retained-messages).
 
 #### 3.1.11.3 Topic Data
 
@@ -3882,7 +3882,7 @@ The CONNECT packet contains flags to communicate to the gateway that Auth intera
 
 Figure 3a: Connect procedure (without Auth flag not Will flag set or no further authentication data required)
 
-![](media/image7.png){width="3.345165135608049in" height="2.963542213473316in"}
+![](media/image3.png){width="3.345165135608049in" height="2.963542213473316in"}
 
 Figure 3b: Connect procedure (with Auth flag set and additional authentication data required)
 
@@ -4604,7 +4604,7 @@ Although the implementation of the transparent Gateway is simpler when compared
 support a separate connection for each active client. Some MQTT server implementations might impose a limitation on the number of concurrent
 connections that they support.
 
-![](media/image11.png){width="3.994792213473316in" height="2.6661472003499562in"}
+![](media/image1.png){width="3.994792213473316in" height="2.6661472003499562in"}
 
 Figure XX: Transparent Gateway scenario
 
@@ -4615,21 +4615,21 @@ exchanges between a MQTT-SN client and an aggregating Gateway end at the Gateway
 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.
 
-![](media/image9.png){width="4.578125546806649in" height="3.0552755905511813in"}
+![](media/image4.png){width="4.578125546806649in" height="3.0552755905511813in"}
 
 Figure XX: Aggregating Gateway scenario
 
 ### 4.11.3 Forwarder encapsulator
 
-![](media/image4.png){width="4.704773622047244in" height="2.7964599737532807in"}
+![](media/image12.png){width="4.704773622047244in" height="2.7964599737532807in"}
 
-Figure XX: Forwarder encapsulator with TransparentGateway scenario![](media/image12.png){width="4.9003171478565175in" height="2.8304625984251968in"}
+Figure XX: Forwarder encapsulator with TransparentGateway scenario![](media/image8.png){width="4.9003171478565175in" height="2.8304625984251968in"}
 
 Figure XX: Forwarder encapsulator with Aggregating Gateway scenario
 
 ### 4.13.4 MQTT-SN broker
 
-![](media/image13.png){width="2.8596172353455818in" height="2.983947944006999in"}
+![](media/image11.png){width="2.8596172353455818in" height="2.983947944006999in"}
 
 Figure XX: MQTT-SN broker scenario
 
@@ -4721,7 +4721,7 @@ the "Sleeping clients" section.
 |                            | state.                                                                                |                              |
 +----------------------------+---------------------------------------------------------------------------------------+------------------------------+
 
-![](media/image1.png){width="6.5in" height="6.944444444444445in"}
+![](media/image9.png){width="6.5in" height="6.944444444444445in"}
 
 Figure 4: The Server View of the Client State
 
@@ -4969,7 +4969,7 @@ state by sending a CONNECT packet to the server/gateway.
 >
 > The gateway should attempt to make the best effort to reuse the same topic alias mappings that existed during any initial associated ACTIVE states.
 >
-> ![](media/image3.png){width="4.615764435695538in" height="7.453125546806649in"}
+> ![](media/image10.png){width="4.615764435695538in" height="7.453125546806649in"}
 
 Figure 5: Awake ping packet flush
 

mqtt-sn-2.0/prose/editorial-content-timetravel/content-autobahn.md.blake3.txt

@@ -1 +1 @@
-c9c1096441597530d66d48ff43c3232cd90fc007d54e9f4c5a2cc098fab29af4  content-autobahn.md
+b9336b22e33d260f820593ec9f646a6d895348279199e84c7c377d28ef91bbf4  content-autobahn.md

mqtt-sn-2.0/prose/editorial-content-timetravel/content-autobahn.md.sha256.txt

@@ -1 +1 @@
-7b02eefa082ebf5ba4507ff25d5ca24a5f1e4cba07b34cf03607744bc3b05018  content-autobahn.md
+c6adf5413137463d45b15459d038b6a1d09481b1e77483e174ee6140a2261226  content-autobahn.md