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

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.

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.

	Thanks,
	Paul

Keith Moore wrote:
> eburger wrote:
>> Personally, I don't understand why we didn't just use YACC.
> Exercise: write an RFC ?822 parse in yacc.  It can be done, but not 
> easily, as the RFC ?822 grammar is not LALR(1).
>>  I am really in favor of using a formal language for specifying grammar. As Munjo states, the ABNF is essentially documentation fluff - useless at best and wrong at worst. 
>>
>> As for this particular suggestion, I am ambivalent as to whether we hack ABNF, adopt YACC, or even adopt ASN.1. 
> One lesson from the DRUMS effort - rewrite an existing grammar at your 
> peril.  Even if the old specification has errors, writing a new grammar 
> which verifiably recognizes exactly the same language as the old one can 
> be difficult.  And even if you restrict the language that new 
> implementations can emit, you generally have to accept the old language 
> for compatibility's sake.  So you end up with two grammars where one was 
> formerly (almost) good enough.
> 
> Keith
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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
_______________________________________________
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