Re: Artart telechat review of draft-ietf-httpbis-cache-header-09

Thanks for the review, Martin!

Francesca

On 10/08/2021, 10:10, "Martin Dürst via Datatracker" <noreply@ietf.org> wrote:

    Reviewer: Martin Dürst
    Review result: Ready with Issues

    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.

Received on Monday, 16 August 2021 15:32:03 UTC