Re: [Last-Call] Artart last call review of draft-ietf-httpbis-proxy-status-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks Jim for the review! And thanks authors for addressing Jim's comments.

Francesca

On 23/08/2021, 04:45, "Mark Nottingham" <mnot@xxxxxxxx> wrote:

    Hi Jim,

    Thanks for the helpful review. I'm tracking this in:
      https://github.com/httpwg/http-extensions/issues/1612

    ... and have updated that with responses and links to the resulting changes. Happy to follow up on any additional discussion here or there.

    Cheers,


    > On 22 Aug 2021, at 4:57 am, Jim Fenton via Datatracker <noreply@xxxxxxxx> wrote:
    > 
    > Reviewer: Jim Fenton
    > Review result: Almost Ready
    > 
    > Substantive comment:
    > 
    > The third paragraph from the end of Section 2 says:
    > 
    >   When adding a value to the Proxy-Status field, intermediaries SHOULD
    >   preserve the existing members of the field, to allow debugging of the
    >   entire chain of intermediaries handling the request.
    > 
    > Under what circumstances would an intermediary need to mess with existing
    > Proxy-Status entries? Please consider upgrading this requirement to a MUST, and
    > perhaps also require that the ordering of existing entries be preserved.
    > 
    > Minor comments:
    > 
    > The descriptions of errors in sections 2.3.13, 2.3.14, 2.3.28, 2.3.30, and
    > 2.3.31 all contain a paragraph saying, "Note that additional information...(as
    > is the case for all errors)." It isn't clear whether this text belongs in the
    > "Notes" column of the registry entry being created since it is separate from
    > the bulleted list describing the entry. Please consider removing this text in
    > these sections and instead including it as introductory text describing the
    > error parameter.
    > 
    > The Notes for the entries either are empty or contain the text, "Responses with
    > this error type might not have been generated by the intermediary." I wonder if
    > this might more efficiently be represented by a Boolean flag in the registry
    > entries, but probably preserving the Notes field in the registry for future use.
    > 
    > The introduction uses both the phrase "towards the origin server" and the term
    > "upstream". It might be helpful to some readers to make it clear that they're
    > synonymous, e.g., "towards the origin server (upstream)"
    > 
    > Section 1.1 says that this specification uses ABNF, but I find only structured
    > fields. Consider removing the mention of ABNF and the informative reference to
    > RFC 5234.
    > 
    > 

    --
    Mark Nottingham   https://protect2.fireeye.com/v1/url?k=68f9b553-37628c56-68f9f5c8-86d2114eab2f-bd4228b7ad10970a&q=1&e=90cbf362-622d-44c7-b8d5-19256b728381&u=https%3A%2F%2Fwww.mnot.net%2F

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux