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.
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.
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
4. Client gets roster, sends presence, etc.
Session drops..
Resume would be,
1. Client authenticates.
2. Client starts stream management by resuming using sm-id.
If a client can't get to step 3 in the setup then it's not losing
anything if the session drops. I'm assuming a client always needs to
authenticate.
ck
