From 12f9d8bc2ad4b4bbe9b805411f37f93f47635cb6 Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Sun, 20 Oct 2024 12:29:40 +0000
Subject: [PATCH] Script updating gh-pages from 5462ab0. [ci skip]

---
 draft-ietf-core-coap-pubsub.html        |  463 ++--
 draft-ietf-core-coap-pubsub.txt         |  930 +++++---
 index.html                              |    8 -
 ps-rev/draft-ietf-core-coap-pubsub.html | 2803 -----------------------
 ps-rev/draft-ietf-core-coap-pubsub.txt  | 1848 ---------------
 ps-rev/index.html                       |   45 -
 6 files changed, 822 insertions(+), 5275 deletions(-)
 delete mode 100644 ps-rev/draft-ietf-core-coap-pubsub.html
 delete mode 100644 ps-rev/draft-ietf-core-coap-pubsub.txt
 delete mode 100644 ps-rev/index.html

diff --git a/draft-ietf-core-coap-pubsub.html b/draft-ietf-core-coap-pubsub.html
index 510e41d..f765e22 100644
--- a/draft-ietf-core-coap-pubsub.html
+++ b/draft-ietf-core-coap-pubsub.html
@@ -11,22 +11,21 @@
 <meta content="
        This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. 
     " name="description">
-<meta content="xml2rfc 3.21.0" name="generator">
+<meta content="xml2rfc 3.23.2" name="generator">
 <meta content="draft-ietf-core-coap-pubsub-latest" name="ietf.draft">
 <!-- Generator version information:
-  xml2rfc 3.21.0
-    Python 3.11.9
+  xml2rfc 3.23.2
+    Python 3.12.7
     ConfigArgParse 1.7
-    google-i18n-address 3.1.0
+    google-i18n-address 3.1.1
     intervaltree 3.1.0
-    Jinja2 3.1.2
-    lxml 4.9.3
-    platformdirs 4.2.0
+    Jinja2 3.1.4
+    lxml 4.9.4
+    platformdirs 4.3.6
     pycountry 22.3.5
     PyYAML 6.0.1
-    requests 2.31.0
-    setuptools 68.2.2
-    six 1.16.0
+    requests 2.32.3
+    setuptools 70.3.0
     wcwidth 0.2.13
 -->
 <link href="draft-ietf-core-coap-pubsub.xml" rel="alternate" type="application/rfc+xml">
@@ -1026,11 +1025,11 @@
 <thead><tr>
 <td class="left">Internet-Draft</td>
 <td class="center">A publish-subscribe architecture for the</td>
-<td class="right">April 2024</td>
+<td class="right">October 2024</td>
 </tr></thead>
 <tfoot><tr>
 <td class="left">Jimenez, et al.</td>
-<td class="center">Expires 20 October 2024</td>
+<td class="center">Expires 23 April 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1043,12 +1042,12 @@
 <dd class="internet-draft">draft-ietf-core-coap-pubsub-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-04-18" class="published">18 April 2024</time>
+<time datetime="2024-10-20" class="published">20 October 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2024-10-20">20 October 2024</time></dd>
+<dd class="expires"><time datetime="2025-04-23">23 April 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1105,7 +1104,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 20 October 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 23 April 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1314,12 +1313,7 @@ <h3 id="name-terminology">
 "MAY", and "OPTIONAL" in this document are to be interpreted as
 described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> when, and only when, they
 appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
-<p id="section-1.1-2">This specification requires readers to be familiar with all the terms and
-concepts that are discussed in <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span> and <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>. Readers
-should also be familiar with the terms and concepts discussed in
-<span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span> and <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. The URI template
-format <span>[<a href="#RFC6570" class="cite xref">RFC6570</a>]</span> is used to describe the REST API defined in
-this specification.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
+<p id="section-1.1-2">This specification requires readers to be familiar with all the terms and concepts that are discussed in <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span> and <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>. Readers should also be familiar with the terms and concepts discussed in <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span> and <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. The URI template format <span>[<a href="#RFC6570" class="cite xref">RFC6570</a>]</span> is used to describe the REST API defined in this specification.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
 <p id="section-1.1-3">This specification makes use of the following terminology:<a href="#section-1.1-3" class="pilcrow">¶</a></p>
 <span class="break"></span><dl class="dlNewline" id="section-1.1-4">
           <dt id="section-1.1-4.1">publish-subscribe (pub/sub):</dt>
@@ -1690,22 +1684,30 @@ <h4 id="name-topic-properties">
             <li class="normal" id="section-2.2.1-2.3">
               <p id="section-2.2.1-2.3.1">'resource-type': A required field used to indicate the resource type of the topic-data resource for the topic. It encodes the resource type as a CBOR text string. The value should be "core.ps.conf".<a href="#section-2.2.1-2.3.1" class="pilcrow">¶</a></p>
 </li>
-          </ul>
-<ul class="normal">
-<li class="normal" id="section-2.2.1-3.1">
-              <p id="section-2.2.1-3.1.1">'media-type': An optional field used to indicate the media type of the topic-data resource for the topic. It encodes the media type as a this information as the integer identifier of the CoAP content-format (e.g., value is "50" for "application/json").<a href="#section-2.2.1-3.1.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-2.2.1-2.4">
+              <p id="section-2.2.1-2.4.1">'media-type': An optional field used to indicate the media type of the topic-data resource for the topic. It encodes the media type as a this information as the integer identifier of the CoAP content-format (e.g., value is "50" for "application/json").<a href="#section-2.2.1-2.4.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-2.2.1-3.2">
-              <p id="section-2.2.1-3.2.1">'topic-type': An optional field used to indicate the attribute or property of the topic-data resource for the topic. It encodes the attribute as a CBOR text string. Example attributes include "temperature".<a href="#section-2.2.1-3.2.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-2.2.1-2.5">
+              <p id="section-2.2.1-2.5.1">'topic-type': An optional field used to indicate the attribute or property of the topic-data resource for the topic. It encodes the attribute as a CBOR text string. Example attributes include "temperature".<a href="#section-2.2.1-2.5.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-2.2.1-3.3">
-              <p id="section-2.2.1-3.3.1">'expiration-date': An optional field used to indicate the expiration date of the topic. It encodes the expiration date as a CBOR text string. The value should be a date string in ISO 8601 format (e.g., "2023-03-31T23:59:59Z"). The broker can use this field to automatically remove topics that are no longer valid. If this field is not present, the topic will not expire automatically.<a href="#section-2.2.1-3.3.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-2.2.1-2.6">
+              <p id="section-2.2.1-2.6.1">'expiration-date': An optional field used to indicate the expiration date of the topic. It encodes the expiration date as a CBOR text string. The value should be a date string in ISO 8601 format (e.g., "2023-03-31T23:59:59Z"). The broker can use this field to automatically remove topics that are no longer valid. If this field is not present, the topic will not expire automatically.<a href="#section-2.2.1-2.6.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-2.2.1-3.4">
-              <p id="section-2.2.1-3.4.1">'max-subscribers': An optional field used to indicate the maximum number of simultaneous subscribers allowed for the topic. It encodes the maximum number as an unsigned CBOR integer. If this field is not present, there is no limit to the number of simultaneous subscribers allowed. The broker can use this field to limit the number of subscribers for the topic. The default value for this field has been set to 100 subscribers.<a href="#section-2.2.1-3.4.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-2.2.1-2.7">
+              <p id="section-2.2.1-2.7.1">'max-subscribers': An optional field used to indicate the maximum number of simultaneous subscribers allowed for the topic. It encodes the maximum number as an unsigned CBOR integer. If this field is not present, there is no limit to the number of simultaneous subscribers allowed. The broker can use this field to limit the number of subscribers for the topic. The default value for this field has been set to 100 subscribers.<a href="#section-2.2.1-2.7.1" class="pilcrow">¶</a></p>
 </li>
-            <li class="normal" id="section-2.2.1-3.5">
-              <p id="section-2.2.1-3.5.1">'observer-check': An optional field that controls the maximum number of seconds between two consecutive Observe notifications sent as Confirmable messages to each topic subscriber. Encoded as a CBOR unsigned integer greater than 0, it ensures subscribers who have lost interest and silently forgotten the observation do not remain indefinitely on the server's observer list. If another CoAP server hosts the topic-data resource, that server is responsible for applying the observer-check value. The default value for this field is 86400, as defined in <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>, which corresponds to 24 hours.<a href="#section-2.2.1-3.5.1" class="pilcrow">¶</a></p>
+            <li class="normal" id="section-2.2.1-2.8">
+              <p id="section-2.2.1-2.8.1">'observer-check': An optional field that controls the maximum number of seconds between two consecutive Observe notifications sent as Confirmable messages to each topic subscriber. Encoded as a CBOR unsigned integer greater than 0, it ensures subscribers who have lost interest and silently forgotten the observation do not remain indefinitely on the server's observer list. If another CoAP server hosts the topic-data resource, that server is responsible for applying the observer-check value. The default value for this field is 86400, as defined in <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>, which corresponds to 24 hours.<a href="#section-2.2.1-2.8.1" class="pilcrow">¶</a></p>
+</li>
+          </ul>
+<ul class="normal">
+<li class="normal" id="section-2.2.1-3.1">
+              <p id="section-2.2.1-3.1.1">'topic-history': An optional field used to indicate how many previous resource representations the broker shall store for a topic. Encoded as an unsigned CBOR integer, it defines a counter representing the number of historical resource states the broker should retain. This enables subscribers to retrieve past states of the topic data when necessary, useful in scenarios where historical context is required (e.g., for data analytics or auditing). If this field is not present, no historical data will be stored.<a href="#section-2.2.1-3.1.1" class="pilcrow">¶</a></p>
+</li>
+          </ul>
+<ul class="normal">
+<li class="normal" id="section-2.2.1-4.1">
+              <p id="section-2.2.1-4.1.1">'initialize': An optional boolean field that, when set to <code>true</code>, allows the topic-data path to be pre-populated with an empty string or other initial value during the topic creation process. This behavior facilitates one-shot publication and topic creation, enabling CoAP clients to subscribe by default without encountering a <code>4.04 Not Found</code> error. If this field is not present, the broker behaves as usual, and the topic-data path is not initialized.<a href="#section-2.2.1-4.1.1" class="pilcrow">¶</a></p>
 </li>
           </ul>
 </section>
@@ -1727,14 +1729,20 @@ <h4 id="name-broker-discovery">
 <p id="section-2.3.1-2">The following example shows an endpoint discovering a broker using the "core.ps" resource type over a multicast network. Brokers within the multicast scope will answer the query.<a href="#section-2.3.1-2" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.3.1-3">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: coap://[ff0x::fe]/.well-known/core
-   Resource-Type: core.ps
+   Request:
 
-&lt;= 2.05 Content
-   Payload:
+   Header: GET (Code=0.01)
+   Uri-Host: "kdc.example.com"
+   Uri-Path: ".well-known"
+   Uri-Path: "core"
+   Uri-Query: "rt=core.ps"
+
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: 40 (application/link-format)
-   &lt;coap://mythinguri.com/broker/v1&gt;; rt=core.ps
+   Payload:
+   &lt;coap://mythinguri.com/broker/v1&gt;;rt="core.ps"
 </pre><a href="#section-2.3.1-3" class="pilcrow">¶</a>
 </div>
 </section>
@@ -1750,12 +1758,18 @@ <h4 id="name-topic-collection-discovery">
 <p id="section-2.3.2-4">Example:<a href="#section-2.3.2-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.3.2-5">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: .well-known/core
-   Resource-Type: core.ps.coll
+   Request:
 
-   &lt;= 2.05 Content
+   Header: GET (Code=0.01)
+   Uri-Path: ".well-known"
+   Uri-Path: "core"
+   Uri-Query: "rt=core.ps.coll"
+
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: 40 (application/link-format)
+   Payload:
    &lt;/ps1&gt;;rt="core.ps.coll";ct=40,
    &lt;/other/path&gt;;rt="core.ps.coll";ct=40
 </pre><a href="#section-2.3.2-5" class="pilcrow">¶</a>
@@ -1771,14 +1785,20 @@ <h4 id="name-topic-configuration-discove">
 <p id="section-2.3.3-2">Below is an example of discovery via /.well-known/core with rt=core.ps.conf that returns a list of topics, as the list of links to the corresponding topic resources.<a href="#section-2.3.3-2" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.3.3-3">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: .well-known/core
-   Resource-Type: core.ps.conf
+   Request:
 
-&lt;= 2.05 Content
+   Header: GET (Code=0.01)
+   Uri-Path: ".well-known"
+   Uri-Path: "core"
+   Uri-Query: "rt=core.ps.conf"
+
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: 40 (application/link-format)
+   Payload:
    &lt;/ps1/h9392&gt;;rt="core.ps.conf";ct=TBD,
-   &lt;/other/path/2e3570&gt;;rt=core.ps.conf;ct=TBD
+   &lt;/other/path/2e3570&gt;;rt="core.ps.conf";ct=TBD
 </pre><a href="#section-2.3.3-3" class="pilcrow">¶</a>
 </div>
 </section>
@@ -1793,13 +1813,18 @@ <h4 id="name-topic-data-discovery">
 <p id="section-2.3.4-3">It is also possible to discover a list of topic-data resources by sending a request to the collection with with rt=core.ps.data resources as shown below.<a href="#section-2.3.4-3" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.3.4-4">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: /ps
-   Resource-Type: core.ps.data
+   Request:
+
+   Header: GET (Code=0.01)
+   Uri-Path: "ps"
+   Uri-Query: "rt=core.ps.data"
+
+   Response:
 
-&lt;= 2.05 Content
+   Header: Content (Code=2.05)
    Content-Format: 40 (application/link-format)
-   &lt;/ps/data/62e4f8d&gt;; rt=core.ps.data; obs
+   Payload:
+   &lt;/ps/data/62e4f8d&gt;;rt="core.ps.data";obs
 </pre><a href="#section-2.3.4-4" class="pilcrow">¶</a>
 </div>
 </section>
@@ -1823,13 +1848,18 @@ <h4 id="name-retrieving-all-topic-config">
 <p id="section-2.4.1-4">Example:<a href="#section-2.4.1-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.4.1-5">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
+   Request:
+
+   Header: GET (Code=0.01)
+   Uri-Path: "ps"
+
+   Response:
 
-&lt;= 2.05 Content
+   Header: Content (Code=2.05)
    Content-Format: 40 (application/link-format)
+   Payload:
    &lt;/ps/h9392&gt;;rt="core.ps.conf",
-   &lt;/ps/2e3570&gt;; rt="core.ps.conf"
+   &lt;/ps/2e3570&gt;;rt="core.ps.conf"
 </pre><a href="#section-2.4.1-5" class="pilcrow">¶</a>
 </div>
 </section>
@@ -1848,17 +1878,22 @@ <h4 id="name-getting-topic-configuration">
 <p id="section-2.4.2-4">Example:<a href="#section-2.4.2-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.4.2-5">
 <pre>
-=&gt; 0.05 FETCH
-   Uri-Path: ps
-   Content-Format: TBD (application/pubsub+cbor)
+   Request:
 
+   Header: FETCH (Code=0.05)
+   Uri-Path: "ps"
+   Content-Format: TBD (application/pubsub+cbor)
+   Payload:
    {
-     "resource-type": "core.ps.conf",
-     "topic-type": "temperature"
+      "resource-type": "core.ps.conf",
+      "topic-type": "temperature"
    }
 
-&lt;= 2.05 Content
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: 40 (application/link-format)
+   Payload:
    &lt;/ps/2e3570&gt;;rt="core.ps.conf"
 </pre><a href="#section-2.4.2-5" class="pilcrow">¶</a>
 </div>
@@ -1871,31 +1906,36 @@ <h4 id="name-creating-a-topic">
           </h4>
 <p id="section-2.4.3-1">A client can add a new topic-configurations to a collection of topics by submitting an initial representation of the initial topic resource (see  <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>) in a POST request to the topic collection URI. The request MUST specify at least a subset of the properties in  <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>, namely: topic-name and resource-type.<a href="#section-2.4.3-1" class="pilcrow">¶</a></p>
 <p id="section-2.4.3-2">Please note that the topic will NOT be fully created until a publisher has published some data to it (See <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>).<a href="#section-2.4.3-2" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-3">On success, the server returns a 2.01 (Created) response, indicating the Location-Path of the new topic and the current representation of the topic resource. The response payload includes a CBOR map with key-value pairs. The response must include the required topic properties (see <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>), namely: "topic-name", "resource-type" and "topic-data". It may also include a number of optional properties too.<a href="#section-2.4.3-3" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-4">If requirements are defined for the client to create the topic as requested and the broker does not successfully assess that those requirements are met, then the broker MUST respond with a 4.03 (Forbidden) error. The response MUST have Content-Format set to "application/core-pubsub+cbor".<a href="#section-2.4.3-4" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-5">The broker MUST issue a 4.00 (Bad Request) error if a received parameter is invalid, unrecognized, or if the topic-name is already in use or otherwise invalid.<a href="#section-2.4.3-5" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.4.3-6">
+<p id="section-2.4.3-3">To facilitate immediate subscription and allow clients to observe the topic before data has been published, the client can include the "initialize" set to "true". When supported, the broker will create the topic and pre-populate the "topic-data" field with an empty value. This allows subscribers to observe the topic without encountering a 4.04 (Not Found) error, even if no data has been published yet.<a href="#section-2.4.3-3" class="pilcrow">¶</a></p>
+<p id="section-2.4.3-4">When "initialize" is set to "false" or omitted, the topic will only be fully created after data is published to it.<a href="#section-2.4.3-4" class="pilcrow">¶</a></p>
+<p id="section-2.4.3-5">On success, the server returns a 2.01 (Created) response, indicating the Location-Path of the new topic and the current representation of the topic resource. The response payload includes a CBOR map with key-value pairs. The response must include the required topic properties (see <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>), namely: "topic-name", "resource-type" and "topic-data". It may also include a number of optional properties too.<a href="#section-2.4.3-5" class="pilcrow">¶</a></p>
+<p id="section-2.4.3-6">If requirements are defined for the client to create the topic as requested and the broker does not successfully assess that those requirements are met, then the broker MUST respond with a 4.03 (Forbidden) error. The response MUST have Content-Format set to "application/core-pubsub+cbor".<a href="#section-2.4.3-6" class="pilcrow">¶</a></p>
+<p id="section-2.4.3-7">The broker MUST issue a 4.00 (Bad Request) error if a received parameter is invalid, unrecognized, or if the topic-name is already in use or otherwise invalid.<a href="#section-2.4.3-7" class="pilcrow">¶</a></p>
+<div class="alignLeft art-text artwork" id="section-2.4.3-8">
 <pre>
-=&gt; 0.02 POST
-   Uri-Path: ps
+   Request:
+
+   Header: POST (Code=0.02)
+   Uri-Path: "ps"
    Content-Format: TBD2 (application/core-pubsub+cbor)
-   TBD (this should be a CBOR map with the mandatory parameters)
+   Payload (in CBOR diagnostic notation):
    {
-     "topic-name": "living-room-sensor",
-     "resource-type": "core.ps.conf"
+      / topic-name /         0: "living-room-sensor",
+      / resource-type /      1: "core.ps.conf"
    }
 
-&lt;= 2.01 Created
-   Location-Path: ps/h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Response:
 
-   TBD (this should be a CBOR map)
+   Header: Created (Code=2.01)
+   Location-Path: "ps/h9392"
+   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-     "topic-name": "living-room-sensor",
-     "topic-data": "ps/data/1bd0d6d",
-     "resource-type": "core.ps.conf"
+      / topic-name /         0: "living-room-sensor",
+      / topic-data /         1: "ps/data/1bd0d6d",
+      / resource-type /      2: "core.ps.conf"
    }
-</pre><a href="#section-2.4.3-6" class="pilcrow">¶</a>
+</pre><a href="#section-2.4.3-8" class="pilcrow">¶</a>
 </div>
 </section>
 </div>
@@ -1919,22 +1959,27 @@ <h4 id="name-getting-a-topic-configurati">
 <p id="section-2.5.1-5">For example, below is a request on the topic "ps/h9392":<a href="#section-2.5.1-5" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.5.1-6">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-   Uri-Path: h9392
+   Request:
+
+   Header: GET (Code=0.01)
+   Uri-Path: "ps"
+   Uri-Path: "h9392"
+
+   Response:
 
-&lt;= 2.05 Content
+   Header: Content (Code=2.05)
    Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-      "topic-name" : "living-room-sensor",
-      "topic-data" : "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "temperature",
-      "expiration-date": "2023-04-00T23:59:59Z",
-      "max-subscribers": 100
+      / topic-name /         0: "living-room-sensor",
+      / topic-data /         1: "ps/data/1bd0d6d",
+      / resource-type /      2: "core.ps.conf",
+      / media-type /         3: "application/senml-cbor",
+      / topic-type /         4: "temperature",
+      / expiration-date /    5: "2023-04-00T23:59:59Z",
+      / max-subscribers /    6: 100,
+      / topic-history /      7: 10
    }
-
 </pre><a href="#section-2.5.1-6" class="pilcrow">¶</a>
 </div>
 </section>
@@ -1953,21 +1998,26 @@ <h4 id="name-getting-part-of-a-topic-con">
 <p id="section-2.5.2-7">Example:<a href="#section-2.5.2-7" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.5.2-8">
 <pre>
-=&gt; 0.05 FETCH
-   Uri-Path: ps
-   Uri-Path: h9392
+   Request:
+
+   Header: FETCH (Code=0.05)
+   Uri-Path: "ps"
+   Uri-Path: "h9392"
    Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-     "conf-filter": ["topic-data", "media-type"]
+      / conf-filter / 0: ["topic-data", "media-type"]
    }
 
-&lt;= 2.05 Content
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-     "topic-data": "ps/data/1bd0d6d",
-     "media-type": "application/senml-cbor"
+      / topic-data /   1: "ps/data/1bd0d6d",
+      / media-type /   3: "application/senml-cbor"
    }
-
 </pre><a href="#section-2.5.2-8" class="pilcrow">¶</a>
 </div>
 </section>
@@ -1985,33 +2035,36 @@ <h4 id="name-updating-the-topic-configur">
 <p id="section-2.5.3-6">Example:<a href="#section-2.5.3-6" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.5.3-7">
 <pre>
-=&gt; 0.03 PUT
-   Uri-Path: ps
-   Uri-Path: h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Request:
 
+   Header: PUT (Code=0.03)
+   Uri-Path: "ps"
+   Uri-Path: "h9392"
+   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-      "topic-name": "living-room-sensor",
-      "topic-data": "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "temperature",
-      "expiration-date": "2023-04-28T23:59:59Z",
+      / topic-name /        0: "living-room-sensor",
+      / topic-data /        1: "ps/data/1bd0d6d",
+      / resource-type /     2: "core.ps.conf",
+      / media-type /        3: "application/senml-cbor",
+      / topic-type /        4: "temperature",
+      / expiration-date /   5: "2023-04-28T23:59:59Z"
    }
 
-&lt;= 2.04 Changed
-   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Response:
 
-   TBD (this should be a CBOR map)
+   Header: Changed (Code=2.04)
+   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-      "topic-name": "living-room-sensor",
-      "topic-data": "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "temperature",
-      "expiration-date": "2023-04-28T23:59:59Z",
-      "max-subscribers": 100,
-      "observer-check": 86400
+      / topic-name /        0: "living-room-sensor",
+      / topic-data /        1: "ps/data/1bd0d6d",
+      / resource-type /     2: "core.ps.conf",
+      / media-type /        3: "application/senml-cbor",
+      / topic-type /        4: "temperature",
+      / expiration-date /   5: "2023-04-28T23:59:59Z",
+      / max-subscribers /   6: 100,
+      / observer-check /    7: 86400
    }
 </pre><a href="#section-2.5.3-7" class="pilcrow">¶</a>
 </div>
@@ -2040,28 +2093,31 @@ <h4 id="name-updating-the-topic-configura">
 <p id="section-2.5.4-4">Contrary to PUT, iPATCH operations will explicitly update some parameters, leaving others unmodified.<a href="#section-2.5.4-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.5.4-5">
 <pre>
-=&gt; 0.07 iPATCH
-   Uri-Path: ps
-   Uri-Path: h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Request:
 
+   Header: iPATCH (Code=0.07)
+   Uri-Path: "ps"
+   Uri-Path: "h9392"
+   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-      "topic-type": "humidity",
-      "max-subscribers": 5
+      / topic-type /       4: "humidity",
+      / max-subscribers /  6: 5
    }
 
-&lt;= 2.04 Changed
-   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Response:
 
-   TBD (this should be a CBOR map)
+   Header: Changed (Code=2.04)
+   Content-Format: TBD2 (application/core-pubsub+cbor)
+   Payload (in CBOR diagnostic notation):
    {
-      "topic-name" : "living-room-sensor",
-      "topic-data" : "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "humidity",
-      "expiration-date": "2023-05-28T23:59:59Z",
-      "max-subscribers": 5
+      / topic-name /        0: "living-room-sensor",
+      / topic-data /        1: "ps/data/1bd0d6d",
+      / resource-type /     2: "core.ps.conf",
+      / media-type /        3: "application/senml-cbor",
+      / topic-type /        4: "humidity",
+      / expiration-date /   5: "2023-05-28T23:59:59Z",
+      / max-subscribers /   6: 5
    }
 </pre><a href="#section-2.5.4-5" class="pilcrow">¶</a>
 </div>
@@ -2079,11 +2135,15 @@ <h4 id="name-deleting-a-topic-configurat">
 <p id="section-2.5.5-4">Example:<a href="#section-2.5.5-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-2.5.5-5">
 <pre>
-=&gt; 0.04 DELETE
-   Uri-Path: ps
-   Uri-Path: h9392
+   Request:
 
-&lt;= 2.02 Deleted
+   Header: DELETE (Code=0.04)
+   Uri-Path: "ps"
+   Uri-Path: "h9392"
+
+   Response:
+
+   Header: Deleted (Code=2.02)
 </pre><a href="#section-2.5.5-5" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2203,12 +2263,14 @@ <h4 id="name-publish">
 <p id="section-3.2.1-6">Example of first publication:<a href="#section-3.2.1-6" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-3.2.1-7">
 <pre>
-=&gt; 0.03 PUT
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-   Content-Format: 110
+   Request:
 
+   Header: PUT (Code=0.03)
+   Uri-Path: "ps"
+   Uri-Path: "data"
+   Uri-Path: "1bd0d6d"
+   Content-Format: 110
+   Payload:
    {
       "n": "coap://dev1.example.com/temperature",
       "u": "Cel",
@@ -2216,18 +2278,22 @@ <h4 id="name-publish">
       "v": 23.5
    }
 
-&lt;= 2.01 Created
+   Response:
+
+   Header: Created (Code=2.01)
 </pre><a href="#section-3.2.1-7" class="pilcrow">¶</a>
 </div>
 <p id="section-3.2.1-8">Example of subsequent publication:<a href="#section-3.2.1-8" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-3.2.1-9">
 <pre>
-=&gt; 0.03 PUT
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-   Content-Format: 110
+   Request:
 
+   Header: PUT (Code=0.03)
+   Uri-Path: "ps"
+   Uri-Path: "data"
+   Uri-Path: "1bd0d6d"
+   Content-Format: 110
+   Payload:
    {
       "n": "coap://dev1.example.com/temperature",
       "u": "Cel",
@@ -2235,7 +2301,9 @@ <h4 id="name-publish">
       "v": 22.5
    }
 
-&lt;= 2.04 Updated
+   Response:
+
+   Header: Updated (Code=2.04)
 </pre><a href="#section-3.2.1-9" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2265,36 +2333,41 @@ <h4 id="name-subscribe">
 <p id="section-3.2.2-7">Example:<a href="#section-3.2.2-7" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-3.2.2-8">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
+   Request:
+
+   Header: GET (Code=0.01)
+   Uri-Path: "ps"
+   Uri-Path: "data"
+   Uri-Path: "1bd0d6d"
    Observe: 0
 
-&lt;= 2.05 Content
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: 110
    Observe: 10001
    Max-Age: 15
+   Payload:
+   {
+      "n": "urn:dev:os:32473-123456",
+      "u": "Cel",
+      "t": 1696341182,
+      "v": 19.87
+   }
 
-  {
-    "n": "urn:dev:os:32473-123456",
-    "u": "Cel",
-    "t": 1696341182,
-    "v": 19.87
-  }
+   Response:
 
-&lt;= 2.05 Content
+   Header: Content (Code=2.05)
    Content-Format: 110
    Observe: 10002
    Max-Age: 15
-
-  {
-
-    "n": "urn:dev:os:32473-123456",
-    "u": "Cel",
-    "t": 1696340184,
-    "v": 21.87
-  }
+   Payload:
+   {
+      "n": "urn:dev:os:32473-123456",
+      "u": "Cel",
+      "t": 1696340184,
+      "v": 21.87
+   }
 </pre><a href="#section-3.2.2-8" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2320,12 +2393,16 @@ <h4 id="name-delete-topic-data">
 <p id="section-3.2.4-4">Example:<a href="#section-3.2.4-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-3.2.4-5">
 <pre>
-=&gt; 0.04 DELETE
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
+   Request:
+
+   Header: DELETE (Code=0.04)
+   Uri-Path: "ps"
+   Uri-Path: "data"
+   Uri-Path: "1bd0d6d"
+
+   Response:
 
-&lt;= 2.02 Deleted
+   Header: Deleted (Code=2.02)
 </pre><a href="#section-3.2.4-5" class="pilcrow">¶</a>
 </div>
 </section>
@@ -2343,15 +2420,19 @@ <h3 id="name-read-latest-data">
 <p id="section-3.3-4">Example:<a href="#section-3.3-4" class="pilcrow">¶</a></p>
 <div class="alignLeft art-text artwork" id="section-3.3-5">
 <pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
+   Request:
 
-&lt;= 2.05 Content
+   Header: GET (Code=0.01)
+   Uri-Path: "ps"
+   Uri-Path: "data"
+   Uri-Path: "1bd0d6d"
+
+   Response:
+
+   Header: Content (Code=2.05)
    Content-Format: 110
    Max-Age: 15
-
+   Payload:
    {
       "n": "coap://dev1.example.com/temperature",
       "u": "Cel",
@@ -2541,7 +2622,7 @@ <h3 id="name-content-format">
 <a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-content-format" class="section-name selfRef">Content-Format</a>
         </h3>
 <p id="section-6.2-1">IANA has added the following Content-Formats to the
-<a href="http://www.iana.org/assignments/core-parameters#content-formats" class="relref">"CoAP Content-Formats"</a>
+<a href="https://www.iana.org/assignments/core-parameters#content-formats" class="relref">"CoAP Content-Formats"</a>
 sub-registry, within the "Constrained RESTful Environments (CoRE)
 Parameters" Registry <span>[<a href="#IANA.core-parameters" class="cite xref">IANA.core-parameters</a>]</span>, as follows:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
 <span id="name-new-content-format"></span><table class="left" id="table-2">
@@ -2633,6 +2714,7 @@ <h2 id="name-acknowledgements">
 <p id="section-7-2">The authors would like to also thank Carsten Bormann, Hannes Tschofenig, Zach Shelby, Mohit Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran Selander, Mikko Majanen, Olaf Bergmann and Oscar Novo for their valuable contributions and reviews.<a href="#section-7-2" class="pilcrow">¶</a></p>
 </section>
 </div>
+<div id="sec-combined-references">
 <section id="section-8">
       <h2 id="name-references">
 <a href="#name-references" class="section-name selfRef">References</a>
@@ -2645,11 +2727,11 @@ <h3 id="name-normative-references">
 <dl class="references">
 <dt id="IANA.core-parameters">[IANA.core-parameters]</dt>
         <dd>
-<span class="refAuthor">IANA</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Parameters"</span>, <span>&lt;<a href="http://www.iana.org/assignments/core-parameters">http://www.iana.org/assignments/core-parameters</a>&gt;</span>. </dd>
+<span class="refAuthor">IANA</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Parameters"</span>, <span>&lt;<a href="https://www.iana.org/assignments/core-parameters">https://www.iana.org/assignments/core-parameters</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 <dt id="IANA.media-types">[IANA.media-types]</dt>
         <dd>
-<span class="refAuthor">IANA</span>, <span class="refTitle">"Media Types"</span>, <span>&lt;<a href="http://www.iana.org/assignments/media-types">http://www.iana.org/assignments/media-types</a>&gt;</span>. </dd>
+<span class="refAuthor">IANA</span>, <span class="refTitle">"Media Types"</span>, <span>&lt;<a href="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 <dt id="RFC2119">[RFC2119]</dt>
         <dd>
@@ -2702,15 +2784,15 @@ <h3 id="name-informative-references">
 <dd class="break"></dd>
 <dt id="I-D.ietf-ace-key-groupcomm">[I-D.ietf-ace-key-groupcomm]</dt>
         <dd>
-<span class="refAuthor">Palombini, F.</span> and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Key Provisioning for Group Communication using ACE"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-key-groupcomm-18</span>, <time datetime="2024-01-16" class="refDate">16 January 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-18">https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-18</a>&gt;</span>. </dd>
+<span class="refAuthor">Palombini, F.</span> and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Key Provisioning for Group Communication using ACE"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-key-groupcomm-19</span>, <time datetime="2024-04-30" class="refDate">30 April 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-19">https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-19</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 <dt id="I-D.ietf-ace-oscore-gm-admin">[I-D.ietf-ace-oscore-gm-admin]</dt>
         <dd>
-<span class="refAuthor">Tiloca, M.</span>, <span class="refAuthor">Höglund, R.</span>, <span class="refAuthor">Van der Stok, P.</span>, and <span class="refAuthor">F. Palombini</span>, <span class="refTitle">"Admin Interface for the OSCORE Group Manager"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-oscore-gm-admin-11</span>, <time datetime="2024-03-04" class="refDate">4 March 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-11">https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-11</a>&gt;</span>. </dd>
+<span class="refAuthor">Tiloca, M.</span>, <span class="refAuthor">Höglund, R.</span>, <span class="refAuthor">Van der Stok, P.</span>, and <span class="refAuthor">F. Palombini</span>, <span class="refTitle">"Admin Interface for the OSCORE Group Manager"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-oscore-gm-admin-12</span>, <time datetime="2024-07-08" class="refDate">8 July 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-12">https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-12</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 <dt id="I-D.ietf-ace-pubsub-profile">[I-D.ietf-ace-pubsub-profile]</dt>
         <dd>
-<span class="refAuthor">Palombini, F.</span>, <span class="refAuthor">Sengul, C.</span>, and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-pubsub-profile-09</span>, <time datetime="2024-03-04" class="refDate">4 March 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-09">https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-09</a>&gt;</span>. </dd>
+<span class="refAuthor">Palombini, F.</span>, <span class="refAuthor">Sengul, C.</span>, and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-pubsub-profile-10</span>, <time datetime="2024-07-07" class="refDate">7 July 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-10">https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-10</a>&gt;</span>. </dd>
 <dd class="break"></dd>
 <dt id="RFC8126">[RFC8126]</dt>
         <dd>
@@ -2744,6 +2826,7 @@ <h3 id="name-informative-references">
 </section>
 </div>
 </section>
+</div>
 <div id="contributors">
 <section id="appendix-A">
       <h2 id="name-contributors">
diff --git a/draft-ietf-core-coap-pubsub.txt b/draft-ietf-core-coap-pubsub.txt
index 6b967f8..202ca1f 100644
--- a/draft-ietf-core-coap-pubsub.txt
+++ b/draft-ietf-core-coap-pubsub.txt
@@ -5,10 +5,10 @@
 CoRE Working Group                                            J. Jimenez
 Internet-Draft                                                  Ericsson
 Intended status: Standards Track                               M. Koster
-Expires: 20 October 2024                                   Dogtiger Labs
+Expires: 23 April 2025                                     Dogtiger Labs
                                                               A. Keranen
                                                                 Ericsson
-                                                           18 April 2024
+                                                         20 October 2024
 
 
     A publish-subscribe architecture for the Constrained Application
@@ -53,9 +53,9 @@ Status of This Memo
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 1]
+Jimenez, et al.           Expires 23 April 2025                 [Page 1]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    Internet-Drafts are draft documents valid for a maximum of six months
@@ -63,7 +63,7 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 20 October 2024.
+   This Internet-Draft will expire on 23 April 2025.
 
 Copyright Notice
 
