- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 6 Aug 2021 16:34:54 +1000
- To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
- Cc: The IESG <iesg@ietf.org>, "draft-ietf-httpbis-cache-header@ietf.org" <draft-ietf-httpbis-cache-header@ietf.org>, "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, "tpauly@apple.com" <tpauly@apple.com>
Admittedly, I may have spent too much time studying law recently. How about this: https://github.com/httpwg/http-extensions/commit/5adb7686d3e6c98291adbcba13dca0b2cffde2ac ? Cheers, > On 5 Aug 2021, at 6:33 pm, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote: > > Thank you Mark for the prompt reply and your answers. > > Nothing is blocking obviously but I still find the abstract use of 'codifies' and 'updates' quite unusual and somehow confusing... > > Regards > > -éric > > -----Original Message----- > From: Mark Nottingham <mnot@mnot.net> > Date: Thursday, 5 August 2021 at 06:14 > To: Eric Vyncke <evyncke@cisco.com> > Cc: The IESG <iesg@ietf.org>, "draft-ietf-httpbis-cache-header@ietf.org" <draft-ietf-httpbis-cache-header@ietf.org>, "httpbis-chairs@ietf.org" <httpbis-chairs@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, "tpauly@apple.com" <tpauly@apple.com> > Subject: Re: Éric Vyncke's No Objection on draft-ietf-httpbis-cache-header-09: (with COMMENT) > > Hi Éric, > > Thanks for the comments. Responses below. > >> -- Abstract -- >> I am puzzled by the use of "updates it" where the "it" is rather undefined... >> especially as this document 'codifies' it, hence, this is the first time it is >> documented so no need to update it. If I am wrong, perhaps good to add a >> reference to the updated document ? > > 'it' refers to the immediately preceding noun, 'practice' -- i.e. there's a widespread non-standardised practice. We're not using 'update' here in the sense of 'IETF document update'. > >> Also wondering about the use of 'codifies' in a standard track document, i.e., >> I was expected a 'specifies'. But, as a non-English speaker, the subtle >> differences among the English in different continents probably escape me :-) > > 'codification' in the sense that it's collecting and restating currently informal practice. > >> -- Section 2 -- >> >> Out of curiosity, why do all parameters start with "sf-" ? > > Because they're ABNF from Structured Fields (RFC8941). > >> How is the IP address specified ? Should RFC 5952 be referenced ? > > At this level, the construct is an opaque string; we're not expecting people to validate that it's an IP address or hostname, or use that for any processing. > >> "The Cache-Status header field is only applicable to responses that have been >> generated by an origin server." but how can a cache know whether it connected >> to the 'actual origin' and not another level of CDN ? (possibly a very naive >> question) > > This is a good question. I've tried to clarify here: > https://github.com/httpwg/http-extensions/commit/560389ff2 > > Is that better? > >> -- Section 2.2 -- >> Should there be a "other" value to catch up any other cases ? > > That would encourage divergence of behaviour in implementations, and reduce the value of the specification. The current values should capture the prominent states in the HTTP caching model; if not, we can add new parameters. > >> == NITS == >> >> -- Section 2 -- >> Just wondering about the capitalized 'List' in 'Its value is a List' when the >> rest of the section uses lowercase 'list'. > > That indicates it's a Structured Fields List. The other instances of 'list' are talking about manipulating the underlying data structure. > > Cheers, > > > > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/
Received on Friday, 6 August 2021 06:35:19 UTC