RFC 2142 RFC 2142: Mailbox Names for Common Services, Roles and Functions <http://tools.ietf.org/html/rfc2142>. specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as security@domain.tld, usenet@domain.tld, and abuse@domain.tld). However, no such conventional email address or XMPP address has been specified for XMPP services (e.g., in RFC 3920 RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc3920>.). This document remedies that oversight, and the email recommendation specified here has been incorporated into RFC 6120 RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>..

Consistent with RFC 2142 RFC 2142: Mailbox Names for Common Services, Roles and Functions <http://tools.ietf.org/html/rfc2142>., a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service.

The administrators of an XMPP service may desire to advertise contact information related to that service. Many existing Jabber/XMPP server implementations use the bare domain <domain.tld> of the server (e.g., "example.org") as an alias for the server administrators, such that a <message/> stanza addressed to that domain name is delivered to the JIDs of the server administrators. (Currently, this functionality does not apply to <iq/> or <presence/> stanzas.) Unfortunately, using the "domain.tld" address as a way to direct messages to the server administrators may result in overloading of the bare domain address (i.e., it may be desirable to send messages to the server's address without having those messages delivered to the server admins, for example if the server doubles as a Publish-Subscribe (XEP-0060) XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>. service). Therefore, it is instead RECOMMENDED to support service discovery of contact addresses as specified herein. This contact information may include email addresses, web URLs, and JabberIDs for specific roles and functions such as the service administrators, abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains SHOULD support the electronic mailboxes required by RFC 2142 RFC 2142: Mailbox Names for Common Services, Roles and Functions <http://tools.ietf.org/html/rfc2142>.. However, additional contact mechanisms may be desirable, and it would be helpful if those who want to initiate contact could discover the contact information using standard XMPP extensions, specifically Service Discovery (XEP-0030) XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.. To make such discovery possible, we specify a Service Discovery Extensions (XEP-0128) XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>. mechanism that a server SHOULD return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information MUST be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in Service Discovery Extensions (XEP-0128) XEP-0128: Service Discovery Extensions <https://xmpp.org/extensions/xep-0128.html>.) and data form fields registered for this purpose as defined in the XMPP Registrar Considerations section of this document.

Values of 'status-addresses' form field MUST be valid URIs, i.e. comply with the 'xs:anyURI' datatype of XML Schema Part 2 XML Schema Part 2: Datatypes <http://www.w3.org/TR/xmlschema11-2/>.. Values of the 'abuse-addresses', 'admin-addresses', 'feedback-addresses', 'sales-addresses', 'security-addresses' and 'support-addresses' SHOULD be valid URIs.

To illustrate this usage, consider the following example of a disco#info request sent to the mythical shakespeare.lit XMPP server:

The "domain.tld" at which the XMPP service is hosted need not be the same as the "domain.tld" at which the email service is hosted. For example, it is common for a service provider to host its XMPP service at a hostname such as "jabber.example.org" whereas email related to the service provider is sent to a hostname of "example.org". Thus while the XMPP address and email address may be the same for some service providers (e.g., both "xmpp@example.com"), that similarity is not necessary.

Although some service providers that use the same address for both XMPP and email messaging may integrate delivery of messages sent by those mechanisms (e.g., XMPP messages sent while a user is offline are redirected to email delivery), XMPP and email remain separate messaging systems.

A service provider that supports the functionality specified herein may advertise the service through a Mailto URI (see RFC 2368 RFC 2368: The mailto URL scheme <http://tools.ietf.org/html/rfc2368>.) of <mailto:xmpp@domain.tld> and through appropriate XMPP URIs (see RFC 5122 RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc5122>.) such as <xmpp:admins@domain.tld> or (per XMPP URI Query Components (XEP-0147) XEP-0147: XMPP URI Query Components <https://xmpp.org/extensions/xep-0147.html>.) <xmpp:admins@domain.tld?message>.

It is a matter of service policy whether the XMPP addresses provided are dedicated accounts or aliases that redirect communications to the appropriate accounts.

Providing or advertising contact addresses may open those addresses to unwanted communication. Server administrators should balance the need for openness with the desire for control over communication with customers and peers.

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>..

The XMPP Registrar The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>. includes the following information in its registries.