@@ -89,51 +89,51 @@ Table of Contents
      2.1.  Collection Representation . . . . . . . . . . . . . . . .   7
      2.2.  Topic-Configuration Representation  . . . . . . . . . . .   8
        2.2.1.  Topic Properties  . . . . . . . . . . . . . . . . . .   8
-     2.3.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   9
-       2.3.1.  Broker Discovery  . . . . . . . . . . . . . . . . . .   9
-       2.3.2.  Topic Collection Discovery  . . . . . . . . . . . . .  10
-       2.3.3.  Topic-Configuration Discovery . . . . . . . . . . . .  10
-       2.3.4.  Topic-Data Discovery  . . . . . . . . . . . . . . . .  11
-     2.4.  Topic Collection Interactions . . . . . . . . . . . . . .  11
-       2.4.1.  Retrieving all topic-configurations . . . . . . . . .  11
-       2.4.2.  Getting topic-configurations by Properties  . . . . .  12
-       2.4.3.  Creating a Topic  . . . . . . . . . . . . . . . . . .  13
-     2.5.  Topic-Configuration Interactions  . . . . . . . . . . . .  14
-       2.5.1.  Getting a topic-configuration . . . . . . . . . . . .  14
-       2.5.2.  Getting part of a topic-configuration . . . . . . . .  15
-       2.5.3.  Updating the topic-configuration  . . . . . . . . . .  16
-       2.5.4.  Updating the topic-configuration with iPATCH  . . . .  18
-       2.5.5.  Deleting a topic-configuration  . . . . . . . . . . .  19
-   3.  Publish and Subscribe . . . . . . . . . . . . . . . . . . . .  19
-     3.1.  Topic Lifecycle . . . . . . . . . . . . . . . . . . . . .  20
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 2]
+     2.3.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .  10
+       2.3.1.  Broker Discovery  . . . . . . . . . . . . . . . . . .  10
+       2.3.2.  Topic Collection Discovery  . . . . . . . . . . . . .  11
+       2.3.3.  Topic-Configuration Discovery . . . . . . . . . . . .  11
+       2.3.4.  Topic-Data Discovery  . . . . . . . . . . . . . . . .  12
+     2.4.  Topic Collection Interactions . . . . . . . . . . . . . .  12
+       2.4.1.  Retrieving all topic-configurations . . . . . . . . .  13
+       2.4.2.  Getting topic-configurations by Properties  . . . . .  13
+       2.4.3.  Creating a Topic  . . . . . . . . . . . . . . . . . .  14
+     2.5.  Topic-Configuration Interactions  . . . . . . . . . . . .  15
+       2.5.1.  Getting a topic-configuration . . . . . . . . . . . .  15
+       2.5.2.  Getting part of a topic-configuration . . . . . . . .  16
+       2.5.3.  Updating the topic-configuration  . . . . . . . . . .  18
+       2.5.4.  Updating the topic-configuration with iPATCH  . . . .  20
+       2.5.5.  Deleting a topic-configuration  . . . . . . . . . . .  21
+   3.  Publish and Subscribe . . . . . . . . . . . . . . . . . . . .  22
+     3.1.  Topic Lifecycle . . . . . . . . . . . . . . . . . . . . .  22
+
+
+
+Jimenez, et al.           Expires 23 April 2025                 [Page 2]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-     3.2.  Topic-Data Interactions . . . . . . . . . . . . . . . . .  20
-       3.2.1.  Publish . . . . . . . . . . . . . . . . . . . . . . .  21
-       3.2.2.  Subscribe . . . . . . . . . . . . . . . . . . . . . .  22
-       3.2.3.  Unsubscribe . . . . . . . . . . . . . . . . . . . . .  23
-       3.2.4.  Delete topic-data . . . . . . . . . . . . . . . . . .  24
-     3.3.  Read latest data  . . . . . . . . . . . . . . . . . . . .  24
-     3.4.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  25
-   4.  CoAP Pubsub Parameters  . . . . . . . . . . . . . . . . . . .  25
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
-     6.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  27
-     6.2.  Content-Format  . . . . . . . . . . . . . . . . . . . . .  28
-     6.3.  CoAP Pubsub Parameters  . . . . . . . . . . . . . . . . .  28
-     6.4.  Resource Types  . . . . . . . . . . . . . . . . . . . . .  29
-   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  30
-   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
-     Normative References  . . . . . . . . . . . . . . . . . . . . .  30
-     Informative References  . . . . . . . . . . . . . . . . . . . .  31
-   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
+     3.2.  Topic-Data Interactions . . . . . . . . . . . . . . . . .  23
+       3.2.1.  Publish . . . . . . . . . . . . . . . . . . . . . . .  23
+       3.2.2.  Subscribe . . . . . . . . . . . . . . . . . . . . . .  25
+       3.2.3.  Unsubscribe . . . . . . . . . . . . . . . . . . . . .  26
+       3.2.4.  Delete topic-data . . . . . . . . . . . . . . . . . .  27
+     3.3.  Read latest data  . . . . . . . . . . . . . . . . . . . .  27
+     3.4.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  28
+   4.  CoAP Pubsub Parameters  . . . . . . . . . . . . . . . . . . .  29
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
+     6.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  30
+     6.2.  Content-Format  . . . . . . . . . . . . . . . . . . . . .  31
+     6.3.  CoAP Pubsub Parameters  . . . . . . . . . . . . . . . . .  31
+     6.4.  Resource Types  . . . . . . . . . . . . . . . . . . . . .  32
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  33
+   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  33
+     Normative References  . . . . . . . . . . . . . . . . . . . . .  33
+     Informative References  . . . . . . . . . . . . . . . . . . . .  34
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  35
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36
 
 1.  Introduction
 
@@ -165,9 +165,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 3]
+Jimenez, et al.           Expires 23 April 2025                 [Page 3]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
 1.1.  Terminology
@@ -221,9 +221,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 4]
+Jimenez, et al.           Expires 23 April 2025                 [Page 4]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    topic-data resource:
@@ -277,9 +277,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 5]
+Jimenez, et al.           Expires 23 April 2025                 [Page 5]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
            CoAP                      CoAP                 CoAP
@@ -333,9 +333,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 6]
+Jimenez, et al.           Expires 23 April 2025                 [Page 6]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    The Broker exports one or more topic-collection resources, with
@@ -389,9 +389,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 7]
+Jimenez, et al.           Expires 23 April 2025                 [Page 7]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    A topic resource with a topic-data link can also be simply called
@@ -445,9 +445,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 8]
+Jimenez, et al.           Expires 23 April 2025                 [Page 8]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    *  'topic-type': An optional field used to indicate the attribute or
@@ -482,6 +482,38 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
       value for this field is 86400, as defined in [RFC7641], which
       corresponds to 24 hours.
 
+   *  'topic-history': An optional field used to indicate how many
+      previous resource representations the broker shall store for a
+      topic.  Encoded as an unsigned CBOR integer, it defines a counter
+      representing the number of historical resource states the broker
+      should retain.  This enables subscribers to retrieve past states
+      of the topic data when necessary, useful in scenarios where
+      historical context is required (e.g., for data analytics or
+      auditing).  If this field is not present, no historical data will
+      be stored.
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                 [Page 9]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
+   *  'initialize': An optional boolean field that, when set to true,
+      allows the topic-data path to be pre-populated with an empty
+      string or other initial value during the topic creation process.
+      This behavior facilitates one-shot publication and topic creation,
+      enabling CoAP clients to subscribe by default without encountering
+      a 4.04 Not Found error.  If this field is not present, the broker
+      behaves as usual, and the topic-data path is not initialized.
+
 2.3.  Discovery
 
    A client can perform a discovery of: the broker; the topic collection
@@ -497,27 +529,38 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    resource type set to "core.ps" as defined in Section 6 of this
    document.
 
+   The following example shows an endpoint discovering a broker using
+   the "core.ps" resource type over a multicast network.  Brokers within
+   the multicast scope will answer the query.
+
+      Request:
+
+      Header: GET (Code=0.01)
+      Uri-Host: "kdc.example.com"
+      Uri-Path: ".well-known"
+      Uri-Path: "core"
+      Uri-Query: "rt=core.ps"
+
+      Response:
+
+      Header: Content (Code=2.05)
+      Content-Format: 40 (application/link-format)
+      Payload:
+      <coap://mythinguri.com/broker/v1>;rt="core.ps"
 
 
 
 
-Jimenez, et al.          Expires 20 October 2024                [Page 9]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
-   The following example shows an endpoint discovering a broker using
-   the "core.ps" resource type over a multicast network.  Brokers within
-   the multicast scope will answer the query.
 
-   => 0.01 GET
-      Uri-Path: coap://[ff0x::fe]/.well-known/core
-      Resource-Type: core.ps
 
-   <= 2.05 Content
-      Payload:
-      Content-Format: 40 (application/link-format)
-      <coap://mythinguri.com/broker/v1>; rt=core.ps
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 10]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
 
 2.3.2.  Topic Collection Discovery
 
@@ -539,12 +582,18 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    Example:
 
-   => 0.01 GET
-      Uri-Path: .well-known/core
-      Resource-Type: core.ps.coll
+      Request:
+
+      Header: GET (Code=0.01)
+      Uri-Path: ".well-known"
+      Uri-Path: "core"
+      Uri-Query: "rt=core.ps.coll"
+
+      Response:
 
-      <= 2.05 Content
+      Header: Content (Code=2.05)
       Content-Format: 40 (application/link-format)
+      Payload:
       </ps1>;rt="core.ps.coll";ct=40,
       </other/path>;rt="core.ps.coll";ct=40
 
@@ -555,25 +604,34 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    Section 2.2.1).  Each topic resource is identified by the resource
    type "core.ps.conf".
 
+   Below is an example of discovery via /.well-known/core with
+   rt=core.ps.conf that returns a list of topics, as the list of links
+   to the corresponding topic resources.
+
+
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 10]
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 11]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
-   Below is an example of discovery via /.well-known/core with
-   rt=core.ps.conf that returns a list of topics, as the list of links
-   to the corresponding topic resources.
+      Request:
 
-   => 0.01 GET
-      Uri-Path: .well-known/core
-      Resource-Type: core.ps.conf
+      Header: GET (Code=0.01)
+      Uri-Path: ".well-known"
+      Uri-Path: "core"
+      Uri-Query: "rt=core.ps.conf"
 
-   <= 2.05 Content
+      Response:
+
+      Header: Content (Code=2.05)
       Content-Format: 40 (application/link-format)
+      Payload:
       </ps1/h9392>;rt="core.ps.conf";ct=TBD,
-      </other/path/2e3570>;rt=core.ps.conf;ct=TBD
+      </other/path/2e3570>;rt="core.ps.conf";ct=TBD
 
 2.3.4.  Topic-Data Discovery
 
@@ -590,33 +648,36 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    sending a request to the collection with with rt=core.ps.data
    resources as shown below.
 
-   => 0.01 GET
-      Uri-Path: /ps
-      Resource-Type: core.ps.data
+      Request:
+
+      Header: GET (Code=0.01)
+      Uri-Path: "ps"
+      Uri-Query: "rt=core.ps.data"
 
-   <= 2.05 Content
+      Response:
+
+      Header: Content (Code=2.05)
       Content-Format: 40 (application/link-format)
-      </ps/data/62e4f8d>; rt=core.ps.data; obs
+      Payload:
+      </ps/data/62e4f8d>;rt="core.ps.data";obs
 
 2.4.  Topic Collection Interactions
 
    These are the interactions that can happen directly with a specific
    topic collection.
 
-2.4.1.  Retrieving all topic-configurations
-
-   A client can request a collection of the topics present in the broker
-   by making a GET request to the collection URI.
-
 
 
 
+Jimenez, et al.           Expires 23 April 2025                [Page 12]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 11]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+2.4.1.  Retrieving all topic-configurations
 
+   A client can request a collection of the topics present in the broker
+   by making a GET request to the collection URI.
 
    On success, the server returns a 2.05 (Content) response, specifying
    the list of links to topic resources associated with this topic
@@ -628,13 +689,18 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    Example:
 
-   => 0.01 GET
-      Uri-Path: ps
+      Request:
 
-   <= 2.05 Content
+      Header: GET (Code=0.01)
+      Uri-Path: "ps"
+
+      Response:
+
+      Header: Content (Code=2.05)
       Content-Format: 40 (application/link-format)
+      Payload:
       </ps/h9392>;rt="core.ps.conf",
-      </ps/2e3570>; rt="core.ps.conf"
+      </ps/2e3570>;rt="core.ps.conf"
 
 2.4.2.  Getting topic-configurations by Properties
 
@@ -659,32 +725,27 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 12]
+Jimenez, et al.           Expires 23 April 2025                [Page 13]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
-   => 0.05 FETCH
-      Uri-Path: ps
-      Content-Format: TBD (application/pubsub+cbor)
+      Request:
 
+      Header: FETCH (Code=0.05)
+      Uri-Path: "ps"
+      Content-Format: TBD (application/pubsub+cbor)
+      Payload:
       {
-        "resource-type": "core.ps.conf",
-        "topic-type": "temperature"
+         "resource-type": "core.ps.conf",
+         "topic-type": "temperature"
       }
 
-   <= 2.05 Content
+      Response:
+
+      Header: Content (Code=2.05)
       Content-Format: 40 (application/link-format)
+      Payload:
       </ps/2e3570>;rt="core.ps.conf"
 
 2.4.3.  Creating a Topic
@@ -698,6 +759,17 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    Please note that the topic will NOT be fully created until a
    publisher has published some data to it (See Section 3.1).
 
+   To facilitate immediate subscription and allow clients to observe the
+   topic before data has been published, the client can include the
+   "initialize" set to "true".  When supported, the broker will create
+   the topic and pre-populate the "topic-data" field with an empty
+   value.  This allows subscribers to observe the topic without
+   encountering a 4.04 (Not Found) error, even if no data has been
+   published yet.
+
+   When "initialize" is set to "false" or omitted, the topic will only
+   be fully created after data is published to it.
+
    On success, the server returns a 2.01 (Created) response, indicating
    the Location-Path of the new topic and the current representation of
    the topic resource.  The response payload includes a CBOR map with
@@ -706,6 +778,14 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    and "topic-data".  It may also include a number of optional
    properties too.
 
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 14]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
    If requirements are defined for the client to create the topic as
    requested and the broker does not successfully assess that those
    requirements are met, then the broker MUST respond with a 4.03
@@ -716,38 +796,27 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    parameter is invalid, unrecognized, or if the topic-name is already
    in use or otherwise invalid.
 
+      Request:
 
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 13]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.02 POST
-      Uri-Path: ps
+      Header: POST (Code=0.02)
+      Uri-Path: "ps"
       Content-Format: TBD2 (application/core-pubsub+cbor)
-      TBD (this should be a CBOR map with the mandatory parameters)
+      Payload (in CBOR diagnostic notation):
       {
-        "topic-name": "living-room-sensor",
-        "resource-type": "core.ps.conf"
+         / topic-name /         0: "living-room-sensor",
+         / resource-type /      1: "core.ps.conf"
       }
 
-   <= 2.01 Created
-      Location-Path: ps/h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Response:
 
-      TBD (this should be a CBOR map)
+      Header: Created (Code=2.01)
+      Location-Path: "ps/h9392"
+      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
       {
-        "topic-name": "living-room-sensor",
-        "topic-data": "ps/data/1bd0d6d",
-        "resource-type": "core.ps.conf"
+         / topic-name /         0: "living-room-sensor",
+         / topic-data /         1: "ps/data/1bd0d6d",
+         / resource-type /      2: "core.ps.conf"
       }
 
 2.5.  Topic-Configuration Interactions
@@ -760,6 +829,19 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    A client can read the configuration of a topic by making a GET
    request to the topic resource URI.
 
+
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 15]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
    On success, the server returns a 2.05 (Content) response with a
    partial representation of the topic resource, as specified in
    Section 2.2.  The partial representation includes only the
@@ -778,28 +860,26 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    For example, below is a request on the topic "ps/h9392":
 
+      Request:
 
+      Header: GET (Code=0.01)
+      Uri-Path: "ps"
+      Uri-Path: "h9392"
 
+      Response:
 
-Jimenez, et al.          Expires 20 October 2024               [Page 14]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.01 GET
-      Uri-Path: ps
-      Uri-Path: h9392
-
-   <= 2.05 Content
+      Header: Content (Code=2.05)
       Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
       {
-         "topic-name" : "living-room-sensor",
-         "topic-data" : "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "temperature",
-         "expiration-date": "2023-04-00T23:59:59Z",
-         "max-subscribers": 100
+         / topic-name /         0: "living-room-sensor",
+         / topic-data /         1: "ps/data/1bd0d6d",
+         / resource-type /      2: "core.ps.conf",
+         / media-type /         3: "application/senml-cbor",
+         / topic-type /         4: "temperature",
+         / expiration-date /    5: "2023-04-00T23:59:59Z",
+         / max-subscribers /    6: 100,
+         / topic-history /      7: 10
       }
 
 2.5.2.  Getting part of a topic-configuration
@@ -809,6 +889,15 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    parameters.  This is done in order to retrieve part of the current
    topic resource.
 
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 16]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
    The request contains a CBOR map with a configuration filter or 'conf-
    filter', a CBOR array with CBOR abbreviation.  Each element of the
    array specifies one requested configuration parameter of the current
@@ -833,30 +922,38 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    Example:
 
+      Request:
 
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 15]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.05 FETCH
-      Uri-Path: ps
-      Uri-Path: h9392
+      Header: FETCH (Code=0.05)
+      Uri-Path: "ps"
+      Uri-Path: "h9392"
       Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
       {
-        "conf-filter": ["topic-data", "media-type"]
+         / conf-filter / 0: ["topic-data", "media-type"]
       }
 
-   <= 2.05 Content
+      Response:
+
+      Header: Content (Code=2.05)
       Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
       {
-        "topic-data": "ps/data/1bd0d6d",
-        "media-type": "application/senml-cbor"
+         / topic-data /   1: "ps/data/1bd0d6d",
+         / media-type /   3: "application/senml-cbor"
       }
 
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 17]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
 2.5.3.  Updating the topic-configuration
 
    A client can update a topic's configuration by submitting the updated
@@ -893,38 +990,56 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 16]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 18]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
-   => 0.03 PUT
-      Uri-Path: ps
-      Uri-Path: h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Request:
 
+      Header: PUT (Code=0.03)
+      Uri-Path: "ps"
+      Uri-Path: "h9392"
+      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
       {
-         "topic-name": "living-room-sensor",
-         "topic-data": "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "temperature",
-         "expiration-date": "2023-04-28T23:59:59Z",
+         / topic-name /        0: "living-room-sensor",
+         / topic-data /        1: "ps/data/1bd0d6d",
+         / resource-type /     2: "core.ps.conf",
+         / media-type /        3: "application/senml-cbor",
+         / topic-type /        4: "temperature",
+         / expiration-date /   5: "2023-04-28T23:59:59Z"
       }
 
-   <= 2.04 Changed
-      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Response:
 
-      TBD (this should be a CBOR map)
+      Header: Changed (Code=2.04)
+      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
       {
-         "topic-name": "living-room-sensor",
-         "topic-data": "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "temperature",
-         "expiration-date": "2023-04-28T23:59:59Z",
-         "max-subscribers": 100,
-         "observer-check": 86400
+         / topic-name /        0: "living-room-sensor",
+         / topic-data /        1: "ps/data/1bd0d6d",
+         / resource-type /     2: "core.ps.conf",
+         / media-type /        3: "application/senml-cbor",
+         / topic-type /        4: "temperature",
+         / expiration-date /   5: "2023-04-28T23:59:59Z",
+         / max-subscribers /   6: 100,
+         / observer-check /    7: 86400
       }
 
    Note that when a topic configuration changes, it may result in
@@ -946,12 +1061,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 17]
+Jimenez, et al.           Expires 23 April 2025                [Page 19]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
 2.5.4.  Updating the topic-configuration with iPATCH
@@ -978,38 +1090,65 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    Contrary to PUT, iPATCH operations will explicitly update some
    parameters, leaving others unmodified.
 
-   => 0.07 iPATCH
-      Uri-Path: ps
-      Uri-Path: h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
 
-      {
-         "topic-type": "humidity",
-         "max-subscribers": 5
-      }
 
-   <= 2.04 Changed
-      Content-Format: TBD2 (application/core-pubsub+cbor)
 
-      TBD (this should be a CBOR map)
-      {
-         "topic-name" : "living-room-sensor",
-         "topic-data" : "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "humidity",
-         "expiration-date": "2023-05-28T23:59:59Z",
-         "max-subscribers": 5
-      }
 
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 18]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 20]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
+      Request:
+
+      Header: iPATCH (Code=0.07)
+      Uri-Path: "ps"
+      Uri-Path: "h9392"
+      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
+      {
+         / topic-type /       4: "humidity",
+         / max-subscribers /  6: 5
+      }
+
+      Response:
+
+      Header: Changed (Code=2.04)
+      Content-Format: TBD2 (application/core-pubsub+cbor)
+      Payload (in CBOR diagnostic notation):
+      {
+         / topic-name /        0: "living-room-sensor",
+         / topic-data /        1: "ps/data/1bd0d6d",
+         / resource-type /     2: "core.ps.conf",
+         / media-type /        3: "application/senml-cbor",
+         / topic-type /        4: "humidity",
+         / expiration-date /   5: "2023-05-28T23:59:59Z",
+         / max-subscribers /   6: 5
+      }
+
    Note that when a topic configuration changes through an iPATCH
    request, it may result in disruptions for the subscribers.  For
    example, limiting the number of subscribers will cause to cancel
@@ -1029,11 +1168,25 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    Example:
 
-   => 0.04 DELETE
-      Uri-Path: ps
-      Uri-Path: h9392
 
-   <= 2.02 Deleted
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 21]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
+      Request:
+
+      Header: DELETE (Code=0.04)
+      Uri-Path: "ps"
+      Uri-Path: "h9392"
+
+      Response:
+
+      Header: Deleted (Code=2.02)
 
 3.  Publish and Subscribe
 
@@ -1057,15 +1210,6 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    the topic-data exists and the URI of the topic-configuration
    resource.
 
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 19]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
 3.1.  Topic Lifecycle
 
    When a topic is newly created, it is first placed by the broker into
@@ -1075,6 +1219,21 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    subscriber cannot yet subscribe to the topic-data resource nor read
    the latest data.
 
+
+
+
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 22]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
                     HALF                          FULLY
                    CREATED       Delete          CREATED
                     ____        topic-data        ____     Publish
@@ -1111,17 +1270,6 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    Interactions with the topic-data resource are covered in this
    section.
 
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 20]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
 3.2.1.  Publish
 
    A topic-configuration with a topic-data resource must have been
@@ -1135,6 +1283,13 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    topic-configuration URI used for configuring the topic (see
    Section 2.2).
 
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 23]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
    On success, the server returns a 2.04 (Updated) response.  However,
    when data is published to the topic for the first time, the server
    instead MUST return a 2.01 (Created) response and set the topic in
@@ -1148,12 +1303,14 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    Example of first publication:
 
-   => 0.03 PUT
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-      Content-Format: 110
+      Request:
 
+      Header: PUT (Code=0.03)
+      Uri-Path: "ps"
+      Uri-Path: "data"
+      Uri-Path: "1bd0d6d"
+      Content-Format: 110
+      Payload:
       {
          "n": "coap://dev1.example.com/temperature",
          "u": "Cel",
@@ -1161,7 +1318,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
          "v": 23.5
       }
 
-   <= 2.01 Created
+      Response:
+
+      Header: Created (Code=2.01)
 
    Example of subsequent publication:
 
@@ -1173,17 +1332,28 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 21]
+
+
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 24]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
-   => 0.03 PUT
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-      Content-Format: 110
+      Request:
 
+      Header: PUT (Code=0.03)
+      Uri-Path: "ps"
+      Uri-Path: "data"
+      Uri-Path: "1bd0d6d"
+      Content-Format: 110
+      Payload:
       {
          "n": "coap://dev1.example.com/temperature",
          "u": "Cel",
@@ -1191,7 +1361,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
          "v": 22.5
       }
 
-   <= 2.04 Updated
+      Response:
+
+      Header: Updated (Code=2.04)
 
 3.2.2.  Subscribe
 
@@ -1225,45 +1397,46 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 22]
+Jimenez, et al.           Expires 23 April 2025                [Page 25]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
-   => 0.01 GET
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
+      Request:
+
+      Header: GET (Code=0.01)
+      Uri-Path: "ps"
+      Uri-Path: "data"
+      Uri-Path: "1bd0d6d"
       Observe: 0
 
-   <= 2.05 Content
+      Response:
+
+      Header: Content (Code=2.05)
       Content-Format: 110
       Observe: 10001
       Max-Age: 15
+      Payload:
+      {
+         "n": "urn:dev:os:32473-123456",
+         "u": "Cel",
+         "t": 1696341182,
+         "v": 19.87
+      }
 
-     {
-       "n": "urn:dev:os:32473-123456",
-       "u": "Cel",
-       "t": 1696341182,
-       "v": 19.87
-     }
+      Response:
 
-   <= 2.05 Content
+      Header: Content (Code=2.05)
       Content-Format: 110
       Observe: 10002
       Max-Age: 15
-
-     {
-
-       "n": "urn:dev:os:32473-123456",
-       "u": "Cel",
-       "t": 1696340184,
-       "v": 21.87
-     }
+      Payload:
+      {
+         "n": "urn:dev:os:32473-123456",
+         "u": "Cel",
+         "t": 1696340184,
+         "v": 21.87
+      }
 
 3.2.3.  Unsubscribe
 
@@ -1275,21 +1448,21 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    server will remove it from the list of observers after the next
    notification.
 
-   As per [RFC7641] a server that transmits notifications mostly in non-
-   confirmable messages, but it MUST send a notification in a
-   confirmable message instead of a non-confirmable message at least
-   every 24 hours.
-
 
 
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 23]
+Jimenez, et al.           Expires 23 April 2025                [Page 26]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
+   As per [RFC7641] a server that transmits notifications mostly in non-
+   confirmable messages, but it MUST send a notification in a
+   confirmable message instead of a non-confirmable message at least
+   every 24 hours.
+
    This value can be modified at the broker by the administrator of a
    topic by modifying the parameter "observer-check" on Section 2.2.
    This would allow to change the rate at which different
@@ -1311,12 +1484,16 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    Example:
 
-   => 0.04 DELETE
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
+      Request:
+
+      Header: DELETE (Code=0.04)
+      Uri-Path: "ps"
+      Uri-Path: "data"
+      Uri-Path: "1bd0d6d"
 
-   <= 2.02 Deleted
+      Response:
+
+      Header: Deleted (Code=2.02)
 
 3.3.  Read latest data
 
@@ -1328,33 +1505,34 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    On success, the server MUST return 2.05 (Content) response with the
    data.
 
-   If the target URI does not match an existing resource or the topic is
-   not in the fully created state (see Section 3.1), the broker MUST
-   return a response code 4.04 (Not Found).
-
-   Example:
 
 
 
 
+Jimenez, et al.           Expires 23 April 2025                [Page 27]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
+   If the target URI does not match an existing resource or the topic is
+   not in the fully created state (see Section 3.1), the broker MUST
+   return a response code 4.04 (Not Found).
 
+   Example:
 
-Jimenez, et al.          Expires 20 October 2024               [Page 24]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+      Request:
 
+      Header: GET (Code=0.01)
+      Uri-Path: "ps"
+      Uri-Path: "data"
+      Uri-Path: "1bd0d6d"
 
-   => 0.01 GET
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
+      Response:
 
-   <= 2.05 Content
+      Header: Content (Code=2.05)
       Content-Format: 110
       Max-Age: 15
-
+      Payload:
       {
          "n": "coap://dev1.example.com/temperature",
          "u": "Cel",
@@ -1380,6 +1558,18 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    MUST NOT send any new publication requests to the same topic-data
    resource before the time indicated by the Max-Age option has passed.
 
+
+
+
+
+
+
+
+Jimenez, et al.           Expires 23 April 2025                [Page 28]
+
+Internet-Draft  A publish-subscribe architecture for the    October 2024
+
+
 4.  CoAP Pubsub Parameters
 
    This document defines parameters used in the messages exchanged
@@ -1392,16 +1582,6 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    when these parameters are transported in the respective message
    fields.
 
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 25]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
          +-----------------+-----------+-----------+------------+
          | Name            | CBOR Key  | CBOR Type | Reference  |
          |-----------------|-----------|-----------|------------|
@@ -1438,26 +1618,20 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
    Access control of clients at the broker MAY be enforced for
    performing discovery operation, and SHOULD be enforced in a fine-
    grained fashion for operations related to the the creation, update,
-   and deletion of topic resources, as well as for operations on topic-
-   data resources such as publication on and subscription to topics.
-   This prevents rogue clients to, among other things, repeatedly create
-   topics at the broker or publish (large) contents, which may result in
-   Denial of Service against the broker and the active subscribers.
-
-
-
-
-
-
 
 
 
-
-Jimenez, et al.          Expires 20 October 2024               [Page 26]
+Jimenez, et al.           Expires 23 April 2025                [Page 29]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
+   and deletion of topic resources, as well as for operations on topic-
+   data resources such as publication on and subscription to topics.
+   This prevents rogue clients to, among other things, repeatedly create
+   topics at the broker or publish (large) contents, which may result in
+   Denial of Service against the broker and the active subscribers.
+
    Building on [I-D.ietf-ace-key-groupcomm], its application profile for
    publish-subscribe communication with CoAP
    [I-D.ietf-ace-pubsub-profile] provides a security model that can be
@@ -1500,20 +1674,20 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
             Table 1: New Media Type application/pubsub+cbor
 
-   Type name:  application
-   Subtype name:  pubsub+cbor
-   Required parameters:  N/A
-   Optional parameters:  N/A
-   Encoding considerations:  binary (CBOR data item)
-   Security considerations:  Section 5 of RFC XXXX
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 27]
+Jimenez, et al.           Expires 23 April 2025                [Page 30]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
+   Type name:  application
+   Subtype name:  pubsub+cbor
+   Required parameters:  N/A
+   Optional parameters:  N/A
+   Encoding considerations:  binary (CBOR data item)
+   Security considerations:  Section 5 of RFC XXXX
    Interoperability considerations:  none
    Published specification:  Section 6.1 of RFC XXXX
    Applications that use this media type:  This type is used by clients
