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.
philipp
