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

From: "Andrew Allen" <[email-masked]>
Date: Tue, 25 May 2004 13:34:39 -0400

This proposal makes a lot of sense for mobile devices which have limited memory and for which the transmission bandwidth may be limited and the cost of which may be significant.

It makes little sense to transmit (at a charge) and overwhelm a UA with data that it cannot handle. 

With messaging we are dealing with the potential interoperability between devices with significantly different memory and and communication link capacities so this feature seems an important requirement to include.

Since the message sessions draft is at a stage where it is still easy to make such a change it would seem now is the time to include this enhancement which seems relatively straight forward.

Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
European Mobile    +358 50 467 5870
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld

-----Original Message-----
From: [email-masked] <[email-masked]>
To: Christer Holmberg (JO/LMF) <[email-masked]>
CC: [email-masked]' <[email-masked]>
Sent: Tue May 25 10:48:52 2004
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: [email-masked]
Date: Mon, 7 Jun 2004 12:57:47 -0500

Hi,

I would say yes/yes as well, but it would be at session initiation.  Since the limit selected would be platform dependent it does not make sense to send the max on every message.
The supporting point here is that allowing small terminals to speed things up a bit by letting the terminal transmit capabilities to the peer to make things easier is a definite plus.

I agree with Christer that this should be an OPTION only.

Corby Wilson
Nokia

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Christer Holmberg (JO/LMF)
Sent: Monday, June 07, 2004 1:23 PM
To: 'Paul Kyzivat'; Ben Campbell
Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); Chris Boulton; [email-masked]
Subject: RE: [Simple] Re: MSRP: Max message size indication

Hi,

I disagree, and my answer is yes/yes.

>I'm inclined to agree with you (no/no). For many nodes this is simply 
>not a number that is easily decided. If anything, I imagine 
>it would be  best to negotiate this. But that requires the sender to pick 
>a maximum send value, even though the sender probably has no particular limit. 
>This just seems like a rat hole best avoided for now.

The support and use of the attribute/parameter would be OPTIONAL, so if a node doesn't support the attribute/parameter (it is not able to calculate a value, it can't be configured, or the node simply thinks that size doesn't matter) everything will still work, as today, and it will then be "local policy" what to do if the messages can't be handled.

Of course, a node can send a 4xx response if the message it receives is too big, but as I said before, there may be scenarios where the size information is used to make decissions already at the session setup phase.

As Andrew said, this feature is especially useful for mobile devices, or other nodes with limited memory.

And, since there is a requirement at least for the receiving part, I assume it at some stage has been realized that the information could be useful.

Regards,

Christer Holmberg
Ericsson Finland

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 7. kesäkuuta 2004 19:55
> To: Ben Campbell
> Cc: Chris Boulton; [email-masked]; 
> [email-masked]; Christer
> Holmberg (JO/LMF)
> Subject: Re: [Simple] Re: MSRP: Max message size indication
> 
> 
> Ben,
> 
> 
> 	Paul
> 
> Ben Campbell wrote:
> > I'd like to try and get some closure on this:
> > 
> > Please answer yes or no to the following:
> > 
> > 1) Should we add the optional signaling of the maximum 
> content size you 
> > are willing to _receive_ into the SDP exchange.
> > 
> > 2) Should we add the optional signaling of the maximum 
> content size you 
> > are planning to _send_ into the SDP exchange.
> > 
> > 3) If either 1 or 2 is yes, do we send one value for the 
> session, or one 
> > value per each type for which we have indicated support.
> > 
> > My personal opinions:
> > 
> > No and No. In all honesty, I think this could be a useful 
> feature, but I 
> > don't think MSRP has to have it to function. I am voting 
> no, not because 
> > I disagree with the feature, but because I don't want to 
> add additional 
> > work to completing MSRP unless it is absolutely necessary. But if 
> > consensus says we need it, I do not object on any technical basis.
> > 
> > 
> > 
> > 
> > Chris Boulton wrote:
> > 
> >> 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.
> >>     
> >>     So, what do others about whether the feature of being 
> able to signal
> >>     message size limits is required?
> >>     
> >>     >>(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
> >>     >>>
> >>     >>>
> >>     >>>
> >>     >>>>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]'
> >>     >>>>I do not have strong feelings on this as a 
> requirement. If we
> >>     >>>>do want to
> >>     >>>>don't think there is a need for the non-type specific size
> >>     >>
> >>     >>attribute.
> >>     >>
> >>     >>>>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?
> >>     >>
> >>     >>>>
> >>     >>>>
> >>     >>>>>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
> >>     >>>>
> >>     >>>>
> >> This message has been scanned for viruses by MailControl - 
> >> www.mailcontrol.com
> >>
> >>
> >>
> >> 
> --------------------------------------------------------------
> ----------
> >>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 7 Jun 2004 20:41:49 +0200

Hi Paul,

>You say this is all optional. But then you say that some 
>nodes will make use of sender maximum size to allocate resources on the 
>receiving node. So what happens when the sender doesn't specify?
> 
>1) sender specifies nothing, receiver assumes worst case.
>(The most it could possibly receive.) How is this
>better than doing nothing?

[CHH] If the sender doesn't specify anything I guess the message size is not very critical for him. The receiver, if then receiving too large messages (the sender doesn't understand the attribute/parameter if sent by the receiver), can then reject them using a suitable 4xx response code. But, the idea it to avoid these kind of situations.
As I've said before, intermediate proxies may use the information for routing, to find the "best" receiver, or the receiver may have reserved more memory from the beginning (it may for example have refused or shut down some other services, in order to get more memory).

>2) sender specifies nothing, receiver picks something
>less than worst case. Then there are things the
>sender won't be able to send that could have been
>sent had the sender requested so in advance. Not nice.

[CHH] Of course there may be good and bad mechanisms for clients to choose a value, and if a node chooses a much lower value than it actually would be able to handle it's not very nice, and there is then a chance that nothing will be sent. However, the main reason for a node to insert a value is because it does have limited memory (or, it will reserve memory according to what it indicates), not just "for fun".

>I'm not opposed to investigating it further. But I do agree with Ben 
>that it is likely to slow things down. And if you intend for it to be 
>optional then it should be no problem to add later.

[CHH] I really don't see how this would slow things down. Again, I see no needs to define how to handle one-node-supporting-and-one-node-not-supporting scenarios, because if one node doesn't support the information just won't be available.

Regards,

Christer Holmberg
Ericsson Finland

> > The support and use of the attribute/parameter would be 
> OPTIONAL, so if a node doesn't support the 
> attribute/parameter (it is not able to calculate a value, it 
> can't be configured, or the node simply thinks that size 
> doesn't matter) everything will still work, as today, and it 
> will then be "local policy" what to do if the messages can't 
> be handled.
> > 
> > Of course, a node can send a 4xx response if the message it 
> receives is too big, but as I said before, there may be 
> scenarios where the size information is used to make 
> decissions already at the session setup phase.
> > 
> > As Andrew said, this feature is especially useful for 
> mobile devices, or other nodes with limited memory.
> > 
> > And, since there is a requirement at least for the 
> receiving part, I assume it at some stage has been realized 
> that the information could be useful.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > 
> > 
> > 
> > 
> > 
> >>>>    >>>>(Oops, itchy trigger finger--ignore my last mail 
> >>>
> >>on the subject.)
> >>
> >>>>    >>>>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 7 Jun 2004 20:27:20 +0200

Hi Corby,

>I would say yes/yes as well, but it would be at session 
>initiation.  Since the limit selected would be platform 
>dependent it does not make sense to send the max on every message.

Correct. Of course, one COULD include it in an updated offer, if the size limit for whatever reason changes. But again, nodes that don't support the attribute/parameter would simply ignore it.

>The supporting point here is that allowing small terminals to 
>speed things up a bit by letting the terminal transmit 
>capabilities to the peer to make things easier is a definite plus.

Exactly.

Regards,

Christer Holmberg
Ericsson Finland

> [mailto:[email-masked]] On Behalf Of ext Christer 
> Holmberg (JO/LMF)
> As Andrew said, this feature is especially useful for mobile 
> devices, or other nodes with limited memory.
> 
> And, since there is a requirement at least for the receiving 
> part, I assume it at some stage has been realized that the 
> information could be useful.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> 
> 
> > >>     >>>>do it, the general approach seems good at the 
> first read, 
> > >> anyway. I

---

From: [email-masked]
Date: Tue, 8 Jun 2004 10:47:22 +0300

> From: ext Christer Holmberg (JO/LMF)
> [mailto:[email-masked]]
> Sent: 07.June.2004 20:23
> Cc: Chris Boulton; Khartabil Hisham (Nokia-TP-MSW/Helsinki);
> [email-masked]

So, You send me an offer with receive-max-size of 1500 bytes, but I don't understand that parameter. This doesn't help you. I send you a message with 1Meg and you have to reject it with a 4xx anyway. So where is the benefit of having this as optional?

/Hisham

---

From: [email-masked]
Date: Tue, 8 Jun 2004 12:11:35 +0300

Christer,

Are you suggesting that SIP intermediaries examine the body of a SIP message to make service/routing decisions? I see a problem here with intermediaries examining SIP message bodies. What routing decision did you have in mind? What services did you have in mind that require this feature? Can you please present some explicit use cases?

Also, if you are referring to MSRP intermediaries, then using SDP to signal this does not help since there is no interface between MSRP relays and the signalling network (that we will definitely not define).

BTW, you have elevated the requirement from "the terminal cannot handle such size messages" to "the network needs to do something". Which is you requirement?

Regards,
Hisham

> Sent: 08.June.2004 11:09
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki); [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Hi Hisham,
> >So, You send me an offer with receive-max-size of 1500 bytes, 
> >but I don't understand that parameter. This doesn't help you. 
> >I send you a message with 1Meg and you have to reject it with 
> >a 4xx anyway. So where is the benefit of having this as optional?
> 
> The benefit is that you may have scenarios or network 
> architectures where this information is used (not only by the 
> end terminals, but also by intermediate nodes) for making 
> service/routing/etc decissions. Of course, a node may always 
> send too large messages, which have to be rejected (using a 
> 4xx response), but the idea is to have a mechanism where this 
> can be avoided. If big messages are to be sent I think it is 
> very useful to have this information, in order to adjust 
> terminal settings, and to make the transmission smooth, and 
> in order to send lots of stuff on the network that may be 
> rejected (that data may then have to be retransmitted, using 
> smaller messages, or the session may fail).
> 
> This is similar to any other SDP attribute. If you don't 
> support it, you discard it, and things should work anyway - 
> but IF you support it it may provide you with useful 
> information for optimal performance.
> 
> However, IF people prefear making support mandatory, I 
> personally don't have anything against that. But, that's not 
> what I am proposing, because I do realize there may be 
> scenarios where this kind of information is not needed. 
> Another option is making it mandatory, and defining a default 
> value if the information is not present (similar to the 
> "sendrecv" media direction attribute), but that is not what I 
> am proposing either. My issue is that I think it's useful to 
> have this kind of information.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> > 
> > /Hisham
> > 
> > > 
> > > > >>     >>>>The only advantage would be to reduce size of 
> > the SDP. I
> > > > >>     >>>>don't see that

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 13:34:16 +0200

Hi Hisham,

>Are you suggesting that SIP intermediaries examine the body 
>of a SIP message to make service/routing decisions?

[CHH] I gave that as an example, yes. It depends on how people impelemnt their intermediates, what information they use to do decissions etc. This kind of information MAY be used for service/routing/whatever decissions.

>I see a problem here with intermediaries examining SIP message 
>bodies. What routing decision did you have in mind? What 
>services did you have in mind that require this feature? Can 
>you please present some explicit use cases?

[CHH] I don't it's very strange if I have a proxy (OR an end-node) which does eg routing (or other kind of) decisions based on body information (eg media types, codecs, accept-type in the case of MSRP, etc etc etc supported), or other message information. However, the point was to give an example where this kind of information MAY be useful before the session has been established. I have not said that an intermediate MUST use this information.

>Also, if you are referring to MSRP intermediaries, then using 
>SDP to signal this does not help since there is no interface 
>between MSRP relays and the signalling network (that we will 
>definitely not define).

[CHH] I was referring to SIP intermediates, for example forking proxies. I appologise if I wasn't clear enough on that.

>BTW, you have elevated the requirement from "the terminal 
>cannot handle such size messages" to "the network needs to do 
>something". Which is you requirement?

[CHH] The only requirement, as far as I can remember, I have been referring to is that a terminal shall be able to indicate the message size it is able to receive. The rest have been examples and cases where I think this kind of information could be useful. 

What requirement have I put on the network? What I said was that if a terminal sends messages which are too big for the other to handle that will cause unecessary traffic on the network, and therefor it could be useful to have the size information already before anything is sent (and eg rejected by 4xx).

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 8 Jun 2004 14:50:47 +0100

Arguing that it is optional does not mean it should go into an RFC with issues attached. We have to solve all the issues even for optional capabilities, and even with restrictions, to be be adopted, it must still be useful.

Our concern on this is that while a message receiver may know the maximum size messages it can buffer, any message sender would require an interaction with the use of the application to decide what that maximum might be. In most, if not all message sessions, that sending size might not be known until the time it is required to send a message, and the overflow may possibly not be known until the sender has started sending the message.

Thus I see some need by the receiver of a message to abort a message when the internal buffers get full. What happens then - we still need to deal with this case even if a size is negotiated. My assumption is that an application would do the best to render what it has, accompanied by some meaningful notation. Further recovery would then take place at the application layer, e.g. a reply message saying "send your message again without the picture because it was too big for my receiver to handle". 

Now give that we have to do that anyway, do we gain any advantage in the few cases where the future message size is known at session establishment time.

regards

Keith

> From: Christer Holmberg (JO/LMF) 
> Sent: 07 June 2004 18:23
> Cc: [email-masked]; Chris Boulton; [email-masked]

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 19:28:58 +0200

Hi Keith,

Comments inline ([CHH])

>Arguing that it is optional does not mean it should go into 
>an RFC with issues attached. We have to solve all the issues 
>even for optional capabilities, and even with restrictions, 
>to be be adopted, it must still be useful.

[CHH] The proposal to make it optional was not be get around other issues. Of course they have to be solved - no matter if we have a max size indicator or not.
 
>Our concern on this is that while a message receiver may know 
>the maximum size messages it can buffer, any message sender 
>would require an interaction with the use of the application 
>to decide what that maximum might be. In most, if not all 
>message sessions, that sending size might not be known until 
>the time it is required to send a message, and the overflow 
>may possibly not be known until the sender has started 
>sending the message.

[CHH] Of course, I am sure there are cases where there may be overflows, and for that we need a way to reject a message which is already being sent. This we need no matter if we have a size indicator or not.

However, if I do indicate a max size buffer to you, at least you have some value to use when you start sending me messages. Your issue about WHEN a node really knows how much it can receive I think is an implementation issue.
 
>Thus I see some need by the receiver of a message to abort a 
>message when the internal buffers get full.
>What happens then - we still need to deal with this case even if a size is 
>negotiated.

[CHH] I totally agree. And, there has being discussions about sending a 4xx response before the message has been received.

>My assumption is that an application would do the best to render what it has, accompanied by some meaningful 
>notation. Further recovery would then take place at the application layer, e.g. a reply message saying "send your 
>message again without the picture because it was too big for my receiver to handle". 

[CHH] Again, I agree. But, I still think many of these scenarios could be avoided by indicating the max size already before the message is sent. And, as I wrote in one of my initial posts, even if I have indicated that I receive X bytes, there may be periodic occations when I am not, in which case I may have to reject your message. But again, IF I at the session setup know how much I will be able to receive, at least most of the time, most of these overflow scenarios can be avoided. 

And, if you don't know how much you will be able to receive, you don't indicate anything, and will then reject messages if too big.

And, even if you don't know how much you will be able to receive, I can still indicate to you (using the max-SEND attribute) how much I will be able send, which could be useful information for you.

>Now give that we have to do that anyway, do we gain any 
>advantage in the few cases where the future message size is 
>known at session establishment time.

[CHH] Well, it depends how "few" those cases are.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 19:31:22 +0200

Hi Ben,

I am pretty sure the main use of this would be for the end terminals. I mentioned the routing proxies as another example where it could be useful to have this information at setup time.

Regards,

Christer Holmberg
Ericsson Finland

> From: Ben Campbell [mailto:[email-masked]]
> Sent: 8. kesäkuuta 2004 17:42
> Cc: [email-masked]'; [email-masked];
> [email-masked]; [email-masked]
> I don't want to get too deep in this until we have results on 
> the "vote" 
> (running neck and neck at the moment.) But to risk jumping into 
> mechanism, comments inline:
> 
> If this is something we expect proxies to use for routing 
> decisions, we 
> should consider doing it in the headers, rather than in the 
> body. So, is 
> there anything in caller-prefs that will help here?
> 
> 
> >>>>>work to completing MSRP unless it is absolutely 
> >>
> >>necessary. But if 
> >>
> >>>>>consensus says we need it, I do not object on any 
> >>
> >>technical basis.
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>>>Chris Boulton wrote:
> >>>>>
> >>>>>
> >>>>>>[mailto:[email-masked]]     Sent: Tue 
> >>>
> >>>25/05/2004 18:27 
> >>>
> >>>>>>    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.
> >>>>>>    
> >>>>>>    >>That brings up an interesting meta-question. What 
> >>>
> >>>is the bar
> >>>
> >>>>>>    >>should we limit new features to things that we 
> >>
> >>decide are 
> >>
> >>>>>>"required."
> >>>>>>    >
> >>>>>>    >
> >>>>>>    > Well, the max-receive is required, and I think 
> >>
> >>it is very 
> >>
> >>>>>>try to reserve memory according to how much big messages 
> >>>
> >>>then can 
> >>>
> >>>>>>expect to receive, redirection/forking may be done 
> >>
> >>based on the 
> >>
> >>>>>>functionality itself, and there would be no interop 
> >>>
> >>>problems with 
> >>>
> >>>>>>    >>>>don't think there is a need for the non-type 
> >>>
> >>>specific size
> >>>
> >>>>>>    >>
> >>>>>>    >>attribute.
> >>>>>>    >>
> >>>>>>    >>>>as a big requirement, since it normally only 
> >>
> >>happens one
> >>
> >>>>>>    >>
> >>>>>>    >>per session.
> >>>>>>    >>
> >>>>>>    >>>>>As agreed at the SIMPLE interim meeting MSRP 
> >>>
> >>>discussion I
> >>>
> >>>>>>    >>>>
> >>>>>>    >>>>indicate the max content size a node is able 
> >>
> >>to receive.
> >>
> >>>>>>    >>>>>REQ-CONTENT-1: A UA MUST be able to indicate 
> >>
> >>the maximum
> >>
> >>>>>>    >>>>
> >>>>>>    >>>>>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
> >>>
> >>>>>>    >>>>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
> >>
> >>>>>>    >>>>
> >>>>>>    >>>>>Even if one is not going to send more than the 
> >>>
> >>>other party
> >>>
> >>>>>>    >>>>
> >>>>>>    >>>>that a node can indicate how much he is able 
> >>
> >>to send. For
> >>
> >>>>>>    >>>>>An MSRP "message size too big" error code 
> >>
> >>could also be
> >>
> >>>>>>    >>>>
> >>>>>>    >>>>SEND message. This may be due to that the 
> >>
> >>remote node is
> >>
> >>>>>>    >>>>sending more data than was agreed in the 
> >>>
> >>>offer/answer, but
> >>>
> >>>>>>    >>>>receival of a message, and this error code could 
> >>>
> >>>be used to
> >>>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 19:46:02 +0200

Hi Hisham,

>Furthermore. If my terminal has 10Meg free memory and some 
>logic decides that my IM session application gets 10% of that 
>(1 Meg), so I signal max-receive-size of 1 Meg.
> 
>In the mean time, I have downloaded a 9 Meg mpeg from some 
>sight. My quota for IMS session would now change to 100K. Do 
>I resignal that max-receive-size has changed?

[CHH] You MAY do so, using an updated offer, if you want to. I wrote some text about that in my initial posts.
 
>Also, after I have signalled that the max-receive-size is 
>1Meg, I receive a 1 Meg message and I accept it (since it did 
>not exceed the 1Meg max size limit). Then I receive a second 
>one of those 1 Meg messages, do I accept?

[CHH] It's up to your implementation. The max-size attribute, even if support would be mandatory, does NOT take away the need to be able to reject a message, if one for whatever reason is not able to receive it.

>What does max-receive-size really mean? Max size of messages 
>in total in this session? Max size of 1 message? 

[CHH] I think I in my initial post very clearly indicated that max size of 1 message - ie NOT the total size of all messages, and NOT the size of a message fragment.

>How can I ever possibly determine the maximum message size I can 
>receive is? In any case, rejecting a message because of size 
>needs to be supported.

[CHH] Again, I agree. Others have said that, and I have said that.

>Too many questions, too little time -> I vote no/no (not as a chair)

[CHH] I have answered some of your questions. The other questions are valid even without the max-size attribute, so they need to be solved anyway.

Regards,

Christer Holmberg
Ericsson Finland

> > Of ext Drage, Keith (Keith)
> > Sent: 08.June.2004 16:51
> > Cc: [email-masked]
> > message when the internal buffers get full. What happens then 
> > - we still need to deal with this case even if a size is 
> > negotiated. My assumption is that an application would do the 
> > best to render what it has, accompanied by some meaningful 
> > notation. Further recovery would then take place at the 
> > application layer, e.g. a reply message saying "send your

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 19:54:42 +0200

Hi Aki,

>I'll have to vote for no/no. I don't think it solves the real problem,
>which is not having the sender/recipient ability to abort transfer
>mid-message.

I never said this will solve all problems :) Again, the idea is to reduce the situations where you would have to reject a message, but of course you still will need a mechanism for that.

