RFC 6121
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
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
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.)
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" | +-----------------------------------------------------------------+
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
"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.
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.
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" | +------------------------------------------------------------------+
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>
<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>
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.
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.
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