[Standards] mobile optimizations (was: Re: Google Andro?d SDK not XMPP compliant ?)
dave at cridland.net
Mon Feb 18 11:47:10 UTC 2008
On Fri Feb 15 20:16:32 2008, Tony Finch wrote:
> (1) In XMPP the client speaks first. This is a win for XMPP
> compared to
> SMTP, since it allows the client to piggyback useful information in
> first data-carrying packet of the TCP connection. SMTP requires
> evil hacks
> to persuade paranoid servers not to reject clients that want to
> earlier than is traditional.
They weren't evil, just misunsderstood.
> (3) XMPP has resource binding, which is a lose compared to SMTP -
> an extra
> round trip. More about this below.
If you know the outcome of a bind a priori, then you can optimize for
it - so if a server tells you that certain bind requests will always
work, then you can safely pipeline it.
The same is true for <starttls/> - there's little reason for this to
fail in the real world. The only two cases I can think of are when
TLS has simply been misconfigured, and is unavailable to the server -
this is trivial to handle properly - and when TLS is configured
correctly, but in such a configuration that the client cannot handle
This latter case covers things like when a server has no certificate,
but wants to use ADH, whereas the client (as is typical) refuses to
The good news is that both bind and starttls steps are usually a
matter of policy and configuration - they'll rarely change between
stream setups, so it's reasonable to cache advertised or discovered
server behaviour. (Discovered for TLS, advertised for bind, so we
need a new child element of the bind feature for this).
As an aside, I really like the term "stunt buffering".
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards