Hi Mark,
On 7/2/21 2:05 AM, Mark Nottingham wrote:
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 <pkyzi...@alum.mit.edu> 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.
OK
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."
OK. This does mean that only the ttl from the "hit" entry is meaningful.
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.
Yes, I saw that. But IANA isn't instructed to make a registry containing
those things. (They are described as being input to the expert. I'm
greatly in favor of specifying what input the expert should consider.)
Also, IANA is asked to populate the registry from section 2. But section
2 isn't consistent with that template.
I suggest you be clear about how the IANA registry should be formatted,
and then provide a filled in template containing what you want to go
into the registry from section 2.
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.
Paul
Thanks again for the review,
--
Mark Nottingham https://www.mnot.net/
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
