[Standards] various rfc3920bis feedback

Pavel Simerda pavlix at pavlix.net
Wed Feb 25 15:55:56 UTC 2009

On Tue, 24 Feb 2009 20:14:27 +0100
Philipp Hancke <fippo at goodadvice.pages.de> wrote:

> Pavel Simerda wrote:
> >>>> * connection reuse for multiple s2s links would be a very useful
> >>>>   feature, ask Dave for details
> >>> Piggybacking.
> >> Which is subtly broken in RFC 3920 - at least 50% of it.
> >> <host-unknown/> makes 'target piggybacking' (different to)
> >> unusable, as you risk the entire stream.
> > 
> > Please provide more specific info about how to fix it in bis 
> I fixed in in my working copy of 220 by completly getting rid of
> host-unknown for dialback. type='error' seems a good fix.
>  > and if/why it is broken now.
> The relevant passage from 3920 about piggybacking is:
> "After successful dialback negotiation, the Receiving Server SHOULD
>   accept subsequent <db:result/> packets (e.g., validation requests
> sent to a subdomain or other hostname serviced by the Receiving
> Server) from the Originating Server over the existing validated
> connection; this enables "piggybacking" of the original validated
> connection in one direction."
> If the receiving server is 'jabber.org', "validation requests sent
>   to a subdomain or other hostname serviced by the Receiving Server"
> means that I can piggyback stanzas to 'users.jabber.org' on that
> connection (target piggybacking, google uses source piggybacking).
> draft-saintandre-rfc3920bis-08.html added the host-unknown stream
> error to dialback with the following description:
> the value of the 'to' attribute provided by the initiating entity in
> the stream header does not correspond to a hostname that is hosted by
> the ^^^^^^^^^^^^^
> server.
> Now what happens should I attempt to piggyback the users.jabber.org
> connection on the jabber.org connection? jabber.org kills my stream.

As I said to Peter....

IMO the whole idea of piggybacking is misguided. Piggybacking means
re-using a connection A for data that would otherwise come in B.

It would be better to think about it as a generic multiplex. Then all
virtual connections would be equal (A and B, specifically). One would
immediately see the consequences of closing the physical connection
(that should only be closed if all virtual connections are closed).

Keeping this as an optional feature (I believe that is a near consensus)
will further simplify the most basic implementations.

> philipp


Freelance consultant and trainer
in networking, communications and security.

Web: http://www.pavlix.net/
Jabber, Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Standards mailing list