Re: [Sip] Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case

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 <moore@cs.utk.edu> 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
> Apps-Discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>