Subject: RE: [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 12:27:48 +0100

Exactly! But that avoids the possibility of having any kind of
confirmation of message delivery when using a relay that has to store
the message. Is there a way to specify this in the current drafts?
What if A still wants to know that the message was correctly delivered
to B?

/Ignacio

-----Original Message-----
From: Hisham Khartabil [mailto:[email-masked]]
Sent: den 23 mars 2005 12:00
To: Ignacio Más Ivars (KI/EAB)
Cc: Simple WG
Subject: Re: [Simple] "draft-ietf-simple-message-sessions-10.txt:
Message ID and store and forward scenarios

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

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

---

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

Remember, we are talking about SESSIONS. If A wants to see the delivery 
report, then A needs to keep that session open until it gets the 
report. It you are talking about A crashing. Then it is an 
implementation issue how to build a recovery mechanism for that.

Hisham