[core] Re: AD Review: draft-ietf-core-coap-pubsub-21

[Mike Bishop <[e-mail]>]

No worries on timing! By and large, these look great. The dependency on draft-jimenez-core-coap-no-content gets us to a better architecture, but it does put the document progress in an interesting spot. With a normative dependency on an unadopted draft, this would get stuck in the RFC Editor queue. I would suggest discussing the draft on Wednesday and/or at 127, so the WG can decide how best to progress that draft. If it's not adopted, we'd need to revisit how to solve that problem here.

I remain slightly unconvinced on POST vs. PUT - the server could always decline the creation of topics it doesn't want, after all. But that's a non-blocking comment, so I'll defer to the WG.

A few smaller comments:

  *
Section 2.2.1 says a client learns which properties were accepted from the representation returned by create and update, but Section 2.4.3 only says the 2.01 response "MAY include optional topic properties". On create, a missing property could mean it was ignored or just omitted.
  *
With the iPATCH semantics in 2.5.4, can a client remove an optional property such as "expiration-date"? It reads as if only POST can. Either say so, or define a value (e.g., CBOR null) that resets a property to its default.
  *
A FETCH filter (2.4.2) that names an unrecognized property never matches, which a client can't tell apart from "no matching topics".
  *
The 2.06 example in 3.2.2 carries Max-Age: 600. Since 2.06 is cacheable, a proxy could keep serving it for up to ten minutes after the first publication. A shorter value, or a note on choosing one, would be a better example.

Thanks for your work on this.

-Mike
________________________________
From: Jaime Jiménez <[e-mail]>
Sent: Monday, November 2, 2026 2:01 PM
To: Mike Bishop <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [core] AD Review: draft-ietf-core-coap-pubsub-21

Hi Mike,

Thank you again for the very thorough review!! It took a while to address it. The new main big change is the new draft 2.06 (No Content). Again sorry for the slow reply and last minute submission.

Below I go through your comments in order. All are addressed on -22.

Important
--------------

1) Section 2.2.1, paragraph 3: topic-data co-location

Mike: "Implementations MUST NOT assume this, yet this document certainly seems to assume the broker has control of both. The broker is tasked with making state changes on the topic-data resource in response to operations directed at the topic resource. I think this statement probably needs some clarification as to what is and is not assumed. (The last paragraph of 3.0 might be a more precise statement of this.)"

Jaime: Agreed. That sentence came in during WGLC. Christian asked for it to cover brokers that serve the topic-data resource from a different address (discussed back at IETF 105), so that subscriber implementations don't break on it. So the intended reader is the client. I rewrote the "topic-data" property to say that the resource is controlled by the broker, that it may be served from a different address, and that clients take the URI from the property instead of deriving it. The broker definition, "observer-check" and the last paragraph of Section 3 now say the same thing, and a broker that cannot serve a topic-data URI proposed by the client returns 4.xx.

https://github.com/core-wg/coap-pubsub/commit/bdee888

2) Sections 2.4 and 2.5: are all interactions mandatory to implement?

Mike: "Is the broker required to implement support for each of these interactions? I don't see that explicitly stated." (asked for both sections)

Jaime: The idea is that the broker supports all of them, since it is the less constrained party, and that clients use whatever subset they need. I added one sentence at the top of 2.4, 2.5 and 3.2 saying so. The one in 2.4 also replaces the opener you flagged in the nits.

https://github.com/core-wg/coap-pubsub/commit/d655283

3) Section 2.4.1 vs 2.3.2: SHOULD vs MUST on topic collection discovery

Mike: "In 2.3.2, brokers "SHOULD" offer a topic discovery entry point. These requirements seem at odds; if there's a distinction, please clarify it. (Also, a cross-reference to 2.3.2 would be appreciated here.)"

Jaime: The collection resource always exists and GET on it always works. I removed the MUST from 2.4.1. The SHOULD in 2.3.2 is about advertising the collection in /.well-known/core. A broker that only wants authorized clients to learn about its collections can skip that and use an RD or pre-configuration, and 2.3.2 now says so. 2.4.1 points to 2.3.2. In that same paragraph I also changed "A client MAY retrieve a list of links to topics it is authorized to access" into a MAY for the broker to filter the list, as you asked in the other comments.

