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

[Ted Lemon <[e-mail]>]

The registry/mapping problem is where we fell down. Why are you trying to
use Core for this anyway? DNS-SD works fine—that’s what we’re using for
Thread, for example. You can just do a DNS UDP query or use DNS Push rather
than using multicast if you use SRP to update the DNS server.

On Fri, May 13, 2022 at 19:57 Toerless Eckert <[e-mail]> wrote:

> Thanks, Ted
>
> Any pointer to Kerry's work in this regard ? I was looking through her
> expired
> draft, but i didn't see anything getting to that exact point
> (draft-doi-core-parameter-option looks like related, but i can't really
>  make heads or tails out of it).
>
> So lets say:
>
> REQ: GET /.well-known/core?rt=<resource>
>
>      RES: 2.05 Content
>      Content-Format: 40
>      Payload:
>      </b>;rt=<resource>;p=<prio>;w=<weight>;proto=<string>,
>      ...
>
> I am just defining in the spec for my resource that it has additional
> option
> link-target attributes. p= for a numeric priority value, w= for a numeric
> weight attribute and proto= for a string enumerating protocol details.
> And these are the same parameters as what i'd use for the same resource
> (oops: service) when using DNS-SD.
>
> It seems as if rfc6690 didn't actually create a registry for those
> link-targets
> but simply created rt= and if= link-targets and just created a registry for
> the values of rt= and if=. Which raises the question if i could simply
> specify p/w/proto to be normative in the context of the specific resource,
> and if not whether those addtiional link-targets would have to be
> specified as
> updated to rfc6690...
>
> Cheers
>     Toerless
>
> On Fri, May 13, 2022 at 07:22:41PM -0400, Ted Lemon wrote:
> > We were never able to figure that out either. The mapping from Core RD in
> > particular to DNS-SD is something that the DNS-SD working group actually
> > pursued for a while (Kerry Lynn worked on this pretty heavily for about a
> > year).
> >
> > On Fri, May 13, 2022 at 7:20 PM Toerless Eckert <[e-mail]> wrote:
> >
> > > Dear CoAP WG
> > >
> > > I am trying to figure out how to use CoAP discovery as specified in
> RFC7252
> > > (and expanded in rfc6690 and rfc7390),  but i can not figure out how
> > > one would encode basic parameters of a resource, such as those
> supported
> > > in DNS-SD, rfc6763:
> > >
> > > When discovering more than one instance of a resource, such as
> possible,
> > > when using multicast discovery as on rfc7252, clients will have to
> figure
> > > out,
> > > which instance of a resource to select. DNS-SSD has priority and weight
> > > parameters associated with each instance. How would one describe/encode
> > > such instance and weight ?
> > >
> > > When discovering one or more instance via DNS-SD, the discoering client
> > > may further select the best instance in terms of interoperability,
> > > functionality
> > > and performance based on one or more key=value property pairs
> describing
> > > the instance. How is this done in CoAP ?
> > >
> > > Thanks a lot!
> > >
> > > Toerless
> > >
> > > _______________________________________________
> > > dnssd mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dnssd
> > >
>
> --
> ---
> [e-mail]
>