> This implies that a server is not required to support /.well-known/est We are > not clear about this. I would prefer that the server ALWAYS supports the > well-known names, such that the client can skip doing resource discovery if > it thinks that the extra bytes in the URL matter less than additional round > trip to do discovery.
Agree that the server MUST always support the /.well-known/est resource, since that's the resource that by definition is used for use cases where discovery is not viable. So if a failure on that resource ought to trigger a discovery action, that would contradict its purpose. Best regards Esko Dijk -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Michael Richardson Sent: Thursday, January 24, 2019 16:59 To: Panos Kampanakis (pkampana) <pkamp...@cisco.com>; ace@ietf.org Cc: Jim Schaad <i...@augustcellars.com>; consulta...@vanderstok.org Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07 https://goo.gl/LT4HYh is a diff from -06 to current. Panos has done a great job updating this according to the issues raised during the WGLC. Thank you I have re-read diffs to catch up, and have these minor author tweaks/questions. > Client authentication via DTLS Client Certificate is mandatory. I wonder if this should go into it's own section so that one can more easily say, "Please see section x.y.z" s/enrolment/enrollment/ <- use American spelling, I guess. We had both. section 6: REQ: GET /.well-known/core?rt=ace.est* I didn't know the trailing "*" was a thing. </est>; rt="ace.est", I guess I have to re-read the Core Link resource discovery document. Can a server respond with </>; ?? it's shorter, and I think would be valid? > If > the default root resource requests fail, the client > SHOULD fall back > to doing a resource discovery. Resource discovery > SHOULD be employed > when non-default URIs (like /est or > /est/ArbitraryLabel) or ports are > supported by the server or when the > client is unaware of what EST- > coaps resources are available by the server. This implies that a server is not required to support /.well-known/est We are not clear about this. I would prefer that the server ALWAYS supports the well-known names, such that the client can skip doing resource discovery if it thinks that the extra bytes in the URL matter less than additional round trip to do discovery. -- 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
