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
it.
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.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
