An XMPP client may need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc3489; and &rfc3489bis;) and STUN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at <http://code.google.com/apis/talk/jep_extensions/jingleinfo.html>, but has been broadened in scope to address additional use cases if desired. An XMPP client can already discover such external services in several ways, including:

1. The service is specified in the client's default settings.
2. The service is manually added into the client's configuration by a human user.
3. The service is discovered via non-XMPP service discovery protocols, such as:
   • DNS SRV records (&rfc2782;)
   • Service Location Protocol (SLP; &rfc2608;)
   • The Dynamic Delegation Discovery System (DDDS; &rfc3401;)
   • The NAPTR profile of DDDS (&rfc3403;)
   • The S-NAPTR profile of DDDS (&rfc3958;)
   • The U-NAPTR profile of DDDS (&rfc4848;)

Unfortunately, some of the foregoing methods are subject to human error and others are either not widely available or cannot be deployed in wide range of scenarios (e.g., when the administrators of an XMPP service do not have access to DNS SRV records). Therefore, this document defines a way for an XMPP server to provide information about external services, which may include extended information such as temporary credentials for authentication at such services. This method should be used only as a fallback when the relevant service discovery technologies (DNS SRV, DDDS, SLP, S-NAPTR, U-NAPTR, etc.) are not available to the client or server. This method does not use &xep0030; since that technology is designed for discovery of XMPP entities, not entities outside an XMPP network.

In order to learn about external services known to an XMPP server, a client sends an IQ-get containing an empty <services/> element qualified by the 'http://www.xmpp.org/extensions/xep-0215.html#ns' namespace &NSNOTE;, typically to its own server (but perhaps to a dedicated discovery service).

The XMPP server (or service) SHOULD return the list of external services it is aware of, but MAY instead return an appropriate error, such as &unavailable; if the server does not support this protocol or &forbidden; if the requesting entity does not have permission to receive the list of external services. Each service is encapsulated via a <service/> element.

Note: The processes by which an XMPP server discovers external services for "proxying" to XMPP entities are out of scope for this specification.

The <service/> element MAY be empty or MAY include extended information about the service as described in the Extended Information section of this document.

The attributes of the <service/> element are summarized in the following table.

* Note: The processes by which an external service might generate or an XMPP server might negotiate the username and password are outside the scope of this specification. One possible approach is for the XMPP server to generate a short-term authentication credential based on a private key shared with the external service.

If a server or service needs to include extended information, it SHOULD do so by including each bit of information as the XML character data of the <value/> child of a distinct <field/> element, with the entire set of fields contained within an <x/> element of type "result" qualified by the 'jabber:x:data' namespace (see &xep0004;); this <x/> element SHOULD be a child of the <service/> element qualified by the 'http://www.xmpp.org/extensions/xep-0215.html#ns' namespace &NSNOTE;. Thus the IQ result SHOULD be of the following form:

Note: A <field/> element MAY contain more than one <value/> child if appropriate.

If the data fields are to be used in the context of a protocol approved by the XMPP Standards Foundation, they SHOULD be registered in accordance with the rules defined in XEP-0068, resulting in the inclusion of a <field/> element whose 'var' attribute has a value of "FORM_TYPE" and whose 'type' attribute has a value of "hidden".

Note: Although &xep0128; specifies that an XMPP entity MUST NOT supply extended information about associated children communicated via the 'http://www.xmpp.org/extensions/xep-0215.html#ns' namespace, that rule does not apply to External Service Discovery since services external to the XMPP network cannot communicate via XMPP.

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: