Re: RFC-2445: ABNF/prose mismatch on parameters

[Frank_Dawson@xxxxxxxxx]

Folks:
Here is a reply from Chris Newman on the ABNF. THANKS, Chris.

-- Frank


>On Wed, 21 Jul 1999 Frank_Dawson@lotus.com wrote:
>> 1. Specify the numerous combinatorial alternatives.
>>
>> 3. Define a special operator (i.e., "&" like used in SGML to indicate
any
>> order to the elements of the set) in the iCalendar specification with
the
>> proper semantics. Declare this as an extension to the RFC 2234 ABNF for
use
>> in this document.
>
>I don't think either of these is a good idea.  (1) just makes things
>unnecessarily complex, and we considered (3) seriously when doing ABNF,
>but the interactions of that operator with other operators gets too
>complex.
>
>> 2. Add a comment to the individual ABNF tokens that "properties are
>> unordered, ABNF just can't express this".
>
>This was the approach used in RFC 822, it's certainly preferable to 1 & 3.
>
>The approach I prefer is to address the problem the same way unordered
>headers are addressed.  See section 3.6 of
>          draft-ietf-drums-msg-fmt-07.txt
>for an example.
>
>In particular, the ABNF uses something like:
>
>  *(param1 / param2 / param3)
>
>and a comment (or table as in the msg-fmt draft) states any restrictions
>on the number of occurances for a given parameter.
>
>                    - Chris