tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6121

 
 
 

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

Part 5 of 5, p. 103 to 114
Prev RFC Part

 


prevText      Top      Up      ToC       Page 103 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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