Issues with header combination text from draft -16

Section 3.2 reads in part;

   Multiple header fields with the same field name MUST NOT be sent in a
   message unless the entire field value for that header field is
   defined as a comma-separated list [i.e., #(values)].


Issue 1; The example is wrong, it would be i.e., #(value)

Issue 2; According to Consolidated ABNF grammar Appendicies, this grammar
appears to be deprecated.  Is this so?  In the body of the spec, we find only...

  Part 1 has one occurrence outside of Section 3.2, in 9.9 1#( item ) for Via.

  Part 3 has four, in 6.1 #( item ) for Accept, in 6.2 1#( item ) for Accept-Charset,
  in 6.3 #( item ) for Accept-Encoding and in 6.4 1#( item ) for Accept-Language

  Part 5 has one, in 5.4.1 - 1#( item ) for byte-range-set

Issue 3; Note that Accept and Accept-Encoding #( item ) differ in ABNF from the other
four 1#( item ) cases, it's not clear to me why this distinction was made.

Issue 4; the spec is explicit in using "MUST NOT", and it is impossible for the
implementer to predict future field names which represent comma separated lists.
While it may be too late to resolve all cases in the wild, it seems reasonable to
insist that future headers or X-Foo-List headers with a -List field name suffix
will represent comma delimited headers subject to 3.2, while all X headers and
all future headers which are not named with a -List suffix cannot not be combined.


Question; does the spec ever suggest that a non-combineable header may not be
presented multiple times?

Received on Friday, 9 September 2011 13:01:42 UTC