Skip to main content

Telechat Review of draft-ietf-httpbis-cache-header-09
review-ietf-httpbis-cache-header-09-artart-telechat-duerst-2021-08-10-00

Request Review of draft-ietf-httpbis-cache-header
Requested revision No specific revision (document currently at 10)
Type Telechat Review
Team ART Area Review Team (artart)
Deadline 2021-08-10
Requested 2021-07-09
Authors Mark Nottingham
I-D last updated 2021-08-10
Completed reviews Genart Last Call review of -08 by Paul Kyzivat (diff)
Artart Telechat review of -09 by Martin J. Dürst (diff)
Assignment Reviewer Martin J. Dürst
State Completed
Request Telechat review on draft-ietf-httpbis-cache-header by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/PkmUw1rBOy6R0EYSYGyKtO38CaQ
Reviewed revision 09 (document currently at 10)
Result Ready w/issues
Completed 2021-08-10
review-ietf-httpbis-cache-header-09-artart-telechat-duerst-2021-08-10-00
Reviewer: Martin J. Dürst
Review result: Ready with Nits

This document is mostly ready, but a few places would benefit from
updated/clarified wording.

Overall: The draft says the header's purpose is "to add debugging". Is the
intent that this header is consumed by debugging tools, or is it simply
intended for human debuggers? If the former, that should be called out more
clearly because it might help implementing senders to be more careful. If the
later, there's a chance that implementations will degrade over time, because
humans are the ultimate example for the second half of Jon Postel's robustness
principle. Also, it would be interesting to know if other uses besides
debugging are possible.

Section 2, first paragraph: The sentence is grammatically correct, but avoiding
"caches'" and the final "within" would definitely make it more readable. E.g.:
"The Cache-Status HTTP response header field indicates how the caches have
handled the request corresponding to the response where the header field
occurs.".

Section 2, second paragraph: "Its value is a List ([RFC8941], Section 3.1):":
RFC 8941 is just referenced in passing. If the header field is using the syntax
from RFC 8941, that should be said independently up front. If only parts of
that syntax are used, that should also be said explicitly.

Section 2, ~forth paragraph (fifth by different counting): This paragraph, and
in particular its first sentence, have left me wondering about its exact
meaning repeatedly. When the draft says "The Cache-Status header field is only
applicable to responses that have been generated by an origin server.", is that
another way of saying that the server  (which may be a cache, but not for the
response in question) originally creating a response SHOULD NOT add such a
header field to that response? The problem with the current language is that in
my understanding, essentially all responses at one point are generated by an
origin server, and so the quoted sentence doesn't in any way restrict anything.
Or is the header also inappropriate for the case when a cache serves a full
fresh response as originally received from the origin server, with 200 OK?
Wouldn't that defy the purpose of this header field?

Section 2.4, first paragraph: "measured when the response header section is
sent by the cache": This may be splitting hairs, but some header sections are
quite large and may not be sent in one go, and on the other hand, generating a
header field and sending it may not happen exactly synchronously, in which case
it would be easy to measure and note down the ttl when generating, but
difficult to do so when sending.

Section 3, last example: There is only one example with two layers of caching.
One or more additional examples of multi-layer caching might greatly enhance
understanding for example-directed readers.