Re: Murray Kucherawy's Discuss on draft-ietf-httpbis-client-hints-13: (with DISCUSS and COMMENT)

[Yoav Weiss <[e-mail]>]

Thanks for reviewing! :)

On Mon, May 11, 2020 at 9:18 AM Murray Kucherawy via Datatracker <
[e-mail]> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-httpbis-client-hints-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-client-hints/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> This one should be easy:
>
> Section 6.1:
> * Why is an Experimental status RFC registering a new header field with
> "standard" status?  (See RFC3864, Section 4.2.1.)
>

This is addressed
<https://github.com/httpwg/http-extensions/pull/1171/files#diff-6e79d9caec04bd66d25e88d370797f08L233>
in an open PR that will hopefully land soon.


>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Nits:
>
> Section 1:
> * "... techniques are expensive to setup and maintain, ..." -- s/setup/set
> up/
> * "... which data is required ..." -- s/is/are/
>

Changed


> * I suspect paragraphs 5 and 7 of this section could be merged.
>

They've been modified in the PR. Can you take a look and let me know if the
concern still applies?


>
> Section 2.1:
> * "... access of third parties to same header fields."  -- s/to same/to
> those
> same/, perhaps?


Changed


> * "Implementers SHOULD be aware ..." -- this feels like an
> awkward construction; might I choose not to be aware?
>

MUST be aware?


>
> Section 2.2:
> * "... contains one or more client hint header fields ..." -- Previous and
> subsequent sections capitalized "Client Hint", shouldn't that be done here
> too?
>

Done

>
> Section 4.1:
> * The parenthetical example at the end of the second paragraph should be
> capitalized and is missing a period at the end.


Done

* "Such features SHOULD take
> into account ..." -- same issue as before, this seems an odd use of BCP 14
> language

* "User agents SHOULD consider ..." -- same

* "Implementers ought to
> consider ..." -- why is this only "ought to" given the prior SHOULDs?
>

Would turning all those to a MUST work?


>
> Section 6.1:
> * Why does "Specification document(s)" refer to only a specific section of
> this
> document?  Isn't the whole document applicable?
>

Sure. It's currently pointing at the specific section that defines the
header, but I can change it to refer to the whole document if that's
preferred.