Re: [core] /.well-known/core and multicast addresses

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Christian Amsüss <[e-mail]>
> Sent: Wednesday, December 12, 2018 12:44 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [core] /.well-known/core and multicast addresses
> 
> On Thu, Dec 06, 2018 at 09:27:14PM -0800, Jim Schaad wrote:
> > I am unsure how to get to the correct answer in this case.
> >
> > I do a multicast get to /.well-known/core The response comes back on a
> > unicast address with relative URIs and without an anchor.
> > I resolve the relative URI against ???
> 
> You resolve against (in RFC6690 link format: the origin of) the URI of the
> requested resource, which in the CoAP case is constructed from the request
> Uri-* options (RFC7252 section 6.5), but with the IP literal of the
multicast
> request as per section 8.2 (last paragraph before 8.2.1; "and any links
> embedded in the representation").
> 
> (I wouldn't have known the exact reference either, had I not outlined it
at [1]).

I was rather afraid that this was the case.  So just to be specific because
this is the context that I ran across the issue.

As a client I am looking for an RD to register with.  So I send the request:

Req: GET coap://[MCD1]/.well-known/core?rt=core.rd*

I get back one or more responses with the following links:

Res: 2.05 Content
</rd>;rt="core.rd";ct=40,
</rd-lookup/ep>;rt="core.rd-lookup-ep";ct=40,
</rd-lookup/res>;rt="core.rd-lookup-res";ct=40,

(Note this is an example that is copied straight out of the RD draft.)

I am now going to register myself by sending a registration request:

  Req: POST coap://[MCD1] /rd?ep=node1
   Content-Format: 40
   Payload:
   </sensors/temp>;ct=41;rt="temperature-c";if="sensor";
         anchor="coap://spurious.example.com:5683",
   </sensors/light>;ct=41;rt="light-lux";if="sensor"


As a response I could get:

1.  Zero or more success responses, and 
2.  Zero or more failure responses

Since multicast is defined as not needing to return any error messages (such
as a 4.01 Unauthorized).  I am going to assume that nobody would say that
the server has nothing "useful to respond (e.g., if it only has an empty
payload or an error response)" given that while there is no payload there is
a returned location path.

Life could be really interesting if, for example, the get on
/.well-known/core is supported as a multicast request but none of the RD
functionality is.  I would kind of expect that this would generally be the
case, but can see cases where the this would not be the case.  It is the way
that I had planned to implement.

If there was a rule that only resources available on the query address were
returned then that would defeat the purpose of doing the query to find a RD
service.  On the other hand if the RD does not recognize that it needs to do
return fully resolved href fields in this case there would also seem to be a
problem.  I am unaware of any such text for /.well-known/core but that does
not mean that it does not exist.

Jim

> 
> Best regards
> Christian
> 
> [1]:
https://tools.ietf.org/html/draft-ietf-core-resource-directory-17#appendix-
> B.1.1
> 
> --
> To use raw power is to make yourself infinitely vulnerable to greater
powers.
>   -- Bene Gesserit axiom