[core] Re: Review of draft-ietf-core-coap-pubsub-16

[Jaime Jiménez <[e-mail]>]

Thank you Esko!

*
*I tried to address your review in the current editor version which I 
plan to upload as v17
https://core-wg.github.io/coap-pubsub/draft-ietf-core-coap-pubsub.html*


1. consistency of terminology - variations of a term are often used. 
Should we try to unify that?  This makes reviewing and proposing text 
updates easier.

   Is there a reason to keep both the terms "topic resource" and 
"topic-configuration resource"?  It can be confusing at times.

   For example I couldn't find "topic resource" in figure 3. If there is 
no reason to keep both terms, we could use the shorter "topic resource" 
only.

   Whatever the outcome, we also need to add "topic resource" to the 
Terminology words list I think.

   Going forward, I will assume the spelling as listed in the 
Terminology section will be the preferred spelling of terms, e.g. 
“pub/sub” instead of “pub-sub” and “topic collection” instead of 
“topic-collection”.

*

Good point, "topic resource" and "topic-configuration resource" are used 
interchangeably. Figure 3 uses topic configuration resource as term.
As long as people understand that topic resources are used for 
configuration and are not the thing you subscribe to (that is 
topic-data) I would be happy to use "topic resource".
We can simply use "pubsub" but I think "topic collection" makes more 
sense than the dashed one. Unless someone has a better suggestion I will 
also leave the following:

- "CoAP Pubsub topic configuration Parameters" IANA registry

- "core.ps.conf" for the topic resource.

*
2. CBOR RFC terminology should be added as ‘required knowledge’ in the 
Terminology section including link to the CBOR RFC.
*

Do we use RFC8949 terminology? We use the word "encode" but not 
"encoder". In any case we also have a normative ref to STD94 already, is 
that not enough?


*3. Section 2.3.1 example discovers an unsecured broker - this goes 
against document's own recommendations? Let's change to a secured 
(coaps) broker being discovered – to show the typical case.

*should be coaps, good catch!
*
4. Section 2.3.4 example: What use is discovering the topic-data 
resource in this way?

   It can't be determined based on this result, which topic(s) these 
resources are linked to.  It is confusing - either remove the example or 
explain why/when used.

   (Moving out to an Appendix is also an option if this discovery is 
typically not used but still good to show for some reason.)
*

Here I am thinking that links may contain other attributes that could be 
of use to better understand the type of topic-data you can subscribe to. 
For example in IANA you have resource types that provide more 
information like "rt=oic.d.switch" and the like that could be used to 
further filter down relevant data sources. I would prefer to keep it 
there for the doc structure and readability but I can move it to 
appendix if you still think is not relevant.

*
5. If the "initialize" field is set to "true" when creating a topic, the 
broker should create the initial published value. But it's too vague 
what this value is.

   I think the spec needs to define a formal default value for this, 
such that observing clients can clearly recognize this as the "initial 
published value".

   Two possible solutions are for example:

       1) zero-length (empty) payload with Content-Format TBD606. This 
has the benefit that it for sure doesn't clash with any other C-Fs that 
publishers might use.

       2) zero-length (empty) payload without an explicit 
Content-Format. That is, a subscribing client would get this zero-length 
representation without an associated Content-Format Option in the CoAP 
resonse.  This means “indeterminate” per RFC 7252 5.10.3.
*


I agree and I will add more details to the topic properties and to the 
creating a topic section. Case 1) does not apply to every topic-data, 
you can have ct=112 or others as well. So I would suggest to use option 2).
*
6. Address the "TODO DELETE" item*

I think I uploaded a 10 minute old version at the time to the 
datatracker by mistake sorry!
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-core-coap-pubsub&url_2=https://core-wg.github.io/coap-pubsub/draft-ietf-core-coap-pubsub.txt



Regards,

Jaime

On 3.2.2025 15.01, Esko Dijk wrote:
>
> Hello Jaime / WG,
>
> Here is a quick initial review of draft-ietf-core-coap-pubsub-16. I 
> plan to do a more complete review later on (Shepherd review), after 
> these first findings are addressed.
>
> My list of review comments:
>
> 1. consistency of terminology - variations of a term are often used. 
> Should we try to unify that?  This makes reviewing and proposing text 
> updates easier.
>
>   Is there a reason to keep both the terms "topic resource" and 
> "topic-configuration resource"?  It can be confusing at times.
>
> For example I couldn't find "topic resource" in figure 3. If there is 
> no reason to keep both terms, we could use the shorter "topic 
> resource" only.
>
>   Whatever the outcome, we also need to add "topic resource" to the 
> Terminology words list I think.
>
> Going forward, I will assume the spelling as listed in the Terminology 
> section will be the preferred spelling of terms, e.g. “pub/sub” 
> instead of “pub-sub” and “topic collection” instead of “topic-collection”.
>
> 2. CBOR RFC terminology should be added as ‘required knowledge’ in the 
> Terminology section including link to the CBOR RFC.
>
> 3. Section 2.3.1 example discovers an unsecured broker - this goes 
> against document's own recommendations? Let's change to a secured 
> (coaps) broker being discovered – to show the typical case.
>
> 4. Section 2.3.4 example: What use is discovering the topic-data 
> resource in this way?
>
>   It can't be determined based on this result, which topic(s) these 
> resources are linked to.  It is confusing - either remove the example 
> or explain why/when used.
>
>   (Moving out to an Appendix is also an option if this discovery is 
> typically not used but still good to show for some reason.)
>
> 5. If the "initialize" field is set to "true" when creating a topic, 
> the broker should create the initial published value. But it's too 
> vague what this value is.
>
>   I think the spec needs to define a formal default value for this, 
> such that observing clients can clearly recognize this as the "initial 
> published value".
>
> Two possible solutions are for example:
>
> 1) zero-length (empty) payload with Content-Format TBD606. This has 
> the benefit that it for sure doesn't clash with any other C-Fs that 
> publishers might use.
>
>       2) zero-length (empty) payload without an explicit 
> Content-Format. That is, a subscribing client would get this 
> zero-length representation without an associated Content-Format Option 
> in the CoAP resonse.  This means “indeterminate” per RFC 7252 5.10.3.
>
> 6. Address the "TODO DELETE" item
>
> Regards,
>
-- 
Jaime Jiménez