No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0225.xml 8.9KB

  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>Component Connections</title>
  10. <abstract>This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers.</abstract>
  12. <number>0225</number>
  13. <status>Deferred</status>
  14. <type>Standards Track</type>
  15. <sig>Standards</sig>
  16. <approver>Council</approver>
  17. <dependencies>
  18. <spec>XMPP Core</spec>
  19. </dependencies>
  20. <supersedes/>
  21. <supersededby/>
  22. <shortname>component</shortname>
  23. &stpeter;
  24. <revision>
  25. <version>0.2</version>
  26. <date>2008-10-06</date>
  27. <initials>psa</initials>
  28. <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>
  29. </revision>
  30. <revision>
  31. <version>0.1</version>
  32. <date>2007-08-08</date>
  33. <initials>psa</initials>
  34. <remark><p>Initial published version.</p></remark>
  35. </revision>
  36. <revision>
  37. <version>0.0.1</version>
  38. <date>2007-07-31</date>
  39. <initials>psa</initials>
  40. <remark><p>First draft.</p></remark>
  41. </revision>
  42. </header>
  43. <section1 topic='Introduction' anchor='intro'>
  44. <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>
  45. <ul>
  46. <li>It does not support Transport Layer Security (TLS; see &rfc5246;) for channel encryption.</li>
  47. <li>It does not support the Simple Authentication and Security Layer (SASL; see &rfc4422;) for authentication.</li>
  48. <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>
  49. <li>It multiplies namespaces beyond necessity, adding the "jabber:component:accept" and "jabber:component:connect" namespaces to "jabber:client" and "jabber:server".</li>
  50. </ul>
  51. <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>
  52. </section1>
  53. <section1 topic='Requirements' anchor='reqs'>
  54. <p>This document addresses the following requirements:</p>
  55. <ol>
  56. <li>Support Transport Layer Security for channel encryption.</li>
  57. <li>Support the Simple Authentication and Security Layer for authentication.</li>
  58. <li>Enable a component to bind multiple hostnames to one stream.</li>
  59. <li>Use one of the existing default namespaces for XML streams between components and servers.</li>
  60. </ol>
  61. </section1>
  62. <section1 topic='Stream Establishment' anchor='stream'>
  63. <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>
  64. <ol>
  65. <li>The 'from' address of the initial stream header SHOULD be the "default" hostname of the component.</li>
  66. <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>
  67. <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>
  68. </ol>
  69. </section1>
  70. <section1 topic='Hostname Binding' anchor='bind'>
  71. <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>
  72. <p>If a server offers component binding over a stream, it MUST advertise a feature of "urn:xmpp:component:0".</p>
  73. <example caption='Stream Feature'><![CDATA[
  74. S: <stream:stream
  75. from=''
  76. id='gPybzaOzBmaADgxKXu9UClbprp0='
  77. to=''
  78. version='1.0'
  79. xml:lang='en'
  80. xmlns='jabber:client'
  81. xmlns:stream=''>
  82. S: <stream:features>
  83. <bind xmlns='urn:xmpp:component:0'>
  84. <required/>
  85. </bind>
  86. </stream:features>
  87. ]]></example>
  88. <p>In order to bind a hostname, the component sends a bind request to the server.</p>
  89. <example caption='Bind Request'><![CDATA[
  90. C: <iq id='bind_1' type='set'>
  91. <bind xmlns='urn:xmpp:component:0'>
  92. <hostname></hostname>
  93. </bind>
  94. </iq>
  95. ]]></example>
  96. <p>If the hostname can be bound, the server MUST return an IQ-result specifying the exact hostname that was bound.</p>
  97. <example caption='Bind Result'><![CDATA[
  98. S: <iq id='bind_1' type='result'>
  99. <bind xmlns='urn:xmpp:component:0'>
  100. <hostname></hostname>
  101. </bind>
  102. </iq>
  103. ]]></example>
  104. <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>
  105. <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>
  106. <p>A component can send a subsequent bind request to bind another hostname (a server MUST support binding of multiple hostnames).</p>
  107. <example caption='Another Bind Request'><![CDATA[
  108. C: <iq id='bind_2' type='set'>
  109. <bind xmlns='urn:xmpp:component:0'>
  110. <hostname></hostname>
  111. </bind>
  112. </iq>
  113. ]]></example>
  114. <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>
  115. <p>A component can also unbind a resource that has already been bound (a server MUST support unbinding).</p>
  116. <example caption='Unbind Request'><![CDATA[
  117. C: <iq id='unbind_1' type='set'>
  118. <unbind xmlns='urn:xmpp:component:0'>
  119. <hostname></hostname>
  120. </unbind>
  121. </iq>
  122. ]]></example>
  123. <p>If the hostname can be unbound, the server MUST return an IQ-result.</p>
  124. <example caption='Unbind Result'><![CDATA[
  125. S: <iq id='unbind_1' type='result'/>
  126. ]]></example>
  127. </section1>
  128. <section1 topic='Security Considerations' anchor='security'>
  129. <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>
  130. </section1>
  131. <section1 topic='IANA Considerations' anchor='iana'>
  132. <p>This document requires no interaction with &IANA;.</p>
  133. </section1>
  134. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  135. <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
  136. <p>This specification defines the following XML namespace:</p>
  137. <ul>
  138. <li>urn:xmpp:component:0</li>
  139. </ul>
  140. <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>
  141. </section2>
  142. <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
  143. &NSVER;
  144. </section2>
  145. </section1>
  146. <section1 topic='XML Schema' anchor='schema'>
  147. <code><![CDATA[
  148. <?xml version='1.0' encoding='UTF-8'?>
  149. <xs:schema
  150. xmlns:xs=''
  151. targetNamespace='urn:xmpp:component:0'
  152. xmlns='urn:xmpp:component:0'
  153. elementFormDefault='qualified'>
  154. <xs:element name='bind'>
  155. <xs:complexType>
  156. <xs:sequence>
  157. <xs:choice minOccurs='0' maxOccurs='1'>
  158. <xs:element name='hostname' type='xs:string'/>
  159. </xs:choice>
  160. <xs:element name='required'
  161. minOccurs='0'
  162. maxOccurs='1'
  163. type='empty'/>
  164. </xs:sequence>
  165. </xs:complexType>
  166. </xs:element>
  167. <xs:element name='unbind'>
  168. <xs:complexType>
  169. <xs:sequence minOccurs='0'>
  170. <xs:element name='hostname' type='xs:string'/>
  171. </xs:sequence>
  172. </xs:complexType>
  173. </xs:element>
  174. </xs:schema>
  175. ]]></code>
  176. </section1>
  177. </xep>