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

[Yoav Weiss <[e-mail]>]

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

> Hi Yoav,
>
>
>
> On Wed, 2020-06-17 at 11:16 +0200, Yoav Weiss wrote:
> > Thanks for reviewing! Apologies for the late reply... :/
> >
> > On Thu, May 21, 2020 at 11:47 AM Magnus Westerlund via Datatracker <
> > [e-mail]> 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?
>
> 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?
>

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

Where there any concerns raised with this, or are all okay with it?
>

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

+Mark Nottingham <[e-mail]> & +Tommy Pauly <[e-mail]> - 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?


>
> 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-".
>

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


>
>
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Networks, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Torshamnsgatan 23           | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>