From 1d3f4adda6c1bfa23df6e2bef391ca494066373c Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 8 Aug 2007 20:39:21 +0000 Subject: [PATCH] initial version git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1125 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0225.xml | 166 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 166 insertions(+) create mode 100644 xep-0225.xml diff --git a/xep-0225.xml b/xep-0225.xml new file mode 100644 index 00000000..8287b73d --- /dev/null +++ b/xep-0225.xml @@ -0,0 +1,166 @@ + + +%ents; +]> + + +
+ Component Connections + This document specifies a standards-track XMPP protocol extension that enables server components to connect to XMPP servers. + &LEGALNOTICE; + 0225 + Experimental + Standards Track + Standards + Council + + XMPP Core + + + + NOT YET ASSIGNED + &stpeter; + + 0.1 + 2007-08-08 + psa +

Initial published version.

 + + + 0.0.1 + 2007-07-31 + psa +

First draft.

 + +
+ +

&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:

+
    +
  • It does not support Transport Layer Security (TLS; see &rfc4346;) for channel encryption.
    • +
  • It does not support the Simple Authentication and Security Layer (SASL; see &rfc4422;) 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.

+ + +

This document addresses the following requirements:

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

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:

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

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 "http://www.xmpp.org/extensions/xep-xxxx.html#ns".

+ + +S: + + + + + ]]> +

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

+ + + chat.example.com + + + ]]> +

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

+ + ]]> +

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

+ + + foo.example.com + + + ]]> +

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

+ + + foo.example.com + + + ]]> +

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

+ + ]]> + + +

Further examples to follow.

+ + +

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.

+ + +

This document requires no interaction with &IANA;.

+ + + +

Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-xxxx.html#ns"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + ]]> + +