Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)

Thank you Paul,

I think you are right, under failure circumstances chunks might be sent 
over different MSRP sessions, if a new session is re-established.

So, I believe the only mechanism we have for a permanent deletion of a 
partially received message is set a timer.

In a chat room environment, this means that when this type of failure 
occurs, the MSRP switch might have sent a number of chunks to the rest of 
the participants, leaving the total message incomplete at those 
endpoints. I wonder if the MSRP switch should, in this case, create an 
abort chunk ("#" flag) to avoid that the rest of the endpoints remain in 
a strange state. I think so.

/Miguel


On 04/09/2012 17:29, Paul Kyzivat wrote:
> Because a failed TCP connection may be reestablished, and the chunk sent
> over the new connection, you can't use connection loss as a trigger for
> giving up on incomplete chunked messages.
>
> The receiver has no firm way to distinguish between a chunk that has
> been a chunk that has been lost and one that has simply been delayed.
> This has to be dealt with via implementation policies and heuristics.
>

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain