Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6121

Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence

Pages: 114
Proposed Standard
Errata
Obsoletes:  3921
Part 5 of 5 – Pages 103 to 114
First   Prev   None

Top   ToC   RFC6121 - Page 103   prevText

Appendix A. Subscription States

This section provides detailed information about subscription states and server processing of subscription-related presence stanzas (i.e., presence stanzas of type "subscribe", "subscribed", "unsubscribe", and "unsubscribed").

A.1. Defined States

There are four primary subscription states (these states are described from the perspective of the user, not the contact): None: The user does not have a subscription to the contact's presence, and the contact does not have a subscription to the user's presence. To: The user has a subscription to the contact's presence, but the contact does not have a subscription to the user's presence. From: The contact has a subscription to the user's presence, but the user does not have a subscription to the contact's presence. Both: Both the user and the contact have subscriptions to each other's presence (i.e., the union of 'from' and 'to'). Implementation Note: For the purpose of processing subscription- related presence stanzas as described in the following sections, a subscription state of "None" includes the case of the contact not being in the user's roster at all, i.e., an unknown entity from the perspective of the user's roster. The foregoing states are supplemented by various sub-states related to pending inbound and outbound subscriptions, thus yielding nine possible subscription states: 1. "None" = Contact and user are not subscribed to each other, and neither has requested a subscription from the other; this is reflected in the user's roster by subscription='none'. 2. "None + Pending Out" = Contact and user are not subscribed to each other, and user has sent contact a subscription request but contact has not replied yet; this is reflected in the user's roster by subscription='none' and ask='subscribe'. 3. "None + Pending In" = Contact and user are not subscribed to each other, and contact has sent user a subscription request but user has not replied yet. This state might or might not be reflected in the user's roster, as follows: if the user has created a
Top   ToC   RFC6121 - Page 104
       roster item for the contact then the server MUST maintain that
       roster item and also note the existence of the inbound presence
       subscription request, whereas if the user has not created a
       roster item for the contact then the user's server MUST note the
       existence of the inbound presence subscription request but MUST
       NOT create a roster item for the contact (instead, the server
       MUST wait until the user has approved the subscription request
       before adding the contact to the user's roster).

   4.  "None + Pending Out+In" = Contact and user are not subscribed to
       each other, contact has sent user a subscription request but user
       has not replied yet, and user has sent contact a subscription
       request but contact has not replied yet; this is reflected in the
       user's roster by subscription='none' and ask='subscribe'.

   5.  "To" = User is subscribed to contact (one-way); this is reflected
       in the user's roster by subscription='to'.

   6.  "To + Pending In" = User is subscribed to contact, and contact
       has sent user a subscription request but user has not replied
       yet; this is reflected in the user's roster by subscription='to'.

   7.  "From" = Contact is subscribed to user (one-way); this is
       reflected in the user's roster by subscription='from'.

   8.  "From + Pending Out" = Contact is subscribed to user, and user
       has sent contact a subscription request but contact has not
       replied yet; this is reflected in the user's roster by
       subscription='from' and ask='subscribe'.

   9.  "Both" = User and contact are subscribed to each other (two-way);
       this is reflected in the user's roster by subscription='both'.

A.2. Server Processing of Outbound Presence Subscription Stanzas

Outbound presence subscription stanzas enable the user to manage his or her subscription to the contact's presence (via the "subscribe" and "unsubscribe" types), and to manage the contact's access to the user's presence (via the "subscribed" and "unsubscribed" types). The following rules apply to outbound routing of the stanza as well as changes to the user's roster. (These rules are described from the perspective of the user, not the contact. In addition, "S.N." stands for SHOULD NOT and "M.N." stands for MUST NOT.)
Top   ToC   RFC6121 - Page 105

A.2.1. Subscribe

Table 2: Processing of outbound "subscribe" stanzas +------------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +------------------------------------------------------------------+ | "None" | MUST [1] | "None + Pending Out" | | "None + Pending Out" | MUST | no state change | | "None + Pending In" | MUST [1] | "None + Pending Out+In" | | "None + Pending Out+In" | MUST | no state change | | "To" | MUST | no state change | | "To + Pending In" | MUST | no state change | | "From" | MUST [1] | "From + Pending Out" | | "From + Pending Out" | MUST | no state change | | "Both" | MUST | no state change | +------------------------------------------------------------------+ [1] A state change to "pending out" includes setting the 'ask' flag to a value of "subscribe" in the user's roster.

A.2.2. Unsubscribe

Table 3: Processing of outbound "unsubscribe" stanzas +-----------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +-----------------------------------------------------------------+ | "None" | MUST | no state change | | "None + Pending Out" | MUST | "None" | | "None + Pending In" | MUST | no state change | | "None + Pending Out+In" | MUST | "None + Pending In" | | "To" | MUST | "None" | | "To + Pending In" | MUST | "None + Pending In" | | "From" | MUST | no state change | | "From + Pending Out" | MUST | "From" | | "Both" | MUST | "From" | +-----------------------------------------------------------------+
Top   ToC   RFC6121 - Page 106

A.2.3. Subscribed

Table 4: Processing of outbound "subscribed" stanzas +-----------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +-----------------------------------------------------------------+ | "None" | M.N. | pre-approval [1] | | "None + Pending Out" | M.N. | pre-approval [1] | | "None + Pending In" | MUST | "From" | | "None + Pending Out+In" | MUST | "From + Pending Out" | | "To" | M.N. | pre-approval [1] | | "To + Pending In" | MUST | "Both" | | "From" | M.N. | no state change | | "From + Pending Out" | M.N. | no state change | | "Both" | M.N. | no state change | +-----------------------------------------------------------------+ [1] Detailed information regarding subscription pre-approval is provided under Section 3.4.

A.2.4. Unsubscribed

Table 5: Processing of outbound "unsubscribed" stanzas +-----------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +-----------------------------------------------------------------+ | "None" | S.N. | no state change [1] | | "None + Pending Out" | S.N. | no state change [1] | | "None + Pending In" | MUST | "None" | | "None + Pending Out+In" | MUST | "None + Pending Out" | | "To" | S.N. | no state change [1] | | "To + Pending In" | MUST | "To" | | "From" | MUST | "None" | | "From + Pending Out" | MUST | "None + Pending Out" | | "Both" | MUST | "To" | +-----------------------------------------------------------------+ [1] This event can result in cancellation of a subscription pre- approval, as described under Section 3.4.

A.3. Server Processing of Inbound Presence Subscription Stanzas

Inbound presence subscription stanzas request a subscription-related action from the user (via the "subscribe" type), inform the user of subscription-related actions taken by the contact (via the
Top   ToC   RFC6121 - Page 107
   "unsubscribe" type), or enable the user to manage the contact's
   access to the user's presence information (via the "subscribed" and
   "unsubscribed" types).

   The following rules apply to delivery of the inbound stanza as well
   as changes to the user's roster.  (These rules for server processing
   of inbound presence subscription stanzas are described from the
   perspective of the user, not the contact.  In addition, "S.N." stands
   for SHOULD NOT.)

