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-0259.xml 18KB

  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>Message Mine-ing</title>
  10. <abstract>In servers that deliver messages intended for the bare JID to
  11. all resources, the resource that claims a conversation notifies all
  12. of the other resources of that claim.</abstract>
  14. <number>0259</number>
  15. <status>Deferred</status>
  16. <type>Standards Track</type>
  17. <sig>Standards</sig>
  18. <approver>Council</approver>
  19. <dependencies>
  20. <spec>XMPP Core</spec>
  21. <spec>XEP-0030</spec>
  22. <spec>XEP-0045</spec>
  23. <spec>XEP-0115</spec>
  24. </dependencies>
  25. <supersedes/>
  26. <supersededby/>
  27. <shortname>mine</shortname>
  28. &hildjj;
  29. <revision>
  30. <version>0.1</version>
  31. <date>2009-01-21</date>
  32. <initials>psa</initials>
  33. <remark><p>Initial published version.</p></remark>
  34. </revision>
  35. <revision>
  36. <version>0.0.1</version>
  37. <date>2008-10-22</date>
  38. <initials>jjh</initials>
  39. <remark><p>First draft.</p></remark>
  40. </revision>
  41. </header>
  42. <section1 topic='Introduction' anchor='intro'>
  43. <p>At the time of original writing of this XEP, many XMPP servers
  44. handle message stanzas sent to a user@host (or "bare") JID with no
  45. resource by delivering that message only to the resource with
  46. the highest priority for the target user. Some server
  47. implementations, however, have chosen to send these messages to all
  48. of the online resources for the target user. If the target user is
  49. online with multiple resources when the orginal message is sent, a
  50. conversation ensues on one of the user's devices; if the user
  51. subsequently switches devices, parts of the conversation may end up
  52. on the alternate device, causing the user to be confused, misled,
  53. or annoyed.</p>
  54. <p>This XEP proposes an approach for cleaning up the leftover
  55. conversation shards on alternate devices, paving the way for servers
  56. to deliver messages to multiple devices. As the basic approach, the
  57. receiving server asks all of the resources of a user "whose message
  58. is this?". The first resource to say "mine!" wins.</p>
  59. </section1>
  60. <section1 topic='Requirements' anchor='reqs'>
  61. <ul>
  62. <li>Large changes SHOULD NOT be required to existing servers</li>
  63. <li>Clients that do not implement the new protocol MUST be able
  64. participate in conversations</li>
  65. <li>All messages MUST NOT be delivered to all devices at all
  66. times, due to scale concerns</li>
  67. <li>Clients that do not own the message MUST be notified
  68. when a different device claims ownership of the message</li>
  69. <li>Multiple clients MUST be able to uambiguosly decide which of
  70. them owns a given message.</li>
  71. </ul>
  72. </section1>
  73. <section1 topic='Use Cases' anchor='usecases'>
  74. <section2 topic='Determining Support: Servers' anchor='disco_server'>
  75. <p>If a server implements the Mine capability, it MUST specify the
  76. 'urn:xmpp:tmp:mine:0' feature in its service discovery
  77. information features as specified in &xep0115; or &xep0030;.
  78. Clients MUST NOT send ownership changes if their server does
  79. not support this feature.</p>
  80. <example caption='Client requests information about its own server'><![CDATA[
  81. <iq type='get'
  82. from=''
  83. id='info1'>
  84. <query xmlns=''/>
  85. </iq>]]></example>
  86. <example caption='Server responds with mine feature'><![CDATA[
  87. <iq type='get'
  88. to=''
  89. from=''
  90. id='info1'>
  91. <query xmlns=''>
  92. ...
  93. <feature var='urn:xmpp:tmp:mine:0'/>
  94. ...
  95. </query>
  96. </iq>]]></example>
  97. </section2>
  98. <section2 topic='Determining Support: Clients' anchor='disco_client'>
  99. <p>Clients that support this protocol MUST support <cite>XEP-0115</cite>, and MUST add the
  100. 'urn:xmpp:tmp:mine:0' feature to their entity capabilities, in
  101. order to allow for potential server optimizations.</p>
  102. <example caption='Romeo publishes his capabilities'><![CDATA[
  103. <presence from=''>
  104. <c xmlns=''
  105. hash='sha-1'
  106. node=''
  107. ver='j+5eLRCz6NP6IEPob80JB6sWR3Y='/>
  108. </presence>
  109. ]]></example>
  110. <example caption='Romeo responds to capabilities inquiry from his server'><![CDATA[
  111. <iq from=''
  112. id='disco1'
  113. to=''
  114. type='result'>
  115. <query xmlns=''
  116. node=''>
  117. <identity category='client' type='pc' name='Mine'/>
  118. <feature var='urn:xmpp:tmp:mine:0'/>
  119. </query>
  120. </iq>]]></example>
  121. </section2>
  122. <section2 topic='Receving a message to the bare JID' anchor='receiving'>
  123. <p>When a server that implements the Mine capability receives a
  124. message addressed to a user's bare JID, it MUST:</p>
  125. <ul>
  126. <li>Ensure that no "whose" element is already on the message.
  127. See the <link url="#errors">Errors</link> section for processing.</li>
  128. <li>Add a whose element to the message, containing an id
  129. attribute with a new value</li>
  130. <li>Ensure that the the same value of the "id" attribute is
  131. never sent to the same session </li>
  132. </ul>
  133. <p>Messages that have been processed to include a valid "whose"
  134. element, are now also considered an "ownership request"</p>
  135. <example caption='Juliet sends Romeo an undirected message'><![CDATA[
  136. <message
  137. from=''
  138. to=''
  139. type='chat'>
  140. <body>Wherefore art thou, Romeo?</body>
  141. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  142. </message>
  143. ]]></example>
  144. <example caption='The ownership request, before broadcasting'><![CDATA[
  145. <message
  146. from=''
  147. to=''
  148. type='chat'>
  149. <body>Wherefore art thou, Romeo?</body>
  150. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  151. <whose xmlns='urn:xmpp:tmp:mine:0' id='4'/>
  152. </message>
  153. ]]></example>
  154. </section2>
  155. <section2 topic='Broadcasting ownership requests' anchor='broadcast'>
  156. <p>The receiving server MUST send a copy of the ownership request
  157. to each of that user's non-negative priority resources. Each copy
  158. of the message MUST contain a whose element, each of which has the
  159. same id attribute.</p>
  160. <example caption='Romeo&apos;s server forwards copies of the
  161. message to all of his resources'><![CDATA[
  162. <message
  163. from=''
  164. to=''
  165. type='chat'>
  166. <body>Wherefore art thou, Romeo?</body>
  167. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  168. <whose xmlns='urn:xmpp:tmp:mine:0' id='4'/>
  169. </message>
  170. <message
  171. from=''
  172. to=''
  173. type='chat'>
  174. <body>Wherefore art thou, Romeo?</body>
  175. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  176. <whose xmlns='urn:xmpp:tmp:mine:0' id='4'/>
  177. </message>
  178. <message
  179. from=''
  180. to=''
  181. type='chat'>
  182. <body>Wherefore art thou, Romeo?</body>
  183. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  184. <whose xmlns='urn:xmpp:tmp:mine:0' id='4'/>
  185. </message>
  186. ]]></example>
  187. </section2>
  188. <section2 topic='Claiming ownership' anchor='claim'>
  189. <p>When one client for a receiving user detects that the user's
  190. attention has been directed to a given message, that client MUST
  191. send an ownership claim (mine!) to the bare JID of the receiving
  192. user. If there was a thread element in the original message, it
  193. MUST be included in the acceptance notification. There MUST NOT
  194. be a body element in the message, and the message SHOULD use the
  195. same message type as the ownership request. The mine element MUST
  196. include an id element for each of the messages that the client
  197. wants to accept. The mine element MUST include at least one
  198. id.</p>
  199. <example caption='Romeo&apos;s &quot;work&quot; client claims ownership'><![CDATA[
  200. <message
  201. to=''
  202. from=''
  203. type='chat'>
  204. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  205. <mine xmlns='urn:xmpp:tmp:mine:0'>
  206. <id>4</id>
  207. </mine>
  208. </message>
  209. ]]></example>
  210. </section2>
  211. <section2 topic='Notification of ownership claim' anchor='notification'>
  212. <p>As with all messages sent to a bare JID at a server
  213. implementing the Mine feature, the acceptance message MUST be
  214. forwarded to all of the non-negative priority resources.</p>
  215. <example caption='Each of Romeo&apos;s clients receives the claim'><![CDATA[
  216. <message
  217. to=''
  218. from=''
  219. type='chat'>
  220. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  221. <mine xmlns='urn:xmpp:tmp:mine:0'>
  222. <id>4</id>
  223. </mine>
  224. </message>
  225. <message
  226. to=''
  227. from=''
  228. type='chat'>
  229. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  230. <mine xmlns='urn:xmpp:tmp:mine:0'>
  231. <id>4</id>
  232. </mine>
  233. </message>
  234. <message
  235. to=''
  236. from=''
  237. type='chat'>
  238. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  239. <mine xmlns='urn:xmpp:tmp:mine:0'>
  240. <id>4</id>
  241. </mine>
  242. </message>
  243. ]]></example>
  244. </section2>
  245. <section2 topic='Claim processing' anchor='processing'>
  246. <p>When a client receives an ownership claim that was sent from
  247. that client for an ID that has not been previously claimed,
  248. the client MUST note that the message associated with the ID has
  249. been confirmed, and ignore any further ownership claims for
  250. that ID.</p>
  251. <p>When a client receives an ownership claim that was sent from
  252. a different client of the same user for a ID that has not
  253. been previously received, the client MUST note that the message
  254. associated with the ID has been retracted, and ignore any further
  255. ownership claims for that ID. Retracted messages SHOULD
  256. be removed from the client's user interface, or otherwise marked
  257. in some way as retracted.</p>
  258. <p>Clients MUST ignore ownership claims for IDs for which they
  259. have no corresponding message.</p>
  260. <p>Assuming that messages are delivered and processed in order,
  261. these rules should ensure that exactly one client resource has a
  262. confirmed copy of the message</p>
  263. </section2>
  264. <section2 topic='Claims for Multi-User Chat rooms' anchor='muc'>
  265. <p>The same approach that has been described for one-to-one
  266. messages above can also be used by &xep0045; (MUC) rooms.
  267. Rooms that want to participate MUST send the
  268. 'urn:xmpp:tmp:mine:0' feature in the room's disco info. The room
  269. MUST then perform the role of the server in the above
  270. descriptions, ensuring that unique ID's are assigned to all
  271. outbound groupchat messages that were addressed to the bare JID of
  272. the room. Ownership claims MUST be sent to the bare JID of the
  273. <strong>room</strong>, not the receiving user.</p>
  274. <p>This capability might be used to distribute questions to
  275. multiple experts in a room, such that a single expert answers a
  276. question.</p>
  277. <example caption='Message is sent to the room'><![CDATA[
  278. <message
  279. from='hag66@shakespeare.lit/pda'
  280. to='darkcave@chat.shakespeare.lit'
  281. type='groupchat'>
  282. <body>Harpier cries: 'tis time, 'tis time.</body>
  283. </message>]]></example>
  284. <example caption='Room forwards message to all participants as ownership request'><![CDATA[
  285. <message
  286. from='darkcave@chat.shakespeare.lit/thirdwitch'
  287. to='crone1@shakespeare.lit/desktop'
  288. type='groupchat'>
  289. <body>Harpier cries: 'tis time, 'tis time.</body>
  290. <whose xmlns='urn:xmpp:tmp:mine:0' id='5'/>
  291. </message>
  292. <message
  293. from='darkcave@chat.shakespeare.lit/thirdwitch'
  294. to='wiccarocks@shakespeare.lit/laptop'
  295. type='groupchat'>
  296. <body>Harpier cries: 'tis time, 'tis time.</body>
  297. <whose xmlns='urn:xmpp:tmp:mine:0' id='5'/>
  298. </message>
  299. <message
  300. from='darkcave@chat.shakespeare.lit/thirdwitch'
  301. to='hag66@shakespeare.lit/pda'
  302. type='groupchat'>
  303. <body>Harpier cries: 'tis time, 'tis time.</body>
  304. <whose xmlns='urn:xmpp:tmp:mine:0' id='5'/>
  305. </message>
  306. ]]></example>
  307. <example caption='A participant claims ownership'><![CDATA[
  308. <message
  309. to='darkcave@chat.shakespeare.lit'
  310. from='crone1@shakespeare.lit/desktop'
  311. type='groupchat'>
  312. <mine xmlns='urn:xmpp:tmp:mine:0'>
  313. <id>5</id>
  314. </mine>
  315. </message>
  316. ]]></example>
  317. </section2>
  318. </section1>
  319. <section1 topic='Error Cases' anchor='errors'>
  320. <section2 topic='Invalid "whose"' anchor='bad_whose'>
  321. <p>A server receives a message addressed to the bare JID of a
  322. user, from a different user than the one in the to address,
  323. containing a "whose" or "mine" element, it MUST NOT forward the
  324. message on to any clients. This case is always either an attack,
  325. a misconfiguration, or the result of bad code. If the user in the
  326. from address is already known to the user in the to address (for
  327. example, to user in the to address has a presence subscription to
  328. the user in the from address), the server MAY send back a helpful
  329. "bad-request" error.</p>
  330. <example caption='Romeo responds to a bad request from his friend Juliet'><![CDATA[
  331. <message
  332. to=''
  333. from=''
  334. type='error>
  335. <thread>0e3141cd80894871a68e6fe6b1ec56fa</thread>
  336. <body>My client runneth over</body>
  337. <whose xmlns='urn:xmpp:tmp:mine:0' id='4'>
  338. <error type='modify'>
  339. <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  340. <text>Yours</text>
  341. </error>
  342. </message>
  343. ]]></example>
  344. <p>However, if the user in the from address is not known to the user
  345. in the to address, or the server perfers not to send helpful
  346. errors, the server MUST treat the message as if it was addressed
  347. to an unknown user. Otherwise, sending a message with an invalid
  348. "whose" or "mine" could allow an attacker to probe for valid users
  349. at a site.</p>
  350. </section2>
  351. </section1>
  352. <section1 topic='Business Rules' anchor='rules'>
  353. <section2 topic='Generating IDs' anchor='generate'>
  354. <p>The value of the id attribute sent by servers MUST be
  355. valid output from the NODEPREP profile of stringprep.</p>
  356. </section2>
  357. <section2 topic="ID Semantics" anchor="semantics">
  358. <p>The value of the id resource is completely opqaque;
  359. receiving clients MUST NOT use any apparent order or semantic in
  360. the value of the id to perform optimizations or business
  361. logic.</p>
  362. </section2>
  363. <section2 topic='Comparing IDs' anchor='compare'>
  364. <p>Clients MUST only compare the value of ID's for equality,
  365. never for order. ID's MUST be compared for equality
  366. octet-for-octet or codepoint-for-codepoint; a basic string
  367. comparison with no extra canonicalization.</p>
  368. </section2>
  369. <section2 topic='Accepting Multiple IDs' anchor='multiple'>
  370. <p>A client MAY send multiple id elements in an accceptance.
  371. Clients that receive a notification with multiple IDs MUST process
  372. each ID individually, as if multiple claims had been sent.</p>
  373. </section2>
  374. <section2 topic='When to send?' anchor='when'>
  375. <p>To avoid race conditions and edge cases (including
  376. invisibility), if both the client and server support the Mine
  377. capability, the client SHOULD send ownership queries regardless
  378. of whether or not the client sees other resources for the same
  379. user online, or the capabilities of those other resources.</p>
  380. </section2>
  381. <section2 topic='Legacy Clients' anchor='unsupported_clients'>
  382. <p>Clients that do not implement the Mine capability MAY be sent
  383. notifications by the server. The server MAY be optimized to
  384. avoid these notifications, however.</p>
  385. </section2>
  386. </section1>
  387. <section1 topic='Implementation Notes' anchor='impl'>
  388. <p>Some examples of events that might lead to a client sending an
  389. ownsership claim:</p>
  390. <ul>
  391. <li>Clicking on a toast notification for the message</li>
  392. <li>Bringing the client window to the front within a short time
  393. after receiving the message, where the message is then displayed
  394. to the user</li>
  395. <li>Bringing the tab containing the message to the front</li>
  396. <li>Beginning to type a response to the message</li>
  397. <li>Closing the window containing the message at least several
  398. seconds after the message was received</li>
  399. <li>Clicking an accept button next to a message</li>
  400. <li>Shutting down the screen saver while the message is in the
  401. top-most window</li>
  402. <li>A camera notices the user's eyes directed at the message</li>
  403. </ul>
  404. </section1>
  405. <section1 topic='Accessibility Considerations' anchor='access'>
  406. <p>Some care should be given to the events that can cause ownsership
  407. claims, particularly in the MUC client implementations, such that
  408. users with different abilities all have a chance to claim ownership.</p>
  409. </section1>
  410. <section1 topic='Security Considerations' anchor='security'>
  411. <p>Clients MUST ignore acceptance notifications received from other users.</p>
  412. </section1>
  413. <section1 topic='IANA Considerations' anchor='iana'>
  414. <p>This document requires no interaction with &IANA;.</p>
  415. </section1>
  416. <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  417. <p>This XEP proposes the new namespace 'urn:xmpp:tmp:mine:0'.</p>
  418. </section1>
  419. <section1 topic='XML Schema' anchor='schema'>
  420. <code><![CDATA[
  421. <?xml version='1.0' encoding='UTF-8' ?>
  422. <xs:schema
  423. xmlns:xs=''
  424. targetNamespace='urn:xmpp:tmp:mine:0'
  425. xmlns='urn:xmpp:tmp:mine:0'
  426. elementFormDefault='qualified'>
  427. <xs:element name='whose'>
  428. <xs:complexType>
  429. <xs:attribute name='id' type='xs:string' use='required'/>
  430. </xs:complexType>
  431. </xs:element>
  432. <xs:element name='mine'>
  433. <xs:complexType>
  434. <xs:sequence>
  435. <xs:element ref='id' minOccurs='1' maxOccurs='unbounded'/>
  436. </xs:sequence>
  437. </xs:complexType>
  438. </xs:element>
  439. <xs:element name='id'>
  440. <xs:complexType>
  441. <xs:simpleContent>
  442. <xs:extension base='xs:NMTOKEN'/>
  443. </xs:simpleContent>
  444. </xs:complexType>
  445. </xs:element>
  446. </xs:schema>
  447. ]]></code>
  448. </section1>
  449. </xep>