State
Click on the red underlined text to get to the source
... conjunction with the show element to provide a
detailed description of an availability state (e.g., "In a meeting").
The <status/> element MUST NOT possess any attributes, with the
...
... (<contact@example.org/resource>) associated with all of the contact's
available resources, but only if the user is in the contact's roster
with a subscription state of "to" or "both" and the contact has not
blocked inbound presence notifications from the user's bare or full
...
...
1. If the user is not in the contact's roster with a subscription
state of "From", "From + Pending Out", or "Both" (as defined
under Subscription States (Section 9)), the contact's server MUST
return a presence stanza ...
...
* if the user is in the contact's roster with a subscription
state of "None", "None + Pending Out", or "To" (or is not in
the contact's roster at all), the contact's server MUST return
a <forbidden/> stanza ...
...
* if the user is in the contact's roster with a subscription
state of "None + Pending In", "None + Pending Out/In", or "To
+ Pending In", the contact's server MUST return a
<not-authorized/> stanza ...
... 4. As a result, the user's server MUST initiate a second roster push
to all of the user's available resources that have requested the
roster, setting the contact to the pending sub-state of the
'none' subscription state; this pending sub-state ...
... roster, setting the contact to the pending sub-state of the
'none' subscription state; this pending sub-state is denoted by
the inclusion of the ask='subscribe ...
... state of the
'none' subscription state; this pending sub-state is denoted by
the inclusion of the ask='subscribe' attribute in the roster
item ...
... (e.g., by tracking an 'id' attribute) and then choose to resend the
"subscribe" request or revert the roster to its previous state by
sending a presence stanza of type "unsubscribe ...
... is next met; normally this is done by adding a roster item for
the contact to the user's roster, with a state of "None + Pending
In" as defined under Subscription States (Section 9), however a
server SHOULD NOT push or deliver roster items ...
... In" as defined under Subscription States (Section 9), however a
server SHOULD NOT push or deliver roster items in that state to
the contact). No matter when the subscription request is
...
... requested the roster, containing a roster item for the user with
the subscription state set to 'from' (the server MUST send this
even if the contact did not perform a roster set); (2) MUST
return an IQ result ...
... resend the "subscribed" notification or revert the roster to its
previous state by sending a presence stanza of type "unsubscribed" to
...
... receiving the presence stanza of type "subscribed", the user
SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "unsubscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification ...
... the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
From the perspective of the user, there now exists a subscription to
...
... presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification ...
... the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
As a result of this activity, the contact is now in the user's roster
...
...
As a result of this activity, the contact is now in the user's roster
with a subscription state of "none", whereas the user is not in the
contact's roster at all.
...
... to all available resources associated with the contact that have
requested the roster, with the user still in the 'from'
subscription state but with a pending 'to' subscription denoted
by the inclusion of the ask='subscribe' attribute in the roster
item ...
... resend the "subscribe" request or revert the roster to its previous
state by sending a presence stanza of type "unsubscribe" to the user.
...
... (e.g., by tracking an 'id' attribute) and then choose to resend the
subscription request or revert the roster to its previous state by
sending a presence stanza of type "unsubscribed ...
... receiving the presence stanza of type "subscribed", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "unsubscribe" to the user; this step
does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
...
... the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
...
... presence stanza of type "unsubscribed", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "subscribe" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
...
... the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
...
...
As a result of this activity, there has been no change in the
subscription state; i.e., the contact is in the user's roster with a
subscription state of "to" and the user is in the contact's roster
...
... subscription state; i.e., the contact is in the user's roster with a
subscription state of "to" and the user is in the contact's roster
with a subscription state of "from".
...
... subscription state of "to" and the user is in the contact's roster
with a subscription state of "from".
...
... XML that the user sends to make this
happen is the same in all instances, the subsequent subscription
state is different depending on the subscription state obtaining when
the unsubscribe ...
... happen is the same in all instances, the subsequent subscription
state is different depending on the subscription state obtaining when
the unsubscribe "command" is sent. Both possible scenarios are
...
... requests the roster); and (2) MUST deliver the "unsubscribe"
state change notification to the contact:
...
... presence stanza of type "unsubscribe", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... sending a presence stanza of type "subscribed" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
...
... the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
...
... presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification ...
... the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
...
... requests the roster); and (2) MUST deliver the "unsubscribe"
state change notification to the contact:
...
... presence stanza of type "unsubscribe", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "subscribed" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
...
... the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
...
... presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification ...
... the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
Note: Obviously this does not result in removal of the roster item ...
... XML that the contact
sends to make this happen is the same in all instances, the
subsequent subscription state is different depending on the
subscription state obtaining when the cancellation was sent. Both
...
... subsequent subscription state is different depending on the
subscription state obtaining when the cancellation was sent. Both
possible scenarios are described below.
...
... that modified item the next time the user requests the roster);
(2) MUST deliver the "unsubscribed" state change notification to
all of the user's available resources; and (3) MUST deliver the
...
... presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification ...
... the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
...
... that modified item the next time the user requests the roster);
and (2) MUST deliver the "unsubscribed" state change notification
to all of the user's available resources; and (3) MUST deliver
...
... presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza ...
... presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification ...
... the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
Note: Obviously this does not result in removal of the roster item ...
... method for doing so.
The process may be initiated no matter what the current subscription
state is by sending a roster set containing an item for the contact
with the 'subscription' attribute set to a value of "remove":
...
... the contact requests the roster); and (2) MUST also deliver the
"unsubscribe" state change notification to all of the contact's
available resources:
...
... the contact requests the roster); and (2) MUST also deliver the
"unsubscribe" state change notification to all of the contact's
available resources:
...
... Note: When the user removes the contact from the user's roster, the
end state of the contact's roster is that the user is still in the
contact's roster with a subscription state of "none"; in order to
...
... end state of the contact's roster is that the user is still in the
contact's roster with a subscription state of "none"; in order to
completely remove the roster item ...
... has not replied yet (note: contact's server SHOULD NOT push or
deliver roster items in this state, but instead SHOULD wait until
contact has approved subscription request from user)
...
... unsubscribed" to the contact if the stanza does not
result in a subscription state change from the user's perspective,
and MUST NOT make a state change. If the stanza ...
... result in a subscription state change from the user's perspective,
and MUST NOT make a state change. If the stanza results in a
subscription state change ...
... state change. If the stanza results in a
subscription state change, the user's server MUST route the stanza to
...
... route the stanza to
the contact and MUST make the appropriate state change. These rules
are summarized in the following tables.
...
...
+----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
...
... | EXISTING STATE | ROUTE? | NEW STATE |
+----------------------------------------------------------------+
| "None" | no | no state change ...
... STATE |
+----------------------------------------------------------------+
| "None" | no | no state change |
| "None + Pending Out" | no | no state change |
...
... | "None" | no | no state change |
| "None + Pending Out" | no | no state change |
| "None + Pending In" | yes | "From" |
| "None + Pending Out/In" | yes | "From + Pending Out" |
...
... | "None + Pending In" | yes | "From" |
| "None + Pending Out/In" | yes | "From + Pending Out" |
| "To" | no | no state change |
| "To + Pending In" | yes | "Both" |
| "From" | no | no state change ...
... state change |
| "To + Pending In" | yes | "Both" |
| "From" | no | no state change |
| "From + Pending Out" | no | no state change |
...
... | "From" | no | no state change |
| "From + Pending Out" | no | no state change |
| "Both" | no | no state change |
...
... | "From + Pending Out" | no | no state change |
| "Both" | no | no state change |
+----------------------------------------------------------------+
...
...
+----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
...
... | EXISTING STATE | ROUTE? | NEW STATE |
+----------------------------------------------------------------+
| "None" | no | no state change ...
... STATE |
+----------------------------------------------------------------+
| "None" | no | no state change |
| "None + Pending Out" | no | no state change |
...
... | "None" | no | no state change |
| "None + Pending Out" | no | no state change |
| "None + Pending In" | yes | "None" |
| "None + Pending Out/In" | yes | "None + Pending Out" |
...
... | "None + Pending In" | yes | "None" |
| "None + Pending Out/In" | yes | "None + Pending Out" |
| "To" | no | no state change |
| "To + Pending In" | yes | "To" |
| "From" | yes | "None" |
...
... presence stanza of type "subscribed" to the contact on behalf of the
user; this rule enables the contact to resynchronize the subscription
state if needed. These rules are summarized in the following table.
Table 3: Recommended handling of inbound "subscribe ...
...
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
...
... +------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | yes | "None + Pending In" |
...
... | "None" | yes | "None + Pending In" |
| "None + Pending Out" | yes | "None + Pending Out/In" |
| "None + Pending In" | no | no state change |
| "None + Pending Out/In" | no | no state change |
...
... | "None + Pending In" | no | no state change |
| "None + Pending Out/In" | no | no state change |
| "To" | yes | "To + Pending In" |
| "To + Pending In" | no | no state change ...
... state change |
| "To" | yes | "To + Pending In" |
| "To + Pending In" | no | no state change |
| "From" | no * | no state change |
...
... | "To + Pending In" | no | no state change |
| "From" | no * | no state change |
| "From + Pending Out" | no * | no state change |
...
... | "From" | no * | no state change |
| "From + Pending Out" | no * | no state change |
| "Both" | no * | no state change |
...
... | "From + Pending Out" | no * | no state change |
| "Both" | no * | no state change |
+------------------------------------------------------------------+
...
... 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 SHOULD auto-reply by sending a presence stanza of type
...
... "unsubscribe" stanza to the user, and MUST change the state. If no
subscription state change results, the user's server SHOULD NOT
...
... stanza to the user, and MUST change the state. If no
subscription state change results, the user's server SHOULD NOT
deliver the stanza and MUST NOT change the state ...
... state change results, the user's server SHOULD NOT
deliver the stanza and MUST NOT change the state. These rules are
summarized in the following table.
...
...
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
...
... +------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | no | no state change ...
... STATE |
+------------------------------------------------------------------+
| "None" | no | no state change |
| "None + Pending Out" | no | no state change |
...
... | "None" | no | no state change |
| "None + Pending Out" | no | no state change |
| "None + Pending In" | yes * | "None" |
| "None + Pending Out/In" | yes * | "None + Pending Out" |
...
... | "None + Pending In" | yes * | "None" |
| "None + Pending Out/In" | yes * | "None + Pending Out" |
| "To" | no | no state change |
| "To + Pending In" | yes * | "To" |
| "From" | yes * | "None" |
...
... "subscribed" for the user from the contact, it MUST NOT deliver the
stanza to the user and MUST NOT change the subscription state if
there is no pending outbound request for access to the contact's
presence information. If there is a pending outbound request for
...
... presence information. 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,
the user's server MUST deliver the stanza to the user and MUST change
...
... the user's server MUST deliver the stanza to the user and MUST change
the subscription state. If the user already has access to the
contact's presence information, the inbound presence stanza of type
...
... contact's presence information, the inbound presence stanza of type
"subscribed" does not result in a subscription state change;
therefore the user's server SHOULD NOT deliver the stanza to the user
...
... therefore the user's server SHOULD NOT deliver the stanza to the user
and MUST NOT change the subscription state. These rules are
summarized in the following table.
...
...
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
...
... +------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | no | no state change ...
... STATE |
+------------------------------------------------------------------+
| "None" | no | no state change |
| "None + Pending Out" | yes | "To" |
| "None + Pending In" | no | no state change ...
... state change |
| "None + Pending Out" | yes | "To" |
| "None + Pending In" | no | no state change |
| "None + Pending Out/In" | yes | "To + Pending In" |
| "To" | no | no state change ...
... state change |
| "None + Pending Out/In" | yes | "To + Pending In" |
| "To" | no | no state change |
| "To + Pending In" | no | no state change |
...
... | "To" | no | no state change |
| "To + Pending In" | no | no state change |
| "From" | no | no state change |
...
... | "To + Pending In" | no | no state change |
| "From" | no | no state change |
| "From + Pending Out" | yes | "Both" |
| "Both" | no | no state change ...
... state change |
| "From + Pending Out" | yes | "Both" |
| "Both" | no | no state change |
+------------------------------------------------------------------+
...
... unsubscribed" for the user from the contact, it MUST deliver the
stanza to the user and MUST change the subscription state if there is
a pending outbound request for access to the contact's presence
information or if the user currently has access to the contact's
...
... presence information. Otherwise, the user's server SHOULD NOT
deliver the stanza and MUST NOT change the subscription state. These
rules are summarized in the following table.
...
...
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
...
... +------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | no | no state change ...
... STATE |
+------------------------------------------------------------------+
| "None" | no | no state change |
| "None + Pending Out" | yes | "None" |
| "None + Pending In" | no | no state change ...
... state change |
| "None + Pending Out" | yes | "None" |
| "None + Pending In" | no | no state change |
| "None + Pending Out/In" | yes | "None + Pending In" |
| "To" | yes | "None" |
...
... | "To" | yes | "None" |
| "To + Pending In" | yes | "None + Pending In" |
| "From" | no | no state change |
| "From + Pending Out" | yes | "From" |
| "Both" | yes | "From" |
...
... "unsubscribe", or "unsubscribed" (i.e., a subscription state change
notification), in addition to sending the appropriate roster push (or
...
... notification to the
intended recipient at least once. A server MAY require the recipient
to acknowledge receipt of all state change notifications (and MUST
require acknowledgement in the case of subscription requests ...
... notification, as shown in the following table:
Table 7: Acknowledgement of subscription state change notifications
...
... +--------------------------------------------------+
Obviously, given the foregoing subscription state charts, some of the
acknowledgement stanzas will be routed to the contact and result in
...
... acknowledgement stanzas will be routed to the contact and result in
subscription state changes, while others will not. However, any such
stanzas MUST result in the server's no longer sending the
...
... stanzas MUST result in the server's no longer sending the
subscription state notification to the user.
...
... equivalent to sending both of those presence stanzas for purposes of
determining whether to continue sending subscription state change
notifications of type "subscribe ...
... applies).
9. If a change to the subscription state or roster group of a roster
item defined in an active ...
... session, subsequent processing based on that list MUST take into
account the changed state or group (for all resources to which
that list currently applies).
...
... separately), but block communications from everyone else
o block communications from anyone whose subscription state is
'none'
...