Based on implementation and deployment experience, discouraged use in Multi-User Chat; also removed Waiting Lists content because of lack of deployment.
&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):
-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.
-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:
-A nickname may also be included in a MUC room invitation:
-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:
-&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.
-Naturally, the WaitingListService SHOULD pass the nick on to its InteropPartners as well:
-If an InteropPartner knows a contact's nickname when it returns results to the WaitingListService it SHOULD include the nickname:
-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:
-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 XEP-0154.
Earlier versions of this document described how to include the User Nickname extension in presence stanzas and invitations sent in relation to &xep0045; 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 &xep0130; protocol. Because that protocol is now obsolete, documentation of such usage has been removed from this specification.
+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 XEP-0165 in order to provide a three-pronged approach to identity validation, preferably in combination with X.509 certificates.
+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.
This document requires no interaction with &IANA;.