draft-ietf-xmpp-im-21.txt

pwlib源码库

       from a subdomain of the server's hostname or another such trusted
       service, it MAY provide presence information about the user to
       that entity).  Specifically:

       *  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 error in response to the presence probe.

       *  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 error in response to the presence
          probe.

   2.  Else, if the contact is blocking presence notifications to the
       user's bare JID or full JID (using either a default list or
       active list as defined under Blocking Outbound Presence
       Notifications (Section 10.11)), the server MUST NOT reply to the
       presence probe.

   3.  Else, if the contact has no available resources, the server MUST
       either (1) reply to the presence probe by sending to the user the
       full XML of the last presence stanza of type "unavailable"
       received by the server from the contact, or (2) not reply at all.

   4.  Else, if the contact has at least one available resource, the
       server MUST reply to the presence probe by sending to the user
       the full XML of the last presence stanza with no 'to' attribute
       received by the server from each of the contact's available
       resources (again, subject to privacy lists in force for each
       session).







Saint-Andre (ed.)      Expires September 19, 2004              [Page 19]

Internet-Draft                  XMPP IM                       March 2004


5.1.4 Directed Presence

   A user MAY send directed presence to another entity (i.e., a presence
   stanza with a 'to' attribute whose value is the JID of the other
   entity and with either no 'type' attribute or a 'type' attribute
   whose value is "unavailable").  There are three possible cases:

   1.  If the user sends directed presence to a contact that is in the
       user's roster with a subscription type of "from" or "both" after
       having sent initial presence and before sending unavailable
       presence broadcast, the user's server MUST route or deliver the
       full XML of that presence stanza (subject to privacy lists) but
       SHOULD NOT otherwise modify the contact's status regarding
       presence broadcast (i.e., it SHOULD include the contact's JID in
       any subsequent presence broadcasts initiated by the user).

   2.  If the user sends directed presence to an entity that is not in
       the user's roster with a subscription type of "from" or "both"
       after having sent initial presence and before sending unavailable
       presence broadcast, the user's server MUST route or deliver the
       full XML of that presence stanza to the entity but MUST NOT
       modify the contact's status regarding available presence
       broadcast (i.e., it MUST NOT include the entity's JID in any
       subsequent broadcasts of available presence initiated by the
       user); however, if the available resource from which the user
       sent the directed presence become unavailable, the user's server
       MUST broadcast that unavailable presence to the entity (if the
       user has not yet sent directed unavailable presence to that
       entity).

   3.  If the user sends directed presence without first sending initial
       presence or after having sent unavailable presence broadcast
       (i.e., the resource is active but not available), the user's
       server MUST treat the entities to which the user sends directed
       presence in the same way that it treats the entities listed in
       case #2 above.


5.1.5 Unavailable Presence

   Before ending its session with a server, a client SHOULD gracefully
   become unavailable by sending a final presence stanza that possesses
   no 'to' attribute and that possesses a 'type' attribute whose value
   is "unavailable" (optionally, the final presence stanza MAY contain
   one or more <status/> elements specifying the reason why the user is
   no longer available).  However, the user's server MUST NOT depend on
   receiving final presence from an available resource, since the
   resource may become unavailable unexpectedly or may be timed out by



Saint-Andre (ed.)      Expires September 19, 2004              [Page 20]

Internet-Draft                  XMPP IM                       March 2004


   the server.  If one of the user's resources becomes unavailable for
   any reason (either gracefully or ungracefully), the user's server
   MUST broadcast unavailable presence to all contacts (1) that are in
   the user's roster with a subscription type of "from" or "both", (2)
   to whom the user has not blocked outbound presence, and (3) from whom
   the server has not received a presence error during the user's
   session; the user's server MUST also send that unavailable presence
   stanza to any of the user's other available resources, as well as to
   any entities to which the user has sent directed presence during the
   user's session for that resource (if the user has not yet sent
   directed unavailable presence to that entity).  Any presence stanza
   with no 'type' attribute and no 'to' attribute that is sent after
   sending directed unavailable presence or broadcasted unavailable
   presence MUST be broadcasted by the server to all subscribers.

5.1.6 Presence Subscriptions

   A 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 contact, the JID supplied in the 'to'
   attribute SHOULD be of the form <[e-mail]> rather than
   <[e-mail]/resource>, since the desired result is normally
   for the user to receive presence from all of the contact's resources,
   not merely the particular resource specified in the 'to' attribute.

   A user's server MUST NOT automatically approve subscription requests
   on the user's behalf.  All subscription requests MUST be directed to
   the user's client, specifically to one or more available resources
   associated with the user.  If there is no available resource
   associated with the user when the subscription request is received by
   the user's server, the user's server MUST keep a record of the
   subscription request and deliver the request when the user next
   creates an available resource, until the user either approves or
   denies the request.  If there is more than one available resource
   associated with the user when the subscription request is received by
   the user's server, the user's server MUST broadcast that subscription
   request to all available resources in accordance with Server Rules
   for Handling XML Stanzas (Section 11).  (Note: If an active resource
   has not provided initial presence, the server MUST NOT consider it to
   be available and therefore MUST NOT send subscription requests to
   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),
   the user's server SHOULD auto-reply on behalf of the user.  In
   addition, the user's server MAY choose to re-send an unapproved
   pending subscription request to the contact based on an
   implementation-specific algorithm (e.g., whenever a new resource



Saint-Andre (ed.)      Expires September 19, 2004              [Page 21]

Internet-Draft                  XMPP IM                       March 2004


   becomes available for the user, or after a certain amount of time has
   elapsed); this helps to recover from transient, silent errors that
   may have occurred in relation to the original subscription request.

