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

[Magnus Westerlund <[e-mail]>]

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? 
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  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------