On 2/25/09 8:55 AM, Pavel Simerda wrote: > On Tue, 24 Feb 2009 20:14:27 +0100 > Philipp Hancke <fi...@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.
That's the general idea, yes. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
