Personally, I don't understand why we didn't just use YACC. 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. -- Eric Burger Sent from my mobile device; sorry if terse. All mobile users need lemonade. See <http://www.standardstrack.com/ietf/lemonade> for more information. -----Original Message----- From: Munjo Yu <[email protected]> Date: Wed, 1 Apr 2009 20:17:58 To: <[email protected]>; <[email protected]> Subject: Proposal of Non-Sequential Group Notion in ABNF w/ a SIP case Hi all, I am Munjo Yu and currently working with Jong Sung Kim of a network solution start-up in Korea, VineGen Inc. During the 74th IETF in San Francisco, Dave Crocker and Lisa Dusseault suggested us to post in the Application mailing list. And I thought the SIP mailing list is a good place too, since we have a use case of our extension with SIP. Jong Sung Kim noticed there should be a better version of the ABNF definition section of RFC 3261 while developing a "complete" ABNF parser generator. The parser generator is complete in the sense that generated parser code does not need any hand coding. In Section 7 of RFC 3261, Request is defined like following. Request = Request-Line *( message-header ) CRLF [ message-body ] where, message-header = (Accept / Accept-Encoding . / Call-ID . / CSeq . / Via . / extension-header) CRLF I omitted most part of the long "message-header" for sake of readability. >From the above, one can tell that *(message-header) achieves a group whose elements are non-sequential and optional. So, any of the following complies with the definition. () ; empty group (Accept) (Accept, Accept) (Accept, Call-ID) (Call-ID, Accept) and so on. However, only a small portion of all the possible combinations are legitimate according to some sections like 8.1.1 as follows. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, . . As shown above, few elements like To, From, CSeq, are mandatory - the first sign that the ABNF definition is not self-contained. In fact, all the "additional" definitions of message-header are embedded in various sections in the RFC , which makes it impractical ( if not impossible ) to build a complete parser generator. So, Jong Sung Kim had to add an extension, "non-sequential" group to ABNF, and he named it as SET whose is already available elsewhere like ASN.1 SET is described simply as follows, using a pair of braces: SET {Rule1 Rule2} Using SET, a redefinition of the above Request is something like following: Request = Request-Line message-header CRLF [ message-body ] where, message-header = { Call-ID CSeq . 1*Via . 0*1Accept 0*1Accept-Encoding . 0*1extension-header} CRLF This new version makes quite a few parts of the RFC paragraphs unnecessary and redundant, resulting in a self-contained, straightforward, easy-to-maintain, and parser generator friendly definition. We'd like to know what SIP folks would think about this, and if there are other cases that can benefit from this extension. Also would like to hear from App folks, such as balance between feature and simplicity, architectural point, etc. Regards, -Munjo Yu P.S. we'd like to express our thanks to Dave Crocker and Lisa Dusseault, and other WG chairs for their help and kindness during the meeting. _______________________________________________ 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
