Subject: Re: Magnus Westerlund's No Objection on draft-ietf-httpbis-client-hints-14: (with COMMENT)

From: Yoav Weiss <[email-masked]>
Date: Wed, 17 Jun 2020 11:16:25 +0200

Thanks for reviewing! Apologies for the late reply... :/

On Thu, May 21, 2020 at 11:47 AM Magnus Westerlund via Datatracker <
[email-masked]> wrote:

> Magnus Westerlund has entered the following ballot position for
> draft-ietf-httpbis-client-hints-14: No Objection
>
> 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/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I have no significant concern here, but I would appreciate an answer if I
> understand the situation correctly.
>
> The Accept-CH header value is  structure header value and uses sh-token
> which
> has a more restrictive syntax than the HTTP specifications token used for
> header field names. However, this restriction is not of any real practical
> concern as all registered HTTP headers starts with an ALPHA. I did notice
> that
> the new HTTP semantics documents proposed new registry was not mandating
> but
> strongly recommending to keep within what sh-token can except. Thus, do I
> assume correctly that this issue has been sufficiently discussed in the WG?
>

I'm not sure I properly understand the issue you're referring to. Would you
like to see a stronger restriction than sh-token?

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jun 2020 08:35:52 +0000

Hi Yoav,

On Wed, 2020-06-17 at 11:16 +0200, Yoav Weiss wrote:
> > the new HTTP semantics documents proposed new registry was not mandating but

No, I am simply noting that by using structured field values your implicitly
restriciting the syntax from what RFC 7230 allows for field names, which is:

header-field   = field-name ":" OWS field-value OWS
field-name     = token
where token is:

     token          = 1*tchar

     tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                    / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                    / DIGIT / ALPHA
                    ; any VCHAR, except delimiters

However Structure field's token definition is this:

   sf-token = ( ALPHA / "*" ) *( tchar / ":" / "/" )

Thus, Client hints will not be able to do express all possible field-names that
may exist in HTTP. 

From that I was asking: 

Where there any discussion of this restriction? 
Where there any concerns raised with this, or are all okay with it? 

I personally don't have an issue with it as all registered HTTP headers will
fitt in this more restricted syntax. 

So all I am asking for is an honest answer of the above questions.

In addition when you update the draft, please fix the fact that draft-ietf-
httpbis-header-structure-19 has changed the prefix for its ABNF constructs from
"sh-" to "sf-".

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Jun 2020 12:01:13 +0200

On 18.06.2020 10:35, Magnus Westerlund wrote:
> ...
> ...

FWIW, an alternative approach would be to allow both sf-token and
sf-string here (I'm not saying it is needed, but it would certainly
resolve the issue).

Best regards, Julian

---

From: Yoav Weiss <[email-masked]>
Date: Thu, 18 Jun 2020 12:57:40 +0200

On Thu, Jun 18, 2020 at 10:35 AM Magnus Westerlund <
[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

I don't believe there was a thorough discussion of this restriction.

I haven't heard any concerns, and I think it's fine to restrict Client
Hints headers to cf-token.

+Mark Nottingham <[email-masked]> & +Tommy Pauly <[email-masked]> - do you
think more discussion is needed on that point? Or is this email thread
enough to ensure concerned folks would come forward if there are any?

> httpbis-header-structure-19 has changed the prefix for its ABNF constructs

Indeed. That came up in the review and a fix is in PR
<https://github.com/httpwg/http-extensions/pull/1220>.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 18 Jun 2020 11:56:07 +0000

Hi,

On Thu, 2020-06-18 at 12:57 +0200, Yoav Weiss wrote:
> I haven't heard any concerns, and I think it's fine to restrict Client Hints
> headers to cf-token.
> 
> +Mark Nottingham & +Tommy Pauly - do you think more discussion is needed on
> that point? Or is this email thread enough to ensure concerned folks would
> come forward if there are any?

So I was simply asking for confirmation as it was a subtle but possible
important point. I think so far my thoughts are moving in the direction that it
is not relevant. This document has after all been through both WG and IETF last
call. So I think it is fine and no action required. If any one in the WG seeing
this conmversation and realizes this is an issue, I think they have a very short
window to yell and it will be up to the responsible AD to decide what to do with
it.

Thanks for working with me to clarify what my potential concern was. 

Thanks 

Magnus Westerlund