- From: Francesca Palombini <francesca.palombini@ericsson.com>
- Date: Wed, 23 Jun 2021 23:29:54 +0000
- To: "draft-ietf-httpbis-cache-header@ietf.org" <draft-ietf-httpbis-cache-header@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi, Thank you for this document, and apologies for the delay. I have reviewed it and have some minor comments. Please handle these together with the Last Call comments. Francesca 1. ----- FP: I think the draft should add a normative reference to the HTTP Caching and HTTP semantics documents, and add a sentence in the terminology stating that terms and concepts from those documents are used. 2. ----- FP: I would also add a sentence in the terminology stating that ABNF definitions of data types used are found in RFC 8941 - right now there is only a reference for Lists, but other data types are used throughout the document. 3. ---- "hit" and "fwd" are exclusive; only one of them should appear on each list member. FP: any reason why this is not a MUST? 4. ----- The most specific reason that the cache is aware of SHOULD be used. FP: you could be even more clear here and mention when it is acceptable that the most specific reason is not used (I take it as this is a SHOULD to leave some flexibilities to implementations, I think it would be good to explicitly state that). Also it might be good to specify what a "more specific" is, in this case. I can see that uri-miss is more specific than miss, but is there any way to evaluate specificity between, say, request and stale? 5. ----- "stored" indicates whether the cache stored the response; a true value indicates that it did. Only meaningful when fwd is present. FP: With this definition I would assume that "stored" would always be true with "hit". Would it be an error on the client if it received it with "hit"? Or even more general: if a parameter is not meaningless, what's the client behavior? I assume ignore, but again it might be good to spell this out. 6. ----- * Name: [a name for the Cache-Status Parameter that matches key] FP: I am a bit confused by "that matches key".
Received on Wednesday, 23 June 2021 23:30:39 UTC