Subject: [Simple] MSRP comments - request/response handling and retrying

From: Aki Niemi <[email-masked]>
Date: Thu, 16 Oct 2003 19:02:29 +0300

Hi,

In the draft, if a SEND times out, the MSRP client is supposed to handle 
this as if a 5xx was received. I.e., it will resend the message a few 
times and then quit the session. In case the other endpoint is in the 
midst of sending a large message, a response may take  longer than the 
request time out value. This will result in a number of duplicate 
messages received. There should be a better way to handle this. Why 
resend in the first place, especially if the connection is active?

Also, what is the motivation for making retransmissions with a different 
TR-ID? Doesn't this go agains the idea of retrying the request?

Regards,
Aki

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 12:44:08 -0500

Based on recent discussions, I think we may need to rethink this. The 
point to resending was _not_ to build a reliability mechanism on top of 
TCP. We really wanted a mechanism to simply warn the user if we could 
not be sure the opposite endpoint had actually processed the message. I 
think we should either remove the text encouraging re-submission, or 
change it to re-use the same TR-ID, and add text to describe what the 
peer should do if it sees duplicate TR-IDs.

Having a response delayed by a long request in the recipricol direction 
is a problem I don't think we have considered. I welcome input as to 
whether we think this is a real issue, and if so, how to deal with it.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 17 Oct 2003 12:44:08 -0500