Regards,

Christer Holmberg
Ericsson Finland

> 
> Cheers,
> Aki
> 
> On Mon, 2004-06-07 at 18:30, ext Ben Campbell wrote:
> receive (if it was type specific) BUT I am not convinced about send.
> > >  
> > > Chris.
> > >  
> > > 
> > > 	Sent: Tue 25/05/2004 18:27 
> > > 	Cc: [email-masked]; [email-masked] 
> > > 	By the required vs useful discussion, I was referring 
> to the feature of
> than some aspect of
> > > 	>>(Ignore my yet-another-empty reply. This time I blame 
> the combined
> "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.
> > > 	>
> 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
> > > 	>
> > > 	>
> > > 	>
> > > 	>>>>>And, if the message size it not type dependent, generic max
> > > 	>>>>
> > > 	>>>>indicates he is able to receive I still think it is 
> important
> > > 	>>>>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
> > > This message has been scanned for viruses by MailControl 
> - www.mailcontrol.com
> > > 
> > > 
> > > 
> > >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 8 Jun 2004 22:33:41 +0200

Hi,

>I just replied to a similar comment from Gonzalo. I had 
>forgotten about that requirement in the draft. That requirement seems to me 
>to require being able to indicate the max size you are willing to 
>receive. It does not seem to require indicating the max size you intend to send.

That is correct. I did mention the requirement a long time ago (I copy/pasted the requirement text in a post, as Gonzalo also did), and have referred to it a few times since then. But, there has been so many posts, and there are also a number of other issues, so I understand that information may get lossed :)

And, as you also said (and which I think I've also said before), the requirement is for indicating the max size you intend to receive only. There is no written requirement to indicate the max size you intend to send. That is something I've proposed to add since I think the information could be useful.

Regards,

Christer Holmberg
Ericsson Finland

> > If for no other reason (ie if nobody thinks the usage 
> examples I've given are valid), I think the requirement 
> (REQ-CONTENT-1) is the "mandate" we need. Or, have I 
> missunderstood the requirment? Of course the meaning of the 
> requirement could be that one should be able to indicate the 
> size in an error response, but the text about offer/answer, 
> and that negotiation is needed , at least to me sounds that 
> negotiation is what it's really about.
> > 
> > Now, of course, if there are technical reasons and/or big 
> problems why a requirement can not be fullfilled we need to 
> re-visit the requirments, and possibly change/remove 
> something. But, so far most of the comments have been about 
> that fact that this doesn't solve the issue when messages 
> need to be rejected. However, the max-size attribute is not 
> supposed to solve that issue, and the requirment says nothing 
> about that issue, so I don't see why we should remove a 
> requirement just because it doesn't solve something it's not 
> even supposed to solve...
> > 
> > If we remove requirements just becuase we suddenly don't 
> think they are needed I wonder how much work we have put on 
> the requirements in the first place, especially when we have 
> came this far with the actual protocol. 
> > 
> > HOWEVER, I would really not like to use the requirements as 
> an argument, and I really hope we all think we have stable 
> requirements - instead I have tried to describe the technical 
> reasons why I think this would be useful.
> > 
> > Regards,
> > 
> > Christer Holmberg
> > Ericsson Finland
> > 
> > 
> > 
> > 
> > 
> >>Sent: 8. kesäkuuta 2004 20:46
> >>To: Aki Niemi
> >>So far, I have had 4 people (counting myself) respond no/no, 
> >>2 respond 
> >>yes/yes, and one equivocation that I interpret as yes/no.
> >>
> >>This is a pretty small fraction of the work group. If only 
> >>seven people 
> >>care enough to even comment, I'm not sure we have a mandate 
> for this.
> >>
> >>So, if there is anyone out there who cares but has not said 
> >>so, please 
> >>do so soon.
> >>
> >>Aki Niemi wrote:
> >>
> >>
> >>>I'll have to vote for no/no. I don't think it solves the 
> >>
> >>real problem,
> >>
> >>>>>	>>>>(Oops, itchy trigger finger--ignore my last mail on 
> >>
> >>the subject.)
> >>
> >>>>>	>>>>
> >>>>>	>>>>do it, the general approach seems good at the first 
> >>
> >>read, anyway. I
> >>
> >>>>----------------------------------------------------------
> --------------
> >>>>

---

From: "Andrew Allen" <[email-masked]>
Date: Tue, 8 Jun 2004 18:39:52 -0400

Ben,

Please count me in the Yes/No column.

I think for now to comply with KISS I think we should just do it as a
global receive max-size and not per type. 

Andrew

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Ben Campbell
> Sent: Tuesday, June 08, 2004 1:46 PM
> To: Aki Niemi
> Cc: [email-masked]; Chris Boulton; [email-masked];
Christer
> So far, I have had 4 people (counting myself) respond no/no, 2 respond
> This is a pretty small fraction of the work group. If only seven
people
> care enough to even comment, I'm not sure we have a mandate for this.
> 
> So, if there is anyone out there who cares but has not said so, please
> do so soon.
> 
> Aki Niemi wrote:
> 
> >>1) Should we add the optional signaling of the maximum content size
you
> >>2) Should we add the optional signaling of the maximum content size
you
> >>3) If either 1 or 2 is yes, do we send one value for the session, or
one
> >>No and No. In all honesty, I think this could be a useful feature,
but I
> >>don't think MSRP has to have it to function. I am voting no, not
because
> >>I disagree with the feature, but because I don't want to add
additional
> >>>I think this feature would certainly be useful for max receive (if
it
> >>>	By the required vs useful discussion, I was referring to the
feature
> of
> >>>	So, what do others about whether the feature of being able to
signal
> >>>	>>(Ignore my yet-another-empty reply. This time I blame the
combined
> >>>	>>for putting new features into MSRP at this stage? Is "useful"
> enough? Or
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
> >>>	>
> >>>	>
> >>>	>
> >>>	>>>>I do not have strong feelings on this as a requirement. If
we
important
> >>>	>>>>example, the remote node may reserve memory according to
that
> >>>	>>>>useful, if a node for whatever reason is not able to accept
a
> >>>	>>>>is permanent a new offer should of course be sent, instead
of
> >>>	>>>>sending an error reply to every SEND). At the interim
meeting
>>>---------------------------------------------------------------------
--
> -

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 9 Jun 2004 16:08:43 +0200

Hi Jonathan,

>I havent been following this discussion entirely, but here is 
>my input.
> 
>The requirement in the requirements document is strictly 
>talking about indicating the maximum an endpoint is willing to receive. The primary 
>purpose of this is for devices like mobile handsets, which want to be 
>able to tell a peer "hey, don't send a huge image, I don't 
>want to pay  for that". I think its better to indicate this during the sdp 
>exchange, rather than have the mobile cut off an incoming messages once 
>it reaches that limit.

Exactly. That is also what I have said all the time.

Regards,

Christer Holmberg
Ericsson Finland

> -Jonathan R.
> forgotten about 
> > that requirement in the draft. That requirement seems to me 
> to require 
> > being able to indicate the max size you are willing to 
> receive. It does 
> > not seem to require indicating the max size you intend to send.
> > 
> examples I've 
> >> given are valid), I think the requirement (REQ-CONTENT-1) is the 
> >> "mandate" we need. Or, have I missunderstood the 
> requirment? Of course 
> >> the meaning of the requirement could be that one should be able to 
> >> indicate the size in an error response, but the text about 
> >> offer/answer, and that negotiation is needed , at least to 
> me sounds 
> >> that negotiation is what it's really about.
> >>
> problems why 
> >> a requirement can not be fullfilled we need to re-visit the 
> >> requirments, and possibly change/remove something. But, so 
> far most of 
> >> the comments have been about that fact that this doesn't solve the 
> >> issue when messages need to be rejected. However, the max-size 
> >> attribute is not supposed to solve that issue, and the 
> requirment says 
> >> nothing about that issue, so I don't see why we should remove a 
> >> requirement just because it doesn't solve something it's not even 
> >> supposed to solve...
> >>
> think they 
> >> are needed I wonder how much work we have put on the 
> requirements in 
> >> the first place, especially when we have came this far 
> with the actual 
> >> protocol.
> >> HOWEVER, I would really not like to use the requirements as an 
> >> argument, and I really hope we all think we have stable 
> requirements - 
> >> instead I have tried to describe the technical reasons why I think 
> >> this would be useful.
> >>
> >> Regards,
> >>
> >> Christer Holmberg
> >> Ericsson Finland
> >>
> >>
> >>
> >>
> >>
> >>> So far, I have had 4 people (counting myself) respond no/no, 2 
> >>> respond yes/yes, and one equivocation that I interpret as yes/no.
> >>>
> >>> people care enough to even comment, I'm not sure we have 
> a mandate 
> >>> for this.
> >>>
> >>> So, if there is anyone out there who cares but has not said so, 
> >>> please do so soon.
> >>>
> >>> Aki Niemi wrote:
> >>>
> >>>
> >>>>>> [email-masked]; [email-masked]     Subject: Re: 
> >>>>>> [Simple] Re: MSRP: Max message size indication
> >>>>>>     
> >>>>>>     
> >>>>>>
> >>>>>>     Let me step up a level:
> >>>>>>     
> >>> very useful. As I wrote earlier, the question is if it should be 
> >>> possible to indicate separate values for different media types.
> >>>
> >>>>>>     >
> >>> 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 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>

---

From: [email-masked]
Date: Wed, 9 Jun 2004 12:11:53 +0300

> From: ext Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 09.June.2004 10:39
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; Niemi Aki (Nokia-M/Espoo);
> [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Hisham,
> so, what is the purpose of the *advanced* requirements? Are they going
> to be used to develop a new protocol different from MSRP, are 
> they going
> to be used to develop extensions to MSRP, or are they going to be just
> ignored?

They will be used to develop extensions to MSRP as well as solutions that will just work with MSRP (isComposing is one example), depending on the requirement.

> 
> In any case, if these are not the requirements that apply to 
> MSRP, where
> are the requirements that do apply?

Some of those requirements do apply to MSRP, but as extensions. I am unaware of any other requirements documents besides RFC2779.

Regards,
Hisham

> Gonzalo
> > This draft is called "Advanced Instant Messaging 
> Requirements for the Session Initiation Protocol". Note the 
> word "Advanced". It means additional, not base requirements.
> > 
> > We are not at a stage yet where solutions for advanced 
> requirements can be discussed. The draft is not even a WG 
> item. There are, however, some exceptions: In some cases, it 
> was found necessary to incorporate some of the advanced 
> features to make the protocol usable (eg: DSNs).  Max message 
> size is not one of those.
> > 
> > Regards,
> > Hisham
> > 
> > 
> >>From: ext Gonzalo Camarillo [mailto:[email-masked]]
> >>Sent: 08.June.2004 22:14
> >>To: Ben Campbell
> >>Cc: Niemi Aki (Nokia-M/Espoo); Khartabil Hisham 
> >>(Nokia-TP-MSW/Helsinki);
> >>Chris Boulton; [email-masked]; Christer Holmberg (JO/LMF); Jonathan
> >>Rosemberg
> >>let me try to understand the discussion here. We have a 
> requirements 
> >>document (written by Jonathan) that says the following:
> >>
> >>http://www.ietf.org/internet-drafts/draft-rosenberg-simple-mes
> >>saging-requirements-01.txt
> >>
> >>    "REQ-CONTENT-1: A UA MUST be able to indicate the 
> maximum message
> >>       size it is willing to receive."
> >>
> >>According to the requirements, the protocol MUST support 
> it... do you 
> >>want to go through the requirements phase again at this point?
> >>
> >>Gonzalo
> >>
> >>
> >>
> >>Ben Campbell wrote:
> >>
> >>
> >>>So far, I have had 4 people (counting myself) respond 
> >>
> >>no/no, 2 respond 
> >>
> >>content size 
> >>>>>you are willing to _receive_ into the SDP exchange.
> >>>>>
> >>content size 
> >>>>>you are planning to _send_ into the SDP exchange.
> >>>>>
> >>session, or 
> >>>>>one value per each type for which we have indicated support.
> >>>>>
> >>>>>My personal opinions:
> >>>>>
> >>feature, 
> >>>>>but I don't think MSRP has to have it to function. I am 
> >>
> >>voting no, 
> >>
> >>>>>not because I disagree with the feature, but because I 
> >>
> >>don't want to 
> >>
> >>>>>add additional work to completing MSRP unless it is absolutely 
> >>>>>necessary. But if consensus says we need it, I do not 
> >>
> >>object on any 
> >>
> >>>>>technical basis.
> >>>>
> > 
> 
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland                   http://www.hut.fi/~gonzalo
> 
> 
>

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Jun 2004 10:26:39 +0100

Before we start accepting draft-rosenberg-simple-messaging-requirements-01.txt as the final answer on messaging requirements, I don't actually remember any discussion that adopted these as the basis for messaging. 

I do remember Jonathan, after some protocol discussion, reissuing the document and saying something like it was time to go back to discussing requirements, but I remember no pronouncement from anybody, let alone the working group chairs, that they therefore agreed these were the requirements we were now working to.

Further there have been other requirements documents, e.g. draft-mahy-simple-im-protocol-reqs that have been equally ignored.

So why should I believe any of these documents as anything more that the input by the original authors?

regards

Keith

> Sent: 08 June 2004 20:21
> To: Gonzalo Camarillo
> Cc: Jonathan Rosemberg; [email-masked]; Aki 
> Niemi; Christer
> Holmberg (JO/LMF); Chris Boulton; [email-masked]
> Gonzalo Camarillo wrote:
> >    "REQ-CONTENT-1: A UA MUST be able to indicate the maximum message
> Ah, I missed making that connection. Avoiding the question of 
> which came 
> first (agreed upon MSRP requirements and that document) for 
> the moment, 
> this would seem to support the yes/no vote. (That is, ability 
> to express 
> max you are willing to receive vs max you intend to send.)
> 
> Since we have a written requirement, I propose we move 
> forward with "max 
> I am willing to receive" part, but not "the max I intend to 
> send" part.
> 
> > 
> > Gonzalo
> > 
> > 
> >

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 10 Jun 2004 06:45:42 +0200

Hi,
 
ONE of the things max-send can be used for, is for the other party to choose (alone or with whatever other functions and mechanisms) a proper max-receive value to return.
 
Regards,
 
Christer Holmberg
Ericsson Finland

-----Original Message-----
From: Alex Audu [mailto:[email-masked]]
Sent: 9. kesäkuuta 2004 23:54
To: Adam Roach
Cc: Ben Campbell; Christer Holmberg (JO/LMF); [email-masked]; [email-masked]'; [email-masked]; [email-masked]
Subject: Re: [Simple] Re: MSRP: Max message size indication

I think there is great value in  end-point being able to signal the maximum size of data it is
willing /able to accept at a time. This information could be used by the sender to, for example
send a less memory intensive version of say an image, instead of a full blown memory hungry
version.  This will allow the information to be communicated with a decreased risk of truncation
at first try. That makes for a more efficient communication (than without this feature). 

I don't see the need  to signal max-send size.   So I vote yes/no

Cheers,
Alex.

Adam Roach wrote:

the "vote" (running neck and neck at the moment.)

Put me in the no/no camp.

/a

Simple mailing list

[email-masked] <mailto:[email-masked]> 

https://www1.ietf.org/mailman/listinfo/simple <https://www1.ietf.org/mailman/listinfo/simple>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 10 Jun 2004 07:05:49 +0200

Hi,

I also think it's important to define what you mean by "usable". It's probably true that from a pure core protocol perspective this is not needed, but I think I have presented (at least I've tried) cases where this information can be usable for the user of the protocol, and/or the protocol stack implementation.

Also, I personally don't see this requirment as very "advanced", based on the fact that since I don't think it doesn't have any impacts on the core protocol functionality itself. I really would understand if this is something which could mess up everything we've done so for, or if it otherwise would take a long time to put into what we've done so far, but I don't think that is the case.

Regards,

Christer Holmberg
Ericsson Finland

> Of [email-masked]
> Sent: 9. kesäkuuta 2004 9:48
> To: Gonzalo Camarillo (JO/LMF); [email-masked]
> Cc: [email-masked]; Christer Holmberg (JO/LMF);
> [email-masked]; [email-masked]; [email-masked]
> This draft is called "Advanced Instant Messaging Requirements 
> for the Session Initiation Protocol". Note the word 
> "Advanced". It means additional, not base requirements.
>

---

From: "Atle Monrad (GR/ETO)" <[email-masked]>
Date: Thu, 10 Jun 2004 12:20:27 +0200

Hi

As we provides SW to multiple terminal manufacturers within 3gpp, we se a benefit with flexibility within the MSRP protocol. The messaging applications are likely to vary, depending on the ideas of e.g. application developers, network models (intermediaries or not) and  charging models.

1. We would like the possibility to reject an incoming message as soon as we realise it's over the acceptable size limit.

2. We would like the possibility to give recommentations from the receiving handset on how big messages the handset want/can receive. From this point of view, I'm in at least in the the yes/no camp, even if max-send may be useful in certain cases. Definitely, yes/yes is better than no/no ;-)

When you inform the peer entity about the max size of the message you want to receive, that may be useful information to the sender, as he knows that you most likely will reject a longer message, thus he shouldn't attempt to send it. I do not see a need for lots of text around this. In particular, I do not think possible algorithms describing the background of how the sender came up with the max-send figure is needed at all. Just go for a minimum text outlining the SDP-attribute.

/atle monrad
Ericsson Mobile Platform

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of [email-masked]
Sent: 10. juni 2004 10:56
To: Gonzalo Camarillo (JO/LMF); Christer Holmberg (JO/LMF)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [Simple] Re: MSRP: Max message size indication

Gonzalo,

We need to be sure that this feature is useful. It is definitely a nice to have and not a must feature. I have posted a list of questions that need answering in an earlier email. We also need to provide guidelines on how to create this value, what it can be used for and how useful it is. I am not yet convinced that it is useful unless you mandate the message sender to obey it and indicate how the value can be generated.

Of course we need time to discuss its usefulness. Solving it is not an issue.

/Hisham

> Sent: 10.June.2004 11:07
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
> [email-masked];
> [email-masked]; [email-masked]; Niemi Aki
> (Nokia-M/Espoo); [email-masked]
> Folks,
> we are using more time in discussing this small issue than 
> what it would 
> take to resolve it. People are asking for an *optional* SDP attribute 
> that allows a UA to say "Hey, FYI: I cannot receive messages 
> over 40 KB".
> 
> Writing the specification of such an SDP attribute would take, 
> literally, less than 10 minutes, because you do not need any type of 
> negotiation or any type of special offer/answer behavior. It 
> is only an 
> attribute that is sent to the receiver of the SDP "For His 
> Information". 
> If the receiver does not understand it, nothing bad happens.
> 
> Some people have claimed that the addition of such attribute 
> could delay 
> the standardization of the protocol (I have not heard any technical 
> reason against this parameter)... given that it is only an *optional* 
> informational attribute that can be defined in a couple of 
> paragraphs, 
> its inclusion would not delay the protocol at all.
> 
> So, if nobody has a better reason for excluding this attribute that 
> claiming that it would delay things, I propose that we add its 
> definition to MSRP and move on to issues that do have a real 
> impact in 
> the MSRP protocol machinery.
> 
> Gonzalo
> 
> 
>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 30 Jun 2004 11:41:16 +0200

Hi,

>Trying to be more specific. The SDP parameter is a max size the person
>receiving the SDP should send. It is the max size of the 
>message not the chunk. The receiver SHOULD NOT send messages larger than 
>this. It is the size of the content not the size of the message.

Yes.

Regards,

Christer Holmberg
Ericsson Finland

> 
> Cullen,
> 
> 
> And if it is set to 1 it means you are in character by 
> character T.140 mode
> :-) The previos line is a joke I'm not suggesting that
> 
> 
> On 6/28/04 12:56 PM, "Ben Campbell" <[email-masked]> wrote:
> 
> > I believe the conclusion is to allow signaling max size you wish to
> > receive, but not to signal the max you intend to send.
> > 
> >> So, do we have some kind of conclusion on this?
> >> 
> >> Some people have asked for use-cases, and scenarios where 
> this can be useful,
> >> and I think a number of those have now been presented.
> >> 
> >> Regards,
> >> 
> >> Christer Holmberg
> >> Ericsson Finland
> >> 
> >> 
> >> 
> >>> Sent: 15. kesäkuuta 2004 2:04
> >>> To: [email-masked]
> >>> Cc: Adam Roach; [email-masked]';
> >>> Holmberg (JO/LMF); [email-masked]; Ben Campbell
> >>> Alex Audu wrote:
> >>>> I think there is great value in  end-point being able to 
> signal the
> >>>> maximum size of data it is
> >>>> willing /able to accept at a time. This information could
> >>> 
> >>> be used by the 
> >>> 
> >>>> sender to, for example
> >>>> send a less memory intensive version of say an image,
> >>> 
> >>> instead of a full
> >>> 
> >>>> blown memory hungry
> >>>> version.  This will allow the information to be 
> communicated with a
> >>>> decreased risk of truncation
> >>> This is the most compelling argument for this feature that I
> >>> have seen.
> >>> 
> >>> Paul
> >>> 
> >