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

From: [email-masked]
Date: Tue, 25 May 2004 21:23:28 +0300

If the receiver has the ability to reject and SEND before it has received the whole content (be it in chunks or not), then this feature is useful, but not required, IMO.

Mandating chunking for messages larger than x bytes seems to enable receivers to send back a 4xx response telling the sender to stop.

Closing the socket is another solution, but it is not a elegant one.

/Hisham

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 25.May.2004 20:28
> To: Christer Holmberg (JO/LMF)
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked]
> Subject: Re: [Simple] Re: MSRP: Max message size indication
> 
> 
> Let me step up a level:
> 
> By the required vs useful discussion, I was referring to the 
> feature of 
> being able to signal size limitations itself, rather than 
> some aspect of 
> the feature.
> 
> So, what do others about whether the feature of being able to signal 
> message size limits is required?
> 
> Christer Holmberg (JO/LMF) wrote:
> 
> > Hi,
> > 
> > 
> >>(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."
> > 
> > 
> > Well, the max-receive is required, and I think it is very 
> useful. As I wrote earlier, the question is if it should be 
> possible to indicate separate values for different media types.
> > 
> > The max-send is not required, but I still think it would be 
> very useful. Earlier I gave some examples I think are very 
> valid (nodes may try to reserve memory according to how much 
> big messages then can expect to receive, redirection/forking 
> may be done based on the information etc etc etc). It 
> wouldn't have any impacts on the protocol functionality 
> itself, and there would be no interop problems with nodes 
> that don't understand the max-send attribute/parameter (or 
> just don't care about it).
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > 
> > 
> >>[email-masked] wrote:
> >>
> >>
> >>>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: "Chris Boulton" <[email-masked]>
Date: Tue, 25 May 2004 19:45:09 +0100

I think this feature would certainly be useful for max receive (if it was type specific) BUT I am not convinced about send.
 
Chris.

	-----Original Message----- 
	From: Ben Campbell [mailto:[email-masked]] 
	Sent: Tue 25/05/2004 18:27 
	To: Christer Holmberg (JO/LMF) 
	Cc: [email-masked]; [email-masked] 
	Subject: Re: [Simple] Re: MSRP: Max message size indication

	Let me step up a level:
	
	By the required vs useful discussion, I was referring to the feature of
	being able to signal size limitations itself, rather than some aspect of
	the feature.

	Christer Holmberg (JO/LMF) wrote:
	
	>>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."
	>
	>
	> Well, the max-receive is required, and I think it is very useful. As I wrote earlier, the question is if it should be possible to indicate separate values for different media types.
	>
	> The max-send is not required, but I still think it would be very useful. Earlier I gave some examples I think are very valid (nodes may try to reserve memory according to how much big messages then can expect to receive, redirection/forking may be done based on the information etc etc etc). It wouldn't have any impacts on the protocol functionality itself, and there would be no interop problems with nodes that don't understand the max-send attribute/parameter (or just don't care about it).
	>
	> Regards,
	>
	> Christer Holmberg
	> Ericsson Finland
	>
	>
	>
	>>>>do it, the general approach seems good at the first read, anyway. I

This message has been scanned for viruses by MailControl - www.mailcontrol.com
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple