idnits 2.17.1 draft-saintandre-rfc3921bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5527 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 3693 -- Looks like a reference, but probably isn't: '2' on line 3664 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. 'IMP-REQS') -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NAMES' ** Obsolete normative reference: RFC 4622 (ref. 'XMPP-URI') (Obsoleted by RFC 5122) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2426 (ref. 'VCARD') (Obsoleted by RFC 6350) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Obsoletes: 3921 (if approved) March 8, 2009 5 Intended status: Standards Track 6 Expires: September 9, 2009 8 Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and 9 Presence 10 draft-saintandre-rfc3921bis-08 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 9, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document defines extensions to core features of the Extensible 49 Messaging and Presence Protocol (XMPP) that provide basic instant 50 messaging (IM) and presence functionality in conformance with RFC 51 2779. 53 This document obsoletes RFC 3921. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.3. Functional Summary . . . . . . . . . . . . . . . . . . . . 8 61 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 9 62 1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 9 63 1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 10 64 2. Managing the Roster . . . . . . . . . . . . . . . . . . . . . 10 65 2.1. Syntax and Semantics . . . . . . . . . . . . . . . . . . . 10 66 2.1.1. Roster Items . . . . . . . . . . . . . . . . . . . . . 10 67 2.1.1.1. Ask Attribute . . . . . . . . . . . . . . . . . . 10 68 2.1.1.2. Jid Attribute . . . . . . . . . . . . . . . . . . 10 69 2.1.1.3. Name Attribute . . . . . . . . . . . . . . . . . . 10 70 2.1.1.4. Subscription Attribute . . . . . . . . . . . . . . 11 71 2.1.1.5. Group Element . . . . . . . . . . . . . . . . . . 11 72 2.1.2. Roster Get . . . . . . . . . . . . . . . . . . . . . . 11 73 2.1.3. Roster Set . . . . . . . . . . . . . . . . . . . . . . 12 74 2.1.4. Roster Push . . . . . . . . . . . . . . . . . . . . . 12 75 2.1.5. Roster Result . . . . . . . . . . . . . . . . . . . . 13 76 2.1.6. Subscription Attribute . . . . . . . . . . . . . . . . 14 77 2.2. Retrieving the Roster on Login . . . . . . . . . . . . . . 14 78 2.3. Adding a Roster Item . . . . . . . . . . . . . . . . . . . 15 79 2.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 15 80 2.3.2. Success Case . . . . . . . . . . . . . . . . . . . . . 16 81 2.3.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 17 82 2.4. Updating a Roster Item . . . . . . . . . . . . . . . . . . 21 83 2.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 21 84 2.4.2. Success Case . . . . . . . . . . . . . . . . . . . . . 23 85 2.4.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 23 86 2.5. Deleting a Roster Item . . . . . . . . . . . . . . . . . . 23 87 2.5.1. Request . . . . . . . . . . . . . . . . . . . . . . . 23 88 2.5.2. Success Case . . . . . . . . . . . . . . . . . . . . . 24 89 2.5.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 24 90 3. Managing Presence Subscriptions . . . . . . . . . . . . . . . 25 91 3.1. Requesting a Subscription . . . . . . . . . . . . . . . . 25 92 3.1.1. Client Generation of Outbound Subscription Request . . 26 93 3.1.2. Server Processing of Outbound Subscription Request . . 26 94 3.1.3. Server Processing of Inbound Subscription Request . . 28 95 3.1.4. Client Processing of Inbound Subscription Request . . 29 96 3.1.5. Server Processing of Outbound Subscription Approval . 30 97 3.1.6. Server Processing of Inbound Subscription Approval . . 31 98 3.2. Cancelling a Subscription . . . . . . . . . . . . . . . . 32 99 3.2.1. Client Generation of Subscription Cancellation . . . . 32 100 3.2.2. Server Processing of Outbound Subscription 101 Cancellation . . . . . . . . . . . . . . . . . . . . . 32 102 3.2.3. Server Processing of Inbound Subscription 103 Cancellation . . . . . . . . . . . . . . . . . . . . . 33 104 3.3. Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 34 105 3.3.1. Client Generation of Unsubscribe . . . . . . . . . . . 34 106 3.3.2. Server Processing of Outbound Unsubscribe . . . . . . 34 107 3.3.3. Server Processing of Inbound Unsubscribe . . . . . . . 35 108 4. Exchanging Presence Information . . . . . . . . . . . . . . . 36 109 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 36 110 4.2. Initial Presence . . . . . . . . . . . . . . . . . . . . . 37 111 4.2.1. Client Generation of Initial Presence . . . . . . . . 37 112 4.2.2. Server Processing of Outbound Presence . . . . . . . . 38 113 4.2.3. Server Processing of Inbound Presence . . . . . . . . 38 114 4.2.4. Client Processing of Inbound Presence . . . . . . . . 39 115 4.3. Presence Probes . . . . . . . . . . . . . . . . . . . . . 39 116 4.3.1. Server Generation of Outbound Presence Probe . . . . . 40 117 4.3.2. Server Processing of Inbound Presence Probe . . . . . 40 118 4.4. Subsequent Presence Broadcast . . . . . . . . . . . . . . 41 119 4.4.1. Client Generation of Presence Broadcast . . . . . . . 41 120 4.4.2. Server Processing of Outbound Presence . . . . . . . . 42 121 4.4.3. Server Processing of Inbound Presence . . . . . . . . 43 122 4.4.4. Client Processing of Inbound Presence . . . . . . . . 43 123 4.5. Unavailable Presence . . . . . . . . . . . . . . . . . . . 44 124 4.5.1. Client Generation of Unavailable Presence . . . . . . 44 125 4.5.2. Server Processing of Outbound Unavailable Presence . . 44 126 4.5.3. Server Processing of Inbound Unavailable Presence . . 45 127 4.5.4. Client Processing of Inbound Unavailable Presence . . 46 128 4.6. Directed Presence . . . . . . . . . . . . . . . . . . . . 46 129 4.6.1. Client Generation of Directed Presence . . . . . . . . 47 130 4.6.2. Server Processing of Outbound Directed Presence . . . 47 131 4.6.3. Server Processing of Inbound Directed Presence . . . . 47 132 4.6.4. Client Processing of Inbound Directed Presence . . . . 48 133 4.7. Presence Syntax . . . . . . . . . . . . . . . . . . . . . 48 134 4.7.1. Type Attribute . . . . . . . . . . . . . . . . . . . . 48 135 4.7.2. Child Elements . . . . . . . . . . . . . . . . . . . . 49 136 4.7.3. Show Element . . . . . . . . . . . . . . . . . . . . . 49 137 4.7.4. Status Element . . . . . . . . . . . . . . . . . . . . 50 138 4.7.5. Priority Element . . . . . . . . . . . . . . . . . . . 51 139 4.7.6. Extended Content . . . . . . . . . . . . . . . . . . . 51 140 5. Exchanging Messages . . . . . . . . . . . . . . . . . . . . . 52 141 5.1. One-to-One Chat Sessions . . . . . . . . . . . . . . . . . 52 142 5.2. Message Syntax . . . . . . . . . . . . . . . . . . . . . . 53 143 5.2.1. To Attribute . . . . . . . . . . . . . . . . . . . . . 53 144 5.2.2. Type Attribute . . . . . . . . . . . . . . . . . . . . 54 145 5.2.3. Body Element . . . . . . . . . . . . . . . . . . . . . 55 146 5.2.4. Subject Element . . . . . . . . . . . . . . . . . . . 56 147 5.2.5. Thread Element . . . . . . . . . . . . . . . . . . . . 56 148 5.3. Extended Content . . . . . . . . . . . . . . . . . . . . . 58 149 6. Exchanging IQ Stanzas . . . . . . . . . . . . . . . . . . . . 58 150 7. A Sample Session . . . . . . . . . . . . . . . . . . . . . . . 59 151 8. Server Rules for Processing XML Stanzas . . . . . . . . . . . 66 152 8.1. No Such User . . . . . . . . . . . . . . . . . . . . . . . 66 153 8.2. Full JID at Local Domain . . . . . . . . . . . . . . . . . 66 154 8.2.1. Resource Matches . . . . . . . . . . . . . . . . . . . 66 155 8.2.2. No Resource Matches . . . . . . . . . . . . . . . . . 67 156 8.3. Bare JID at Local Domain . . . . . . . . . . . . . . . . . 67 157 8.3.1. Available or Connected Resources . . . . . . . . . . . 67 158 8.3.1.1. Message . . . . . . . . . . . . . . . . . . . . . 67 159 8.3.1.2. Presence . . . . . . . . . . . . . . . . . . . . . 68 160 8.3.1.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . 69 161 8.3.2. No Available or Connected Resources . . . . . . . . . 69 162 8.3.2.1. Message . . . . . . . . . . . . . . . . . . . . . 69 163 8.3.2.2. Presence . . . . . . . . . . . . . . . . . . . . . 70 164 8.3.2.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . 70 165 8.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . . 70 166 9. IM and Presence Compliance Requirements . . . . . . . . . . . 71 167 9.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 71 168 9.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 72 169 10. Internationalization Considerations . . . . . . . . . . . . . 72 170 11. Security Considerations . . . . . . . . . . . . . . . . . . . 72 171 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 172 12.1. Instant Messaging SRV Protocol Label Registration . . . . 73 173 12.2. Presence SRV Protocol Label Registration . . . . . . . . . 74 174 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 175 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74 176 13.2. Informative References . . . . . . . . . . . . . . . . . . 75 177 Appendix A. Subscription States . . . . . . . . . . . . . . . . . 76 178 A.1. Defined States . . . . . . . . . . . . . . . . . . . . . . 77 179 A.2. Server Processing of Outbound Presence Subscription 180 Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 78 181 A.2.1. Subscribe . . . . . . . . . . . . . . . . . . . . . . 78 182 A.2.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 79 183 A.2.3. Subscribed . . . . . . . . . . . . . . . . . . . . . . 79 184 A.2.4. Unsubscribed . . . . . . . . . . . . . . . . . . . . . 80 185 A.3. Server Processing of Inbound Presence Subscription 186 Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 80 187 A.3.1. Subscribe . . . . . . . . . . . . . . . . . . . . . . 81 188 A.3.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 81 189 A.3.3. Subscribed . . . . . . . . . . . . . . . . . . . . . . 82 190 A.3.4. Unsubscribed . . . . . . . . . . . . . . . . . . . . . 83 191 Appendix B. Blocking Communication . . . . . . . . . . . . . . . 84 192 Appendix C. vCards . . . . . . . . . . . . . . . . . . . . . . . 84 193 Appendix D. XML Schemas . . . . . . . . . . . . . . . . . . . . . 84 194 D.1. jabber:client . . . . . . . . . . . . . . . . . . . . . . 84 195 D.2. jabber:server . . . . . . . . . . . . . . . . . . . . . . 89 196 D.3. jabber:iq:roster . . . . . . . . . . . . . . . . . . . . . 93 197 Appendix E. Differences From RFC 3921 . . . . . . . . . . . . . . 94 198 Appendix F. Copying Conditions . . . . . . . . . . . . . . . . . 95 199 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 200 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 96 202 1. Introduction 204 1.1. Overview 206 The Extensible Messaging and Presence Protocol (XMPP) is an 207 application profile of the Extensible Markup Language [XML] for 208 streaming XML data in close to real time between any two (or more) 209 network-aware entities. XMPP is typically used to exchange messages, 210 share presence information, and engage in structured request-response 211 interactions. The core features of XMPP defined in [rfc3920bis] 212 provide the building blocks for many types of near-real-time 213 applications, which can be layered on top of the core by sending 214 application-specific data qualified by particular XML namespaces 215 (refer to [XML-NAMES]). This document defines XMPP extensions that 216 provide the basic functionality expected of an instant messaging (IM) 217 and presence application as defined in [IMP-REQS]. 219 As a result of extensive implementation and deployment experience 220 with XMPP since 2004, as well as more formal interoperability testing 221 carried out under the auspices of the XMPP Standards Foundation 222 (XSF), this document reflects consensus from the XMPP developer 223 community regarding XMPP's basic instant messaging and presence 224 features. In particular, this document incorporates the following 225 backward-compatible changes from RFC 3921: 227 o Incorporated corrections and errata 228 o Added examples throughout 229 o Clarified and more completely specified matters that were 230 underspecified 231 o Removed the protocol for session establishment, which was deemed 232 unnecessary 233 o Modified error handling related to presence stanzas to more 234 seamlessly repair lack of synchronization in subscription states 235 between rosters located at different servers 236 o Added optional server support for pre-approved presence 237 subscriptions 238 o Added optional 'parent' attribute to element 239 o Transferred documentation for the communications blocking protocol 240 from this specification to a separate specification 242 Therefore, this document defines the basic instant messaging and 243 presence features of XMPP 1.0, thus obsoleting RFC 3921. 245 1.2. Requirements 247 Traditionally, instant messaging applications have combined the 248 following factors: 250 1. The central point of focus is a list of one's contacts or 251 "buddies" (in XMPP this list is called a ROSTER). 252 2. The purpose of using such an application is to exchange 253 relatively brief text messages with particular contacts in close 254 to real time -- often relatively large numbers of such messages 255 in rapid succession, in the form of a one-to-one CHAT SESSION as 256 described under Section 5.1. 257 3. The catalyst for exchanging messages is PRESENCE -- i.e., 258 information about the network availability of particular contacts 259 (thus knowing who is online and available for a one-to-one chat 260 session). 261 4. Presence information is provided only to contacts that one has 262 authorized by means of an explicit agreement called a PRESENCE 263 SUBSCRIPTION. 265 Thus at a high level this document assumes that a user must be able 266 to complete the following use cases: 268 o Manage items in one's contact list 269 o Exchange messages with one's contacts 270 o Exchange presence information with one's contacts 271 o Manage presence subscriptions to and from one's contacts 273 Detailed definitions of these functionality areas are contained in 274 RFC 2779 [IMP-REQS], and the interested reader is referred to that 275 document regarding the requirements addressed herein. While the XMPP 276 instant messaging and presence extensions specified herein meet the 277 requirements of RFC 2779, they were not designed explicitly with that 278 specification in mind, since the base protocol evolved through an 279 open development process within the Jabber open-source community 280 before RFC 2779 was written. Although XMPP protocol extensions 281 addressing many other functionality areas have been defined in the 282 XMPP Standards Foundation's XEP series (e.g., multi-user text chat as 283 specified in [XEP-0045]), such extensions are not specified in this 284 document because they are not mandated by RFC 2779. 286 Note: RFC 2779 stipulates that presence services must be separable 287 from instant messaging services and vice-versa; i.e., it must be 288 possible to use the protocol to provide a presence service, an 289 instant messaging service, or both. Although the text of this 290 document assumes that implementations and deployments will want to 291 offer a unified instant messaging and presence service, there is 292 no requirement that a service must offer both a presence service 293 and an instant messaging service, and the protocol makes it 294 possible to offer separate and distinct services for presence and 295 for instant messaging. (For example, a presence-only service 296 could return a stanza error if a client 297 attempt to send a stanza.) 299 1.3. Functional Summary 301 This non-normative section provides a developer-friendly, functional 302 summary of XMPP-based instant messaging and presence features; 303 consult the sections that follow for a normative definition of these 304 features. 306 [rfc3920bis] specifies how an XMPP client connects to an XMPP server. 307 In particular, it specifies the preconditions that must be fulfilled 308 before a client is allowed to send XML stanzas (the basic unit of 309 meaning in XMPP) to other entities on an XMPP network. These 310 preconditions comprise negotiation of the XML stream and include XML 311 stream establishment, optional channel encryption via Transport Layer 312 Security [TLS], mandatory authentication via Simple Authentication 313 and Security Layer [SASL], and binding of a resource to the stream 314 for client addressing. The reader is referred to [rfc3920bis] for 315 details regarding these preconditions, and knowledge of [rfc3920bis] 316 is assumed herein. 318 Note: [RFC3921] specified one additional precondition: formal 319 establishment of an instant messaging and presence session. 320 Implementation and deployment experience has shown that this 321 additional step is unnecessary. However, for backward 322 compatibility an implementation SHOULD still offer that feature 323 and note in the stream feature that negotiation of the feature is 324 discretionary (via the child element). This enables 325 older software to connect while saving newer software to skip a 326 round trip. 328 Upon fulfillment of the preconditions specified in [rfc3920bis], an 329 XMPP client has a long-lived XML stream with an XMPP server, which 330 enables the user controlling that client to send and receive a 331 potentially unlimited number of XML stanzas over the stream. Such a 332 stream can be used to exchange messages, share presence information, 333 and engage in structured request-response interactions in close to 334 real time. After negotiation of the XML stream, the typical flow for 335 an instant messaging and presence session is as follows: 337 1. Retrieve one's roster. (See Section 2.2.) 338 2. Send initial presence to the server for broadcasting to all 339 subscribed contacts, thus "going online" from the perspective of 340 XMPP communication. (See Section 4.2.) 341 3. Exchange messages, manage presence subscriptions, perform roster 342 updates, and in general process and generate other XML stanzas 343 with particular semantics throughout the life of the session. 344 (See Section 5, Section 3, Section 2, and Section 6.) 346 4. Terminate the session when desired by sending unavailable 347 presence and closing the underlying XML stream. (See 348 Section 4.5.) 350 1.4. Conventions 352 This document inherits the terminology defined in [rfc3920bis]. 354 The following keywords are to be interpreted as described in [TERMS]: 355 "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", 356 "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL". 358 For convenience, this document employs the term "user" to refer to 359 the owner of an XMPP account; however, account owners need not be 360 human persons and can be bots, devices, or other non-human 361 applications. 363 Following the "XML Notation" used in [IRI] to represent characters 364 that cannot be rendered in ASCII-only documents, some examples in 365 this document use the form "&#x...." as a notational device to 366 represent Unicode characters (e.g., the string "ř" stands for 367 the Unicode character LATIN SMALL LETTER R WITH CARON). 369 In examples, lines have been wrapped for improved readability, 370 "[...]" means elision, and the following prepended strings are used 371 (these prepended strings are not to be sent over the wire): 373 o C: = client 374 o CC: = contact's client 375 o CS: = contact's server 376 o S: = server 377 o UC: = user's client 378 o US: = user's server 380 1.5. Acknowledgements 382 The editor of this document finds it impossible to appropriately 383 acknowledge the many individuals who have provided comments regarding 384 the protocols defined herein. However, thanks are due to those who 385 have who have provided implementation feedback, bug reports, requests 386 for clarification, and suggestions for improvement since the 387 publication of the RFC this document supersedes. The editor has 388 endeavored to address all such feedback, but is solely responsible 389 for any remaining errors and ambiguities. 391 1.6. Discussion Venue 393 The document editor and the broader XMPP developer community welcome 394 discussion and comments related to the topics presented in this 395 document. The preferred forum is the mailing 396 list, for which archives and subscription information are available 397 at . 399 2. Managing the Roster 401 In XMPP, one's roster contains any number of specific contacts. A 402 user's roster is stored by the user's server on the user's behalf so 403 that the user can access roster information from any resource. 405 2.1. Syntax and Semantics 407 Rosters are managed using IQ stanzas, specifically by means of a 408 child element qualified by the 'jabber:iq:roster' namespace. 409 The detailed syntax and semantics are defined in the following 410 sections. 412 2.1.1. Roster Items 414 The element MAY contain one or more children, each 415 describing a unique ROSTER ITEM or "contact". 417 The syntax of the element is described in the following 418 sections. 420 2.1.1.1. Ask Attribute 422 The 'ask' attribute is used to specify certain subscription sub- 423 states; for details, see Section 3.1.2. 425 Inclusion of the 'ask' attribute is OPTIONAL. 427 2.1.1.2. Jid Attribute 429 The 'jid' attribute specifies the Jabber Identifier (JID) that 430 uniquely identifies the roster item. 432 Inclusion of the 'jid' attribute is REQUIRED. 434 2.1.1.3. Name Attribute 436 The 'name' attribute specifies the "handle" to be associated with the 437 JID, as determined by the user (not the contact). Although the value 438 of the 'name' attribute MAY have meaning to a human user, it is 439 opaque to the server. However, the 'name' attribute MAY be used by 440 the server for matching purposes within the context of various XMPP 441 extensions, in which case the values MUST be compared only after 442 application of the Resourceprep profile of stringprep as defined in 443 [rfc3920bis]. 445 Inclusion of the 'name' attribute is OPTIONAL. 447 2.1.1.4. Subscription Attribute 449 The 'subscription' attribute is OPTIONAL; see Section 2.1.6. 451 Inclusion of the 'subscription' attribute is OPTIONAL. 453 2.1.1.5. Group Element 455 The child element specifies a category or "bucket" into 456 which the roster item is to be grouped by a client. An 457 element MAY contain more than one element, so that roster 458 groups are not exclusive. Although the XML character data of the 459 element MAY have meaning to a human user, it is opaque to 460 the server. However, the element MAY be used by the server 461 for matching purposes within the context of various XMPP extensions, 462 in which case the data MUST be compared only after application of the 463 Resourceprep profile of stringprep as defined in [rfc3920bis]. 465 Inclusion of the child element is OPTIONAL. 467 2.1.2. Roster Get 469 A ROSTER GET is a client's request for the server to send the roster; 470 syntactically it is an IQ stanza of type "get" sent from client to 471 server and containing a element qualified by the 'jabber:iq: 472 roster' namespace, where the element MUST NOT contain any 473 child elements. 475 C: 478 479 481 The expected outcome of sending a roster get is for the server to 482 return a roster result. 484 2.1.3. Roster Set 486 A ROSTER SET is a client's request for the server to modify (i.e., 487 create, update, or delete) a roster item; syntactically it is an IQ 488 stanza of type "set" sent from client to server and containing a 489 element qualified by the 'jabber:iq:roster' namespace. 491 The following rules apply to roster sets: 493 1. The element MUST contain one and only one 494 element. 495 2. The server MUST ignore any value of the 'subscription' attribute 496 other than "remove" (see Section 2.1.6). 497 3. The server MUST ignore any 'to' address specified on the IQ 498 stanza and MUST handle the IQ stanza as if it included no 'to' 499 attribute. 501 C: 504 505 506 507 509 2.1.4. Roster Push 511 A ROSTER PUSH is a newly created, updated, or deleted roster item 512 that is sent from the server to the client; syntactically it is an IQ 513 stanza of type "set" sent from server to client and containing a 514 element qualified by the 'jabber:iq:roster' namespace. 516 The following rules apply to roster pushes: 518 1. The element in a roster push MUST contain one and only 519 one element. 520 2. A receiving client MUST ignore the stanza unless it has no 'from' 521 attribute (i.e., implicitly from the user's bare JID) or it has a 522 'from' attribute whose value matches the user's bare JID 523 . 525 S: 528 529 530 531 533 As mandated by the semantics of the IQ stanza as defined in 534 [rfc3920bis], each resource that receives a roster push MUST reply 535 with an IQ stanza of type "result" (or "error"). 537 C: 541 C: 545 Note: There is no error case for client processing of roster 546 pushes; if the server receives an IQ of type "error" in response 547 to a roster push it SHOULD ignore the error. 549 2.1.5. Roster Result 551 A ROSTER RESULT is the server's response to a roster get; 552 syntactically it is an IQ stanza of type "result" sent from server to 553 client and containing a element qualified by the 'jabber:iq: 554 roster' namespace. 556 The element in a roster result contains one element 557 for each contact and therefore can contain more than one 558 element. 560 S: 563 564 565 566 567 569 If there are no contacts in the roster, the server MUST return an IQ- 570 result containing a child element that in turn contains no 571 children (e.g., the server MUST NOT return an empty 572 stanza element). 574 S: 577 578 580 2.1.6. Subscription Attribute 582 The state of the presence subscription in relation to a roster item 583 is captured in the 'subscription' attribute of the element. 584 Allowable subscription-related values for this attribute are: 586 o "none" -- the user does not have a subscription to the contact's 587 presence, and the contact does not have a subscription to the 588 user's presence 589 o "to" -- the user has a subscription to the contact's presence, but 590 the contact does not have a subscription to the user's presence 591 o "from" -- the contact has a subscription to the user's presence, 592 but the user does not have a subscription to the contact's 593 presence 594 o "both" -- both the user and the contact have subscriptions to each 595 other's presence (also called a "mutual subscription") 597 In a roster result, the client MUST ignore values of the 598 'subscription' attribute other than "none", "to", "from", or "both". 600 In a roster push, the client MUST ignore values of the 'subscription' 601 attribute other than "none", "to", "from", "both", or "remove". 603 In a roster set, the value of the 'subscription' attribute MAY be 604 included with a value of "remove", which indicates that the item is 605 to be removed from the roster; the server MUST ignore all values of 606 the 'subscription' attribute other than "remove". 608 2.2. Retrieving the Roster on Login 610 Upon authenticating with a server and binding a resource (thus 611 becoming a connected resource), a client SHOULD request the roster 612 before sending initial presence (however, because receiving the 613 roster is not necessarily desirable for all resources, e.g., a 614 connection with limited bandwidth, the client's request for the 615 roster is not mandatory). After a connected resource sends initial 616 presence (see Section 4.2), it is referred to as an available 617 resource. If a connected resource or available resource requests the 618 roster, it is referred to as an INTERESTED RESOURCE. The server MUST 619 send roster pushes to all interested resources. 621 Note: Presence subscription requests are sent to available 622 resources, whereas the roster pushes associated with subscription 623 state changes are sent to interested resources. Therefore if a 624 resource wishes to receive both subscription requests and roster 625 pushes, it MUST both send initial presence and request the roster. 627 A client requests the roster by sending a roster get over its stream 628 to the server. 630 C: 633 634 636 S: 639 640 643 Friends 644 645 648 651 652 654 If the server cannot process the roster get, it MUST return an 655 appropriate stanza error as described in [rfc3920bis] (such as 656 if the roster namespace is not supported or 657 if the server experiences trouble processing 658 or returning the roster). 660 2.3. Adding a Roster Item 662 2.3.1. Request 664 At any time, a client can add an item to the roster. This is done by 665 sending a roster set containing a new item. 667 C: 670 671 673 Servants 674 675 676 678 Note: When a user adds a contact for the purpose of tracking the 679 user's presence subscription to a contact, the user's client MUST 680 send a presence subscription request to the contact before 681 generating any roster set related to the contact. This enables 682 the user's server to enforce any policies relevant to presence 683 subscriptions (e.g., a prohibition on presence subscriptions to 684 full JIDs). For details, see Section 3. 686 2.3.2. Success Case 688 If the server can successfully process the roster set (i.e., if none 689 of the error cases occurs), it MUST create the roster item in 690 persistent storage. 692 The server MUST then return an IQ stanza of type "result" to the 693 connected resource that sent the roster set. 695 S: 699 The server MUST also send a roster push containing the new roster 700 item to all of the user's interested resources, including the 701 resource that generated the roster set. 703 S: 706 707 710 Servants 711 712 713 715 S: 718 719 722 Servants 723 724 725 727 As mandated by the semantics of the IQ stanza as defined in 728 [rfc3920bis], each resource that receives a roster push MUST reply 729 with an IQ stanza of type "result" (or "error"). 731 C: 735 C: 739 2.3.3. Error Cases 741 If the server cannot successfully process the roster set, it MUST 742 return a stanza error. The following error cases are defined 743 (naturally, other stanza errors can occur, such as ). 746 The server SHOULD return a stanza error to the client 747 if the roster set violates any of the following conditions: 749 1. The element contains more than one child 750 element. 751 2. The element contains more than one element, but 752 there are duplicate groups (where duplicates are determined using 753 the Resourceprep profile of stringprep as defined in 754 [rfc3920bis]). 756 The server SHOULD return a stanza error to the 757 client if the roster set violates any of the following conditions: 759 1. The value of the 'name' attribute is greater than a server- 760 configured limit. 761 2. The XML character data of the element is of zero length. 762 3. The XML character data of the element is greater than a 763 server-configured limit. 765 Alternatively, the server MAY ignore the foregoing violations and 766 process the roster set as best as possible (e.g., process only the 767 first element, ignore duplicate elements, place the 768 roster item in no group or a default group if the element is 769 empty, and truncate 'name' attributes and elements that are 770 too long). 772 Error: Roster set contains more than one item 774 C: 777 778 780 Servants 781 782 784 Family 785 786 787 789 S: 792 793 794 795 797 Error: Roster set contains item with oversized handle 799 C: 802 803 805 Servants 806 807 808 810 S: 813 814 815 816 818 Error: Roster set contains duplicate groups 820 C: 823 824 826 Servants 827 Servants 828 829 830 832 S: 835 836 837 838 840 Error: Roster set contains empty group 842 C: 845 846 848 849 850 851 853 S: 856 857 858 859 861 Error: Roster set contains oversized group 863 C: 866 867 869 [ ... some-very-long-group-name ... ] 870 871 872 874 S: 877 878 879 880 882 The server MUST return a stanza error to the client if 883 the value of the element's 'jid' attribute matches the bare 884 JID portion of the element's 'from' attribute 885 (i.e., a JID MUST NOT be allowed to add itself to its own roster). 887 Error: Roster set contains sender's JID 889 C: 892 893 894 895 897 S: 900 901 902 903 905 2.4. Updating a Roster Item 907 2.4.1. Request 909 Updating an existing roster item is done in the same way as adding a 910 new roster item, i.e., by sending a roster set to the server. 911 Because a roster item is atomic, the item MUST be updated exactly as 912 provided in the roster set. 914 There are several reasons why a client might update a roster item: 916 1. Adding a group 917 2. Deleting a group 918 3. Changing the handle 919 4. Deleting the handle 921 Consider a roster item that is defined as follows: 923 925 Friends 926 928 The user who has this item in her roster might want to add the item 929 to another group. 931 C: 934 935 937 Friends 938 Lovers 939 940 941 943 The user might then want to remove the item from the original group. 945 C: 948 949 951 Lovers 952 953 954 956 The user might then want to change the handle for the item. 958 C: 961 962 964 Lovers 965 966 967 969 The user might then want to remove the handle altogether (note: 970 including an empty 'name' attribute is equivalent to including no 971 'name' attribute). 973 C: 976 977 979 Lovers 980 981 982 984 The user might then want to remove the item from all groups. 986 C: 989 990 991 992 994 2.4.2. Success Case 996 As with adding a roster item, if the roster item can be successfully 997 processed then the server MUST update the roster information in 998 persistent storage, send a roster push to all of the user's 999 interested resources, and send an IQ result to the initiating 1000 resource; for details, see Section 2.3. 1002 2.4.3. Error Cases 1004 The error cases described under Section 2.3.3 also apply to updating 1005 a roster item. 1007 2.5. Deleting a Roster Item 1009 2.5.1. Request 1011 At any time, a client can delete an item from his or her roster by 1012 sending a roster set and specifying the value of the 'subscription' 1013 attribute to be "remove". 1015 C: 1018 1019 1020 1022 1024 2.5.2. Success Case 1026 As with adding a roster item, if the server can successfully process 1027 the roster set then it MUST update the roster information in 1028 persistent storage, send a roster push to all of the user's 1029 interested resources (with the 'subscription' attribute set to a 1030 value of "remove"), and send an IQ result to the initiating resource; 1031 for details, see Section 2.3. 1033 If the user has a presence subscription to the contact or the contact 1034 has a presence subscription to the user, the user's server MUST also 1035 generate a presence stanza of type "unsubscribe" (to unsubscribe from 1036 the contact's presence) or a presence stanza of type "unsubscribed" 1037 (to cancel the contact's subscription to the user), or both. 1039 S: 1043 S: 1047 2.5.3. Error Cases 1049 If the value of the 'jid' attribute specifies an item that is not in 1050 the roster, the server MUST return an stanza error. 1052 Error: Roster item not found 1054 C: 1057 1058 1060 1061 1063 S: 1066 1067 1068 1069 1071 3. Managing Presence Subscriptions 1073 In order to protect the privacy of instant messaging users, presence 1074 information is disclosed only to other entities that a user has 1075 approved. When a user has agreed that another entity is allowed to 1076 view its presence, the entity is said to have a SUBSCRIPTION to the 1077 user's presence. An entity that has a subscription to a user's 1078 presence or to which a user has a presence subscription is called a 1079 CONTACT (in this document the term "contact" is also used in a less 1080 strict sense to refer to a potential contact or an item in a user's 1081 roster). 1083 In XMPP, a subscription lasts across presence sessions; indeed, it 1084 lasts until the contact unsubscribes or the user cancels the 1085 previously-granted subscription. 1087 Subscriptions are managed within XMPP by sending presence stanzas 1088 containing specially-defined attributes ("subscribe", "unsubscribe", 1089 "subscribed", and "unsubscribed"). 1091 Note: When a server processes or generates an outbound presence 1092 stanza of type "subscribe", "subscribed", "unsubscribe", or 1093 "unsubscribed", the server MUST stamp the outgoing presence stanza 1094 with the bare JID of the sending entity, not the 1095 full JID . Enforcement of this rule 1096 simplifies the presence subscription model and helps to prevent 1097 presence leaks; for information about presence leaks, refer to the 1098 security considerations of [rfc3920bis]. 1100 Subscription states are reflected in the rosters of both the user and 1101 the contact. Complete details regarding these subscription states 1102 can be found Appendix A; those details are not provided in this 1103 section, which simply narrates the protocol flows for common use 1104 cases related to presence subscriptions. 1106 3.1. Requesting a Subscription 1108 A SUBSCRIPTION REQUEST is a request from a user for authorization to 1109 permanently subscribe to a contact's presence information; 1110 syntactically it is a presence stanza whose 'type' attribute has a 1111 value of "subscribe". A subscription request is generated by a 1112 user's client, processed by the (potential) contact's server, and 1113 acted on by the contact via the contact's client. The workflow is 1114 described in the following sections. 1116 Note: Presence subscription requests are sent to available 1117 resources, whereas the roster pushes associated with subscription 1118 state changes are sent to interested resources. Therefore if a 1119 resource wishes to receive both subscription requests and roster 1120 pushes, it MUST both send initial presence and request the roster. 1122 3.1.1. Client Generation of Outbound Subscription Request 1124 A user's client generates a subscription request by sending a 1125 presence stanza of type "subscribe" and specifying a 'to' address of 1126 the potential contact's bare JID . 1128 UC: 1130 When a user sends a presence subscription request to a potential 1131 instant messaging and presence contact, the value of the 'to' 1132 attribute MUST be a bare JID rather a full JID 1133 , since the desired result is for the user 1134 to receive presence from all of the contact's resources, not merely 1135 the particular resource specified in the 'to' attribute. Use of bare 1136 JIDs also simplifies subscription processing, presence probes, and 1137 presence notifications by the user's server and the contact's server. 1139 Although many XMPP clients prompt the user for information about 1140 the potential contact (e.g., "handle" and desired roster group) 1141 when generating an outbound presence subscription request, the 1142 client MUST NOT send a roster set before sending the presence 1143 subscription request, but instead MUST wait until receiving the 1144 initial roster push from the server. This enables the user's 1145 server to enforce any policies relevant to presence subscriptions 1146 (e.g., a prohibition on presence subscriptions to full JIDs). 1148 3.1.2. Server Processing of Outbound Subscription Request 1150 Upon receiving the outbound presence subscription request, the user's 1151 server MUST proceed as follows. 1153 1. Before processing the request, the user's server SHOULD check the 1154 syntax of the JID contained in the 'to' attribute. If the JID is 1155 of the form instead of 1156 , the user's server SHOULD treat it as if the 1157 request had been directed to the contact's bare JID and modify 1158 the 'to' address accordingly. The server MAY also verify that 1159 the JID adheres to the format defined in [rfc3920bis], including 1160 checking against the relevant stringprep profiles. 1161 2. If the potential contact is hosted on the same server as the 1162 user, the server MUST adhere to the rules specified in the next 1163 section in processing the subscription request and delivering it 1164 to the (local) contact. 1166 3. If the potential contact is hosted on a remote server, subject to 1167 local service policies the user's server MUST then route the 1168 stanza to that remote domain in accordance with core XMPP stanza 1169 processing rules. (This can result in returning an appropriate 1170 stanza error to the user, such as .) 1172 As mentioned, before locally delivering or remotely routing the 1173 presence subscription request, the user's server MUST stamp the 1174 outbound subscription request with the bare JID of the 1175 user. 1177 US: 1181 After locally delivering or remotely routing the presence 1182 subscription request, the user's server MUST then send a roster push 1183 to all of the user's interested resources, containing the potential 1184 contact with a subscription state of "none" and with notation that 1185 the subscription is pending (via an 'ask' attribute whose value is 1186 "subscribe"). 1188 US: 1191 1192 1195 1196 1198 US: 1201 1202 1205 1206 1207 1209 If the contact does not approve or deny the subscription request 1210 within some configurable amount of time, the user's server SHOULD re- 1211 send the subscription request to the contact based on an 1212 implementation-specific algorithm (e.g., whenever a new resource 1213 becomes available for the user, or after a certain amount of time has 1214 elapsed); this helps to recover from transient, silent errors that 1215 might have occurred in relation to the original subscription request. 1217 3.1.3. Server Processing of Inbound Subscription Request 1219 Before processing the inbound presence subscription request, the 1220 contact's server SHOULD check the syntax of the JID contained in the 1221 'to' attribute. If the JID is of the form 1222 instead of , the contact's server SHOULD treat it as 1223 if the request had been directed to the contact's bare JID and modify 1224 the 'to' address accordingly. The server MAY also verify that the 1225 JID adheres to the format defined in [rfc3920bis], including checking 1226 against the relevant stringprep profiles. 1228 When processing the inbound presence subscription request, the 1229 contact's server MUST adhere to the following rules: 1231 1. Above all, the contact's server MUST NOT automatically approve 1232 subscription requests on the contact's behalf (unless the contact 1233 has configured its account to automatically approve subscription 1234 requests or has accepted an agreement with its service provider 1235 that allows such behavior, for instance via an employment 1236 agreement within an enterprise deployment). Instead, if a 1237 subscription request requires approval then the contact's server 1238 MUST deliver that request to the contact's available resource(s) 1239 for approval or denial by the contact. 1240 2. If the contact does not exist, then the contact's server MUST 1241 automatically return a presence stanza of type "unsubscribed" to 1242 the user. 1244 CS: 1248 3. If the contact exists and the user already has a subscription to 1249 the contact's presence, then the contact's server MUST auto-reply 1250 on behalf of the contact by sending a presence stanza of type 1251 "subscribed" from the contact's bare JID to the user's bare JID. 1252 If the contact previously sent a presence stanza of type 1253 "subscribed" and the contact's server treated that as indicating 1254 "pre-approval" for the user's presence subscription (see 1255 Appendix A), then the contact's server SHOULD also auto-reply on 1256 behalf of the contact. 1257 4. If the contact exists, the user does not already have a 1258 subscription to the contact's presence, and there is at least one 1259 available resource associated with the contact when the 1260 subscription request is received by the contact's server, then 1261 the contact's server MUST broadcast that subscription request to 1262 all available resources in accordance with Section 8. 1263 5. If the contact exists, the user does not already have a 1264 subscription to the contact's presence, and the contact has no 1265 available resources when the subscription request is received by 1266 the contact's server, then the contact's server MUST keep a 1267 record of the complete presence stanza comprising the 1268 subscription request, including any extended content contained 1269 therein, and deliver the request when the contact next has an 1270 available resource. The contact's server MUST continue to 1271 deliver the subscription request whenever the contact creates an 1272 available resource, until the contact either approves or denies 1273 the request. (The contact's server MUST NOT deliver more than 1274 one subscription request from any given user when the contact 1275 next has an available resource; e.g., if the user sends multiple 1276 subscription requests to the contact while the contact is 1277 offline, the contact's server SHOULD store only one of those 1278 requests, such as the first request or last request, and MUST 1279 deliver only one of the requests when the contact next has an 1280 available resource; this helps to prevent "subscription request 1281 spam".) 1283 Note: Until and unless the contact approves the subscription 1284 request as described under Section 3.1.4, the contact's server 1285 MUST NOT add an item for the user to the contact's roster. 1287 3.1.4. Client Processing of Inbound Subscription Request 1289 When the contact's client receives a subscription request from the 1290 user, it MUST present the request to the contact for approval (unless 1291 the contact has explicitly configured the client to automatically 1292 approve or deny some or all subscription requests). 1294 A subscription request is approved by sending a presence stanza of 1295 type "subscribed", which is processed as described in the following 1296 sections for both the contact's server and the user's server. 1298 CC: 1300 A subscription request is denied by sending a presence stanza of type 1301 "unsubscribed", which is processed as described under Section 3.2 for 1302 both the contact's server and the user's server. 1304 CC: 1306 3.1.5. Server Processing of Outbound Subscription Approval 1308 When the contact's client sends the subscription approval, the 1309 contact's server MUST stamp the outbound stanza with the bare JID 1310 of the contact and locally deliver or remotely route 1311 the stanza to the user. 1313 CS: 1317 The contact's server then MUST send a roster push to all of the 1318 contact's interested resources. 1320 CS: 1323 1324 1326 1327 1329 CS: 1332 1333 1335 1336 1338 The contact's server MUST then also send current presence to the user 1339 from each of the contact's available resources. 1341 CS: 1344 CS: 1347 From the perspective of the contact, there now exists a subscription 1348 from the user. 1350 In order to subscribe to the user's presence, the contact would then 1351 send a subscription request to the user. (XMPP clients will often 1352 automatically send the subscription request instead of requiring the 1353 contact to initiate the subscription request, since it is assumed 1354 that the desired end state is a mutual subscription.) Naturally, 1355 when the contact sends a subscription request to the user, the 1356 subscription states will be different from those shown in the 1357 foregoing examples (see Appendix A) and the roles will be reversed. 1359 3.1.6. Server Processing of Inbound Subscription Approval 1361 When the user's server receives the subscription approval, it MUST 1362 first check if the contact is in the user's roster with 1363 subscription='none' or subscription='from' and the 'ask' flag set to 1364 "subscribe" (i.e., a subscription state of "None + Pending Out", 1365 "None + Pending Out+In", or "From + Pending Out"; see Appendix A). 1366 If this check is successful, the user's server MUST initiate a roster 1367 push to all of the user's interested resources, containing an updated 1368 roster item for the contact with the 'subscription' attribute set to 1369 a value of "to" (if the subscription state was "None + Pending Out" 1370 or "None + Pending Out+In") or "both" (if the subscription state was 1371 "From + Pending Out"). 1373 US: 1376 1377 1379 1380 1382 US: 1385 1386 1388 1389 1390 1392 (Otherwise -- that is, if the user does not exist, if the contact is 1393 not in the user's roster, or if the contact is in the user's roster 1394 with a subscription state other than those described in the foregoing 1395 check -- then the user's server MUST silently ignore the stanza by 1396 not delivering it to the user, not modifying the user's roster, and 1397 not generating a roster push to the user's interested resources.) 1399 From the perspective of the user, there now exists a subscription to 1400 the contact's presence. 1402 The user's server MUST also deliver the available presence stanza 1403 received from each of the contact's available resources to each of 1404 the user's available resources. 1406 [ ... to resource1 ... ] 1408 US: 1411 [ ... to resource2 ... ] 1413 US: 1416 [ ... to resource1 ... ] 1418 US: 1421 [ ... to resource2 ... ] 1423 US: 1426 3.2. Cancelling a Subscription 1428 3.2.1. Client Generation of Subscription Cancellation 1430 If a contact would like to cancel a subscription that it has 1431 previously granted to a user (or deny a subscription request), it 1432 sends a presence stanza of type "unsubscribed". 1434 CC: 1436 3.2.2. Server Processing of Outbound Subscription Cancellation 1438 Upon receiving the outound subscription cancellation, the contact's 1439 server MUST proceed as follows. 1441 1. If the user is hosted on the same server as the contact, the 1442 server MUST adhere to the rules specified in the next section in 1443 processing the subscription cancellation. 1444 2. If the user is hosted on a remote server, subject to local 1445 service policies the contact's server MUST then route the stanza 1446 to that remote domain in accordance with core XMPP stanza 1447 processing rules. (This can result in returning an appropriate 1448 stanza error to the contact, such as .) 1450 As mentioned, before locally delivering or remotely routing the 1451 stanza, the contact's server MUST stamp the outbound subscription 1452 cancellation with the bare JID of the contact. 1454 CS: 1458 The contact's server then MUST send a roster push with the updated 1459 roster item to all of the contact's interested resources, where the 1460 subscription state is now either "none" or "to" (see Appendix A). 1462 CS: 1465 1466 1468 1469 1471 CS: 1474 1475 1477 1478 1480 3.2.3. Server Processing of Inbound Subscription Cancellation 1482 When the user's server receives the inbound subscription 1483 cancellation, it MUST first check if the contact is in the user's 1484 roster with subscription='to' or subscription='both' (see 1485 Appendix A). If this check is successful, the user's server MUST 1486 initiate a roster push to all of the user's interested resources, 1487 containing an updated roster item for the contact with the 1488 'subscription' attribute set to a value of "none" (if the 1489 subscription state was "To" or "To + Pending In") or "from" (if the 1490 subscription state was "Both"). 1492 US: 1495 1496 1498 1499 1501 US: 1504 1505 1507 1508 1509 1511 (Otherwise -- that is, if the user does not exist, if the contact is 1512 not in the user's roster, or if the contact is in the user's roster 1513 with a subscription state other than those described in the foregoing 1514 check -- then the user's server MUST silently ignore the stanza by 1515 not delivering it to the user, not modifying the user's roster, and 1516 not generating a roster push to the user's interested resources.) 1518 3.3. Unsubscribing 1520 3.3.1. Client Generation of Unsubscribe 1522 If a user would like to unsubscribe from a contact's presence, it 1523 sends a presence stanza of type "unsubscribe". 1525 UC: 1527 3.3.2. Server Processing of Outbound Unsubscribe 1529 Upon receiving the outbound unsubscribe, the user's server MUST 1530 proceed as follows. 1532 1. If the contact is hosted on the same server as the user, the 1533 server MUST adhere to the rules specified in the next section in 1534 processing the subscription request. 1535 2. If the contact is hosted on a remote server, subject to local 1536 service policies the user's server MUST then route the stanza to 1537 that remote domain in accordance with core XMPP stanza processing 1538 rules. (This can result in returning an appropriate stanza error 1539 to the user, such as .) 1541 As mentioned, before locally delivering or remotely routing the 1542 unsubscrbe, the user's server MUST stamp the stanza with the bare JID 1543 of the user. 1545 US: 1549 The user's server then MUST send a roster push with the updated 1550 roster item to all of the user's interested resources, where the 1551 subscription state is now either "none" or "from" (see Appendix A). 1553 US: 1556 1557 1559 1560 1562 US: 1565 1566 1568 1569 1570 1572 3.3.3. Server Processing of Inbound Unsubscribe 1574 When the contact's server receives the subscription approval, it MUST 1575 first check if the user is in the contact's roster with 1576 subscription='from' or subscription='both' (i.e., a subscription 1577 state of "From", "From + Pending Out", or "Both"; see Appendix A). 1578 If this check is successful, the contact's server MUST initiate a 1579 roster push to all of the contact's interested resources, containing 1580 an updated roster item for the contact with the 'subscription' 1581 attribute set to a value of "none" (if the subscription state was 1582 "From" or "From + Pending Out") or "to" (if the subscription state 1583 was "Both"). 1585 CS: 1588 1589 1591 1592 1594 CS: 1597 1598 1600 1601 1603 (Otherwise -- that is, if the contact does not exist, if the user is 1604 not in the contact's roster, or if the user is in the contact's 1605 roster with a subscription state other than those described in the 1606 foregoing check -- then the contact's server MUST silently ignore the 1607 stanza by not delivering it to the contact, not modifying the 1608 contact's roster, and not generating a roster push to the contact's 1609 interested resources.) 1611 4. Exchanging Presence Information 1613 4.1. Overview 1615 The concept of presence refers to an entity's availability for 1616 communication over a network. At the most basic level, presence is a 1617 boolean "on/off" variable that signals whether an entity is available 1618 or unavailable for communication (the terms "online" and "offline" 1619 are also used). In XMPP, a user's availability is signalled when a 1620 client controlled by the user generates a stanza with no 1621 'type' attribute, and an entity's lack of availability is signalled 1622 when a client generates a stanza whose 'type' attribute 1623 has a value of "unavailable". 1625 XMPP presence typically follows a "publish-subscribe" or "observer" 1626 pattern, wherein an entity sends presence to its server, and its 1627 server then broadcasts that information to all of the entity's 1628 contacts who have a subscription to the entity's presence (in the 1629 terminology of [IMP-MODEL], an entity that generates presence is a 1630 "presentity" and the entities that receive presence are 1631 "subscribers"). A client generates presence for broadcasting to all 1632 subscribed entities by sending a presence stanza to its server with 1633 no 'to' address, where the presence stanza has either no 'type' 1634 attribute or a 'type' attribute whose value is "unavailable". This 1635 kind of presence is called BROADCAST PRESENCE. (A client can also 1636 send DIRECTED PRESENCE, i.e., a presence stanza with a 'to' address; 1637 this is less common but is sometimes used to send presence to 1638 entities that are not subscribed to the user's presence; see 1639 Section 4.6.) 1641 After a client completes the preconditions specified in [rfc3920bis], 1642 it can establish a PRESENCE SESSION at its server by sending initial 1643 presence (Section 4.2), where the presence session is terminated by 1644 sending unavailable presence (Section 4.5). For the duration of its 1645 presence session, a connected resource (in the terminology of 1646 [rfc3920bis]) is said to be an AVAILABLE RESOURCE. 1648 In XMPP-based applications that combine messaging and presence 1649 functionality, the default type of communication for which presence 1650 signals availability is messaging; however, it is not necessary for 1651 XMPP-based applications to combine messaging and presence 1652 functionality, and can provide standalone presence features without 1653 messaging (in addition, XMPP servers do not require information about 1654 network availability in order to successfully route message and IQ 1655 stanzas). 1657 Note: In the following examples, the "user" is juliet@example.com 1658 and the user has three contacts in her roster with a subscription 1659 state of "from" or "both": romeo@example.net, 1660 mercutio@example.com, and benvolio@example.net. 1662 4.2. Initial Presence 1664 4.2.1. Client Generation of Initial Presence 1666 After completing the preconditions described in [rfc3920bis] 1667 (REQUIRED) and requesting the roster (RECOMMENDED), a client signals 1668 its availability for communication by sending INITIAL PRESENCE to its 1669 server, i.e., a presence stanza with no 'to' address (indicating that 1670 it is meant to be broadcast by the server on behalf of the client) 1671 and no 'type' attribute (indicating the user's availability). 1673 UC: 1675 The initial presence stanza MAY contain the element, the 1676 element, and one or more instances of the element, 1677 as well as extended content. 1679 4.2.2. Server Processing of Outbound Presence 1681 Upon receiving initial presence from a client, the user's server MUST 1682 send the initial presence stanza from the full JID 1683 of the user to all contacts that are 1684 subscribed to the user's presence; such contacts are those for which 1685 a JID is present in the user's roster with the 'subscription' 1686 attribute set to a value of "from" or "both". 1688 US: 1691 US: 1694 US: 1697 The user's server MUST also broadcast initial presence from the 1698 user's newly available resource to all of the user's available 1699 resources (including the resource that generated the presence 1700 notification in the first place). 1702 US: 1705 US: 1708 In the absence of presence information about the user's contacts, the 1709 user's server MUST also send presence probes to the user's contacts 1710 on behalf of the user as specified under Section 4.3. 1712 4.2.3. Server Processing of Inbound Presence 1714 Upon receiving presence from the user, the contact's server MUST 1715 deliver the user's presence stanza to all of the contact's available 1716 resources. 1718 [ ... to resource1 ... ] 1720 CS: 1723 [ ... to resource2 ... ] 1725 CS: 1728 If there is no such contact, the contact's server MUST silently 1729 ignore the presence stanza. 1731 4.2.4. Client Processing of Inbound Presence 1733 When the contact's client receives presence from the user, it SHOULD 1734 proceed as follows: 1736 1. If the user is in the contact's roster, the client MUST display 1737 the presence information in an appropriate roster interface. 1738 2. If the user is not in the contact's roster but the contact and 1739 the user are actively exchanging message or IQ stanzas, the 1740 contact's client SHOULD display the presence information in the 1741 user interface for that chat session (see also Section 4.6 and 1742 Section 5.1). 1743 3. Otherwise, the client MUST ignore the presence information and 1744 not display it to the contact. 1746 4.3. Presence Probes 1748 A PRESENCE PROBE is a request for a contact's current presence 1749 information, sent on behalf of a user by the user's server; 1750 syntactically it is a presence stanza whose 'type' attribute has a 1751 value of "probe". The value of the 'from' address MUST be the full 1752 JID of the user and the value of the 'to' 1753 address MUST be the bare JID of the contact to which 1754 the user is subscribed. 1756 US: 1760 Note: Although presence probes MAY be sent by a client, in general 1761 a client will not need to send them since the task of gathering 1762 presence from a user's contacts is managed by the user's server. 1763 However, if a client generates an outbound presence probe then the 1764 user's server SHOULD route the probe (if the contact is at another 1765 server) or process the probe (if the contact is at the same 1766 server) and MUST NOT return a stanza or stream error to the 1767 client. 1769 If a server receives a presence probe intended for a full JID 1770 , it SHOULD treat the probe as if the 'to' 1771 address was a bare JID, but MAY instead handle it on behalf of the 1772 connected resource by returning only the presence information for 1773 that particular resources (and in any case MUST NOT deliver it to the 1774 resource). 1776 4.3.1. Server Generation of Outbound Presence Probe 1778 When a server needs to discover the availability of a user's contact, 1779 it sends a presence probe from the full JID of 1780 the user to the bare JID of the contact. The server 1781 MUST NOT send a probe to a contact if the user is not subscribed to 1782 the contact's presence (i.e., if the contact is not in the user's 1783 roster with the 'subscription' attribute set to a value of "to" or 1784 "both". 1786 The user's server SHOULD send a presence probe whenever the user 1787 starts a new presence session by sending initial presence; however, 1788 the server MAY choose not to send the probe at that point if it has 1789 what it deems to be reliable and up-to-date presence information 1790 about the user's contacts (e.g., because the user has another 1791 available resource or because the user briefly logged off and on 1792 before the new presence session began). In addition, a server MAY 1793 periodically send a presence probe to a contact if it has not 1794 received presence information or other traffic from the contact in 1795 some configurable amount of time; this can help to prevent "ghost" 1796 contacts who appear to be online but in fact are not. 1798 US: 1802 US: 1806 Naturally, the user's server does not need to send a presence probe 1807 to a contact if the contact's account resides on the same server as 1808 the user, since the server possesses contact's information locally. 1810 4.3.2. Server Processing of Inbound Presence Probe 1812 Upon receiving a presence probe from the user's server on behalf of 1813 the user, the contact's server SHOULD reply as follows: 1815 1. If the contact account does not exist or the user is in the 1816 contact's roster with a subscription state other than "From", 1817 "From + Pending Out", or "Both" (as defined under Appendix A), 1818 the contact's server MUST return a presence stanza of type 1819 "unsubscribed" in response to the presence probe (however, if a 1820 server receives a presence probe from a configured hostname of 1821 the server itself or another such trusted service, it MAY provide 1822 presence information about the user to that entity). 1824 CS: 1828 2. Else, if the contact has no available resources, the server 1829 SHOULD reply to the presence probe by sending to the user the 1830 full XML of the last presence stanza of type "unavailable" 1831 received by the server from the contact (however, the server MAY 1832 opt to not reply at all). 1833 3. Else, if the contact has at least one available resource, the 1834 server MUST reply to the presence probe by sending to the user 1835 the full XML of the last presence stanza with no 'to' attribute 1836 received by the server from each of the contact's available 1837 resources. 1839 CS: 1842 CS: 1844 away 1845 1847 4.4. Subsequent Presence Broadcast 1849 4.4.1. Client Generation of Presence Broadcast 1851 After sending initial presence, the user's client can update its 1852 availability for broadcasting at any time during its session by 1853 sending a presence stanza with no 'to' address and no 'type' 1854 attribute. 1856 UC: 1857 away 1858 1860 The presence broadcast MAY contain the element, the 1861 element, and one or more instances of the element, 1862 as well as extended content. 1864 However, a user SHOULD send a presence update only to broadcast 1865 information that is relevant to the user's availability for 1866 communication or the communication capabilities of the connected 1867 resource. Information that is not relevant in this way can be of 1868 interest to the user's contacts but SHOULD be sent via other means, 1869 such as the XMPP message stanza. 1871 4.4.2. Server Processing of Outbound Presence 1873 Upon receiving a presence stanza expressing updated availability, the 1874 user's server MUST broadcast the full XML of that presence stanza to 1875 the contacts who meet all of the following criteria: 1877 1. The contact is in the user's roster with a subscription type of 1878 "from" or "both". 1879 2. The last presence stanza received from the contact during the 1880 user's presence session was not of type "error" or "unsubscribe". 1882 As an optimization, if the subscription type is "both", the server 1883 SHOULD send subsequent presence notifications to a contact only if 1884 the contact is online according to the user's server. That is, if 1885 the user's server never received a positive indication that the 1886 contact is online in response to the presence probe it sent to the 1887 contact or if the last presence stanza it received from the contact 1888 during the user's presence session was of type "unavailable", the 1889 user's server SHOULD NOT send subsequent presence notifications from 1890 the user to the contact. This optimization helps to save bandwidth, 1891 since most presence subscriptions are bidirectional and many contacts 1892 will not be online at any given time. 1894 US: 1896 away 1897 1899 US: 1901 away 1902 1904 US: 1906 away 1907 1909 See Section 4.6 regarding rules that supplement the foregoing for 1910 handling of directed presence. 1912 The user's server MUST also send the presence stanza to all of the 1913 user's available resources (including the resource that generated the 1914 presence notification in the first place). 1916 US: 1918 away 1919 1921 US: 1923 away 1924 1926 4.4.3. Server Processing of Inbound Presence 1928 Upon receiving presence from the user, the contact's server MUST 1929 deliver the user's presence stanza to all of the contact's available 1930 resources. 1932 [ ... to resource1 ... ] 1934 CS: 1936 away 1937 1939 [ ... to resource2 ... ] 1941 CS: 1943 away 1944 1946 4.4.4. Client Processing of Inbound Presence 1948 When the contact's client receives presence from the user, it SHOULD 1949 proceed as follows: 1951 1. If the user is in the contact's roster, the client MUST display 1952 the presence information in an appropriate roster interface. 1953 2. If the user is not in the contact's roster but the contact and 1954 the user are actively exchanging message or IQ stanzas, the 1955 contact's client SHOULD display the presence information in the 1956 user interface for that chat session (see also Section 4.6 and 1957 Section 5.1). 1958 3. Otherwise, the client MUST ignore the presence information and 1959 not display it to the contact. 1961 4.5. Unavailable Presence 1963 4.5.1. Client Generation of Unavailable Presence 1965 Before ending its presence session with a server, the user's client 1966 SHOULD gracefully become unavailable by sending UNAVAILABLE PRESENCE, 1967 i.e., a presence stanza that possesses no 'to' attribute and that 1968 possesses a 'type' attribute whose value is "unavailable". 1970 UC: 1972 Optionally, the unavailable presence stanza MAY contain one or more 1973 elements specifying the reason why the user is no longer 1974 available. 1976 UC: 1977 going on vacation 1978 1980 However, the unavailable presence stanza MUST NOT contain the 1981 element or the element, since these elements 1982 apply only to available presence. 1984 4.5.2. Server Processing of Outbound Unavailable Presence 1986 The user's server MUST NOT depend on receiving unavailable presence 1987 from an available resource, since the resource can become unavailable 1988 ungracefully (e.g., the resource can be timed out by the server 1989 because of inactivity). 1991 If an available resource becomes unavailable for any reason (either 1992 gracefully or ungracefully), the user's server MUST broadcast 1993 unavailable presence to all contacts that meet all of the following 1994 criteria: 1996 1. The contact is in the user's roster with a subscription type of 1997 "from" or "both". 1998 2. The last presence stanza received from the contact during the 1999 user's presence session was not of type "error" or "unsubscribe". 2001 See Section 4.6 regarding rules that supplement the foregoing for 2002 handling of directed presence. 2004 The optimization employed for subsequent presence broadcast during 2005 a user's presence session MUST NOT be employed for unavailable 2006 presence broadcast; if it were, the last presence received by the 2007 contact's server would be the user's initial presence for the 2008 presence session, with the result that the contact would consider 2009 the user to be online. 2011 If the unavailable presence stanza was gracefully received from the 2012 client, the server MUST broadcast the full XML of the presence 2013 stanza. 2015 US: 2018 going on vacation 2019 2021 US: 2024 going on vacation 2025 2027 US: 2030 going on vacation 2031 2033 The user's server MUST also send the unavailable presence stanza to 2034 all of the user's available resources (including the resource that 2035 generated the presence notification in the first place). 2037 US: 2040 going on vacation 2041 2043 If the server detects that the user has gone offline ungracefully, 2044 the server MUST generate the unavailable presence broadcast on the 2045 user's behalf. 2047 Note: Any presence stanza with no 'type' attribute and no 'to' 2048 attribute that is sent after sending unavailable presence 2049 broadcast MUST be sent by the user's server to all subscribers 2050 (i.e., MUST be treated as equivalent to initial presence for a new 2051 presence session). 2053 4.5.3. Server Processing of Inbound Unavailable Presence 2055 Upon receiving unavailable presence from the user, the contact's 2056 server MUST deliver the user's presence stanza to all of the 2057 contact's available resources. 2059 [ ... to resource1 ... ] 2061 CS: 2064 going on vacation 2065 2067 [ ... to resource2 ... ] 2069 CS: 2072 going on vacation 2073 2075 If the contact's server is optimizing subsequent presence delivery as 2076 described under Section 4.4, it MUST also note that the user is 2077 unavailable and appropriately update its internal representation of 2078 which entities are online. 2080 4.5.4. Client Processing of Inbound Unavailable Presence 2082 When the contact's client receives unavailable presence from the 2083 user, it SHOULD proceed as follows: 2085 1. If the user is in the contact's roster, the client MUST display 2086 the unavailable presence information in an appropriate roster 2087 interface. 2088 2. If the user is not in the contact's roster but the contact and 2089 the user are actively exchanging message or IQ stanzas, the 2090 contact's client SHOULD display the unavailable presence 2091 information in the user interface for that chat session (see also 2092 Section 4.6 and Section 5.1). 2093 3. Otherwise, the client MUST ignore the unavailable presence 2094 information and not display it to the contact. 2096 4.6. Directed Presence 2098 This section supplements and in some respects modifies the rules for 2099 client and server processing of presence notifications, but only for 2100 the special case of directed presence. 2102 4.6.1. Client Generation of Directed Presence 2104 As noted, directed presence is a presence stanza with a 'to' 2105 attribute whose value is the bare JID or full JID of the other entity 2106 and with either no 'type' attribute (indicating availability) or a 2107 'type' attribute whose value is "unavailable". 2109 Information about the use of directed presence in the context of a 2110 one-to-one chat session is provided under Section 5.1. 2112 4.6.2. Server Processing of Outbound Directed Presence 2114 When the user's server receives a directed presence stanza, it SHOULD 2115 process it according to the following rules. 2117 1. If the user sends directed available or unavailable presence to a 2118 contact that is in the user's roster with a subscription type of 2119 "from" or "both" after having sent initial presence and before 2120 sending unavailable presence broadcast (i.e., during the user's 2121 presence session), the user's server MUST locally deliver or 2122 remotely route the full XML of that presence stanza but SHOULD 2123 NOT otherwise modify the contact's status regarding presence 2124 broadcast (i.e., it SHOULD include the contact's JID in any 2125 subsequent presence broadcasts initiated by the user). 2126 2. If the user sends directed presence to an entity that is not in 2127 the user's roster with a subscription type of "from" or "both" 2128 after having sent initial presence and before sending unavailable 2129 presence broadcast (i.e., during the user's presence session), 2130 the user's server MUST locally deliver or remotely route the full 2131 XML of that presence stanza to the entity but MUST NOT modify the 2132 contact's status regarding available presence broadcast (i.e., it 2133 MUST NOT include the entity's JID in any subsequent broadcasts of 2134 available presence initiated by the user); however, if the 2135 available resource from which the user sent the directed presence 2136 becomes unavailable, the user's server MUST route that 2137 unavailable presence to the entity (if the user has not yet sent 2138 directed unavailable presence to that entity). 2139 3. If the user sends directed presence without first sending initial 2140 presence or after having sent unavailable presence broadcast 2141 (i.e., the resource is connected but not available), the user's 2142 server MUST treat the entity to which the user sends directed 2143 presence as in case #2 above. 2145 4.6.3. Server Processing of Inbound Directed Presence 2147 From the perspective of the contact's server, there is no difference 2148 between presence broadcast and directed presence, so the contact's 2149 server follows the existing rules for processing of inbound presence. 2151 4.6.4. Client Processing of Inbound Directed Presence 2153 When the contact's client receives directed presence from the user, 2154 it SHOULD proceed as follows: 2156 1. If the user is in the contact's roster, the client MUST display 2157 the presence information in an appropriate roster interface. 2158 2. If the user is not in the contact's roster but the contact and 2159 the user are actively exchanging message or IQ stanzas, the 2160 contact's client SHOULD display the presence information in the 2161 user interface for that chat session (see also Section 4.6 and 2162 Section 5.1). 2163 3. Otherwise, the client MUST ignore the presence information and 2164 not display it to the contact. 2166 4.7. Presence Syntax 2168 4.7.1. Type Attribute 2170 The absence of a 'type' attribute signals that the relevant entity is 2171 available for communication (see Section 4.2 and Section 4.4). 2173 A 'type' attribute with a value of "unavailable" signals that the 2174 relevant entity is not available for communication (see Section 4.5). 2176 The XMPP presence stanza is also used to negotiate and manage 2177 subscriptions to the presence of other entities. These tasks are 2178 completed via presence stanzas of type "subscribe", "unsubscribe", 2179 "subscribed", and "unsubscribed" as described under Section 3. 2181 If a user and contact are associated with different XMPP servers, 2182 those servers also use a special presence stanza of type "probe" in 2183 order to determine the availability of the entity on the peer server; 2184 for details, see Section 4.3. Clients SHOULD NOT send presence 2185 stanzas of type "probe". 2187 The values of the 'type' attribute can be summarized as follows: 2189 o error -- An error has occurred regarding processing of a 2190 previously-sent presence stanza; if the presence stanza is of type 2191 "error", it MUST include an child element (refer to 2192 [rfc3920bis]). 2193 o probe -- A request for an entity's current presence; SHOULD be 2194 generated only by a server on behalf of a user. 2195 o subscribe -- The sender wishes to subscribe to the recipient's 2196 presence. 2198 o subscribed -- The sender has allowed the recipient to receive 2199 their presence. 2200 o unavailable -- Signals that the entity is no longer available for 2201 communication. 2202 o unsubscribe -- The sender is unsubscribing from the receiver's 2203 presence. 2204 o unsubscribed -- The subscription request has been denied or a 2205 previously-granted subscription has been cancelled. 2207 If the value of the 'type' attribute is not one of the foregoing 2208 values, the recipient or an intermediate router SHOULD return a 2209 stanza error of . 2211 Note: There is no default value for the 'type' attribute of the 2212 element; in particular, there is no value of 2213 "available". 2215 4.7.2. Child Elements 2217 In accordance with the default namespace declaration, a presence 2218 stanza is qualified by the 'jabber:client' or 'jabber:server' 2219 namespace, which defines certain allowable children of presence 2220 stanzas, in particular the , , and 2221 elements. These child elements are used to provide more detailed 2222 information about an entity's availability. Typically these child 2223 elements are provided only if the presence stanza possesses no 'type' 2224 attribute, although exceptions are noted in the text that follows. 2226 4.7.3. Show Element 2228 The OPTIONAL element specifies the particular availability 2229 sub-state of an entity or a specific resource thereof. A presence 2230 stanza MUST NOT contain more than one element. The 2231 element MUST NOT possess any attributes. The XML character data of 2232 the element is not human-readable. The XML character data 2233 MUST be one of the following (additional availability states could be 2234 defined through a child element of the presence stanza that is 2235 qualified by a namespace other than the default namespace): 2237 o away -- The entity or resource is temporarily away. 2238 o chat -- The entity or resource is actively interested in chatting. 2239 o dnd -- The entity or resource is busy (dnd = "Do Not Disturb"). 2240 o xa -- The entity or resource is away for an extended period (xa = 2241 "eXtended Away"). 2243 If no element is provided, the entity is assumed to be online 2244 and available. 2246 Any specialized processing of availability states by recipients and 2247 intermediate routers is up to the implementation (e.g., incorporation 2248 of availability states into stanza routing and delivery logic). 2250 4.7.4. Status Element 2252 The OPTIONAL element contains human-readable XML character 2253 data specifying a natural-language description of an entity's 2254 availability. It is normally used in conjunction with the show 2255 element to provide a detailed description of an availability state 2256 (e.g., "In a meeting") when the presence stanza has no 'type' 2257 attribute. 2259 2261 dnd 2262 Wooing Juliet 2263 2265 The element MUST NOT possess any attributes, with the 2266 exception of the 'xml:lang' attribute. Multiple instances of the 2267 element MAY be included, but only if each instance 2268 possesses an 'xml:lang' attribute with a distinct language value 2269 (either explicitly or by inheritance from the 'xml:lang' value of an 2270 element farther up in the XML hierarchy, which can include the XML 2271 stream header as described in [rfc3920bis]). 2273 2275 dnd 2276 Wooing Juliet 2277 Dvořím se Julii 2278 2280 A presence stanza of type "unavailable" MAY also include a 2281 element to provide detailed information about why the entity is going 2282 offline. 2284 2287 Busy IRL 2288 2290 The child MAY also be sent in a subscription-related 2291 presence stanza (i.e., type "subscribe", "subscribed", "unsubscribe", 2292 or "unsubscribed") to provide a description of the action. The 2293 receiving client MAY present this information to a human 2294 user (see Section 11). 2296 2299 Hi, Juliet told to add you to my buddy list. 2300 2302 4.7.5. Priority Element 2304 The OPTIONAL element contains non-human-readable XML 2305 character data that specifies the priority level of the resource. 2306 The value MUST be an integer between -128 and +127. A presence 2307 stanza MUST NOT contain more than one element. The 2308 element MUST NOT possess any attributes. 2310 2311 dnd 2312 Wooing Juliet 2313 Dvořím se Julii 2314 1 2315 2317 If no priority is provided, the processing server or client MUST 2318 consider the priority to be zero ("0"). 2320 For information regarding the semantics of priority values in stanza 2321 processing within instant messaging and presence applications, refer 2322 to Section 8. 2324 4.7.6. Extended Content 2326 As described in [rfc3920bis], an XML stanza MAY contain any child 2327 element that is qualified by a namespace other than the default 2328 namespace; this applies to the presence stanza as well. 2330 (In the following example, the presence stanza includes entity 2331 capabilities information as defined in [XEP-0115]).) 2333 2334 2338 2340 Any extended content included in a presence stanza SHOULD represent 2341 aspects of an entity's availability for communication or provide 2342 information about communication-related capabilities. 2344 5. Exchanging Messages 2346 Once a client has authenticated with a server and bound a resource to 2347 an XML stream as described in [rfc3920bis], an XMPP server will route 2348 XML stanzas to and from that client. One kind of stanza that can be 2349 exchanged is (if, that is, messaging functionality is 2350 enabled and the server is not a presence-only service). Exchanging 2351 messages is a basic use of XMPP and occurs when a user generates a 2352 message stanza that is addressed to another entity. As defined under 2353 Section 8, the sender's server is responsible for delivering the 2354 message to the intended recipient (if the recipient is on the same 2355 local server) or for routing the message to the recipient's server 2356 (if the recipient is on a remote server). Thus a message stanza is 2357 used to "push" information to another entity. 2359 5.1. One-to-One Chat Sessions 2361 In practice, instant messaging activity between human users tends to 2362 occur in form of a conversational burst that we call a CHAT SESSION: 2363 the exchange of at least several messages between two parties in 2364 relatively rapid succession within a relatively brief period of time. 2366 When a human user intends to engage in such a chat session with a 2367 contact (rather than sending a single message to which no reply is 2368 expected), the user's client SHOULD send a message of type "chat" and 2369 the contact's client SHOULD preserve that message type in subsequent 2370 replies. The user's client also SHOULD include a element 2371 with its initial message, which the contact's client SHOULD also 2372 preserve during the life of the chat session. 2374 The user's client MUST address the initial message in a chat session 2375 to the bare JID (rather than attempting to guess an 2376 appropriate full JID ). Until and unless 2377 the user's client receives a reply from the contact, it MUST continue 2378 sending any further messages to the contact's bare JID. The 2379 contact's client SHOULD address its subsequent replies to the user's 2380 full JID as provided in the 'from' address of 2381 the initial message. Once the user's client receives a reply from 2382 the contact's full JID, it SHOULD address its subsequent messages to 2383 the contact's full JID as provided in the 'from' address of the 2384 contact's replies. 2386 When two parties engage in a chat session but do not share presence 2387 with each other based on a presence subscription, they SHOULD send 2388 directed presence to each other so that either party can easily 2389 discover if the other party changes its availability or goes offline 2390 during the course of the chat session. However, a client MUST 2391 provide a way for a user to disable such presence sharing globally or 2392 to enable it only with particular entities. Furthermore, a party 2393 SHOULD send directed unavailable to the other party when it has 2394 reason to believe that the chat session is over (e.g., if, after some 2395 reasonable amount of time, no subsequent messages have been exchanged 2396 between the parties). 2398 An example of a chat session is provided under Section 7. 2400 5.2. Message Syntax 2402 The following sections describe the syntax of the stanza. 2404 5.2.1. To Attribute 2406 An instant messaging client specifies an intended recipient for a 2407 message by providing the JID of an entity other than the sender in 2408 the 'to' attribute of the stanza. 2410 If the message is being sent outside the context of any existing chat 2411 session or received message, the value of the 'to' address SHOULD be 2412 of the form rather than of the form 2413 . 2415 2420 Art thou not Romeo, and a Montague? 2421 2423 If the message is being sent in reply to a message previously 2424 received from an address of the form (e.g., 2425 within the context of a one-to-one chat session as described under 2426 Section 5.1), the value of the 'to' address SHOULD be of the form 2427 rather than of the form unless 2428 the sender has knowledge (via presence) that the intended recipient's 2429 resource is no longer available. 2431 2436 Neither, fair saint, if either thee dislike. 2438 2440 5.2.2. Type Attribute 2442 Common uses of the message stanza in instant messaging applications 2443 include: single messages; messages sent in the context of a one-to- 2444 one chat session; messages sent in the context of a multi-user chat 2445 room; alerts, notifications, or other information to which no reply 2446 is expected; and errors. These uses are differentiated via the 2447 'type' attribute. Inclusion of the 'type' attribute is RECOMMENDED. 2448 If included, the 'type' attribute MUST have one of the following 2449 values: 2451 o chat -- The message is sent in the context of a one-to-one chat 2452 session. Typically a receiving client will present message of 2453 type "chat" in an interface that enables one-to-one chat between 2454 the two parties, including an appropriate conversation history. 2455 Detailed recommendations regarding one-to-one chat sessions are 2456 provided under Section 5.1. 2457 o error -- The message is generated by an entity that experiences an 2458 error in processing a message received from another entity (for 2459 details regarding stanza error syntax, refer to [rfc3920bis]). A 2460 client that receives a message of type "error" SHOULD present an 2461 appropriate interface informing the sender of the nature of the 2462 error. 2463 o groupchat -- The message is sent in the context of a multi-user 2464 chat environment (similar to that of [IRC]). Typically a 2465 receiving client will present a message of type "groupchat" in an 2466 interface that enables many-to-many chat between the parties, 2467 including a roster of parties in the chatroom and an appropriate 2468 conversation history. For detailed information about XMPP-based 2469 groupchat, refer to [XEP-0045]. 2470 o headline -- The message provides an alert, a notification, or 2471 other information to which no reply is expected (e.g., news 2472 headlines, sports updates, near-real-time market data, and 2473 syndicated content). Because no reply to the message is expected, 2474 typically a receiving client will present a message of type 2475 "headline" in an interface that appropriately differentiates the 2476 message from standalone messages, chat messages, or groupchat 2477 messages (e.g., by not providing the recipient with the ability to 2478 reply). The receiving server SHOULD deliver the message to all of 2479 the recipient's available resources. 2480 o normal -- The message is a standalone message that is sent outside 2481 the context of a one-to-one conversation or groupchat, and to 2482 which it is expected that the recipient will reply. Typically a 2483 receiving client will present a message of type "normal" in an 2484 interface that enables the recipient to reply, but without a 2485 conversation history. The default value of the 'type' attribute 2486 is "normal". 2488 An IM application SHOULD support all of the foregoing message types. 2489 If an application receives a message with no 'type' attribute or the 2490 application does not understand the value of the 'type' attribute 2491 provided, it MUST consider the message to be of type "normal" (i.e., 2492 "normal" is the default). 2494 Although the 'type' attribute is OPTIONAL, it is considered polite to 2495 mirror the type in any replies to a message; furthermore, some 2496 specialized applications (e.g., a multi-user chat service) MAY at 2497 their discretion enforce the use of a particular message type (e.g., 2498 type='groupchat'). 2500 5.2.3. Body Element 2502 The element contains human-readable XML character data that 2503 specifies the textual contents of the message; this child element is 2504 normally included but is OPTIONAL. 2506 2511 Wherefore art thou, Romeo? 2512 2514 The element MUST NOT possess any attributes, with the 2515 exception of the 'xml:lang' attribute. Multiple instances of the 2516 element MAY be included in a message stanza, but only if each 2517 instance possesses an 'xml:lang' attribute with a distinct language 2518 value (either explicitly or by inheritance from the 'xml:lang' value 2519 of an element farther up in the XML hierarchy, which can include the 2520 XML stream header as described in [rfc3920bis]). 2522 2527 Wherefore art thou, Romeo? 2528 2529 PročeŽ jsi ty, Romeo? 2530 2531 2533 The element MUST NOT contain mixed content (as defined in 2534 Section 3.2.2 of [XML]). 2536 5.2.4. Subject Element 2538 The element contains human-readable XML character data 2539 that specifies the topic of the message. 2541 2546 I implore you! 2547 Wherefore art thou, Romeo? 2548 2550 The element MUST NOT possess any attributes, with the 2551 exception of the 'xml:lang' attribute. Multiple instances of the 2552 element MAY be included for the purpose of providing 2553 alternate versions of the same subject, but only if each instance 2554 possesses an 'xml:lang' attribute with a distinct language value 2555 (either explicitly or by inheritance from the 'xml:lang' value of an 2556 element farther up in the XML hierarchy, which can include the XML 2557 stream header as described in [rfc3920bis]). 2559 2564 I implore you! 2565 2566 Úpěnlivě prosím! 2567 2568 Wherefore art thou, Romeo? 2569 2570 Pročež jsi ty, Romeo? 2571 2572 2574 The element MUST NOT contain mixed content (as defined in 2575 Section 3.2.2 of [XML]). 2577 5.2.5. Thread Element 2579 The primary use of the XMPP element is to uniquely identify 2580 a conversation thread or "chat session" between two entities 2581 instantiated by stanzas of type 'chat'. However, the XMPP 2582 element can also be used to uniquely identify an analogous 2583 thread between two entities instantiated by stanzas of 2584 type 'headline' or 'normal', or among multiple entities in the 2585 context of a multi-user chat room instantiated by stanzas 2586 of type 'groupchat'. It MAY also be used for stanzas not 2587 related to a human conversation, such as a game session or an 2588 interaction between plugins. The element is not used to 2589 identify individual messages, only conversations or messagingg 2590 sessions. 2592 The inclusion of the element is OPTIONAL. Because the 2593 element uniquely identifies the particular conversation 2594 thread to which a message belongs, a message stanza MUST NOT contain 2595 more than one element. 2597 The value of the element is not human-readable and MUST be 2598 treated as opaque by entities; no semantic meaning can be derived 2599 from it, and only exact comparisons can be made against it. The 2600 value of the element MUST be a universally unique 2601 identifier (UUID) as described in [UUID]. 2603 The element MAY possess a 'parent' attribute that 2604 identifies another thread of which the current thread is an offshoot 2605 or child; the value of the 'parent' MUST conform to the syntax of the 2606 element itself. 2608 The element MUST NOT contain mixed content (as defined in 2609 Section 3.2.2 of [XML]). 2611 2616 I implore you! 2617 2618 Úpěnlivě prosím! 2619 2620 Wherefore art thou, Romeo? 2621 2622 Pročež jsi ty, Romeo? 2623 2624 2625 0e3141cd80894871a68e6fe6b1ec56fa 2626 2627 2629 For detailed recommendations regarding use of the element, 2630 refer to [XEP-0201]. 2632 5.3. Extended Content 2634 As described in [rfc3920bis], an XML stanza MAY contain any child 2635 element that is qualified by a namespace other than the default 2636 namespace; this applies to the message stanza as well. 2638 (In the following example, the message stanza includes an XHTML- 2639 formatted version of the message as defined in [XEP-0071]).) 2641 2646 Wherefore art thou, Romeo? 2647 2648 2649 Wherefore art 2650 thou, Romeo? 2651 2652 2653 2655 6. Exchanging IQ Stanzas 2657 As described in [rfc3920bis], IQ stanzas provide a structured 2658 request-response mechanism. The basic semantics of that mechanism 2659 (e.g., that the 'id' attribute is mandatory) are defined in 2660 [rfc3920bis], whereas the specific semantics needed to complete 2661 particular use cases are defined in all instances by the extended 2662 namespace that qualifies the direct child element of an IQ stanza of 2663 type "get" or "set". The 'jabber:client' and 'jabber:server' 2664 namespaces do not define any children of IQ stanzas other than the 2665 element common to all stanza types. This document defines 2666 one such extended namespace, for Managing the Roster (Section 2). 2667 However, an IQ stanza MAY contain structured information qualified by 2668 any extended namespace. 2670 As noted under Section 4.6, if a user exchanges IQ stanzas with 2671 another entity but does not share presence with the entity based on a 2672 presence subscription, it is RECOMMENDED for the user's client to 2673 send directed presence to the other entity. 2675 7. A Sample Session 2677 The examples in this section illustrate a possible instant messaging 2678 and presence session. The user is romeo@example.net, he has an 2679 available resource whose resource identifier is "orchard", and he has 2680 the following individuals in his roster: 2682 o juliet@example.com (subscription="both" and she has two available 2683 resources, one whose resource identifier is "chamber" and another 2684 whose resource identifier is "balcony") 2685 o benvolio@example.net (subscription="to") 2686 o mercutio@example.org (subscription="from") 2688 First, the user completes the preconditions (stream establishment, 2689 TLS and SASL negotiation, and resource binding) described in 2690 [rfc3920bis]; those protocol flows are not reproduced here. 2692 Next, the user requests his roster. 2694 Example 1: User requests current roster from server: 2696 UC: 2699 2700 2702 Example 2: User receives roster from server: 2704 US: 2707 2708 2711 Friends 2712 2713 2716 2719 2720 2722 Now the user begins a presence session. 2724 Example 3: User sends initial presence: 2726 UC: 2728 Example 4: User's server sends presence probes to contacts with 2729 subscription="to" and subscription="both" on behalf of the user's 2730 available resource: 2732 US: 2737 US: 2742 Example 5: User's server sends initial presence to contacts with 2743 subscription="from" and subscription="both" on behalf of the user's 2744 available resource: 2746 US: 2750 US: 2754 Example 6: Contacts' servers reply to presence probe on behalf of all 2755 available resources: 2757 CS: 2761 away 2762 be right back 2763 0 2764 2766 CS: 2769 1 2770 2772 CS: 2776 dnd 2777 gallivanting 2778 2780 Example 7: Contacts' servers deliver user's initial presence to all 2781 available resources: 2783 CS: 2787 CS: 2791 CS: 2795 Example 8: User sends directed presence to another user not in his 2796 roster: 2798 UC: 2802 dnd 2803 courting Juliet 2804 0 2805 2807 Now the user engages in a chat session with one of his contacts. 2809 Example 9: A threaded conversation 2811 CC: 2816 My ears have not yet drunk a hundred words 2817 e0ffe42b28561960c6b12b944a092794b9683a38 2818 2820 CC: 2825 Of that tongue's utterance, yet I know the sound: 2826 e0ffe42b28561960c6b12b944a092794b9683a38 2827 2829 CC: 2834 Art thou not Romeo, and a Montague? 2835 e0ffe42b28561960c6b12b944a092794b9683a38 2836 2838 UC: 2843 Neither, fair saint, if either thee dislike. 2844 e0ffe42b28561960c6b12b944a092794b9683a38 2845 2847 CC: 2852 How cam'st thou hither, tell me, and wherefore? 2853 e0ffe42b28561960c6b12b944a092794b9683a38 2854 2856 And so on. 2858 The user can also send subsequent presence broadcast. 2860 Example 10: User sends updated available presence for broadcasting: 2862 UC: 2863 away 2864 I shall return! 2865 1 2866 2868 Example 11: User's server broadcasts updated presence only to one 2869 contact: 2871 US: 2875 away 2876 I shall return! 2877 1 2878 2880 Example 12: Contact's server delivers updated presence to all of the 2881 contact's available resources ("balcony" and "chamber"): 2883 CS: 2887 away 2888 I shall return! 2889 1 2890 2892 CS: 2896 away 2897 I shall return! 2898 1 2899 2901 Example 13: One of the contact's resources broadcasts unavailable 2902 presence: 2904 CC: 2905 Example 14: Contact's server sends unavailable presence to user: 2907 CS: 2912 Now the user ends his presence session. 2914 Example 15: User sends unavailable presence: 2916 UC: 2919 gone home 2920 2922 Example 16: User's server broadcasts unavailable presence to contacts 2923 as well as to the person to whom the user sent directed presence: 2925 US: 2930 gone home 2931 2933 US: 2938 gone home 2939 2941 Finally the user closes his stream and the server responds in kind. 2943 Example 17: User closes stream: 2945 UC: 2947 Example 18: User's server closes stream: 2949 US: 2951 THE END 2953 8. Server Rules for Processing XML Stanzas 2955 Basic server rules for processing XML stanzas are defined in 2956 [rfc3920bis]. This section defines supplementary rules for XMPP 2957 instant messaging and presence servers; in the absence of a 2958 supplementary rule defined below (e.g., for stanzas without a 'to' 2959 address), the rule defined in [rfc3920bis] applies. 2961 8.1. No Such User 2963 If the user account identified by the 'to' attribute does not exist, 2964 how the stanza is processed depends on the stanza type. 2966 o For an IQ stanza, the server MUST return a 2967 stanza error to the sender. 2968 o For a message stanza, the server MUST return a stanza error to the sender. 2970 o For a presence stanza with no 'type' attribute or a 'type' 2971 attribute of "unavailable", the server MUST silently ignore the 2972 stanza. 2973 o For a presence stanza of type "subscribe", the server MUST return 2974 a presence stanza of type "unsubscribed". 2975 o For a presence stanza of type "subscribed", "unsubscribe", or 2976 "unsubscribed", the server MUST silently ignroe the stanza. 2978 8.2. Full JID at Local Domain 2980 If the hostname of the domain identifier portion of the JID contained 2981 in the 'to' attribute of an inbound stanza matches one of the 2982 configured hostnames of the server itself and the JID contained in 2983 the 'to' attribute is of the form , the server 2984 MUST adhere to the following rules (subject to enforcement of 2985 relevant privacy and security policies, such as those deployed by 2986 means of [XEP-0016] or [XEP-0191]). 2988 8.2.1. Resource Matches 2990 If an available or connected resource exactly matches the full JID, 2991 how the stanza is processed depends on the stanza type. 2993 o For an IQ stanzas of type "get" or "set", if the intended 2994 recipient does not share presence with the requesting entity 2995 either by means of a presence subscription of type "both" or 2996 "from" or by means of directed presence, then the server SHOULD 2997 NOT deliver the IQ stanza but instead SHOULD return a stanza error to the requesting entity. This policy 2999 helps to prevent presence leaks (see Section 11). 3001 o For a message stanza, the server MUST deliver the stanza to the 3002 resource. 3003 o For a presence stanza with no 'type' attribute or a 'type' 3004 attribute of "unavailable", the server MUST deliver the stanza to 3005 the resource. 3006 o For a presence stanza of type "subscribe", the server MUST follow 3007 the guidelines provided under Section 3.1.3. 3008 o For a presence stanza of type "subscribe", "subscribed", 3009 "unsubscribe", or "unsubscribed", the server MUST follow the 3010 guidelines provided under Section 3. 3012 8.2.2. No Resource Matches 3014 If no connected or available resource exactly matches the full JID, 3015 how the stanza is processed depends on the stanza type. 3017 o For an IQ stanza, the server MUST return a 3018 stanza error to the sender. 3019 o For a message stanza, the server SHOULD treat the stanza as if it 3020 were addressed to as described in the next section 3021 (but without modifying the value of the 'to' attribute). 3022 o For a presence stanza with no 'type' attribute or a 'type' 3023 attribute of "unavailable", the server MUST silently ignore the 3024 stanza. 3025 o For a presence stanza of type "subscribe", the server MUST follow 3026 the guidelines provided under Section 3.1.3. 3027 o For a presence stanza of type "subscribed", "unsubscribe", or 3028 "unsubscribed", the server MUST ignore the stanza. 3030 8.3. Bare JID at Local Domain 3032 If the hostname of the domain identifier portion of the JID contained 3033 in the 'to' attribute of an inbound stanza matches one of the 3034 configured hostnames of the server itself and the JID contained in 3035 the 'to' attribute is of the form , the server MUST 3036 adhere to the following rules. 3038 8.3.1. Available or Connected Resources 3040 If there is at least one available or connected resource, how the 3041 stanza is processed depends on the stanza type. 3043 8.3.1.1. Message 3045 For a message stanza of type "headline", the server SHOULD deliver 3046 the stanza to all available resources. 3048 For a message stanza of type "chat" or "normal", the server SHOULD 3049 deliver the stanza to the highest-priority available resource. If 3050 there is not one highest-priority available resource but instead the 3051 highest priority is asserted by two or more available resources, 3052 these resources are said to form a "delivery tie". In the case of a 3053 delivery tie, a server SHOULD deliver the message to all of the tied 3054 resources. However, before delivering the message, a server MAY 3055 remove one or more resources from the tie. Methods for doing so are 3056 outside the scope of this specification, but could include factors 3057 such as the resource's time of connection, time of last network or 3058 application activity, availability as determined by some hierarchy of 3059 values, or user-configured rules. Nevertheless, a server 3060 MUST NOT remove all resources from the tie, and MUST deliver the 3061 message to at least one of the highest-priority resources (subject to 3062 appropriate security policies as described under Section 11 and in 3063 [rfc3920bis]). 3065 For a message stanza of type "groupchat", the server SHOULD NOT 3066 deliver the stanza to any of the available resources but instead 3067 SHOULD return an error to the sender. 3069 For a message stanza of type "error", the server SHOULD silently 3070 discard the message (i.e., neither deliver it to the intended 3071 recipient nor return an error to the sender). 3073 However, for any message type the server MUST NOT deliver the stanza 3074 to any available resource with a negative priority; if the only 3075 available resource has a negative priority, the server SHOULD handle 3076 the message as if there were no available or connected resources as 3077 described under Section 8.3.2. 3079 In all cases, the server MUST NOT rewrite the 'to' attribute (i.e., 3080 it MUST leave it as rather than change it to 3081 ). 3083 8.3.1.2. Presence 3085 For a presence stanza of type "probe", the server MUST handle it 3086 directly as described under Section 4.3. 3088 For a presence stanza with no type or of type "unavailable", the 3089 server MUST deliver the stanza to all available resources. 3091 For a presence stanza of type "subscribe", "subscribed", 3092 "unsubscribe", or "unsubscribed", the server MUST adhere to the rules 3093 defined under Section 3 and summarized under Appendix A. 3095 In all cases, the server MUST NOT rewrite the 'to' attribute (i.e., 3096 it MUST leave it as rather than change it to 3097 ). 3099 8.3.1.3. IQ 3101 For an IQ stanza, the server itself MUST reply on behalf of the user 3102 with either an IQ result or an IQ error, and MUST NOT deliver the IQ 3103 stanza to any of the user's available resources. Specifically, if 3104 the semantics of the qualifying namespace define a reply that the 3105 server can provide on behalf of the user, the server MUST reply to 3106 the stanza on behalf of the user by returning either an IQ stanza of 3107 type "result" or an IQ stanza of type "error" that is appropriate to 3108 the original payload; if not, the server MUST reply with a stanza error. 3111 8.3.2. No Available or Connected Resources 3113 If there are no available or connected resources associated with the 3114 user, how the stanza is processed depends on the stanza type. 3116 8.3.2.1. Message 3118 In order to properly handle message stanzas, it is strongly 3119 RECOMMENDED for an implementation to support OFFLINE STORAGE, i.e., 3120 the server SHOULD store the message stanza on behalf of the user and 3121 deliver it when the user next becomes available. For recommendations 3122 regarding offline message storage refer to [XEP-0160]. 3124 For a message stanza of type "chat" or "normal", the server SHOULD 3125 add the message to offline storage or forward the message to the user 3126 via a non-XMPP messaging system (e.g., to the user's email account). 3127 However, if offline message storage or message forwarding is not 3128 enabled or available (e.g., because a size limit has been reached on 3129 offline messages), the server MUST return a 3130 stanza error to the sender. 3132 For a message stanza of type "headline", according to local service 3133 policies the server MUST either (1) add the message to offline 3134 storage or (2) silently discard the message (i.e., neither deliver it 3135 to the intended recipient nor return an error to the sender). 3137 For a message stanza of type "groupchat", the server SHOULD NOT add 3138 the message to offline storage but instead SHOULD return an error to 3139 the sender. 3141 For a message stanza of type "error", the server MUST NOT add the 3142 message to offline storage but instead SHOULD silently discard the 3143 message (i.e., neither deliver it to the intended recipient nor 3144 return an error to the sender). 3146 8.3.2.2. Presence 3148 For a presence stanza with no type or of type "unavailable" or 3149 "probe", the server SHOULD silently ignore the stanza by not storing 3150 it for later delivery and not replying to it on behalf of the user. 3152 For a presence stanza of type "subscribe", "subscribed", 3153 "unsubscribe", or "unsubscribed", the server MUST adhere to the rules 3154 defined under Section 3 and summarized under Appendix A. 3156 8.3.2.3. IQ 3158 For an IQ stanza, the server itself MUST reply on behalf of the user 3159 with either an IQ result or an IQ error. Specifically, if the 3160 semantics of the qualifying namespace define a reply that the server 3161 can provide on behalf of the user, the server MUST reply to the 3162 stanza on behalf of the user by returning either an IQ stanza of type 3163 "result" or an IQ stanza of type "error" that is appropriate to the 3164 original payload; if not, the server MUST reply with a stanza error. 3167 8.4. Remote Domain 3169 If the hostname of the domain identifier portion of the address 3170 contained in the 'to' attribute of an outbound stanza does not match 3171 a configured hostname of the server itself, the server MUST attempt 3172 to route the stanza to the remote domain. If there exists an active 3173 stream between the two peers, the server MUST route the stanza over 3174 that stream for processing by the peer server. If not, the server 3175 MUST do the following. 3177 First, resolve the hostname of the remote domain (or use a cached 3178 resolution of the remote domain to an IP address). The RECOMMENDED 3179 order of attempted resolutions is as follows: 3181 1. Attempt to resolve the remote hostname using a DNS service 3182 location record [SRV] Service of "xmpp-server" and a Proto of 3183 "tcp", resulting in resource records such as "_xmpp- 3184 server._tcp.example.com.", as specified in [rfc3920bis]. 3185 2. If the "xmpp-server" address record resolution fails, attempt to 3186 resolve the "_im" or "_pres" SRV Service as specified in 3187 [IMP-SRV], using the "_im" Service for stanzas and the 3188 "_pres" Service for stanzas (it is up to the 3189 implementation how to handle stanzas). This will result in 3190 one or more resolutions of the form "_im..example.com." or 3191 "_pres..example.com.", where "" would be a label 3192 registered in the Instant Messaging SRV Protocol Label registry 3193 or the Presence SRV Protocol Label registry: either "_xmpp" for 3194 an XMPP-aware domain or some other IANA-registered label (e.g., 3195 "_simple") for a non-XMPP-aware domain. 3196 3. If both SRV address record resolutions fail, attempt to perform a 3197 normal IPv4/IPv6 address record resolution to determine the IP 3198 address using the "xmpp-server" port of 5269 registered with the 3199 IANA, as specified in [rfc3920bis]. 3201 If the server cannot resolve the remote domain, it MUST return a 3202 stanza error. 3204 Second, negotiate XML streams with the remote domain by following the 3205 process defined in [rfc3920bis]. If the server can resolve the 3206 remote domain but cannot establish streams with the XMPP service at 3207 that domain, it MUST return a stanza error. 3209 Third, route the stanza to the remote domain for processing by the 3210 peer server. 3212 Note: Administrators of server deployments are strongly encouraged 3213 to keep the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records 3214 properly synchronized, since different implementations might 3215 perform the "_im" and "_pres" lookups before the "xmpp-server" 3216 lookup. 3218 9. IM and Presence Compliance Requirements 3220 This section summarizes the specific aspects of the Extensible 3221 Messaging and Presence Protocol that MUST be supported by instant 3222 messaging and presence servers and clients in order to be considered 3223 compliant implementations. All such applications MUST comply with 3224 the requirements specified in [rfc3920bis]. The text in this section 3225 specifies additional compliance requirements for instant messaging 3226 and presence servers and clients (the requirements described here 3227 supplement but do not supersede the core requirements). 3229 Note: A server or client MAY support only presence or instant 3230 messaging; therefore is not necessary to support both if only a 3231 presence service or an instant messaging service is desired. 3233 9.1. Servers 3235 In addition to the core server compliance requirements, an instant 3236 messaging and presence server MUST additionally support all server- 3237 related instant messaging and presence syntax and semantics defined 3238 in this document, including: 3240 o Presence broadcast on behalf of clients as specified under 3241 Section 4 3242 o Presence subscriptions as specified under Section 3 3243 o Roster storage and management as specified under Section 2 3244 o IM-specific routing and delivery rules as specified under 3245 Section 8 3247 9.2. Clients 3249 In addition to the core client compliance requirements, an instant 3250 messaging and presence client MUST additionally support the following 3251 protocols: 3253 o Generation and processing of the IM-specific semantics of XML 3254 stanzas as defined by the XML schemas, including the 'type' 3255 attribute of message and presence stanzas as well as their child 3256 elements (see Section 5 and Section 4) 3257 o All client-related instant messaging syntax and semantics defined 3258 in this document, including presence subscriptions and roster 3259 management (see Section 3 and Section 2) 3261 A client MUST also handle addresses that are encoded as "im:" URIs as 3262 specified in [CPIM] and "pres:" URIs as specified in [CPP], although 3263 it MAY do so by removing the "im:" or "pres:" scheme and entrusting 3264 address resolution to the server as specified under Section 8.4. A 3265 client SHOULD also handle addresses that are encoded as "xmpp:" URIs 3266 and IRIs as specified in [XMPP-URI], although here again it MAY do so 3267 by removing the scheme and entrusting address resolution to the 3268 server. 3270 10. Internationalization Considerations 3272 For internationalization considerations, refer to the relevant 3273 section of [rfc3920bis]. 3275 11. Security Considerations 3277 Core security considerations for XMPP are defined in the relevant 3278 section of [rfc3920bis]. 3280 Additional considerations that apply only to instant messaging and 3281 presence applications of XMPP are defined in several places within 3282 this document; specifically: 3284 o When a server processes an inbound presence stanza of type "probe" 3285 whose intended recipient is a user associated with one of the 3286 server's hostnames, the server MUST NOT reveal the user's presence 3287 if the sender is an entity that is not authorized to receive that 3288 information as determined by presence subscriptions (see 3289 Section 4). 3290 o A user's server MUST NOT leak the user's network availability to 3291 entities who are not authorized to know the user's presence, 3292 either via an explicit subscription as described herein or via an 3293 existing trust relationship (such as presence-enabled user 3294 directories within organizations). 3295 o When a server processes an outbound presence stanza with no type 3296 or of type "unavailable", it MUST follow the rules defined under 3297 Section 4 in order to ensure that such presence information is not 3298 sent to entities that are not authorized to know such information. 3299 o When a server generates an error stanza in response to receiving a 3300 stanza for a user account that does not exist, the use of the 3301 stanza error condition can help protect 3302 against dictionary attacks, since this is the same error condition 3303 that is returned if, for instance, the namespace of an IQ child 3304 element is not understood, or if offline message storage or 3305 message forwarding is not enabled for a domain. However, subtle 3306 differences in the exact XML of error stanzas, as well as in the 3307 timing with which such errors are returned, can enable an attacker 3308 to determine the network presence of a user when more advanced 3309 blocking technologies are not used (see for instance [XEP-0016] 3310 and [XEP-0191]). 3311 o A client MAY ignore the element when contained in a 3312 presence stanza of type "subscribe", "unsubscribe", "subscribed", 3313 or "unsubscribed"; this can help prevent "presence subscription 3314 spam". 3316 12. IANA Considerations 3318 The following sections update the registrations provided in 3319 [RFC3921]. 3321 For a number of related IANA considerations, refer to the relevant 3322 section of [rfc3920bis]. 3324 12.1. Instant Messaging SRV Protocol Label Registration 3326 Address Resolution for Instant Messaging and Presence [IMP-SRV] 3327 defines an Instant Messaging SRV Protocol Label registry for 3328 protocols that can provide services that conform to the "_im" SRV 3329 Service label. Because XMPP is one such protocol, the IANA registers 3330 the "_xmpp" protocol label in the appropriate registry, as follows: 3332 Protocol label: _xmpp 3333 Specification: XXXX 3334 Description: Instant messaging protocol label for the Extensible 3335 Messaging and Presence Protocol (XMPP) as defined by XXXX. 3336 Registrant Contact: IETF, XMPP Working Group, 3338 12.2. Presence SRV Protocol Label Registration 3340 Address Resolution for Instant Messaging and Presence [IMP-SRV] 3341 defines a Presence SRV Protocol Label registry for protocols that can 3342 provide services that conform to the "_pres" SRV Service label. 3343 Because XMPP is one such protocol, the IANA registers the "_xmpp" 3344 protocol label in the appropriate registry, as follows: 3346 Protocol label: _xmpp 3347 Specification: XXXX 3348 Description: Presence protocol label for the Extensible Messaging 3349 and Presence Protocol (XMPP) as defined by XXXX. 3350 Registrant Contact: IETF, XMPP Working Group, 3352 13. References 3354 13.1. Normative References 3356 [IMP-REQS] 3357 Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging 3358 / Presence Protocol Requirements", RFC 2779, 3359 February 2000. 3361 [IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging 3362 and Presence", RFC 3861, August 2004. 3364 [rfc3920bis] 3365 Saint-Andre, P., "Extensible Messaging and Presence 3366 Protocol (XMPP): Core", draft-saintandre-rfc3920bis-09 3367 (work in progress), March 2009. 3369 [SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 3370 specifying the location of services (DNS SRV)", RFC 2782, 3371 February 2000. 3373 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 3374 Requirement Levels", BCP 14, RFC 2119, March 1997. 3376 [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally 3377 Unique IDentifier (UUID) URN Namespace", RFC 4122, 3378 July 2005. 3380 [XML] Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., 3381 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fourth 3382 Edition)", World Wide Web Consortium Recommendation REC- 3383 xml-20060816, August 2006, 3384 . 3386 [XML-NAMES] 3387 Bray, T., Hollander, D., and A. Layman, "Namespaces in 3388 XML", W3C REC-xml-names, January 1999, 3389 . 3391 [XMPP-URI] 3392 Saint-Andre, P., "Internationalized Resource Identifiers 3393 (IRIs) and Uniform Resource Identifiers (URIs) for the 3394 Extensible Messaging and Presence Protocol (XMPP)", 3395 RFC 4622, July 2006. 3397 13.2. Informative References 3399 [CPIM] Peterson, J., "Common Profile for Instant Messaging 3400 (CPIM)", RFC 3860, August 2004. 3402 [CPP] Peterson, J., "Common Profile for Presence (CPP)", 3403 RFC 3859, August 2004. 3405 [IMP-MODEL] 3406 Day, M., Rosenberg, J., and H. Sugano, "A Model for 3407 Presence and Instant Messaging", RFC 2778, February 2000. 3409 [IRC] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, 3410 April 2000. 3412 [IRI] Duerst, M. and M. Suignard, "Internationalized Resource 3413 Identifiers (IRIs)", RFC 3987, January 2005. 3415 [RFC3921] Saint-Andre, P., "Extensible Messaging and Presence 3416 Protocol (XMPP): Instant Messaging and Presence", 3417 RFC 3921, October 2004. 3419 [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and 3420 Security Layer (SASL)", RFC 4422, June 2006. 3422 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 3423 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3425 [XEP-0016] 3426 Millard, P. and P. Saint-Andre, "Privacy Lists", XSF 3427 XEP 0016, February 2007. 3429 [XEP-0045] 3430 Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, 3431 January 2008. 3433 [XEP-0054] 3434 Saint-Andre, P., "vcard-temp", XSF XEP 0054, March 2003. 3436 [XEP-0071] 3437 Saint-Andre, P., "XHTML-IM", XSF XEP 0071, August 2007. 3439 [XEP-0115] 3440 Hildebrand, J., Saint-Andre, P., and R. Troncon, "Entity 3441 Capabilities", XSF XEP 0115, February 2008. 3443 [XEP-0160] 3444 Saint-Andre, P., "Best Practices for Handling Offline 3445 Messages", XSF XEP 0160, January 2006. 3447 [XEP-0191] 3448 Saint-Andre, P., "Simple Communications Blocking", XSF 3449 XEP 0191, February 2007. 3451 [XEP-0201] 3452 Saint-Andre, P., Paterson, I., and K. Smith, "Best 3453 Practices for Message Threads", XSF XEP 0201, 3454 February 2008. 3456 [XML-SCHEMA] 3457 Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, 3458 "XML Schema Part 1: Structures Second Edition", World Wide 3459 Web Consortium Recommendation REC-xmlschema-1-20041028, 3460 October 2004, 3461 . 3463 [VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 3464 RFC 2426, September 1998. 3466 Appendix A. Subscription States 3468 This section provides detailed information about subscription states 3469 and server processing of subscription-related presence stanzas (i.e., 3470 presence stanzas of type "subscribe", "subscribed", "unsubscribe", 3471 and "unsubscribed"). 3473 A.1. Defined States 3475 There are four primary subscription states (note: these states are 3476 described from the perspective of the user, not the contact): 3478 o None -- the user does not have a subscription to the contact's 3479 presence, and the contact does not have a subscription to the 3480 user's presence 3481 o To -- the user has a subscription to the contact's presence, but 3482 the contact does not have a subscription to the user's presence 3483 o From -- the contact has a subscription to the user's presence, but 3484 the user does not have a subscription to the contact's presence 3485 o Both -- both the user and the contact have subscriptions to each 3486 other's presence (i.e., the union of 'from' and 'to') 3488 These states are supplemented by various pending sub-states to yield 3489 nine possible subscription states: 3491 1. "None" = contact and user are not subscribed to each other, and 3492 neither has requested a subscription from the other; this is 3493 reflected in the user's roster by subscription='none' 3494 2. "None + Pending Out" = contact and user are not subscribed to 3495 each other, and user has sent contact a subscription request but 3496 contact has not replied yet; this is reflected in the user's 3497 roster by subscription='none' and ask='subscribe' 3498 3. "None + Pending In" = contact and user are not subscribed to each 3499 other, and contact has sent user a subscription request but user 3500 has not replied yet (note: contact's server SHOULD NOT push or 3501 deliver roster items in this state, but instead SHOULD wait until 3502 user has approved subscription request from contact); this is 3503 reflected in the user's roster by subscription='none' 3504 4. "None + Pending Out+In" = contact and user are not subscribed to 3505 each other, contact has sent user a subscription request but user 3506 has not replied yet, and user has sent contact a subscription 3507 request but contact has not replied yet; this is reflected in the 3508 user's roster by subscription='none' and ask='subscribe' 3509 5. "To" = user is subscribed to contact (one-way); this is reflected 3510 in the user's roster by subscription='to' 3511 6. "To + Pending In" = user is subscribed to contact, and contact 3512 has sent user a subscription request but user has not replied 3513 yet; this is reflected in the user's roster by subscription='to' 3514 7. "From" = contact is subscribed to user (one-way); this is 3515 reflected in the user's roster by subscription='from' 3516 8. "From + Pending Out" = contact is subscribed to user, and user 3517 has sent contact a subscription request but contact has not 3518 replied yet; this is reflected in the user's roster by 3519 subscription='from' and ask='subscribe' 3521 9. "Both" = user and contact are subscribed to each other (two-way); 3522 this is reflected in the user's roster by subscription='both' 3524 A.2. Server Processing of Outbound Presence Subscription Stanzas 3526 Outbound presence subscription stanzas enable the user to manage his 3527 or her subscription to the contact's presence (via the "subscribe" 3528 and "unsubscribe" types), and to manage the contact's access to the 3529 user's presence (via the "subscribed" and "unsubscribed" types). 3531 The following rules apply to outbound routing of the stanza as well 3532 as changes to the user's roster. 3534 Note: The rules for server processing of outbound presence 3535 subscription stanzas are described from the perspective of the 3536 user, not the contact. In addition, "S.N." stands for SHOULD NOT. 3538 A.2.1. Subscribe 3540 Table 1: Processing of outbound "subscribe" stanzas 3542 +-----------------------------------------------------------------+ 3543 | EXISTING STATE | ROUTE? | NEW STATE | 3544 +-----------------------------------------------------------------+ 3545 | "None" | MUST | "None + Pending Out" | 3546 | "None + Pending Out" | MUST | no state change | 3547 | "None + Pending In" | MUST | "None + Pending Out+In" | 3548 | "None + Pending Out+In" | MUST | no state change | 3549 | "To" | MUST | no state change | 3550 | "To + Pending In" | MUST | no state change | 3551 | "From" | MUST | "From + Pending Out" | 3552 | "From + Pending Out" | MUST | no state change | 3553 | "Both" | MUST | no state change | 3554 +-----------------------------------------------------------------+ 3556 Note: A state change to "pending out" includes setting the 'ask' 3557 flag to a value of "subscribe" in the user's roster. 3559 A.2.2. Unsubscribe 3561 Table 2: Processing of outbound "unsubscribe" stanzas 3563 +-----------------------------------------------------------------+ 3564 | EXISTING STATE | ROUTE? | NEW STATE | 3565 +-----------------------------------------------------------------+ 3566 | "None" | MUST | no state change | 3567 | "None + Pending Out" | MUST | "None" | 3568 | "None + Pending In" | MUST | no state change | 3569 | "None + Pending Out+In" | MUST | "None + Pending In" | 3570 | "To" | MUST | "None" | 3571 | "To + Pending In" | MUST | "Pending In" | 3572 | "From" | MUST | no state change | 3573 | "From + Pending Out" | MUST | "From" | 3574 | "Both" | MUST | "From" | 3575 +-----------------------------------------------------------------+ 3577 A.2.3. Subscribed 3579 Table 3: Processing of outbound "subscribed" stanzas 3581 +-----------------------------------------------------------------+ 3582 | EXISTING STATE | ROUTE? | NEW STATE | 3583 +-----------------------------------------------------------------+ 3584 | "None" | S.N. | no state change [1] | 3585 | "None + Pending Out" | S.N. | no state change | 3586 | "None + Pending In" | MUST | "From" | 3587 | "None + Pending Out+In" | MUST | "From + Pending Out" | 3588 | "To" | S.N. | no state change | 3589 | "To + Pending In" | MUST | "Both" | 3590 | "From" | S.N. | no state change | 3591 | "From + Pending Out" | S.N. | no state change | 3592 | "Both" | S.N. | no state change | 3593 +-----------------------------------------------------------------+ 3595 [1] A server MAY note the fact that the user wishes to allow the 3596 contact to be subscribed to the user's presence and automatically 3597 approve any subscription request received from the contact; if it 3598 does so, upon the receiving presence stanza of type "subscribed" from 3599 the user's client it MUST add a roster item for the contact to the 3600 user's roster and set the 'ask' flag to a value of "subscribed". 3601 However, the user's server still SHOULD NOT route the presence stanza 3602 of type "subscribed" to the contact. This optional functionality 3603 applies only if the contact is not already in the user's roster or if 3604 the contact is in the user's roster with a state of "None" (not 3605 including a state of "None + Pending Out"). 3607 A.2.4. Unsubscribed 3609 Table 4: Processing of outbound "unsubscribed" stanzas 3611 +-----------------------------------------------------------------+ 3612 | EXISTING STATE | ROUTE? | NEW STATE | 3613 +-----------------------------------------------------------------+ 3614 | "None" | S.N. | no state change | 3615 | "None + Pending Out" | S.N. | no state change | 3616 | "None + Pending In" | MUST | "None" | 3617 | "None + Pending Out+In" | MUST | "None + Pending Out" | 3618 | "To" | S.N. | no state change | 3619 | "To + Pending In" | MUST | "To" | 3620 | "From" | MUST | "None" | 3621 | "From + Pending Out" | MUST | "None + Pending Out" | 3622 | "Both" | MUST | "To" | 3623 +-----------------------------------------------------------------+ 3625 A.3. Server Processing of Inbound Presence Subscription Stanzas 3627 Inbound presence subscription stanzas request a subscription-related 3628 action from the user (via the "subscribe" type), inform the user of 3629 subscription-related actions taken by the contact (via the 3630 "unsubscribe" type), or enable the user to manage the contact's 3631 access to the user's presence information (via the "subscribed" and 3632 "unsubscribed" types). 3634 The following rules apply to delivery of the inbound stanza as well 3635 as changes to the user's roster. 3637 Note: The rules for server processing of inbound presence 3638 subscription stanzas are described from the perspective of the 3639 user, not the contact. In addition, "S.N." stands for SHOULD NOT. 3641 A.3.1. Subscribe 3643 Table 5: Processing of inbound "subscribe" stanzas 3645 +------------------------------------------------------------------+ 3646 | EXISTING STATE | DELIVER? | NEW STATE | 3647 +------------------------------------------------------------------+ 3648 | "None" | MUST [1] | "None + Pending In" | 3649 | "None + Pending Out" | MUST | "None + Pending Out+In" | 3650 | "None + Pending In" | S.N. | no state change | 3651 | "None + Pending Out+In" | S.N. | no state change | 3652 | "To" | MUST | "To + Pending In" | 3653 | "To + Pending In" | S.N. | no state change | 3654 | "From" | S.N. [2] | no state change | 3655 | "From + Pending Out" | S.N. [2] | no state change | 3656 | "Both" | S.N. [2] | no state change | 3657 +------------------------------------------------------------------+ 3659 [1] If the user previously sent presence of type "subscribed" as 3660 described under Appendix A.2.3, then the server MAY auto-reply with 3661 "subscribed" and change the state to "From" rather than "None + 3662 Pending In". 3664 [2] Server SHOULD auto-reply with "subscribed". 3666 A.3.2. Unsubscribe 3668 When the user's server receives a presence stanza of type 3669 "unsubscribe" for the user from the contact, if the stanza results in 3670 a subscription state change from the user's perspective then the 3671 user's server MUST change the state and SHOULD auto-reply by sending 3672 a presence stanza of type "unsubscribed" to the contact on behalf of 3673 the user. Otherwise the user's server MUST NOT change the state and 3674 SHOULD NOT deliver the stanza. These rules are summarized in the 3675 following table. 3677 Table 6: Processing of inbound "unsubscribe" stanzas 3679 +------------------------------------------------------------------+ 3680 | EXISTING STATE | DELIVER? | NEW STATE | 3681 +------------------------------------------------------------------+ 3682 | "None" | S.N. | no state change | 3683 | "None + Pending Out" | S.N. | no state change | 3684 | "None + Pending In" | S.N. [1] | "None" | 3685 | "None + Pending Out+In" | S.N. [1] | "None + Pending Out" | 3686 | "To" | S.N. | no state change | 3687 | "To + Pending In" | S.N. [1] | "To" | 3688 | "From" | S.N. [1] | "None" | 3689 | "From + Pending Out" | S.N. [1] | "None + Pending Out | 3690 | "Both" | S.N. [1] | "To" | 3691 +------------------------------------------------------------------+ 3693 [1] Server SHOULD auto-reply with "unsubscribed". 3695 A.3.3. Subscribed 3697 When the user's server receives a presence stanza of type 3698 "subscribed" for the user from the contact, if there is no pending 3699 outbound request for access to the contact's presence information, 3700 then it MUST NOT change the subscription state and SHOULD NOT deliver 3701 the stanza to the user. If there is a pending outbound request for 3702 access to the contact's presence information and the inbound presence 3703 stanza of type "subscribed" results in a subscription state change, 3704 then the user's server MUST change the subscription state but SHOULD 3705 NOT deliver the stanza to the user. If the user already has access 3706 to the contact's presence information, the inbound presence stanza of 3707 type "subscribed" does not result in a subscription state change; 3708 therefore the user's server MUST NOT change the subscription state 3709 and SHOULD NOT deliver the stanza to the user. These rules are 3710 summarized in the following table. 3712 Table 7: Processing of inbound "subscribed" stanzas 3714 +------------------------------------------------------------------+ 3715 | EXISTING STATE | DELIVER? | NEW STATE | 3716 +------------------------------------------------------------------+ 3717 | "None" | S.N. | no state change | 3718 | "None + Pending Out" | S.N. | "To" | 3719 | "None + Pending In" | S.N. | no state change | 3720 | "None + Pending Out+In" | S.N. | "To + Pending In" | 3721 | "To" | S.N. | no state change | 3722 | "To + Pending In" | S.N. | no state change | 3723 | "From" | S.N. | no state change | 3724 | "From + Pending Out" | S.N. | "Both" | 3725 | "Both" | S.N. | no state change | 3726 +------------------------------------------------------------------+ 3728 A.3.4. Unsubscribed 3730 When the user's server receives a presence stanza of type 3731 "unsubscribed" for the user from the contact, if there is a pending 3732 outbound request for access to the contact's presence information or 3733 if the user currently has access to the contact's presence 3734 information, then the user's server MUST change the subscription 3735 state but SHOULD NOT deliver the stanza to the user. Otherwise, the 3736 user's server MUST NOT change the subscription state and SHOULD NOT 3737 deliver the stanza. These rules are summarized in the following 3738 table. 3740 Table 8: Processing of inbound "unsubscribed" stanzas 3742 +------------------------------------------------------------------+ 3743 | EXISTING STATE | DELIVER? | NEW STATE | 3744 +------------------------------------------------------------------+ 3745 | "None" | S.N. | no state change | 3746 | "None + Pending Out" | S.N. | "None" | 3747 | "None + Pending In" | S.N. | no state change | 3748 | "None + Pending Out+In" | S.N. | "None + Pending In" | 3749 | "To" | S.N. | "None" | 3750 | "To + Pending In" | S.N. | "None + Pending In" | 3751 | "From" | S.N. | no state change | 3752 | "From + Pending Out" | S.N. | "From" | 3753 | "Both" | S.N. | "From" | 3754 +------------------------------------------------------------------+ 3756 Appendix B. Blocking Communication 3758 Sections 2.3.5 and 5.4.10 of [IMP-REQS] require that a compliant 3759 instant messaging and presence technology must enable a user to block 3760 communications from selected users. Protocols for doing so are 3761 specified in [XEP-0016] and [XEP-0191]. 3763 Appendix C. vCards 3765 Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to 3766 retrieve out-of-band contact information for other users (e.g., 3767 telephone number or email address). An XML representation of the 3768 vCard specification defined in RFC 2426 [VCARD] is in common use 3769 within the Jabber community to provide such information but is out of 3770 scope for this specification (documentation of this protocol is 3771 contained in [XEP-0054]). 3773 Appendix D. XML Schemas 3775 Because validation of XML streams and stanzas is optional, the 3776 following XML schemas are provided for descriptive purposes only. 3777 These schemas are not normative. 3779 The following schemas formally define various XML namespaces used in 3780 the core XMPP protocols, in conformance with [XML-SCHEMA]. For 3781 schemas defining namespaces for XML streams and other core aspects of 3782 XMPP, refer to [rfc3920bis]. 3784 D.1. jabber:client 3786 3788 3794 3797 3798 3799 3800 3801 3802 3803 3804 3805 3808 3810 3811 3814 3817 3820 3823 3824 3825 3826 3827 3828 3829 3830 3831 3832 3833 3834 3835 3837 3838 3839 3840 3841 3842 3843 3844 3845 3847 3848 3849 3850 3851 3852 3853 3854 3855 3857 3858 3859 3860 3861 3864 3865 3866 3867 3869 3870 3871 3872 3873 3874 3875 3876 3877 3880 3882 3883 3886 3889 3892 3893 3894 3895 3896 3897 3898 3899 3900 3901 3902 3903 3904 3905 3906 3907 3909 3910 3911 3912 3913 3914 3915 3916 3917 3918 3920 3921 3922 3923 3924 3925 3926 3927 3928 3930 3931 3932 3933 3934 3935 3937 3939 3940 3941 3942 3944 3947 3948 3951 3954 3957 3958 3959 3960 3961 3962 3963 3964 3965 3966 3967 3968 3969 3971 3972 3973 3974 3975 3977 3978 3979 3980 3981 3982 3983 3984 3985 3986 3987 3988 3989 3990 3992 3994 D.2. jabber:server 3995 3997 4003 4006 4007 4008 4009 4010 4011 4012 4013 4014 4017 4019 4020 4023 4026 4029 4032 4033 4034 4035 4036 4037 4038 4039 4040 4041 4042 4044 4045 4047 4048 4049 4050 4051 4052 4053 4054 4055 4057 4058 4059 4060 4061 4062 4063 4064 4065 4067 4068 4069 4070 4071 4074 4075 4076 4077 4079 4080 4081 4082 4083 4086 4087 4088 4089 4091 4092 4093 4094 4095 4096 4097 4098 4099 4102 4104 4105 4108 4111 4114 4115 4116 4117 4118 4119 4120 4121 4122 4123 4124 4125 4126 4127 4128 4129 4131 4132 4133 4134 4135 4136 4137 4138 4139 4141 4143 4144 4145 4146 4147 4148 4149 4150 4151 4153 4154 4155 4156 4157 4158 4160 4162 4163 4164 4165 4167 4169 4170 4173 4176 4179 4180 4181 4182 4183 4184 4185 4186 4187 4188 4189 4190 4191 4193 4194 4195 4196 4197 4199 4200 4201 4202 4203 4204 4205 4206 4207 4208 4209 4210 4211 4212 4214 4216 D.3. jabber:iq:roster 4218 4220 4226 4227 4228 4229 4232 4233 4234 4236 4237 4238 4239 4242 4243 4244 4245 4246 4247 4248 4249 4250 4251 4252 4253 4254 4255 4256 4257 4258 4259 4260 4261 4262 4263 4264 4265 4267 4269 4271 Appendix E. Differences From RFC 3921 4273 Based on consensus derived from implementation and deployment 4274 experience as well as formal interoperability testing, the following 4275 substantive modifications were made from RFC 3921. 4277 o The protocol for session establishment was determined to be 4278 unnecessary and therefore the content previously defined in 4279 Section 3 of RFC 3921 was removed. However, for the sake of 4280 backward-compatibility server implementations are encouraged to 4281 advertise support for the feature, even though session 4282 establishment is a "no-op". 4284 o In order to more seamlessly repair lack of synchronization in 4285 subscription states between rosters located at different servers, 4286 error handling related to presence probes and presence 4287 notifications was modified to return presence stanzas of type 4288 "unsubscribe" or "unsubscribed" rather than error stanzas. 4289 o Added optional server support for pre-approved presence 4290 subscriptions via presence stanzas of type "subscribed" and the 4291 optional "subscribed" value for the 'ask' flag. 4292 o Added optional 'parent' attribute to element 4293 o The protocol for communications blocking specified in Section 10 4294 of RFC 3921 has been moved to [XEP-0016]. 4296 In addition, numerous changes of an editorial nature were made in 4297 order to more fully specify and clearly explain the protocols. 4299 Appendix F. Copying Conditions 4301 Regarding this entire document or any portion of it, the author makes 4302 no guarantees and is not responsible for any damage resulting from 4303 its use. The author grants irrevocable permission to anyone to use, 4304 modify, and distribute it in any way that does not diminish the 4305 rights of anyone else to use, modify, and distribute it, provided 4306 that redistributed derivative works do not contain misleading author 4307 or version information. Derivative works need not be licensed under 4308 similar terms. 4310 Index 4312 A 4313 Available Resource 37 4315 C 4316 Chat Session 52 4317 Contact 25 4319 D 4320 Directed Presence 37 4322 I 4323 Initial Presence 37 4325 O 4326 Offline Message Storage 69 4328 P 4329 Presence 7 4330 Presence Broadcast 37 4331 Presence Probe 39 4332 Presence Session 37 4333 Presence Subscription 25 4335 R 4336 Roster 7 4337 Roster Get 11 4338 Roster Push 12 4339 Roster Result 13 4340 Roster Set 12 4342 S 4343 Subscription Request 25 4345 U 4346 Unavailable Presence 44 4348 Author's Address 4350 Peter Saint-Andre 4351 Cisco 4353 Email: psaintan@cisco.com