Re: [Simple] Questions regarding MSRP drafts

[Avshalom Houri <AVSHALOM at il.ibm.com>]

I think that it should be done and finished
with. If someone has ideas how to improve it,
they can suggest another alternative
on a new draft and a new work item.

SIP implementations can not afford not
finishing with MSRP now. Session IM is more
then needed for deployments.

Avshalom
IBM

Paul Kyzivat <pkyzivat at cisco.com>
Sent by: simple-bounces at ietf.org

12/08/2005 12:53 AM

To	Remi Denis-Courmont <remi.denis-courmont at nokia.com>
cc	SIMPLE <simple at ietf.org>
Subject	Re: [Simple] Questions regarding MSRP drafts

Remi,

Lets see what others have to say. I think most people just want this 
done. It has been restarted multiple times over a couple of years, and
we just can't afford for it not to be done. If we were to reopen it for
the kinds of changes you are suggesting we would effectively be 
reengineering it from scratch - these kind of changes are fundamental.

                
Paul

Remi Denis-Courmont wrote:
>                  Hello,
> 
> Le mer 10/08/2005 à 23:33, ext Paul Kyzivat a écrit :
> 
>>The cases where reordering can occur are actually pretty obscure
I 
>>think. (Somebody correct me if I am wrong.) The one I can think
of is:
>>
>>- Two connections between a pair of relays. Two messages from same
>>connection get sent, one over each connection. The 1st message
is very 
>>long, while the 2nd is very short. The last byte of the 2nd message
may 
>>be received before the last byte of the first message. Then it
gets 
>>forwarded on.
> 
> 
> That only happens if relays are to maintain multiple connections to
the
> same peer. Might be wrong, but I doubt ensuring they only have one
> connection at a time (of course renewing should it fail) would pose
any
> problem nor much additionnal load.
> 
> On the other hand, supporting re-ordering, without any sane limit
on the
> re-ordering window size sounds very dangerous and prone to abuse to
me.
> At least, there ought to be an error code for client not able or not
> willing to accept a chunk because of memory constraints.
> 

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple