<abstract>This specification defines a protocol for communicating user nicknames, either in XMPP presence subscription requests or in XMPP messages.</abstract>
<remark><p>Based on implementation and deployment experience, discouraged use in Multi-User Chat; also removed text about Waiting Lists because of lack of deployment.</p></remark>
<remark><p>Per a vote of the Jabber Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2006-05-10</date>
<initials>psa</initials>
<remark><p>Added pubsub examples.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2006-04-28</date>
<initials>psa</initials>
<remark><p>Clarified terminology; explicitly mentioned that nicknames must not be included in presence broadcasts (only subscription requests); added implementation note about display names.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2006-04-21</date>
<initials>psa/vm</initials>
<remark><p>Added further detail to waitlist example; added schema.</p></remark>
<remark><p>Fixed MUC invite example; clarified that nick refers to entity associated with nearest ancestor element that specifies a sender; added waitlist example.</p></remark>
<remark><p>To reflect use of dedicated namespace, (1) changed document type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.</p></remark>
<p>A nickname is a global, memorable (but not necessarily unique) friendly or informal name chosen by the owner of a bare JID &LOCALBARE; for the purpose of associating a distinctive mapping between the person's unique JID and non-unique nickname. While nicknames have been a common feature of instant messaging systems for many years, they have not always featured prominently in Jabber/XMPP IM systems (e.g., nicknames are not specified in &rfc3921;). However, there are several reasons why nicknames are important:</p>
<p>This document defines best practices that enable IM users to advertise their preferred nicknames over Jabber/XMPP instant messaging networks.</p>
</section1>
<section1topic='Terminology'anchor='terms'>
<p>This proposal draws a distinction between the following kinds of names, where a JID is an innate feature of a user's identity on an XMPP system, a nickname is asserted by a user, and a handle is assigned by a contact to a user.</p>
<td>A global and unique XMPP identifier registered to a particular user, of the form &LOCALBARE;; represented in the 'from' attribute of XML stanzas sent by that user, the 'jid' attribute of items associated with that user in a contact's roster, etc.</td>
<td>A global and memorable (but not necessarily unique) friendly name or informal name asserted by an IM user. Typically, a nickname is different from a familiar name, such as "Chuck" for "Charles", "Bill" for "William", "Pete" for "Peter", or "Dave" for "David"; instead, a nickname is even less formal, such as "stpeter" or "dizzyd". A nickname is thus typically different from a "display name" as that term is understood in SMTP (see &rfc2821;) and SIP (see &rfc3261;).</td>
</tr>
<tr>
<td>Handle</td>
<td>A private, unique, and memorable "petname" or "alias" assigned by a contact to a user; represented in the 'name' attribute of the item associated with that user's JID in the contact's roster. <note>In RFC 3921, the name here called a "handle" is described as an "alias"; rfc3921 will be modified to use the term "handle" instead.</note></td>
</tr>
</table>
</section1>
<section1topic='Format'anchor='format'>
<p>A nickname MUST be encapsulated as the XML character data of a <nick/> element qualified by the 'http://jabber.org/protocol/nick' namespace. Here is an example:</p>
<li>The "Alias" field specified in the <cite>Extensible Name and Address Language</cite><note>See <<linkurl='http://xml.coverpages.org/xnal.html'>http://xml.coverpages.org/xnal.html</link>>.</note> developed by &OASIS;.</li>
</ul>
<p>The entity to which the <nick/> refers is the from address (no matter how encapsulated in XML) of the nearest ancestor element that specifies the sender (which might be a parent or grandparent element, e.g. the 'from' attribute of an &IQ; stanza).</p>
</section1>
<section1topic='Use Cases'anchor='usecases'>
<p>In general, a user SHOULD include his or her nickname when establishing initial communication with a contact or group of contacts (i.e., the user has never been in communication with and does not have a prior relationship with the contact or group of contacts). Appropriate use cases therefore include:</p>
<p>Naturally, based on the JID of the sender, it is possible for the client to pull information about the sender from a persistent data store such as an LDAP database, &xep0054; node, or <cite>XEP-0154</cite> store. However, to speed interactions, this document recommends that when a client sends a subscription request, it SHOULD include the preferred nickname of the sender:</p>
<p>Note: This document recommends sending the nickname only in presence subscription requests; the nickname MUST NOT be included in presence broadcasts (i.e., &PRESENCE; stanzas with no 'type' attribute or of type "unavailable").</p>
<p>When a user begins to chat with a contact but the two parties have no pre-existing relationship or prior communications (e.g., no presence subscription or previous message exchange), the user SHOULD include the nickname with the first message sent to the contact:</p>
<examplecaption='Including Nickname with First Message'><