Re: [core] Question on draft-fossati-core-publish-option-02

["Rahman, Akbar" <[e-mail]>]

Hi Thomas,


Thanks for the detailed and useful clarification.  The only open
question in my mind is what happens if the delegated proxy happens to be
not link local and not site local?  Does this mean that then a global
multicast href query would need to be attempted by the client?


/Akbar



-----Original Message-----
From: Thomas Fossati [mailto:[e-mail]] 
Sent: Tuesday, October 22, 2013 4:59 PM
To: Rahman, Akbar
Cc: [e-mail]
Subject: Re: Question on draft-fossati-core-publish-option-02

Thank you Akbar for taking the time to review it.

As far as your question:

On Tue, Oct 22, 2013 at 6:58 PM, Rahman, Akbar
<[e-mail]> wrote:
> How is a client directed synchronously to go towards the delegated 
> Endpoint?  In other words, suppose a client had a priori (e.g. at 
> provisioning or startup) obtained the URI of the SEP for the resource 
> that it was interested in.

This is a great example, and one which we've not documented in the
current I-D but should have been (next round!).

In this case, I would expect the client doing an href query to the
(multicast) /.well-known/core interface:

REQ: GET /.well-known/core?href=coap://sleepy.example.org/res

and get the following response back from the delegated Proxy (or from
another endpoint who happens to have this information):

RES: 2.05 Content
<coap://sleepy.example.org/res>;
  anchor="coap://proxy.example.org/";
  rel="proxies"

which tells the client that coap://proxy.example.org "proxies" the
requested resource, so that it can then issue its Proxy-URI request for
that resource to said proxy.

> Your I-D is very clear on how the SEP
> can delegate a resource to a delegated Endpoint.  But how would the 
> client, in a synchronous manner, know that the resource is no longer 
> at the SEP but to go instead to the delegated Endpoint?

I hope my previous example is clear enough.  If you are not satisfied,
please shout :-)

> (I did see your Section 3, Discovery, but this to me seemed to be 
> somehow a specific use case and not a general approach.  Apologies if 
> I missed something obvious.)

Well, the intention is to make it a general approach, it should not look
like an ad hoc solution :-)

We set an explicit design constraint to reuse the discovery model of
RFC6690 as much as possible -- in line with our aim at providing a fully
"in-protocol" solution to the sleepy problem.
To make RFC6690 a building block that also supports the
sleepy/intermittent scenario, we had to bring in the "proxies" link
relation, that works around some semantic and syntactic limitation of
the "hosts" relation.  Using this new thing, the proxy not only hands
off packets around, but also participates into discovery, by advertising
resources that may be "hidden" to the other side of a CoAP network.

Cheers