Magnus Westerlund's Discuss on draft-ietf-httpbis-header-structure-18: (with DISCUSS and COMMENT)

Magnus Westerlund has entered the following ballot position for
draft-ietf-httpbis-header-structure-18: 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-header-structure/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A. Section 3.1:

   The ABNF for Lists in HTTP fields is:

   sh-list       = list-member *( *SP "," *SP list-member )
   list-member   = sh-item / inner-list

   Each member is separated by a comma and optional whitespace.

To me there is a clarity issue that could lead to interoperability issues.
Namely the difference in the meaning of whitespace between RFC 7230 and this
document. Structured headers appear to not allow the HTAB that RFC7230 allows.
And that is fine, but I would expect this to be more clearly discussed. If the
intention was to allow for HTAB you need to use WSP rather than SP in above
rule.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1. Section 2, page 8:
   --8<--
     42. Foo-Example Header

   The Foo-Example HTTP header field conveys information about how
   much Foo the message has.

   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

     Foo-Example = sh-integer

   Its value indicates the amount of Foo in the message, and MUST
   be between 0 and 10, inclusive; other values MUST cause
   the entire header field to be ignored.

   The following parameters are defined:
   * A Parameter whose name is "foourl", and whose value is a String
     (Section Y.Y of [RFCxxxx]), conveying the Foo URL
     for the message. See below for processing requirements.

   "foourl" contains a URI-reference (Section 4.1 of [RFC3986]). If
   its value is not a valid URI-reference, the entire header field
   MUST be ignored. If its value is a relative reference (Section 4.2
   of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
   being used.

   For example:

     Foo-Example: 2; foourl="https://foo.example.com/"
   --8<--

To me this example indicates several unclarities in this specification.

First there is a lack of discussion of the definition of the field-name and
clearly identify it. In the above example it is only implicit identified. I
would propose that this example has an additional paragraph that explicitly
defined the Structure header name as discussed in the paragraph above this
example.

Per RFC 7230 Section 3.2 a header field is the complete structure of field-name
":" OWS field-value OWS. However looking at this example it appears that
structured header field only define the field-value. Wouldn't it be better to
be explicit about these two components although I understand that field-name is
a constant. This is also evident in what appears to be a grammatical error in
the above paragraph:

   Foo-Example is a Item Structured Header [RFCxxxx]. Its value MUST be
   an Integer (Section Y.Y of [RFCxxxx]). Its ABNF is:

The second "Its" would to me indicate Foo-Example a Item Structured Header, not
the header value (field-value in ABNF) which is defined. I would suggest
changing the second Its to "The Structured header value ABNF is:"

Received on Wednesday, 20 May 2020 16:14:30 UTC