[Standards] LAST CALL: XEP-0220 (Server Dialback)
dave at cridland.net
Wed Nov 12 08:12:51 CST 2008
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:
> <dialback xmlns='urn:xmpp:features:dialback'>
> <multiplex xmlns='urn:xmpp:features:multiplex'>
> 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).
1) Do any server implementations actually do piggybacking anymore?
2) Do any server implementations reject piggybacking attempts, as per
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards