- From: Yoav Weiss <yoav@yoav.ws>
- Date: Mon, 11 May 2020 09:58:34 +0200
- To: Murray Kucherawy <superuser@gmail.com>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-client-hints@ietf.org, httpbis-chairs@ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
- Message-ID: <CACj=BEhN7omYjpQQQ=jKkp8XiP+hpKt+KnDAShwG+Jp0e_YFhQ@mail.gmail.com>
Thanks for reviewing! :) On Mon, May 11, 2020 at 9:18 AM Murray Kucherawy via Datatracker < noreply@ietf.org> 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.
Received on Monday, 11 May 2020 07:59:04 UTC