https://github.com/core-wg/coap-pubsub/commit/1fd7aa8

4) Section 2.4.3, paragraph 5: 4.xx on unrecognized parameters

Mike: "This requires 4.xx when an unknown parameter is received from the client. That means, for any extensions, the client must know in advance whether the broker supports them. Is there a defined mechanism for that discovery?"

Jaime: No, we don't define that. I changed that rule to must-ignore: the broker ignores topic properties it does not recognize, does not store them and does not show them in the representation. Create, POST update and iPATCH all return the current representation, so the client sees which of the properties it sent were kept, and that is the discovery you asked about. 4.xx stays for invalid values of recognized properties and for topic-name conflicts. In the same commit I reworded the Section 2.2 sentence you flagged in the other comments ("all topic properties are defined in this document") so it points at the registry.

https://github.com/core-wg/coap-pubsub/commit/0f031dd

5) Section 2.5.4: iPATCH media type

Mike: "RFC 8132 says "The set of changes is represented in a format identified by a media type." All the examples show a media type which is a patch to be applied; "application/json-patch+json", "application/merge-patch+json", etc. This uses the same media type as the resource being updated, which is unusual. Consider whether a distinct media type definition is warranted."

Jaime: We considered it and I think a second media type does not help much here. RFC 8132 asks that the patch format be identified by a media type, and CoMI does what we do: the datastore resource and the iPATCH payload share application/yang-instances+cbor-seq, with the registration spelling out what the payload means in an iPATCH request, and that sentence was what we were missing. Section 2.5.4 now says the request payload is a CBOR map with Content-Format TBD606 carrying the properties to update, each present property replaces the current value, and absent ones are left unchanged. The media type registration says the same for iPATCH requests.

https://github.com/core-wg/coap-pubsub/commit/dbb1575

6) Section 3.1, paragraph 2: HALF CREATED state and a No-Content response code [DISCUSS]

Mike: "I really don't like this; half-creation feels like an overly complicated way to get around an empty resource. In HTTP-land, I would say that the topic-data resource exists, but has no content yet; an attempt to retrieve it would get 204 (No Content). It appears that this was proposed several years back (#4), then closed out last year with no intervening discussion. If such a success status code existed, it would fix two big pain points in this document: clients having to discriminate between states by which operations 4.04 and the inability to subscribe until there's data there. The WG should consider whether the machinery built to handle those problems is less trouble than one new status code, in this or a companion document."

Jaime: Carsten and I wrote draft-jimenez-core-coap-no-content (https://datatracker.ietf.org/doc/html/draft-jimenez-core-coap-no-content-00) , which defines 2.06 (No Content) for GET and FETCH, allows a 2.06 response to confirm an Observe registration and to be sent as a notification, and maps it to HTTP 204 at cross-proxies. -22 builds on it and removes the HALF CREATED state: the broker creates the topic-data resource together with the topic; GET and Observe requests on it return 2.06 until the first publication; the first publication returns 2.04 like any other; 4.04 means that the topic does not exist. The Delete topic-data operation is removed, since a DELETE terminates all observations on the resource with a final 4.04 and therefore cannot clear a topic without losing its subscribers. A topic-data resource has no representation only between creation and the first publication.

https://github.com/core-wg/coap-pubsub/commit/258d905
https://github.com/core-wg/coap-pubsub/commit/f27c73b
https://github.com/core-wg/coap-pubsub/compare/b3bac9f...main

7) Section 5, paragraph 2: security RECOMMENDED vs MUST

Mike: "In this day and age, I'd argue that security is probably a MUST. Deployments might choose to accomplish that at other layers, such as at the application layer or over a secure network that doesn't require CoAP to do its own encryption, but I still think we want something stronger than RECOMMENDED here."

