On 2/24/09 12:14 PM, Philipp Hancke 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.
Really? Why? Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
