Subject: [Sip] Some more ABNF issues - bis07

From: [email-masked]
Date: Mon, 4 Feb 2002 13:44:15 +0200

1. TEXT-UTF8-TRIM - while the text claims it does not allow leading WS, it 
actually does. should be redefined as:
        TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
        (added "1" before "*")

2. token - isn't there a requirement for a token to start with alphanum ?
        (e.g. current definition allows  -.+!'  as a valid token)

3. SIP-Version - "SIP/2.0" is the current version, but I believe 
        SIP-Version = "SIP/" 1*DIGIT "." 1*DIGIT
        is the general term.

4. line-breaks: Many places allow LWS  (e.g. surrounding the "=" in any 
URL parameter) - which are converted into a single space when parsed. The 
<SWS char SWS> table characters should be used sparingly (if at all)

4. method-extension allows "token". see (1) above

5. parameter ambiguity for URI's. e.g:
        from-spec = ( name-addr = addr-spec ) *( SEMI from-param )
Cannot tell if a parameter is "from-spec" parameter, or "addr-spec" 
(actually, SIP-URI) parameter.
Also, the format suggests that all SIP-URI parameters MUST appear before 
all "from-spec" parameters (otherwise, they are parsed as "extension" 
parameters of the "from-spec".
This actually might be a "good thing" - but should be documented in 
English as well...

Note: this is an "eye" scan, not any automated parser...
Did anyone ran an automated ABNF parser, and passed the "torture test" 
messages ?

/dror

_______________________________________________
Sip mailing list  https://www1.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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Feb 2002 19:58:17 -0500

>         TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)

Good point. Fixed.

>         (e.g. current definition allows  -.+!'  as a valid token)

I don't think there is such a requirement. Certainly not as far as the
parser is concerned.

>         SIP-Version = "SIP/" 1*DIGIT "." 1*DIGIT

I think this is also correct. I am not sure why the BNF was made to
forcefully limit the version to 2.0, since there are torture tests for
higher versions, and a response code to deal with it to.

> URL parameter)

I don't know what gives you that impression that there is LWS in the
URI; there is no LWS in the BNF for any of the URI parameters. They
cannot contain LWS.

ANyway, I don't see the specific problem. Of course there is LWS in
places...?

> - which are converted into a single space when parsed.
> The

We cannot remove them arbitrarily. rfc 2543 allowed optional LWS between
separators and tokens, and between separators and separators. The SWS
expresses this optionality. Removing it would break backwards
compatibility with RFC 2543.

> 4. method-extension allows "token". see (1) above

There is nothing wrong with this. The method +&$ may be ugly, but it
will parse just fine. Asthetic beauty is not important for method
names.... ;)

> (actually, SIP-URI) parameter.

This is discussed in the text.

> parameters of the "from-spec".

Yes.

> This actually might be a "good thing" - but should be documented in

Its mentioned something like three times, once in the header sections
for the From, To and Contact. We don't need yet another mention.

Thanks for your comments,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 19 Feb 2002 15:47:36 -0500

> >         TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)

Unfortunately, as a side effect, this forbids TEXT-UTF8-TRIM from matching
the empty string.  Not intended, I assume.

You need either to stick the whole thing in brackets, or add an explicit 
           /               ; empty 
afterwards.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Feb 2002 04:37:37 -0500

Jonathan Lennox wrote:
> 
> On Monday, February 18 2002, "Jonathan Rosenberg" wrote to
> "[email-masked], [email-masked]" saying:
> 
> >
> >
> > [email-masked] wrote:
> > >
> > > 1. TEXT-UTF8-TRIM - while the text claims it does not allow leading
> WS,
> > > it

I was debating it, but rfc2543 does allow an empty string in Subject and
Organization, so that is the intent.

> You need either to stick the whole thing in brackets, or add an explicit

I took a slightly different approach, which was to put brackets around
TEXT-UTF8-TRIM in the two headers which use it.

THanks,
Jonathan R.