xeps/xep-0225.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Component Connections</title>
  <abstract>This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers.</abstract>
  &LEGALNOTICE;
  <number>0225</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>component</shortname>
  &stpeter;
  <revision>
    <version>0.2</version>
    <date>2008-10-06</date>
    <initials>psa</initials>
    <remark><p>Modified namespace to incorporate namespace versioning; clarified that the value of the &lt;hostname/&gt; element can be either &lt;domain&gt; or &lt;domain/resource&gt;.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2007-08-08</date>
    <initials>psa</initials>
    <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>
<section1 topic='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>
  <ul>
    <li>It does not support Transport Layer Security (TLS; see &rfc4346;) for channel encryption.</li>
    <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>
<section1 topic='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>
  </ol>
</section1>
<section1 topic='Stream Establishment' anchor='stream'>
  <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 &lt;domain&gt; 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 &lt;domain&gt; in conformance with the definition of a domain identifier from XMPP Core.</li>
  </ol> 
</section1>
<section1 topic='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 a server offers component binding over a stream, it MUST advertise a feature of "urn:xmpp:component:0".</p>
  <example caption='Stream Feature'><![CDATA[
S: <stream:stream
       from='example.com'
       id='gPybzaOzBmaADgxKXu9UClbprp0='
       to='chat.example.com'
       version='1.0'
       xml:lang='en'
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'>

S: <stream:features>
     <bind xmlns='urn:xmpp:component:0'>
       <required/>
     </bind>
   </stream:features>
  ]]></example>
  <p>In order to bind a hostname, the component sends a bind request to the server.</p>
  <example caption='Bind Request'><![CDATA[
C: <iq id='bind_1' type='set'>
     <bind xmlns='urn:xmpp:component:0'>
       <hostname>chat.example.com</hostname>
     </bind>
   </iq>
  ]]></example>
  <p>If the hostname can be bound, the server MUST return an IQ-result specifying the exact hostname that was bound.</p>
  <example caption='Bind Result'><![CDATA[
S: <iq id='bind_1' type='result'>
     <bind xmlns='urn:xmpp:component:0'>
       <hostname>chat.example.com</hostname>
     </bind>
   </iq>
  ]]></example>
  <p>If the hostname cannot be bound, the server MUST return an IQ-error, which SHOULD be &badrequest;, &conflict;, &notallowed;, 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 &lt;domain&gt; (i.e., an XMPP domain identifier), the &lt;hostname/&gt; element MAY be of the form &lt;domain/resource&gt;. 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>A component can send a subsequent bind request to bind another hostname (a server MUST support binding of multiple hostnames).</p>
  <example caption='Another Bind Request'><![CDATA[
C: <iq id='bind_2' type='set'>
     <bind xmlns='urn:xmpp:component:0'>
       <hostname>foo.example.com</hostname>
     </bind>
   </iq>
  ]]></example>
  <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>
  <example caption='Unbind Request'><![CDATA[
C: <iq id='unbind_1' type='set'>
     <unbind xmlns='urn:xmpp:component:0'>
       <hostname>foo.example.com</hostname>
     </unbind>
   </iq>
  ]]></example>
  <p>If the hostname can be unbound, the server MUST return an IQ-result.</p>
  <example caption='Unbind Result'><![CDATA[
S: <iq id='unbind_1' type='result'/>
  ]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <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 rfc3920bis apply to this protocol as well.</p> 
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
    <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 &REGISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
  </section2>
  <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
    <p>If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of <cite>XEP-0053</cite>.</p>
  </section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
  <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:component:0'
    xmlns='urn:xmpp:component:0'
    elementFormDefault='qualified'>

  <xs:element name='bind'>
    <xs:complexType>
      <xs:sequence>
        <xs:choice minOccurs='0' maxOccurs='1'>
          <xs:element name='hostname' type='xs:string'/>
        </xs:choice>
        <xs:element name='required'
                    minOccurs='0'
                    maxOccurs='1'
                    type='empty'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='unbind'>
    <xs:complexType>
      <xs:sequence minOccurs='0'>
        <xs:element name='hostname' type='xs:string'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

</xs:schema>
  ]]></code>
</section1>
</xep>