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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple