<remark><p>Modified namespace to incorporate namespace versioning; clarified that the value of the <hostname/> element can be either <domain> or <domain/resource>.</p></remark>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-07-31</date>
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0114; defines a protocol that enables a server component to connect to an XMPP server. However, there are a number of perceived limitations with that protocol:</p>
<li>It does not support the Simple Authentication and Security Layer (SASL; see &rfc4422;) for authentication.</li>
<li>It does not enable a component to bind multiple hostnames to one stream (as, for example, a client can bind multiple resource identifiers).</li>
<li>It multiplies namespaces beyond necessity, adding the "jabber:component:accept" and "jabber:component:connect" namespaces to "jabber:client" and "jabber:server".</li>
</ul>
<p>This document specifies a standards-track protocol that addresses the basic requirements for component connections. In the future, additional documents may specify more advanced features on top of the protocol defined herein.</p>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p>This document addresses the following requirements:</p>
<ol>
<li>Support Transport Layer Security for channel encryption.</li>
<li>Support the Simple Authentication and Security Layer for authentication.</li>
<li>Enable a component to bind multiple hostnames to one stream.</li>
<li>Use one of the existing default namespaces for XML streams between components and servers.</li>
<p>XML streams are established between a component and a server exactly as they are between a client and a server as specified in &xmppcore;, with the following exceptions:</p>
<ol>
<li>The 'from' address of the initial stream header SHOULD be the "default" hostname of the component.</li>
<li>The JID asserted by the end entity (in this case a component) during STARTTLS negotiation and SASL negotiation MUST be of the form <domain> in conformance with the definition of a domain identifier from XMPP Core.</li>
<li>If a "simple user name" is included in accordance with the chosen SASL mechanism, it MUST be of the form <domain> in conformance with the definition of a domain identifier from XMPP Core.</li>
</ol>
</section1>
<section1topic='Hostname Binding'anchor='bind'>
<p>The protocol defined in <cite>XEP-0114</cite> depended on use of the 'to' address in the stream header to specify the hostname of the component. By contrast, client-to-server connections use stream establishment is followed by binding of a resource to the stream (in fact multiple resources can be bound to the stream). This protocol emulates client-to-server connections by using a hostname binding process that is similar to the resource binding process specified in XMPP Core.</p>
<p>If the hostname cannot be bound, the server MUST return an IQ-error, which SHOULD be &badrequest;, &conflict;, ¬allowed;, or &constraint;, just as with client resource binding as specified in <cite>RFC 3920</cite>.</p>
<p>Note: Although the JID asserted during STARTTLS and SASL negotiation MUST be of the form <domain> (i.e., an XMPP domain identifier), the <hostname/> element MAY be of the form <domain/resource>. This form can be used for application-specific functionality (e.g., load balancing), but such functionality is out of scope for this specification.</p>
<p>If the server cannot process the bind request (e.g., because the component has already bound the desired hostname), the server MUST return an IQ-error (e.g., &conflict;).</p>
<p>A component can also unbind a resource that has already been bound (a server MUST support unbinding).</p>
<p>This protocol improves upon the earlier component protocol defined in <cite>XEP-0114</cite> by specifying the use of Transport Layer Security (TLS) for channel encryption and the Simple Authentication and Security Layer (SASL) for authentication. Because this protocol re-uses the XML stream establishment processes defined in XMPP Core, the security considerations from RFC 3920 and RFC 6120 apply to this protocol as well.</p>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:component:0</li>
</ul>
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>