[core] Re: PR submitted on pubsub: attribute usage

[Carsten Bormann <[e-mail]>]

Hi Esko,

what do our documents say today about eliding attributes from query results?
I wasn’t aware that we are considering eliding attributes based on some logic making use of what the query says.

Grüße, Carsten


> On 2025-02-06, at 15:21, Esko Dijk <[e-mail]> wrote:
> 
> Hi Jaime,
>  
> I’ve just submitted a PR for pubsub: https://github.com/core-wg/coap-pubsub/pull/61
>  
> This aims to optimize the use of link format attributes in the examples, and adds some wording around that.
>  
> This is based on a few key ideas:
>  
> 	• When doing RFC 6690 link format querying on /.well-known/core , and the query parameter is “rt=<something>”, then it applies the convention that each link returned also has the “rt” attribute to be sure that the result is of the right type.
> This has been used as the convention over the past years, I think. One reason to do this is that a server may optionally not support querying and so it would return all the links (even those with wrong rt!).
> If every server always returns “rt” attributes, this issue of not supporting querying doesn’t interfere with the correctness of the result.
> 	• When doing a query (rt=<something>) on another resource, i.e. one defined in scope of the pubsub draft, the draft itself can define the rules for that.  For example the resource can be mandated (MUST) to support this query so we know that any and all results will have the correct rt type.
> There’s no need to include that rt type in each link result, thereby saving lots of bytes on the wire.
> 	• When doing a CoAP GET on a collection resource, such as topic collection, the specification itself can define the exact operation of that and what is returned and how.
> Because currently a topic collection can only contain topics as children, and not other types, we know that for each returned link in the link format document the default resource type of “topic” (core.ps.conf) must be applicable.  No other options possible. Therefore, we can define that if “rt” attributes are elided in those results, the default must apply.  So, no need to include “rt” attributes for each link there.
> 	• If the “rt” on a returned link is 100% known to the client parsing the links (whether rt is explicitly included or not), and there is no “ct” (content-format) attribute given, then the default “ct” as defined by this document is applied. Because it follows from “rt” there’s no need to add “ct” attributes where it follows the default. This also saves bytes on the wire.
> 	• The examples preferably need to guide the reader to the most typical, efficient implementation. Unless an example is explicitly marked as “exception case”. So this calls for only including attributes that we like to see in practical implementations.
>  
> Because this PR makes quite some changes, it might be good to discuss here on the list first if we agree to these principles. Or want to see something else?
>  
> Best regards
> Esko
> _______________________________________________
> core mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]