<abstract>This specification defines a protocol for using server-to-server connections in a bidirectional way such that stanzas are sent and received on the same TCP connection.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0178</spec>
<spec>XEP-0220</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<author>
<firstname>Philipp</firstname>
<surname>Hancke</surname>
<jid>fippo@ve.symlynx.com</jid>
</author>
<author>
<firstname>Dave</firstname>
<surname>Cridland</surname>
<email>dave.cridland@isode.com</email>
<jid>dave.cridland@isode.com</jid>
</author>
<revision>
<version>0.0.2</version>
<date>2010-09-13</date>
<initials>dwd</initials>
<remark>
<p>belated run-over pre-publication</p>
<p>Added notes on authentication</p>
</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2010-04-12</date>
<initials>ph</initials>
<remark><p>initial version</p></remark>
</revision>
</header>
<section1topic='Introduction'>
<p>&rfc3920; restricts server-to-server communication in such a way that a server has to use on TCP connection for XML stanzas sent from the server to the peer and another TCP connection (initiated by the peer) for stanzas from the peer to the server, for a total of two TCP connections. &rfc3920bis; allows two servers to send stanzas in a bidirectional way, but does not define methods for explicitly signalling the usage thereof. This is accomplished in this specification.</p>
<p>If a server supports bidirectional server-to-server streams, it should inform the connecting entity when returning stream features during the stream negotiation process (both before and after TLS negotiation). This is done by including a <bidi/> element qualified by the 'urn:xmpp:features:bidi' namespace.</p>
<p>If the initiating entity chooses to use TLS, STARTTLS negotiation MUST be completed before enabling bidirectionality.</p>
</section2>
<section2topic='Negotiation'anchor='nego'>
<p>To enable bidirectional communication, the connecting server sends a <bidi/> element qualified by the 'urn:xmpp:bidi' namespace. This SHOULD be done before either SASL negotiation or &xep0220;.</p>
<examplecaption="Connecting Server Requests Bidirectionality"><![CDATA[
C: <bidixmlns='urn:xmpp:bidi'/>
]]></example>
<p>Note: Since there is no reply to the request, it is possible to pipeline it.</p>
<p>After enabling bidirectionality, the connecting server continues to authenticate via SASL or requests to send stanzas for a domain pair with Server Dialback. The receiving server MUST NOT send stanzas to the peer before it has authenticated via SASL, or the peer's identity has been verified via Server Dialback. Note that the receiving server MUST NOT attempt to verify a dialback key on the same connection where the corresponding request was issued.</p>
<p>Also note that the receiving server MUST only send stanzas for which it has been authenticated - in the case of TLS/SASL based authentication, this is the value of the stream's 'to' attribute, whereas in the case of &xep0220; this is the value of the 'to' attribute on any <db:result> element.</p>
<p>Finally, once bidirectionality is enabled, the receiving server MAY initiate &xep0220; authentications for other domains it hosts to any domain authenticated to be hosted by the connecting server.</p>
</section2>
</section1>
<section1topic='Examples'anchor='examples'>
<p>This section shows two complete examples of bidirectional streams, the first example uses SASL EXTERNAL, the second uses Server Dialback. </p>
<examplecaption='Bidirectional Streams with SASL Authentication'><