This document defines a protocol for communicating user nicknames.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Standards Track
Number: 0172
Version: 0.6
Last Updated: 2006-03-27
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: N/A
Wiki Page: <http://wiki.jabber.org/index.php/User Nickname (JEP-0172)>
Email:
stpeter@jabber.org
JID:
stpeter@jabber.org
Email:
valerie.mercier@francetelecom.com
JID:
vmercier@jabber.com
This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
A nickname is a global, memorable (but not necessarily unique) friendly or informal name chosen by the owner of a bare JID (<node@domain.tld>) 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 RFC 3921 [1]). However, there are several reasons why nicknames are important:
This document defines best practices that enable IM users to advertise their preferred nicknames over Jabber/XMPP instant messaging networks.
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.
Table 1: JIDs, Nicknames, and Handles
| Name | Definition |
|---|---|
| Jabber ID (JID) | A global and unique XMPP identifier registered to a particular user, of the form <node@domain.tld>; 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. |
| Nickname | 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 RFC 2821 [3]) and SIP (see RFC 3261 [4]). |
| Handle | A private, unique, and memorable "petname" 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. |
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:
Example 1. A Nickname
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
A nickname of this form has the same semantic meaning as the following data fields:
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).
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:
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:
Example 2. Including Nickname with First Message
<message from='bernardo@shakespeare.lit/pda' to='francisco@shakespeare.lit' type='chat'>
<body>Who's there?</body>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</message>
As defined in RFC 3921, a subscription request contains only the JID of the sender:
Example 3. A Basic Subscription Request
<presence from='bernardo@shakespeare.lit' to='francisco@shakespeare.lit' type='subscribe'/>
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, vcard-temp [11] node, or JEP-0154 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:
Example 4. Including Nickname with Subscription Request
<presence from='bernardo@shakespeare.lit' to='francisco@shakespeare.lit' type='subscribe'>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</presence>
Multi-User Chat [12] defines a protocol for groupchat rooms. A user specifies a "room nickname" when joining such a room (the resource identifier of the 'to' address):
Example 5. A Basic Room Join Request
<presence from='bernardo@shakespeare.lit/patrol' to='elsinore@muc.shakespeare.lit/bernie'/>
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, because the user would like to log in to the same room from multiple resources, or because the service "locks down" room nicknames.
Example 6. Including Nickname with Room Join Request
<presence from='bernardo@shakespeare.lit/patrol' to='elsinore@muc.shakespeare.lit/bernie'>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</presence>
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:
Example 7. Presence Change With Nickname
<presence from='bernardo@shakespeare.lit/patrol' to='elsinore@muc.shakespeare.lit/bernie'>
<show>away</show>
<status>Out to lunch</status>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</presence>
A nickname may also be included in a MUC room invitation:
Example 8. Occupant Sends MUC Invitation
<message from='bernardo@shakespeare.lit/patrol' to='elsinore@muc.shakespeare.lit'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite to='francisco@shakespeare.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</invite>
</x>
</message>
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:
Example 9. MUC Room Forwards Invitation
<message from='elsinore@muc.shakespeare.lit' to='francisco@shakespeare.lit'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite from='bernardo@shakespeare.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</invite>
</x>
</message>
Waiting Lists [13] 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.
Example 10. IM User Requests Addition of Contact to WaitingList
<iq type='set'
from='bernardo@shakespeare.lit'
to='waitlist.shakespeare.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'>BernieBoy</nick>
</query>
</iq>
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:
Example 11. WaitingListService Pushes Contact's JID to IM User
<message
from='waitlist.shakespeare.lit'
to='bernardo@shakespeare.lit'>
<body>This message contains a WaitingList item.</body>
<waitlist xmlns='http://jabber.org/protocol/waitinglist'>
<item id='34567' jid='francisco@shakespeare.lit'>
<uri scheme='tel'>+45-555-1212</uri>
<nick xmlns='http://jabber.org/protocol/nick'>Frisco</nick>
</item>
</waitlist>
</message>
In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use the protocol defined in JEP-0154. If a Personal Eventing Protocol [14] service is not available, a client SHOULD use a standalone Publish-Subscribe [15] service. If a client does not support JEP-0060 or the subset thereof specified in JEP-0163, it MAY send one <message/> stanza to each of its contacts, containing the updated nickname:
Example 12. Nickname Change
<message from='bernardo@shakespeare.lit/patrol' to='francisco@shakespeare.lit'>
<nick xmlns='http://jabber.org/protocol/nick'>BernieBoy</nick>
</message>
.
.
.
The client SHOULD send the messages in a staggered fashion in order to avoid rate limiting (commonly known as "karma").
A nickname is a memorable, friendly name asserted by a user. There is no guarantee that any given nickname will be unique even within given 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 aliases or "petnames" (which are private and unique) as described in Prevention of JID Spoofing [16] in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [17].
The Jabber Registrar [18] shall include 'http://jabber.org/protocol/nick' in its registry of protocol namespaces.
Thanks to Ian Paterson for his feedback.
Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson (see <http://richard.dobson-i.net/jep.php?html=jep-01xx.xml>).
1. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
2. JEP-0165: Prevention of JID Spoofing <http://www.jabber.org/jeps/jep-0165.html>.
3. RFC 2821: Simple Mail Transfer Protocol <http://www.ietf.org/rfc/rfc2821.txt>.
4. RFC 3261: Session Initiation Protocol (SIP) <http://www.ietf.org/rfc/rfc3261.txt>.
5. JEP-0054: vcard-temp <http://www.jabber.org/jeps/jep-0054.html>.
6. JEP-0154: User Profile <http://www.jabber.org/jeps/jep-0154.html>.
7. JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>.
8. Friend of a Friend (FOAF) <http://xmlns.com/foaf/0.1/>.
9. See <http://xml.coverpages.org/xnal.html>.
10. OASIS is a not-for-profit, international consortium that drives the development, convergence and adoption of e-business standards. For further information, see <http://www.oasis-open.org/>.
11. JEP-0054: vcard-temp <http://www.jabber.org/jeps/jep-0054.html>.
12. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.
13. JEP-0130: Waiting Lists <http://www.jabber.org/jeps/jep-0130.html>.
14. JEP-0163: Personal Eventing Protocol <http://www.jabber.org/jeps/jep-0163.html>.
15. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.
16. JEP-0165: Prevention of JID Spoofing <http://www.jabber.org/jeps/jep-0165.html>.
17. 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/>.
18. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
Specified security considerations.
(psa)Fixed MUC invite example; clarified that nick refers to entity associated with nearest ancestor element that specifies a sender; added waitlist example.
(psa)To reflect use of dedicated namespace, (1) changed JEP type from Informational to Standards Track and (2) updated Jabber Registrar Considerations.
(psa)Modified to use dedicated namespace; added example for multi-user chat invitations.
(psa)Added wrapper element from JEP-0154.
(psa)Initial JEP version.
(psa)Added message exchange use case.
(psa)Added MUC and nickname management use cases; specified profile data syntax.
(psa)Initial version.
(psa)END