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

Hi Magnus,

Thanks for the review. Responses below.

> On 21 May 2020, at 2:14 am, Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> ----------------------------------------------------------------------
> 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.

Hm. Conceivably, someone (e.g., an intermediary or a library) could combine two header instances and use COMMA HTAB; while the current text in 7230 only says "separated by a comma", but the (I believe more correct) text in semantics-core says "separated by a comma and optional whitespace. For consistency, use comma SP."

I think the chances of that actually being a problem are very, very small; by far the most common practice is comma SP. However, it's hard to rule out completely.

At this late stage, this is a non-trivial change; the risk of an implementation not updating for it is relatively low, but the risk of getting the fix wrong is much higher. So, I'm going to prepare a pull request and circulate it in the community to both get more eyes on it, and make sure the change gets consensus.


> ----------------------------------------------------------------------
> 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:

This is how we define HTTP headers; see for example the core documents, RFC7230, or most any of the extensions we're working on. There's been a lot of discussion leading up to this, and I won't reiterate all of that here; but it's pretty settled.


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

I don't think that's an improvement.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 21 May 2020 03:30:02 UTC