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.
Not evil, just misunderstood. :-)
For really tight optimisation, I expect the trickiest part will be
dealing
with the stream restart after SASL negotiation, especially when
there is a
failure. The simplest solution is to require a round trip at that
point.
Otherwise you'd have to introduce a new error response to deal
gracefully
with what looks to the server like an attempt to nest streams after
a SASL
failure, when the client expected a stream restart after a SASL
success.
Or you simply tell clients they MUST NOT attempt pipelining without
reasonable grounds for knowing the authentication will succeed.
I think my nefarious use of EXTERNAL+TLS session resume essentially
requires a round-trip before, whereas PLAIN would need a previous
authentication success, and DIGEST-MD5 fast-reauth would need a
round-trip during.
Resource binding is interesting because either end can choose the
resource. It's much easier to pipeline if the client specifies it,
since
that means it doesn't have to wait for information from the server.
How
common is it for clients to let servers choose their resource?
Latency-sensitive clients should be encouraged not to.
There's also the odd case where a client attempts to use a
pre-existing resource and conflicts, or where the client specifies
the resource but the server overrides.
These sorts of things are policy/implementation issues, though - I
think we could have a child element or two of the bind feature that
will allow clients to know, a priori, what to expect.
The pipelined session above is 4 round trips, compared to 8 in
3920bis
section 10. It could be reduced to 3 with a TLS session cache. If
you are
willing to specify some stunt buffer handling then it is possible
to shift
the TLS hello into the client's first packet and save another round
trip.
However this requires some really quite tricky juggling of the XML
and TLS
layering which might not even be possible on many platforms.
Stunt buffering - and that's a great term - is not always easy,
especially with XML processing. A lot of XMPP implementations handle
the XML streams by pushing buffers directly into the XML parser, and
unless the XML parser tells the application exactly where each
element ends, things are going to get unpleasant.
It's also tricky because many TLS implementations either explicitly
must use the socket directly, or are very much easiest in that mode.
(Example: OpenSSL is a lot easier to use with sockets, and many
bindings only support this mode. I added buffering support to my fork
of PyOpenSSL, so it's possible to do stunt buffering in Python, at
least, but this probably won't help the average mobile handset).
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