5.2 Specifying Availability Status

   A client MAY provide further information about its availability
   status by using the <show/> element (see Show (Section 2.2.2.1)).

   Example: Availability status:

   <presence>
     <show>dnd</show>
   </presence>


5.3 Specifying Detailed Status Information

   In conjunction with the <show/> element, a client MAY provide
   detailed status information by using the <status/> element (see
   Status (Section 2.2.2.2)).

   Example: Detailed status information:

   <presence xml:lang='en'>
     <show>dnd</show>
     <status>Wooing Juliet</status>
     <status xml:lang='cz'>Ja dvo&#x0159;&#x00ED;m Juliet</status>
   </presence>


5.4 Specifying Presence Priority

   A client MAY provide a priority for its resource by using the
   <priority/> element (see Priority (Section 2.2.2.3)).

   Example: Presence priority:

   <presence xml:lang='en'>
     <show>dnd</show>
     <status>Wooing Juliet</status>
     <status xml:lang='cz'>Ja dvo&#x0159;&#x00ED;m Juliet</status>
     <priority>1</priority>
   </presence>







Saint-Andre (ed.)      Expires September 19, 2004              [Page 22]

Internet-Draft                  XMPP IM                       March 2004


5.5 Presence Examples

   The examples in this section illustrate the presence-related
   protocols described above.  The user is [e-mail], he has an
   available resource whose resource identifier is "orchard", and he has
   the following individuals in his roster:

   o  [e-mail] (subscription="both" and she has two available
      resources, one whose resource is "chamber" and another whose
      resource is "balcony")

   o  [e-mail] (subscription="to")

   o  [e-mail] (subscription="from")

   Example 1: User sends initial presence:

   <presence/>

   Example 2: User's server sends presence probes to contacts with
   subscription="to" and subscription="both" on behalf of the user's
   available resource:

   <presence
       type='probe'
       from='[e-mail]/orchard'
       to='[e-mail]'/>

   <presence
       type='probe'
       from='[e-mail]/orchard'
       to='[e-mail]'/>

   Example 3: User's server sends initial presence to contacts with
   subscription="from" and subscription="both" on behalf of the user's
   available resource:

   <presence
       from='[e-mail]/orchard'
       to='[e-mail]'/>

   <presence
       from='[e-mail]/orchard'
       to='[e-mail]'/>

   Example 4: Contacts's servers reply to presence probe on behalf of
   all available resources:




Saint-Andre (ed.)      Expires September 19, 2004              [Page 23]

Internet-Draft                  XMPP IM                       March 2004


   <presence
       from='[e-mail]/balcony'
       to='[e-mail]/orchard'
       xml:lang='en'>
     <show>away</show>
     <status>be right back</status>
     <priority>0</priority>
   </presence>

   <presence
       from='[e-mail]/chamber'
       to='[e-mail]/orchard'>
     <priority>1</priority>
   </presence>

   <presence
       from='[e-mail]/pda'
       to='[e-mail]/orchard'
       xml:lang='en'>
     <show>dnd</show>
     <status>gallivanting</status>
   </presence>

   Example 5: Contacts's servers deliver user's initial presence to all
   available resources or return error to user:

   <presence
       from='[e-mail]/orchard'
       to='[e-mail]/chamber'/>

   <presence
       from='[e-mail]/orchard'
       to='[e-mail]/balcony'/>

   <presence
       type='error'
       from='[e-mail]'
       to='[e-mail]/orchard'>
     <error type='cancel'>
       <gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>
   </presence>

   Example 6: User sends directed presence to another user not in his
   roster:

   <presence
       from='[e-mail]/orchard'



Saint-Andre (ed.)      Expires September 19, 2004              [Page 24]

Internet-Draft                  XMPP IM                       March 2004


       to='[e-mail]'
       xml:lang='en'>
     <show>dnd</show>
     <status>courting Juliet</status>
     <priority>0</priority>
   </presence>

   Example 7: User sends updated available presence information for
   broadcasting:

   <presence xml:lang='en'>
     <show>away</show>
     <status>I shall return!</status>
     <priority>1</priority>
   </presence>

   Example 8: User's server broadcasts updated presence information only