From 0f72dccf7d706bddedc15e5be9da582ce0bd9a39 Mon Sep 17 00:00:00 2001 From: ID Bot Date: Sun, 5 Nov 2023 13:36:49 +0000 Subject: [PATCH] Script updating gh-pages from 79e4016. [ci skip] --- draft-ietf-core-coap-pubsub.html | 205 +++++++++++++++++++------------ draft-ietf-core-coap-pubsub.txt | 124 ++++++++++++++----- index.html | 2 +- 3 files changed, 224 insertions(+), 107 deletions(-) diff --git a/draft-ietf-core-coap-pubsub.html b/draft-ietf-core-coap-pubsub.html index 9a7068a..e1d38a1 100644 --- a/draft-ietf-core-coap-pubsub.html +++ b/draft-ietf-core-coap-pubsub.html @@ -12,7 +12,6 @@ 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"> - @@ -1027,11 +1026,11 @@ Internet-Draft A publish-subscribe architecture for the -October 2023 +November 2023 Jimenez, et al. -Expires 22 April 2024 +Expires 8 May 2024 [Page] @@ -1039,17 +1038,17 @@
Workgroup:
-
Internet Engineering Task Force
+
CoRE Working Group
Internet-Draft:
draft-ietf-core-coap-pubsub-latest
Published:
- +
Intended Status:
Standards Track
Expires:
-
+
Authors:
@@ -1106,7 +1105,7 @@

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 22 April 2024.

+ This Internet-Draft will expire on 8 May 2024.

@@ -1687,20 +1690,22 @@

  • '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").

    + +
      +
    • +

      '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").

      • -
    • -

      '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".

      +
    • +

      '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.

      +
    • +

      '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.

      +
    • +

      '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.

      +
    • +

      '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.

    @@ -1718,7 +1723,7 @@

    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.

    +

    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.

    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.

    @@ -1739,7 +1744,7 @@ 
    
           
    
 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".
    
+
    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:
    
@@ -1814,7 +1819,7 @@ 
    
           
    
 
    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 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.
    
+
    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:
    
 
    
 
    @@ -1864,11 +1869,11 @@ 
    
           
    
 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.
    
+
    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.
    
+
    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.
    
 
    
 
     => 0.02 POST
@@ -1909,7 +1914,7 @@ 
    
           
    
 
    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.
    
+
    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":
    
 
    
@@ -1942,9 +1947,9 @@ 
    
 
    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.
    
+
    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".
    
+
    Both request and response MUST have Content-Format set to "application/core-pubsub+cbor".
    
 
    Example:
    
 
    
 
    @@ -1973,10 +1978,12 @@ 
    
 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 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. 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.
    
-
    Example:
    
-
    
+
    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:
    
+
    
 
     => 0.03 PUT
    Uri-Path: ps
@@ -1986,9 +1993,10 @@ 
    
    {
       "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": 2
    }
 
 <= 2.04 Changed
@@ -2002,41 +2010,82 @@ 
    
       "media-type": "application/senml-cbor",
       "topic-type": "temperature",
       "expiration-date": "2023-04-28T23:59:59Z",
-      "max-subscribers": 2
+      "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:
    
+
    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.
      
+
    • 
+              
      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 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.
      
+            
    • 
+              
      Changing of the expiration-date may cause to cancel ongoing subscriptions if the topic expires at an earlier data.
      
 
      • 
           
    
 
 
    
-
    
+
    
 
    
-          
    
-2.5.4. Deleting a topic-configuration
+          
    
+2.5.4. Updating the topic-configuration with iPATCH
           
    
-
    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:
    
+
    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
+   }
+
    
+
    
+
    Note that when a topic configuration changes through an iPATCH request, 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.
    
+
    
+
    
+
    
+
    
+          
    
+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
-
    
+
    
 
    
 
 
    
@@ -2148,7 +2197,7 @@ 
    
           
    
 
    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).
    
+
    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].
    
@@ -2198,8 +2247,8 @@ 
    
 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).
    
+
    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:
    
@@ -2213,7 +2262,7 @@ 
    
 
           
    
 
    
-
    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.
    
+
    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:
    
 
    
 
    @@ -2229,10 +2278,10 @@ 
    
    Max-Age: 15
 
   {
-    "bn": "urn:dev:os:193-iot/sparrow/jorvas/",
-    "n": "Raitis-lampotila",
+    "bn": "urn:dev:mydevice",
+    "n": "Company X",
     "u": "Cel",
-    "t": 1696340182,
+    "t": 1696341182,
     "v": 19.87
   }
 
@@ -2242,8 +2291,8 @@ 
    
    Max-Age: 15
 
   {
-    "bn": "urn:dev:os:193-iot/sparrow/jorvas/",
-    "n": "Raitis-lampotila",
+    "bn": "urn:dev:os:mydevice",
+    "n": "Company X",
     "u": "Cel",
     "t": 1696340182,
     "v": 21.87
@@ -2257,8 +2306,8 @@ 
    
           
    
 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.
    
+
    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.
    
 
    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.
    
 
 
    
@@ -2267,9 +2316,9 @@ 
    
           
    
 3.2.4. Delete topic-data
           
    
-
    A publisher MAY delete a topic by making a CoAP DELETE request on the topic-data URI.
    
+
    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.
    
+
    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:
    
 
    
 
    @@ -2291,8 +2340,8 @@ 
    
 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).
    