A.3.1. Subscribe

Table 6: Processing of inbound "subscribe" stanzas +------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | MUST [1] | "None + Pending In" | | "None + Pending Out" | MUST | "None + Pending Out+In" | | "None + Pending In" | S.N. | no state change | | "None + Pending Out+In" | S.N. | no state change | | "To" | MUST | "To + Pending In" | | "To + Pending In" | S.N. | no state change | | "From" | S.N. [2] | no state change | | "From + Pending Out" | S.N. [2] | no state change | | "Both" | S.N. [2] | no state change | +------------------------------------------------------------------+ [1] If the user previously sent presence of type "subscribed" as described under Appendix A.2.3 and Section 3.4, then the server MAY auto-reply with "subscribed" and change the state to "From" rather than "None + Pending In". [2] Server SHOULD auto-reply with "subscribed".

A.3.2. Unsubscribe

When the user's server receives a presence stanza of type "unsubscribe" for the user from the contact, if the stanza results in a subscription state change from the user's perspective then the user's server MUST change the state, MUST deliver the presence stanza from the contact to the user, and SHOULD auto-reply by sending a presence stanza of type "unsubscribed" to the contact on behalf of the user. Otherwise the user's server MUST NOT change the state and (because there is no state change) SHOULD NOT deliver the stanza. These rules are summarized in the following table.
Top   ToC   RFC6121 - Page 108
   Table 7: Processing of inbound "unsubscribe" stanzas

   +------------------------------------------------------------------+
   |  EXISTING STATE          |  DELIVER?  |  NEW STATE               |
   +------------------------------------------------------------------+
   |  "None"                  |  S.N.      |  no state change         |
   |  "None + Pending Out"    |  S.N.      |  no state change         |
   |  "None + Pending In"     |  MUST [1]  |  "None"                  |
   |  "None + Pending Out+In" |  MUST [1]  |  "None + Pending Out"    |
   |  "To"                    |  S.N.      |  no state change         |
   |  "To + Pending In"       |  MUST [1]  |  "To"                    |
   |  "From"                  |  MUST [1]  |  "None"                  |
   |  "From + Pending Out"    |  MUST [1]  |  "None + Pending Out"    |
   |  "Both"                  |  MUST [1]  |  "To"                    |
   +------------------------------------------------------------------+

   [1] Server SHOULD auto-reply with "unsubscribed".

