xeps/xep-0157.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Contact Addresses for XMPP Services</title>
  <abstract>This document defines a method for specifying contact addresses related to an XMPP service.</abstract>
  &LEGALNOTICE;
  <number>0157</number>
  <status>Experimental</status>
  <type>Standards Track</type>
  <jig>Standards JIG</jig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>N/A</shortname>
  &stpeter;
  <author>
    <firstname>Jacek</firstname>
    <surname>Konieczny</surname>
    <email>jajcus@jajcus.net</email>
    <jid>jajcus@jabber.bnet.pl</jid>
  </author>
  <revision>
    <version>0.3</version>
    <date>2006-07-31</date>
    <initials>psa</initials>
    <remark><p>Recommended support for RFC2142-style mailbox in addition to XMPP address.</p></remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2006-07-18</date>
    <initials>psa</initials>
    <remark><p>Removed extended addressing recommendations pending further review.</p></remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2005-09-08</date>
    <initials>psa</initials>
    <remark><p>Initial version.</p></remark>
  </revision>
  <revision>
    <version>0.0.2</version>
    <date>2005-09-06</date>
    <initials>psa</initials>
    <remark><p>Added security considerations and XMPP Registrar considerations.</p></remark>
  </revision>
  <revision>
    <version>0.0.1</version>
    <date>2005-08-27</date>
    <initials>psa/jk</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  &BISNOTE;
  <p>&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.</p>
</section1>
<section1 topic='XMPP Address' anchor='xmpp'>
  <p>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;.</p>
</section1>
<section1 topic='Email Address' anchor='email'>
  <p>Consistent with <cite>RFC 2142</cite>, 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 &lt;mailto:xmpp@domain.tld&gt;.</p>
</section1>
<!--
<section1 topic='Extended Server Information' anchor='disco'>
  <p>The administrators of a Jabber/XMPP service may desire to advertise more detailed contact information related to that service. This contact information may include email addresses, web URLs, and JIDs for specific roles and functions such as abuse reports, customer feedback, sales inquiries, technical support, and security concerns. For this purpose, domains MUST support the electronic mailboxes required by <cite>RFC 2142</cite>. 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 &xep0030;. To make such discovery possible, we specify a &xep0128; mechanism that a server MAY return in response to service discovery information ("disco#info") requests sent to the bare domain of the server. This information SHOULD be scoped using a FORM_TYPE of "http://jabber.org/network/serverinfo" (as already specified in <cite>XEP-0128</cite>) and data form fields registered for this purpose as defined in the <link url='#registrar'>XMPP Registrar Considerations</link> section of this document.</p>
  <p>To illustrate this usage, consider the following example of a disco#info request sent to the mythical shakespeare.lit XMPP server:</p>
  <example caption='Entity queries server for information'><![CDATA[
<iq from='juliet@capulet.com/chamber'
    to='shakespeare.lit'
    id='disco1'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    ]]></example>
    <example caption='Server communicates information'><![CDATA[
<iq from='shakespeare.lit'
    to='juliet@capulet.com/chamber'
    id='disco1'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='server' type='im'/>
    <feature var='http://jabber.org/protocol/disco'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>http://jabber.org/network/serverinfo</value>
      </field>
      <field var='abuse-addresses'>
        <value>mailto:abuse@shakespeare.lit</value>
        <value>xmpp:shakespeare.lit/abuse</value>
      </field>
      <field var='feedback-addresses'>
        <value>http://shakespeare.lit/feedback.php</value>
        <value>mailto:feedback@shakespeare.lit</value>
        <value>xmpp:shakespeare.lit/feedback</value>
      </field>
      <field var='sales-addresses'>
        <value>xmpp:bard@shakespeare.lit</value>
      </field>
      <field var='security-addresses'>
        <value>xmpp:shakespeare.lit/security</value>
      </field>
      <field var='support-addresses'>
        <value>http://shakespeare.lit/support.php</value>
        <value>xmpp:shakespeare.lit/support</value>
      </field>
    </x>
  </query>
</iq>
    ]]></example>
</section1>
-->
<section1 topic='Security Considerations' anchor='security'>
  <p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p>
</section1>
<!--
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>The &REGISTRAR; shall include the following information in its registries.</p>
  <section2 topic='Field Standardization' anchor='registrar-formtype'>
    <p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace, and <cite>XEP-0128</cite> describes how to use field standardization in the context of service discovery. This section registers fields for server information scoped by the "http://jabber.org/network/serverinfo" FORM_TYPE.</p>
    <code caption='Registry Submission'><![CDATA[
<form_type>
  <name>http://jabber.org/network/serverinfo</name>
  <doc>XEP-0157</doc>
  <desc>
    Forms enabling the communication of contact addresses
    and other server information.
  </desc>
  <field
      var='abuse-addresses'
      type='list-multi'
      label='One or more addresses for communication related to abusive traffic'/>
  <field
      var='feedback-addresses'
      type='list-multi'
      label='One or more addresses for customer feedback'/>
  <field
      var='sales-addresses'
      type='list-multi'
      label='One or more addresses for communication related to sales and marketing'/>
  <field
      var='security-addresses'
      type='list-multi'
      label='One or more addresses for communication related to security concerns'/>
  <field
      var='support-addresses'
      type='list-multi'
      label='One or more addresses for customer support'/>
</form_type>
    ]]></code>
  </section2>
</section1>
-->
</xep>