@@ -1557,19 +1731,17 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
    The columns of this registry are:
 
-   *  Name: This is a descriptive name that enables easier reference to
-      the item.  The name MUST be unique.  It is not used in the
-      encoding.
-
-
-
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 28]
+Jimenez, et al.           Expires 23 April 2025                [Page 31]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
+   *  Name: This is a descriptive name that enables easier reference to
+      the item.  The name MUST be unique.  It is not used in the
+      encoding.
+
    *  CBOR Key: This is the value used as CBOR key of the item.  These
       values MUST be unique.  The value can be a positive integer, a
       negative integer, or a text string.  Different ranges of values
@@ -1617,13 +1789,9 @@ Internet-Draft  A publish-subscribe architecture for the      April 2024
 
 
 
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 29]
+Jimenez, et al.           Expires 23 April 2025                [Page 32]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
 Acknowledgements
@@ -1647,11 +1815,11 @@ Normative References
    [IANA.core-parameters]
               IANA, "Constrained RESTful Environments (CoRE)
               Parameters",
-              <http://www.iana.org/assignments/core-parameters>.
+              <https://www.iana.org/assignments/core-parameters>.
 
    [IANA.media-types]
               IANA, "Media Types",
-              <http://www.iana.org/assignments/media-types>.
+              <https://www.iana.org/assignments/media-types>.
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119,
@@ -1677,9 +1845,9 @@ Normative References
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 30]
+Jimenez, et al.           Expires 23 April 2025                [Page 33]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    [RFC7641]  Hartke, K., "Observing Resources in the Constrained
@@ -1719,32 +1887,32 @@ Informative References
    [I-D.ietf-ace-key-groupcomm]
               Palombini, F. and M. Tiloca, "Key Provisioning for Group
               Communication using ACE", Work in Progress, Internet-
-              Draft, draft-ietf-ace-key-groupcomm-18, 16 January 2024,
+              Draft, draft-ietf-ace-key-groupcomm-19, 30 April 2024,
               <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-
-              groupcomm-18>.
+              groupcomm-19>.
 
    [I-D.ietf-ace-oscore-gm-admin]
               Tiloca, M., Höglund, R., Van der Stok, P., and F.
               Palombini, "Admin Interface for the OSCORE Group Manager",
               Work in Progress, Internet-Draft, draft-ietf-ace-oscore-
-              gm-admin-11, 4 March 2024,
+              gm-admin-12, 8 July 2024,
               <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
-              oscore-gm-admin-11>.
+              oscore-gm-admin-12>.
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 31]
+Jimenez, et al.           Expires 23 April 2025                [Page 34]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    [I-D.ietf-ace-pubsub-profile]
               Palombini, F., Sengul, C., and M. Tiloca, "Publish-
               Subscribe Profile for Authentication and Authorization for
               Constrained Environments (ACE)", Work in Progress,
-              Internet-Draft, draft-ietf-ace-pubsub-profile-09, 4 March
+              Internet-Draft, draft-ietf-ace-pubsub-profile-10, 7 July
               2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
-              ace-pubsub-profile-09>.
+              ace-pubsub-profile-10>.
 
    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
               Writing an IANA Considerations Section in RFCs", BCP 26,
@@ -1789,9 +1957,9 @@ Contributors
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 32]
+Jimenez, et al.           Expires 23 April 2025                [Page 35]
 
-Internet-Draft  A publish-subscribe architecture for the      April 2024
+Internet-Draft  A publish-subscribe architecture for the    October 2024
 
 
    Marco offered comprehensive reviews and insightful guidance on the
@@ -1845,4 +2013,4 @@ Authors' Addresses
 
 
 
-Jimenez, et al.          Expires 20 October 2024               [Page 33]
+Jimenez, et al.           Expires 23 April 2025                [Page 36]
diff --git a/index.html b/index.html
index 2a9c719..28ed839 100644
--- a/index.html
+++ b/index.html
@@ -24,14 +24,6 @@ <h1>Editor's drafts for main branch of <a href="https://github.com/core-wg/coap-
         <td></td>
       </tr>
     </table>
