Thanks, this is really useful.
On Wed Nov 12 11:56:57 2008, Pedro Melo wrote:
3. Section 3, Reuse of Connections (piggybacking)
1. Cosmetic: maybe we should start using the term multiplexing;
I think changing it now would be more confusing than not changing it.
2. The second paragraph limits the piggyback connections to sub-
domains of the initial negotiated domain.
I don't see any security reason for this. You can allow any domain
to be multiplexed on an already existing connection, provided that
the dialback verification process is successful. This would allow
services with large number of domains to reuse S2S connections
much easily.
Interesting - I don't read that as limiting reuse to that case, I
read it as saying that's merely a typical reason. Indeed, Google used
to do this kind of piggybacking, and as I recall, it couldn't cope
with piggybacking being refused.
3. Support for multiplex connections
Going forward, it would be cleaner if the Recv Server announces
support for multiplexed connections in the initial stream features.
Something like:
R2O:
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<required/>
</dialback>
<multiplex xmlns='urn:xmpp:features:multiplex'>
<optional/>
</multiplex>
</stream:features>
This clearly announces support for the feature and would precent
try- and-miss attempts on future servers.
Well, going forward, I'm hoping we'll remove the need for dialback at
all. I'd like to hope it remains purely as a stub protocol for
connection reuse, and that db:verify simply disappears in a puff of
certificate equality checking. (Which it could do, I think).
Two questions:
1) Do any server implementations actually do piggybacking anymore?
2) Do any server implementations reject piggybacking attempts, as per
Example 45?
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
