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

From: Yoav Weiss <[email-masked]>
Date: Mon, 11 May 2020 09:58:34 +0200

Thanks for reviewing! :)

On Mon, May 11, 2020 at 9:18 AM Murray Kucherawy via Datatracker <
[email-masked]> 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.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 11 May 2020 10:24:23 -0700

Thanks for replying.  As a reminder, once you've dealt with the IANA
concern, the rest of these comments are non-blocking.  However, I'm happy
to discuss them too.

>> awkward construction; might I choose not to be aware?

Just "need to be aware".  I find it awkward to apply
compliance/requirements language to people.

> Would turning all those to a MUST work?

In the third bullet I was trying to illustrate my point: I think it makes
more sense not to use requirements language when talking about people, so
that one seems right to me.

RFC2119 Section 6 gives guidance that's relevant here.

In the first two bullets above, I don't know how to measure compliance with
the requirement that a feature SHOULD take something into account, or
SHOULD consider something.  I think the guidance you're providing needs to
either be more direct and explain what compliance looks like, or not use
these key words at all (at least not in their all-caps forms) if all you
want to do is bring a particular topic to the attention of an implementer.

You also have a "SHOULD take into account" wrapping a list that has two
SHOULD NOTs in it.  I don't know how to interpret that.

Section 6.1:
>> * Why does "Specification document(s)" refer to only a specific section
>> of this

The registration document says you can do it either way.  I just find
identifying a specific section to be unusual and I was curious.

-MSK

---

From: Yoav Weiss <[email-masked]>
Date: Tue, 12 May 2020 14:26:47 +0200

On Mon, May 11, 2020 at 7:24 PM Murray S. Kucherawy <[email-masked]>
wrote:

> In the first two bullets above, I don't know how to measure compliance
> with the requirement that a feature SHOULD take something into account, or

Thanks for clarifying. I'll change those to "need to", as you suggested.

> identifying a specific section to be unusual and I was curious.

I don't think there was a particular reason for that, other than trying to
point folks at the relevant section.