Jaime: Yes. The RECOMMENDED was there because a MUST seemed to need a normative reference to a concrete security protocol. RFC 7252 is already normative and its DTLS binding is the default. The paragraph now says communications between each client and the broker MUST be secured, with the RFC 7252 security as default, OSCORE and DTLS 1.3 as examples.

https://github.com/core-wg/coap-pubsub/commit/6d8f74a

Other Comments
--------------

Section 2.2, paragraph 3: "all topic properties are defined in this document"

Mike: "This could be read as saying that topic properties other than the ones in this document are protocol violations. That would be unusual; assuming that's not the case, can you reword to clarify?"

Jaime: Reworded in the commit for item 4 above; the sentence now lists the properties defined here and points at the registry for further ones.

Section 2.2.1, paragraph 7: "max-subscribers" and undisclosed limits

Mike: "I would suggest that the broker might be allowed to have a limit even if it doesn't choose to disclose that limit to clients."

Jaime: The text now says that an absent "max-subscribers" means the topic configuration sets no limit, and that the broker MAY still enforce its own limit without exposing it in the field. The hint-at-creation sentence from the shepherd review already let the broker store a different value or none.

https://github.com/core-wg/coap-pubsub/commit/62df4ed

Section 2.2.1, paragraph 8: "observer-check" maximum and obligation

Mike: "RFC7641 says this MUST be no more than 24 hours, but this description doesn't specify a maximum. Also, is the broker obligated to honor this value or is it merely a hint to the broker as to when a lower value might be suitable?"

Jaime: Yes to both. The field is now bounded: greater than 0 and no greater than 86400, with a pointer to Section 4.5 of RFC 7641 for the 24-hour rule, so a larger value is an invalid value and gets the 4.xx from 2.4.3. On obligation I used the same wording as "max-subscribers": at creation or update it is a hint, the broker MAY store a different value within the bound, and once stored the server hosting the topic-data resource applies it.

https://github.com/core-wg/coap-pubsub/commit/1f07265

Section 2.2.1, paragraph 9: "initialize" with a remote topic-data resource

Mike: "When the topic-data resource is not co-located with the broker, does this require the broker to act as a client to wherever the resource actually is?"

Jaime:  "initialize" was removed under item 6

Section 2.3.1, paragraph 1: BCP 14 keywords on discovery

Mike: "Do these need to be BCP14 keywords? I'd think "clients can" and "Brokers can" is sufficient."

Jaime: Both are now "can".

https://github.com/core-wg/coap-pubsub/commit/717e8f9

Section 2.3.3, paragraph 0: normative permission on /.well-known/core

Mike: "Similarly, this doesn't feel like normative permission. I think what you actually mean is either that client MAY query this path to attempt discovery, or simply that you're defining this .well-known value in case brokers wish to publish there."

Jaime: The second reading is the intended one.

https://github.com/core-wg/coap-pubsub/commit/5ac7c27

Section 2.3.4, paragraph 7: eliding attributes

Mike: "Here, on the other hand, I think you are implying normative permission. "Brokers MAY elide these attributes to minimize....""

Jaime: Yes, that is what we meant, tweaked a bit the sentence to clarify.

https://github.com/core-wg/coap-pubsub/commit/87197e1

Section 2.4.1, paragraph 3: "A client MAY retrieve a list of links to topics it is authorized to"

Mike: "What precisely does this permit the client to do? This seems more likely to be a permission to the broker to only return topics the client would be authorized to access."

Jaime: It is now a MAY for the broker to limit the list to the topics the client is authorized to access.

Section 2.4.2, paragraph 3: response Content-Format scope

Mike: "Is this response Content-Format specific to handling the request CF defined in this section, or does it apply to all future request Content-Formats as well?"

Jaime: It is specific to this request Content-Format. The paragraph now says so, and that an extension defining another request format (when CoRAL is done, for example) also defines its response format.

https://github.com/core-wg/coap-pubsub/commit/760c7dc

Section 2.4.3, paragraph 4: "includes" or "is"

Mike: ""includes" or "is"? Could the server send multiple objects, one of which is a CBOR map?"

