Hi Paul, Thanks for the review; I've added the WG mailing list to the CC.
> On 2 Jul 2021, at 2:55 am, Paul Kyzivat <[email protected]> wrote: > > 1) Minor: Is a hit or fwd parameter required? > > Is it required that an entry contain one of "hit" or "fwd"? Section 2.1 makes > it clear that you can't use both, but is less clear that one of them must be > included. But logically it seems that an entry without either wouldn't be > very useful. > > I suggest that this be stated explicitly. It's not required; conceivably, there's value in knowing that a cache was merely present. As the spec states, all parameters are OPTIONAL. > 2) Minor: ttl for other caches > > I'm not clear about the following in section 3: > > Going through two separate layers of caching, where the cache closest > to the origin responded to an earlier request with a stored response, > and a second cache stored that response and later reused it to > satisfy the current request: > > Cache-Status: OriginCache; hit; ttl=1100, > "CDN Company Here"; hit; ttl=545 > > When "CDN Company Here" replies with a hit is it responsible for updating the > ttl for the OriginCache? (Based on the time that has elapsed since it cached > the value.) If not, does that ttl have any relevance? No - 'ttl' is how fresh a response is in a cache when it's served; recording it helps to determine how old the response was at each step. As the spec says: "When adding a value to the Cache-Status header field, caches SHOULD preserve the existing field value, to allow debugging of the entire chain of caches handling the request." > 3) Minor: registration of parameters > > IMO the process of registration is underspecified. > > For one thing, IANA is not instructed as to what the registry itself should > look like. Given that a specification document is optional, the registry > presumably must contain everything specified by the template in section 4 for > new parameter registrations. But the instructions for pre-populating the > registry from section 2 would mean copying a *lot* free formatted text into > the registry. > > ISTM that it would be more straightforward to always require a specification > and have the IANA registry refer to it. > > Alternatively, you could have different templates for registering > with/without a specification and different registry formats for each. > > I suggest you provide IANA with a template for the registry, and provide > authors of extension parameters with a template for what should be included > in a specification document. There's a registration template in Section 4, referenced from the IANA considerations. > 4) Minor: Applicability of this header field is confusing > > Section 2 says: > > The Cache-Status header field is only applicable to responses that > are generated by an origin server. An intermediary SHOULD NOT append > a Cache-Status member to responses that it generates, even if that > intermediary contains a cache, except when the generated response is > based upon a stored response (e.g., a 304 Not Modified or 206 Partial > Content). > > The use of "are" implies to me that the cache received the response from the > origin server just now. Using "were" (or even more explicit language) would > tell me that this was a response received by the cache either now or in the > past. > > Also, IIUC the cache can't ever really distinguish if it received a response > from the origin server or another cache. So how can it know if this response > *ever* was created by the origin server? All it can know is that it received > it from a server closer to the origin. > > Can you clarify the language? OK. I've changed 'are' to 'have been'. Thanks again for the review, -- Mark Nottingham https://www.mnot.net/ _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
