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

From: Ben Campbell <[email-masked]>
Date: Sun, 3 Apr 2005 16:00:29 -0500

Sorry for coming late to this thead, but I have been thinking about 
this a bit for a while. I have come to the conclusion that this sort of 
requirement should not be solved with MSRP.

Specifically, if you have a store-and-forward server for MSRP, from the 
perspective of the MSRP session, that server is the destination 
endpoint. You can think of this like a voice mail server, except for 
text and other sorts of content. It is MSRP's job to get the message to 
that endpoint, and no further. If we want some sort of notification of 
what happens after the message is delivered to the endpoint, that needs 
to happen though some other mechanism.

The reasoning becomes more apparent if you consider that the method of 
delivery from the store-and-forward server to the final destination may 
well be something other than MSRP, and  such delivery is likely to 
happen well after the originating session has ended.

On Mar 25, 2005, at 10:22 AM, Ignacio Más Ivars (KI/EAB) wrote:

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

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