Thanks for the historical insights.
Yes, I found the following section from
http://tools.ietf.org/html/draft-ietf-drums-abnf-02
3.5 Set Group: {Rule 1 Rule2}
Elements enclosed in braces (squiggly brackets) are treated
as a single, UNORDERED element. Its contents may occur in
any order. Hence:
{elem foo} bar
would match (elem foo bar) and (foo elem bar).
NOTE: Specifying alternatives is quite different from
specifying set grouping. Alternatives indicate the matching
of exactly one (sub-)rule out of the total grouping. The set
mechanism indicates the matching of a string which contains
all of the elements within the group; however the elements
may occur in any order.
And it was dropped from the following revisions.
To understand the ambiguity Keith mentioned, I tried to find any
discussion archives which led to the decision, but no luck so far.
Anyone knows about such an archive somewhere?
thanks,
-Munjo
On Thu, Apr 2, 2009 at 6:46 PM, Keith Moore <[email protected]> wrote:
> Paul Kyzivat wrote:
>> I agree with Keith about the inadvisability of rewriting the grammar.
>> Save it for SIP/3.0.
>>
>> In any case, I think the issue isn't with ABNF per se, its with the
>> way ABNF was used for SIP. ABNF isn't actually able to represent
>> everything that was desired for sip, so some things were simply
>> handled as exceptions in the text.
>>
>> Of course the "right" thing to do would have been to either give up on
>> anything that couldn't legitimately be represented, or else switch to
>> some other specification language that could express what was intended.
> not clear. IMHO, trying to specify every aspect of detail of a protocol
> syntax using a formal specification language can be misleading and cause
> more interop failures, than a looser specification written in ABNF plus
> some exceptions in the text. One reason for the additional failures
> when using the precise formal specification is that you don't really
> benefit from that specification unless you feed it to a program that
> will automatically generate the recognizer. And if you do automatically
> generate a recognizer from the formal specification, you often find that
> it doesn't report errors in the way that you'd like, doesn't perform as
> well as you want, etc.
>
> The trick is to design the protocol in such a way that a precise formal
> syntax specification is not necessary. This implies having a certain
> degree of simplicity and regularity in the protocol.
>>
>> But there is a big tradeoff there. At least many people are capable of
>> reading ABNF, and a reasonable number of those can accurately
>> understand what it means. A somewhat smaller, but still significant,
>> number can write it correctly. Its important that the people involved
>> in the standardization process, and that implement the standard, be
>> able to understand it. A more powerful specification language, that
>> fewer people could understand, might not be such a great choice.
> exactly.
>
> Keith
>
> _______________________________________________
> Apps-Discuss mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
