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

[Toerless Eckert <[e-mail]>]

On Sat, May 14, 2022 at 07:08:34PM +0200, Carsten Bormann wrote:
> 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.

Let me rephrase:
Multicast resource discovery was not inherited and adopted from rfc5988,
but was newly introduced by rfc6690.  Even though there do exist several
web-space multicast resource discovery mechanismens, such as WS-discovery.
None of those IETF defined though AFAIK...

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

Right. It might help visibility to ask IANA to insert a pseudo entry
into the registrary "s." with a pointer to the description of the method. 
Which kinda means it is probably better to write a 2 page RFC about this instead of
embedding it into a larger technology spec..

> > 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 =).

Right.

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

Right. except that it requires quoted strong, which is 2 character more
overhead... But would make life easier.

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

";" is not a ptoken character either, so it would have to be a quoted string
too, as for " ", or ",".

But given how you say other rt's have already used quoted-strings, it
seems the resource overhead of quoted strings is considered fine.

Some more things:

a) https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#if-link-target-att-value

The references to OIC Core specification v1.1.0 section 7.5.3 are wrong. No
such section. Maybe 7.6.3 was meant.  

b) I was looking this OIC stuff up to understand if/when an rt could/should use
an if parameter instead of a parameter of its own, such as proto= or p=

In case of ANIMA BRSKI, it seems that the protocols are all REST based, so
it seems an if= parameter would make sense, but in OIC core, the
if= and the rt= value are not only indicated in the core data, but then
they're also used in forming URLs, such as GET /oic/res?if=oic.if.baseline
or GET /oic/res?rt=oic.r.switch.binary, and so i wonder if/how there is
an assumption/expectation of if= and rt= values to be used in the
actual discovered REST URIs.

Cheers
    Toerless

> Grüße, Carsten

-- 
---
[e-mail]