-    <h2>Preview for branch <a href="ps-rev">ps-rev</a></h2>
-    <table id="branch-ps-rev">
-      <tr>
-        <td><a href="ps-rev/draft-ietf-core-coap-pubsub.html" class="html draft-ietf-core-coap-pubsub" title="A publish-subscribe architecture for the Constrained Application Protocol (CoAP) (HTML)">A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</a></td>
-        <td><a href="ps-rev/draft-ietf-core-coap-pubsub.txt" class="txt draft-ietf-core-coap-pubsub" title="A publish-subscribe architecture for the Constrained Application Protocol (CoAP) (Text)">plain text</a></td>
-        <td>same as main</td>
-      </tr>
-    </table>
     <script>
 window.onload = function() {
   var referrer_branch = 'main';
diff --git a/ps-rev/draft-ietf-core-coap-pubsub.html b/ps-rev/draft-ietf-core-coap-pubsub.html
deleted file mode 100644
index 510e41d..0000000
--- a/ps-rev/draft-ietf-core-coap-pubsub.html
+++ /dev/null
@@ -1,2803 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" class="Internet-Draft">
-<head>
-<meta charset="utf-8">
-<meta content="Common,Latin" name="scripts">
-<meta content="initial-scale=1.0" name="viewport">
-<title>A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</title>
-<meta content="Jaime Jimenez" name="author">
-<meta content="Michael Koster" name="author">
-<meta content="Ari Keranen" name="author">
-<meta content="
-       This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker. 
-    " name="description">
-<meta content="xml2rfc 3.21.0" name="generator">
-<meta content="draft-ietf-core-coap-pubsub-latest" name="ietf.draft">
-<!-- Generator version information:
-  xml2rfc 3.21.0
-    Python 3.11.9
-    ConfigArgParse 1.7
-    google-i18n-address 3.1.0
-    intervaltree 3.1.0
-    Jinja2 3.1.2
-    lxml 4.9.3
-    platformdirs 4.2.0
-    pycountry 22.3.5
-    PyYAML 6.0.1
-    requests 2.31.0
-    setuptools 68.2.2
-    six 1.16.0
-    wcwidth 0.2.13
--->
-<link href="draft-ietf-core-coap-pubsub.xml" rel="alternate" type="application/rfc+xml">
-<link href="#copyright" rel="license">
-<style type="text/css">@font-face {
-  font-family: 'Lora';
-  font-style: italic;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Italic'), local('Lora-Italic'), url('https://martinthomson.github.io/rfc-css/fonts/lora-italic-cyrillic-ext.woff2') format('woff2');
-  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: italic;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Italic'), local('Lora-Italic'), url('https://martinthomson.github.io/rfc-css/fonts/lora-italic-cyrillic-ext.woff2') format('woff2');
-  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: italic;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Italic'), local('Lora-Italic'), url('https://martinthomson.github.io/rfc-css/fonts/lora-italic-vietnamese.woff2') format('woff2');
-  unicode-range: U+0102-0103, U+0110-0111, U+1EA0-1EF9, U+20AB;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: italic;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Italic'), local('Lora-Italic'), url('https://martinthomson.github.io/rfc-css/fonts/lora-italic-latin-ext.woff2') format('woff2');
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-
-@font-face {
-  font-family: 'Lora';
-  font-style: italic;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Italic'), local('Lora-Italic'), url('https://martinthomson.github.io/rfc-css/fonts/lora-italic-latin.woff2') format('woff2');
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Regular'), local('Lora-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/lora-regular-cyrillic-ext.woff2') format('woff2');
-  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Regular'), local('Lora-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/lora-regular-cyrillic.woff2') format('woff2');
-  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Regular'), local('Lora-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/lora-regular-vietnamese.woff2') format('woff2');
-  unicode-range: U+0102-0103, U+0110-0111, U+1EA0-1EF9, U+20AB;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Regular'), local('Lora-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/lora-regular-latin-ext.woff2') format('woff2');
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Lora Regular'), local('Lora-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/lora-regular-latin.woff2') format('woff2');
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 700;
-  font-display: swap;
-  src: local('Lora Bold'), local('Lora-Bold'), url('https://martinthomson.github.io/rfc-css/fonts/lora-bold-cyrillic-ext.woff2') format('woff2');
-  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 700;
-  font-display: swap;
-  src: local('Lora Bold'), local('Lora-Bold'), url('https://martinthomson.github.io/rfc-css/fonts/lora-bold-cyrillic.woff2') format('woff2');
-  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 700;
-  font-display: swap;
-  src: local('Lora Bold'), local('Lora-Bold'), url('https://martinthomson.github.io/rfc-css/fonts/lora-bold-vietnamese.woff2') format('woff2');
-  unicode-range: U+0102-0103, U+0110-0111, U+1EA0-1EF9, U+20AB;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 700;
-  font-display: swap;
-  src: local('Lora Bold'), local('Lora-Bold'), url('https://martinthomson.github.io/rfc-css/fonts/lora-bold-latin-ext.woff2') format('woff2');
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 700;
-  font-display: swap;
-  src: local('Lora Bold'), local('Lora-Bold'), url('https://martinthomson.github.io/rfc-css/fonts/lora-bold-latin.woff2') format('woff2');
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-@font-face {
-  font-family: 'Lora';
-  font-style: normal;
-  font-weight: 600;
-  font-display: swap;
-  src: local('Lora SemiBold'), local('Lora-SemiBold'), url('https://martinthomson.github.io/rfc-css/fonts/lora-semibold-latin.woff2') format('woff2');
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-@font-face {
-  font-family: 'Cabin Condensed';
-  font-style: normal;
-  font-weight: 600;
-  font-display: swap;
-  src: local('Cabin Condensed SemiBold'), local('CabinCondensed-SemiBold'), url('https://martinthomson.github.io/rfc-css/fonts/cabincondensed-semibold-vietnamese.woff2') format('woff2');
-  unicode-range: U+0102-0103, U+0110-0111, U+1EA0-1EF9, U+20AB;
-}
-@font-face {
-  font-family: 'Cabin Condensed';
-  font-style: normal;
-  font-weight: 600;
-  font-display: swap;
-  src: local('Cabin Condensed SemiBold'), local('CabinCondensed-SemiBold'), url('https://martinthomson.github.io/rfc-css/fonts/cabincondensed-semibold-latin-ext.woff2') format('woff2');
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-@font-face {
-  font-family: 'Cabin Condensed';
-  font-style: normal;
-  font-weight: 600;
-  font-display: swap;
-  src: local('Cabin Condensed SemiBold'), local('CabinCondensed-SemiBold'), url('https://martinthomson.github.io/rfc-css/fonts/cabincondensed-semibold-latin.woff2') format('woff2');
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-@font-face {
-  font-family: 'Oxygen Mono';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Oxygen Mono'), local('OxygenMono-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/oxygenmono-regular-latin-ext.woff2') format('woff2');
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-@font-face {
-  font-family: 'Oxygen Mono';
-  font-style: normal;
-  font-weight: 400;
-  font-display: swap;
-  src: local('Oxygen Mono'), local('OxygenMono-Regular'), url('https://martinthomson.github.io/rfc-css/fonts/oxygenmono-regular-latin.woff2') format('woff2');
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-
-:root {
-  color-scheme: light dark;
-  --background-color: #fff;
-  --text-color: #222;
-  --title-color: #191919;
-  --link-color: #2a6496;
-  --highlight-color: #f9f9f9;
-  --line-color: #eee;
-  --pilcrow-weak: #ddd;
-  --pilcrow-strong: #bbb;
-  --small-font-size: 14.5px;
-  --font-mono: 'Oxygen Mono', monospace;
-  scrollbar-color: #bbb #eee;
-}
-body {
-  max-width: 600px;
-  margin: 75px auto;
-  padding: 0 5px;
-  color: var(--text-color);
-  background-color: var(--background-color);
-  font: 16px/22px "Lora", serif;
-  scroll-behavior: smooth;
-}
-
-.ears {
-  display: none;
-}
-
-/* headings */
-h1, h2, h3, h4, h5, h6 {
-  font-family: "Cabin Condensed", sans-serif;
-  font-weight: 600;
-  margin: 0.8em 0 0.3em;
-  font-size-adjust: 0.5;
-  color: var(--title-color);
-}
-h1#title {
-  font-size: 32px;
-  line-height: 40px;
-  clear: both;
-}
-h1#title, h1#rfcnum {
-  margin: 1.5em 0 0.2em;
-}
-h1#rfcnum + h1#title {
-  margin: 0.2em 0;
-}
-
-h1, h2, h3 {
-  font-size: 22px;
-  line-height: 27px;
-}
-h4, h5, h6 {
-  font-size: 20px;
-  line-height: 24px;
-}
-
-/* general structure */
-.author {
-  padding-bottom: 0.3em;
-}
-#abstract+p {
-  font-size: 18px;
-  line-height: 24px;
-}
-#abstract+p code, #abstract+p samp, #abstract+p tt {
-  font-size: 16px;
-  line-height: 0;
-}
-
-p {
-  padding: 0;
-  margin: 0.5em 0;
-  text-align: left;
-}
-div {
-  margin: 0;
-}
-.alignRight.art-text {
-  background-color: var(--highlight-color);
-  border: 1px solid var(--line-color);
-  border-radius: 3px;
-  padding: 0.5em 1em 0;
-  margin-bottom: 0.5em;
-}
-.alignRight.art-text pre {
-  padding: 0;
-  width: auto;
-}
-.alignRight {
-  margin: 1em 0;
-}
-.alignRight > *:first-child {
-  border: none;
-  margin: 0;
-  float: right;
-  clear: both;
-}
-.alignRight > *:nth-child(2) {
-  clear: both;
-  display: block;
-  border: none;
-}
-svg {
-  display: block;
-}
-/* font-family isn't space-separated, but =~ will have to do */
-svg[font-family~="monospace" i], svg [font-family~="monospace" i] {
-  font-family: var(--font-mono);
-}
-.alignCenter.art-text {
-  background-color: var(--highlight-color);
-  border: 1px solid var(--line-color);
-  border-radius: 3px;
-  padding: 0.5em 1em 0;
-  margin-bottom: 0.5em;
-}
-.alignCenter.art-text pre {
-  padding: 0;
-  width: auto;
-}
-.alignCenter {
-  margin: 1em 0;
-}
-.alignCenter > *:first-child {
-  border: none;
-  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
-     support flexbox yet.
-  */
-  display: table;
-  margin: 0 auto;
-}
-
-/* lists */
-ol, ul {
-  padding: 0;
-  margin: 0 0 0.5em 2em;
-}
-:is(ol, ul) :is(ol, ul) {
-  margin-left: 1em;
-}
-li {
-  margin: 0 0 0.25em 0;
-}
-.ulCompact li {
-  margin: 0;
-}
-ul.empty, .ulEmpty {
-  list-style-type: none;
-}
-ul.empty li, .ulEmpty li {
-  margin-top: 0.5em;
-}
-:is(ul, ol).compact, .ulCompact, .olCompact {
-  line-height: 1;
-  margin: 0 0 0 2em;
-}
-
-/* definition lists */
-dl {
-  clear: left;
-  --indent: 3ch;
-  /* --indent: attr(indent ch); not supported in any browser, but we can dream */
-}
-dl.olPercent {
-  --indent: 5ch;
-}
-dl > dt {
-  float: left;
-  margin-right: 2ch;
-  min-width: 8ch;
-}
-dl.dlNewline > dt {
-  float: none;
-}
-dl > dd {
-  margin-bottom: .8em;
-  margin-left: var(--indent) !important; /* stupid element overrides */
-  min-height: 2ex;
-}
-dl.olPercent > dt {
-  min-width: calc(var(--indent) - 2ch);
-}
-:is(dl.compact, .dlCompact) > dd {
-  margin-bottom: 0;
-}
-:is(dl.compact, .dlCompact) > dd > :is(:first-child, .break:first-child + *) {
-  margin-top: 0;
-}
-:is(dl.compact, .dlCompact) > dd > :is(:last-child) {
-  margin-bottom: 0;
-}
-dl > dd > dl {
-  margin-top: 0.5em;
-  margin-bottom: 0;
-}
-:is(dd, span).break {
-  display: none;
-}
-
-/* links */
-a, a[href].selfRef:hover {
-  text-decoration: none;
-}
-a[href] {
-  color: var(--link-color);
-}
-a[href].selfRef, .iref + a[href].internal {
-  color: var(--text-color);
-}
-a[href]:hover {
-  text-decoration: underline;
-}
-a[href].selfRef:hover {
-  background-color: var(--highlight-color);
-}
-a.xref:is(.cite, .auto), :is(#status-of-memo, #copyright) a {
-  white-space: nowrap;
-}
-
-/* Figures */
-tt, code, pre {
-  background-color: var(--highlight-color);
-  font: 14px/22px var(--font-mono);
-}
-tt, code {
-  /* changing the font for inline elements leads to different ascender
-     and descender heights; as we want to retain baseline alignment,
-     remove leading to avoid altering the final height of lines
-     note: this fails if these blocks take an entire line,
-     a different solution would be great */
-  line-height: 0;
-}
-:is(h1, h2, h3, h4, h5, h6) :is(tt, code) {
-  font-size: 84%;
-}
-pre {
-  border: 1px solid var(--line-color);
-  font-size: 13.5px;
-  line-height: 16px;
-  letter-spacing: -0.2px;
-  margin: 5px;
-  padding: 5px;
-}
-img {
-  max-width: 100%;
-}
-figure {
-  margin: 0.5em 0;
-  padding: 0;
-}
-figure blockquote {
-  margin: 0.8em 0.4em 0.4em;
-}
-figcaption, caption {
-  font-style: italic;
-  margin: 0.5em 1.5em;
-  text-align: left;
-}
-@media screen {
-  /* Auto-collapse boilerplate. */
-  :is(#status-of-memo, #copyright) p {
-    margin: -2px 0;
-    max-height: 0;
-    transition: max-height 2s ease, margin 0.5s ease 0.5s;
-    overflow: hidden;
-  }
-  :is(#status-of-memo, #copyright):hover p,
-  :is(#status-of-memo, #copyright) h2:target ~ p {
-    margin: 0.5em 0;
-    max-height: 500px;
-    overflow: auto;
-  }
-  pre, svg {
-    display: inline-block;
-    overflow-x: auto;
-  }
-  pre {
-    max-width: 100%;
-    width: calc(100% - 22px - 1em);
-  }
-  svg {
-    max-width: calc(100% - 22px - 1em);
-  }
-  figure pre {
-    display: block;
-    width: calc(100% - 25px);
-  }
-  :is(pre, svg) + .pilcrow {
-    display: inline-block;
-    vertical-align: text-bottom;
-    padding-bottom: 8px;
-  }
-}
-
-/* aside, blockquote */
-aside, blockquote {
-  margin-left: 0;
-  padding: 0 2em;
-  font-style: italic;
-}
-blockquote {
-  margin: 1em 0;
-}
-cite {
-  display: block;
-  text-align: right;
-  font-style: italic;
-}
-
-/* tables */
-table {
-  max-width: 100%;
-  margin: 0 0 1em;
-  border-collapse: collapse;
-}
-table.right {
-  margin-left: auto;
-}
-table.center {
-  margin-left: auto;
-  margin-right: auto;
-}
-table.left {
-  margin-right: auto;
-}
-thead, tbody {
-  border: 1px solid var(--line-color);
-}
-th, td {
-  text-align: left;
-  vertical-align: top;
-  padding: 5px 10px;
-}
-th {
-  background-color: var(--line-color);
-}
-:is(tr:nth-child(2n), thead+tbody > tr:nth-child(2n+1)) > td {
-  background-color: var(--background-color);
-}
-:is(tr:nth-child(2n+1), thead+tbody > tr:nth-child(2n)) > td {
-  background-color: var(--highlight-color);
-}
-table caption {
-  margin: 0;
-  padding: 3px 0 3px 1em;
-}
-table p {
-  margin: 0;
-}
-
-/* pilcrow */
-a.pilcrow {
-  margin-left: 3px;
-  opacity: 0.2;
-  user-select: none;
-}
-a.pilcrow[href] { color: var(--pilcrow-weak); }
-a.pilcrow[href]:hover { text-decoration: none; }
-@media not print {
-  :hover > a.pilcrow {
-    opacity: 1;
-  }
-  a.pilcrow[href]:hover {
-    color: var(--pilcrow-strong);
-    background-color: transparent;
-  }
-}
-@media print {
-  a.pilcrow {
-    display: none;
-  }
-}
-
-/* misc */
-hr {
-  border: 0;
-  border-top: 1px solid var(--line-color);
-}
-.bcp14 {
-  font-variant: small-caps;
-  font-weight: 600;
-  font-size: var(--small-font-size);
-}
-.role {
-  font-variant: all-small-caps;
-}
-sub, sup {
-  line-height: 1;
-  font-size: 80%;
-}
-
-/* info block */
-#identifiers {
-  margin: 0;
-  font-size: var(--small-font-size);
-  line-height: 18px;
-  --identifier-width: 15ch;
-}
-#identifiers dt {
-  width: var(--identifier-width);
-  min-width: var(--identifier-width);
-  clear: left;
-  float: left;
-  text-align: right;
-  margin-right: 1ch;
-}
-#identifiers dd {
-  margin: 0;
-  margin-left: calc(1em + var(--identifier-width)) !important;
-  min-width: 5em;
-}
-#identifiers .authors .author {
-  display: inline-block;
-  margin-right: 1.5em;
-}
-#identifiers .authors .org {
-  font-style: italic;
-}
-
-/* The prepared/rendered info at the very bottom of the page */
-.docInfo {
-  color: #999;
-  font-size: 0.9em;
-  font-style: italic;
-  margin-top: 2em;
-}
-.docInfo .prepared {
-  float: left;
-}
-.docInfo .prepared {
-  float: right;
-}
-
-/* table of contents */
-#toc {
-  padding: 0.75em 0 2em 0;
-  margin-bottom: 1em;
-}
-#toc nav ul {
-  margin: 0 0.5em 0 0;
-  padding: 0;
-  list-style: none;
-}
-#toc nav li {
-  line-height: 1.3em;
-  margin: 2px 0;
-  padding-left: 1.2em;
-  text-indent: -1.2em;
-}
-#toc a.xref {
-  white-space: normal;
-}
-/* references */
-.references dt {
-  text-align: right;
-  font-weight: bold;
-  min-width: 10ch;
-  margin-right: 1.5ch;
-}
-.references dt:target::before {
-  content: "⇒";
-  width: 15px;
-  margin: 0 10px 0 -25px;
-}
-.references dd {
-  margin-left: 12ch !important;
-  overflow: auto;
-}
-
-.refInstance {
-  margin-bottom: 1.25em;
-}
-
-.references .ascii {
-  margin-bottom: 0.25em;
-}
-
-/* index */
-#rfc\.index\.index + ul {
-  margin-left: 0;
-}
-
-/* authors */
-address.vcard {
-  font-style: normal;
-  margin: 1em 0;
-}
-address.vcard .nameRole {
-  font-weight: 700;
-  margin-left: 0;
-}
-address.vcard .label {
-  margin: 0.5em 0;
-}
-address.vcard .type {
-  display: none;
-}
-.alternative-contact {
-  margin: 1.5em 0 1em;
-}
-hr.addr {
-  border-top: 1px dashed;
-  margin: 0;
-  color: #ddd;
-  max-width: calc(100% - 16px);
-}
-@media (min-width: 500px) {
-  #authors-addresses > section {
-    column-count: 2;
-    column-gap: 20px;
-  }
-  #authors-addresses > section > h2 {
-    column-span: all;
-  }
-  /* hack for break-inside: avoid-column */
-  #authors-addresses address {
-    display: inline-block;
-    break-inside: avoid-column;
-  }
-}
-
-.rfcEditorRemove p:first-of-type {
-  font-style: italic;
-}
-.cref {
-  background-color: rgba(249, 232, 105, 0.3);
-  padding: 2px 4px;
-}
-.crefSource {
-  font-style: italic;
-}
-/* alternative layout for smaller screens */
-@media screen and (max-width: 929px) {
-  #toc {
-    position: fixed;
-    z-index: 2;
-    top: 0;
-    right: 0;
-    padding: 1px 0 0 0;
-    margin: 0;
-    border-bottom: 1px solid #ccc;
-    opacity: 0.6;
-  }
-  #toc.active {
-      opacity: 1;
-  }
-  #toc h2 {
-    margin: 0;
-    padding: 2px 0 2px 6px;
-    padding-right: 1em;
-    font-size: 18px;
-    line-height: 24px;
-    min-width: 190px;
-    text-align: right;
-    background-color: #444;
-    color: white;
-    cursor: pointer;
-  }
-  #toc h2::before { /* css hamburger */
-    float: right;
-    position: relative;
-    width: 1em;
-    height: 1px;
-    left: -164px;
-    margin: 8px 0 0 0;
-    background: white none repeat scroll 0 0;
-    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
-    content: "";
-  }
-  #toc nav {
-    display: none;
-    background-color: var(--background-color);
-    padding: 0.5em 1em 1em;
-    overflow: auto;
-    overscroll-behavior: contain;
-    height: calc(100vh - 48px);
-    border-left: 1px solid #ddd;
-  }
-  #toc.active nav {
-    display: block;
-  }
-  /* Make the collapsed ToC header render white on gray also when it's a link */
-  #toc h2 a,
-  #toc h2 a:link,
-  #toc h2 a:focus,
-  #toc h2 a:hover,
-  #toc a.toplink,
-  #toc a.toplink:hover {
-    color: white;
-    background-color: #444;
-    text-decoration: none;
-  }
-  #toc a.toplink {
-    margin-top: 2px;
-  }
-}
-
-/* alternative layout for wide screens */
-@media screen and (min-width: 930px) {
-  body {
-    padding-right: 360px;
-    padding-right: calc(min(180px + 20%, 500px));
-  }
-  #toc {
-    position: fixed;
-    bottom: 0;
-    right: 0;
-    right: calc(50vw - 480px);
-    width: 312px;
-    margin: 0;
-    padding: 0;
-    z-index: 1;
-  }
-  #toc h2 {
-    margin: 0;
-    padding: 0.25em 1em 1em 0;
-  }
-  #toc nav {
-    display: block;
-    height: calc(90vh - 84px);
-    bottom: 0;
-    padding: 0.5em 0 2em;
-    overflow: auto;
-    overscroll-behavior: contain;
-    scrollbar-width: thin;
-  }
-  #toc nav > ul  {
-    margin-bottom: 2em;
-  }
-  #toc ul {
-    margin: 0 0 0 4px;
-    font-size: var(--small-font-size);
-  }
-  #toc ul :is(p, li) {
-    margin: 2px 0;
-    line-height: 22px;
-  }
-  img { /* future proofing */
-    max-width: 100%;
-    height: auto;
-  }
-}
-
-/* pagination */
-@media print {
-  body {
-    width: 100%;
-  }
-  p {
-    orphans: 3;
-    widows: 3;
-  }
-  #n-copyright-notice {
-    border-bottom: none;
-  }
-  #toc, #n-introduction {
-    page-break-before: always;
-  }
-  #toc {
-    border-top: none;
-    padding-top: 0;
-  }
-  figure, pre, .vcard {
-    page-break-inside: avoid;
-  }
-  h1, h2, h3, h4, h5, h6 {
-    page-break-after: avoid;
-  }
-  :is(h2, h3, h4, h5, h6)+*, dd {
-    page-break-before: avoid;
-  }
-  pre {
-    white-space: pre-wrap;
-    word-wrap: break-word;
-    font-size: 10pt;
-  }
-  table {
-    border: 1px solid #ddd;
-  }
-  td {
-    border-top: 1px solid #ddd;
-  }
-  .toplink {
-    display: none;
-  }
-}
-
-@page :first {
-  padding-top: 0;
-  @top-left {
-    content: normal;
-    border: none;
-  }
-  @top-center {
-    content: normal;
-    border: none;
-  }
-  @top-right {
-    content: normal;
-    border: none;
-  }
-}
-
-@page {
-  size: A4;
-  margin-bottom: 45mm;
-  padding-top: 20px;
-}
-
-/* Changes introduced to fix issues found during implementation */
-
-/* Separate body from document info even without intervening H1 */
-section {
-  clear: both;
-}
-
-/* Top align author divs, to avoid names without organization dropping level with org names */
-.author {
-  vertical-align: top;
-}
-
-/* Style section numbers with more space between number and title */
-.section-number {
-  padding-right: 0.5em;
-}
-
-/* Add styling for a link in the ToC that points to the top of the document */
-a.toplink {
-  float: right;
-  margin: 8px 0.5em 0;
-}
-
-/* Provide styling for table cell text alignment */
-table .text-left {
-  text-align: left;
-}
-table .text-center {
-  text-align: center;
-}
-table .text-right {
-  text-align: right;
-}
-
-/* Make the alternative author contact information look less like just another
-   author, and group it closer with the primary author contact information */
-.alternative-contact {
-  margin: 0.5em 0 0.25em 0;
-}
-address .non-ascii {
-  margin: 0 0 0 2em;
-}
-
-/* With it being possible to set tables with alignment
-  left, center, and right, { width: 100%; } does not make sense */
-table {
-  width: auto;
-}
-
-/* Avoid reference text that sits in a block with very wide left margin,
-   because of a long floating dt label.*/
-.references dd {
-  overflow: visible;
-}
-
-/* Control caption placement */
-caption {
-  caption-side: bottom;
-}
-
-/* Limit the width of the author address vcard, so names in right-to-left
-   script don't end up on the other side of the page. */
-
-address.vcard {
-  max-width: 20em;
-  margin-right: auto;
-}
-
-/* For address alignment dependent on LTR or RTL scripts */
-address div.left {
-  text-align: left;
-}
-address div.right {
-  text-align: right;
-}
-
-/* Dark mode. */
-@media (prefers-color-scheme: dark) {
-:root {
-  --background-color: #121212;
-  --text-color: #f0f0f0;
-  --title-color: #fff;
-  --link-color: #4da4f0;
-  --highlight-color: #282828;
-  --line-color: #444;
-  --pilcrow-weak: #444;
-  --pilcrow-strong: #666;
-  scrollbar-color: #777 #333;
-}
-}
-
-/* SVG Trick: a prefix match works because only black and white are allowed */
-svg :is([stroke="black"], [stroke^="#000"]) {
-  stroke: var(--text-color);
-}
-svg :is([stroke="white"], [stroke^="#fff"]) {
-  stroke: var(--background-color);
-}
-svg :is([fill="black"], [fill^="#000"], :not([fill])) {
-  fill: var(--text-color);
-}
-svg :is([fill="white"], [fill^="#fff"]) {
-  fill: var(--background-color);
-}
-</style>
-
-</head>
-<body class="xml2rfc">
-<table class="ears">
-<thead><tr>
-<td class="left">Internet-Draft</td>
-<td class="center">A publish-subscribe architecture for the</td>
-<td class="right">April 2024</td>
-</tr></thead>
-<tfoot><tr>
-<td class="left">Jimenez, et al.</td>
-<td class="center">Expires 20 October 2024</td>
-<td class="right">[Page]</td>
-</tr></tfoot>
-</table>
-<div id="external-metadata" class="document-information"></div>
-<div id="internal-metadata" class="document-information">
-<dl id="identifiers">
-<dt class="label-workgroup">Workgroup:</dt>
-<dd class="workgroup">CoRE Working Group</dd>
-<dt class="label-internet-draft">Internet-Draft:</dt>
-<dd class="internet-draft">draft-ietf-core-coap-pubsub-latest</dd>
-<dt class="label-published">Published:</dt>
-<dd class="published">
-<time datetime="2024-04-18" class="published">18 April 2024</time>
-    </dd>
-<dt class="label-intended-status">Intended Status:</dt>
-<dd class="intended-status">Standards Track</dd>
-<dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2024-10-20">20 October 2024</time></dd>
-<dt class="label-authors">Authors:</dt>
-<dd class="authors">
-<div class="author">
-      <div class="author-name">J. Jimenez</div>
-<div class="org">Ericsson</div>
-</div>
-<div class="author">
-      <div class="author-name">M. Koster</div>
-<div class="org">Dogtiger Labs</div>
-</div>
-<div class="author">
-      <div class="author-name">A. Keranen</div>
-<div class="org">Ericsson</div>
-</div>
-</dd>
-</dl>
-</div>
-<h1 id="title">A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</h1>
-<section id="section-abstract">
-      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
-<p id="section-abstract-1">This document describes a publish-subscribe architecture for the Constrained Application Protocol (CoAP), extending the capabilities of CoAP communications for supporting endpoints with long breaks in connectivity and/or up-time. CoAP clients publish on and subscribe to a topic via a corresponding topic resource at a CoAP server acting as broker.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
-</section>
-<section class="note rfcEditorRemove" id="section-note.1">
-      <h2 id="name-about-this-document">
-<a href="#name-about-this-document" class="section-name selfRef">About This Document</a>
-      </h2>
-<p id="section-note.1-1">This note is to be removed before publishing as an RFC.<a href="#section-note.1-1" class="pilcrow">¶</a></p>
-<p id="section-note.1-2">
-        Status information for this document may be found at <span><a href="https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/">https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/</a></span>.<a href="#section-note.1-2" class="pilcrow">¶</a></p>
-<p id="section-note.1-3">
-        Discussion of this document takes place on the
-        core Working Group mailing list (<span><a href="mailto:core@ietf.org">mailto:core@ietf.org</a></span>),
-        which is archived at <span><a href="https://mailarchive.ietf.org/arch/browse/core/">https://mailarchive.ietf.org/arch/browse/core/</a></span>.
-        Subscribe at <span><a href="https://www.ietf.org/mailman/listinfo/core/">https://www.ietf.org/mailman/listinfo/core/</a></span>.<a href="#section-note.1-3" class="pilcrow">¶</a></p>
-<p id="section-note.1-4">Source for this draft and an issue tracker can be found at
-        <span><a href="https://github.com/core-wg/coap-pubsub">https://github.com/core-wg/coap-pubsub</a></span>.<a href="#section-note.1-4" class="pilcrow">¶</a></p>
-</section>
-<div id="status-of-memo">
-<section id="section-boilerplate.1">
-        <h2 id="name-status-of-this-memo">
-<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
-        </h2>
-<p id="section-boilerplate.1-1">
-        This Internet-Draft is submitted in full conformance with the
-        provisions of BCP 78 and BCP 79.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-2">
-        Internet-Drafts are working documents of the Internet Engineering Task
-        Force (IETF). Note that other groups may also distribute working
-        documents as Internet-Drafts. The list of current Internet-Drafts is
-        at <span><a href="https://datatracker.ietf.org/drafts/current/">https://datatracker.ietf.org/drafts/current/</a></span>.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-3">
-        Internet-Drafts are draft documents valid for a maximum of six months
-        and may be updated, replaced, or obsoleted by other documents at any
-        time. It is inappropriate to use Internet-Drafts as reference
-        material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 20 October 2024.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="copyright">
-<section id="section-boilerplate.2">
-        <h2 id="name-copyright-notice">
-<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
-        </h2>
-<p id="section-boilerplate.2-1">
-            Copyright (c) 2024 IETF Trust and the persons identified as the
-            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
-<p id="section-boilerplate.2-2">
-            This document is subject to BCP 78 and the IETF Trust's Legal
-            Provisions Relating to IETF Documents
-            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
-            publication of this document. Please review these documents
-            carefully, as they describe your rights and restrictions with
-            respect to this document. Code Components extracted from this
-            document must include Revised BSD License text as described in
-            Section 4.e of the Trust Legal Provisions and are provided without
-            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="toc">
-<section id="section-toc.1">
-        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
-<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
-        </h2>
-<nav class="toc"><ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
-            <p id="section-toc.1-1.1.1"><a href="#section-1" class="auto internal xref">1</a>.  <a href="#name-introduction" class="internal xref">Introduction</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
-                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="auto internal xref">1.1</a>.  <a href="#name-terminology" class="internal xref">Terminology</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
-                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="auto internal xref">1.2</a>.  <a href="#name-coap-publish-subscribe-arch" class="internal xref">CoAP Publish-Subscribe Architecture</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
-                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="auto internal xref">1.3</a>.  <a href="#name-managing-topics" class="internal xref">Managing Topics</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
-            <p id="section-toc.1-1.2.1"><a href="#section-2" class="auto internal xref">2</a>.  <a href="#name-pub-sub-topics" class="internal xref">Pub-Sub Topics</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
-                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="auto internal xref">2.1</a>.  <a href="#name-collection-representation" class="internal xref">Collection Representation</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
-                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="auto internal xref">2.2</a>.  <a href="#name-topic-configuration-represe" class="internal xref">Topic-Configuration Representation</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.1">
-                    <p id="section-toc.1-1.2.2.2.2.1.1"><a href="#section-2.2.1" class="auto internal xref">2.2.1</a>.  <a href="#name-topic-properties" class="internal xref">Topic Properties</a></p>
-</li>
-                </ul>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
-                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="auto internal xref">2.3</a>.  <a href="#name-discovery" class="internal xref">Discovery</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.1">
-                    <p id="section-toc.1-1.2.2.3.2.1.1"><a href="#section-2.3.1" class="auto internal xref">2.3.1</a>.  <a href="#name-broker-discovery" class="internal xref">Broker Discovery</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.2">
-                    <p id="section-toc.1-1.2.2.3.2.2.1"><a href="#section-2.3.2" class="auto internal xref">2.3.2</a>.  <a href="#name-topic-collection-discovery" class="internal xref">Topic Collection Discovery</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.3">
-                    <p id="section-toc.1-1.2.2.3.2.3.1"><a href="#section-2.3.3" class="auto internal xref">2.3.3</a>.  <a href="#name-topic-configuration-discove" class="internal xref">Topic-Configuration Discovery</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.4">
-                    <p id="section-toc.1-1.2.2.3.2.4.1"><a href="#section-2.3.4" class="auto internal xref">2.3.4</a>.  <a href="#name-topic-data-discovery" class="internal xref">Topic-Data Discovery</a></p>
-</li>
-                </ul>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
-                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="auto internal xref">2.4</a>.  <a href="#name-topic-collection-interactio" class="internal xref">Topic Collection Interactions</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4.2.1">
-                    <p id="section-toc.1-1.2.2.4.2.1.1"><a href="#section-2.4.1" class="auto internal xref">2.4.1</a>.  <a href="#name-retrieving-all-topic-config" class="internal xref">Retrieving all topic-configurations</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4.2.2">
-                    <p id="section-toc.1-1.2.2.4.2.2.1"><a href="#section-2.4.2" class="auto internal xref">2.4.2</a>.  <a href="#name-getting-topic-configuration" class="internal xref">Getting topic-configurations by Properties</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4.2.3">
-                    <p id="section-toc.1-1.2.2.4.2.3.1"><a href="#section-2.4.3" class="auto internal xref">2.4.3</a>.  <a href="#name-creating-a-topic" class="internal xref">Creating a Topic</a></p>
-</li>
-                </ul>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5">
-                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="auto internal xref">2.5</a>.  <a href="#name-topic-configuration-interac" class="internal xref">Topic-Configuration Interactions</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.1">
-                    <p id="section-toc.1-1.2.2.5.2.1.1"><a href="#section-2.5.1" class="auto internal xref">2.5.1</a>.  <a href="#name-getting-a-topic-configurati" class="internal xref">Getting a topic-configuration</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.2">
-                    <p id="section-toc.1-1.2.2.5.2.2.1"><a href="#section-2.5.2" class="auto internal xref">2.5.2</a>.  <a href="#name-getting-part-of-a-topic-con" class="internal xref">Getting part of a topic-configuration</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.3">
-                    <p id="section-toc.1-1.2.2.5.2.3.1"><a href="#section-2.5.3" class="auto internal xref">2.5.3</a>.  <a href="#name-updating-the-topic-configur" class="internal xref">Updating the topic-configuration</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.4">
-                    <p id="section-toc.1-1.2.2.5.2.4.1"><a href="#section-2.5.4" class="auto internal xref">2.5.4</a>.  <a href="#name-updating-the-topic-configura" class="internal xref">Updating the topic-configuration with iPATCH</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.5.2.5">
-                    <p id="section-toc.1-1.2.2.5.2.5.1"><a href="#section-2.5.5" class="auto internal xref">2.5.5</a>.  <a href="#name-deleting-a-topic-configurat" class="internal xref">Deleting a topic-configuration</a></p>
-</li>
-                </ul>
-</li>
-            </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
-            <p id="section-toc.1-1.3.1"><a href="#section-3" class="auto internal xref">3</a>.  <a href="#name-publish-and-subscribe" class="internal xref">Publish and Subscribe</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
-                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="auto internal xref">3.1</a>.  <a href="#name-topic-lifecycle" class="internal xref">Topic Lifecycle</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
-                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="auto internal xref">3.2</a>.  <a href="#name-topic-data-interactions" class="internal xref">Topic-Data Interactions</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.1">
-                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="auto internal xref">3.2.1</a>.  <a href="#name-publish" class="internal xref">Publish</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.2">
-                    <p id="section-toc.1-1.3.2.2.2.2.1"><a href="#section-3.2.2" class="auto internal xref">3.2.2</a>.  <a href="#name-subscribe" class="internal xref">Subscribe</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.3">
-                    <p id="section-toc.1-1.3.2.2.2.3.1"><a href="#section-3.2.3" class="auto internal xref">3.2.3</a>.  <a href="#name-unsubscribe" class="internal xref">Unsubscribe</a></p>
-</li>
-                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.4">
-                    <p id="section-toc.1-1.3.2.2.2.4.1"><a href="#section-3.2.4" class="auto internal xref">3.2.4</a>.  <a href="#name-delete-topic-data" class="internal xref">Delete topic-data</a></p>
-</li>
-                </ul>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
-                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="auto internal xref">3.3</a>.  <a href="#name-read-latest-data" class="internal xref">Read latest data</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
-                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="auto internal xref">3.4</a>.  <a href="#name-rate-limiting" class="internal xref">Rate Limiting</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
-            <p id="section-toc.1-1.4.1"><a href="#section-4" class="auto internal xref">4</a>.  <a href="#name-coap-pubsub-parameters" class="internal xref">CoAP Pubsub Parameters</a></p>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
-            <p id="section-toc.1-1.5.1"><a href="#section-5" class="auto internal xref">5</a>.  <a href="#name-security-considerations" class="internal xref">Security Considerations</a></p>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
-            <p id="section-toc.1-1.6.1"><a href="#section-6" class="auto internal xref">6</a>.  <a href="#name-iana-considerations" class="internal xref">IANA Considerations</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
-                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="auto internal xref">6.1</a>.  <a href="#name-media-type" class="internal xref">Media Type</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
-                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="auto internal xref">6.2</a>.  <a href="#name-content-format" class="internal xref">Content-Format</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
-                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="auto internal xref">6.3</a>.  <a href="#name-coap-pubsub-parameters-3" class="internal xref">CoAP Pubsub Parameters</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
-                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="auto internal xref">6.4</a>.  <a href="#name-resource-types" class="internal xref">Resource Types</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
-            <p id="section-toc.1-1.7.1"><a href="#section-7" class="auto internal xref"></a><a href="#name-acknowledgements" class="internal xref">Acknowledgements</a></p>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
-            <p id="section-toc.1-1.8.1"><a href="#section-8" class="auto internal xref"></a><a href="#name-references" class="internal xref">References</a></p>
-<ul class="compact toc ulBare ulEmpty">
-<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
-                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="auto internal xref"></a><a href="#name-normative-references" class="internal xref">Normative References</a></p>
-</li>
-              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
-                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="auto internal xref"></a><a href="#name-informative-references" class="internal xref">Informative References</a></p>
-</li>
-            </ul>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
-            <p id="section-toc.1-1.9.1"><a href="#appendix-A" class="auto internal xref"></a><a href="#name-contributors" class="internal xref">Contributors</a></p>
-</li>
-          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
-            <p id="section-toc.1-1.10.1"><a href="#appendix-B" class="auto internal xref"></a><a href="#name-authors-addresses" class="internal xref">Authors' Addresses</a></p>
-</li>
-        </ul>
-</nav>
-</section>
-</div>
-<div id="introduction">
-<section id="section-1">
-      <h2 id="name-introduction">
-<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
-      </h2>
-<p id="section-1-1">The Constrained Application Protocol (CoAP) <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> supports
-machine-to-machine communication across networks of constrained
-devices and constrained networks. CoAP uses a request/response model where clients make requests to servers in order to request actions on resources. Depending on the situation the same device may act either as a server, a client, or both.<a href="#section-1-1" class="pilcrow">¶</a></p>
-<p id="section-1-2">One important class of constrained devices includes devices that are intended to run for years from a small battery, or by scavenging energy from their environment. These devices have limited up-time because they spend most of their time in a sleeping state with no network connectivity. Another important class of nodes are devices with limited reachability due to middle-boxes like Network Address Translators (NATs) and firewalls.<a href="#section-1-2" class="pilcrow">¶</a></p>
-<p id="section-1-3">For these nodes, the client/server-oriented architecture of REST can be challenging when interactions are not initiated by the devices themselves. A publish/subscribe-oriented architecture where nodes exchange data via topics through a broker entity might fit these nodes better.<a href="#section-1-3" class="pilcrow">¶</a></p>
-<p id="section-1-4">This document applies the idea of broker-based publish-subscribe to Constrained RESTful Environments using CoAP. It defines a broker that allows to create, discover subscribe and publish on topics.<a href="#section-1-4" class="pilcrow">¶</a></p>
-<div id="terminology">
-<section id="section-1.1">
-        <h3 id="name-terminology">
-<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
-        </h3>
-<p id="section-1.1-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
-NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
-"MAY", and "OPTIONAL" in this document are to be interpreted as
-described in BCP 14 <span>[<a href="#RFC2119" class="cite xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="cite xref">RFC8174</a>]</span> when, and only when, they
-appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
-<p id="section-1.1-2">This specification requires readers to be familiar with all the terms and
-concepts that are discussed in <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span> and <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>. Readers
-should also be familiar with the terms and concepts discussed in
-<span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>, <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span> and <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. The URI template
-format <span>[<a href="#RFC6570" class="cite xref">RFC6570</a>]</span> is used to describe the REST API defined in
-this specification.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
-<p id="section-1.1-3">This specification makes use of the following terminology:<a href="#section-1.1-3" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlNewline" id="section-1.1-4">
-          <dt id="section-1.1-4.1">publish-subscribe (pub/sub):</dt>
-          <dd style="margin-left: 1.5em" id="section-1.1-4.2">
-            <p id="section-1.1-4.2.1">A message communication model where messages associated with specific topics are sent to a broker. Interested parties, i.e. subscribers, receive these topic-based messages from the broker without the original sender knowing the recipients. The broker handles matching and delivering these messages to the appropriate subscribers.<a href="#section-1.1-4.2.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-1.1-4.3">publishers and subscribers:</dt>
-          <dd style="margin-left: 1.5em" id="section-1.1-4.4">
-            <p id="section-1.1-4.4.1">CoAP clients can act as publishers or as subscribers. Publishers send CoAP messages (publications) to the broker on specific topics. Subscribers have an ongoing observation relation (subscription) to a topic. Both roles operate without any mutual knowledge, guided by their respective topic interests.<a href="#section-1.1-4.4.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-1.1-4.5">topic collection:</dt>
-          <dd style="margin-left: 1.5em" id="section-1.1-4.6">
-            <p id="section-1.1-4.6.1">A set of topic configurations. A topic collection is hosted as one collection resource at the broker, and its representation is the list of links to the topic resources corresponding to each topic configuration.<a href="#section-1.1-4.6.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-1.1-4.7">topic-configuration:</dt>
-          <dd style="margin-left: 1.5em" id="section-1.1-4.8">
-            <p id="section-1.1-4.8.1">A set of information concerning a topic, including its configuration and other metadata. A topic configuration is hosted as one topic resource at the broker, and its representation is the set of configuration information concerning the topic. All the topic resources associated with the same topic collection share a common base URI, i.e., the URI of the collection resource. Throughout this document the word "topic" and "topic-configuration" can be used interchangeably.<a href="#section-1.1-4.8.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-1.1-4.9">topic-data resource:</dt>
-          <dd style="margin-left: 1.5em" id="section-1.1-4.10">
-            <p id="section-1.1-4.10.1">A resource where clients can publish data and/or subscribe to data for a specific topic. The representation of the topic resource corresponding to such a topic also specifies the URI to the present topic-data resource.<a href="#section-1.1-4.10.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-1.1-4.11">broker:</dt>
-          <dd style="margin-left: 1.5em" id="section-1.1-4.12">
-            <p id="section-1.1-4.12.1">A CoAP server that hosts one or more topic collections with their topic-configurations, and also topic-data resources. The broker is responsible for the store-and-forward of state update representations, for the topics for which it hosts the corresponding topic-data resources. The broker is also responsible of handling the topic lifecycle as defined in <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>. The creation, configuration, and discovery of topics at a broker is specified in <a href="#topics" class="auto internal xref">Section 2</a>.<a href="#section-1.1-4.12.1" class="pilcrow">¶</a></p>
-</dd>
-        <dd class="break"></dd>
-</dl>
-</section>
-</div>
-<div id="coap-publish-subscribe-architecture">
-<section id="section-1.2">
-        <h3 id="name-coap-publish-subscribe-arch">
-<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-coap-publish-subscribe-arch" class="section-name selfRef">CoAP Publish-Subscribe Architecture</a>
-        </h3>
-<p id="section-1.2-1"><a href="#fig-arch" class="auto internal xref">Figure 1</a> shows a simple Publish/Subscribe architecture over CoAP.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
-<p id="section-1.2-2">Topics are created by the broker, but the initial configuration can be proposed by a client (e.g., a publisher or a dedicated administrator) over the RESTful interface of a corresponding topic resource hosted by the broker.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
-<p id="section-1.2-3">Publishers submit their data over the RESTful interface of a topic-data resource corresponding to the topic, which may be hosted by the broker. Subscribers to a topic are notified of new publications by using Observe <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> on the corresponding topic-data resource.<a href="#section-1.2-3" class="pilcrow">¶</a></p>
-<p id="section-1.2-4">The broker is responsible for the store-and-forward of state update representations between CoAP clients. Subscribers observing a resource will receive notifications, the delivery of which is done on a best-effort basis.<a href="#section-1.2-4" class="pilcrow">¶</a></p>
-<span id="name-publish-subscribe-architect"></span><div id="fig-arch">
-<figure id="figure-1">
-          <div id="section-1.2-5.1">
-            <div class="alignCenter art-svg artwork" id="section-1.2-5.1.1">
-<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="272" width="488" viewBox="0 0 488 272" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
-                <path d="M 8,64 L 8,128" fill="none" stroke="black"></path>
-                <path d="M 8,176 L 8,240" fill="none" stroke="black"></path>
-                <path d="M 104,64 L 104,128" fill="none" stroke="black"></path>
-                <path d="M 104,176 L 104,240" fill="none" stroke="black"></path>
-                <path d="M 192,64 L 192,240" fill="none" stroke="black"></path>
-                <path d="M 280,64 L 280,240" fill="none" stroke="black"></path>
-                <path d="M 376,64 L 376,128" fill="none" stroke="black"></path>
-                <path d="M 376,176 L 376,240" fill="none" stroke="black"></path>
-                <path d="M 480,64 L 480,128" fill="none" stroke="black"></path>
-                <path d="M 480,176 L 480,240" fill="none" stroke="black"></path>
-                <path d="M 8,64 L 104,64" fill="none" stroke="black"></path>
-                <path d="M 192,64 L 280,64" fill="none" stroke="black"></path>
-                <path d="M 376,64 L 480,64" fill="none" stroke="black"></path>
-                <path d="M 288,80 L 376,80" fill="none" stroke="black"></path>
-                <path d="M 104,96 L 184,96" fill="none" stroke="black"></path>
-                <path d="M 280,96 L 368,96" fill="none" stroke="black"></path>
-                <path d="M 280,112 L 368,112" fill="none" stroke="black"></path>
-                <path d="M 8,128 L 104,128" fill="none" stroke="black"></path>
-                <path d="M 376,128 L 480,128" fill="none" stroke="black"></path>
-                <path d="M 8,176 L 104,176" fill="none" stroke="black"></path>
-                <path d="M 376,176 L 480,176" fill="none" stroke="black"></path>
-                <path d="M 288,192 L 376,192" fill="none" stroke="black"></path>
-                <path d="M 104,208 L 184,208" fill="none" stroke="black"></path>
-                <path d="M 280,208 L 368,208" fill="none" stroke="black"></path>
-                <path d="M 280,224 L 368,224" fill="none" stroke="black"></path>
-                <path d="M 8,240 L 104,240" fill="none" stroke="black"></path>
-                <path d="M 192,240 L 280,240" fill="none" stroke="black"></path>
-                <path d="M 376,240 L 480,240" fill="none" stroke="black"></path>
-                <polygon class="arrowhead" points="376,224 364,218.4 364,229.6" fill="black" transform="rotate(0,368,224)"></polygon>
-                <polygon class="arrowhead" points="376,208 364,202.4 364,213.6" fill="black" transform="rotate(0,368,208)"></polygon>
-                <polygon class="arrowhead" points="376,112 364,106.4 364,117.6" fill="black" transform="rotate(0,368,112)"></polygon>
-                <polygon class="arrowhead" points="376,96 364,90.4 364,101.6" fill="black" transform="rotate(0,368,96)"></polygon>
-                <polygon class="arrowhead" points="296,192 284,186.4 284,197.6" fill="black" transform="rotate(180,288,192)"></polygon>
-                <polygon class="arrowhead" points="296,80 284,74.4 284,85.6" fill="black" transform="rotate(180,288,80)"></polygon>
-                <polygon class="arrowhead" points="192,208 180,202.4 180,213.6" fill="black" transform="rotate(0,184,208)"></polygon>
-                <polygon class="arrowhead" points="192,96 180,90.4 180,101.6" fill="black" transform="rotate(0,184,96)"></polygon>
-                <g class="text">
-                  <text x="36" y="36">CoAP</text>
-                  <text x="244" y="36">CoAP</text>
-                  <text x="412" y="36">CoAP</text>
-                  <text x="48" y="52">clients</text>
-                  <text x="244" y="52">server</text>
-                  <text x="424" y="52">clients</text>
-                  <text x="328" y="68">observe</text>
-                  <text x="144" y="84">publish</text>
-                  <text x="56" y="100">publisher</text>
-                  <text x="428" y="100">subscriber</text>
-                  <text x="56" y="148">...</text>
-                  <text x="236" y="148">broker</text>
-                  <text x="424" y="148">...</text>
-                  <text x="56" y="164">...</text>
-                  <text x="424" y="164">...</text>
-                  <text x="328" y="180">observe</text>
-                  <text x="144" y="196">publish</text>
-                  <text x="56" y="212">publisher</text>
-                  <text x="428" y="212">subscriber</text>
-                </g>
-              </svg><a href="#section-1.2-5.1.1" class="pilcrow">¶</a>
-</div>
-</div>
-<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
-<a href="#name-publish-subscribe-architect" class="selfRef">Publish-subscribe architecture over CoAP</a>
-          </figcaption></figure>
-</div>
-<p id="section-1.2-6">This document describes two sets of interactions, interactions to configure topics and their lifecycle (see <a href="#topic-configuration-interactions" class="auto internal xref">Section 2.5</a>) and interactions about the topic-data (see <a href="#topic-data-interactions" class="auto internal xref">Section 3.2</a>).<a href="#section-1.2-6" class="pilcrow">¶</a></p>
-<p id="section-1.2-7">Topic-configuration interactions are discovery, create, read configuration, update configuration, and delete configuration. These operations handle the management of the topics.<a href="#section-1.2-7" class="pilcrow">¶</a></p>
-<p id="section-1.2-8">Topic-data interactions are publish, subscribe, unsubscribe, read, and delete. These operations are oriented on how data is transferred from a publisher to a subscriber.<a href="#section-1.2-8" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="managing-topics">
-<section id="section-1.3">
-        <h3 id="name-managing-topics">
-<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-managing-topics" class="section-name selfRef">Managing Topics</a>
-        </h3>
-<p id="section-1.3-1"><a href="#fig-api" class="auto internal xref">Figure 2</a> shows the resources related to a Topic Collection that can be managed at the Broker.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
-<span id="name-resources-of-a-broker"></span><div id="fig-api">
-<figure id="figure-2">
-          <div id="section-1.3-2.1">
-            <div class="alignCenter art-svg artwork" id="section-1.3-2.1.1">
-<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="176" width="496" viewBox="0 0 496 176" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
-                <path d="M 92,56 L 100,72" fill="none" stroke="black"></path>
-                <path d="M 148,136 L 156,152" fill="none" stroke="black"></path>
-                <path d="M 136,80 L 156,120" fill="none" stroke="black"></path>
-                <path d="M 124,40 L 132,56" fill="none" stroke="black"></path>
-                <path d="M 180,120 L 188,136" fill="none" stroke="black"></path>
-                <path d="M 212,136 L 220,152" fill="none" stroke="black"></path>
-                <path d="M 212,104 L 220,120" fill="none" stroke="black"></path>
-                <path d="M 244,120 L 252,136" fill="none" stroke="black"></path>
-                <path d="M 308,136 L 316,152" fill="none" stroke="black"></path>
-                <path d="M 308,104 L 316,120" fill="none" stroke="black"></path>
-                <path d="M 340,120 L 348,136" fill="none" stroke="black"></path>
-                <path d="M 92,56 L 100,40" fill="none" stroke="black"></path>
-                <path d="M 124,72 L 132,56" fill="none" stroke="black"></path>
-                <path d="M 148,136 L 156,120" fill="none" stroke="black"></path>
-                <path d="M 180,152 L 188,136" fill="none" stroke="black"></path>
-                <path d="M 212,136 L 220,120" fill="none" stroke="black"></path>
-                <path d="M 244,152 L 252,136" fill="none" stroke="black"></path>
-                <path d="M 308,136 L 316,120" fill="none" stroke="black"></path>
-                <path d="M 340,152 L 348,136" fill="none" stroke="black"></path>
-                <path d="M 100,40 L 124,40" fill="none" stroke="black"></path>
-                <path d="M 100,72 L 124,72" fill="none" stroke="black"></path>
-                <path d="M 148,104 L 308,104" fill="none" stroke="black"></path>
-                <path d="M 156,120 L 180,120" fill="none" stroke="black"></path>
-                <path d="M 220,120 L 244,120" fill="none" stroke="black"></path>
-                <path d="M 316,120 L 340,120" fill="none" stroke="black"></path>
-                <path d="M 156,152 L 180,152" fill="none" stroke="black"></path>
-                <path d="M 220,152 L 244,152" fill="none" stroke="black"></path>
-                <path d="M 316,152 L 340,152" fill="none" stroke="black"></path>
-                <g class="text">
-                  <text x="40" y="52">topic</text>
-                  <text x="44" y="68">collection</text>
-                  <text x="44" y="84">resource</text>
-                  <text x="280" y="132">...</text>
-                  <text x="392" y="132">topic</text>
-                  <text x="456" y="132">resources</text>
-                </g>
-              </svg><a href="#section-1.3-2.1.1" class="pilcrow">¶</a>
-</div>
-</div>
-<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
-<a href="#name-resources-of-a-broker" class="selfRef">Resources of a Broker</a>
-          </figcaption></figure>
-</div>
-<p id="section-1.3-3">The Broker exports one or more topic-collection resources, with resource type "core.ps.coll" defined in <a href="#iana" class="auto internal xref">Section 6</a> of this document. The interfaces for the topic-collection resource is defined in <a href="#topic-collection-interactions" class="auto internal xref">Section 2.4</a>.<a href="#section-1.3-3" class="pilcrow">¶</a></p>
-<p id="section-1.3-4">A topic-collection resource can have topic resources as its child resources, with resource type "core.ps.conf".<a href="#section-1.3-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="topics">
-<section id="section-2">
-      <h2 id="name-pub-sub-topics">
-<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-pub-sub-topics" class="section-name selfRef">Pub-Sub Topics</a>
-      </h2>
-<p id="section-2-1">The configuration side of a "publish/subscribe broker" consists of a collection of topics. These topics as well as the collection itself are exposed by a CoAP server as resources (see <a href="#fig-topic" class="auto internal xref">Figure 3</a>). Each topic is associated with a topic configuration resource and a topic-data resource. The topic configuration resource is used by a client creating or administering a topic. The topic-data resource is used by the publishers and the subscribers to a topic.<a href="#section-2-1" class="pilcrow">¶</a></p>
-<span id="name-topic-and-topic-data-resour"></span><div id="fig-topic">
-<figure id="figure-3">
-        <div id="section-2-2.1">
-          <div class="alignCenter art-svg artwork" id="section-2-2.1.1">
-<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="336" width="448" viewBox="0 0 448 336" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
-              <path d="M 184,152 L 184,232" fill="none" stroke="black"></path>
-              <path d="M 272,152 L 272,232" fill="none" stroke="black"></path>
-              <path d="M 400,152 L 400,232" fill="none" stroke="black"></path>
-              <path d="M 164,248 L 172,264" fill="none" stroke="black"></path>
-              <path d="M 92,56 L 100,72" fill="none" stroke="black"></path>
-              <path d="M 164,168 L 172,184" fill="none" stroke="black"></path>
-              <path d="M 196,232 L 204,248" fill="none" stroke="black"></path>
-              <path d="M 228,280 L 236,296" fill="none" stroke="black"></path>
-              <path d="M 136,80 L 172,152" fill="none" stroke="black"></path>
-              <path d="M 124,40 L 132,56" fill="none" stroke="black"></path>
-              <path d="M 196,152 L 204,168" fill="none" stroke="black"></path>
-              <path d="M 252,248 L 260,264" fill="none" stroke="black"></path>
-              <path d="M 252,168 L 260,184" fill="none" stroke="black"></path>
-              <path d="M 284,232 L 292,248" fill="none" stroke="black"></path>
-              <path d="M 236,104 L 260,152" fill="none" stroke="black"></path>
-              <path d="M 284,152 L 292,168" fill="none" stroke="black"></path>
-              <path d="M 380,248 L 388,264" fill="none" stroke="black"></path>
-              <path d="M 380,168 L 388,184" fill="none" stroke="black"></path>
-              <path d="M 412,232 L 420,248" fill="none" stroke="black"></path>
-              <path d="M 364,104 L 388,152" fill="none" stroke="black"></path>
-              <path d="M 412,152 L 420,168" fill="none" stroke="black"></path>
-              <path d="M 92,56 L 100,40" fill="none" stroke="black"></path>
-              <path d="M 124,72 L 132,56" fill="none" stroke="black"></path>
-              <path d="M 164,168 L 172,152" fill="none" stroke="black"></path>
-              <path d="M 164,248 L 172,232" fill="none" stroke="black"></path>
-              <path d="M 196,184 L 204,168" fill="none" stroke="black"></path>
-              <path d="M 196,264 L 204,248" fill="none" stroke="black"></path>
-              <path d="M 252,168 L 260,152" fill="none" stroke="black"></path>
-              <path d="M 220,296 L 228,280" fill="none" stroke="black"></path>
-              <path d="M 252,248 L 260,232" fill="none" stroke="black"></path>
-              <path d="M 284,184 L 292,168" fill="none" stroke="black"></path>
-              <path d="M 284,264 L 292,248" fill="none" stroke="black"></path>
-              <path d="M 380,168 L 388,152" fill="none" stroke="black"></path>
-              <path d="M 380,248 L 388,232" fill="none" stroke="black"></path>
-              <path d="M 412,184 L 420,168" fill="none" stroke="black"></path>
-              <path d="M 412,264 L 420,248" fill="none" stroke="black"></path>
-              <path d="M 100,40 L 124,40" fill="none" stroke="black"></path>
-              <path d="M 100,72 L 124,72" fill="none" stroke="black"></path>
-              <path d="M 148,104 L 364,104" fill="none" stroke="black"></path>
-              <path d="M 172,152 L 196,152" fill="none" stroke="black"></path>
-              <path d="M 260,152 L 284,152" fill="none" stroke="black"></path>
-              <path d="M 388,152 L 412,152" fill="none" stroke="black"></path>
-              <path d="M 172,264 L 196,264" fill="none" stroke="black"></path>
-              <path d="M 260,264 L 284,264" fill="none" stroke="black"></path>
-              <path d="M 388,264 L 412,264" fill="none" stroke="black"></path>
-              <path d="M 148,296 L 220,296" fill="none" stroke="black"></path>
-              <path d="M 236,296 L 308,296" fill="none" stroke="black"></path>
-              <path d="M 364,296 L 436,296" fill="none" stroke="black"></path>
-              <circle cx="184" cy="160" r="6" class="closeddot" fill="black"></circle>
-              <circle cx="272" cy="160" r="6" class="closeddot" fill="black"></circle>
-              <circle cx="400" cy="160" r="6" class="closeddot" fill="black"></circle>
-              <g class="text">
-                <text x="40" y="52">topic</text>
-                <text x="44" y="68">collection</text>
-                <text x="44" y="84">resource</text>
-                <text x="196" y="132">......</text>
-                <text x="284" y="132">......</text>
-                <text x="412" y="132">......</text>
-                <text x="112" y="148">topic</text>
-                <text x="152" y="148">:</text>
-                <text x="216" y="148">:</text>
-                <text x="240" y="148">:</text>
-                <text x="304" y="148">:</text>
-                <text x="368" y="148">:</text>
-                <text x="432" y="148">:</text>
-                <text x="80" y="164">configuration</text>
-                <text x="152" y="164">:</text>
-                <text x="216" y="164">:</text>
-                <text x="240" y="164">:</text>
-                <text x="304" y="164">:</text>
-                <text x="368" y="164">:</text>
-                <text x="432" y="164">:</text>
-                <text x="100" y="180">resource</text>
-                <text x="152" y="180">:</text>
-                <text x="176" y="180">_</text>
-                <text x="192" y="180">_</text>
-                <text x="216" y="180">:</text>
-                <text x="240" y="180">:</text>
-                <text x="264" y="180">_</text>
-                <text x="280" y="180">_</text>
-                <text x="304" y="180">:</text>
-                <text x="368" y="180">:</text>
-                <text x="392" y="180">_</text>
-                <text x="408" y="180">_</text>
-                <text x="432" y="180">:</text>
-                <text x="164" y="196">....</text>
-                <text x="204" y="196">....</text>
-                <text x="252" y="196">....</text>
-                <text x="292" y="196">....</text>
-                <text x="380" y="196">....</text>
-                <text x="420" y="196">....</text>
-                <text x="164" y="212">....</text>
-                <text x="204" y="212">....</text>
-                <text x="252" y="212">....</text>
-                <text x="292" y="212">....</text>
-                <text x="380" y="212">....</text>
-                <text x="420" y="212">....</text>
-                <text x="152" y="228">:</text>
-                <text x="176" y="228">_</text>
-                <text x="192" y="228">_</text>
-                <text x="216" y="228">:</text>
-                <text x="240" y="228">:</text>
-                <text x="264" y="228">_</text>
-                <text x="280" y="228">_</text>
-                <text x="304" y="228">:</text>
-                <text x="336" y="228">...</text>
-                <text x="368" y="228">:</text>
-                <text x="392" y="228">_</text>
-                <text x="408" y="228">_</text>
-                <text x="432" y="228">:</text>
-                <text x="92" y="244">topic-data</text>
-                <text x="152" y="244">:</text>
-                <text x="216" y="244">:</text>
-                <text x="240" y="244">:</text>
-                <text x="304" y="244">:</text>
-                <text x="368" y="244">:</text>
-                <text x="432" y="244">:</text>
-                <text x="100" y="260">resource</text>
-                <text x="152" y="260">:</text>
-                <text x="216" y="260">:</text>
-                <text x="240" y="260">:</text>
-                <text x="304" y="260">:</text>
-                <text x="368" y="260">:</text>
-                <text x="432" y="260">:</text>
-                <text x="184" y="276">:.......:</text>
-                <text x="272" y="276">:.......:</text>
-                <text x="400" y="276">:.......:</text>
-                <text x="144" y="292">\</text>
-                <text x="312" y="292">/</text>
-                <text x="336" y="292">...</text>
-                <text x="360" y="292">\</text>
-                <text x="440" y="292">/</text>
-                <text x="176" y="308">topic</text>
-                <text x="208" y="308">1</text>
-                <text x="264" y="308">topic</text>
-                <text x="296" y="308">2</text>
-                <text x="392" y="308">topic</text>
-                <text x="424" y="308">n</text>
-              </g>
-            </svg><a href="#section-2-2.1.1" class="pilcrow">¶</a>
-</div>
-</div>
-<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
-<a href="#name-topic-and-topic-data-resour" class="selfRef">Topic and topic-data resources of a topic</a>
-        </figcaption></figure>
-</div>
-<div id="collection-representation">
-<section id="section-2.1">
-        <h3 id="name-collection-representation">
-<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-collection-representation" class="section-name selfRef">Collection Representation</a>
-        </h3>
-<p id="section-2.1-1">Each topic configuration is represented as a link, where the link target is the URI of the corresponding topic resource.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
-<p id="section-2.1-2">Publication and subscription to a topic occur at a link, where the link target is the URI of the corresponding topic-data resource. Such a link is specified by the topic-data entry within the topic resource (see <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>).<a href="#section-2.1-2" class="pilcrow">¶</a></p>
-<p id="section-2.1-3">A topic resource with a topic-data link can also be simply called "topic".<a href="#section-2.1-3" class="pilcrow">¶</a></p>
-<p id="section-2.1-4">The list of links to the topic resources can be retrieved from the associated topic collection resource, and represented as a Link Format document <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>where each such link specifies the link target attribute 'rt' (Resource Type), with value "core.ps.conf" defined in this document.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="topic-resource-representation">
-<section id="section-2.2">
-        <h3 id="name-topic-configuration-represe">
-<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-topic-configuration-represe" class="section-name selfRef">Topic-Configuration Representation</a>
-        </h3>
-<p id="section-2.2-1">A CoAP client can create a new topic by submitting an initial configuration for the topic (see <a href="#topic-create" class="auto internal xref">Section 2.4.3</a>). It can also read and update the configuration of existing topics and delete them when they are no longer needed (see <a href="#topic-configuration-interactions" class="auto internal xref">Section 2.5</a>).<a href="#section-2.2-1" class="pilcrow">¶</a></p>
-<p id="section-2.2-2">The configuration of a topic itself consists of a set of properties that can be set by a client or by the broker. The topic-configuration is represented as a CBOR map containing the configuration properties of the topic as top-level elements.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
-<p id="section-2.2-3">Unless specified otherwise, these are defined in this document and their CBOR abbreviations are defined in <a href="#pubsub-parameters" class="auto internal xref">Section 4</a>.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
-<div id="topic-properties">
-<section id="section-2.2.1">
-          <h4 id="name-topic-properties">
-<a href="#section-2.2.1" class="section-number selfRef">2.2.1. </a><a href="#name-topic-properties" class="section-name selfRef">Topic Properties</a>
-          </h4>
-<p id="section-2.2.1-1">The CBOR map includes the following configuration parameters, whose CBOR abbreviations are defined in <a href="#pubsub-parameters" class="auto internal xref">Section 4</a> of this document.<a href="#section-2.2.1-1" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-2.2.1-2.1">
-              <p id="section-2.2.1-2.1.1">'topic-name': A required field used as an application identifier. It encodes the topic name as a CBOR text string. Examples of topic names include human-readable strings (e.g., "room2"), UUIDs, or other values.<a href="#section-2.2.1-2.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.2.1-2.2">
-              <p id="section-2.2.1-2.2.1">'topic-data': A required field (optional during creation) containing the URI of the topic-data resource for publishing/subscribing to this topic. It encodes the URI as a CBOR text string.<a href="#section-2.2.1-2.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.2.1-2.3">
-              <p id="section-2.2.1-2.3.1">'resource-type': A required field used to indicate the resource type of the topic-data resource for the topic. It encodes the resource type as a CBOR text string. The value should be "core.ps.conf".<a href="#section-2.2.1-2.3.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-<ul class="normal">
-<li class="normal" id="section-2.2.1-3.1">
-              <p id="section-2.2.1-3.1.1">'media-type': An optional field used to indicate the media type of the topic-data resource for the topic. It encodes the media type as a this information as the integer identifier of the CoAP content-format (e.g., value is "50" for "application/json").<a href="#section-2.2.1-3.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.2.1-3.2">
-              <p id="section-2.2.1-3.2.1">'topic-type': An optional field used to indicate the attribute or property of the topic-data resource for the topic. It encodes the attribute as a CBOR text string. Example attributes include "temperature".<a href="#section-2.2.1-3.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.2.1-3.3">
-              <p id="section-2.2.1-3.3.1">'expiration-date': An optional field used to indicate the expiration date of the topic. It encodes the expiration date as a CBOR text string. The value should be a date string in ISO 8601 format (e.g., "2023-03-31T23:59:59Z"). The broker can use this field to automatically remove topics that are no longer valid. If this field is not present, the topic will not expire automatically.<a href="#section-2.2.1-3.3.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.2.1-3.4">
-              <p id="section-2.2.1-3.4.1">'max-subscribers': An optional field used to indicate the maximum number of simultaneous subscribers allowed for the topic. It encodes the maximum number as an unsigned CBOR integer. If this field is not present, there is no limit to the number of simultaneous subscribers allowed. The broker can use this field to limit the number of subscribers for the topic. The default value for this field has been set to 100 subscribers.<a href="#section-2.2.1-3.4.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.2.1-3.5">
-              <p id="section-2.2.1-3.5.1">'observer-check': An optional field that controls the maximum number of seconds between two consecutive Observe notifications sent as Confirmable messages to each topic subscriber. Encoded as a CBOR unsigned integer greater than 0, it ensures subscribers who have lost interest and silently forgotten the observation do not remain indefinitely on the server's observer list. If another CoAP server hosts the topic-data resource, that server is responsible for applying the observer-check value. The default value for this field is 86400, as defined in <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>, which corresponds to 24 hours.<a href="#section-2.2.1-3.5.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-</section>
-</div>
-</section>
-</div>
-<div id="discovery">
-<section id="section-2.3">
-        <h3 id="name-discovery">
-<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-discovery" class="section-name selfRef">Discovery</a>
-        </h3>
-<p id="section-2.3-1">A client can perform a discovery of: the broker; the topic collection resources and topic resources hosted by the broker; and the topic-data resources associated with those topic resources.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
-<div id="broker-discovery">
-<section id="section-2.3.1">
-          <h4 id="name-broker-discovery">
-<a href="#section-2.3.1" class="section-number selfRef">2.3.1. </a><a href="#name-broker-discovery" class="section-name selfRef">Broker Discovery</a>
-          </h4>
-<p id="section-2.3.1-1">CoAP clients MAY discover brokers by using CoAP Simple Discovery, via multicast, through a Resource Directory (RD) <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span> or by other means specified in extensions to <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span>. Brokers MAY register with a RD by following the steps on Section 5 of <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span> with the resource type set to "core.ps" as defined in <a href="#iana" class="auto internal xref">Section 6</a> of this document.<a href="#section-2.3.1-1" class="pilcrow">¶</a></p>
-<p id="section-2.3.1-2">The following example shows an endpoint discovering a broker using the "core.ps" resource type over a multicast network. Brokers within the multicast scope will answer the query.<a href="#section-2.3.1-2" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.3.1-3">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: coap://[ff0x::fe]/.well-known/core
-   Resource-Type: core.ps
-
-&lt;= 2.05 Content
-   Payload:
-   Content-Format: 40 (application/link-format)
-   &lt;coap://mythinguri.com/broker/v1&gt;; rt=core.ps
-</pre><a href="#section-2.3.1-3" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-collection-discovery">
-<section id="section-2.3.2">
-          <h4 id="name-topic-collection-discovery">
-<a href="#section-2.3.2" class="section-number selfRef">2.3.2. </a><a href="#name-topic-collection-discovery" class="section-name selfRef">Topic Collection Discovery</a>
-          </h4>
-<p id="section-2.3.2-1">A Broker SHOULD offer a topic discovery entry point to enable clients to find topics of interest. The resource entry point is the topic collection resource collecting the topic configurations for those topics (see Section 1.2.2 of <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>) and is identified by the resource type "core.ps.coll".<a href="#section-2.3.2-1" class="pilcrow">¶</a></p>
-<p id="section-2.3.2-2">The specific resource path is left for implementations, examples in this document use the "/ps" path. The interactions with a topic collection are further defined in <a href="#topic-collection-interactions" class="auto internal xref">Section 2.4</a>.<a href="#section-2.3.2-2" class="pilcrow">¶</a></p>
-<p id="section-2.3.2-3">Since the representation of the topic collection resource includes the links to the associated topic resources, it is not required to locate those links under "/.well-known/core", also in order to limit the size of the Link Format document returned as result of the discovery.<a href="#section-2.3.2-3" class="pilcrow">¶</a></p>
-<p id="section-2.3.2-4">Example:<a href="#section-2.3.2-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.3.2-5">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: .well-known/core
-   Resource-Type: core.ps.coll
-
-   &lt;= 2.05 Content
-   Content-Format: 40 (application/link-format)
-   &lt;/ps1&gt;;rt="core.ps.coll";ct=40,
-   &lt;/other/path&gt;;rt="core.ps.coll";ct=40
-</pre><a href="#section-2.3.2-5" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-discovery">
-<section id="section-2.3.3">
-          <h4 id="name-topic-configuration-discove">
-<a href="#section-2.3.3" class="section-number selfRef">2.3.3. </a><a href="#name-topic-configuration-discove" class="section-name selfRef">Topic-Configuration Discovery</a>
-          </h4>
-<p id="section-2.3.3-1">Each topic collection is associated with a group of topic resources, each detailing the configuration of its respective topic (refer to <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>). Each topic resource is identified by the resource type "core.ps.conf".<a href="#section-2.3.3-1" class="pilcrow">¶</a></p>
-<p id="section-2.3.3-2">Below is an example of discovery via /.well-known/core with rt=core.ps.conf that returns a list of topics, as the list of links to the corresponding topic resources.<a href="#section-2.3.3-2" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.3.3-3">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: .well-known/core
-   Resource-Type: core.ps.conf
-
-&lt;= 2.05 Content
-   Content-Format: 40 (application/link-format)
-   &lt;/ps1/h9392&gt;;rt="core.ps.conf";ct=TBD,
-   &lt;/other/path/2e3570&gt;;rt=core.ps.conf;ct=TBD
-</pre><a href="#section-2.3.3-3" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-data-discovery">
-<section id="section-2.3.4">
-          <h4 id="name-topic-data-discovery">
-<a href="#section-2.3.4" class="section-number selfRef">2.3.4. </a><a href="#name-topic-data-discovery" class="section-name selfRef">Topic-Data Discovery</a>
-          </h4>
-<p id="section-2.3.4-1">Within a topic, there is the topic-data property containing the URI of the topic-data resource that a CoAP client can subscribe and publish to. Resources exposing resources of the topic-data type are expected to use the resource type 'core.ps.data'.<a href="#section-2.3.4-1" class="pilcrow">¶</a></p>
-<p id="section-2.3.4-2">The topic-data contains the URI of the topic-data resource for publishing and subscribing. So retrieving the topic configuration will also provide the URL of the topic-data (see <a href="#topic-get-resource" class="auto internal xref">Section 2.5.1</a>).<a href="#section-2.3.4-2" class="pilcrow">¶</a></p>
-<p id="section-2.3.4-3">It is also possible to discover a list of topic-data resources by sending a request to the collection with with rt=core.ps.data resources as shown below.<a href="#section-2.3.4-3" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.3.4-4">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: /ps
-   Resource-Type: core.ps.data
-
-&lt;= 2.05 Content
-   Content-Format: 40 (application/link-format)
-   &lt;/ps/data/62e4f8d&gt;; rt=core.ps.data; obs
-</pre><a href="#section-2.3.4-4" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="topic-collection-interactions">
-<section id="section-2.4">
-        <h3 id="name-topic-collection-interactio">
-<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-topic-collection-interactio" class="section-name selfRef">Topic Collection Interactions</a>
-        </h3>
-<p id="section-2.4-1">These are the interactions that can happen directly with a specific topic collection.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
-<div id="topic-get-all">
-<section id="section-2.4.1">
-          <h4 id="name-retrieving-all-topic-config">
-<a href="#section-2.4.1" class="section-number selfRef">2.4.1. </a><a href="#name-retrieving-all-topic-config" class="section-name selfRef">Retrieving all topic-configurations</a>
-          </h4>
-<p id="section-2.4.1-1">A client can request a collection of the topics present in the broker by making a GET request to the collection URI.<a href="#section-2.4.1-1" class="pilcrow">¶</a></p>
-<p id="section-2.4.1-2">On success, the server returns a 2.05 (Content) response, specifying the list of links to topic resources associated with this topic collection (see  <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>).<a href="#section-2.4.1-2" class="pilcrow">¶</a></p>
-<p id="section-2.4.1-3">Depending on its granted permissions, a client MAY retrieve a different list of links, corresponding to the topics that the client is authorized to access.<a href="#section-2.4.1-3" class="pilcrow">¶</a></p>
-<p id="section-2.4.1-4">Example:<a href="#section-2.4.1-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.4.1-5">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-
-&lt;= 2.05 Content
-   Content-Format: 40 (application/link-format)
-   &lt;/ps/h9392&gt;;rt="core.ps.conf",
-   &lt;/ps/2e3570&gt;; rt="core.ps.conf"
-</pre><a href="#section-2.4.1-5" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-get-properties">
-<section id="section-2.4.2">
-          <h4 id="name-getting-topic-configuration">
-<a href="#section-2.4.2" class="section-number selfRef">2.4.2. </a><a href="#name-getting-topic-configuration" class="section-name selfRef">Getting topic-configurations by Properties</a>
-          </h4>
-<p id="section-2.4.2-1">A client can filter a collection of topics by submitting the
-representation of a topic filter (see  <a href="#topic-fetch-resource" class="auto internal xref">Section 2.5.2</a>) in a FETCH request to the topic collection URI.<a href="#section-2.4.2-1" class="pilcrow">¶</a></p>
-<p id="section-2.4.2-2">On success, the server returns a 2.05 (Content) response with a
-representation of a list of topics in the collection (see
- <a href="#topic-discovery" class="auto internal xref">Section 2.3.3</a>) that match the filter in CoRE link format <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>.<a href="#section-2.4.2-2" class="pilcrow">¶</a></p>
-<p id="section-2.4.2-3">Upon success, the server responds with a 2.05 (Content), providing a list of links to topic resources associated with this topic collection that match the request's filter criteria (refer to  <a href="#topic-discovery" class="auto internal xref">Section 2.3.3</a>). A positive match happens only when each request parameter is present with the indicated value in the topic resource representation.<a href="#section-2.4.2-3" class="pilcrow">¶</a></p>
-<p id="section-2.4.2-4">Example:<a href="#section-2.4.2-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.4.2-5">
-<pre>
-=&gt; 0.05 FETCH
-   Uri-Path: ps
-   Content-Format: TBD (application/pubsub+cbor)
-
-   {
-     "resource-type": "core.ps.conf",
-     "topic-type": "temperature"
-   }
-
-&lt;= 2.05 Content
-   Content-Format: 40 (application/link-format)
-   &lt;/ps/2e3570&gt;;rt="core.ps.conf"
-</pre><a href="#section-2.4.2-5" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-create">
-<section id="section-2.4.3">
-          <h4 id="name-creating-a-topic">
-<a href="#section-2.4.3" class="section-number selfRef">2.4.3. </a><a href="#name-creating-a-topic" class="section-name selfRef">Creating a Topic</a>
-          </h4>
-<p id="section-2.4.3-1">A client can add a new topic-configurations to a collection of topics by submitting an initial representation of the initial topic resource (see  <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>) in a POST request to the topic collection URI. The request MUST specify at least a subset of the properties in  <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>, namely: topic-name and resource-type.<a href="#section-2.4.3-1" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-2">Please note that the topic will NOT be fully created until a publisher has published some data to it (See <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>).<a href="#section-2.4.3-2" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-3">On success, the server returns a 2.01 (Created) response, indicating the Location-Path of the new topic and the current representation of the topic resource. The response payload includes a CBOR map with key-value pairs. The response must include the required topic properties (see <a href="#topic-properties" class="auto internal xref">Section 2.2.1</a>), namely: "topic-name", "resource-type" and "topic-data". It may also include a number of optional properties too.<a href="#section-2.4.3-3" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-4">If requirements are defined for the client to create the topic as requested and the broker does not successfully assess that those requirements are met, then the broker MUST respond with a 4.03 (Forbidden) error. The response MUST have Content-Format set to "application/core-pubsub+cbor".<a href="#section-2.4.3-4" class="pilcrow">¶</a></p>
-<p id="section-2.4.3-5">The broker MUST issue a 4.00 (Bad Request) error if a received parameter is invalid, unrecognized, or if the topic-name is already in use or otherwise invalid.<a href="#section-2.4.3-5" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.4.3-6">
-<pre>
-=&gt; 0.02 POST
-   Uri-Path: ps
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-   TBD (this should be a CBOR map with the mandatory parameters)
-   {
-     "topic-name": "living-room-sensor",
-     "resource-type": "core.ps.conf"
-   }
-
-&lt;= 2.01 Created
-   Location-Path: ps/h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-
-   TBD (this should be a CBOR map)
-   {
-     "topic-name": "living-room-sensor",
-     "topic-data": "ps/data/1bd0d6d",
-     "resource-type": "core.ps.conf"
-   }
-</pre><a href="#section-2.4.3-6" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="topic-configuration-interactions">
-<section id="section-2.5">
-        <h3 id="name-topic-configuration-interac">
-<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-topic-configuration-interac" class="section-name selfRef">Topic-Configuration Interactions</a>
-        </h3>
-<p id="section-2.5-1">These are the interactions that can happen at the topic resource level.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
-<div id="topic-get-resource">
-<section id="section-2.5.1">
-          <h4 id="name-getting-a-topic-configurati">
-<a href="#section-2.5.1" class="section-number selfRef">2.5.1. </a><a href="#name-getting-a-topic-configurati" class="section-name selfRef">Getting a topic-configuration</a>
-          </h4>
-<p id="section-2.5.1-1">A client can read the configuration of a topic by making a GET request to the topic resource URI.<a href="#section-2.5.1-1" class="pilcrow">¶</a></p>
-<p id="section-2.5.1-2">On success, the server returns a 2.05 (Content) response with a partial representation of the topic resource, as specified in <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>. The partial representation includes only the configuration parameters such that they are present and have the same value in both the current topic configuration as well as in the FETCH request.<a href="#section-2.5.1-2" class="pilcrow">¶</a></p>
-<p id="section-2.5.1-3">If requirements are defined for the client to create the topic as requested and the broker does not successfully assess that those requirements are met, then the broker MUST respond with a 4.03 (Forbidden) error.<a href="#section-2.5.1-3" class="pilcrow">¶</a></p>
-<p id="section-2.5.1-4">The response payload is a CBOR map, whose possible entries are specified in <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a> and use the same abbreviations defined in <a href="#pubsub-parameters" class="auto internal xref">Section 4</a>.<a href="#section-2.5.1-4" class="pilcrow">¶</a></p>
-<p id="section-2.5.1-5">For example, below is a request on the topic "ps/h9392":<a href="#section-2.5.1-5" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.5.1-6">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-   Uri-Path: h9392
-
-&lt;= 2.05 Content
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-   {
-      "topic-name" : "living-room-sensor",
-      "topic-data" : "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "temperature",
-      "expiration-date": "2023-04-00T23:59:59Z",
-      "max-subscribers": 100
-   }
-
-</pre><a href="#section-2.5.1-6" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-fetch-resource">
-<section id="section-2.5.2">
-          <h4 id="name-getting-part-of-a-topic-con">
-<a href="#section-2.5.2" class="section-number selfRef">2.5.2. </a><a href="#name-getting-part-of-a-topic-con" class="section-name selfRef">Getting part of a topic-configuration</a>
-          </h4>
-<p id="section-2.5.2-1">A client can read the configuration of a topic by making a FETCH request to the topic resource URI with a filter for specific parameters. This is done in order to retrieve part of the current topic resource.<a href="#section-2.5.2-1" class="pilcrow">¶</a></p>
-<p id="section-2.5.2-2">The request contains a CBOR map with a configuration filter or 'conf-filter', a CBOR array with CBOR abbreviation. Each element of the array specifies one requested configuration parameter of the current topic resource (see <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>).<a href="#section-2.5.2-2" class="pilcrow">¶</a></p>
-<p id="section-2.5.2-3">On success, the server returns a 2.05 (Content) response with a representation of the topic resource. The response has as payload the partial representation of the topic resource as specified in <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>.<a href="#section-2.5.2-3" class="pilcrow">¶</a></p>
-<p id="section-2.5.2-4">If requirements are defined for the client to create the topic as requested and the broker does not successfully assess that those requirements are met, then the broker MUST respond with a 4.03 (Forbidden) error.<a href="#section-2.5.2-4" class="pilcrow">¶</a></p>
-<p id="section-2.5.2-5">The response payload is a CBOR map, whose possible entries are specified in <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a> and use the same abbreviations defined in <a href="#pubsub-parameters" class="auto internal xref">Section 4</a>.<a href="#section-2.5.2-5" class="pilcrow">¶</a></p>
-<p id="section-2.5.2-6">Both request and response MUST have Content-Format set to "application/core-pubsub+cbor".<a href="#section-2.5.2-6" class="pilcrow">¶</a></p>
-<p id="section-2.5.2-7">Example:<a href="#section-2.5.2-7" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.5.2-8">
-<pre>
-=&gt; 0.05 FETCH
-   Uri-Path: ps
-   Uri-Path: h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-   {
-     "conf-filter": ["topic-data", "media-type"]
-   }
-
-&lt;= 2.05 Content
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-   {
-     "topic-data": "ps/data/1bd0d6d",
-     "media-type": "application/senml-cbor"
-   }
-
-</pre><a href="#section-2.5.2-8" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="topic-update-resource">
-<section id="section-2.5.3">
-          <h4 id="name-updating-the-topic-configur">
-<a href="#section-2.5.3" class="section-number selfRef">2.5.3. </a><a href="#name-updating-the-topic-configur" class="section-name selfRef">Updating the topic-configuration</a>
-          </h4>
-<p id="section-2.5.3-1">A client can update a topic's configuration by submitting the updated topic representation in a PUT request to the topic URI. However, the parameters "topic-name", "topic-data", and "resource-type" are immutable post-creation, and any request attempting to change them will be deemed invalid by the broker.<a href="#section-2.5.3-1" class="pilcrow">¶</a></p>
-<p id="section-2.5.3-2">On success, the topic configuration is overwritten and server returns a 2.04 (Changed) response and the current full resource representation. The broker may chose not to overwrite parameters that are not explicitly modified in the request.<a href="#section-2.5.3-2" class="pilcrow">¶</a></p>
-<p id="section-2.5.3-3">Note that updating the "topic-data" path will automatically cancel all existing observations on it and thus will unsubscribe all subscribers. Updating the "topic-data" may happen also after it being deleted, as described on {delete-topic-data}, this will in turn create a new "topic-data" path for that topic configuration.<a href="#section-2.5.3-3" class="pilcrow">¶</a></p>
-<p id="section-2.5.3-4">Similarly, decreasing max-subscribers will also cause that some subscribers get unsubscribed. Unsubscribed endpoints SHOULD receive a final 4.04 (Not Found) response as per <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> Section 3.2.<a href="#section-2.5.3-4" class="pilcrow">¶</a></p>
-<p id="section-2.5.3-5">Please note that when using PUT the topic configuration is being overwritten, thus some of the optional parameters (e.g., "max-subscribers", "observer-check") not included in the PUT message will be reset to their default values.<a href="#section-2.5.3-5" class="pilcrow">¶</a></p>
-<p id="section-2.5.3-6">Example:<a href="#section-2.5.3-6" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.5.3-7">
-<pre>
-=&gt; 0.03 PUT
-   Uri-Path: ps
-   Uri-Path: h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-
-   {
-      "topic-name": "living-room-sensor",
-      "topic-data": "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "temperature",
-      "expiration-date": "2023-04-28T23:59:59Z",
-   }
-
-&lt;= 2.04 Changed
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-
-   TBD (this should be a CBOR map)
-   {
-      "topic-name": "living-room-sensor",
-      "topic-data": "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "temperature",
-      "expiration-date": "2023-04-28T23:59:59Z",
-      "max-subscribers": 100,
-      "observer-check": 86400
-   }
-</pre><a href="#section-2.5.3-7" class="pilcrow">¶</a>
-</div>
-<p id="section-2.5.3-8">Note that when a topic configuration changes, it may result in disruptions for the subscribers. Some potential issues that may arise include:<a href="#section-2.5.3-8" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-2.5.3-9.1">
-              <p id="section-2.5.3-9.1.1">Limiting the number of subscribers will cause to cancel ongoing subscriptions until max-subscribers has been reached.<a href="#section-2.5.3-9.1.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.5.3-9.2">
-              <p id="section-2.5.3-9.2.1">Changing the topic-data value will cancel all ongoing subscriptions.<a href="#section-2.5.3-9.2.1" class="pilcrow">¶</a></p>
-</li>
-            <li class="normal" id="section-2.5.3-9.3">
-              <p id="section-2.5.3-9.3.1">Changing of the expiration-date may cause to cancel ongoing subscriptions if the topic expires at an earlier data.<a href="#section-2.5.3-9.3.1" class="pilcrow">¶</a></p>
-</li>
-          </ul>
-</section>
-</div>
-<div id="topic-update-resource-patch">
-<section id="section-2.5.4">
-          <h4 id="name-updating-the-topic-configura">
-<a href="#section-2.5.4" class="section-number selfRef">2.5.4. </a><a href="#name-updating-the-topic-configura" class="section-name selfRef">Updating the topic-configuration with iPATCH</a>
-          </h4>
-<p id="section-2.5.4-1">A client can partially update a topic's configuration by submitting a partial topic representation in an iPATCH request to the topic URI. The iPATCH request allows for updating only specific fields of the topic configuration while leaving the others unchanged. As with the PUT method, the parameters "topic-name", "topic-data", and "resource-type" are immutable post-creation, and any request attempting to change them will be deemed invalid by the broker.<a href="#section-2.5.4-1" class="pilcrow">¶</a></p>
-<p id="section-2.5.4-2">On success, the server returns a 2.04 (Changed) response and the current full resource representation. The broker only updates parameters that are explicitly mentioned in the request.<a href="#section-2.5.4-2" class="pilcrow">¶</a></p>
-<p id="section-2.5.4-3">As with the PUT method, updating the "topic-data" path will automatically cancel all existing observations on it and thus will unsubscribe all subscribers. Decreasing max-subscribers will also cause some subscribers to get unsubscribed. Unsubscribed endpoints SHOULD receive a final 4.04 (Not Found) response as per <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> Section 3.2.<a href="#section-2.5.4-3" class="pilcrow">¶</a></p>
-<p id="section-2.5.4-4">Contrary to PUT, iPATCH operations will explicitly update some parameters, leaving others unmodified.<a href="#section-2.5.4-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.5.4-5">
-<pre>
-=&gt; 0.07 iPATCH
-   Uri-Path: ps
-   Uri-Path: h9392
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-
-   {
-      "topic-type": "humidity",
-      "max-subscribers": 5
-   }
-
-&lt;= 2.04 Changed
-   Content-Format: TBD2 (application/core-pubsub+cbor)
-
-   TBD (this should be a CBOR map)
-   {
-      "topic-name" : "living-room-sensor",
-      "topic-data" : "ps/data/1bd0d6d",
-      "resource-type": "core.ps.conf",
-      "media-type": "application/senml-cbor",
-      "topic-type": "humidity",
-      "expiration-date": "2023-05-28T23:59:59Z",
-      "max-subscribers": 5
-   }
-</pre><a href="#section-2.5.4-5" class="pilcrow">¶</a>
-</div>
-<p id="section-2.5.4-6">Note that when a topic configuration changes through an iPATCH request, it may result in disruptions for the subscribers. For example, limiting the number of subscribers will cause to cancel ongoing subscriptions until max-subscribers has been reached.<a href="#section-2.5.4-6" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="topic-delete">
-<section id="section-2.5.5">
-          <h4 id="name-deleting-a-topic-configurat">
-<a href="#section-2.5.5" class="section-number selfRef">2.5.5. </a><a href="#name-deleting-a-topic-configurat" class="section-name selfRef">Deleting a topic-configuration</a>
-          </h4>
-<p id="section-2.5.5-1">A client can delete a topic by making a CoAP DELETE request on the topic resource URI.<a href="#section-2.5.5-1" class="pilcrow">¶</a></p>
-<p id="section-2.5.5-2">On success, the server returns a 2.02 (Deleted) response.<a href="#section-2.5.5-2" class="pilcrow">¶</a></p>
-<p id="section-2.5.5-3">When a topic-configuration resource is deleted, the broker MUST also delete the topic-data resource, unsubscribe all subscribers by removing them from the list of observers and returning a final 4.04 (Not Found) response as per section 3.2 of <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>.<a href="#section-2.5.5-3" class="pilcrow">¶</a></p>
-<p id="section-2.5.5-4">Example:<a href="#section-2.5.5-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-2.5.5-5">
-<pre>
-=&gt; 0.04 DELETE
-   Uri-Path: ps
-   Uri-Path: h9392
-
-&lt;= 2.02 Deleted
-</pre><a href="#section-2.5.5-5" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="pubsub">
-<section id="section-3">
-      <h2 id="name-publish-and-subscribe">
-<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-publish-and-subscribe" class="section-name selfRef">Publish and Subscribe</a>
-      </h2>
-<p id="section-3-1">The overview of the publish/subscribe mechanism over CoAP is as follows: a publisher publishes to a topic by submitting the data in a PUT request to a topic-data resource and subscribers subscribe to a topic by submitting a GET request with Observe option set to 0 (register) to a topic-data resource. When resource state changes, subscribers observing the resource <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> at that time will receive a notification.<a href="#section-3-1" class="pilcrow">¶</a></p>
-<p id="section-3-2">A topic-data resource does not exist until some initial data has been published to it. Before initial data publication, a GET request to the topic-data resource URI results in a 4.04 (Not Found) response. If such a "half created" topic is undesired, the creator of the topic can simply immediately publish some initial placeholder data to make the topic "fully created" (see <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>).<a href="#section-3-2" class="pilcrow">¶</a></p>
-<p id="section-3-3">URIs for topic resources are broker-generated (see <a href="#topic-create" class="auto internal xref">Section 2.4.3</a>). There is no necessary URI pattern dependence between the URI where the topic-data exists and the URI of the topic-configuration resource.<a href="#section-3-3" class="pilcrow">¶</a></p>
-<div id="topic-lifecycle">
-<section id="section-3.1">
-        <h3 id="name-topic-lifecycle">
-<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-topic-lifecycle" class="section-name selfRef">Topic Lifecycle</a>
-        </h3>
-<p id="section-3.1-1">When a topic is newly created, it is first placed by the broker into the HALF CREATED state (see <a href="#fig-life" class="auto internal xref">Figure 4</a>). In this state, a client can read and update the configuration of the topic and delete the topic. A publisher can publish to the topic-data resource.  However, a subscriber cannot yet subscribe to the topic-data resource nor read the latest data.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
-<span id="name-lifecycle-of-a-topic"></span><div id="fig-life">
-<figure id="figure-4">
-          <div id="section-3.1-2.1">
-            <div class="alignCenter art-svg artwork" id="section-3.1-2.1.1">
-<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="224" width="544" viewBox="0 0 544 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
-                <path d="M 128,72 L 128,120" fill="none" stroke="black"></path>
-                <path d="M 128,144 L 128,176" fill="none" stroke="black"></path>
-                <path d="M 160,144 L 160,176" fill="none" stroke="black"></path>
-                <path d="M 168,72 L 168,120" fill="none" stroke="black"></path>
-                <path d="M 248,152 L 248,184" fill="none" stroke="black"></path>
-                <path d="M 280,152 L 280,184" fill="none" stroke="black"></path>
-                <path d="M 368,72 L 368,120" fill="none" stroke="black"></path>
-                <path d="M 368,144 L 368,176" fill="none" stroke="black"></path>
-                <path d="M 400,144 L 400,176" fill="none" stroke="black"></path>
-                <path d="M 408,72 L 408,120" fill="none" stroke="black"></path>
-                <path d="M 8,80 L 104,80" fill="none" stroke="black"></path>
-                <path d="M 192,80 L 344,80" fill="none" stroke="black"></path>
-                <path d="M 432,80 L 520,80" fill="none" stroke="black"></path>
-                <path d="M 192,112 L 344,112" fill="none" stroke="black"></path>
-                <path d="M 432,112 L 520,112" fill="none" stroke="black"></path>
-                <path d="M 200,160 L 224,160" fill="none" stroke="black"></path>
-                <path d="M 304,160 L 328,160" fill="none" stroke="black"></path>
-                <path d="M 184,128 L 200,160" fill="none" stroke="black"></path>
-                <path d="M 328,160 L 344,128" fill="none" stroke="black"></path>
-                <path d="M 520,80 C 528.83064,80 536,87.16936 536,96" fill="none" stroke="black"></path>
-                <path d="M 520,112 C 528.83064,112 536,104.83064 536,96" fill="none" stroke="black"></path>
-                <path d="M 144,192 C 135.16936,192 128,184.83064 128,176" fill="none" stroke="black"></path>
-                <path d="M 144,192 C 152.83064,192 160,184.83064 160,176" fill="none" stroke="black"></path>
-                <path d="M 384,192 C 375.16936,192 368,184.83064 368,176" fill="none" stroke="black"></path>
-                <path d="M 384,192 C 392.83064,192 400,184.83064 400,176" fill="none" stroke="black"></path>
-                <path d="M 128,72 L 168,72" fill="none" stroke="black"></path>
-                <path d="M 368,72 L 408,72" fill="none" stroke="black"></path>
-                <path d="M 128,120 L 168,120" fill="none" stroke="black"></path>
-                <path d="M 368,120 L 408,120" fill="none" stroke="black"></path>
-                <path d="M 248,152 L 280,152" fill="none" stroke="black"></path>
-                <path d="M 248,184 L 280,184" fill="none" stroke="black"></path>
-                <polygon class="arrowhead" points="440,112 428,106.4 428,117.6" fill="black" transform="rotate(180,432,112)"></polygon>
-                <polygon class="arrowhead" points="408,144 396,138.4 396,149.6" fill="black" transform="rotate(270,400,144)"></polygon>
-                <polygon class="arrowhead" points="352,112 340,106.4 340,117.6" fill="black" transform="rotate(0,344,112)"></polygon>
-                <polygon class="arrowhead" points="312,160 300,154.4 300,165.6" fill="black" transform="rotate(180,304,160)"></polygon>
-                <polygon class="arrowhead" points="232,160 220,154.4 220,165.6" fill="black" transform="rotate(0,224,160)"></polygon>
-                <polygon class="arrowhead" points="200,80 188,74.4 188,85.6" fill="black" transform="rotate(180,192,80)"></polygon>
-                <polygon class="arrowhead" points="168,144 156,138.4 156,149.6" fill="black" transform="rotate(270,160,144)"></polygon>
-                <polygon class="arrowhead" points="112,80 100,74.4 100,85.6" fill="black" transform="rotate(0,104,80)"></polygon>
-                <g class="text">
-                  <text x="148" y="36">HALF</text>
-                  <text x="392" y="36">FULLY</text>
-                  <text x="152" y="52">CREATED</text>
-                  <text x="260" y="52">Delete</text>
-                  <text x="392" y="52">CREATED</text>
-                  <text x="268" y="68">topic-data</text>
-                  <text x="472" y="68">Publish</text>
-                  <text x="52" y="100">Create</text>
-                  <text x="264" y="132">Publish</text>
-                  <text x="480" y="132">Subscribe</text>
-                  <text x="96" y="164">Read/</text>
-                  <text x="432" y="164">Read/</text>
-                  <text x="92" y="180">Update</text>
-                  <text x="204" y="180">Delete</text>
-                  <text x="324" y="180">Delete</text>
-                  <text x="436" y="180">Update</text>
-                  <text x="200" y="196">Topic</text>
-                  <text x="320" y="196">Topic</text>
-                  <text x="264" y="212">DELETED</text>
-                </g>
-              </svg><a href="#section-3.1-2.1.1" class="pilcrow">¶</a>
-</div>
-</div>
-<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
-<a href="#name-lifecycle-of-a-topic" class="selfRef">Lifecycle of a Topic</a>
-          </figcaption></figure>
-</div>
-<p id="section-3.1-3">After a publisher publishes to the topic-data for the first time, the topic is placed into the FULLY CREATED state. In this state, a client can read data by means of a GET request without observe. A publisher can publish to the topic-data resource and a subscriber can observe the topic-data resource.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
-<p id="section-3.1-4">When a client deletes a topic-configuration resource, the topic is placed into the DELETED state and shortly after removed from the server. In this state, all subscribers are removed from the list of observers of the topic-data resource and no further interactions with the topic are possible.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
-<p id="section-3.1-5">When a client deletes a topic-data, the topic is placed into the HALF CREATED state, where clients can read, update and delete the topic-configuration and await for a publisher to begin publication.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="topic-data-interactions">
-<section id="section-3.2">
-        <h3 id="name-topic-data-interactions">
-<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-topic-data-interactions" class="section-name selfRef">Topic-Data Interactions</a>
-        </h3>
-<p id="section-3.2-1">Interactions with the topic-data resource are covered in this section.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
-<div id="publish">
-<section id="section-3.2.1">
-          <h4 id="name-publish">
-<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-publish" class="section-name selfRef">Publish</a>
-          </h4>
-<p id="section-3.2.1-1">A topic-configuration with a topic-data resource must have been created in order to publish data to it (See <a href="#topic-create" class="auto internal xref">Section 2.4.3</a>) and be in the half-created or fully-created state in order to the publish operation to work (see <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>).<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
-<p id="section-3.2.1-2">A client can publish data to a topic by submitting the data in a PUT request to the topic-data URI as indicated in its topic resource property. Please note that the topic-data URI is not the same as the topic-configuration URI used for configuring the topic (see <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>).<a href="#section-3.2.1-2" class="pilcrow">¶</a></p>
-<p id="section-3.2.1-3">On success, the server returns a 2.04 (Updated) response. However, when data is published to the topic for the first time, the server instead MUST return a 2.01 (Created) response and set the topic in the fully-created state (see <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>).<a href="#section-3.2.1-3" class="pilcrow">¶</a></p>
-<p id="section-3.2.1-4">If the request does not have an acceptable content-format, the server returns a 4.15 (Unsupported Content-Format) response.<a href="#section-3.2.1-4" class="pilcrow">¶</a></p>
-<p id="section-3.2.1-5">If the client is sending publications too fast, the server returns a
-4.29 (Too Many Requests) response <span>[<a href="#RFC8516" class="cite xref">RFC8516</a>]</span>.<a href="#section-3.2.1-5" class="pilcrow">¶</a></p>
-<p id="section-3.2.1-6">Example of first publication:<a href="#section-3.2.1-6" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-3.2.1-7">
-<pre>
-=&gt; 0.03 PUT
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-   Content-Format: 110
-
-   {
-      "n": "coap://dev1.example.com/temperature",
-      "u": "Cel",
-      "t": 1621452122,
-      "v": 23.5
-   }
-
-&lt;= 2.01 Created
-</pre><a href="#section-3.2.1-7" class="pilcrow">¶</a>
-</div>
-<p id="section-3.2.1-8">Example of subsequent publication:<a href="#section-3.2.1-8" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-3.2.1-9">
-<pre>
-=&gt; 0.03 PUT
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-   Content-Format: 110
-
-   {
-      "n": "coap://dev1.example.com/temperature",
-      "u": "Cel",
-      "t": 1621452149,
-      "v": 22.5
-   }
-
-&lt;= 2.04 Updated
-</pre><a href="#section-3.2.1-9" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="subscribe">
-<section id="section-3.2.2">
-          <h4 id="name-subscribe">
-<a href="#section-3.2.2" class="section-number selfRef">3.2.2. </a><a href="#name-subscribe" class="section-name selfRef">Subscribe</a>
-          </h4>
-<p id="section-3.2.2-1">A client can subscribe to a topic-data by sending a CoAP GET request with the Observe set to 0 to subscribe to resource updates. <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>.<a href="#section-3.2.2-1" class="pilcrow">¶</a></p>
-<p id="section-3.2.2-2">On success, the server hosting the topic-data resource MUST return 2.05 (Content) notifications with the data and the Observe Option. Otherwise, if no Observe Option is present the client should assume that the subscription was not successful.<a href="#section-3.2.2-2" class="pilcrow">¶</a></p>
-<p id="section-3.2.2-3">If the topic is not yet in the fully created state (see <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>) the broker SHOULD return a response code 4.04 (Not Found).<a href="#section-3.2.2-3" class="pilcrow">¶</a></p>
-<p id="section-3.2.2-4">The following response codes are defined for the Subscribe operation:<a href="#section-3.2.2-4" class="pilcrow">¶</a></p>
-<span class="break"></span><dl class="dlParallel" id="section-3.2.2-5">
-            <dt id="section-3.2.2-5.1">Success:</dt>
-            <dd style="margin-left: 1.5em" id="section-3.2.2-5.2">
-              <p id="section-3.2.2-5.2.1">2.05 "Content". Successful subscribe with observe response, current value included in the response.<a href="#section-3.2.2-5.2.1" class="pilcrow">¶</a></p>
-</dd>
-            <dd class="break"></dd>
-<dt id="section-3.2.2-5.3">Failure:</dt>
-            <dd style="margin-left: 1.5em" id="section-3.2.2-5.4">
-              <p id="section-3.2.2-5.4.1">4.04 "Not Found". The topic-data does not exist.<a href="#section-3.2.2-5.4.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-</dl>
-<p id="section-3.2.2-6">If the 'max-subscribers' parameter has been reached, the server must treat that as specified in section 4.1 of <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. The response MUST NOT include an Observe Option, the absence of which signals to the subscriber that the subscription failed.<a href="#section-3.2.2-6" class="pilcrow">¶</a></p>
-<p id="section-3.2.2-7">Example:<a href="#section-3.2.2-7" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-3.2.2-8">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-   Observe: 0
-
-&lt;= 2.05 Content
-   Content-Format: 110
-   Observe: 10001
-   Max-Age: 15
-
-  {
-    "n": "urn:dev:os:32473-123456",
-    "u": "Cel",
-    "t": 1696341182,
-    "v": 19.87
-  }
-
-&lt;= 2.05 Content
-   Content-Format: 110
-   Observe: 10002
-   Max-Age: 15
-
-  {
-
-    "n": "urn:dev:os:32473-123456",
-    "u": "Cel",
-    "t": 1696340184,
-    "v": 21.87
-  }
-</pre><a href="#section-3.2.2-8" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="unsubscribe">
-<section id="section-3.2.3">
-          <h4 id="name-unsubscribe">
-<a href="#section-3.2.3" class="section-number selfRef">3.2.3. </a><a href="#name-unsubscribe" class="section-name selfRef">Unsubscribe</a>
-          </h4>
-<p id="section-3.2.3-1">A CoAP client can unsubscribe simply by cancelling the observation as described in Section 3.6 of <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>. The client MUST either use CoAP GET with the Observe Option set to 1 or send a CoAP Reset message in response to a notification. Also on Section 3.6 of <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> the client can simply "forget" the observation and the server will remove it from the list of observers after the next notification.<a href="#section-3.2.3-1" class="pilcrow">¶</a></p>
-<p id="section-3.2.3-2">As per <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> a server that transmits notifications mostly in non-confirmable messages, but it MUST send a notification in a confirmable message instead of a non-confirmable message at least every 24 hours.<a href="#section-3.2.3-2" class="pilcrow">¶</a></p>
-<p id="section-3.2.3-3">This value can be modified at the broker by the administrator of a topic by modifying the parameter "observer-check" on <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>. This would allow to change the rate at which different implementations verify that a subscriber is still interested in observing a topic-data resource.<a href="#section-3.2.3-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="delete-topic-data">
-<section id="section-3.2.4">
-          <h4 id="name-delete-topic-data">
-<a href="#section-3.2.4" class="section-number selfRef">3.2.4. </a><a href="#name-delete-topic-data" class="section-name selfRef">Delete topic-data</a>
-          </h4>
-<p id="section-3.2.4-1">A publisher MAY delete a topic by making a CoAP DELETE request on the topic-data URI.<a href="#section-3.2.4-1" class="pilcrow">¶</a></p>
-<p id="section-3.2.4-2">On success, the server returns a 2.02 (Deleted) response.<a href="#section-3.2.4-2" class="pilcrow">¶</a></p>
-<p id="section-3.2.4-3">When a topic-data resource is deleted, the broker SHOULD also delete the topic-data parameter in the topic resource, unsubscribe all subscribers by removing them from the list of observers and return a final 4.04 (Not Found) response as per <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span> Section 3.2. The topic is then set back to the half created state as per <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>.<a href="#section-3.2.4-3" class="pilcrow">¶</a></p>
-<p id="section-3.2.4-4">Example:<a href="#section-3.2.4-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-3.2.4-5">
-<pre>
-=&gt; 0.04 DELETE
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-
-&lt;= 2.02 Deleted
-</pre><a href="#section-3.2.4-5" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="read-data">
-<section id="section-3.3">
-        <h3 id="name-read-latest-data">
-<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-read-latest-data" class="section-name selfRef">Read latest data</a>
-        </h3>
-<p id="section-3.3-1">A client can get the latest published topic-data by making a GET request to the topic-data URI in the broker. Please note that discovery of the topic-data parameter is a required previous step (see <a href="#topic-get-resource" class="auto internal xref">Section 2.5.1</a>).<a href="#section-3.3-1" class="pilcrow">¶</a></p>
-<p id="section-3.3-2">On success, the server MUST return 2.05 (Content) response with the data.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
-<p id="section-3.3-3">If the target URI does not match an existing resource or the topic is not in the fully created state (see <a href="#topic-lifecycle" class="auto internal xref">Section 3.1</a>), the broker MUST return a response code 4.04 (Not Found).<a href="#section-3.3-3" class="pilcrow">¶</a></p>
-<p id="section-3.3-4">Example:<a href="#section-3.3-4" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-3.3-5">
-<pre>
-=&gt; 0.01 GET
-   Uri-Path: ps
-   Uri-Path: data
-   Uri-Path: 1bd0d6d
-
-&lt;= 2.05 Content
-   Content-Format: 110
-   Max-Age: 15
-
-   {
-      "n": "coap://dev1.example.com/temperature",
-      "u": "Cel",
-      "t": 1621452122,
-      "v": 23.5
-   }
-</pre><a href="#section-3.3-5" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-<div id="rate-limit">
-<section id="section-3.4">
-        <h3 id="name-rate-limiting">
-<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-rate-limiting" class="section-name selfRef">Rate Limiting</a>
-        </h3>
-<p id="section-3.4-1">The server hosting the topic-data may have to handle a potentially large number of publishers and subscribers at the same time. This means it could become overwhelmed if it receives too many publications in a short period of time.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
-<p id="section-3.4-2">In this situation, if a publisher is sending publications too fast, the server SHOULD return a 4.29 (Too Many Requests) response <span>[<a href="#RFC8516" class="cite xref">RFC8516</a>]</span>.  As described in <span>[<a href="#RFC8516" class="cite xref">RFC8516</a>]</span>, the Max-Age option <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> in this response indicates the number of seconds after which the client may retry. The broker MAY also stop publishing messages from that publisher for the indicated time.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
-<p id="section-3.4-3">When a publisher receives a 4.29 (Too Many Requests) response, it MUST NOT send any new publication requests to the same topic-data resource before the time indicated by the Max-Age option has passed.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-</section>
-</div>
-<div id="pubsub-parameters">
-<section id="section-4">
-      <h2 id="name-coap-pubsub-parameters">
-<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-coap-pubsub-parameters" class="section-name selfRef">CoAP Pubsub Parameters</a>
-      </h2>
-<p id="section-4-1">This document defines parameters used in the messages exchanged between a client and the broker during the topic creation and configuration process (see <a href="#topic-resource-representation" class="auto internal xref">Section 2.2</a>). The table below summarizes them and specifies the CBOR key to use instead of the full descriptive name.<a href="#section-4-1" class="pilcrow">¶</a></p>
-<p id="section-4-2">Note that the media type application/core-pubsub+cbor MUST be used when these parameters are transported in the respective message fields.<a href="#section-4-2" class="pilcrow">¶</a></p>
-<span id="name-coap-pubsub-parameters-2"></span><div id="fig-CoAP-Pubsub-Parameters">
-<figure id="figure-5">
-        <div class="alignCenter art-text artwork" id="section-4-3.1">
-<pre>
-+-----------------+-----------+-----------+------------+
-| Name            | CBOR Key  | CBOR Type | Reference  |
-|-----------------|-----------|-----------|------------|
-| topic-name      | TBD1      | tstr      | [RFC-XXXX] |
-| topic-data      | TBD2      | tstr      | [RFC-XXXX] |
-| resource-type   | TBD3      | tstr      | [RFC-XXXX] |
-| media-type      | TBD4      | uint      | [RFC-XXXX] |
-| topic-type      | TBD5      | tstr      | [RFC-XXXX] |
-| expiration-date | TBD6      | tstr      | [RFC-XXXX] |
-| max-subscribers | TBD7      | uint      | [RFC-XXXX] |
-| observer-check  | TBD8      | uint      | [RFC-XXXX] |
-+-----------------+-----------+-----------+------------+
-</pre>
-</div>
-<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
-<a href="#name-coap-pubsub-parameters-2" class="selfRef">CoAP Pubsub Parameters</a>
-        </figcaption></figure>
-</div>
-</section>
-</div>
-<div id="seccons">
-<section id="section-5">
-      <h2 id="name-security-considerations">
-<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
-      </h2>
-<p id="section-5-1">The architecture presented in this document inherits the security considerations from CoAP <span>[<a href="#RFC7252" class="cite xref">RFC7252</a>]</span> and Observe <span>[<a href="#RFC7641" class="cite xref">RFC7641</a>]</span>, as well as from Web Linking <span>[<a href="#RFC8288" class="cite xref">RFC8288</a>]</span>, Link-Format <span>[<a href="#RFC6690" class="cite xref">RFC6690</a>]</span>, and the CoRE Resource Directory <span>[<a href="#RFC9176" class="cite xref">RFC9176</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
-<p id="section-5-2">Communications between each client and the broker MUST be secured, e.g., by using OSCORE <span>[<a href="#RFC8613" class="cite xref">RFC8613</a>]</span> or DTLS <span>[<a href="#RFC9147" class="cite xref">RFC9147</a>]</span>. Security considerations for the used secure communication protocols apply too.<a href="#section-5-2" class="pilcrow">¶</a></p>
-<p id="section-5-3">The content published on a topic by a publisher client SHOULD be protected end-to-end between the publisher and all the subscribers to that topic. In such a case, it MUST be possible to assert source authentication of the published data. This can be achieved at the application layer, e.g., by using COSE <span>[<a href="#RFC9052" class="cite xref">RFC9052</a>]</span>, <span>[<a href="#RFC9053" class="cite xref">RFC9053</a>]</span>, <span>[<a href="#RFC9338" class="cite xref">RFC9338</a>]</span>.<a href="#section-5-3" class="pilcrow">¶</a></p>
-<p id="section-5-4">Access control of clients at the broker MAY be enforced for performing discovery operation, and SHOULD be enforced in a fine-grained fashion for operations related to the the creation, update, and deletion of topic resources, as well as for operations on topic-data resources such as publication on and subscription to topics. This prevents rogue clients to, among other things, repeatedly create topics at the broker or publish (large) contents, which may result in Denial of Service against the broker and the active subscribers.<a href="#section-5-4" class="pilcrow">¶</a></p>
-<p id="section-5-5">Building on <span>[<a href="#I-D.ietf-ace-key-groupcomm" class="cite xref">I-D.ietf-ace-key-groupcomm</a>]</span>, its application profile for publish-subscribe communication with CoAP <span>[<a href="#I-D.ietf-ace-pubsub-profile" class="cite xref">I-D.ietf-ace-pubsub-profile</a>]</span> provides a security model that can be used in the architecture presented in this document, in order to enable secure communication between the different parties as well as secure, authorized operations of publishers and subscribers that fulfill the requirements above.<a href="#section-5-5" class="pilcrow">¶</a></p>
-<p id="section-5-6">In particular, the application profile above relies on the ACE framework for Authentication and Authorization in Constrained Environments (ACE) <span>[<a href="#RFC9200" class="cite xref">RFC9200</a>]</span> and defines a method to: authorize publishers and subscribers to perform operations at the broker, with fine-grained access control; authorize publishers and subscribers to obtain the keying material required to take part to a topic managed by the broker; protect published data end-to-end between its publisher and all the subscribers to the targeted topic, ensuring confidentiality, integrity, and source authentication of the published content end-to-end. That approach can be extended to enforce authorization and fine-grained access control for administrator clients that are intended to create, update, and delete topic configurations at the broker.<a href="#section-5-6" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="iana">
-<section id="section-6">
-      <h2 id="name-iana-considerations">
-<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
-      </h2>
-<p id="section-6-1">This document has the following actions for IANA.<a href="#section-6-1" class="pilcrow">¶</a></p>
-<p id="section-6-2">Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.<a href="#section-6-2" class="pilcrow">¶</a></p>
-<div id="media-type">
-<section id="section-6.1">
-        <h3 id="name-media-type">
-<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-media-type" class="section-name selfRef">Media Type</a>
-        </h3>
-<p id="section-6.1-1">IANA is requested to add the following Media-Type to the "Media Types"
-registry <span>[<a href="#IANA.media-types" class="cite xref">IANA.media-types</a>]</span>.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
-<span id="name-new-media-type-application-"></span><div id="new-media-type">
-<table class="left" id="table-1">
-          <caption>
-<a href="#table-1" class="selfRef">Table 1</a>:
-<a href="#name-new-media-type-application-" class="selfRef">New Media Type application/pubsub+cbor</a>
-          </caption>
-<thead>
-            <tr>
-              <th class="text-left" rowspan="1" colspan="1">Name</th>
-              <th class="text-left" rowspan="1" colspan="1">Template</th>
-              <th class="text-left" rowspan="1" colspan="1">Reference</th>
-            </tr>
-          </thead>
-          <tbody>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">pubsub+cbor</td>
-              <td class="text-left" rowspan="1" colspan="1">application/pubsub+cbor</td>
-              <td class="text-left" rowspan="1" colspan="1">RFC XXXX, <a href="#media-type" class="auto internal xref">Section 6.1</a>
-</td>
-            </tr>
-          </tbody>
-        </table>
-</div>
-<span class="break"></span><dl class="dlCompact dlParallel" id="section-6.1-3">
-          <dt id="section-6.1-3.1">Type name:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.2">
-            <p id="section-6.1-3.2.1">application<a href="#section-6.1-3.2.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.3">Subtype name:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.4">
-            <p id="section-6.1-3.4.1">pubsub+cbor<a href="#section-6.1-3.4.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.5">Required parameters:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.6">
-            <p id="section-6.1-3.6.1">N/A<a href="#section-6.1-3.6.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.7">Optional parameters:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.8">
-            <p id="section-6.1-3.8.1">N/A<a href="#section-6.1-3.8.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.9">Encoding considerations:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.10">
-            <p id="section-6.1-3.10.1">binary (CBOR data item)<a href="#section-6.1-3.10.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.11">Security considerations:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.12">
-            <p id="section-6.1-3.12.1"><a href="#seccons" class="auto internal xref">Section 5</a> of RFC XXXX<a href="#section-6.1-3.12.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.13">Interoperability considerations:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.14">
-            <p id="section-6.1-3.14.1">none<a href="#section-6.1-3.14.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.15">Published specification:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.16">
-            <p id="section-6.1-3.16.1"><a href="#media-type" class="auto internal xref">Section 6.1</a> of RFC XXXX<a href="#section-6.1-3.16.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.17">Applications that use this media type:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.18">
-            <p id="section-6.1-3.18.1">This type is used by clients that create, retrieve, and update topic configurations at servers acting as a pub-sub broker.<a href="#section-6.1-3.18.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.19">Fragment identifier considerations:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.20">
-            <p id="section-6.1-3.20.1">N/A<a href="#section-6.1-3.20.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.21">Person &amp; email address to contact for further information:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.22">
-            <p id="section-6.1-3.22.1">CoRE WG mailing list (core@ietf.org),
-or IETF Applications and Real-Time Area (art@ietf.org)<a href="#section-6.1-3.22.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.23">Intended usage:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.24">
-            <p id="section-6.1-3.24.1">COMMON<a href="#section-6.1-3.24.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.25">Restrictions on usage:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.26">
-            <p id="section-6.1-3.26.1">none<a href="#section-6.1-3.26.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.27">Author/Change controller:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.28">
-            <p id="section-6.1-3.28.1">IETF<a href="#section-6.1-3.28.1" class="pilcrow">¶</a></p>
-</dd>
-          <dd class="break"></dd>
-<dt id="section-6.1-3.29">Provisional registration:</dt>
-          <dd style="margin-left: 1.5em" id="section-6.1-3.30">
-            <p id="section-6.1-3.30.1">no<a href="#section-6.1-3.30.1" class="pilcrow">¶</a></p>
-</dd>
-        <dd class="break"></dd>
-</dl>
-</section>
-</div>
-<div id="content-format">
-<section id="section-6.2">
-        <h3 id="name-content-format">
-<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-content-format" class="section-name selfRef">Content-Format</a>
-        </h3>
-<p id="section-6.2-1">IANA has added the following Content-Formats to the
-<a href="http://www.iana.org/assignments/core-parameters#content-formats" class="relref">"CoAP Content-Formats"</a>
-sub-registry, within the "Constrained RESTful Environments (CoRE)
-Parameters" Registry <span>[<a href="#IANA.core-parameters" class="cite xref">IANA.core-parameters</a>]</span>, as follows:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
-<span id="name-new-content-format"></span><table class="left" id="table-2">
-          <caption>
-<a href="#table-2" class="selfRef">Table 2</a>:
-<a href="#name-new-content-format" class="selfRef">New Content-Format</a>
-          </caption>
-<thead>
-            <tr>
-              <th class="text-left" rowspan="1" colspan="1">Content Type</th>
-              <th class="text-left" rowspan="1" colspan="1">Content Coding</th>
-              <th class="text-left" rowspan="1" colspan="1">ID</th>
-              <th class="text-left" rowspan="1" colspan="1">Reference</th>
-            </tr>
-          </thead>
-          <tbody>
-            <tr>
-              <td class="text-left" rowspan="1" colspan="1">application/pubsub+cbor</td>
-              <td class="text-left" rowspan="1" colspan="1">-</td>
-              <td class="text-left" rowspan="1" colspan="1">TBD9</td>
-              <td class="text-left" rowspan="1" colspan="1">RFC XXXX</td>
-            </tr>
-          </tbody>
-        </table>
-<p id="section-6.2-3">TBD9 is to be assigned from the space 256..999.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="iana-coap-pubsub-parameters">
-<section id="section-6.3">
-        <h3 id="name-coap-pubsub-parameters-3">
-<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-coap-pubsub-parameters-3" class="section-name selfRef">CoAP Pubsub Parameters</a>
-        </h3>
-<p id="section-6.3-1">IANA is asked to register the following entries in the subregistry of the "Constrained RESTful Environments (CoRE) Parameters" registry group.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
-<p id="section-6.3-2">This specification establishes the "Pubsub Topic Configuration Parameters" IANA registry within the "Constrained RESTful Environments (CoRE)
-Parameters" registry group.<a href="#section-6.3-2" class="pilcrow">¶</a></p>
-<p id="section-6.3-3">The columns of this registry are:<a href="#section-6.3-3" class="pilcrow">¶</a></p>
-<ul class="normal">
-<li class="normal" id="section-6.3-4.1">
-            <p id="section-6.3-4.1.1">Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.<a href="#section-6.3-4.1.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-6.3-4.2">
-            <p id="section-6.3-4.2.1">CBOR Key: This is the value used as CBOR key of the item. These values MUST be unique. The value can be a positive integer, a negative integer, or a text string. Different ranges of values use different registration policies <span>[<a href="#RFC8126" class="cite xref">RFC8126</a>]</span>. Integer values from -256 to 255 as well as text strings of length 1 are designated as "Standards Action With Expert Review". Integer values from -65536 to -257 and from 256 to 65535, as well as text strings of length 2 are designated as "Specification Required". Integer values greater than 65535 as well as text strings of length greater than 2 are designated as "Expert Review". Integer values less than -65536 are marked as "Private Use".<a href="#section-6.3-4.2.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-6.3-4.3">
-            <p id="section-6.3-4.3.1">CBOR Type: This contains the CBOR type of the item, or a pointer to the registry that defines its type, when that depends on another item.<a href="#section-6.3-4.3.1" class="pilcrow">¶</a></p>
-</li>
-          <li class="normal" id="section-6.3-4.4">
-            <p id="section-6.3-4.4.1">Reference: This contains a pointer to the public specification for the item.<a href="#section-6.3-4.4.1" class="pilcrow">¶</a></p>
-</li>
-        </ul>
-<p id="section-6.3-5">The registry is initially populated with the entries in <a href="#fig-CoAP-Pubsub-Parameters" class="auto internal xref">Figure 5</a> of <a href="#pubsub-parameters" class="auto internal xref">Section 4</a>.<a href="#section-6.3-5" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="iana-rt">
-<section id="section-6.4">
-        <h3 id="name-resource-types">
-<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-resource-types" class="section-name selfRef">Resource Types</a>
-        </h3>
-<p id="section-6.4-1">IANA is asked to enter the following values in the "Resource Type (rt=) Link Target Attribute Values" registry within the "Constrained Restful Environments (CoRE) Parameters" registry group.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
-<div class="alignLeft art-text artwork" id="section-6.4-2">
-<pre>
-Value: core.ps
-Description: Publish-Subscribe Broker
-Reference: [RFC-XXXX]
-
-Value: core.ps.coll
-Description: Topic-collection resource of a Publish-Subscribe Broker
-Reference: [RFC-XXXX]
-
-Value: core.ps.conf
-Description: Topic-configuration resource of a Publish-Subscribe Broker
-Reference: [RFC-XXXX]
-
-Value: core.ps.data
-Description: Topic-data resource of a broker
-Reference: [RFC-XXXX]
-</pre><a href="#section-6.4-2" class="pilcrow">¶</a>
-</div>
-</section>
-</div>
-</section>
-</div>
-<div id="acknowledgements">
-<section id="section-7">
-      <h2 id="name-acknowledgements">
-<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
-      </h2>
-<p id="section-7-1">The current version of this document contains a substantial contribution by Klaus Hartke's proposal <span>[<a href="#I-D.hartke-t2trg-coral-pubsub" class="cite xref">I-D.hartke-t2trg-coral-pubsub</a>]</span>, which defines the topic resource model and structure as well as the topic lifecycle and interactions. It also follows a similar architectural design as that provided by Marco Tiloca's <span>[<a href="#I-D.ietf-ace-oscore-gm-admin" class="cite xref">I-D.ietf-ace-oscore-gm-admin</a>]</span>.<a href="#section-7-1" class="pilcrow">¶</a></p>
-<p id="section-7-2">The authors would like to also thank Carsten Bormann, Hannes Tschofenig, Zach Shelby, Mohit Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran Selander, Mikko Majanen, Olaf Bergmann and Oscar Novo for their valuable contributions and reviews.<a href="#section-7-2" class="pilcrow">¶</a></p>
-</section>
-</div>
-<section id="section-8">
-      <h2 id="name-references">
-<a href="#name-references" class="section-name selfRef">References</a>
-      </h2>
-<div id="sec-normative-references">
-<section id="section-8.1">
-        <h3 id="name-normative-references">
-<a href="#name-normative-references" class="section-name selfRef">Normative References</a>
-        </h3>
-<dl class="references">
-<dt id="IANA.core-parameters">[IANA.core-parameters]</dt>
-        <dd>
-<span class="refAuthor">IANA</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Parameters"</span>, <span>&lt;<a href="http://www.iana.org/assignments/core-parameters">http://www.iana.org/assignments/core-parameters</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="IANA.media-types">[IANA.media-types]</dt>
-        <dd>
-<span class="refAuthor">IANA</span>, <span class="refTitle">"Media Types"</span>, <span>&lt;<a href="http://www.iana.org/assignments/media-types">http://www.iana.org/assignments/media-types</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC2119">[RFC2119]</dt>
-        <dd>
-<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc2119">https://www.rfc-editor.org/rfc/rfc2119</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC6570">[RFC6570]</dt>
-        <dd>
-<span class="refAuthor">Gregorio, J.</span>, <span class="refAuthor">Fielding, R.</span>, <span class="refAuthor">Hadley, M.</span>, <span class="refAuthor">Nottingham, M.</span>, and <span class="refAuthor">D. Orchard</span>, <span class="refTitle">"URI Template"</span>, <span class="seriesInfo">RFC 6570</span>, <span class="seriesInfo">DOI 10.17487/RFC6570</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc6570">https://www.rfc-editor.org/rfc/rfc6570</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC6690">[RFC6690]</dt>
-        <dd>
-<span class="refAuthor">Shelby, Z.</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Link Format"</span>, <span class="seriesInfo">RFC 6690</span>, <span class="seriesInfo">DOI 10.17487/RFC6690</span>, <time datetime="2012-08" class="refDate">August 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc6690">https://www.rfc-editor.org/rfc/rfc6690</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC7252">[RFC7252]</dt>
-        <dd>
-<span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Hartke, K.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"The Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7252</span>, <span class="seriesInfo">DOI 10.17487/RFC7252</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7252">https://www.rfc-editor.org/rfc/rfc7252</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC7641">[RFC7641]</dt>
-        <dd>
-<span class="refAuthor">Hartke, K.</span>, <span class="refTitle">"Observing Resources in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7641</span>, <span class="seriesInfo">DOI 10.17487/RFC7641</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc7641">https://www.rfc-editor.org/rfc/rfc7641</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC8174">[RFC8174]</dt>
-        <dd>
-<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8174">https://www.rfc-editor.org/rfc/rfc8174</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC8516">[RFC8516]</dt>
-        <dd>
-<span class="refAuthor">Keranen, A.</span>, <span class="refTitle">""Too Many Requests" Response Code for the Constrained Application Protocol"</span>, <span class="seriesInfo">RFC 8516</span>, <span class="seriesInfo">DOI 10.17487/RFC8516</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8516">https://www.rfc-editor.org/rfc/rfc8516</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC8613">[RFC8613]</dt>
-        <dd>
-<span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Mattsson, J.</span>, <span class="refAuthor">Palombini, F.</span>, and <span class="refAuthor">L. Seitz</span>, <span class="refTitle">"Object Security for Constrained RESTful Environments (OSCORE)"</span>, <span class="seriesInfo">RFC 8613</span>, <span class="seriesInfo">DOI 10.17487/RFC8613</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8613">https://www.rfc-editor.org/rfc/rfc8613</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC9176">[RFC9176]</dt>
-      <dd>
-<span class="refAuthor">Amsüss, C., Ed.</span>, <span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Koster, M.</span>, <span class="refAuthor">Bormann, C.</span>, and <span class="refAuthor">P. van der Stok</span>, <span class="refTitle">"Constrained RESTful Environments (CoRE) Resource Directory"</span>, <span class="seriesInfo">RFC 9176</span>, <span class="seriesInfo">DOI 10.17487/RFC9176</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9176">https://www.rfc-editor.org/rfc/rfc9176</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-</dl>
-</section>
-</div>
-<div id="sec-informative-references">
-<section id="section-8.2">
-        <h3 id="name-informative-references">
-<a href="#name-informative-references" class="section-name selfRef">Informative References</a>
-        </h3>
-<dl class="references">
-<dt id="I-D.hartke-t2trg-coral-pubsub">[I-D.hartke-t2trg-coral-pubsub]</dt>
-        <dd>
-<span class="refAuthor">Hartke, K.</span>, <span class="refTitle">"Publish/Subscribe over the Constrained Application Protocol (CoAP) using the Constrained RESTful Application Language (CoRAL)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-hartke-t2trg-coral-pubsub-01</span>, <time datetime="2020-05-09" class="refDate">9 May 2020</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-hartke-t2trg-coral-pubsub-01">https://datatracker.ietf.org/doc/html/draft-hartke-t2trg-coral-pubsub-01</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="I-D.ietf-ace-key-groupcomm">[I-D.ietf-ace-key-groupcomm]</dt>
-        <dd>
-<span class="refAuthor">Palombini, F.</span> and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Key Provisioning for Group Communication using ACE"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-key-groupcomm-18</span>, <time datetime="2024-01-16" class="refDate">16 January 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-18">https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-18</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="I-D.ietf-ace-oscore-gm-admin">[I-D.ietf-ace-oscore-gm-admin]</dt>
-        <dd>
-<span class="refAuthor">Tiloca, M.</span>, <span class="refAuthor">Höglund, R.</span>, <span class="refAuthor">Van der Stok, P.</span>, and <span class="refAuthor">F. Palombini</span>, <span class="refTitle">"Admin Interface for the OSCORE Group Manager"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-oscore-gm-admin-11</span>, <time datetime="2024-03-04" class="refDate">4 March 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-11">https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-11</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="I-D.ietf-ace-pubsub-profile">[I-D.ietf-ace-pubsub-profile]</dt>
-        <dd>
-<span class="refAuthor">Palombini, F.</span>, <span class="refAuthor">Sengul, C.</span>, and <span class="refAuthor">M. Tiloca</span>, <span class="refTitle">"Publish-Subscribe Profile for Authentication and Authorization for Constrained Environments (ACE)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ace-pubsub-profile-09</span>, <time datetime="2024-03-04" class="refDate">4 March 2024</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-09">https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-09</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC8126">[RFC8126]</dt>
-        <dd>
-<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8126">https://www.rfc-editor.org/rfc/rfc8126</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC8288">[RFC8288]</dt>
-        <dd>
-<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"Web Linking"</span>, <span class="seriesInfo">RFC 8288</span>, <span class="seriesInfo">DOI 10.17487/RFC8288</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8288">https://www.rfc-editor.org/rfc/rfc8288</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC9052">[RFC9052]</dt>
-        <dd>
-<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE): Structures and Process"</span>, <span class="seriesInfo">STD 96</span>, <span class="seriesInfo">RFC 9052</span>, <span class="seriesInfo">DOI 10.17487/RFC9052</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9052">https://www.rfc-editor.org/rfc/rfc9052</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC9053">[RFC9053]</dt>
-        <dd>
-<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE): Initial Algorithms"</span>, <span class="seriesInfo">RFC 9053</span>, <span class="seriesInfo">DOI 10.17487/RFC9053</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9053">https://www.rfc-editor.org/rfc/rfc9053</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC9147">[RFC9147]</dt>
-        <dd>
-<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 9147</span>, <span class="seriesInfo">DOI 10.17487/RFC9147</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9147">https://www.rfc-editor.org/rfc/rfc9147</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC9200">[RFC9200]</dt>
-        <dd>
-<span class="refAuthor">Seitz, L.</span>, <span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Wahlstroem, E.</span>, <span class="refAuthor">Erdtman, S.</span>, and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)"</span>, <span class="seriesInfo">RFC 9200</span>, <span class="seriesInfo">DOI 10.17487/RFC9200</span>, <time datetime="2022-08" class="refDate">August 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9200">https://www.rfc-editor.org/rfc/rfc9200</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-<dt id="RFC9338">[RFC9338]</dt>
-      <dd>
-<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE): Countersignatures"</span>, <span class="seriesInfo">STD 96</span>, <span class="seriesInfo">RFC 9338</span>, <span class="seriesInfo">DOI 10.17487/RFC9338</span>, <time datetime="2022-12" class="refDate">December 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9338">https://www.rfc-editor.org/rfc/rfc9338</a>&gt;</span>. </dd>
-<dd class="break"></dd>
-</dl>
-</section>
-</div>
-</section>
-<div id="contributors">
-<section id="appendix-A">
-      <h2 id="name-contributors">
-<a href="#name-contributors" class="section-name selfRef">Contributors</a>
-      </h2>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Marco Tiloca</span></div>
-<div dir="auto" class="left"><span class="org">RISE AB</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:marco.tiloca@ri.se" class="email">marco.tiloca@ri.se</a>
-</div>
-</address>
-<p id="appendix-A-1">Marco offered comprehensive reviews and insightful guidance on the recent iterations of this document. His contributions were particularly notable in the Security Considerations section, among others.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
-</section>
-</div>
-<div id="authors-addresses">
-<section id="appendix-B">
-      <h2 id="name-authors-addresses">
-<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
-      </h2>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Jaime Jimenez</span></div>
-<div dir="auto" class="left"><span class="org">Ericsson</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:jaime@iki.fi" class="email">jaime@iki.fi</a>
-</div>
-</address>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Michael Koster</span></div>
-<div dir="auto" class="left"><span class="org">Dogtiger Labs</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:michaeljohnkoster@gmail.com" class="email">michaeljohnkoster@gmail.com</a>
-</div>
-</address>
-<address class="vcard">
-        <div dir="auto" class="left"><span class="fn nameRole">Ari Keranen</span></div>
-<div dir="auto" class="left"><span class="org">Ericsson</span></div>
-<div class="email">
-<span>Email:</span>
-<a href="mailto:ari.keranen@ericsson.com" class="email">ari.keranen@ericsson.com</a>
-</div>
-</address>
-</section>
-</div>
-<script>const toc = document.getElementById("toc");
-toc.querySelector("h2").addEventListener("click", e => {
-  toc.classList.toggle("active");
-});
-toc.querySelector("nav").addEventListener("click", e => {
-  toc.classList.remove("active");
-});
-</script>
-</body>
-</html>
diff --git a/ps-rev/draft-ietf-core-coap-pubsub.txt b/ps-rev/draft-ietf-core-coap-pubsub.txt
deleted file mode 100644
index 6b967f8..0000000
--- a/ps-rev/draft-ietf-core-coap-pubsub.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-
-CoRE Working Group                                            J. Jimenez
-Internet-Draft                                                  Ericsson
-Intended status: Standards Track                               M. Koster
-Expires: 20 October 2024                                   Dogtiger Labs
-                                                              A. Keranen
-                                                                Ericsson
-                                                           18 April 2024
-
-
-    A publish-subscribe architecture for the Constrained Application
-                            Protocol (CoAP)
-                   draft-ietf-core-coap-pubsub-latest
-
-Abstract
-
-   This document describes a publish-subscribe architecture for the
-   Constrained Application Protocol (CoAP), extending the capabilities
-   of CoAP communications for supporting endpoints with long breaks in
-   connectivity and/or up-time.  CoAP clients publish on and subscribe
-   to a topic via a corresponding topic resource at a CoAP server acting
-   as broker.
-
-About This Document
-
-   This note is to be removed before publishing as an RFC.
-
-   Status information for this document may be found at
-   https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/.
-
-   Discussion of this document takes place on the core Working Group
-   mailing list (mailto:core@ietf.org), which is archived at
-   https://mailarchive.ietf.org/arch/browse/core/.  Subscribe at
-   https://www.ietf.org/mailman/listinfo/core/.
-
-   Source for this draft and an issue tracker can be found at
-   https://github.com/core-wg/coap-pubsub.
-
-Status of This Memo
-
-   This Internet-Draft is submitted in full conformance with the
-   provisions of BCP 78 and BCP 79.
-
-   Internet-Drafts are working documents of the Internet Engineering
-   Task Force (IETF).  Note that other groups may also distribute
-   working documents as Internet-Drafts.  The list of current Internet-
-   Drafts is at https://datatracker.ietf.org/drafts/current/.
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 1]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   Internet-Drafts are draft documents valid for a maximum of six months
-   and may be updated, replaced, or obsoleted by other documents at any
-   time.  It is inappropriate to use Internet-Drafts as reference
-   material or to cite them other than as "work in progress."
-
-   This Internet-Draft will expire on 20 October 2024.
-
-Copyright Notice
-
-   Copyright (c) 2024 IETF Trust and the persons identified as the
-   document authors.  All rights reserved.
-
-   This document is subject to BCP 78 and the IETF Trust's Legal
-   Provisions Relating to IETF Documents (https://trustee.ietf.org/
-   license-info) in effect on the date of publication of this document.
-   Please review these documents carefully, as they describe your rights
-   and restrictions with respect to this document.  Code Components
-   extracted from this document must include Revised BSD License text as
-   described in Section 4.e of the Trust Legal Provisions and are
-   provided without warranty as described in the Revised BSD License.
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
-     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
-     1.2.  CoAP Publish-Subscribe Architecture . . . . . . . . . . .   5
-     1.3.  Managing Topics . . . . . . . . . . . . . . . . . . . . .   6
-   2.  Pub-Sub Topics  . . . . . . . . . . . . . . . . . . . . . . .   7
-     2.1.  Collection Representation . . . . . . . . . . . . . . . .   7
-     2.2.  Topic-Configuration Representation  . . . . . . . . . . .   8
-       2.2.1.  Topic Properties  . . . . . . . . . . . . . . . . . .   8
-     2.3.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   9
-       2.3.1.  Broker Discovery  . . . . . . . . . . . . . . . . . .   9
-       2.3.2.  Topic Collection Discovery  . . . . . . . . . . . . .  10
-       2.3.3.  Topic-Configuration Discovery . . . . . . . . . . . .  10
-       2.3.4.  Topic-Data Discovery  . . . . . . . . . . . . . . . .  11
-     2.4.  Topic Collection Interactions . . . . . . . . . . . . . .  11
-       2.4.1.  Retrieving all topic-configurations . . . . . . . . .  11
-       2.4.2.  Getting topic-configurations by Properties  . . . . .  12
-       2.4.3.  Creating a Topic  . . . . . . . . . . . . . . . . . .  13
-     2.5.  Topic-Configuration Interactions  . . . . . . . . . . . .  14
-       2.5.1.  Getting a topic-configuration . . . . . . . . . . . .  14
-       2.5.2.  Getting part of a topic-configuration . . . . . . . .  15
-       2.5.3.  Updating the topic-configuration  . . . . . . . . . .  16
-       2.5.4.  Updating the topic-configuration with iPATCH  . . . .  18
-       2.5.5.  Deleting a topic-configuration  . . . . . . . . . . .  19
-   3.  Publish and Subscribe . . . . . . . . . . . . . . . . . . . .  19
-     3.1.  Topic Lifecycle . . . . . . . . . . . . . . . . . . . . .  20
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 2]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-     3.2.  Topic-Data Interactions . . . . . . . . . . . . . . . . .  20
-       3.2.1.  Publish . . . . . . . . . . . . . . . . . . . . . . .  21
-       3.2.2.  Subscribe . . . . . . . . . . . . . . . . . . . . . .  22
-       3.2.3.  Unsubscribe . . . . . . . . . . . . . . . . . . . . .  23
-       3.2.4.  Delete topic-data . . . . . . . . . . . . . . . . . .  24
-     3.3.  Read latest data  . . . . . . . . . . . . . . . . . . . .  24
-     3.4.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .  25
-   4.  CoAP Pubsub Parameters  . . . . . . . . . . . . . . . . . . .  25
-   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
-   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  27
-     6.1.  Media Type  . . . . . . . . . . . . . . . . . . . . . . .  27
-     6.2.  Content-Format  . . . . . . . . . . . . . . . . . . . . .  28
-     6.3.  CoAP Pubsub Parameters  . . . . . . . . . . . . . . . . .  28
-     6.4.  Resource Types  . . . . . . . . . . . . . . . . . . . . .  29
-   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  30
-   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  30
-     Normative References  . . . . . . . . . . . . . . . . . . . . .  30
-     Informative References  . . . . . . . . . . . . . . . . . . . .  31
-   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  32
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33
-
-1.  Introduction
-
-   The Constrained Application Protocol (CoAP) [RFC7252] supports
-   machine-to-machine communication across networks of constrained
-   devices and constrained networks.  CoAP uses a request/response model
-   where clients make requests to servers in order to request actions on
-   resources.  Depending on the situation the same device may act either
-   as a server, a client, or both.
-
-   One important class of constrained devices includes devices that are
-   intended to run for years from a small battery, or by scavenging
-   energy from their environment.  These devices have limited up-time
-   because they spend most of their time in a sleeping state with no
-   network connectivity.  Another important class of nodes are devices
-   with limited reachability due to middle-boxes like Network Address
-   Translators (NATs) and firewalls.
-
-   For these nodes, the client/server-oriented architecture of REST can
-   be challenging when interactions are not initiated by the devices
-   themselves.  A publish/subscribe-oriented architecture where nodes
-   exchange data via topics through a broker entity might fit these
-   nodes better.
-
-   This document applies the idea of broker-based publish-subscribe to
-   Constrained RESTful Environments using CoAP.  It defines a broker
-   that allows to create, discover subscribe and publish on topics.
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 3]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-1.1.  Terminology
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
-   "OPTIONAL" in this document are to be interpreted as described in
-   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
-   capitals, as shown here.
-
-   This specification requires readers to be familiar with all the terms
-   and concepts that are discussed in [RFC8288] and [RFC6690].  Readers
-   should also be familiar with the terms and concepts discussed in
-   [RFC7252], [RFC9176] and [RFC7641].  The URI template format
-   [RFC6570] is used to describe the REST API defined in this
-   specification.
-
-   This specification makes use of the following terminology:
-
-   publish-subscribe (pub/sub):
-      A message communication model where messages associated with
-      specific topics are sent to a broker.  Interested parties, i.e.
-      subscribers, receive these topic-based messages from the broker
-      without the original sender knowing the recipients.  The broker
-      handles matching and delivering these messages to the appropriate
-      subscribers.
-
-   publishers and subscribers:
-      CoAP clients can act as publishers or as subscribers.  Publishers
-      send CoAP messages (publications) to the broker on specific
-      topics.  Subscribers have an ongoing observation relation
-      (subscription) to a topic.  Both roles operate without any mutual
-      knowledge, guided by their respective topic interests.
-
-   topic collection:
-      A set of topic configurations.  A topic collection is hosted as
-      one collection resource at the broker, and its representation is
-      the list of links to the topic resources corresponding to each
-      topic configuration.
-
-   topic-configuration:
-      A set of information concerning a topic, including its
-      configuration and other metadata.  A topic configuration is hosted
-      as one topic resource at the broker, and its representation is the
-      set of configuration information concerning the topic.  All the
-      topic resources associated with the same topic collection share a
-      common base URI, i.e., the URI of the collection resource.
-      Throughout this document the word "topic" and "topic-
-      configuration" can be used interchangeably.
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 4]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   topic-data resource:
-      A resource where clients can publish data and/or subscribe to data
-      for a specific topic.  The representation of the topic resource
-      corresponding to such a topic also specifies the URI to the
-      present topic-data resource.
-
-   broker:
-      A CoAP server that hosts one or more topic collections with their
-      topic-configurations, and also topic-data resources.  The broker
-      is responsible for the store-and-forward of state update
-      representations, for the topics for which it hosts the
-      corresponding topic-data resources.  The broker is also
-      responsible of handling the topic lifecycle as defined in
-      Section 3.1.  The creation, configuration, and discovery of topics
-      at a broker is specified in Section 2.
-
-1.2.  CoAP Publish-Subscribe Architecture
-
-   Figure 1 shows a simple Publish/Subscribe architecture over CoAP.
-
-   Topics are created by the broker, but the initial configuration can
-   be proposed by a client (e.g., a publisher or a dedicated
-   administrator) over the RESTful interface of a corresponding topic
-   resource hosted by the broker.
-
-   Publishers submit their data over the RESTful interface of a topic-
-   data resource corresponding to the topic, which may be hosted by the
-   broker.  Subscribers to a topic are notified of new publications by
-   using Observe [RFC7641] on the corresponding topic-data resource.
-
-   The broker is responsible for the store-and-forward of state update
-   representations between CoAP clients.  Subscribers observing a
-   resource will receive notifications, the delivery of which is done on
-   a best-effort basis.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 5]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-           CoAP                      CoAP                 CoAP
-           clients                  server                clients
-         .-----------.          .----------.  observe  .------------.
-         |           | publish  |          |<----------+            |
-         | publisher +--------->+          +---------->| subscriber |
-         |           |          |          +---------->|            |
-         '-----------'          |          |           '------------'
-              ...               |  broker  |                ...
-              ...               |          |                ...
-         .-----------.          |          |  observe  .------------.
-         |           | publish  |          |<----------+            |
-         | publisher +--------->|          +---------->| subscriber |
-         |           |          |          +---------->|            |
-         '-----------'          '----------'           '------------'
-
-             Figure 1: Publish-subscribe architecture over CoAP
-
-   This document describes two sets of interactions, interactions to
-   configure topics and their lifecycle (see Section 2.5) and
-   interactions about the topic-data (see Section 3.2).
-
-   Topic-configuration interactions are discovery, create, read
-   configuration, update configuration, and delete configuration.  These
-   operations handle the management of the topics.
-
-   Topic-data interactions are publish, subscribe, unsubscribe, read,
-   and delete.  These operations are oriented on how data is transferred
-   from a publisher to a subscriber.
-
-1.3.  Managing Topics
-
-   Figure 2 shows the resources related to a Topic Collection that can
-   be managed at the Broker.
-
-                   ___
-         topic    /   \
-       collection \___/
-        resource       \
-                        \____________________
-                         \___    \___        \___
-                         /   \   /   \  ...  /   \   topic resources
-                         \___/   \___/       \___/
-
-                      Figure 2: Resources of a Broker
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 6]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   The Broker exports one or more topic-collection resources, with
-   resource type "core.ps.coll" defined in Section 6 of this document.
-   The interfaces for the topic-collection resource is defined in
-   Section 2.4.
-
-   A topic-collection resource can have topic resources as its child
-   resources, with resource type "core.ps.conf".
-
-2.  Pub-Sub Topics
-
-   The configuration side of a "publish/subscribe broker" consists of a
-   collection of topics.  These topics as well as the collection itself
-   are exposed by a CoAP server as resources (see Figure 3).  Each topic
-   is associated with a topic configuration resource and a topic-data
-   resource.  The topic configuration resource is used by a client
-   creating or administering a topic.  The topic-data resource is used
-   by the publishers and the subscribers to a topic.
-
-                       ___
-             topic    /   \
-           collection \___/
-            resource       \
-                            \___________________________
-                             \          \               \
-                              \ ......   \ ......        \ ......
-                      topic  : \___  :  : \___  :       : \___  :
-              configuration  : / * \ :  : / * \ :       : / * \ :
-                   resource  : \_|_/ :  : \_|_/ :       : \_|_/ :
-                             ....|....  ....|....       ....|....
-                             ....|....  ....|....       ....|....
-                             :  _|_  :  :  _|_  :  ...  :  _|_  :
-                 topic-data  : /   \ :  : /   \ :       : /   \ :
-                   resource  : \___/ :  : \___/ :       : \___/ :
-                             :.......:  :.......:       :.......:
-                            \_________/\_________/ ... \_________/
-                              topic 1    topic 2         topic n
-
-            Figure 3: Topic and topic-data resources of a topic
-
-2.1.  Collection Representation
-
-   Each topic configuration is represented as a link, where the link
-   target is the URI of the corresponding topic resource.
-
-   Publication and subscription to a topic occur at a link, where the
-   link target is the URI of the corresponding topic-data resource.
-   Such a link is specified by the topic-data entry within the topic
-   resource (see Section 2.2.1).
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 7]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   A topic resource with a topic-data link can also be simply called
-   "topic".
-
-   The list of links to the topic resources can be retrieved from the
-   associated topic collection resource, and represented as a Link
-   Format document [RFC6690]where each such link specifies the link
-   target attribute 'rt' (Resource Type), with value "core.ps.conf"
-   defined in this document.
-
-2.2.  Topic-Configuration Representation
-
-   A CoAP client can create a new topic by submitting an initial
-   configuration for the topic (see Section 2.4.3).  It can also read
-   and update the configuration of existing topics and delete them when
-   they are no longer needed (see Section 2.5).
-
-   The configuration of a topic itself consists of a set of properties
-   that can be set by a client or by the broker.  The topic-
-   configuration is represented as a CBOR map containing the
-   configuration properties of the topic as top-level elements.
-
-   Unless specified otherwise, these are defined in this document and
-   their CBOR abbreviations are defined in Section 4.
-
-2.2.1.  Topic Properties
-
-   The CBOR map includes the following configuration parameters, whose
-   CBOR abbreviations are defined in Section 4 of this document.
-
-   *  'topic-name': A required field used as an application identifier.
-      It encodes the topic name as a CBOR text string.  Examples of
-      topic names include human-readable strings (e.g., "room2"), UUIDs,
-      or other values.
-
-   *  'topic-data': A required field (optional during creation)
-      containing the URI of the topic-data resource for publishing/
-      subscribing to this topic.  It encodes the URI as a CBOR text
-      string.
-
-   *  'resource-type': A required field used to indicate the resource
-      type of the topic-data resource for the topic.  It encodes the
-      resource type as a CBOR text string.  The value should be
-      "core.ps.conf".
-
-   *  'media-type': An optional field used to indicate the media type of
-      the topic-data resource for the topic.  It encodes the media type
-      as a this information as the integer identifier of the CoAP
-      content-format (e.g., value is "50" for "application/json").
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 8]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   *  'topic-type': An optional field used to indicate the attribute or
-      property of the topic-data resource for the topic.  It encodes the
-      attribute as a CBOR text string.  Example attributes include
-      "temperature".
-
-   *  'expiration-date': An optional field used to indicate the
-      expiration date of the topic.  It encodes the expiration date as a
-      CBOR text string.  The value should be a date string in ISO 8601
-      format (e.g., "2023-03-31T23:59:59Z").  The broker can use this
-      field to automatically remove topics that are no longer valid.  If
-      this field is not present, the topic will not expire
-      automatically.
-
-   *  'max-subscribers': An optional field used to indicate the maximum
-      number of simultaneous subscribers allowed for the topic.  It
-      encodes the maximum number as an unsigned CBOR integer.  If this
-      field is not present, there is no limit to the number of
-      simultaneous subscribers allowed.  The broker can use this field
-      to limit the number of subscribers for the topic.  The default
-      value for this field has been set to 100 subscribers.
-
-   *  'observer-check': An optional field that controls the maximum
-      number of seconds between two consecutive Observe notifications
-      sent as Confirmable messages to each topic subscriber.  Encoded as
-      a CBOR unsigned integer greater than 0, it ensures subscribers who
-      have lost interest and silently forgotten the observation do not
-      remain indefinitely on the server's observer list.  If another
-      CoAP server hosts the topic-data resource, that server is
-      responsible for applying the observer-check value.  The default
-      value for this field is 86400, as defined in [RFC7641], which
-      corresponds to 24 hours.
-
-2.3.  Discovery
-
-   A client can perform a discovery of: the broker; the topic collection
-   resources and topic resources hosted by the broker; and the topic-
-   data resources associated with those topic resources.
-
-2.3.1.  Broker Discovery
-
-   CoAP clients MAY discover brokers by using CoAP Simple Discovery, via
-   multicast, through a Resource Directory (RD) [RFC9176] or by other
-   means specified in extensions to [RFC7252].  Brokers MAY register
-   with a RD by following the steps on Section 5 of [RFC9176] with the
-   resource type set to "core.ps" as defined in Section 6 of this
-   document.
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024                [Page 9]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   The following example shows an endpoint discovering a broker using
-   the "core.ps" resource type over a multicast network.  Brokers within
-   the multicast scope will answer the query.
-
-   => 0.01 GET
-      Uri-Path: coap://[ff0x::fe]/.well-known/core
-      Resource-Type: core.ps
-
-   <= 2.05 Content
-      Payload:
-      Content-Format: 40 (application/link-format)
-      <coap://mythinguri.com/broker/v1>; rt=core.ps
-
-2.3.2.  Topic Collection Discovery
-
-   A Broker SHOULD offer a topic discovery entry point to enable clients
-   to find topics of interest.  The resource entry point is the topic
-   collection resource collecting the topic configurations for those
-   topics (see Section 1.2.2 of [RFC6690]) and is identified by the
-   resource type "core.ps.coll".
-
-   The specific resource path is left for implementations, examples in
-   this document use the "/ps" path.  The interactions with a topic
-   collection are further defined in Section 2.4.
-
-   Since the representation of the topic collection resource includes
-   the links to the associated topic resources, it is not required to
-   locate those links under "/.well-known/core", also in order to limit
-   the size of the Link Format document returned as result of the
-   discovery.
-
-   Example:
-
-   => 0.01 GET
-      Uri-Path: .well-known/core
-      Resource-Type: core.ps.coll
-
-      <= 2.05 Content
-      Content-Format: 40 (application/link-format)
-      </ps1>;rt="core.ps.coll";ct=40,
-      </other/path>;rt="core.ps.coll";ct=40
-
-2.3.3.  Topic-Configuration Discovery
-
-   Each topic collection is associated with a group of topic resources,
-   each detailing the configuration of its respective topic (refer to
-   Section 2.2.1).  Each topic resource is identified by the resource
-   type "core.ps.conf".
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 10]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   Below is an example of discovery via /.well-known/core with
-   rt=core.ps.conf that returns a list of topics, as the list of links
-   to the corresponding topic resources.
-
-   => 0.01 GET
-      Uri-Path: .well-known/core
-      Resource-Type: core.ps.conf
-
-   <= 2.05 Content
-      Content-Format: 40 (application/link-format)
-      </ps1/h9392>;rt="core.ps.conf";ct=TBD,
-      </other/path/2e3570>;rt=core.ps.conf;ct=TBD
-
-2.3.4.  Topic-Data Discovery
-
-   Within a topic, there is the topic-data property containing the URI
-   of the topic-data resource that a CoAP client can subscribe and
-   publish to.  Resources exposing resources of the topic-data type are
-   expected to use the resource type 'core.ps.data'.
-
-   The topic-data contains the URI of the topic-data resource for
-   publishing and subscribing.  So retrieving the topic configuration
-   will also provide the URL of the topic-data (see Section 2.5.1).
-
-   It is also possible to discover a list of topic-data resources by
-   sending a request to the collection with with rt=core.ps.data
-   resources as shown below.
-
-   => 0.01 GET
-      Uri-Path: /ps
-      Resource-Type: core.ps.data
-
-   <= 2.05 Content
-      Content-Format: 40 (application/link-format)
-      </ps/data/62e4f8d>; rt=core.ps.data; obs
-
-2.4.  Topic Collection Interactions
-
-   These are the interactions that can happen directly with a specific
-   topic collection.
-
-2.4.1.  Retrieving all topic-configurations
-
-   A client can request a collection of the topics present in the broker
-   by making a GET request to the collection URI.
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 11]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   On success, the server returns a 2.05 (Content) response, specifying
-   the list of links to topic resources associated with this topic
-   collection (see Section 2.2).
-
-   Depending on its granted permissions, a client MAY retrieve a
-   different list of links, corresponding to the topics that the client
-   is authorized to access.
-
-   Example:
-
-   => 0.01 GET
-      Uri-Path: ps
-
-   <= 2.05 Content
-      Content-Format: 40 (application/link-format)
-      </ps/h9392>;rt="core.ps.conf",
-      </ps/2e3570>; rt="core.ps.conf"
-
-2.4.2.  Getting topic-configurations by Properties
-
-   A client can filter a collection of topics by submitting the
-   representation of a topic filter (see Section 2.5.2) in a FETCH
-   request to the topic collection URI.
-
-   On success, the server returns a 2.05 (Content) response with a
-   representation of a list of topics in the collection (see
-   Section 2.3.3) that match the filter in CoRE link format [RFC6690].
-
-   Upon success, the server responds with a 2.05 (Content), providing a
-   list of links to topic resources associated with this topic
-   collection that match the request's filter criteria (refer to
-   Section 2.3.3).  A positive match happens only when each request
-   parameter is present with the indicated value in the topic resource
-   representation.
-
-   Example:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 12]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.05 FETCH
-      Uri-Path: ps
-      Content-Format: TBD (application/pubsub+cbor)
-
-      {
-        "resource-type": "core.ps.conf",
-        "topic-type": "temperature"
-      }
-
-   <= 2.05 Content
-      Content-Format: 40 (application/link-format)
-      </ps/2e3570>;rt="core.ps.conf"
-
-2.4.3.  Creating a Topic
-
-   A client can add a new topic-configurations to a collection of topics
-   by submitting an initial representation of the initial topic resource
-   (see Section 2.2) in a POST request to the topic collection URI.  The
-   request MUST specify at least a subset of the properties in
-   Section 2.2.1, namely: topic-name and resource-type.
-
-   Please note that the topic will NOT be fully created until a
-   publisher has published some data to it (See Section 3.1).
-
-   On success, the server returns a 2.01 (Created) response, indicating
-   the Location-Path of the new topic and the current representation of
-   the topic resource.  The response payload includes a CBOR map with
-   key-value pairs.  The response must include the required topic
-   properties (see Section 2.2.1), namely: "topic-name", "resource-type"
-   and "topic-data".  It may also include a number of optional
-   properties too.
-
-   If requirements are defined for the client to create the topic as
-   requested and the broker does not successfully assess that those
-   requirements are met, then the broker MUST respond with a 4.03
-   (Forbidden) error.  The response MUST have Content-Format set to
-   "application/core-pubsub+cbor".
-
-   The broker MUST issue a 4.00 (Bad Request) error if a received
-   parameter is invalid, unrecognized, or if the topic-name is already
-   in use or otherwise invalid.
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 13]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.02 POST
-      Uri-Path: ps
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-      TBD (this should be a CBOR map with the mandatory parameters)
-      {
-        "topic-name": "living-room-sensor",
-        "resource-type": "core.ps.conf"
-      }
-
-   <= 2.01 Created
-      Location-Path: ps/h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-
-      TBD (this should be a CBOR map)
-      {
-        "topic-name": "living-room-sensor",
-        "topic-data": "ps/data/1bd0d6d",
-        "resource-type": "core.ps.conf"
-      }
-
-2.5.  Topic-Configuration Interactions
-
-   These are the interactions that can happen at the topic resource
-   level.
-
-2.5.1.  Getting a topic-configuration
-
-   A client can read the configuration of a topic by making a GET
-   request to the topic resource URI.
-
-   On success, the server returns a 2.05 (Content) response with a
-   partial representation of the topic resource, as specified in
-   Section 2.2.  The partial representation includes only the
-   configuration parameters such that they are present and have the same
-   value in both the current topic configuration as well as in the FETCH
-   request.
-
-   If requirements are defined for the client to create the topic as
-   requested and the broker does not successfully assess that those
-   requirements are met, then the broker MUST respond with a 4.03
-   (Forbidden) error.
-
-   The response payload is a CBOR map, whose possible entries are
-   specified in Section 2.2 and use the same abbreviations defined in
-   Section 4.
-
-   For example, below is a request on the topic "ps/h9392":
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 14]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.01 GET
-      Uri-Path: ps
-      Uri-Path: h9392
-
-   <= 2.05 Content
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-      {
-         "topic-name" : "living-room-sensor",
-         "topic-data" : "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "temperature",
-         "expiration-date": "2023-04-00T23:59:59Z",
-         "max-subscribers": 100
-      }
-
-2.5.2.  Getting part of a topic-configuration
-
-   A client can read the configuration of a topic by making a FETCH
-   request to the topic resource URI with a filter for specific
-   parameters.  This is done in order to retrieve part of the current
-   topic resource.
-
-   The request contains a CBOR map with a configuration filter or 'conf-
-   filter', a CBOR array with CBOR abbreviation.  Each element of the
-   array specifies one requested configuration parameter of the current
-   topic resource (see Section 2.2).
-
-   On success, the server returns a 2.05 (Content) response with a
-   representation of the topic resource.  The response has as payload
-   the partial representation of the topic resource as specified in
-   Section 2.2.
-
-   If requirements are defined for the client to create the topic as
-   requested and the broker does not successfully assess that those
-   requirements are met, then the broker MUST respond with a 4.03
-   (Forbidden) error.
-
-   The response payload is a CBOR map, whose possible entries are
-   specified in Section 2.2 and use the same abbreviations defined in
-   Section 4.
-
-   Both request and response MUST have Content-Format set to
-   "application/core-pubsub+cbor".
-
-   Example:
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 15]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.05 FETCH
-      Uri-Path: ps
-      Uri-Path: h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-      {
-        "conf-filter": ["topic-data", "media-type"]
-      }
-
-   <= 2.05 Content
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-      {
-        "topic-data": "ps/data/1bd0d6d",
-        "media-type": "application/senml-cbor"
-      }
-
-2.5.3.  Updating the topic-configuration
-
-   A client can update a topic's configuration by submitting the updated
-   topic representation in a PUT request to the topic URI.  However, the
-   parameters "topic-name", "topic-data", and "resource-type" are
-   immutable post-creation, and any request attempting to change them
-   will be deemed invalid by the broker.
-
-   On success, the topic configuration is overwritten and server returns
-   a 2.04 (Changed) response and the current full resource
-   representation.  The broker may chose not to overwrite parameters
-   that are not explicitly modified in the request.
-
-   Note that updating the "topic-data" path will automatically cancel
-   all existing observations on it and thus will unsubscribe all
-   subscribers.  Updating the "topic-data" may happen also after it
-   being deleted, as described on {delete-topic-data}, this will in turn
-   create a new "topic-data" path for that topic configuration.
-
-   Similarly, decreasing max-subscribers will also cause that some
-   subscribers get unsubscribed.  Unsubscribed endpoints SHOULD receive
-   a final 4.04 (Not Found) response as per [RFC7641] Section 3.2.
-
-   Please note that when using PUT the topic configuration is being
-   overwritten, thus some of the optional parameters (e.g., "max-
-   subscribers", "observer-check") not included in the PUT message will
-   be reset to their default values.
-
-   Example:
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 16]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.03 PUT
-      Uri-Path: ps
-      Uri-Path: h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-
-      {
-         "topic-name": "living-room-sensor",
-         "topic-data": "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "temperature",
-         "expiration-date": "2023-04-28T23:59:59Z",
-      }
-
-   <= 2.04 Changed
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-
-      TBD (this should be a CBOR map)
-      {
-         "topic-name": "living-room-sensor",
-         "topic-data": "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "temperature",
-         "expiration-date": "2023-04-28T23:59:59Z",
-         "max-subscribers": 100,
-         "observer-check": 86400
-      }
-
-   Note that when a topic configuration changes, it may result in
-   disruptions for the subscribers.  Some potential issues that may
-   arise include:
-
-   *  Limiting the number of subscribers will cause to cancel ongoing
-      subscriptions until max-subscribers has been reached.
-
-   *  Changing the topic-data value will cancel all ongoing
-      subscriptions.
-
-   *  Changing of the expiration-date may cause to cancel ongoing
-      subscriptions if the topic expires at an earlier data.
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 17]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-2.5.4.  Updating the topic-configuration with iPATCH
-
-   A client can partially update a topic's configuration by submitting a
-   partial topic representation in an iPATCH request to the topic URI.
-   The iPATCH request allows for updating only specific fields of the
-   topic configuration while leaving the others unchanged.  As with the
-   PUT method, the parameters "topic-name", "topic-data", and "resource-
-   type" are immutable post-creation, and any request attempting to
-   change them will be deemed invalid by the broker.
-
-   On success, the server returns a 2.04 (Changed) response and the
-   current full resource representation.  The broker only updates
-   parameters that are explicitly mentioned in the request.
-
-   As with the PUT method, updating the "topic-data" path will
-   automatically cancel all existing observations on it and thus will
-   unsubscribe all subscribers.  Decreasing max-subscribers will also
-   cause some subscribers to get unsubscribed.  Unsubscribed endpoints
-   SHOULD receive a final 4.04 (Not Found) response as per [RFC7641]
-   Section 3.2.
-
-   Contrary to PUT, iPATCH operations will explicitly update some
-   parameters, leaving others unmodified.
-
-   => 0.07 iPATCH
-      Uri-Path: ps
-      Uri-Path: h9392
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-
-      {
-         "topic-type": "humidity",
-         "max-subscribers": 5
-      }
-
-   <= 2.04 Changed
-      Content-Format: TBD2 (application/core-pubsub+cbor)
-
-      TBD (this should be a CBOR map)
-      {
-         "topic-name" : "living-room-sensor",
-         "topic-data" : "ps/data/1bd0d6d",
-         "resource-type": "core.ps.conf",
-         "media-type": "application/senml-cbor",
-         "topic-type": "humidity",
-         "expiration-date": "2023-05-28T23:59:59Z",
-         "max-subscribers": 5
-      }
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 18]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   Note that when a topic configuration changes through an iPATCH
-   request, it may result in disruptions for the subscribers.  For
-   example, limiting the number of subscribers will cause to cancel
-   ongoing subscriptions until max-subscribers has been reached.
-
-2.5.5.  Deleting a topic-configuration
-
-   A client can delete a topic by making a CoAP DELETE request on the
-   topic resource URI.
-
-   On success, the server returns a 2.02 (Deleted) response.
-
-   When a topic-configuration resource is deleted, the broker MUST also
-   delete the topic-data resource, unsubscribe all subscribers by
-   removing them from the list of observers and returning a final 4.04
-   (Not Found) response as per section 3.2 of [RFC7641].
-
-   Example:
-
-   => 0.04 DELETE
-      Uri-Path: ps
-      Uri-Path: h9392
-
-   <= 2.02 Deleted
-
-3.  Publish and Subscribe
-
-   The overview of the publish/subscribe mechanism over CoAP is as
-   follows: a publisher publishes to a topic by submitting the data in a
-   PUT request to a topic-data resource and subscribers subscribe to a
-   topic by submitting a GET request with Observe option set to 0
-   (register) to a topic-data resource.  When resource state changes,
-   subscribers observing the resource [RFC7641] at that time will
-   receive a notification.
-
-   A topic-data resource does not exist until some initial data has been
-   published to it.  Before initial data publication, a GET request to
-   the topic-data resource URI results in a 4.04 (Not Found) response.
-   If such a "half created" topic is undesired, the creator of the topic
-   can simply immediately publish some initial placeholder data to make
-   the topic "fully created" (see Section 3.1).
-
-   URIs for topic resources are broker-generated (see Section 2.4.3).
-   There is no necessary URI pattern dependence between the URI where
-   the topic-data exists and the URI of the topic-configuration
-   resource.
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 19]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-3.1.  Topic Lifecycle
-
-   When a topic is newly created, it is first placed by the broker into
-   the HALF CREATED state (see Figure 4).  In this state, a client can
-   read and update the configuration of the topic and delete the topic.
-   A publisher can publish to the topic-data resource.  However, a
-   subscriber cannot yet subscribe to the topic-data resource nor read
-   the latest data.
-
-                    HALF                          FULLY
-                   CREATED       Delete          CREATED
-                    ____        topic-data        ____     Publish
-    ------------>  |    |  <-------------------  |    |  ------------.
-       Create      |    |                        |    |               |
-                   |____|  ------------------->  |____|  <-----------'
-                          \      Publish      /            Subscribe
-                   |   ^   \       ___       /   |   ^
-             Read/ |   |    '-->  |   |  <--'    |   | Read/
-            Update |   |  Delete  |___|  Delete  |   | Update
-                    '-'   Topic          Topic    '-'
-                                 DELETED
-
-                       Figure 4: Lifecycle of a Topic
-
-   After a publisher publishes to the topic-data for the first time, the
-   topic is placed into the FULLY CREATED state.  In this state, a
-   client can read data by means of a GET request without observe.  A
-   publisher can publish to the topic-data resource and a subscriber can
-   observe the topic-data resource.
-
-   When a client deletes a topic-configuration resource, the topic is
-   placed into the DELETED state and shortly after removed from the
-   server.  In this state, all subscribers are removed from the list of
-   observers of the topic-data resource and no further interactions with
-   the topic are possible.
-
-   When a client deletes a topic-data, the topic is placed into the HALF
-   CREATED state, where clients can read, update and delete the topic-
-   configuration and await for a publisher to begin publication.
-
-3.2.  Topic-Data Interactions
-
-   Interactions with the topic-data resource are covered in this
-   section.
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 20]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-3.2.1.  Publish
-
-   A topic-configuration with a topic-data resource must have been
-   created in order to publish data to it (See Section 2.4.3) and be in
-   the half-created or fully-created state in order to the publish
-   operation to work (see Section 3.1).
-
-   A client can publish data to a topic by submitting the data in a PUT
-   request to the topic-data URI as indicated in its topic resource
-   property.  Please note that the topic-data URI is not the same as the
-   topic-configuration URI used for configuring the topic (see
-   Section 2.2).
-
-   On success, the server returns a 2.04 (Updated) response.  However,
-   when data is published to the topic for the first time, the server
-   instead MUST return a 2.01 (Created) response and set the topic in
-   the fully-created state (see Section 3.1).
-
-   If the request does not have an acceptable content-format, the server
-   returns a 4.15 (Unsupported Content-Format) response.
-
-   If the client is sending publications too fast, the server returns a
-   4.29 (Too Many Requests) response [RFC8516].
-
-   Example of first publication:
-
-   => 0.03 PUT
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-      Content-Format: 110
-
-      {
-         "n": "coap://dev1.example.com/temperature",
-         "u": "Cel",
-         "t": 1621452122,
-         "v": 23.5
-      }
-
-   <= 2.01 Created
-
-   Example of subsequent publication:
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 21]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.03 PUT
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-      Content-Format: 110
-
-      {
-         "n": "coap://dev1.example.com/temperature",
-         "u": "Cel",
-         "t": 1621452149,
-         "v": 22.5
-      }
-
-   <= 2.04 Updated
-
-3.2.2.  Subscribe
-
-   A client can subscribe to a topic-data by sending a CoAP GET request
-   with the Observe set to 0 to subscribe to resource updates.
-   [RFC7641].
-
-   On success, the server hosting the topic-data resource MUST return
-   2.05 (Content) notifications with the data and the Observe Option.
-   Otherwise, if no Observe Option is present the client should assume
-   that the subscription was not successful.
-
-   If the topic is not yet in the fully created state (see Section 3.1)
-   the broker SHOULD return a response code 4.04 (Not Found).
-
-   The following response codes are defined for the Subscribe operation:
-
-   Success:  2.05 "Content".  Successful subscribe with observe
-      response, current value included in the response.
-
-   Failure:  4.04 "Not Found".  The topic-data does not exist.
-
-   If the 'max-subscribers' parameter has been reached, the server must
-   treat that as specified in section 4.1 of [RFC7641].  The response
-   MUST NOT include an Observe Option, the absence of which signals to
-   the subscriber that the subscription failed.
-
-   Example:
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 22]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.01 GET
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-      Observe: 0
-
-   <= 2.05 Content
-      Content-Format: 110
-      Observe: 10001
-      Max-Age: 15
-
-     {
-       "n": "urn:dev:os:32473-123456",
-       "u": "Cel",
-       "t": 1696341182,
-       "v": 19.87
-     }
-
-   <= 2.05 Content
-      Content-Format: 110
-      Observe: 10002
-      Max-Age: 15
-
-     {
-
-       "n": "urn:dev:os:32473-123456",
-       "u": "Cel",
-       "t": 1696340184,
-       "v": 21.87
-     }
-
-3.2.3.  Unsubscribe
-
-   A CoAP client can unsubscribe simply by cancelling the observation as
-   described in Section 3.6 of [RFC7641].  The client MUST either use
-   CoAP GET with the Observe Option set to 1 or send a CoAP Reset
-   message in response to a notification.  Also on Section 3.6 of
-   [RFC7641] the client can simply "forget" the observation and the
-   server will remove it from the list of observers after the next
-   notification.
-
-   As per [RFC7641] a server that transmits notifications mostly in non-
-   confirmable messages, but it MUST send a notification in a
-   confirmable message instead of a non-confirmable message at least
-   every 24 hours.
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 23]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   This value can be modified at the broker by the administrator of a
-   topic by modifying the parameter "observer-check" on Section 2.2.
-   This would allow to change the rate at which different
-   implementations verify that a subscriber is still interested in
-   observing a topic-data resource.
-
-3.2.4.  Delete topic-data
-
-   A publisher MAY delete a topic by making a CoAP DELETE request on the
-   topic-data URI.
-
-   On success, the server returns a 2.02 (Deleted) response.
-
-   When a topic-data resource is deleted, the broker SHOULD also delete
-   the topic-data parameter in the topic resource, unsubscribe all
-   subscribers by removing them from the list of observers and return a
-   final 4.04 (Not Found) response as per [RFC7641] Section 3.2.  The
-   topic is then set back to the half created state as per Section 3.1.
-
-   Example:
-
-   => 0.04 DELETE
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-
-   <= 2.02 Deleted
-
-3.3.  Read latest data
-
-   A client can get the latest published topic-data by making a GET
-   request to the topic-data URI in the broker.  Please note that
-   discovery of the topic-data parameter is a required previous step
-   (see Section 2.5.1).
-
-   On success, the server MUST return 2.05 (Content) response with the
-   data.
-
-   If the target URI does not match an existing resource or the topic is
-   not in the fully created state (see Section 3.1), the broker MUST
-   return a response code 4.04 (Not Found).
-
-   Example:
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 24]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   => 0.01 GET
-      Uri-Path: ps
-      Uri-Path: data
-      Uri-Path: 1bd0d6d
-
-   <= 2.05 Content
-      Content-Format: 110
-      Max-Age: 15
-
-      {
-         "n": "coap://dev1.example.com/temperature",
-         "u": "Cel",
-         "t": 1621452122,
-         "v": 23.5
-      }
-
-3.4.  Rate Limiting
-
-   The server hosting the topic-data may have to handle a potentially
-   large number of publishers and subscribers at the same time.  This
-   means it could become overwhelmed if it receives too many
-   publications in a short period of time.
-
-   In this situation, if a publisher is sending publications too fast,
-   the server SHOULD return a 4.29 (Too Many Requests) response
-   [RFC8516].  As described in [RFC8516], the Max-Age option [RFC7252]
-   in this response indicates the number of seconds after which the
-   client may retry.  The broker MAY also stop publishing messages from
-   that publisher for the indicated time.
-
-   When a publisher receives a 4.29 (Too Many Requests) response, it
-   MUST NOT send any new publication requests to the same topic-data
-   resource before the time indicated by the Max-Age option has passed.
-
-4.  CoAP Pubsub Parameters
-
-   This document defines parameters used in the messages exchanged
-   between a client and the broker during the topic creation and
-   configuration process (see Section 2.2).  The table below summarizes
-   them and specifies the CBOR key to use instead of the full
-   descriptive name.
-
-   Note that the media type application/core-pubsub+cbor MUST be used
-   when these parameters are transported in the respective message
-   fields.
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 25]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-         +-----------------+-----------+-----------+------------+
-         | Name            | CBOR Key  | CBOR Type | Reference  |
-         |-----------------|-----------|-----------|------------|
-         | topic-name      | TBD1      | tstr      | [RFC-XXXX] |
-         | topic-data      | TBD2      | tstr      | [RFC-XXXX] |
-         | resource-type   | TBD3      | tstr      | [RFC-XXXX] |
-         | media-type      | TBD4      | uint      | [RFC-XXXX] |
-         | topic-type      | TBD5      | tstr      | [RFC-XXXX] |
-         | expiration-date | TBD6      | tstr      | [RFC-XXXX] |
-         | max-subscribers | TBD7      | uint      | [RFC-XXXX] |
-         | observer-check  | TBD8      | uint      | [RFC-XXXX] |
-         +-----------------+-----------+-----------+------------+
-
-                      Figure 5: CoAP Pubsub Parameters
-
-5.  Security Considerations
-
-   The architecture presented in this document inherits the security
-   considerations from CoAP [RFC7252] and Observe [RFC7641], as well as
-   from Web Linking [RFC8288], Link-Format [RFC6690], and the CoRE
-   Resource Directory [RFC9176].
-
-   Communications between each client and the broker MUST be secured,
-   e.g., by using OSCORE [RFC8613] or DTLS [RFC9147].  Security
-   considerations for the used secure communication protocols apply too.
-
-   The content published on a topic by a publisher client SHOULD be
-   protected end-to-end between the publisher and all the subscribers to
-   that topic.  In such a case, it MUST be possible to assert source
-   authentication of the published data.  This can be achieved at the
-   application layer, e.g., by using COSE [RFC9052], [RFC9053],
-   [RFC9338].
-
-   Access control of clients at the broker MAY be enforced for
-   performing discovery operation, and SHOULD be enforced in a fine-
-   grained fashion for operations related to the the creation, update,
-   and deletion of topic resources, as well as for operations on topic-
-   data resources such as publication on and subscription to topics.
-   This prevents rogue clients to, among other things, repeatedly create
-   topics at the broker or publish (large) contents, which may result in
-   Denial of Service against the broker and the active subscribers.
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 26]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   Building on [I-D.ietf-ace-key-groupcomm], its application profile for
-   publish-subscribe communication with CoAP
-   [I-D.ietf-ace-pubsub-profile] provides a security model that can be
-   used in the architecture presented in this document, in order to
-   enable secure communication between the different parties as well as
-   secure, authorized operations of publishers and subscribers that
-   fulfill the requirements above.
-
-   In particular, the application profile above relies on the ACE
-   framework for Authentication and Authorization in Constrained
-   Environments (ACE) [RFC9200] and defines a method to: authorize
-   publishers and subscribers to perform operations at the broker, with
-   fine-grained access control; authorize publishers and subscribers to
-   obtain the keying material required to take part to a topic managed
-   by the broker; protect published data end-to-end between its
-   publisher and all the subscribers to the targeted topic, ensuring
-   confidentiality, integrity, and source authentication of the
-   published content end-to-end.  That approach can be extended to
-   enforce authorization and fine-grained access control for
-   administrator clients that are intended to create, update, and delete
-   topic configurations at the broker.
-
-6.  IANA Considerations
-
-   This document has the following actions for IANA.
-
-   Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]"
-   with the RFC number of this specification and delete this paragraph.
-
-6.1.  Media Type
-
-   IANA is requested to add the following Media-Type to the "Media
-   Types" registry [IANA.media-types].
-
-   +=============+=========================+=======================+
-   | Name        | Template                | Reference             |
-   +=============+=========================+=======================+
-   | pubsub+cbor | application/pubsub+cbor | RFC XXXX, Section 6.1 |
-   +-------------+-------------------------+-----------------------+
-
-            Table 1: New Media Type application/pubsub+cbor
-
-   Type name:  application
-   Subtype name:  pubsub+cbor
-   Required parameters:  N/A
-   Optional parameters:  N/A
-   Encoding considerations:  binary (CBOR data item)
-   Security considerations:  Section 5 of RFC XXXX
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 27]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   Interoperability considerations:  none
-   Published specification:  Section 6.1 of RFC XXXX
-   Applications that use this media type:  This type is used by clients
-      that create, retrieve, and update topic configurations at servers
-      acting as a pub-sub broker.
-   Fragment identifier considerations:  N/A
-   Person & email address to contact for further information:  CoRE WG
-      mailing list (core@ietf.org), or IETF Applications and Real-Time
-      Area (art@ietf.org)
-   Intended usage:  COMMON
-   Restrictions on usage:  none
-   Author/Change controller:  IETF
-   Provisional registration:  no
-
-6.2.  Content-Format
-
-   IANA has added the following Content-Formats to the "CoAP
-   Content-Formats" sub-registry, within the "Constrained RESTful
-   Environments (CoRE) Parameters" Registry [IANA.core-parameters], as
-   follows:
-
-   +=========================+================+======+===========+
-   | Content Type            | Content Coding | ID   | Reference |
-   +=========================+================+======+===========+
-   | application/pubsub+cbor | -              | TBD9 | RFC XXXX  |
-   +-------------------------+----------------+------+-----------+
-
-                     Table 2: New Content-Format
-
-   TBD9 is to be assigned from the space 256..999.
-
-6.3.  CoAP Pubsub Parameters
-
-   IANA is asked to register the following entries in the subregistry of
-   the "Constrained RESTful Environments (CoRE) Parameters" registry
-   group.
-
-   This specification establishes the "Pubsub Topic Configuration
-   Parameters" IANA registry within the "Constrained RESTful
-   Environments (CoRE) Parameters" registry group.
-
-   The columns of this registry are:
-
-   *  Name: This is a descriptive name that enables easier reference to
-      the item.  The name MUST be unique.  It is not used in the
-      encoding.
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 28]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   *  CBOR Key: This is the value used as CBOR key of the item.  These
-      values MUST be unique.  The value can be a positive integer, a
-      negative integer, or a text string.  Different ranges of values
-      use different registration policies [RFC8126].  Integer values
-      from -256 to 255 as well as text strings of length 1 are
-      designated as "Standards Action With Expert Review".  Integer
-      values from -65536 to -257 and from 256 to 65535, as well as text
-      strings of length 2 are designated as "Specification Required".
-      Integer values greater than 65535 as well as text strings of
-      length greater than 2 are designated as "Expert Review".  Integer
-      values less than -65536 are marked as "Private Use".
-
-   *  CBOR Type: This contains the CBOR type of the item, or a pointer
-      to the registry that defines its type, when that depends on
-      another item.
-
-   *  Reference: This contains a pointer to the public specification for
-      the item.
-
-   The registry is initially populated with the entries in Figure 5 of
-   Section 4.
-
-6.4.  Resource Types
-
-   IANA is asked to enter the following values in the "Resource Type
-   (rt=) Link Target Attribute Values" registry within the "Constrained
-   Restful Environments (CoRE) Parameters" registry group.
-
- Value: core.ps
- Description: Publish-Subscribe Broker
- Reference: [RFC-XXXX]
-
- Value: core.ps.coll
- Description: Topic-collection resource of a Publish-Subscribe Broker
- Reference: [RFC-XXXX]
-
- Value: core.ps.conf
- Description: Topic-configuration resource of a Publish-Subscribe Broker
- Reference: [RFC-XXXX]
-
- Value: core.ps.data
- Description: Topic-data resource of a broker
- Reference: [RFC-XXXX]
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 29]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-Acknowledgements
-
-   The current version of this document contains a substantial
-   contribution by Klaus Hartke's proposal
-   [I-D.hartke-t2trg-coral-pubsub], which defines the topic resource
-   model and structure as well as the topic lifecycle and interactions.
-   It also follows a similar architectural design as that provided by
-   Marco Tiloca's [I-D.ietf-ace-oscore-gm-admin].
-
-   The authors would like to also thank Carsten Bormann, Hannes
-   Tschofenig, Zach Shelby, Mohit Sethi, Peter van der Stok, Tim
-   Kellogg, Anders Eriksson, Goran Selander, Mikko Majanen, Olaf
-   Bergmann and Oscar Novo for their valuable contributions and reviews.
-
-References
-
-Normative References
-
-   [IANA.core-parameters]
-              IANA, "Constrained RESTful Environments (CoRE)
-              Parameters",
-              <http://www.iana.org/assignments/core-parameters>.
-
-   [IANA.media-types]
-              IANA, "Media Types",
-              <http://www.iana.org/assignments/media-types>.
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119,
-              DOI 10.17487/RFC2119, March 1997,
-              <https://www.rfc-editor.org/rfc/rfc2119>.
-
-   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
-              and D. Orchard, "URI Template", RFC 6570,
-              DOI 10.17487/RFC6570, March 2012,
-              <https://www.rfc-editor.org/rfc/rfc6570>.
-
-   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
-              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
-              <https://www.rfc-editor.org/rfc/rfc6690>.
-
-   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
-              Application Protocol (CoAP)", RFC 7252,
-              DOI 10.17487/RFC7252, June 2014,
-              <https://www.rfc-editor.org/rfc/rfc7252>.
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 30]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
-              Application Protocol (CoAP)", RFC 7641,
-              DOI 10.17487/RFC7641, September 2015,
-              <https://www.rfc-editor.org/rfc/rfc7641>.
-
-   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
-              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
-              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
-
-   [RFC8516]  Keranen, A., ""Too Many Requests" Response Code for the
-              Constrained Application Protocol", RFC 8516,
-              DOI 10.17487/RFC8516, January 2019,
-              <https://www.rfc-editor.org/rfc/rfc8516>.
-
-   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
-              "Object Security for Constrained RESTful Environments
-              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
-              <https://www.rfc-editor.org/rfc/rfc8613>.
-
-   [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
-              P. van der Stok, "Constrained RESTful Environments (CoRE)
-              Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
-              2022, <https://www.rfc-editor.org/rfc/rfc9176>.
-
-Informative References
-
-   [I-D.hartke-t2trg-coral-pubsub]
-              Hartke, K., "Publish/Subscribe over the Constrained
-              Application Protocol (CoAP) using the Constrained RESTful
-              Application Language (CoRAL)", Work in Progress, Internet-
-              Draft, draft-hartke-t2trg-coral-pubsub-01, 9 May 2020,
-              <https://datatracker.ietf.org/doc/html/draft-hartke-t2trg-
-              coral-pubsub-01>.
-
-   [I-D.ietf-ace-key-groupcomm]
-              Palombini, F. and M. Tiloca, "Key Provisioning for Group
-              Communication using ACE", Work in Progress, Internet-
-              Draft, draft-ietf-ace-key-groupcomm-18, 16 January 2024,
-              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-
-              groupcomm-18>.
-
-   [I-D.ietf-ace-oscore-gm-admin]
-              Tiloca, M., Höglund, R., Van der Stok, P., and F.
-              Palombini, "Admin Interface for the OSCORE Group Manager",
-              Work in Progress, Internet-Draft, draft-ietf-ace-oscore-
-              gm-admin-11, 4 March 2024,
-              <https://datatracker.ietf.org/doc/html/draft-ietf-ace-
-              oscore-gm-admin-11>.
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 31]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   [I-D.ietf-ace-pubsub-profile]
-              Palombini, F., Sengul, C., and M. Tiloca, "Publish-
-              Subscribe Profile for Authentication and Authorization for
-              Constrained Environments (ACE)", Work in Progress,
-              Internet-Draft, draft-ietf-ace-pubsub-profile-09, 4 March
-              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
-              ace-pubsub-profile-09>.
-
-   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
-              Writing an IANA Considerations Section in RFCs", BCP 26,
-              RFC 8126, DOI 10.17487/RFC8126, June 2017,
-              <https://www.rfc-editor.org/rfc/rfc8126>.
-
-   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
-              DOI 10.17487/RFC8288, October 2017,
-              <https://www.rfc-editor.org/rfc/rfc8288>.
-
-   [RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
-              Structures and Process", STD 96, RFC 9052,
-              DOI 10.17487/RFC9052, August 2022,
-              <https://www.rfc-editor.org/rfc/rfc9052>.
-
-   [RFC9053]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
-              Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
-              August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.
-
-   [RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
-              Datagram Transport Layer Security (DTLS) Protocol Version
-              1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
-              <https://www.rfc-editor.org/rfc/rfc9147>.
-
-   [RFC9200]  Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
-              H. Tschofenig, "Authentication and Authorization for
-              Constrained Environments Using the OAuth 2.0 Framework
-              (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
-              <https://www.rfc-editor.org/rfc/rfc9200>.
-
-   [RFC9338]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
-              Countersignatures", STD 96, RFC 9338,
-              DOI 10.17487/RFC9338, December 2022,
-              <https://www.rfc-editor.org/rfc/rfc9338>.
-
-Contributors
-
-   Marco Tiloca
-   RISE AB
-   Email: marco.tiloca@ri.se
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 32]
-
-Internet-Draft  A publish-subscribe architecture for the      April 2024
-
-
-   Marco offered comprehensive reviews and insightful guidance on the
-   recent iterations of this document.  His contributions were
-   particularly notable in the Security Considerations section, among
-   others.
-
-Authors' Addresses
-
-   Jaime Jimenez
-   Ericsson
-   Email: jaime@iki.fi
-
-
-   Michael Koster
-   Dogtiger Labs
-   Email: michaeljohnkoster@gmail.com
-
-
-   Ari Keranen
-   Ericsson
-   Email: ari.keranen@ericsson.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Jimenez, et al.          Expires 20 October 2024               [Page 33]
diff --git a/ps-rev/index.html b/ps-rev/index.html
deleted file mode 100644
index bfb88eb..0000000
--- a/ps-rev/index.html
+++ /dev/null
@@ -1,45 +0,0 @@
-<!DOCTYPE html>
-<html>
-  <head>
-    <title>core-wg/coap-pubsub ps-rev preview</title>
-    <meta name="viewport" content="initial-scale=1.0">
-    <style type="text/css">/*<![CDATA[*/
-      body { font-family: "Helvetica Neue","Open Sans", Helvetica, Calibri,sans-serif; }
-      h1, h2, td { font-family: "Helvetica Neue", "Roboto Condensed", "Open Sans", Helvetica, Calibri, sans-serif; }
-      h1 { font-size: 20px; } h2 { font-size: 16px; }
-      table { margin: 5px 10px; border-collapse: collapse; }
-      th, td { font-weight: normal; text-align: left; padding: 2px 5px; }
-      a:link { color: #000; } a:visited { color: #00a; }
-    /*]]>*/</style>
-  </head>
-  <body>
-    <h1>Editor's drafts for ps-rev branch of <a href="https://github.com/core-wg/coap-pubsub/tree/ps-rev">core-wg/coap-pubsub</a></h1>
-    <table id="branch-ps-rev">
-      <tr>
-        <td><a href="./draft-ietf-core-coap-pubsub.html" class="html draft-ietf-core-coap-pubsub" title="A publish-subscribe architecture for the Constrained Application Protocol (CoAP) (HTML)">A publish-subscribe architecture for the Constrained Application Protocol (CoAP)</a></td>
-        <td><a href="./draft-ietf-core-coap-pubsub.txt" class="txt draft-ietf-core-coap-pubsub" title="A publish-subscribe architecture for the Constrained Application Protocol (CoAP) (Text)">plain text</a></td>
-        <td>same as main</td>
-      </tr>
-    </table>
-    <script>
-window.onload = function() {
-  var referrer_branch = 'main';
-  // e.g., "https://github.com/user/repo/tree/main"
-  var chunks = document.referrer.split("/");
-  if (chunks[2] === 'github.com' && chunks[5] === 'tree') {
-    referrer_branch = chunks[6];
-  }
-  let branch = document.querySelector('#branch-' + referrer_branch);
-  let h = document.location.hash.substring(1);
-  if (h === 'show') {
-    document.location.hash = '#' + branch.id;
-  } else if (branch && h.startsWith('go')) {
-    let e = branch.querySelector(h.substring(2));
-    if (e && e.href) {
-      document.location = e.href;
-    }
-  }
-};
-    </script>
-  </body>
-</html>