mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-28 04:02:20 -05:00
1.1rc1
This commit is contained in:
stpeter
parent
c7c525fa4c
commit
6e2f7fdbab
111
xep-0172.xml
111
xep-0172.xml
@ -11,6 +11,7 @@
|
||||
&LEGALNOTICE;
|
||||
<number>0172</number>
|
||||
<status>Draft</status>
|
||||
<interim/>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
@ -25,6 +26,12 @@
|
||||
</schemaloc>
|
||||
&stpeter;
|
||||
&val;
|
||||
<revision>
|
||||
<version>1.1rc1</version>
|
||||
<date>in progress, last updated 2012-03-06</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Based on implementation and deployment experience, discouraged use in Multi-User Chat; also removed Waiting Lists content because of lack of deployment.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.0</version>
|
||||
<date>2006-06-05</date>
|
||||
@ -176,104 +183,6 @@
|
||||
<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>
|
||||
@ -361,8 +270,12 @@
|
||||
<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='Former Usages' anchor='former'>
|
||||
<p>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.</p>
|
||||
<p>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.</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>
|
||||
<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 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 <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>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user