IANA Registration for Enumservice 'XMPP'

E.164 Number Mapping (ENUM) uses the Domain Name System (DNS) to refer from E.164 numbers to Uniform Resource Identifiers (URIs). Specific services to be used with ENUM must be registered with IANA. Section 3 of RFC 3761 describes the process of such an Enumservice registration. The Extensible Messaging and Presence Protocol (XMPP) provides means for streaming Extensible Markup Language (XML) elements between endpoints in close to real time. The XMPP framework is mainly used to provide instant messaging, presence, and streaming media services. RFC 4622 registers a Uniform Resource Identifier (URI) scheme for identifying an XMPP entity as a URI or as an Internationalized Resource Identifier (IRI). The Enumservice specified in this document allows the provisioning of such "xmpp" URIs (and the URI representations of "xmpp" IRIs) in ENUM.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The following template contains information required for the IANA registrations of the 'XMPP' Enumservice, according to Section 3 of RFC 3761: Enumservice Name: "XMPP" Enumservice Type: "xmpp" Enumservice Subtype: n/a URI Schemes: "xmpp" Functional Specification: This Enumservice indicates that the resource identified is an XMPP entity. Security Considerations: see Intended Usage: COMMON Author: Alexander Mayrhofer <alexander.mayrhofer@enum.at>

XMPP IRIs/URIs optionally contain an "Authority Component" (see Section 2.3 of RFC 4622). The presence of such an Authority Component in an IRI/URI signals the processing application to authenticate as the user indicated in the URI/IRI rather than using the preconfigured identity. In the context of this Enumservice, arbitrary clients may discover and use the XMPP URIs/IRIs associated to an E.164 number. Hence, in most cases, those clients will not be able to authenticate as requested in the Authority Component. Therefore, URIs/IRIs that result from processing an XMPP Enumservice record SHOULD NOT contain an Authority Component.

While XMPP supports IRIs as well as 'plain' URIs, ENUM itself supports only the use of URIs for Enumservices. Therefore, XMPP IRIs MUST be mapped to URIs for use in an XMPP Enumservice record. The mapping MUST follow the procedures outlined in Section 3.1 of RFC 3987.

An example ENUM entry referencing to a XMPP URI could look like: $ORIGIN 6.9.4.0.6.9.4.5.1.1.4.4.e164.arpa. @ IN NAPTR ( 100 10 "u" "E2U+xmpp" "!^.*$!xmpp:some-user@example.com!" . )

General security considerations of the protocols on which this Enumservice registration is based are addressed in Sections 3.1.3 and 6 of RFC 3761 (ENUM) and Section 14 of RFC 3920 (XMPP). Since ENUM uses DNS -- a publicly available database -- any information contained in records provisioned in ENUM domains must be considered public as well. Even after revoking the DNS entry and removing the referred resource, copies of the information could still be available. Information published in ENUM records could reveal associations between E.164 numbers and their owners -- especially if IRIs/URIs contain personal identifiers or domain names for which ownership information can be obtained easily. However, it is important to note that the ENUM record itself does not need to contain any personal information. It just points to a location where access to personal information could be granted. ENUM records pointing to third-party resources can easily be provisioned on purpose by the ENUM domain owner -- so any assumption about the association between a number and an entity could therefore be completely bogus unless some kind of identity verification is in place. This verification is out of scope for this memo.

This memo requests IANA to add a new "XMPP" Enumservice to the 'Enumservice Registrations' registry, according to the definitions in this document and RFC 3761. The required template is contained in .

Some text from RFC 4622 was used in the Introduction of this document. Charles Clancy, Miguel Garcia, Andrew Newton, Jon Peterson, and Peter Saint-Andre provided extensive reviews and valuable feedback.