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

[Thomas Fossati <[e-mail]>]

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