[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 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