Subject: [Sip] ABNF comment/nit on draft-ietf-sip-rfc2543bis-03.txt

From: Chip Sharp <[email-masked]>
Date: Mon, 09 Jul 2001 17:04:18 -0400

The following production is in Appendix C:
	escaped = "%" hex hex

HEX is capitalized in its production.  While this is legal according to 
RFC2234, is it possible to use the same case?

I assume this is academic, but why include Appendix C instead of 
referencing RFC2234 and listing the exceptions/additions?  Why use "|" for 
alternatives instead of the "/" defined in RFC2234?

Thanks,
Chip

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 09 Jul 2001 20:27:14 -0400

> RFC2234, is it possible to use the same case?

Yes, this should be consistent.

> alternatives instead of the "/" defined in RFC2234?

This is annoying, but since rfc2534bis inherits definitions from RFC
2068 (HTTP/1.1), which does not quite use RFC 2234, we can either

- use RFC 2234 and remove all references in syntax to RFC 2068

- keep the | notation (and a few other modifications relative to 2234)
from RFC 2068

Beyond the / vs. |, the major difference is that RFC 2234 is a
character-oriented grammar, while SIP (and HTTP) use a word-oriented
grammar. We'd have to add a lot of LWSP everywhere in the grammar,
basically between every token, as in

Subject  =  ( "Subject" $|$ "s" ) ":" TEXT-UTF8-TRIM

becomes

Subject = ( "Subject" $|$ "s") LWSP ":" LWSP TEXT-UTF8-TRIM

and more complicated grammars become even messier. I'm not convinced
that this visual noise aids understanding, but there may be other
reasons to do this.
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 10 Jul 2001 10:07:39 -0400 (EDT)

> that this visual noise aids understanding, but there may be other

The main motivation for this, IMO, would be that, currently, you have to do
a fairly close reading of the spec in order to determine where LWSP is
allowed.

For instance, consider (just as an example extracted from a quick browsing
of the spec):

        Timestamp  =  "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ]
        delay      =  *(DIGIT) [ "." *(DIGIT) ]

As I understand it, LWSP is *allowed* before and after the colon, is
*required* between the timestamp and the delay, and is *forbidden* before
and after the decimal points, and between the digits.

I think this interpretation is probably derivable from the implicit-lwsp
rules (since "." is a word character but ":" isn't) but it's very
non-obvious.

I've made some attempts at automatically generating a SIP parser from the
grammar in the spec.  The LWSP issue is by far the hardest thing to resolve.

-- 
Jonathan Lennox
[email-masked]

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Tue, 10 Jul 2001 10:27:04 -0400

> a fairly close reading of the spec in order to determine where LWSP is

I agree; this is a problem shared across these types of grammars. RFC
2822 (the successor to RFC 822) tries to be more rigorous and now calls
out LWS and FLWS explicitly.