[rfc-i] ABNF (RFC2234) vs HTTP's augmented BNF syntax (RFC822 + RFC2616)

[Julian Reschke]

Hi,

I was in the process of upgrading some Internet Drafts to use the ABNF 
defined in RFC2234. All these drafts define extensions/applications of 
HTTP (RFC2616).

At first I thought that this was a simple "add the reference and apply 
some minor syntax tweaks" thing; but it turns out that RFC2616 modifies 
RFC822's BNF in a way that makes it particularly useful when defining 
HTTP header fields 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.2.1>), namely:

    #rule
       A construct "#" is defined, similar to "*", for defining lists of
       elements. The full form is "<n>#<m>element" indicating at least
       <n> and at most <m> elements, each separated by one or more commas
       (",") and OPTIONAL linear white space (LWS). This makes the usual
       form of lists very easy; a rule such as
          ( *LWS element *( *LWS "," *LWS element ))
       can be shown as
          1#element
       Wherever this construct is used, null elements are allowed, but do
       not contribute to the count of elements present. That is,
       "(element), , (element) " is permitted, but counts as only two
       elements. Therefore, where at least one element is required, at
       least one non-null element MUST be present. Default values are 0
       and infinity so that "#element" allows any number, including zero;
       "1#element" requires at least one; and "1#2element" allows one or
       two.

...and...

    implied *LWS
       The grammar described by this specification is word-based. Except
       where noted otherwise, linear white space (LWS) can be included
       between any two adjacent words (token or quoted-string), and
       between adjacent words and separators, without changing the
       interpretation of a field. At least one delimiter (LWS and/or

       separators) MUST exist between any two tokens (for the definition
       of "token" below), since they would otherwise be interpreted as a
       single token.


So for new specs that define HTTP header fields, what would be the 
preferred approach...?

1) Use the augmented BNF defined in RFC2616, Section 2.1, rather than 
RFC2234's ABNF?

2) Use the RFC2234 ABNF, but extend it in the same manner?

3) Stick with what RFC2234 allows (making the syntax definitions harder 
to read at best)?

4) ...?

Feedback appreciated,

Julian