| blob | f0cbda988a01273fb96429ef05f54a12076d1692 |
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-loose.dtd">
4 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>XEP-0144: Roster Item Exchange</title><link rel="stylesheet" type="text/css" href="xep-0144_soubory/xmpp.css"><link rel="shortcut icon" type="image/x-icon" href="http://xmpp.org/favicon.ico"><meta name="DC.Title" content="Roster Item Exchange"><meta name="DC.Creator" content="Peter Saint-Andre"><meta name="DC.Description" content="This specification defines an XMPP protocol extension for exchanging contact list items, including the ability to suggest whether the item is to be added, deleted, or modified in the contact list of the recipient, as well as the suggested roster group for the item."><meta name="DC.Publisher" content="XMPP Standards Foundation"><meta name="DC.Contributor" content="XMPP Extensions Editor"><meta name="DC.Date" content="2005-08-26"><meta name="DC.Type" content="XMPP Extension Protocol"><meta name="DC.Format" content="XHTML"><meta name="DC.Identifier" content="XEP-0144"><meta name="DC.Language" content="en"><meta name="DC.Rights" content="This XMPP Extension Protocol is copyright © 1999 - 2009 by the XMPP Standards Foundation (XSF)."></head><body><h1>XEP-0144: Roster Item Exchange</h1><table><tbody><tr valign="top"><td><strong>Abstract:</strong></td><td>This
5 specification defines an XMPP protocol extension for exchanging contact
6 list items, including the ability to suggest whether the item is to be
7 added, deleted, or modified in the contact list of the recipient, as
8 well as the suggested roster group for the item.</td></tr><tr valign="top"><td><strong>Author:</strong></td><td>Peter Saint-Andre</td></tr><tr valign="top"><td><strong>Copyright:</strong></td><td>© 1999 - 2009 XMPP Standards Foundation. <a href="#appendix-legal">SEE LEGAL NOTICES</a>.</td></tr><tr valign="top"><td><strong>Status:</strong></td><td>Draft</td></tr><tr valign="top"><td><strong>Type:</strong></td><td>Standards Track</td></tr><tr valign="top"><td><strong>Version:</strong></td><td>1.0</td></tr><tr valign="top"><td><strong>Last Updated:</strong></td><td>2005-08-26</td></tr></tbody></table><hr><p style="color: green;">NOTICE:
9 The protocol defined herein is a Draft Standard of the XMPP Standards
10 Foundation. Implementations are encouraged and the protocol is
11 appropriate for deployment in production systems, but some changes to
12 the protocol are possible before it becomes a Final Standard.</p><hr><h2>Table of Contents</h2><div class="indent"><p><br>1. <a href="#intro">Introduction</a><br>2. <a href="#reqs">Requirements</a><br>3. <a href="#usecases">Use Cases</a><br>
15 3.3. <a href="#modify">Suggesting Roster Item Modification</a><br>4. <a href="#disco">Service Discovery</a><br>5. <a href="#stanza">Recommended Stanza Type</a><br>
16 5.1. <a href="#stanza-iq">IQ Semantics</a><br>6. <a href="#bizrules">Business Rules</a><br>7. <a href="#entities">Types of Sending Entities</a><br>
19 7.3. <a href="#entities-groupservice">Group Services</a><br>8. <a href="#security">Security Considerations</a><br>
22 8.3. <a href="#security-support">Advertising Support</a><br>9. <a href="#iana">IANA Considerations</a><br>10. <a href="#registrar">XMPP Registrar Considerations</a><br>
24 10.2. <a href="#registrar-disco">Service Discovery Identities</a><br>11. <a href="#schema">XML Schema</a></p><p><a href="#appendices">Appendices</a><br> <a href="#appendix-docinfo">A: Document Information</a><br> <a href="#appendix-authorinfo">B: Author Information</a><br> <a href="#appendix-legal">C: Legal Notices</a><br> <a href="#appendix-xmpp">D: Relation to XMPP</a><br> <a href="#appendix-discuss">E: Discussion Venue</a><br> <a href="#appendix-conformance">F: Requirements Conformance</a><br> <a href="#appendix-notes">G: Notes</a><br> <a href="#appendix-revs">H: Revision History</a></p></div><hr><h2>1.
27 Jabber protocols have long included a method for sending roster items
28 from one entity to another, making use of the 'jabber:x:roster'
29 namespace. Because this protocol extension was not required by <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc2779">RFC 2779</a></span> [<a href="#nt-id2251511">1</a>], it was removed from <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc3921">XMPP IM</a></span> [<a href="#nt-id2251676">2</a>] and documented for historical purposes in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0093.html">Roster Item Exchange</a></span> [<a href="#nt-id2251703">3</a>]. However, since that time discussions in the <span class="ref" style=""><a href="http://mail.jabber.org/mailman/listinfo/standards/">Standards SIG</a></span> [<a href="#nt-id2251730">4</a>]
30 have revealed that it would be helpful to use roster item exchange in
31 the problem spaces of "shared groups" (e.g., predefined roster groups
32 used within an organization) and roster synchronization (e.g., keeping
33 a Jabber roster in sync with a contact list on a legacy IM service).
34 These problem spaces require a slightly more sophisticated kind of
35 roster item exchange than was documented in XEP-0093, specifically the
36 ability to indicate whether a roster item is to be added, deleted, or
37 modified. Therefore this document redefines roster item exchange to
38 provide this functionality in a way that is backwards-compatible with
39 existing implementations, albeit using a modern namespace URI of
40 'http://jabber.org/protocol/rosterx' rather than the old
41 'jabber:x:roster' namespace name. Further specifications will define
42 how to solve the problems of shared groups and roster synchronization
43 using the protocol defined herein.</p>
46 <p class="" style="">XEP-0093 did not define the requirements for roster item exchange. This section remedies that oversight.</p>
50 an entity to send one or more roster items to another entity, with the
51 suggestion that the roster item(s) be added to the recipient's roster.</li>
53 an entity to send one or more roster items to another entity, with the
54 suggestion that the roster item(s) be deleted from the recipient's
55 roster.</li>
57 more roster items to another entity, with the suggestion that the
58 roster item(s) be modified in the recipient's roster.</li>
59 </ol>
61 document deliberately speaks of rosters and roster items, not presence
62 subscriptions. Although rosters and subscriptions are closely connected
64 identical. The protocol defined herein enables an entity to suggest
65 that another entity might want to add, delete, or modify roster items
66 only, and does not dictate the suggested presence subscription state
67 associated with those roster items. This is intentional.</p>
72 order to programatically suggest that the receiving entity should add
73 one or more items to its roster, the sending entity MUST send a
75 qualified by the 'http://jabber.org/protocol/rosterx' namespace (see <a href="#stanza">Recommended Stanza Type</a>
78 child elements, each of which SHOULD possess an 'action' attribute
80 'jid' attribute that specifies the JabberID of the item to be added,
81 MAY possess a 'name' attribute that specifies a natural-language name
83 elements specifying roster groups into which to place the item. If a
85 but SHOULD NOT contain any other child elements. Here is an example:</p>
86 <p class="caption"><a name="example-1" id="example-1"></a>Example 1. Suggesting Addition</p><div class="indent"><pre><message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
89 <item action='add'
90 jid='rosencrantz@denmark.lit'
91 name='Rosencrantz'>
94 <item action='add'
95 jid='guildenstern@denmark.lit'
96 name='Guildenstern'>
101 </pre></div>
103 determining how to handle any given roster item whose 'action'
104 attribute has a value of "add" (either explicitly or as the default
105 value), the receiving application SHOULD proceed as follows:</p>
108 the item already exists in the roster and the item is in the specified
109 group (or no group is specified), the receiving application MUST NOT
110 prompt a human user for approval regarding that item and MUST NOT add
111 that item to the roster.</li>
113 does not already exist in the roster, the receiving application SHOULD
114 prompt a human user for approval regarding that item and, if approval
115 is granted, MUST add that item to the roster.</li>
117 the item already exists in the roster but not in the specified group,
118 the receiving application MAY prompt the user for approval and SHOULD
119 edit the existing item so that will also belong to the specified group
120 (in addition to the existing group, if any).</li>
121 </ol>
123 the roster item addition stanza will result in adding the item to the
124 roster, the receiving application MUST (either with approval by a human
125 user or automatically subject to configuration) send a roster set to
127 After completing the roster set, the receiving application SHOULD also
129 new item.</p>
131 recommended application behavior when a roster item addition stanza
132 actually results in editing of an existing roster item, refer to the <a href="#modify">Suggesting Roster Item Modification</a> section of this document.</p>
133 </div>
134 <div class="indent"><h3>3.2 <a name="delete" id="delete">Suggesting Roster Item Deletion</a></h3>
136 order to programatically suggest that the receiving entity should
137 delete one or more items from its roster, the sending entity MUST send
139 element qualified by the 'http://jabber.org/protocol/rosterx'
142 attribute whose value is "delete", MUST possess a 'jid' attribute that
143 specifies the JabberID of the item to be deleted, MAY possess a 'name'
144 attribute that specifies a natural-language name or nickname for the
148 child elements. Here is an example:</p>
149 <p class="caption"><a name="example-2" id="example-2"></a>Example 2. Suggesting Deletion</p><div class="indent"><pre><message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
151 <item action='delete'
152 jid='rosencrantz@denmark'
153 name='Rosencrantz'>
156 <item action='delete'
157 jid='guildenstern@denmark'
158 name='Guildenstern'>
163 </pre></div>
165 determining how to handle any given roster item whose 'action'
166 attribute has a value of "delete", the receiving application SHOULD
167 proceed as follows:</p>
170 the item does not exist in the roster, the receiving application MUST
171 NOT prompt a human user for approval regarding that item and MUST NOT
172 delete that item from the roster.</li>
174 the item exists in the roster but not in the specified group, the
175 receiving application MUST NOT prompt the user for approval and MUST
176 NOT delete the existing item.</li>
178 item exists in the roster and is in both the specified group and
179 another group, the receiving application MAY prompt the user for
180 approval and SHOULD edit the existing item so that it no longer belongs
181 to the specified group.</li>
182 </ol>
184 item is to be deleted, the receiving application SHOULD remove the item
185 from the roster by sending a roster set to the user's server with the
186 'subscription' attribute set to a value of "remove" as described in <span class="ref">RFC 3921</span>, since this results in generation of the appropriate <presence/> stanzas by the user's server.</p>
187 </div>
188 <div class="indent"><h3>3.3 <a name="modify" id="modify">Suggesting Roster Item Modification</a></h3>
190 order to programatically suggest that the receiving entity should
191 modify one or more items from its roster, the sending entity MUST send
193 element qualified by the 'http://jabber.org/protocol/rosterx'
196 attribute whose value is "modify", MUST possess a 'jid' attribute that
197 specifies the JabberID of the item to be modified, MAY possess a 'name'
198 attribute that specifies a natural-language name or nickname for the
202 contain any other child elements. Here is an example:</p>
203 <p class="caption"><a name="example-3" id="example-3"></a>Example 3. Suggesting Modification</p><div class="indent"><pre><message from='horatio@denmark.lit' to='hamlet@denmark.lit'>
205 <item action='modify'
206 jid='rosencrantz@denmark.lit'
207 name='Rosencrantz'>
210 <item action='modify'
211 jid='guildenstern@denmark.lit'
212 name='Guildenstern'>
217 </pre></div>
219 determining how to handle any given roster item whose 'action'
220 attribute has a value of "modify", the receiving application SHOULD
221 proceed as follows:</p>
224 the item does not exist in the roster, the receiving application MUST
225 NOT prompt a human user for approval regarding that item and MUST NOT
226 add that item to the roster.</li>
228 item exists in the roster and the modification results in a change of
229 group only, the receiving application MAY prompt the user for approval
230 and SHOULD move the item to the specified group.</li>
232 the item exists in the roster and the modification results in adding
233 the item to a new group in addition to its existing group, the
234 receiving application MAY prompt the user for approval and SHOULD add
235 the item to the specified group.</li>
237 the item exists in the roster and the modification results in a change
238 of name only, the receiving application MAY prompt the user for
239 approval and SHOULD modify the name to that specified in the
240 modification suggestion.</li>
241 </ol>
243 roster item addition, deletion, or modification stanza will result in
244 editing of an existing item in the roster, the receiving application
245 MUST (either with approval by a human user or automatically subject to
246 configuration) send a roster set to the user's server with no changes
247 to the 'subscription' attribute but rather with appropriate changes to
250 </div>
253 <p class="" style="">In order to determine whether a receiving entity supports the protocol defined herein, the sending entity SHOULD use <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0030.html">Service Discovery</a></span> [<a href="#nt-id2262769">6</a>] but MAY depend on the "profile" of Service Discovery defined in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0115.html">Entity Capabilities</a></span> [<a href="#nt-id2262795">7</a>]. If an entity supports roster item exchange, it MUST (subject to appropriate security considerations as described under <a href="#security-support">Advertising Support</a>)
255 its responses to disco#info queries. Thus a sending entity can discover
256 if a receiving entity supports the protocol defined herein by sending
257 an IQ request of the following form:</p>
258 <p class="caption"><a name="example-4" id="example-4"></a>Example 4. Sending Entity Queries for Support</p><div class="indent"><pre><iq from='horatio@denmark.lit/castle'
259 to='hamlet@denmark.lit/throne'
260 type='get'
261 id='disco1'>
264 </pre></div>
266 <p class="caption"><a name="example-5" id="example-5"></a>Example 5. Receiving Entity Advertises Support</p><div class="indent"><pre><iq from='hamlet@denmark.lit/throne'
267 to='horatio@denmark.lit/castle'
268 type='get'
269 id='disco1'>
271 ...
273 ...
276 </pre></div>
280 the sending entity has knowledge (e.g., via presence or an active chat
281 conversation) that the receiving entity is online and available, it
284 <li class="" style="">Discover if the receiving entity supports the protocol defined herein (see the <a href="#disco">Service Discovery</a> section of this document).</li>
286 so, send its roster item exchange stanza to a particular resource
289 </ol>
291 the sending entity does not know that the receiving entity is online
294 particular resource.</p>
298 item exchange suggestions, the receiving entity MUST adhere to the IQ
299 semantics defined in <span class="ref" style=""><a href="http://tools.ietf.org/html/rfc3920">XMPP Core</a></span> [<a href="#nt-id2262953">9</a>]. Specifically:</p>
302 the receiving entity successfully processes the suggested action(s)
303 (which may include ignoring certain suggestions), the receiving entity
304 MUST return an empty IQ result to the sending entity.</li>
306 the receiving entity does not understand the roster item exchange
307 namespace, the receiving entity MUST return an error to the sending
310 the receiving entity will not process the suggested action(s) because
311 the receiving entity is not registered with the sending entity, the
312 receiving entity MUST return an error to the sending entity, which
315 the receiving entity will not process the suggested action(s) because
316 the sending entity is not in the receiving entity's roster, the
317 receiving entity MUST return an error to the sending entity, which
319 <li class="" style="">If the receiving entity will not process the suggested action(s) because the sending entity is not trusted (see <a href="#security-trust">Trusted Entities</a>), the receiving entity MUST return an error to the sending entity, which error SHOULD be <forbidden/>.</li>
320 </ol>
322 other IQ errors may be more appropriate; however, if the receiving
323 entity will not or cannot process the suggested action(s), it MUST
324 return an error to the sending entity.</p>
325 </div>
330 sending entity or sending application MUST NOT send additions,
333 separate stanzas for the additions, deletions, and modifications.</p></li>
335 approval is required or recommended regarding more than one item
336 suggested by the sending entity, the receiving entity SHOULD present
337 all of the items for approval at the same time or in the same interface.</p></li>
338 <li class="" style=""><p class="" style="">If the sending entity is in some sense "trusted" (see <a href="#security-trust">Trusted Entities</a>), then the receiving application MAY skip the approval steps described above.</p></li>
340 receiving application SHOULD NOT accept an unreasonable number of
341 roster items from any one sending entity at one time. Unfortunately, it
342 can be difficult to determine how many roster items count as
343 "unreasonable". For example, when a user registers with a gateway, it
344 is possible that the initial set of roster items may be quite large
345 (however, note that most existing consumer IM services enforce a limit
347 registered with or been newly created on a server (e.g., within an
348 organization) may also receive a large set of initial roster items in
349 order to sync up with shared groups established on the server. However,
350 after such initialization, the subsequent roster item sets should be
352 SHOULD be treated with suspicion, and entities that repeatedly send
353 such sets SHOULD NOT be trusted.</p></li>
354 </ol>
358 foregoing protocol description speaks only of "sending entities" and
359 does not differentiate between different types of sending entities.
360 However, it is envisioned that roster items will be sent to receiving
361 entities by three different kinds of senders:</p>
366 </ol>
370 item exchange as developed within the early Jabber community and
371 documented in XEP-0093 was used to send a roster item from one user to
372 another in a manner more structured than simply typing a third party's
373 JID in a chat window. This usage is still encouraged. However, if the
374 sender is a human user and/or the sending application has a primary <span class="ref">Service Discovery</span> category of "client" (e.g., a bot) [<a href="#nt-id2263230">10</a>],
375 the sending application SHOULD NOT specify an 'action' attribute other
376 than "add", the receiving application MAY ignore values of the 'action'
377 attribute other than "add", and the receiving application MUST prompt a
378 human user regarding whether to add the suggested item or items to the
379 user's roster.</p>
380 </div>
382 <p class="" style="">The nature of client proxy gateways (i.e., entities with a service discovery category of "gateway") is specified more fully in <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0100.html">Gateway Interaction</a></span> [<a href="#nt-id2263287">11</a>].
383 Herein we describe how such gateways should use roster item exchange,
384 and how receiving applications should treat roster items received from
385 such gateways.</p>
387 gateway's protocol translation service, a user MUST first register with
388 the gateway. If the gateway advertises support for a service discovery
389 feature of 'http://jabber.org/protocol/rosterx', then the user's client
390 SHOULD expect that it may receive roster item suggestions from the
391 gateway. In order to maintain synchronization between the user's
392 contact list on a legacy IM service and the user's Jabber roster, the
393 gateway SHOULD send roster items with an 'action' attribute of "add",
395 SHOULD process such roster item suggestions. Such processing MAY occur
396 automatically (i.e., without the user's approval of each roster item or
397 batch of roster items) if and only if the receiving application has
398 explicitly informed the user that it will automatically process roster
399 items from the gateway. Furthermore, the receiving application SHOULD
400 periodically verify automatic processing with the user (e.g., once per
401 session in which the gateway sends roster item suggestions to the user).</p>
402 </div>
403 <div class="indent"><h3>7.3 <a name="entities-groupservice" id="entities-groupservice">Group Services</a></h3>
405 is a third category of entities that might initiate roster item
406 exchanges, which we label a "group service" and identify by a <span class="ref">Service Discovery</span>
408 administrator to centrally define and administer roster groups so that
409 they can be shared among a user population in an organized fashion.
410 Such a service could prove useful in enterprise environments [<a href="#nt-id2263339">12</a>] and other settings where it is
411 beneficial to synchronize rosters across individuals (e.g., schools,
412 social networking applications, consumer IM services, and anywhere else
413 that it is important to build and manage small communities of users).</p>
415 some contexts, an IM server could function as a group service (e.g., if
416 there is a single server deployed on a small company intranet); in
417 other contexts, it may make more sense to deploy a standalone group
418 service (e.g., in a larger or more heterogeneous environment with users
419 on multiple servers). In both cases, the group service MUST advertise a
420 service discovery identity of "directory/group" and SHOULD use the
422 "modify") to the relevant shared groups; in addition, a user MUST first
423 register with the service (either over Jabber via <span class="ref" style=""><a href="http://xmpp.org/extensions/xep-0077.html">In-Band Registration</a></span> [<a href="#nt-id2263438">13</a>]
424 or out of band, e.g., via the web) or be otherwise provisioned to use
425 the service (e.g., by a system administrator) before accepting roster
426 item suggestions from the service.</p>
428 user has registered with a group service or been otherwise provisioned
429 to use a group service, the receiving application SHOULD process roster
430 item suggestions received from the service. Such processing MAY occur
431 automatically (i.e., without the user's approval of each roster item or
432 batch of roster items) if and only if the receiving application has
433 explicitly informed the user that it will automatically process roster
434 items from the service. Furthermore, the receiving application SHOULD
435 periodically verify automatic processing with the user (e.g., once per
436 session in which the service sends roster item suggestions to the user).</p>
437 </div>
440 <div class="indent"><h3>8.1 <a name="security-trust" id="security-trust">Trusted Entities</a></h3>
442 principal (user) or receiving application MAY establish a list of
443 trusted entities from which roster item exchanges are processed
444 automatically, i.e., without explicit approval by a human user. In
445 order to avoid corruption of the roster, it is STRONGLY RECOMMENDED
446 that such trusted entities be limited to gateways and group services as
447 defined above. In addition, the receiving application SHOULD
448 periodically verify such automatic processing with the principal, e.g.,
449 once per session in which the trusted entity sends roster item
450 suggestions to the user.</p>
451 </div>
454 sending entity could effectively deny service to the receiving entity
455 by rapidly and repeatedly sending (1) alternating add and delete
456 suggestions or (2) modify suggestions, thus invoking throttling
457 mechanisms enforced by the receiving entity's server. The receiving
458 application SHOULD guard against this by monitoring roster item
459 exchanges received from each sending entity and refusing or ignoring
460 roster item exchanges from offending entities (e.g., by adding such
461 entities to a list of distrusted entities).</p>
462 </div>
463 <div class="indent"><h3>8.3 <a name="security-support" id="security-support">Advertising Support</a></h3>
464 <p class="" style="">A receiving application MAY refuse to advertise its support for the roster item exchange protocol (see the <a href="#disco">Service Discovery</a> section of this document) to entities that that are (1) not explicitly trusted or (2) explicitly distrusted.</p>
465 </div>
468 <p class="" style="">This document requires no interaction with the <span class="ref" style=""><a href="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a></span> [<a href="#nt-id2263540">14</a>].</p>
471 <div class="indent"><h3>10.1 <a name="registrar-ns" id="registrar-ns">Protocol Namespaces</a></h3>
472 <p class="" style="">The <span class="ref" style=""><a href="http://xmpp.org/registrar/">XMPP Registrar</a></span> [<a href="#nt-id2263591">15</a>] includes 'http://jabber.org/protocol/rosterx' in its registry of protocol namespaces.</p>
473 </div>
474 <div class="indent"><h3>10.2 <a name="registrar-disco" id="registrar-disco">Service Discovery Identities</a></h3>
475 <p class="" style="">The XMPP Registrar includes a <span class="ref">Service Discovery</span> type of "group" under the "directory" category in its registry of service discovery identities.</p>
476 </div>
481 <xs:schema
482 xmlns:xs='http://www.w3.org/2001/XMLSchema'
483 targetNamespace='http://jabber.org/protocol/rosterx'
484 xmlns='http://jabber.org/protocol/rosterx'
485 elementFormDefault='qualified'>
489 The protocol documented by this schema is defined in
522 </pre></div>
523 <hr><a name="appendices" id="appendices"></a><h2>Appendices</h2><hr><a name="appendix-docinfo" id="appendix-docinfo"></a><h3>Appendix A: Document Information</h3><p class="indent">
527 Status:
529 Type:
530 <a href="http://www.xmpp.org/extensions/xep-0001.html#types-Standards%20Track">Standards Track</a><br>
533 Approving Body: <a href="http://www.xmpp.org/council/">XMPP Council</a><br>Dependencies: XMPP Core, XMPP IM<br>Supersedes: XEP-0093<br>
534 Superseded By: None<br>
535 Short Name: rosterx<br>
536 Schema: <<a href="http://www.xmpp.org/schemas/rosterx.xsd">http://www.xmpp.org/schemas/rosterx.xsd</a>><br>
537 Source Control:
538 <a class="standardsButton" href="http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0144.xml">HTML</a>
539 <a class="standardsButton" href="http://svn.xmpp.org:18080//changelog/%7Erss/XMPP/trunk/extensions/xep-0144.xml/rss.xml">RSS</a></p><hr><a name="appendix-authorinfo" id="appendix-authorinfo"></a><h3>Appendix B: Author Information</h3><div class="indent"><h3>Peter Saint-Andre</h3><p class="indent">
540 JabberID:
542 URI:
543 <a href="https://stpeter.im/">https://stpeter.im/</a><br></p></div><hr><a name="appendix-legal" id="appendix-legal"></a><h3>Appendix C: Legal Notices</h3><div class="indent"><h4>Copyright</h4>This XMPP Extension Protocol is copyright © 1999 - 2009 by the <a href="http://xmpp.org/">XMPP Standards Foundation</a> (XSF).<h4>Permissions</h4>Permission
544 is hereby granted, free of charge, to any person obtaining a copy of
545 this specification (the "Specification"), to make use of the
546 Specification without restriction, including without limitation the
547 rights to implement the Specification in a software program, deploy the
548 Specification in a network service, and copy, modify, merge, publish,
549 translate, distribute, sublicense, or sell copies of the Specification,
550 and to permit persons to whom the Specification is furnished to do so,
551 subject to the condition that the foregoing copyright notice and this
552 permission notice shall be included in all copies or substantial
553 portions of the Specification. Unless separate permission is granted,
554 modified works that are redistributed shall not contain misleading
555 information regarding the authors, title, number, or publisher of the
556 Specification, and shall not claim endorsement of the modified works by
557 the authors, any organization or project to which the authors belong,
558 or the XMPP Standards Foundation.<h4>Disclaimer of Warranty</h4><span style="font-weight: bold;">##
559 NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT
560 WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including,
561 without limitation, any warranties or conditions of TITLE,
562 NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
563 In no event shall the XMPP Standards Foundation or the authors of this
564 Specification be liable for any claim, damages, or other liability,
565 whether in an action of contract, tort, or otherwise, arising from, out
566 of, or in connection with the Specification or the implementation,
568 no event and under no legal theory, whether in tort (including
569 negligence), contract, or otherwise, unless required by applicable law
570 (such as deliberate and grossly negligent acts) or agreed to in
571 writing, shall the XMPP Standards Foundation or any author of this
572 Specification be liable for damages, including any direct, indirect,
573 special, incidental, or consequential damages of any character arising
574 out of the use or inability to use the Specification (including but not
575 limited to damages for loss of goodwill, work stoppage, computer
576 failure or malfunction, or any and all other commercial damages or
577 losses), even if the XMPP Standards Foundation or such author has been
579 XMPP Extension Protocol has been contributed in full conformance with
580 the XSF's Intellectual Property Rights Policy (a copy of which may be
581 found at <<a href="http://xmpp.org/extensions/ipr-policy.shtml">http://xmpp.org/extensions/ipr-policy.shtml</a>> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</div><hr><a name="appendix-xmpp" id="appendix-xmpp"></a><h3>Appendix D: Relation to XMPP</h3><p class="indent">The
582 Extensible Messaging and Presence Protocol (XMPP) is defined in the
584 by the XMPP Standards Foundation to the Internet Standards Process,
585 which is managed by the Internet Engineering Task Force in accordance
586 with RFC 2026. Any protocol defined in this document has been developed
587 outside the Internet Standards Process and is to be understood as an
588 extension to XMPP rather than as an evolution, development, or
589 modification of XMPP itself.</p><hr><a name="appendix-discuss" id="appendix-discuss"></a><h3>Appendix E: Discussion Venue</h3><p class="indent">The primary venue for discussion of XMPP Extension Protocols is the <<a href="http://mail.jabber.org/mailman/listinfo/standards">standards@xmpp.org</a>> discussion list.</p><p class="indent">Discussion on other xmpp.org discussion lists might also be appropriate; see <<a href="http://xmpp.org/about/discuss.shtml">http://xmpp.org/about/discuss.shtml</a>> for a complete list.</p><p class="indent">Errata may be sent to <<a href="mailto:editor@xmpp.org">editor@xmpp.org</a>>.</p><hr><a name="appendix-conformance" id="appendix-conformance"></a><h3>Appendix F: Requirements Conformance</h3><p class="indent">The following requirements keywords as used in this document are to be interpreted as described in <a href="http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>:
591 "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".</p><hr><a name="appendix-notes" id="appendix-notes"></a><h3>Appendix G: Notes</h3><div class="indent"><p><a name="nt-id2251511" id="nt-id2251511">1</a>. RFC 2779: A Model for Presence and Instant Messaging <<a href="http://tools.ietf.org/html/rfc2779">http://tools.ietf.org/html/rfc2779</a>>.</p><p><a name="nt-id2251676" id="nt-id2251676">2</a>. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <<a href="http://tools.ietf.org/html/rfc3921">http://tools.ietf.org/html/rfc3921</a>>.</p><p><a name="nt-id2251703" id="nt-id2251703">3</a>. XEP-0093: Roster Item Exchange <<a href="http://xmpp.org/extensions/xep-0093.html">http://xmpp.org/extensions/xep-0093.html</a>>.</p><p><a name="nt-id2251730" id="nt-id2251730">4</a>.
592 The Standards SIG is a standing Special Interest Group devoted to
593 development of XMPP Extension Protocols. The discussion list of the
594 Standards SIG is the primary venue for discussion of XMPP protocol
595 extensions, as well as for announcements by the XMPP Extensions Editor
596 and XMPP Registrar. To subscribe to the list or view the list archives,
597 visit <<a href="http://mail.jabber.org/mailman/listinfo/standards/">http://mail.jabber.org/mailman/listinfo/standards/</a>>.</p><p><a name="nt-id2251653" id="nt-id2251653">5</a>.
598 The default value of the 'action' attribute is "add"; therefore, if the
599 'action' attribute is not included or the receiving application does
600 not understand the 'action' attribute, the receiving application MUST
601 treat the item as if the value were "add".</p><p><a name="nt-id2262769" id="nt-id2262769">6</a>. XEP-0030: Service Discovery <<a href="http://xmpp.org/extensions/xep-0030.html">http://xmpp.org/extensions/xep-0030.html</a>>.</p><p><a name="nt-id2262795" id="nt-id2262795">7</a>. XEP-0115: Entity Capabilities <<a href="http://xmpp.org/extensions/xep-0115.html">http://xmpp.org/extensions/xep-0115.html</a>>.</p><p><a name="nt-id2262856" id="nt-id2262856">8</a>.
602 If the receiving entity has more than one available resource, the
603 sending application SHOULD communicate with the "most available"
604 resource according its best estimation (e.g., the resource with the
605 highest priority).</p><p><a name="nt-id2262953" id="nt-id2262953">9</a>. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <<a href="http://tools.ietf.org/html/rfc3920">http://tools.ietf.org/html/rfc3920</a>>.</p><p><a name="nt-id2263230" id="nt-id2263230">10</a>. See <<a href="http://www.xmpp.org/registrar/disco-categories.html#client">http://www.xmpp.org/registrar/disco-categories.html#client</a>>.</p><p><a name="nt-id2263287" id="nt-id2263287">11</a>. XEP-0100: Gateway Interaction <<a href="http://xmpp.org/extensions/xep-0100.html">http://xmpp.org/extensions/xep-0100.html</a>>.</p><p><a name="nt-id2263339" id="nt-id2263339">12</a>.
606 For example, when Alice is hired by the marketing department of Big
607 Company Enterprises, it makes sense for her to automatically have the
608 other members of the marketing department in her roster the first time
609 she logs in, and for the rest of the marketing department to have Alice
610 in their rosters as soon as her account has been set up. Similarly,
611 when Bob in logistics gets fired, it makes sense for him to disappear
612 from the rosters of everyone else in the logistics department.</p><p><a name="nt-id2263438" id="nt-id2263438">13</a>. XEP-0077: In-Band Registration <<a href="http://xmpp.org/extensions/xep-0077.html">http://xmpp.org/extensions/xep-0077.html</a>>.</p><p><a name="nt-id2263540" id="nt-id2263540">14</a>.
613 The Internet Assigned Numbers Authority (IANA) is the central
614 coordinator for the assignment of unique parameter values for Internet
615 protocols, such as port numbers and URI schemes. For further
616 information, see <<a href="http://www.iana.org/">http://www.iana.org/</a>>.</p><p><a name="nt-id2263591" id="nt-id2263591">15</a>.
617 The XMPP Registrar maintains a list of reserved protocol namespaces as
618 well as registries of parameters used in the context of XMPP extension
619 protocols approved by the XMPP Standards Foundation. For further
620 information, see <<a href="http://xmpp.org/registrar/">http://xmpp.org/registrar/</a>>.</p></div><hr><a name="appendix-revs" id="appendix-revs"></a><h3>Appendix H: Revision History</h3><div class="indent"><h4>Version 1.0 (2005-08-26)</h4><div class="indent">Per a vote of the Jabber Council, advanced status to Draft. (psa)
622 Council feedback: specified that a body MAY be included when sending a
623 message stanza; changed prohibition on mixing of additions, deletions,
624 and modifications from SHOULD NOT to MUST NOT; clarified status of bots
625 as sending entities. (psa) </div><h4>Version 0.5 (2005-07-26)</h4><div class="indent">Reverted roster item deletion changes. (psa)
626 </div><h4>Version 0.4 (2005-07-21)</h4><div class="indent">Simplified processing of roster item deletions. (psa)
628 the nature of sending entities (users, gateways, and group services);
629 specified "directory/group" service discovery identity for shared group
630 services. (psa) </div><h4>Version 0.2 (2004-10-04)</h4><div class="indent">Further defined the nature of trusted entities. (psa)
632 </div><h4>Version 0.0.2 (2004-09-22)</h4><div class="indent">To address Council feedback, added text about service discovery and choice of stanza type (message or IQ). (psa)
634 XEP-0093 by adding the action attribute, defining requirements and use
635 cases, specifying processing rules, and detailing security