- From: Francesca Palombini <francesca.palombini@ericsson.com>
- Date: Wed, 25 Aug 2021 16:44:42 +0000
- To: Mark Nottingham <mnot@mnot.net>, Jim Fenton <fenton@bluepopcorn.net>
- CC: "art@ietf.org" <art@ietf.org>, "draft-ietf-httpbis-proxy-status.all@ietf.org" <draft-ietf-httpbis-proxy-status.all@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, "last-call@ietf.org" <last-call@ietf.org>
Thanks Jim for the review! And thanks authors for addressing Jim's comments.
Francesca
On 23/08/2021, 04:45, "Mark Nottingham" <mnot@mnot.net> 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@ietf.org> 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
Received on Wednesday, 25 August 2021 16:45:02 UTC