Hi,
Jim suggests to keep both the /.well-known/est/* entry-points and the
optional short ones.
Seems the right approach to me and gives the application the opportunity
to shorten the request URIs.
Michael Richardson schreef op 2017-11-14 03:57:
Carsten Bormann <c...@tzi.org> wrote:
>> 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 /?)
> Why do you think that a node can only have one EST endpoint?
It could have hundreds, I agree.
Could also have hundreds of different IPs in the /64 answer.
If it had more than one, then shortening would have to be done
differently
for each, I think.
We already have /.well-known/est as well.
> It should be possible to have many, and the client should be able
to
> choose the one that is actually doing the right thing for them.
I'm pretty sure that I have no way to describe the logic to a client.
>> It seems like maybe a 301-like (Moved Permantly) reply from
>> /.well-known/est/*, but CoAP doesn't have 301 codes….
> (The link-format self-description is exactly the replacement for
the
> HTTP 301 here. Same number of roundtrips...)
yes, that's a good point, except that for the end-point that has the
single
end point at /.well-known/est, then there is no 301.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
