[Standards] various rfc3920bis feedback

Philipp Hancke fippo at goodadvice.pages.de
Tue Feb 24 19:14:27 UTC 2009

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

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

Now what happens should I attempt to piggyback the users.jabber.org
connection on the jabber.org connection? jabber.org kills my stream.


More information about the Standards mailing list