[Standards] Proposed XMPP Extension: Bind 2.0

Kevin Smith kevin.smith at isode.com
Wed Jan 25 10:32:41 UTC 2017

On 23 Jan 2017, at 15:38, Georg Lukas <georg at op-co.de> wrote:
> * XMPP Extensions Editor <editor at xmpp.org> [2017-01-17 16:24]:
>> Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup.
> I know this is a bold request, but as a client developer, I wish for the
> following from bind2:
> 1. Client performs authentication (outside of bind2 focus)
> 2. Client sends a bind2 element with the following optional payloads:
>   - last received MAM-ID,
>   - last-used-resource
>   - last SM session-ID + h
> 3. Server performs magic:
> - if the SM session is valid, perform a SM resume, otherwise:

That seems like it might be interesting.

> - kill the old server-side session identified by last-used-resource

That seems potentially useful.

> - bind a new session, using last-used-resource or a uuid
> - enable SM + resumption
> - start sending MAM messages to the client starting after last received MAM-ID

This one I’m not convinced by. You’re going to need to deal with multiple roundtrips for doing a full MAM sync on login anyway, because the server likely won’t return all results in a single query, and I’m not sold that doing a full sync before the client is responsive is necessarily sensible.

> This approach would have multiple benefits:
> * Less roundtrips (when <resume> would fail; for MAM response)

The MAM response doesn’t actually need to be a roundtrip for the first results, even without this, because you can issue a query in the same write.

> * Smarter server, dumber client (original XMPP design goal)
> * One-step creation/restore of a properly configured session

Merging resumption seems potentially useful, yes.

> Regarding the random vs. client-supplied resource, I'm strongly in favor
> of having the client generate a random resource like "yaxim.DEADBEAF" on
> first use. This makes debugging problems easier for server operators,
> and I can say from experience that running a server is hard enough
> already.

Being able to tie a unique identifier to a client for server debugging is useful, but I don’t think it’s the job of the resource to encode it.


More information about the Standards mailing list