No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0245.xml 6.7KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130
  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM 'xep.ent'>
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>The /me Command</title>
  10. <abstract>This specification defines recommended handling of the /me command in XMPP instant messaging clients.</abstract>
  11. &LEGALNOTICE;
  12. <number>0245</number>
  13. <status>Active</status>
  14. <type>Informational</type>
  15. <sig>Standards</sig>
  16. <approver>Council</approver>
  17. <dependencies>
  18. <spec>XMPP Core</spec>
  19. <spec>XMPP IM</spec>
  20. </dependencies>
  21. <supersedes/>
  22. <supersededby/>
  23. <shortname>N/A</shortname>
  24. &stpeter;
  25. <revision>
  26. <version>1.0</version>
  27. <date>2009-01-21</date>
  28. <initials>psa</initials>
  29. <remark><p>Per a vote of the XMPP Council, advanced specification to Active and changed type from Historical to Informational.</p></remark>
  30. </revision>
  31. <revision>
  32. <version>0.2</version>
  33. <date>2009-01-08</date>
  34. <initials>psa</initials>
  35. <remark><p>Clarified handling of XHTML-IM formatting; added security consideration for multi-user chat rooms.</p></remark>
  36. </revision>
  37. <revision>
  38. <version>0.1</version>
  39. <date>2008-06-18</date>
  40. <initials>psa</initials>
  41. <remark><p>Initial published version.</p></remark>
  42. </revision>
  43. <revision>
  44. <version>0.0.1</version>
  45. <date>2008-06-09</date>
  46. <initials>psa</initials>
  47. <remark><p>First draft.</p></remark>
  48. </revision>
  49. </header>
  50. <section1 topic='Introduction' anchor='intro'>
  51. <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>
  52. </section1>
  53. <section1 topic='Recommended Handling' anchor='handling'>
  54. <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., &lt;body&gt;/me laughs&lt;/body&gt;) 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>
  55. <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>
  56. <example caption="A /me Command"><![CDATA[
  57. /me shrugs in disgust
  58. ]]></example>
  59. <p>That text will be sent to all the occupants in the chatroom as follows:</p>
  60. <example caption="XMPP Stanza"><![CDATA[
  61. <message from='olympians@chat.gods.lit/Atlas'
  62. to='olympians@chat.gods.lit'
  63. type='groupchat'>
  64. <body>/me shrugs in disgust</body>
  65. </message>
  66. ]]></example>
  67. <p>Each recipient's client would then show the message with a special presentation, such as:</p>
  68. <example caption="Presentation of /me Command">
  69. * Atlas shrugs in disgust
  70. </example>
  71. <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>
  72. <example caption="Some Non-Commands"><![CDATA[
  73. <body>/meshrugs in disgust</body>
  74. <body>/me's disgusted</body>
  75. <body> /me shrugs in disgust</body>
  76. <body>"/me shrugs in disgust"</body>
  77. <body>* Atlas shrugs in disgust</body>
  78. <body>Why did Atlas say "/me shrugs in disgust"?</body>
  79. ]]></example>
  80. </section1>
  81. <section1 topic='Integration With XHTML-IM' anchor='xhtml'>
  82. <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>
  83. <example caption="XMPP Stanza With XHTML-IM"><![CDATA[
  84. <message from='olympians@chat.gods.lit/Atlas'
  85. to='olympians@chat.gods.lit'
  86. type='groupchat'>
  87. <body>/me shrugs in disgust</body>
  88. <html xmlns='http://jabber.org/protocol/xhtml-im'>
  89. <body xmlns='http://www.w3.org/1999/xhtml'>
  90. <p style='color:green'>/me shrugs in disgust</p>
  91. </body>
  92. </html>
  93. </message>
  94. ]]></example>
  95. <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>
  96. </section1>
  97. <section1 topic='Accessibility Considerations' anchor='access'>
  98. <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>
  99. </section1>
  100. <section1 topic='Security Considerations' anchor='security'>
  101. <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>
  102. <example caption="Presentation of In-Room Presence Notification">
  103. *** Atlas has left the room
  104. </example>
  105. <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>
  106. </section1>
  107. <section1 topic='IANA Considerations' anchor='iana'>
  108. <p>This document requires no interaction with &IANA;.</p>
  109. </section1>
  110. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  111. <p>This document requires no interaction with the &REGISTRAR;.</p>
  112. </section1>
  113. <section1 topic='Acknowledgements' anchor='ack'>
  114. <p>Thanks to Dave Cridland, Kevin Smith, and Matthew Wild for their feedback and suggestions.</p>
  115. </section1>
  116. </xep>