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: Fri, 25 Mar 2005 17:22:07 +0100

Paul,

I agree that this requires much more than what it's in the specs right now. Of course, I agree that delaying the development of MSRP is not something we want to do. We'll think about the concrete requirements for the store and forward architecture and propose them later as an addition. Thanks anyway for the interesting discussion!

Cheers,
/Ignacio

-----Original Message-----
From: Paul Kyzivat
To: Ignacio Más Ivars (KI/EAB)
Cc: Hisham Khartabil; Simple WG
Sent: 3/24/2005 3:00 PM
Subject: Re: [Simple] "draft-ietf-simple-message-sessions-10.txt: Message ID	and store and forward scenarios

Ignacio,

Lets assume there was a IM-automaton.  There are then two completely 
independent MSRP end-to-end sessions:
- A to Automaton
- Automaton to B

I think we can presume that A establishes an MSRP session, sends a bunch

of messages, and then terminates the session. If there is some glitch in

this process and the session is lost, if a dialog remains A may be able 
to reinvite and negotiate a subsequent and related session. In that case

the messages in that session may be merged in to the sequence from the 
first session. The end result of this is a message sequence that B will 
ultimately want to retrieve.

If this message sequence is to be transferred to B via MSRP, then an 
MSRP session needs to be established between them. Lets assume SIP is 
used to do this. (Either B calling the automaton or visa versa.) Lets 
further assume that the purpose of this session is specifically to 
transfer the sequence that was provided by A. Once the session is 
established, the automaton would presumably bind it to the sequence to 
be transmitted.

As long as that sequence of messages is to be transferred to B in a 
single MSRP session, or a series of MSRP sessions tied together with a 
common dialog, then MSRP as it stands is sufficient to get the job done.

The only case where I can see that you might need more is if B wants the

option of connecting to the automaton, collecting *some* of the message 
sequence, fully disconnecting, and then at some later time connecting to

the automaton again and attempting to resume the transfer.

This presumes a lot that is not in scope for MSRP, that has never been 
mentioned as a requirement, and has not been discussed at all. It may or

may not come into scope at some time in the future. Attempting to 
introduce features into the protocol that might help this is IMO unwise 
without having done all the necessary homework. It is also not something

that anyone here would want to delay the completion of MSRP for.

If this is of interest to you, I suggest you start developing a set of 
requirements for MSRP store-and-forward support.

	Paul

Ignacio Más Ivars (KI/EAB) wrote:
> Yes, I completely agree that you need some kind of IM-automaton that
acts as middle-storage point. What I was feeling is that by specyfing
that a message ID needs to be unique in the context of the MSRP session
we are complicating extremely the possible adition of such an entity,
since there will be no way to link a particular message ID to a
particular MSRP session. Perhaps it's just overshooting but I think that
it introduces some degree of amibuity that could be good to solve...
> 
> Cheers!
> /Ignacio
> 
> -----Original Message-----
> From: Paul Kyzivat
> To: Hisham Khartabil
> Cc: Ignacio Más Ivars (KI/EAB); Simple WG
> Sent: 3/23/2005 4:11 PM
> Subject: Re: [Simple] "draft-ietf-simple-message-sessions-10.txt:
Message ID	and store and forward scenarios
> 
> 
> 
> Hisham Khartabil wrote:
> 
>>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?).
> 
> 
> 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
> 

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