+
    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:
    
 
    
 
    @@ -2321,8 +2370,8 @@ 
    
 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.
    
+
    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.
    
 
 
    
 
@@ -2333,7 +2382,7 @@ 
    
 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.
    
+
    Note that the media type application/core-pubsub+cbor MUST be used when these parameters are transported in the respective message fields.
    
 
    
 
    
         
    
@@ -2364,9 +2413,9 @@ 
    
 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.
    
+
    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.
    
 
    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.
    
 
@@ -2533,10 +2582,10 @@ 
    
 
    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.
      
+            
      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 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 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.
      
@@ -2659,11 +2708,11 @@ 
      
 
      
 
      [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-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-09>. 
      
+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-10, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-10>. 
 
      
 
      [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-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-07>. 
      
+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-08, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-08>. 
 
      
 
      [RFC8126]
      
         
      
diff --git a/draft-ietf-core-coap-pubsub.txt b/draft-ietf-core-coap-pubsub.txt
index c9056bf..8ab9e40 100644
--- a/draft-ietf-core-coap-pubsub.txt
+++ b/draft-ietf-core-coap-pubsub.txt
@@ -2,13 +2,13 @@
 
 
 
-Internet Engineering Task Force                               J. Jimenez
+CoRE Working Group                                            J. Jimenez
 Internet-Draft                                                  Ericsson
 Intended status: Standards Track                               M. Koster
-Expires: 22 April 2024                                     Dogtiger Labs
+Expires: 8 May 2024                                        Dogtiger Labs
                                                               A. Keranen
                                                                 Ericsson
-                                                         20 October 2023
+                                                         5 November 2023
 
 
     A publish-subscribe architecture for the Constrained Application
@@ -54,7 +54,7 @@ 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."
 
-   This Internet-Draft will expire on 22 April 2024.
+   This Internet-Draft will expire on 8 May 2024.
 
 Copyright Notice
 
@@ -93,7 +93,8 @@ Table of Contents
        2.5.1.  Getting a topic-configuration
        2.5.2.  Getting part of a topic-configuration
        2.5.3.  Updating the topic-configuration
-       2.5.4.  Deleting a topic-configuration
+       2.5.4.  Updating the topic-configuration with iPATCH
+       2.5.5.  Deleting a topic-configuration
    3.  Publish and Subscribe
      3.1.  Topic Lifecycle
      3.2.  Topic-Data Interactions
@@ -200,8 +201,8 @@ Table of Contents
 
    broker:
       A CoAP server that hosts one or more topic collections with their
-      topic-configurations, and possibly also topic-data resources.  The
-      broker is responsible for the store-and-forward of state update
+      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
@@ -388,7 +389,8 @@ Table of Contents
       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.
+      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
@@ -708,16 +710,25 @@ Table of Contents
    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 may chose not to
-   overwrite parameters that are not explicitly modified in the request.
+   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.  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.
+   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:
 
@@ -729,9 +740,10 @@ Table of Contents
       {
          "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": 2
       }
 
    <= 2.04 Changed
@@ -745,7 +757,8 @@ Table of Contents
          "media-type": "application/senml-cbor",
          "topic-type": "temperature",
          "expiration-date": "2023-04-28T23:59:59Z",
-         "max-subscribers": 2
+         "max-subscribers": 100,
+         "observer-check": 86400
       }
 
    Note that when a topic configuration changes, it may result in
@@ -761,7 +774,62 @@ Table of Contents
    *  Changing of the expiration-date may cause to cancel ongoing
       subscriptions if the topic expires at an earlier data.
 
-2.5.4.  Deleting a topic-configuration
+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
+      }
+
+   Note that when a topic configuration changes through an iPATCH
+   request, 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.
+
+2.5.5.  Deleting a topic-configuration
 
    A client can delete a topic by making a CoAP DELETE request on the
    topic resource URI.
@@ -946,10 +1014,10 @@ Table of Contents
       Max-Age: 15
 
      {
-       "bn": "urn:dev:os:193-iot/sparrow/jorvas/",
-       "n": "Raitis-lampotila",
+       "bn": "urn:dev:mydevice",
+       "n": "Company X",
        "u": "Cel",
-       "t": 1696340182,
+       "t": 1696341182,
        "v": 19.87
      }
 
@@ -959,8 +1027,8 @@ Table of Contents
       Max-Age: 15
 
      {
-       "bn": "urn:dev:os:193-iot/sparrow/jorvas/",
-       "n": "Raitis-lampotila",
+       "bn": "urn:dev:os:mydevice",
+       "n": "Company X",
        "u": "Cel",
        "t": 1696340182,
        "v": 21.87
@@ -1343,17 +1411,17 @@ Informative References
               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-09, 1 July 2023,
+              gm-admin-10, 23 October 2023,
               .
+              oscore-gm-admin-10>.
 
    [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-07, 13
-              September 2023, .
+              Internet-Draft, draft-ietf-ace-pubsub-profile-08, 23
+              October 2023, .
 
    [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
               Writing an IANA Considerations Section in RFCs", BCP 26,
diff --git a/index.html b/index.html
index 5a41334..733b409 100644
--- a/index.html
+++ b/index.html
@@ -29,7 +29,7 @@ 
      Preview for branch ps-rev
      
       
         A publish-subscribe architecture for the Constrained Application Protocol (CoAP)
         plain text
-        diff with main
+        same as main
       
     
     
      Preview for branch edit-fixes