[Standards] LAST CALL: XEP-0220 (Server Dialback)
Dave Cridland
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:
>
> 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:dave at cridland.net - xmpp:dwd at dave.cridland.net
- 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