From 6684521d7f7585a5c1f56a2e3ddfa0173502342e Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 16 May 2007 22:39:47 +0000 Subject: [PATCH] initial version git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@844 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0215.xml | 208 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 xep-0215.xml diff --git a/xep-0215.xml b/xep-0215.xml new file mode 100644 index 00000000..16ab3ece --- /dev/null +++ b/xep-0215.xml @@ -0,0 +1,208 @@ + + +%ents; +]> + + +
+ STUN Server Discovery for Jingle + This document specifies methods for discovering STUN servers for use in negotiation of certain Jingle transport methods. + &LEGALNOTICE; + 0215 + Experimental + Standards Track + Standards + Council + + XMPP Core + + + + NOT YET ASSIGNED + &stpeter; + &seanegan; + + 0.1 + 2007-05-16 + psa +

Initial published version.

+
+ + 0.0.5 + 2007-05-10 + psa +

Added attributes for username and password; reverted to IQ method since credentials are individualized.

+
+ + 0.0.4 + 2007-04-18 + psa +

Modified to use a well-known publish-subscribe node instead of a dedicated IQ exchange.

+
+ + 0.0.3 + 2007-03-30 + psa +

Made port mandatory since spec assumes that SRV is not available; added XML schema.

+
+ + 0.0.2 + 2007-03-27 + psa +

Made port optional.

+
+ + 0.0.1 + 2007-03-23 + psa/se +

First draft.

+
+
+ + +

The administrator of an XMPP server may wish to deploy one or more STUN servers (see &rfc3489; and &rfc3489bis;) in order to ease the process of negotiating media exchanges via &xep0176;. A client can become aware of a STUN server in the following ways:

+
    +
  1. The server is specified in the default settings for the client.
  2. +
  3. The server is manually added by a human user into the client's configuration.
  4. +
  5. The server is discovered via DNS SRV records as specified in Section 9.1 of RFC 3489.
  6. +
+

Unfortunately, the foregoing methods are subject to human error or cannot be deployed in wide range of scenarios. Therefore, this document defines a way for an XMPP server to advertise a list of STUN servers and provide credentials for use by an XMPP client at a STUN server. This method SHOULD be used only as a fallback when DNS SRV lookups are not possible for the client or server.

+

Note: The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service and documented at <http://code.google.com/apis/talk/jep_extensions/jingleinfo.html>.

+
+ + +

In order to learn about available STUN servers associated with or known by an XMPP server, a client sends an IQ-get containing a <stun/> element qualified by the "http://www.xmpp.org/extensions/xep-0215.html#ns" namespace &NSNOTE;.

+

An example of the payload format for this node is as follows:

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

(Naturally, the XMPP MAY instead return an appropriate error, such as &unavailable; if the server does not support the STUN Server Discovery protocol or &forbidden; if the requesting entity does not have permission to receive the server list.)

+

The 'host' attribute is REQUIRED and specifies either a fully qualified domain name (FQDN) or an IP address (IPv4 or IPv6). The 'port' attribute is REQUIRED and specifies the communications port to be used at the host. The port is necessary since this specification assumes that DNS SRV lookups are not possible.

+

A STUN server may require a username and password in order to accept STUN binding requests and/or STUN allocate requests. In this case, the XMPP server would typically generate a short-term authentication credential based on a private key shared with the STUN server (naturally, other implementations are possible, and long-term credentials could be used instead; see RFC 3489 and rfc3489bis for details).

+ + + + + + + ]]> +

The 'username' and 'password' attributes are OPTIONAL.

+

An XMPP server MAY send an updated list of STUN servers by "pushing" the list to a client that has previously requested the list:

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

If an entity supports the STUN Server Discovery protocol, it MUST report that fact by including a service discovery feature of "http://www.xmpp.org/extensions/xep-0215.html#ns" &NSNOTE; in response to a &xep0030; information request:

+ + + + ]]> + + + ... + + ... + + + ]]> +
+ + + +

Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0215.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;.

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