%ents; ]>
Contact Addresses for XMPP Services This document defines a method for specifying contact addresses related to an XMPP service. &LEGALNOTICE; 0157 Experimental Standards Track Standards JIG Council XMPP Core N/A &stpeter; Jacek Konieczny jajcus@jajcus.net jajcus@jabber.bnet.pl 0.3 2006-07-31 psa

Recommended support for RFC2142-style mailbox in addition to XMPP address.

0.2 2006-07-18 psa

Removed extended addressing recommendations pending further review.

0.1 2005-09-08 psa

Initial JEP version.

0.0.2 2005-09-06 psa

Added security considerations and Jabber Registrar considerations.

0.0.1 2005-08-27 psa/jk

First draft.

&BISNOTE;

&rfc2142; specifies conventional electronic mailbox names for common services, roles, and functions related to SMTP, NNTP, and HTTP (such as postmaster@domain.tld, usenet@domain.tld, and webmaster@domain.tld). However, no such conventional email address or Jabber ID (JID) has been specified for XMPP services. This document remedies that oversight.

Many existing Jabber/XMPP server implementations use the bare domain of the server as an alias for the server administrators, such that a &MESSAGE; stanza addressed to that domain name (e.g., "jabber.org") is delivered to the JIDs of the server administrators (this does not apply to &IQ; or &PRESENCE; stanzas). It is RECOMMENDED that all server implementations support this functionality, and the authors will work toward standardization of this functionality in the forthcoming revisions to &rfc3920;.

Consistent with RFC 2142, a domain that offers a Jabber/XMPP service SHOULD provide an Internet mailbox of "XMPP" for inquiries related to that service, which MAY be advertised through a URI of <mailto:xmpp@domain.tld>.

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. That said, certain contact addresses (e.g., abuse addresses and security addresses) may enable server administrators to more quickly learn of abusive usage and potential security holes, and advertisement of those addresses is strongly encouraged.

This document requires no interaction with &IANA;.