forked from xsf/xeps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0245.xml
130 lines (116 loc) · 6.74 KB
/
xep-0245.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
<?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>The /me Command</title>
<abstract>This specification defines recommended handling of the /me command in XMPP instant messaging clients.</abstract>
&LEGALNOTICE;
<number>0245</number>
<status>Active</status>
<type>Informational</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.0</version>
<date>2009-01-21</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, advanced specification to Active and changed type from Historical to Informational.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2009-01-08</date>
<initials>psa</initials>
<remark><p>Clarified handling of XHTML-IM formatting; added security consideration for multi-user chat rooms.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2008-06-18</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2008-06-09</date>
<initials>psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Many Jabber/XMPP instant messaging clients provide special processing and presentation of the string "/me " at the beginning of a message body. This specification describes the recommended handling of this "command".</p>
</section1>
<section1 topic='Recommended Handling' anchor='handling'>
<p>The /me command <note>The string "/me " is usually pronounced "slash-me".</note> is a text string that enables a human user to type an action phrase and have it be presented in a special way within an instant messaging client. The text string is followed by a verb or verb phrase, such as "/me laughs" or "/me is logging off now". This command does not result in the generation of any XMPP protocol. Instead, the command is sent as-is (e.g., <body>/me laughs</body>) and the receiving client performs string-matching on the first four characters of the data included in the &BODY; element to determine if the message begins with the string "/me ". If the client finds a match, the receiving client will show the message with a special presentation. It is RECOMMENDED for the client to show the receiving client's understanding of the sender's user name, nickname, or handle <note>On the difference between user names, nicknames, and handles, see &xep0165; and &xep0172;.</note> followed by the verb phrase in italicized text, prepended by the "*" character.</p>
<p>For example, imagine that the Greek god Atlas is in a chatroom with the other gods and types the following text in his IM client:</p>
<example caption="A /me Command"><![CDATA[
/me shrugs in disgust
]]></example>
<p>That text will be sent to all the occupants in the chatroom as follows:</p>
<example caption="XMPP Stanza"><![CDATA[
<message from='[email protected]/Atlas'
to='[email protected]'
type='groupchat'>
<body>/me shrugs in disgust</body>
</message>
]]></example>
<p>Each recipient's client would then show the message with a special presentation, such as:</p>
<example caption="Presentation of /me Command">
* Atlas shrugs in disgust
</example>
<p>If the receiving client does not find a match on the string "/me " in the first four characters of the message body, it SHOULD NOT present the text in a special way. For example, the following message bodies do not match:</p>
<example caption="Some Non-Commands"><![CDATA[
<body>/meshrugs in disgust</body>
<body>/me's disgusted</body>
<body> /me shrugs in disgust</body>
<body>"/me shrugs in disgust"</body>
<body>* Atlas shrugs in disgust</body>
<body>Why did Atlas say "/me shrugs in disgust"?</body>
]]></example>
</section1>
<section1 topic='Integration With XHTML-IM' anchor='xhtml'>
<p>&xep0071; describes a method for lightweight formatting of a message body using a subset of XHTML. For example, the stanza shown above might be formatted in the color green, as follows.</p>
<example caption="XMPP Stanza With XHTML-IM"><![CDATA[
<message from='[email protected]/Atlas'
to='[email protected]'
type='groupchat'>
<body>/me shrugs in disgust</body>
<html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'>
<p style='color:green'>/me shrugs in disgust</p>
</body>
</html>
</message>
]]></example>
<p>The XHTML-formatted version of the message MUST NOT modify the "/me " command string (e.g., in this case to something like "* Atlas shrugs in disgust") because the recipient might have a different user name, nickname, or handle on file for the sender.</p>
</section1>
<section1 topic='Accessibility Considerations' anchor='access'>
<p>This specification describes the /me command in terms of visual presentation. A receiving client that presents messages aurally MAY modify its presentation of /me commands and SHOULD at a minimum transform the string "/me " into the user name, nickname, or handle of the sender.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>&xep0045; rooms send XMPP presence stanzas when people leave and join the room, and receiving clients typically show these presence changes as the equivalent of in-room messages, such as the following transformation of a presence stanza of type unavailable:</p>
<example caption="Presentation of In-Room Presence Notification">
*** Atlas has left the room
</example>
<p>A sender could attempt to spoof such a leave message by sending an XMPP groupchat message stanza whose body text is "/me has left the room". Although the presentation of presence joins and leaves is determined by the receiving client and therefore such a notification cannot be universally spoofed for all receivers, a client SHOULD differentiate between presence notifications and /me commands (e.g., with different colors and different prepended characters, such as several asterisks for presence notifications and one asterisk for /me commands).</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'>
<p>This document requires no interaction with the ®ISTRAR;.</p>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>Thanks to Dave Cridland, Kevin Smith, and Matthew Wild for their feedback and suggestions.</p>
</section1>
</xep>