On Thu Mar 5 17:16:44 2009, Curtis King wrote:
On 5-Mar-09, at 8:41 AM, Mickael Remond wrote:
So, you have to build another routing table at the implementation
level.
I have been given many reason why the sm-id was something sufficent
enough, but no reason explaining why requiring the full JID to
resume a
session was a bad design decision.
resource conflict, using just the full jid would not handle this
situation. You need something else to make sure you are resuming
the correct session for the correct client. So, the id needs to-be
something opaque and non-deterministic to the client.
XEP-0198 can restore a session after the server has noticed the TCP
session down, in principle, in which case the full_jid is unroutable,
and actually available for another session if one gets there first -
it's possible that in some cases, a client might even still want to
know whether its dropped connection at least sent all the messages
when it hits a conflict.
I agree with you, that the server would want to use the full jid in
some way to produce the id, so you could just use the existing
routing tables to find the session.
I'm inclined to agree, but I suspect you'd still need to share state
on what sessions were available by session id, which'd somewhat
obviate the need for including the full jid.
But I'll admit I might be making this more complex than it really
needs to be, and besides which, if the full jid is needed by the
server, it can be encoded in and recovered from the sm-id.
All, we need to-do this is to require a bind first before stream
management. This would add no additional steps for the clients.
Setup would be,
1. Client authenticates.
2. Client Binds.
3. Client starts stream management, gets back sm-id
Could this step be the <session/> we all love to hate? (RFC 3920
section 3, if, like me, you'd forgotten about it). It's the right
place, after all.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
