mirror of https://github.com/moparisthebest/xeps
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.
182 lines
8.9 KiB
182 lines
8.9 KiB
<?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>Deferred</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 <hostname/> element can be either <domain> or <domain/resource>.</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 &rfc5246;) 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 <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> |
|
<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;, ¬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>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 RFC 6120 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 ®ISTRAR; 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'> |
|
&NSVER; |
|
</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>
|
|
|