subscribe
Click on the red underlined text to get to the source
... subscription request is a presence stanza whose 'type' attribute
has a value of "subscribe". If the subscription request is being
sent to an instant messaging ...
... it.) However, if the user receives a presence stanza of type
"subscribe" from a contact to whom the user has already granted
permission to see the user's presence information (e.g., in cases
when the contact is seeking to resynchronize subscription states),
...
... entity's presence is made by
sending a presence stanza of type "subscribe".
Example: Sending a subscription request ...
... subscription request:
<presence to='juliet@example.com' type='subscribe'/>
For client and server ...
... User Subscribes to Contact ...
...
The process by which a user subscribes to a contact, including the
interaction between roster items and subscription states, is
...
... presence information, the user's client MUST send a presence
stanza of type='subscribe' to the contact:
<presence to='contact@example.org' type='subscribe ...
... subscribe' to the contact:
<presence to='contact@example.org' type='subscribe'/>
4. As a result, the user's server MUST initiate a second roster push
...
... state; this pending sub-state is denoted by
the inclusion of the ask='subscribe' attribute in the roster
item:
...
... 5. The user's server MUST also stamp the presence stanza of type
"subscribe" with the user's bare JID (i.e., <user@example.com>)
as the 'from' address ...
... from='user@example.com'
to='contact@example.org'
type='subscribe'/>
Note: If the user's server receives a presence stanza ...
... client MAY determine that the error is in response to the
outgoing presence stanza of type "subscribe" it sent previously
(e.g., by tracking an 'id' attribute) and then choose to resend the
"subscribe ...
... subscribe" it sent previously
(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 ...
... 6. Upon receiving the presence stanza of type "subscribe" addressed
to the contact, the contact's server MUST determine if there is
at least one available resource from which the contact has
...
... to the user, the user's server MUST first verify that the contact
is in the user's roster with either of the following states: (a)
subscription='none' and ask='subscribe' or (b)
subscription='from' and ask='subscribe'. If the contact is not
...
... subscription='none' and ask='subscribe' or (b)
subscription='from' and ask='subscribe'. If the contact is not
in the user's roster with either of those states, the user's
server MUST silently ignore the presence stanza ...
... notification through either "affirming" it by sending a presence
stanza of type "subscribe" to the contact or "denying" it by
sending a presence stanza of type "unsubscribe ...
...
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
...
... this automatically):
<presence to='user@example.com' type='subscribe'/>
2. As a result, the contact's server (1) MUST initiate a roster push
...
... subscription state but with a pending 'to' subscription denoted
by the inclusion of the ask='subscribe' attribute in the roster
item; and (2) MUST route the presence stanza ...
... roster
item; and (2) MUST route the presence stanza of type "subscribe"
to the user, first stamping the 'from' address as the bare JID ...
... from='contact@example.org'
to='user@example.com'
type='subscribe'/>
Note: If the contact's server receives a presence stanza ...
... client MAY determine that the error is in response
to the outgoing presence stanza of type "subscribe" it sent
previously (e.g., by tracking an 'id' attribute) and then choose to
resend the "subscribe ...
... subscribe" it sent
previously (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 ...
... 3. Upon receiving the presence stanza of type "subscribe" addressed
to the user, the user's server must determine if there is at
least one available resource for which the user has requested the
...
... to the contact, the contact's server MUST first verify that the
user is in the contact's roster with either of the following
states: (a) subscription='none' and ask='subscribe' or (b)
subscription='from' and ask='subscribe'. If the user is not in
...
... states: (a) subscription='none' and ask='subscribe' or (b)
subscription='from' and ask='subscribe'. If the user is not in
the contact's roster with either of those states, the contact's
server MUST silently ignore the presence stanza ...
... notification through either "affirming" it by sending a presence
stanza of type "subscribe" to the user or "denying" it by sending
a presence stanza of type "unsubscribe ...
... unsubscribe" to the user or "denying" it by
sending a presence stanza of type "subscribe" to the user; this
step does not necessarily affect the subscription state (see
...
... unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
...
... unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
...
... unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state ...
... unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
...
... presence stanzas (i.e.,
presence stanzas of type "subscribe", "subscribed", "unsubscribe",
and "unsubscribed ...
... stanzas enable the user to manage his
or her subscription to the contact's presence information (via the
"subscribe" and "unsubscribe" types), and to manage the contact's
access to the user's presence information (via the "subscribed" and
...
... route all outbound presence stanzas of
type "subscribe" or "unsubscribe" to the contact so that the user is
able to resynchronize his or her subscription to the contact's
...
... 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 ...
... subscription request for the user
from the contact (i.e., a presence stanza of type "subscribe"), it
MUST deliver that request to the user for approval if the user has
not already granted the contact access to the user's presence
...
... information, the user's server SHOULD auto-reply to an inbound
presence stanza of type "subscribe" from the contact by sending a
presence stanza of type "subscribed" to the contact on behalf of the
...
... state if needed. These rules are summarized in the following table.
Table 3: Recommended handling of inbound "subscribe" stanzas
...
...
When a server receives an inbound presence stanza of type "subscribe"
(i.e., a subscription request) or of type "subscribed",
...
... subscription requests, i.e.,
presence stanzas of type "subscribe"). In order to require
acknowledgement, a server SHOULD send the request or notification to
...
... DENY |
+--------------------------------------------------+
| subscribe | subscribed | unsubscribed |
| subscribed | subscribe ...
... subscribe | subscribed | unsubscribed |
| subscribed | subscribe | unsubscribe |
| unsubscribe ...
... | unsubscribed | unsubscribe | subscribe |
+--------------------------------------------------+
...
... creates an available resource); in
addition, the server MUST continue to deliver presence
stanzas of type "subscribe" until the user either approves or
denies the subscription request (see also Presence
Subscriptions ...
... <xs:enumeration value='probe'/>
<xs:enumeration value='subscribe'/>
<xs:enumeration value='subscribed'/>
<xs:enumeration value='unavailable ...
... <xs:enumeration value='probe'/>
<xs:enumeration value='subscribe'/>
<xs:enumeration value='subscribed'/>
<xs:enumeration value='unavailable ...
... <xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='subscribe'/>
</xs:restriction>
</xs:simpleType>
...