Hello, 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. The resource conflict is still handled / enforced on opening new session. And if the session you want to resume has been kicked due to resource conflict, sm-id will not match, so your session resume will not work. > 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. Yes, that's a possible option as well. So do we all agree that either way (using jid on resume or starting stream management after bind), the XEP needs to be modified ? -- Mickaël Rémond http://www.process-one.net/
