Subject: RE: MESSAGE size limitations (Was: RE: [Sip] Message draft changes)

From: [email-masked]
Date: Tue, 21 May 2002 11:15:40 +0300

Hi,

> > If #2 is in any way possible, let's pursue that. Reading the bis-09
> > again, I can't help but wonder if the RFC2543 option of still trying
> > with UDP, if TCP has failed actually provides value for 
> messages over
> > the UDP maximum datagram size of 65,535 bytes.
> 
> Well, to be honest, there are other reasons why sending such large
> content (over 64k) in SIP directly is a bad idea in any case, 
> TCP or no
> TCP. I can't tell you how many times I've flamed people for 
> sending 10M
> email attachments to mailing lists; I always prefer a URL so 
> that I can
> fetch it at my convenience. 

I totally agree. However, I know of email lists / systems, which have local policy governing the sizes of attachments. I feel such optionality is currently missing from the MESSAGE draft. For example, the default content-indirection policy seems to be that the sender always performs it. How about if this was part of the recipient's service offering? Sort of like a safeguard for UAs behind the low-capacity links.
 
> MMS in the GSM world works the same; everything is via indirection.

But only on the "last hop", i.e., the core MMS infra still has direct content all the way. I actually think this model should be available for the SIP MESSAGE indirection as well.
 
> My concern is actually with the arbitraryness of the 1300 
> number; I fear
> there will be cases when an indirection might even exceed 
> this limit (in
> the case of S/MIME with a cert chain). Last thing we want to do is
> discourage S/MIME usage...

Yes, and in fact concerning this, there is an inconsistency with the SIP spec, which talks about 1300 bytes for the *whole* request. If we abide by that limit, with those lengthy Subject fields etc., there is even less space for the indirection object in the payload.

Cheers,
Aki

_______________________________________________
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: "Dean Willis" <[email-masked]>
Date: Tue, 21 May 2002 15:26:47 -0500

Aki says:
> I totally agree. However, I know of email lists / systems, 
> which have local policy governing the sizes of attachments. I 
> feel such optionality is currently missing from the MESSAGE 
> draft. For example, the default content-indirection policy 
> seems to be that the sender always performs it. How about if 
> this was part of the recipient's service offering? Sort of 
> like a safeguard for UAs behind the low-capacity links.

It's called a B2BUA or "in network UA" -- it accepts the SIP message,
stores the content, and sends a new message (containing a pointer) on
towards the user. Like other B2BUA-ish things, this capability is
implicit in the current specification.

But yeah, it's a cool and useful service opportunity.

I use something very similar to send snippets of large emails to my
mobile devices. Then I can look at the snippets and guess if it's worth
downloading full text at $10/MB . . .

--
Dean