Re: [dnssd] [core] CoAP resource discovery and DNS-SD

[Carsten Bormann <[e-mail]>]

On 2022-05-14, at 16:28, Toerless Eckert <[e-mail]> wrote:
> 
> On Sat, May 14, 2022 at 02:08:00AM +0200, Carsten Bormann wrote:
>>> Likewise, for other parameters, the client gets replies from multiple
>>> instances, but they resource differs in some details and those are expressed
>>> in those additional parameters.
>> 
>> RFC 6690 is based on web linking, and that is quite flexible with request to defining target attributes.
> 
> Except that rfc5988 didn't have the element of discovery or multicast, but rfc6690
> came up with them - and then did not inherit whats good about DNS-SD, which
> arguably was the best and most widely deployed discovery mechanism we had defined.

I don’t know what’s “except” about that — RFC 6990 truly is quite flexible with request to defining target attributes.

>> If we think this is a use case we want to address, we could define these target attributes.  I’d assume it would be pretty much up to the querier to interpret them, but the attribute definitions should be well-defined.
> 
> Sure. How about this definition:
> 
> REQ: GET /.well-known/core?rt=<resource>
> 
>     RES: 2.05 Content
>     Content-Format: 40
>     Payload:
>     </b>;rt=s.service-name;p=num;w=num;key=value;
> 
> If service-name is an rfc6335 registered service name, then it
> can be mapped into a resource type by using the s.service-name notation.
> The prefix s. is reserved for this purpose, no other resource types shall
> use it.

We don’t really have a way to insert one registry into another, but technically, this makes a lot of sense.

> p(riority) and w(weight) have the semantic defined in rfc2782 and
> are used by the requester to select which discovered instance to select.

Works for me.

> If the service-name uses rfc6763 key-value property pairs (encoded in
> DNS TXT RR), those are represented equally as key=value.

These of course can conflict with other target attribute names.
As the namespace for target attributes is not controlled at the moment, a trick like the s.servicename above could work here, too (on the left side of the =).

> Given the likely slightly different string rules in coap and dns-sd,
> it is necessary anyhow to design the possible values such that they
> conform to dns-sd and coap rules. Hence it should also be easily
> possible to pick key names that do not conflict with pre-existing
> coap target attribute names.

Doing this manually works, too.

> This should be all there is to it.

Right; it should not be complicated.

> Actually a Q: In DNS SD, we might have a key=val1,val2,val3
> Given how "," seems to be a reserved structure character (like ";'),
> what would be a good separator inside a value to structure it ?

Section 2 of RFC 6690:
"Note that commas can also
   occur in quoted strings and URIs but do not end a description.”

We used space separators or multiple instances of the attribute, i.e.

key=“val1 val2 val3” (e.g., for rt=, if=, rel=)
Or
key=val1;key=val2;key=val3 (can’t remember outright where we did this).

The fact that we didn’t encourage to always use *one* of these in RFC6690 is haunting us a bit.

Grüße, Carsten