Jaime: "Is"

https://github.com/core-wg/coap-pubsub/commit/67f4f14

Section 2.5, paragraph 1: are brokers required to implement all of these

Mike: "Again, are brokers REQUIRED to implement all of these?"

Jaime: Yes

Section 2.5.1, paragraph 10: cacheability of topic resources

Mike: "Probably want some mention of cachability or not for topic resources; cf. 3.2.2/3.3 defined for topic data."

Jaime: Added to 2.5.1

https://github.com/core-wg/coap-pubsub/commit/350f658

Section 2.5.3, paragraph 1: POST vs PUT for full replacement

Mike: "Why is POST used for full replacement of topics, while PUT is used for full replacement of topic data? It's the same operation; I would have expected the same method."

Jaime: I would keep POST. PUT semantics do not fit the topic resource. PUT would also let a client create a topic at a URI of its choosing, and topic URIs are broker-generated.

Section 2.5.3, paragraph 3: "some of" the optional properties

Mike: "Perhaps "any of"? "some of" suggests that any given property might or might not be reset, leaving ambiguity about what clients should expect."

Jaime: Changed to "any".

https://github.com/core-wg/coap-pubsub/commit/1d0559e

Section 2.5.3, paragraph 8: shared considerations for both update methods

Mike: "The same considerations apply for both varieties of update; consider moving 2.5.3 and 2.5.4 to subsections under a more general "Updating the topic" which discusses updates across both methods."

Jaime: I left the sections as they are and wrote a couple of nits clarifying it. In 2.5.3 we now cover both methods and 2.5.4 points to that.

https://github.com/core-wg/coap-pubsub/commit/5093f10

Section 3.2.2, paragraph 6: HALF CREATED vs DELETED on 4.04

Mike: "How does a client distinguish a resource which is HALF CREATED versus DELETED?"

Jaime: Now using 2.06

https://github.com/core-wg/coap-pubsub/commit/da5ea37

Section 3.3, paragraph 1: "required previous step"

Mike: "It's required only in the sense that it needs to discover the URI somehow. No one is enforcing that they queried the topic first, are they? If not, consider softening this to something like "Discovery of the URI is described in...""

Jaime: Right, nobody enforces it. Softened as you suggest.

https://github.com/core-wg/coap-pubsub/commit/1a4a2ab

Section 3.3, paragraph 2: differentiating 4.04 cases

Mike: "Again, how does the client differentiate these cases?"

Jaime: Same as 3.2.2 above: 2.06 when there is no representation, 4.04 only when the topic does not exist.

Section 3.3, paragraph 7: old representations paragraph

Mike: "I'd argue this entire paragraph is out of scope for this document. (Unless you'd like to use it as a hypothetical example of your extensibility story.)"

Jaime: The paragraph came from a WGLC ask on what happens to older publications; we kept history out of scope then. So I took your second option and kept it as an example of extension through the topic-properties registry, in your wording.

https://github.com/core-wg/coap-pubsub/commit/80e709e

Section 5, paragraph 2: SHOULD end-to-end, MUST source authentication

Mike: "This paragraph confuses me. A MUST that applies only if you do the thing you SHOULD do means that only the middle is prohibited -- you can do end-to-end with source authentication, or you can completely omit end-to-end, but you MUST NOT do end-to-end without authentication? The more sensible formulation, I think, is that you SHOULD use end-to-end protection which provides source authentication."

Jaime: Your reading is the intended one: end-to-end protection, when used, MUST include source authentication. Content that is encrypted for the subscribers but carries no proof of who published it leaves them worse off than with hop-by-hop security, where at least the broker is authenticated.

https://github.com/core-wg/coap-pubsub/commit/6517782

Nits
----

All applied, thanks!  The examples with Content-Format 110 now use 112 (application/senml+cbor), which is also what the example topic declares in "topic-content-format". Expert Review Instructions is now 6.4.1.

https://github.com/core-wg/coap-pubsub/commit/19e2a57

Ciao!
Jaime Jiménez