A.3.3. Subscribed

When the user's server receives a presence stanza of type "subscribed" for the user from the contact, if there is no pending outbound request for access to the contact's presence information, then it MUST NOT change the subscription state and (because there is no state change) SHOULD NOT deliver the stanza to the user. If there is a pending outbound request for access to the contact's presence information and the inbound presence stanza of type "subscribed" results in a subscription state change, then the user's server MUST change the subscription state and MUST deliver the stanza to the user. If the user already is subscribed to the contact's presence information, the inbound presence stanza of type "subscribed" does not result in a subscription state change; therefore the user's server MUST NOT change the subscription state and (because there is no state change) SHOULD NOT deliver the stanza to the user. These rules are summarized in the following table.
Top   ToC   RFC6121 - Page 109
   Table 8: Processing of inbound "subscribed" stanzas

   +------------------------------------------------------------------+
   |  EXISTING STATE          |  DELIVER?  |  NEW STATE               |
   +------------------------------------------------------------------+
   |  "None"                  |  S.N.      |  no state change         |
   |  "None + Pending Out"    |  MUST      |  "To"                    |
   |  "None + Pending In"     |  S.N.      |  no state change         |
   |  "None + Pending Out+In" |  MUST      |  "To + Pending In"       |
   |  "To"                    |  S.N.      |  no state change         |
   |  "To + Pending In"       |  S.N.      |  no state change         |
   |  "From"                  |  S.N.      |  no state change         |
   |  "From + Pending Out"    |  MUST      |  "Both"                  |
   |  "Both"                  |  S.N.      |  no state change         |
   +------------------------------------------------------------------+

A.3.4. Unsubscribed

When the user's server receives a presence stanza of type "unsubscribed" for the user from the contact, if there is a pending outbound request for access to the contact's presence information or if the user currently is subscribed to the contact's presence information, then the user's server MUST change the subscription state and MUST deliver the stanza to the user. Otherwise, the user's server MUST NOT change the subscription state and (because there is no state change) SHOULD NOT deliver the stanza. These rules are summarized in the following table. Table 9: Processing of inbound "unsubscribed" stanzas +------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | S.N. | no state change | | "None + Pending Out" | MUST | "None" | | "None + Pending In" | S.N. | no state change | | "None + Pending Out+In" | MUST | "None + Pending In" | | "To" | MUST | "None" | | "To + Pending In" | MUST | "None + Pending In" | | "From" | S.N. | no state change | | "From + Pending Out" | MUST | "From" | | "Both" | MUST | "From" | +------------------------------------------------------------------+
Top   ToC   RFC6121 - Page 110

Appendix B. Blocking Communication

Sections 2.3.5 and 5.4.10 of [IMP-REQS] require that a compliant instant messaging and presence technology needs to enable a user to block communications from selected users. Protocols for doing so are specified in [XEP-0016] and [XEP-0191].

Appendix C. vCards

Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to retrieve out-of-band contact information for other users (e.g., telephone number or email address). An XML representation of the vCard specification defined in RFC 2426 [VCARD] is in common use within the XMPP community to provide such information but is out of scope for this specification (documentation of this protocol is contained in [XEP-0054]).

Appendix D. XML Schema for jabber:iq:roster

The following schema formally defines the 'jabber:iq:roster' namespace used in this document, in conformance with [XML-SCHEMA]. Because validation of XML streams and stanzas is optional, this schema is not normative and is provided for descriptive purposes only. For schemas defining core XMPP namespaces, refer to [XMPP-CORE]. <?xml version='1.0' encoding='UTF-8'?> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:iq:roster' xmlns='jabber:iq:roster' elementFormDefault='qualified'> <xs:element name='query'> <xs:complexType> <xs:sequence> <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> <xs:attribute name='ver' type='xs:string' use='optional'/> </xs:complexType> </xs:element>
Top   ToC   RFC6121 - Page 111
     <xs:element name='item'>
       <xs:complexType>
         <xs:sequence>
           <xs:element ref='group'
                       minOccurs='0'
                       maxOccurs='unbounded'/>
         </xs:sequence>
         <xs:attribute name='approved'
                       type='xs:boolean'
                       use='optional'/>
         <xs:attribute name='ask'
                       use='optional'>
           <xs:simpleType>
             <xs:restriction base='xs:NMTOKEN'>
               <xs:enumeration value='subscribe'/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
         <xs:attribute name='jid'
                       type='xs:string'
                       use='required'/>
         <xs:attribute name='name'
                       type='xs:string'
                       use='optional'/>
         <xs:attribute name='subscription'
                       use='optional'
                       default='none'>
           <xs:simpleType>
             <xs:restriction base='xs:NMTOKEN'>
               <xs:enumeration value='both'/>
               <xs:enumeration value='from'/>
               <xs:enumeration value='none'/>
               <xs:enumeration value='remove'/>
               <xs:enumeration value='to'/>
             </xs:restriction>
           </xs:simpleType>
         </xs:attribute>
       </xs:complexType>
     </xs:element>

     <xs:element name='group' type='xs:string'/>

   </xs:schema>
Top   ToC   RFC6121 - Page 112

Appendix E. Differences From RFC 3921

Based on consensus derived from implementation and deployment experience as well as formal interoperability testing, the following substantive modifications were made from [RFC3921] (in addition to numerous changes of an editorial nature). o The protocol for session establishment was determined to be unnecessary and therefore the content previously defined in Section 3 of RFC 3921 was removed. However, for the sake of backward-compatibility server implementations are encouraged to advertise support for the feature, even though session establishment is a "no-op". o In order to more seamlessly repair lack of synchronization in subscription states between rosters located at different servers, clarified and modified error handling related to presence subscription requests, presence probes and presence notifications. o Changed the 'from' address for presence probes so that it is the bare JID, not the full JID. o Adjusted and clarified stanza delivery rules based on implementation and deployment experience. o Explicitly specified that a server is allowed to deliver a message stanza of type "normal" or "chat" to all resources if it has a method for allowing resources to opt in to such behavior. o Allowed a server to use its own algorithm for determining the "most available" resource for the purpose of message delivery, but mentioned the recommended algorithm from RFC 3921 (based on presence priority) as one possible algorithm. o Added optional versioning of roster information to save bandwidth in cases where the roster has not changed (or has changed very little) between sessions; the relevant protocol interactions were originally described in [XEP-0237]. o Added optional server support for pre-approved presence subscriptions via presence stanzas of type "subscribed", including a new 'approved' attribute that can be set to "true" (for a pre- approved subscription) or "false" (the default). o Added optional 'parent' attribute to <thread/> element.
Top   ToC   RFC6121 - Page 113
   o  Moved the protocol for communications blocking (specified in
      Section 10 of RFC 3921) back to [XEP-0016], from which it was
      originally taken.

   o  Recommended returning presence unavailable in response to probes.

   o  Clarified handling of presence probes sent to full JIDs.

   o  Explicitly specified that the default value for the presence
      <priority/> element is zero.

   o  Removed recommendation to support the "_im" and "_pres" SRV
      records.

Appendix F. Acknowledgements

This document is an update to, and derived from, RFC 3921. This document would have been impossible without the work of the contributors and commenters acknowledged there. Hundreds of people have provided implementation feedback, bug reports, requests for clarification, and suggestions for improvement since publication of RFC 3921. Although the document editor has endeavored to address all such feedback, he is solely responsible for any remaining errors and ambiguities. Some of the text about roster versioning was borrowed from [XEP-0237], and some of the text about message threads was borrowed from [XEP-0201]. Special thanks are due to Kevin Smith, Matthew Wild, Dave Cridland, Waqas Hussain, Philipp Hancke, Florian Zeitz, Jonas Lindberg, Jehan Pages, Tory Patnoe, and others for their comments during Working Group Last Call. Thanks also to Richard Barnes for his review on behalf of the Security Directorate. The Working Group chairs were Ben Campbell and Joe Hildebrand. The responsible Area Director was Gonzalo Camarillo.
Top   ToC   RFC6121 - Page 114

Author's Address

Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA Phone: +1-303-308-3282 EMail: psaintan@cisco.com