Subject: [SIP] Simplify SIP

From: Bertil Engelholm <[email-masked]>
Date: Fri, 18 Aug 2000 10:56:16 +0200

Hello,

we would like to start a discussion about the possibility of making 
SIP more simple than today. We realize that it's a little late to
make big changes in the protocol at this stage but the change we
propose seems quite small. This proposal is our personal proposal 
and is not in any way reflecting the Ericsson point of view 
(not yet anyway).

We feel that SIP today is unnecessary complex which costs time
during development and testing of a SIP parser. It also cost 
execution time which we can see no reason for. Maybe there are 
historic reasons why SIP is specified as it is but since the 
specification does not explain this (which it shouldn't) we 
can't see the reason for certain constructions. We understand 
that HTTP has been a great influence when specifying SIP but 
we have not heard any explanation why. 

In general we think SIP allows too many optional ways of doing things. 
Each of these options cost development time, testing time and 
execution time in every SIP enabled product. And since some SIP
UA most likely is small devices with limited processor power, memory
size etc. it must be interesting to reduce the amount of code
needed to parse the SIP messages. 
Every option also adds the possibility of introducing bugs which 
we noticed during the last bakeoff. So by making SIP more 
simple we think it will be easier to develop SIP enabled products 
with better quality in shorter time. This would at the end help 
spreading SIP even faster than today which we hope everyone is 
interested in doing (at least in this mail group). 

So what we basically suggest is that only the canonical representation
should be used. All other formats should be depricated in the same
way as the different ways of terminating the SIP-headers was depricated
some time ago. In this way SIP will still be backwards-compatible 
since everyone has to be able to receive the canonical representation.
It will just take some time for everyone to adapt their code so
they only send out the canonical representation. After a while it's 
possible to make a new version of SIP that only allows the canonical
form. Then it's up to everyone to decide if they want to support
both SIP 2.0 as well as the new version or only the new version.

According to the SIP specification (chapter 13.2 in rfc2543bis-01) 
the canonical representation restricts the SIP syntax in this way :

* No short form header fields;   
* Header field names are capitalized as shown in the rfc;   
* No white space between the header name and the colon;   
* A single space after the colon;   
* Line termination with a CRLF;   
* No line folding;   
* No comma separated lists of header values; each must appear as a
separate header;   
* Only a single SP between tokens, between tokens and quoted strings,
and between quoted strings; no SP after last token or quoted string;   
* No LWS between tokens and separators, except as described above for
after the colon in header fields;   
* The To and From header fields always include the < and > delimiters
even if the display-name is empty. 

We can't see any problem in any of these restrictions. Some of them
only restricts how many white space characters you are allowed to use 
so those restrictions can't be any problem to introduce. Why send extra
spaces that only adds unnecessary bytes to the messages ?

To disallow the compact form of the headers might be a problem but
since using the compact form only saves about 70-80 bytes a UA still
have to be able to handle the case where the message don't fit in
one MTU. If this is a real problem why not define a compact form 
for _all_ headers in SIP and only use that form ? 

To capitalize the header field names exactly as they are specified
in the RFC does not seem to be a problem either. Why should it be
possible to write e.g. Content-Length as cOnTeNt-lEnGtH ?

Line folding is also something we can't see any reason for. Since
all UA/Servers have to be able to _receive_ any length of a header 
line why can't they _send_ every header in one line ?  

To allow a comma separated list in the Via and Record-Route etc.
is one of the optional things that seems unnecessary. Especially 
since it creates longer lines which means you might need line folding.
Since all UA that intend to handle Authentication have to use the 
canonical representation anyway why not always use it ?

We realize that it's a little bit late in the SIP development to
make changes in the protocol but we feel that these changes are 
not very big since it's already specified in the RFC. 

If everyone is happy with todays specification we can live with 
it too since we have already implemented it. But we feel that it 
would help SIP to spread faster in the future by making it as 
simple as possible to parse.  

So what do you think. Is this proposal something you think
is worth introducing or is it better to keep things as it is ?

-- 
Bertil Engelholm	[email-masked] 
Eric Turesson		[email-masked]

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Gethin Liddell <[email-masked]>
Date: Fri, 18 Aug 2000 14:50:06 +0100

i agree.

the sip specification is not easy to implement, for the main reason
that you have to be able to accept the same information in many
different ways.

conforming to the canonicial form should not be a hardship for anyone
and will make everyone's implementations faster thanx to a, probably
quite noticable, efficiency gain.

-- 
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 18 Aug 2000 10:53:28 -0400

If I had it over again, I would eliminate line folding, case
insensitivity, and a host of other things. But, when the spec was begun,
it was decided that rather than inventing new syntax, we would borrow
from a clearly successful, highly interoperable, well understood
protocol for which a whole lot of code was available. That meant we
inherited the good along with the bad. 

Because we must be backwards compatible with rfc2543, there is no choice
but to insist implementations handle line folding and other things (in
reality its not so bad once you construct a tokenizer than knows about
line folding. In this way, it is handled once. My old C code for this
was on the order of 50 lines). We could have rfc2543bis insist on
sending in some canonical form, but it won't help parsers which must
anyway handle the various forms. I suppose eventually those could be
phased out, but there is a fair amount of SIP out there already, so I
don't know that non-canonical form would be gone that soon.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 18 Aug 2000 07:42:31 -0700

I am not sure to agree with this. 
SIP is not so difficult to parse and adding such restrictions can have a
negative impact on my personal SIP protocol analyzer (The one I have in
my head :-). 
Text-based protocols (HTTP, MGCP, Megaco, SMTP, POP3...) have this
characteristic that they can be easily used with language like Perl,
Java and even directly with telnet. I think this restrictions look like
a step in direction of a binary protocol.

Just my opinion.

-- 
Marc Petit-Huguenin
Home: mailto:[email-masked]
Work: mailto:[email-masked]
"So much to do and so little time" The Joker - Batman (The Movie)

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 18 Aug 2000 18:48:04 +0100

Just to add my two pence...

I found line folding and the comma separation a bit of a pain when doing our
SIP implementation.

I feel that if someone does a quick and dirty implementation of SIP, then
this is something they may either forget or just leave out.

As one of the attractions of SIP is its simplicity (at least the appearance
of such!), then I feel such quick and dirty jobs may appear in a number of
places.  This would lead to interoperability problems.

Therefore I think it would be reasonable for the spec to strongly suggest
that messages generated by a UA should not use line folding and comma
separation.  I think such advice would remove a whole bunch of potential
interoperability problems between industrial strength implementations and
quick jobs you might knock up in Perl or something to give you some neat
feature.

However, I agree that if you want to be industrial strength then you have no
choice but to cope with line-folding and comma separation for ever more.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

----- Original Message -----
From: Jonathan Rosenberg <[email-masked]>
To: Gethin Liddell <[email-masked]>
Cc: Bertil Engelholm <[email-masked]>;
<[email-masked]>
Sent: 18 August 2000 15:53
Subject: Re: [SIP] Simplify SIP

> > > make big changes in the protocol at this stage but the change we

... snip...

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 18 Aug 2000 17:04:44 -0500

Pete,

Gee, it's so difficult to handle line folding in Perl!
It takes a whole line!  And gee: that space before the
colon on the headers takes three characters of Perl!
Those case-insensitive comparisons are soooo difficult!

Don't be ridiculous: these aspects of parsing could be
coded on an MC6800 chip in assembler in less than an hour!

    $msg = <>;
    ($header, $body) = split(/\r?\n\r?\n/,$msg,2);
    ($start, $header) = split(/\r?\n/,$header,2);
    $header =~ s/\r?\n\s+/ /g; # handle line folding
    @headers = split(/(?:^|\r?\n)(\S+?)\s*:\s*/s,$header);
    shift @headers;
    %headers = ( @headers );
    foreach $k ( keys %headers ) {
        print $k.': '.$headers{$k}
    }

Pete Cordell wrote:                           (Fri, 18 Aug 2000 18:48:04)
[snip]
> I think such advice would remove a whole bunch of potential

-- 
Brian F. G. Bidulock
[email-masked]

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 18 Aug 2000 23:49:09 +0100

An hour - I could do it on a diode in 2 seconds...  And where's your
handling of comma separation!!!

Perl is good at this sort of thing.  That's probably why I use it to hack
things together.  Hence why I mentioned Perl when hacking.

But there are other languages that people hack around with that are not
quite as good as Perl for this sort of exercise.  Why make interoperability
problems if they can easily be avoided by generating easier code to parse in
the first place.  If anything, its the polite thing to do and it doesn't
really cost you anything.

BTW - You could write a bit of Perl to find where I mentioned something
about spaces before colons if you like!!

Pete.

----- Original Message -----
From: Brian F. G. Bidulock <[email-masked]>
To: Pete Cordell <[email-masked]>
Cc: Jonathan Rosenberg <[email-masked]>; Gethin Liddell
<[email-masked]>; Bertil Engelholm <[email-masked]>;
<[email-masked]>
Sent: 18 August 2000 23:04
Subject: Re: [SIP] Simplify SIP

---

From: jimmy Zhang <[email-masked]>
Date: Fri, 18 Aug 2000 16:38:26 -0700

Just want to add to what you said, Perl's regex package stems from
Henry
Spencer's v8 regex package written in C.  If you don't like that package,
you
can also look at the perl's source code for regex packages.

     Even implementing perl's parsing features needed for SIP in C from
scratch
is also doable, the trick is to only implement what is needed, not any more.

     So parsing SIP can be done is C, perl, Java, not mentioning assembly.

--

Jimmy zhang ([email-masked])

Software Engineer