[Standards] mobile optimizations (was: Re: Google Andro?d SDK not XMPP compliant ?)

Dave Cridland 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  
> the
> first data-carrying packet of the TCP connection. SMTP requires  
> evil hacks
> to persuade paranoid servers not to reject clients that want to  
> speak
> 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  
use it.

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
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list