Subject: [Simple] "draft-ietf-simple-message-sessions-10.txt: Message ID and store and forward scenarios

From: Ignacio Más Ivars (KI/EAB)<[email-masked]>
Date: Wed, 23 Mar 2005 11:31:05 +0100

Hi all:

We have identified an scenario for which we can have a problem by having a unique message ID *only* in the content of the MSRP session. The problem arises in the following scenario:

A -- Relay -- B

- A send a message to B, B is offline. Relay answers with 200 OK with the message ID and stores the message...
- A goes offline. The MSRP conection terminates. B comes online.
- Relay sends the message to B, perhaps rechunking or joining chunks with the same message ID
- B tries to send a REPORT with the message ID, which gets stored in Relay
- When A comes back online Relay opens a MSRP connection to it, to send just the REPORT. A needs to have kept some state about 'waiting for REPORT' for message ID. Here is where we can have the problem is A opens some other MSRP connection to A in the meantime and reuses that ID. So the unique property should be enforced in the clients ... since there could be a new connection A - Relay with the same URL as the previous one...

Could it be possible to make the message ID unique for the MSRP session *and* any previous sessions with a pending REPORT? Specifically we could change the description of the message ID in draft-ietf-message-session-10.txt from:

"7.1.1  Delivering SEND requests

   When an endpoint has a message to deliver, it first generates a new
   unique Message-ID.  This ID MUST be unique within the scope of the
   session.  If necessary, it breaks the message into chunks.  It then
   generates a SEND request for each chunk, following the procedures for
   constructing requests (Section 7.1)."

To:
"...This ID MUST be unique in the within the scope of the session **and any previous sessions with pending REPORTS**..."

Another possibility would be to add it to the draft of relay extensions, but I have not found an proper place to introduce it yet. Comments to the depicted scenario?

Thanks!

/Ignacio

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

---

From: Hisham Khartabil <[email-masked]>
Date: Wed, 23 Mar 2005 12:00:06 +0100

When a client (client A in your example) chooses to close a session, it 
is also choosing to forgo receiving any reports to pending requests. I 
thought the MSRP draft says that somewhere, but I don't remember in 
which section (or was that text lost at some point between versions?).

Hisham

On Mar 23, 2005, at 11:31 AM, Ignacio Más Ivars (KI/EAB) wrote:

> Hi all:
>
> We have identified an scenario for which we can have a problem by 
> having a unique message ID *only* in the content of the MSRP session. 
> The problem arises in the following scenario:
>
> A -- Relay -- B
>
> - When A comes back online Relay opens a MSRP connection to it, to 
> send just the REPORT. A needs to have kept some state about 'waiting 
> for REPORT' for message ID. Here is where we can have the problem is A 
> opens some other MSRP connection to A in the meantime and reuses that 
> ID. So the unique property should be enforced in the clients ... since 
> there could be a new connection A - Relay with the same URL as the 
> previous one...
>
> Could it be possible to make the message ID unique for the MSRP 
> session *and* any previous sessions with a pending REPORT? 
> Specifically we could change the description of the message ID in 
> draft-ietf-message-session-10.txt from:
>
> "...This ID MUST be unique in the within the scope of the session 
> **and any previous sessions with pending REPORTS**..."
>
> Another possibility would be to add it to the draft of relay 
> extensions, but I have not found an proper place to introduce it yet. 
> Comments to the depicted scenario?
>
> Thanks!
>
> /Ignacio
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Mar 2005 10:11:40 -0500

> which section (or was that text lost at some point between versions?).

And some added thoughts:

This offline/online of A and B: I presume you mean that the TCP 
connection is closed. It says somewhere that to replace that requires 
another offer/answer in the same dialog. This will set up a new path end 
to end. A and B can then know there is a relationship between the old 
and new paths, and attempt to recover from messages that were not 
completely delivered. But the relays have no way to know of any 
relationship between the old and new paths. So a message sent thru an 
old path will simply fail if one of the connections is down.

The recovery for this is for A to note that it never got a 
Success-Report and then to decide to retransmit the message.

However, this all assumes that A and B themselves remain online in order 
to maintain the dialog and reestablish the session via reinvite. I get a 
feeling the scenario is intended to reflect a store-and-forward relay in 
a situation where A and B are literally not online at the same time. 
MSRP is not intended to support this case. If that is what you want, 
then I think you need an automaton (an "IM-Mail" server) that can 
receive IMs, store them, and then retain for future access by a real user.

	Paul