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

From: [email-masked]
Date: Thu, 10 Jun 2004 11:56:18 +0300

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

> -----Original Message-----
> From: ext Gonzalo Camarillo [mailto:[email-masked]]
> Sent: 10.June.2004 11:07
> To: Christer Holmberg (JO/LMF)
> Cc: Khartabil Hisham (Nokia-TP-MSW/Helsinki); 
> [email-masked];
> [email-masked]; [email-masked]; Niemi Aki
> (Nokia-M/Espoo); [email-masked]
> Subject: Re: [Simple] Re: MSRP: Max message size indication
> 
> 
> 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
> 
> 
> 

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 10 Jun 2004 12:27:18 +0300

Hisham,

> We need to be sure that this feature is useful. It is definitely a
> nice to have and not a must feature. 

A bunch of people have said that they need this feature. So, we are 
talking about a feature whose complexity is negligible, that is needed 
by some people, that would take 10 minutes to specify, and that, if you 
do not need it, you just don't implement it... really, what is the problem??

> 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, 

You create this value based on your device's limitations (i.e., up to 
local policy).

 > what it can be used
 > for

If an entity understands this attribute, it SHOULD NOT send messages 
bigger that what the attribute says to the remote end.

 > 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.

I guess you are having problems understanding the optionality of the 
attribute. Let me give you an example. My SIP device does not support 
video. So, my presence information says that I am available on a device 
that only supports audio. If you want to call me, your terminal fetches 
my presence information, and does not even try to offer me video. If 
directly invites me to an audio-only session.

Now, since implementing presence in a device is optional, you may have a 
SIP UA which does not support it. If you try to call me from that 
device, you will invite me to a video session... since we know that 
presence is an optional feature, my terminal is ready to reject your 
video stream. That is, we have a rejection mechanism in place.

Exactly the same thing as with the max-rev attribute. If you understand 
the attribute, you wouldn't even try to send me big messages. If you do 
not understand it (because it is optional and you did not want to 
implement it), you will send me big messages, and I will reject them 
using the rejection mechanism. Not optimal, but still works. This is the 
meaning of optional here.

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

Again, if this is useful to a bunch of people, and the rest do not need 
to worry about it, we should go for it and move on.

Gonzalo