[Standards] Binary data over XMPP

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Thu Nov 8 19:11:03 UTC 2007

On Thursday 08 November 2007 1:26 am, Fabio Forno wrote:
> On Nov 8, 2007 9:52 AM, Tomasz Sterna <tomek at xiaoka.com> wrote:
> > Dnia 08-11-2007, Cz o godzinie 00:29 +0100, Fabio Forno pisze:
> > > One of the reasons I tend to use id bosh is the ability of keeping the
> > >  session open when the client temporary disconnects
> >
> > XEP-0198: Stanza Acknowledgements already supports session recovery
> > after disconnection with <reconnect/> element.
> > It also ensures, that no packets get lost with the connection failure.
> Too many xeps, sometime sou get lost ;) Yep it seems to work also for
> tcp connections, there is a thing I cant understand: when the
> initiating entity tries to recover from a packet of a previouos
> session, how do the server choses the correct session if the <bind/>
> of the resources and stanzas acks are offered together? I mean: in the
> unlucky case of an entity having two open sessions and losing both of
> them, how can the server decide which is the session to recover, but
> adding some semantics to the ids?

When you connect again, you specify the ack session id of the disconnected 
connection, so that the server knows which session you are trying to recover.

According to the XEP, you then would do resource binding.  At the very least, 
the XEP should be updated to state that the client must bind to the same 
resource as before, and if it doesn't then the server must assert the correct 
resource in the bind iq reply.  However, I'm tempted to say that when you 
resume an ack session, the resource binding step should just be skipped.  
After all, both parties already know what the resource is supposed to be.


More information about the Standards mailing list