Michael Richardson schreef op 2017-11-13 03:32:
Michael Richardson <[email protected]> wrote:
> Section 4.1 provides for the process to start with a discovery
> operation.
...
> REQ: GET /.well-known/core?rt=ace.est
> I can see the architectural reasons for why we do that, but I
really
> have to ask why if we really really need this extra round trip.
Having read rfc6690 over again in order to implement this, I am now
further
convinced that using this mechanism as a way to shorten the
/.well-known/est
to something else is not entirely right.
I can see how a CoAP multicast to /.well-known/core?rt=ace.est ought to
return a list of hosts that support EST, and that EST ought to be
returned in
a list of supported interfaces.
I'm less convinced that we ought to be using this mechanism to shorten
/.well-known/est to /est (why stop there? can't we go to /?)
It seems like maybe a 301-like (Moved Permantly) reply from
/.well-known/est/*, but CoAP doesn't have 301 codes....
/.well-known/core is supposed to contain links.
The links point to resources which can be at the host themselves or at
other hosts.
The example link for the resource with rt=ace.est is /est in the draft.
Anything else than /est can be used; the chosen path name is SDO- or
installation dependent.
Indeed table 1 proposes to shorten the path names to the resources;
these have received the same resource type (rt) in the discovery request
half a page later.
One could make them discoverable with different rt's. In the latter
case, these rt's need to be registered and the path names become
discoverable.
Hope this clarifies.
Peter
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
