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
