XEP-0172: User Nickname

Abstract:This specification defines a protocol for communicating user nicknames, either in XMPP presence subscription requests or in XMPP messages.
Authors:Peter Saint-Andre, Valerie Mercier
Copyright:© 1999 - 2012 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Draft
Type:Standards Track
Version:1.1
Last Updated:2012-03-21

NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.

Table of Contents


1. Introduction
2. Terminology
3. Format
4. Use Cases
    4.1. Presence Subscription Requests
    4.2. Message Exchange
    4.3. Nickname Management
5. Implementation Notes
6. Former Usages
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
    9.1. Protocol Namespaces
10. XML Schema
11. Acknowledgements

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

A nickname is a global, memorable (but not necessarily unique) friendly or informal name chosen by the owner of a bare JID <localpart@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.

2. Terminology

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 <localpart@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" 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. [5]

3. Format

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'>Ishmael</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).

4. Use Cases

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:

4.1 Presence Subscription Requests

As defined in RFC 3921, a presence subscription request contains only the JID of the sender:

Example 2. A Basic Subscription Request

<presence from='narrator@moby-dick.lit' to='starbuck@moby-dick.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 [12] node, or XEP-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 3. Including Nickname with Subscription Request

<presence from='narrator@moby-dick.lit' to='starbuck@moby-dick.lit' type='subscribe'>
  <nick xmlns='http://jabber.org/protocol/nick'>Ishmael</nick>
</presence>

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").

4.2 Message Exchange

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 4. Including Nickname with First Message

<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>

4.3 Nickname Management

In order for a user to modify his or her nickname and notify contacts of that change, it is RECOMMENDED for clients to use Personal Eventing Protocol [13] (a.k.a. PEP).

Example 5. User Publishes Updated Nickname to PEP Node

<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 6. PEP Node Generates Notifications

<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>
.
.
.

If a XEP-0163-compliant personal eventing service is not available, a client SHOULD use a standalone Publish-Subscribe [14] service.

Example 7. User Publishes Updated Nickname to PubSub Node

<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 8. PubSub Node Generates Notifications

<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>
.
.
.

If a client does not support XEP-0060 or the subset thereof specified in XEP-0163, 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").

Example 9. Nickname Change Notification via Message

<message from='narrator@moby-dick.lit/pda' to='starbuck@moby-dick.lit'>
  <nick xmlns='http://jabber.org/protocol/nick'>CallMeIshmael</nick>
</message>
.
.
.

5. Implementation Notes

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, Private XML Storage [15], or XEP-0154.

6. Former Usages

Earlier versions of this document described how to include the User Nickname extension in presence stanzas and invitations sent in relation to Multi-User Chat [16] rooms. Based on deployment experience, that usage is now discouraged, since it is confusing to display multiple nicknames to an end user and inclusion of user-generated nicknames can override or work around local service policies for "nick lockdown" in chatrooms.

Earlier versions also described usage in relation to the Waiting Lists [17] protocol. Because that protocol is now obsolete, documentation of such usage has been removed from this specification.

7. Security Considerations

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 particular 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 XEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA) [18].

9. XMPP Registrar Considerations

9.1 Protocol Namespaces

The XMPP Registrar [19] includes 'http://jabber.org/protocol/nick' in its registry of protocol namespaces (see <http://xmpp.org/registrar/namespaces.html>).

10. XML Schema

<?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>

11. Acknowledgements

Thanks to Ian Paterson for his feedback.

Unbeknownst to the authors of this document, work on user nicknames was previously done by Richard Dobson.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0172
Publisher: XMPP Standards Foundation
Status: Draft
Type: Standards Track
Version: 1.1
Last Updated: 2012-03-21
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: nick
Schema: <http://www.xmpp.org/schemas/nick.xsd>
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/

Valerie Mercier

Email: valerie.mercier@orange-ftgroup.com
JabberID: vmercier@jabber.com

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2012 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards 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 document 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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

2. XEP-0165: Best Practices to Prevent JID Mimicking <http://xmpp.org/extensions/xep-0165.html>.

3. RFC 2821: Simple Mail Transfer Protocol <http://tools.ietf.org/html/rfc2821>.

4. RFC 3261: Session Initiation Protocol (SIP) <http://tools.ietf.org/html/rfc3261>.

5. In RFC 3921, the name here called a "handle" is described as an "alias"; rfc3921 will be modified to use the term "handle" instead.

6. XEP-0054: vcard-temp <http://xmpp.org/extensions/xep-0054.html>.

7. XEP-0154: User Profile <http://xmpp.org/extensions/xep-0154.html>.

8. XEP-0077: In-Band Registration <http://xmpp.org/extensions/xep-0077.html>.

9. Friend of a Friend (FOAF) <http://xmlns.com/foaf/0.1/>.

10. See <http://xml.coverpages.org/xnal.html>.

11. 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/>.

12. XEP-0054: vcard-temp <http://xmpp.org/extensions/xep-0054.html>.

13. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

14. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

15. XEP-0049: Private XML Storage <http://xmpp.org/extensions/xep-0049.html>.

16. XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

17. XEP-0130: Waiting Lists <http://xmpp.org/extensions/xep-0130.html>.

18. 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/>.

19. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 1.1 (2012-03-21)

Based on implementation and deployment experience, discouraged use in Multi-User Chat; also removed text about Waiting Lists because of lack of deployment.

(psa)

Version 1.0 (2006-06-05)

Per a vote of the Jabber Council, advanced status to Draft.

(psa)

Version 0.9 (2006-05-10)

Added pubsub examples.

(psa)

Version 0.8 (2006-04-28)

Clarified terminology; explicitly mentioned that nicknames must not be included in presence broadcasts (only subscription requests); added implementation note about display names.

(psa)

Version 0.7 (2006-04-21)

Added further detail to waitlist example; added schema.

(psa/vm)

Version 0.6 (2006-03-27)

Specified security considerations.

(psa)

Version 0.5 (2006-03-22)

Fixed MUC invite example; clarified that nick refers to entity associated with nearest ancestor element that specifies a sender; added waitlist example.

(psa)

Version 0.4 (2006-03-20)

To reflect use of dedicated namespace, (1) changed document type from Informational to Standards Track and (2) updated XMPP Registrar Considerations.

(psa)

Version 0.3 (2006-03-16)

Modified to use dedicated namespace; added example for multi-user chat invitations.

(psa/vm)

Version 0.2 (2006-03-08)

Added wrapper element from XEP-0154.

(psa)

Version 0.1 (2006-01-24)

Initial version.

(psa)

Version 0.0.3 (2006-01-22)

Added message exchange use case.

(psa/vm)

Version 0.0.2 (2006-01-18)

Added MUC and nickname management use cases; specified profile data syntax.

(psa/vm)

Version 0.0.1 (2005-09-12)

Initial version.

(psa)

END