XEP-0225: Component Connections

This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers.

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

Document Information

Series: XEP
Number: 0225
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2007-08-08
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED
Wiki Page: <http://wiki.jabber.org/index.php/Component Connections (XEP-0225)>

Author Information

Legal Notices

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

Errata may be sent to <editor@xmpp.org>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents

1. Introduction

Jabber Component Protocol [1] 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:

• It does not support Transport Layer Security (TLS; see RFC 4346 [2]) for channel encryption.
• It does not support the Simple Authentication and Security Layer (SASL; see RFC 4422 [3]) for authentication.
• It does not enable a component to bind multiple hostnames to one stream (as, for example, a client can bind multiple resource identifiers).
• It multiplies namespaces beyond necessity, adding the "jabber:component:accept" and "jabber:component:connect" namespaces to "jabber:client" and "jabber:server".

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.

2. Requirements

This document addresses the following requirements:

1. Support Transport Layer Security for channel encryption.
2. Support the Simple Authentication and Security Layer for authentication.
3. Enable a component to bind multiple hostnames to one stream.
4. Use one of the existing default namespaces for XML streams between components and servers.

3. Stream Establishment

XML streams are established between a component and a server exactly as they are between a client and a server as specified in XMPP Core [4], with the following exceptions:

1. The 'from' address of the initial stream header SHOULD be the "default" hostname of the component.
2. 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.
3. 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.

4. Hostname Binding

The protocol defined in XEP-0114 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.

If a server offers component binding over a stream, it MUST advertise a feature of "urn:xmpp:tmp:component".

Example 1. Stream Feature

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:tmp:component'>
       <required/>
     </bind>
   </stream:features>
  

In order to bind a hostname, the component sends a bind request to the server.

Example 2. Bind Request

C: <iq id='bind_1' type='set'>
     <bind xmlns='urn:xmpp:tmp:component'>
       <hostname>chat.example.com</hostname>
     </bind>
   </iq>
  

If the hostname can be bound, the server MUST return an IQ-result.

Example 3. Bind Result

S: <iq id='bind_1' type='result'/>
  

A component can send a subsequent bind request to bind another hostname (a server MUST support binding of multiple hostnames).

Example 4. Another Bind Request

C: <iq id='bind_2' type='set'>
     <bind xmlns='urn:xmpp:tmp:component'>
       <hostname>foo.example.com</hostname>
     </bind>
   </iq>
  

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/>).

A component can also unbind a resource that has already been bound (a server MUST support unbinding).

Example 5. Unbind Request

C: <iq id='unbind_1' type='set'>
     <unbind xmlns='urn:xmpp:tmp:component'>
       <hostname>foo.example.com</hostname>
     </unbind>
   </iq>
  

If the hostname can be unbound, the server MUST return an IQ-result.

Example 6. Unbind Result

S: <iq id='unbind_1' type='result'/>
  

5. Examples

Further examples to follow.

6. Security Considerations

This protocol improves upon the earlier component protocol defined in XEP-0114 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.

7. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [5].

8. XMPP Registrar Considerations

9. XML Schema

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:xmpp:tmp:component'
    xmlns='urn:xmpp:tmp:component'
    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>
  

Notes

Revision History

END