Fix the schema to:
Fix incorrect type on IQ response in example 7
Updated references to IETF specifications.
Added ability to request credentials from a particular service; incremented the protocol version number to reflect the new feature.
Revived the spec by popular demand; updated namespace to use XMPP URN; defined registry process and several initial entries.
Added name attribute for human-readable labels; added internationalization considerations; added security considerations.
Broadened scope from discovery of STUN servers to discovery of any external (non-XMPP) service.
Initial published version.
Added attributes for username and password; reverted to IQ method since credentials are individualized.
Modified to use a well-known publish-subscribe node instead of a dedicated IQ exchange.
Made port mandatory since spec assumes that SRV is not available; added XML schema.
Made port optional.
First draft.
An XMPP client or other entity might 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 RFC 5389
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 or discovery service to provide information about external services, which might 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 XMPP entities involved (typically a client and server). This method does not use Service Discovery (XEP-0030)
In order to learn about external services known to an XMPP server or discovery service, a requesting entity (typically a client) sends an IQ-get containing an empty <services/> element qualified by the 'urn:xmpp:extdisco:2' namespace (see Protocol Namespaces regarding issuance of one or more permanent namespaces), typically to its own server but perhaps alternatively to a dedicated discovery service.
The responding entity (XMPP server or discovery service) SHOULD return the list of external services it is aware of, but MAY instead return an appropriate error, such as <service-unavailable/> if the responding entity 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 a responding entity 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.
| Name | Definition | Inclusion |
|---|---|---|
| action | When sending a push update, the action value indicates if the service is being added or deleted from the set of known services (or simply being modified). The defined values are "add", "remove", and "modify", where "add" is the default. | OPTIONAL |
| expires | A timestamp indicating when the provided username and password credentials will expire. The format MUST adhere to the dateTime format specified in XMPP Date and Time Profiles (XEP-0082) |
OPTIONAL |
| host | Either a fully qualified domain name (FQDN) or an IP address (IPv4 or IPv6). | REQUIRED |
| name | A friendly (human-readable) name or label for the service. | OPTIONAL |
| password | A service- or server-generated password for use at the service. * | OPTIONAL |
| port | The communications port to be used at the host. | RECOMMENDED |
| restricted | A boolean value indicating that username and password credentials are required and will need to be requested if not already provided (see Requesting Credentials). | OPTIONAL |
| transport | The underlying transport protocol to be used when communicating with the service (typically either TCP or UDP). | RECOMMENDED |
| type | The service type as registered with the XMPP Registrar |
REQUIRED |
| username | A service- or server-generated username for use at the service. * | OPTIONAL |
* 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.
A requesting entity requests all services by sending a <services/> element to its server or a discovery service.
A requesting entity requests services of a particular type by sending a <services/> element including a 'type' attribute specifying the service type of interest.
If a requesting entity requests services of a particular type, the responding service MAY as needed send an updated list of the relevant services by "pushing" the list to a requesting entity that has previously requested the list. However, it MUST NOT push updates to the requesting entity unless it has presence information about the requesting entity (e.g., because the requesting entity is connected to the XMPP server or because the requesting entity has shared presence with a remote discovery service). A push is an IQ set to the requesting entity containing a <services/> payload with updated data about services matching the requested type (e.g., new services or updated credentials). Each <service/> element SHOULD contain an 'action' attribute indicating if the service is being added, deleted, or modified.
Upon receiving a push, the requesting entity would then send an IQ-result to the responding service in accordance with XMPP Core
An entity might know about an external service via DNS or some other means, but still might need short-term credentials to use the service. The entity can request credentials by sending a special request to the server composed of a <credentials/> element qualified by the 'urn:xmpp:extdisco:2' namespace and contains a <service/> element which MUST include the 'host' and 'type' attributes to identify the desired service (the 'port' attribute MAY be provided if there are multiple services with the same host and type but different ports).
The server then returns credentials if possible.
For TURN, the server might construct time-limited credentials as described in A REST API for Access to TURN Services
There MAY be multiple <service/> elements in the result if more than one service matched the requested service identity (e.g., the same host provides service on multiple ports).
If the server cannot obtain credentials at the service, it returns an appropriate stanza error, such as <item-not-found/>, <remote-server-not-found/>, <remote-server-timeout/>, or <not-authorized/>.
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 Data Forms (XEP-0004)
[var-value]
[ ... ]
]]>
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 Field Standardization for Data Forms (XEP-0068)
Note: Although Service Discovery Extensions (XEP-0128)
If an XMPP entity supports this protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:extdisco:2" (see Protocol Namespaces regarding issuance of one or more permanent namespaces) in response to a Service Discovery (XEP-0030)
If the requesting entity includes an 'xml:lang' attribute with its request, the responding entity SHOULD include appropriately internationalized text as the value of the 'name' attribute. No other attributes are human-readable.
Because the responding entity (XMPP server or discovery service) functions as a "proxy" from external services to the XMPP network, it could modify the information it receives before passing it on to the requesting entity.
This specification defines the following XML namespace:
Upon advancement of this specification from a status of Experimental to a status of Draft, the XMPP Registrar
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.
The XMPP Registrar shall maintain a registry of external service types and their associated transport protocol(s). Such service types will probably be derived from the IANA Port Numbers Registry
In order to submit new values to this registry, the registrant shall define an XML fragment of the following form and either include it in the relevant XMPP Extension Protocol or send it to the email address <registrar@xmpp.org>:
the XML character data of the service type
a natural-language description of the service type
the document that best defines the service type
]]>
The registrant can register more than one service type at a time, each contained in a separate <service/> element.
stun
a server that provides Session Traversal Utilities for NAT (STUN)
RFC 5389
turn
a server that provides Traversal Using Relays around NAT (TURN)
RFC 5766
]]>
]]>
Thanks to Philipp Hancke, Justin Karneges, Evgeniy Khramtsov, and Unnikrishnan Vikrama Panicker for their feedback.