1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-17 13:22:26 -05:00
xeps/xep-0172.xml
Peter Saint-Andre 0e73f89e7c abstract
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1703 4b5297f7-1745-476d-ba37-a9c6900126ab
2008-02-25 23:45:29 +00:00

402 lines
20 KiB
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>User Nickname</title>
<abstract>This specification defines a protocol for communicating user nicknames, either in XMPP presence subscription requests or in XMPP messages.</abstract>
&LEGALNOTICE;
<number>0172</number>
<status>Draft</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>nick</shortname>
<schemaloc>
<url>http://www.xmpp.org/schemas/nick.xsd</url>
</schemaloc>
&stpeter;
&val;
<revision>
<version>1.0</version>
<date>2006-06-05</date>
<initials>psa</initials>
<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>
</revision>
<revision>
<version>0.6</version>
<date>2006-03-27</date>
<initials>psa</initials>
<remark><p>Specified security considerations.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2006-03-22</date>
<initials>psa</initials>
<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>
</revision>
<revision>
<version>0.4</version>
<date>2006-03-20</date>
<initials>psa</initials>
<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>
</revision>
<revision>
<version>0.3</version>
<date>2006-03-16</date>
<initials>psa/vm</initials>
<remark><p>Modified to use dedicated namespace; added example for multi-user chat invitations.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2006-03-08</date>
<initials>psa</initials>
<remark><p>Added wrapper element from XEP-0154.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark><p>Initial version.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2006-01-22</date>
<initials>psa/vm</initials>
<remark><p>Added message exchange use case.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2006-01-18</date>
<initials>psa/vm</initials>
<remark><p>Added MUC and nickname management use cases; specified profile data syntax.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2005-09-12</date>
<initials>psa</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<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>
<ul>
<li>Users like them.</li>
<li>They are easier to remember than JIDs.</li>
<li>They can be used to help prevent mimicking of JIDs (see &xep0165;).</li>
</ul>
<p>This document defines best practices that enable IM users to advertise their preferred nicknames over Jabber/XMPP instant messaging networks.</p>
</section1>
<section1 topic='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>
<table caption='JIDs, Nicknames, and Handles'>
<tr>
<th>Name</th>
<th>Definition</th>
</tr>
<tr>
<td>Jabber ID (JID)</td>
<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>
</tr>
<tr>
<td>Nickname</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>
<section1 topic='Format' anchor='format'>
<p>A nickname MUST be encapsulated as the XML character data of a &lt;nick/&gt; element qualified by the 'http://jabber.org/protocol/nick' namespace. Here is an example:</p>
<example caption='A Nickname'><![CDATA[
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
]]></example>
<p>A nickname of this form has the same semantic meaning as the following data fields:</p>
<ul>
<li>The "NICKNAME" field specified in &xep0054;.</li>
<li>The "nickname" field specified in &xep0154;.</li>
<li>The "nickname" field specified in &xep0077;.</li>
<li>The "nick" field specified in &foaf;.</li>
<li>The "Alias" field specified in the <cite>Extensible Name and Address Language</cite> <note>See &lt;<link url='http://xml.coverpages.org/xnal.html'>http://xml.coverpages.org/xnal.html</link>&gt;.</note> developed by &OASIS;.</li>
</ul>
<p>The entity to which the &lt;nick/&gt; 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>
<section1 topic='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>
<ul>
<li>Presence subscription requests</li>
<li>Message exchange</li>
<li>Multi-user chat</li>
<li>Waiting lists</li>
</ul>
<section2 topic='Presence Subscription Requests' anchor='subscription'>
<p>As defined in <cite>RFC 3921</cite>, a presence subscription request contains only the JID of the sender:</p>
<example caption='A Basic Subscription Request'><![CDATA[
<presence from='narrator@moby-dick.lit' to='starbuck@moby-dick.lit' type='subscribe'/>
]]></example>
<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>
<example caption='Including Nickname with Subscription Request'><![CDATA[
<presence from='narrator@moby-dick.lit' to='starbuck@moby-dick.lit' type='subscribe'>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</presence>
]]></example>
<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>
</section2>
<section2 topic='Message Exchange' anchor='message'>
<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>
<example caption='Including Nickname with First Message'><![CDATA[
<message from='narrator@moby-dick.lit/pda' to='starbuck@moby-dick.lit' type='chat'>
<body>Call me Ishmael</body>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</message>
]]></example>
</section2>
<section2 topic='Multi-User Chat' anchor='muc'>
<p>&xep0045; defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):</p>
<example caption='A Basic Room Join Request'><![CDATA[
<presence from='narrator@moby-dick.lit/pda' to='pequod@muc.moby-dick.lit/narrator'/>
]]></example>
<p>A user MAY specify his or her persistent nickname as well. This may be desirable because the user's preferred room nickname is already taken or because the service "locks down" room nicknames.</p>
<example caption='Including Nickname with Room Join Request'><![CDATA[
<presence from='narrator@moby-dick.lit/pda' to='pequod@muc.moby-dick.lit/narrator'>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</presence>
]]></example>
<p>If a user includes his or her persistent nickname in the room join request, the nickname SHOULD also be included in any presence changes sent to the room:</p>
<example caption='Presence Change With Nickname'><![CDATA[
<presence from='narrator@moby-dick.lit/pda' to='pequod@muc.moby-dick.lit/narrator'>
<show>away</show>
<status>writing</status>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</presence>
]]></example>
<p>A nickname may also be included in a MUC room invitation:</p>
<example caption='Occupant Sends MUC Invitation'><![CDATA[
<message from='narrator@moby-dick.lit/pda' to='pequod@muc.moby-dick.lit'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite to='starbuck@moby-dick.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</invite>
</x>
</message>
]]></example>
<p>Although the foregoing stanza may seem to violate the rule about associating a nick with the nearest ancestor element that specifies the sender's JID, the output from the MUC room does not violate that rule, since the room swaps the to and from addresses before sending the invitation to the invitee:</p>
<example caption='MUC Room Forwards Invitation'><![CDATA[
<message from='pequod@muc.moby-dick.lit' to='starbuck@moby-dick.lit'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite from='narrator@moby-dick.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</invite>
</x>
</message>
]]></example>
</section2>
<section2 topic='Waiting Lists' anchor='waitlist'>
<p>&xep0130; defines a protocol that enables a user to be informed when a contact signs up for an IM account. The user MAY include his or her nick in the request so that the contact can associate a nickname with the request.</p>
<example caption="IM User Requests Addition of Contact to WaitingList"><![CDATA[
<iq type='set'
from='narrator@moby-dick.lit'
to='waitlist.mody-dick.lit'
id='wl1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>+45-555-1212</uri>
</item>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</query>
</iq>
]]></example>
<p>Naturally, the WaitingListService SHOULD pass the nick on to its InteropPartners as well:</p>
<example caption="ServiceProvider's WaitingListService Adds New Item to WaitingList"><![CDATA[
<iq type='set'
from='waitlist.service-provider.com'
to='waitlist.interop-partner.com'
id='waitinglist2'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item>
<uri scheme='tel'>contact-number</uri>
</item>
<nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</query>
</iq>
]]></example>
<p>If an InteropPartner knows a contact's nickname when it returns results to the WaitingListService it SHOULD include the nickname:</p>
<example caption="InteropPartner's WaitingListService Pushes Contact's JID to ServiceProvider's WaitingListService"><![CDATA[
<iq type='set'
from='waitlist.interop-partner.com'
to='waitlist.service-provider.com'
id='jidpush1'>
<query xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567' jid='user@domain'>
<uri scheme='tel'>contact-number</uri>
<nick xmlns='http://jabber.org/protocol/nick'>Starbuck</nick>
</item>
</query>
</iq>
]]></example>
<p>Finally, if the user's waiting list service knows the contact's nickname when it sends a notification to the user, it SHOULD include the nickname:</p>
<example caption="WaitingListService Pushes Contact's JID to IM User"><![CDATA[
<message
from='waitlist.mody-dick.lit'
to='narrator@moby-dick.lit'>
<body>This message contains a WaitingList item.</body>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567' jid='starbuck@moby-dick.lit'>
<uri scheme='tel'>+45-555-1212</uri>
<nick xmlns='http://jabber.org/protocol/nick'>Starbuck</nick>
</item>
</waitlist>
</message>
]]></example>
</section2>
<section2 topic='Nickname Management' anchor='manage'>
<p>In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use &xep0163; (a.k.a. PEP).</p>
<example caption='User Publishes Updated Nickname to PEP Node'><![CDATA[
<iq from='narrator@moby-dick.lit/pda'
type='set'
id='pub1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='http://jabber.org/protocol/nick'>
<item>
<nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<example caption='PEP Node Generates Notifications'><![CDATA[
<message from='narrator@moby-dick.lit'
to='starbuck@moby-dick.lit'
type='headline'
id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='http://jabber.org/protocol/nick'>
<item>
<nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='narrator@moby-dick.lit/pda'/>
</addresses>
</message>
.
.
.
]]></example>
<p>If a XEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone &xep0060; service.</p>
<example caption='User Publishes Updated Nickname to PubSub Node'><![CDATA[
<iq from='narrator@moby-dick.lit/pda'
to='pubsub.mody-dick.lit'
type='set'
id='pub2'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='841f3c8955c4c41a0cf99620d78a33b996659ded'>
<item>
<nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<example caption='PubSub Node Generates Notifications'><![CDATA[
<message from='pubsub.mody-dick.lit'
to='starbuck@moby-dick.lit'
type='headline'
id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='841f3c8955c4c41a0cf99620d78a33b996659ded'>
<item>
<nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
</item>
</items>
</event>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='replyto' jid='narrator@moby-dick.lit/pda'/>
</addresses>
</message>
.
.
.
]]></example>
<p>If a client does not support <cite>XEP-0060</cite> or the subset thereof specified in <cite>XEP-0163</cite>, it MAY send one &MESSAGE; stanza to each of its contacts, containing the updated nickname (note: the client SHOULD send the messages in a staggered fashion in order to avoid server-enforced rate limiting, commonly known as "karma").</p>
<example caption='Nickname Change Notification via Message'><![CDATA[
<message from='narrator@moby-dick.lit/pda' to='starbuck@moby-dick.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
</message>
.
.
.
]]></example>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>An IM client MAY use the user's own nickname as all or part of the "display name" shown to the user of that client (e.g., as the sending name in one-to-one chats and groupchats). For example, if the user whose JID is narrator@moby-dick.lit asserts that his nickname is "Ishmael", that user's client may show "Ishmael" as all or part of the user's display name. How the client shall store the display name is out of scope for this document; possible mechanisms include the user's local vCard, an organizational LDAP directory, &xep0049;, or <cite>XEP-0154</cite>.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within a particulat community (such as an enterprise or university), let alone across the Internet through federation of communities. Clients SHOULD warn users that nicknames asserted by contacts are not unique and that nickname collisions are possible. Clients also MUST NOT depend on nicknames to validate the identity of contacts; instead, nicknames SHOULD be used in conjunction with JIDs (which are globally unique) and user-assigned handles (which are private and unique) as described in <cite>XEP-0165</cite> in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.</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'>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>The &REGISTRAR; includes 'http://jabber.org/protocol/nick' in its registry of protocol namespaces (see &NAMESPACES;).</p>
</section2>
</section1>
<section1 topic="XML Schema" anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/nick'
xmlns='http://jabber.org/protocol/nick'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0172: http://www.xmpp.org/extensions/xep-0172.html
</xs:documentation>
</xs:annotation>
<xs:element name='nick' type='xs:string'/>
</xs:schema>
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Ian Paterson for his feedback.</p>
<p>Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see &lt;<link url='http://richard.dobson-i.net/xep.php?html=xep-01xx.xml'>http://richard.dobson-i.net/xep.php?html=xep-01xx.xml</link>&gt;).</p>
</section1>
</xep>