I haven't had a chance to study your ABNF documents, so this may be
an inappropriate comment.
Will the decision to use "-" for ranges, instead of "..", have problems where
"-" is one of the characters used in tokens to give nice readable attribute
names and value names, such as in ASN.1, and IPP? Having to resort to using
"_" (underscore) as a separator between words in attribute names
and attribute value names or having to quote attribute names and value
names that contain "-" would be a big step backward.
I don't know whether ":" could be used for a range or not?
Thanks for your consideration that "-" (hyphen) be used in tokens
and not for ranges.
I happen to like the ".." for range. I wonder if there is someway
to preserve that usage for ranges and fix you ambiguity problem some
other way?
Tom
>Return-Path: <ipp-owner@pwg.org>
>X-Sender: cumanros@pop3.holonet.net
>Date: Wed, 16 Apr 1997 23:50:47 PDT
>To: ipp@pwg.org
>From: Carl-Uno Manros <carl@manros.com>
>Subject: IPP> ABNF near finished?
>Sender: ipp-owner@pwg.org
>
>Here are suggested fixes to the current ABNF draft.
>
>Carl-Uno
>
>>Date: Mon, 14 Apr 1997 16:46:30 -0700 (PDT)
>>From: Chris Newman <Chris.Newman@innosoft.com>
>>Subject: ABNF near finished?
>>To: Detailed Revision/Update of Message Standards <drums@cs.utk.edu>
>>
>>At the IETF meeting, we spent a fair amount of time discussing some
>>possible problems with ABNF. The conclusions were as follows (using my
>>own interpretations):
>>
>>(1) It's too hard to get the set notation {} both clear and useful, so
>>we'll punt.
>>
>>(2) Range notation needs to be simplified to avoid confusions like
>>"a".."Z", which is ambiguous since each end is case-insensitive. Also
>>decided to use "-" instead of "..".
>>
>>(3) The "#" notation is used incompatibly in many specs (e.g. 822 & 2060).
>>Decided to drop it from notation since it's usually #thing or 1#thing both
>>of which are fairly simple to write without that notation. In addition,
>>current definition implies linear-white-space which is troublesome.
>>
>>(4) Case-sensitive strings can be written with literals, and shouldn't be
>>used often anyway. No special notation needed.
>>
>>Given these decisions it appears the ABNF document has no remaining
>>substantive open issues. If you think this is wrong, please speak up now.
>>
>>[As an implementation test, I updated my working copy of the ACAP
>> specification to use the new ABNF plus these decisions. Removing "#"
>> wasn't bad, and the literal numbers + ranges allowed me to get rid of
>> all <description> rules.]
>>
>>
>>
>>
>
>
>