Re: Artart last call review of draft-ietf-httpbis-proxy-status-06

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://www.mnot.net/

Received on Monday, 23 August 2021 02:45:06 UTC