Subject: Re: RFC 2543 / bug report

From: [email-masked]
Date: Thu, 12 Aug 1999 17:50:48 +0530

Hi Bernie,
The grammar seems fine to me.
Why do you feel the contact params must be outside the brackets ? They are
optional - which the grammar indicates

regds
Arjun

Bernie Höneisen <[email-masked]> on 08/12/99 01:53:34 PM

To:   [email-masked]
cc:
Subject:  RFC 2543 / bug report

Content-type: text/plain; charsetÿ-ascii

Hi,
I am writing a paser for the SIP protocol and found some problem in
RFC 2543. There is a mismatch between the ABNF spec and the examples:
ABNF:
  Contact ÿ "Contact" | "m" ) ":"
             ("*" | (1# (( name-addr | addr-spec )
             [ *( ";" contact-params ) ] [ comment ] )))
>From the examples, that use contact-params:
Contact: <sip:[email-masked]:3890;transportýp>
Contact: <sip:[email-masked]:5080;maddrÿare.caller.com>
These exemples don't follow the ABNF Spec. the contact-params should be
outside the brackets.
Is this an already known bug?
Is there a bug-list available for RFC 2543 ?
What about a possible bug-list for RFC 2327 ?
Greetings
 Bernie

---

From: "Jacek Grabiec" <[email-masked]>
Date: Thu, 12 Aug 1999 09:15:37 -0500

On Thu, 12 Aug 1999 11:23:34 +0300 (EET DST), [email-masked]
(=?ISO-8859-1?Q?Bernie_H=F6neisen?=) wrote:

>  Contact = ( "Contact" | "m" ) ":"
>Contact: <sip:[email-masked]:3890;transport=udp>
>Contact: <sip:[email-masked]:5080;maddr=spare.caller.com>
>
there's no bug, at least in that example. what you refer to as contact-params
(which should be outside brackets)
 transport=udp and maddr=spare.caller.com are url-parameters which go with
addr-spec
(that can be in turn SIP-uri or URI and then you read the grammar for SIP-URI)
regards, Jacek Grabiec

---

From: [email-masked]
Date: Fri, 13 Aug 1999 17:48:09 +0530

Hi,
The following are the problems I faced with the grammar in 2543 ( I also
referred to RFC 2616 , RFC 1123, RFC 2396)
many are minor nitpicks, but generally these are the problems that were
really faced while doing the grammar - I dont know how many other people
are facing the same problem.

* Token telephone-subscriber does not feature on any RHS
* Token extension-name not defined
* Token extension-value not defined
* Token maddr not defined (should be maddr = host)
* Token delta-seconds is defined in RFC 2616 - a reference to it should be
given in 2543 (like other tokens referred to)
*  2543 specifices  port = *digit instead of port = 1*digit (which one of
the referred to RFC corrects)
* credentials and challenge tokens in Proxy-Authorisation and
Proxy-Authenticate are not defined

*        pgp-version      =  "version"           "="      <         ">
digit *( "          .              "digit ) *letter <"          >

          Above is defined  in 15.1.1 in 2543 - is it right ? It indicates
"digit*( " and  "digit ) *letter <" within quotes !

Some further issues:

1) Many parts of the SIP document refer to the HTTP RFC for tokens. The
HTTP 1.1 RFC in turn points to RFC 2396 (URI) which goes on to
define certain parameters which have the same name as other tokens in SIP -
 but with separate definitions.

eg in RFC 2396

   userinfo      = *( unreserved | escaped |
                              ";" | ":" | "&" | "=" | "+" | "$" | "," )

in the SIP RFC,
  userinfo        = user [ ":" password ]

I found two such conflicts:

userinfo and server tokens - both are defined separately in both the RFCs.
We could consider using separate names in 2543 for userinfo
and server.

Above, again, confuses a person trying to layout the grammar

(Note even SDP RFC has common tokens- but thats not too much of a problem -
 typically SDP and SIP signals could be lexed separately,
but atleast SIP should not conflict in tokennames with HTTP1.1 and URI RFC
as they are imported tokens in the same space.)

2) The SIP grammar is quite extensive (especially after importing all the
other references). The grammar programmer can easily
make mistakes in issues like (for example):

2543 says in sec. 4.3 "  The Request-URI is a SIP URL as described in
Section 2 or a general   URI".
However, if a SIP URL is used as a request URI, then it MUST not have
certain fields.

I think it would be a better idea not to reuse more general grammar rules
into specific cases by adding notes in other sections.
Rather, maybe 2543 should define:

Request-URI =  sip-req-url | general-uri  // general-uri is in HTTP 1.1

The point is , the grammar being as extensive as it already is, we could
try and reduce as much confusion by being more specific with
the production rules.

In general: I think it would be better mentioning behaviours specifically
into rules rather that pointing it out at various places as notes
(eg Proxy-Require is treated identical to Requre is a part of notes in
6.28)

Regds
Arjun

Jonathan Rosenberg <[email-masked]> on 08/12/99 08:14:29 PM

To:   [email-masked]
cc:   [email-masked], "Bernie Höneisen" <[email-masked]>
Subject:  Re: RFC 2543 / bug report

[email-masked] wrote:
>
> This brings me to point out that the enire grammar does not seem to be
> complete. When we were writing ours, we noticed quite a few tokens (I
think
> one was delta-seconds and some others)
You're right about delta-seconds. Please share specific other instances
where its missing so it can be fixed.
 that did not have an expansion -
> although some of them were easily understandable . Also, if I remember
> correctly, things like telephone-subscriber etc dont feature on the right
> hand side of any production (the RFC mentions it as an example though, if
i
> remember right)
Also correct. Interestingly, the point of the user parameter is to
indicate whether
the userinfo field is formatted according to telephone-subscriber. Can
lex support
things like that?
>
> also for guys who are actually trying to use a lex tool, some hyperlinked
> version of the complete grammar would be of great help - I have a nearly
> complete linked version (some missing tokens which I did not find are not
> linked) - so if anyone wants it for ease of reference, feel free to take
it
> from me :-) (altho it needs more work ;)
Great! Please send a pointer when its ready.
-Jonathan R.
--
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen