Michael Richardson <mcr+i...@sandelman.ca> 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....
(weird to me that rfc6690 got published with an informative reference to CoAP,
as WIP... I guess the WG wanted to get it out. I wish our process would let
us update that reference to the RFC, because it confuses the rfc dependancy
process)
> The alternative is that we either have to use /.well-known/est, or that
> we wind up standardizing something (maybe /e) that isn't inside
> /.well-known.
> Can DTLS compression do better things for us instead?
> 2) DTLS and HelloVerifyRequest.
> SHOULD CoAP-EST servers always perform the HelloVerifyRequest state?
> Again, it's an extra round trip. Always doing it would simplify the
> code paths on both ends.
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -=
> IPv6 IoT consulting =-
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
