Subject: RE: [Sip] MAJOR Open Issue #184: Message size limitations

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 6 Dec 2001 14:09:42 -0000

> Issue:
[...]
> 2. The spec imposes no specific limits on the sizes of 
> various headers, or the number of each type of header.
> However, many implementations have chosen their own
> limitations, often based on a guess, in order to allocate
> maximum buffer sizes and the like. This has resulted in
> some interoperability problems. Ideally, we should allow
> any number of each header, and any size for any element,
> up to the maximum allowed SIP message size (64k), but
> this is not realistic.

Hello.  Call me "Devil's Advocate".
Why is this not realistic?

 - Jo.

_______________________________________________
Sip mailing list  http://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: Gordon Ledgard <[email-masked]>
Date: Thu, 6 Dec 2001 13:09:17 -0500

I agree with Mike on option 1 and 2 below being NOT desirable.
I should think that it would be fairly easy to come up with
a way to frag SIP messages without deeply disturbing most
implementations, at least at the parsing layer. Unfortunately,
I can't think of how you would do it without hitting some
rather nasty backward compatibility issues.

But I think setting field size limits would be worse.

Gordon Ledgard

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Thursday, December 06, 2001 12:54 PM
To: Jonathan Rosenberg
Cc: [email-masked]'
Subject: [Sip] MAJOR Open Issue #184: Message size limitations

Jonathan Rosenberg writes:
 > 2. The spec imposes no specific limits on the sizes of various headers,
or
 > the number of each type of header. However, many implementations have
chosen
 > their own limitations, often based on a guess, in order to allocate
maximum
 > buffer sizes and the like. This has resulted in some interoperability
 > problems. Ideally, we should allow any number of each header, and any
size
 > for any element, up to the maximum allowed SIP message size (64k), but
this
 > is not realistic.

   I do not understand why this should be a problem given
   a reasonable implementation. Fixed sized fields suck;
   lets not go there. 

 > Discussion:
 > 
 > There are no simple solutions to these problems. For the first problem,
some
 > of the solutions include:
 > 
 > 1. deprecate UDP; use only TCP or SCTP for SIP
 > 2. deprecate UDP for server to server, only allow it client to server. 
 > 3. define sip layer fragmentation
 > 4. ignore the problem
 > 
 > (4) is not so unreasonable, in fact. Assuming messages don't get THAT
much
 > larger, we will usually see two fragments, which isn't too bad from a
loss
 > amplification perspective. It is a problem for NAT, but if you assume NAT
is
 > client to server only, and users are using TCP there anyway, its solved.
Not
 > ideal, but none of the solutions is.

   I would be highly *unsupportive* of 1 or 2. Beyond that
   I'm not sure. Compression may be our friend here.

	   Mike

---

From: Scott Bradner <[email-masked]>
Date: Fri, 28 Dec 2001 13:29:38 -0500 (EST)

> i'm wasting too much bandwidth on this, but my point att the time has
> been that someone already has convinced IESG not to have MUST there,

the IESG has not yet spoken but at the time that 2543 was done it
was not envisioned that SIP would be used for Instant Messaging which
seems to be used for just about everything including large MP3 files

in retrospect I think we made an error in having that a SHOULD

Scott