Subject: RE: [Simple] Re: MSRP: Max message size indication

From: [email-masked]
Date: Tue, 25 May 2004 19:50:24 +0300

I think max-receive is useful, but not max-send.

/Hisham

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Ben Campbell
> Sent: 25.May.2004 17:49
> To: Christer Holmberg (JO/LMF)
> Cc: [email-masked]'
> Subject: [Simple] Re: MSRP: Max message size indication
> 
> 
> (Oops, itchy trigger finger--ignore my last mail on the subject.)
> 
> I do not have strong feelings on this as a requirement. If we 
> do want to 
> do it, the general approach seems good at the first read, anyway. I 
> don't think there is a need for the non-type specific size attribute. 
> The only advantage would be to reduce size of the SDP. I 
> don't see that 
> as a big requirement, since it normally only happens one per session.
> 
> Do others have thoughts on the matter? Do we need this feature at all?
> 
> 
> 
> Christer Holmberg (JO/LMF) wrote:
> 
> > Hi,
> > 
> > As agreed at the SIMPLE interim meeting MSRP discussion I 
> am bringing to the list the issue about being able to 
> indicate the max content size a node is able to receive. 
> Also, as input, in chapter 4 of 
> draft-rosenberg-simple-messaging-requirements-01.txt there is 
> a requirement for such functionality:
> > 
> > REQ-CONTENT-1: A UA MUST be able to indicate the maximum 
> message size it is willing to receive. 
> > 
> > I think it would be useful if clients could indicate the 
> maximum payload size he is able to receive, and also send, 
> either per type or stream. Note that I am talking about the 
> total message/content size, not the size of individual 
> fragments (the spec does say that messages bigger than 2k 
> should be fragmented).
> > 
> > If the max size is dependent on the media type, max size 
> could be defined as a accept-type token paramter:
> > 
> > example:
> > 
> > accept-type: X;max-send=1000;max-receive=1000, 
> Y;max-send=2000;max-receive=500
> > 
> > And, if the message size it not type dependent, generic max 
> size attributes could be used.
> > 
> > example:
> > 
> > a=max-send: 1000
> > a=max-receive:1000
> > 
> > Even if one is not going to send more than the other party 
> indicates he is able to receive I still think it is important 
> that a node can indicate how much he is able to send. For 
> example, the remote node may reserve memory according to that 
> information, and/or intermediate proxies may do 
> forking/routing based on the client capabilities.
> > 
> > An MSRP "message size too big" error code could also be 
> useful, if a node for whatever reason is not able to accept a 
> SEND message. This may be due to that the remote node is 
> sending more data than was agreed in the offer/answer, but 
> also due to that the receiving node for a short period isn't 
> able to receive the agreed data size (if the max size change 
> is permanent a new offer should of course be sent, instead of 
> sending an error reply to every SEND). At the interim meeting 
> is was desired to have a mechanism to "interrupt" the 
> receival of a message, and this error code could be used to 
> indicate that. The sender would then stop sending the 
> message, and any possible yet unsent fragments.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 May 2004 11:53:27 -0500

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 May 2004 11:55:47 -0500

(Ignore my yet-another-empty reply. This time I blame the combined 
ergonomics of Thunderbird and my laptop.)

That brings up an interesting meta-question. What is the bar for putting 
new features into MSRP at this stage? Is "useful" enough? Or should we 
limit new features to things that we decide are "required."