> -----Original Message-----
> From: Michael Richardson <mcr+i...@sandelman.ca>
> Sent: Thursday, January 24, 2019 7:59 AM
> 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?
The wild card on the end is defined behavior in RD and elsewhere. It means
just what it looks like - return anything that starts with this string,
including the string.
Yes a server can respond with "</>" if the resource is at the root.
Especially for the wild card not sending back the rt would not be good
behavior as you don't know that it is not something else such as
ace.est.foo.
>
> > 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.
If one is doing compressed headers, this may not be a big issue to have the
extra links in there. My main issue with the section is it is not clear
what an application should do and how it should make the decision.
Jim
>
>
> --
> 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
