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

From: Jim Schaad <[email-masked]>
Date: Thu, 6 Dec 2018 21:27:14 -0800

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

At this point I am supposed to resolve against the origin of the target URI,
but from my understanding this would be the multicast address which is
probably the wrong answer but may not be.  It would depend if this is a
really a multicast resource or is just a unicast resource.  However I am not
sure where the hint is going to be deep in my code that I should resolve
against the return address rather than against the query address.  I would
know that using the return address is wrong in the event that the query went
first to a proxy or gateway before going to the correct location.

Jim

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 12 Dec 2018 21:43:45 +0100

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

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 12 Dec 2018 14:54:18 -0800

> -----Original Message-----
> From: Christian Amsüss <[email-masked]>
> Sent: Wednesday, December 12, 2018 12:44 PM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [core] /.well-known/core and multicast addresses
> 
> > I do a multicast get to /.well-known/core The response comes back on a
> > unicast address with relative URIs and without an anchor.
> 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").
> 
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

> [1]:
https://tools.ietf.org/html/draft-ietf-core-resource-directory-17#appendix-
> B.1.1

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 14 Dec 2018 12:18:17 +0100

On Wed, Dec 12, 2018 at 02:54:18PM -0800, Jim Schaad wrote:
>   Req: POST coap://[MCD1]/rd?ep=node1

Nope -- you're following a </rd> reference, and the base URI already
contains the IP literal that sent the response. Therefore, your
registration POST already goes to a unicast address.

> as a 4.01 Unauthorized).

I don't think that's a general rule. A server MAY pretend it didn't get
the message if there's nothing usefult o respond, but the decision is
made per application, and it's only the .well-known/core discovery that
says that a no-match should not be reported. A "2.04 Changed" is useful.

As said, this won't affect regular registration anyway due to the path
discovery lookup step that bakes in the unicast address.

In simple registration, a POST to a multicast can happen; there, I'd
expect that the simple client goes into "I'm good for $LIFETIME" mode
whenever it receives the first 2.04.

Best regards
Christian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Dec 2018 12:26:54 +0100

> "and any links embedded in the representation").

That may be worded a bit confusing.  From the horse’s mouth:

   For the purposes of interpreting the Location-* options and any links
   embedded in the representation, the request URI (i.e., the base URI
   relative to which the response is interpreted) is formed by replacing
   the multicast address in the Host component of the original request
   URI by the literal IP address of the endpoint actually responding.

End of https://tools.ietf.org/html/rfc7252#section-8.2 — as you noted.
Link that leads you almost there: https://tools.ietf.org/html/rfc7252#page-67

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Fri, 14 Dec 2018 08:56:42 -0800

> Sent: Friday, December 14, 2018 3:18 AM
> > 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.
> >
contains
> the IP literal that sent the response. Therefore, your registration POST
already
> goes to a unicast address.

I don't see how you got to here.  In you previous message you said:

" You resolve against  ... the origin of) the URI of the requested resource
... the IP literal of the multicast request as per section 8.2"

Now you are saying that you use the unicast response.  I was assuming that
the request address is what is going to be used when I wrote this up.

Jim

> 
> > Since multicast is defined as not needing to return any error messages
> > (such as a 4.01 Unauthorized).
> 
the
> message if there's nothing usefult o respond, but the decision is made per
> application, and it's only the .well-known/core discovery that says that a
no-
> match should not be reported. A "2.04 Changed" is useful.
> 
discovery
> lookup step that bakes in the unicast address.
> 
expect that
> the simple client goes into "I'm good for $LIFETIME" mode whenever it
receives
> the first 2.04.

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 14 Dec 2018 18:14:34 +0100

On Fri, Dec 14, 2018 at 08:56:42AM -0800, Jim Schaad wrote:
> .... the IP literal of the multicast request as per section 8.2"
> 

My apologies -- what Carsten pointed out as me having "worded
confusingly" is what I'd call plain wrong. The base address contains the
IP literal of the source address of the response, which is a unicast
address.

Should read through mails once more before sending them.
c

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn

---

From: Peter van der Stok <[email-masked]>
Date: Mon, 17 Dec 2018 11:38:30 +0100

Hi Christian,

It might make sense to complement the example to remove the issue cited
by Jim.
What do you think?

Peter

> From: Christian Amsüss <[email-masked]
> 
>> As a client I am looking for an RD to register with.  So I send the

contains

already

" You resolve against  ... the origin of) the URI of the requested
resource
.... the IP literal of the multicast request as per section 8.2"

---

From: 'Christian Amsüss' <[email-masked]>
Date: Mon, 17 Dec 2018 14:49:56 +0100

> It might make sense to complement the example to remove the issue cited

We already have an example on that in there: In B.1/B.2 a GET is sent to
a multicast .well-known/core, and the sender's IP literal is replaced in
for further resolution steps.

Best regards
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying