2.2.  Retrieving the Roster on Login

   Upon authenticating with a server and binding a resource (thus
   becoming a connected resource as defined in [XMPP-CORE]), a client
   SHOULD request the roster before sending initial presence (however,
   because receiving the roster is not necessarily desirable for all
   resources, e.g., a connection with limited bandwidth, the client's
   request for the roster is not mandatory).  After a connected resource
   sends initial presence (see Section 4.2), it is referred to as an
   "available resource".  If a connected resource or available resource
   requests the roster, it is referred to as an "interested resource".
   The server MUST send roster pushes to all interested resources.

      Implementation Note: Presence subscription requests are sent to
      available resources, whereas the roster pushes associated with
      subscription state changes are sent to interested resources.
      Therefore, if a resource wishes to receive both subscription
      requests and roster pushes, it MUST both send initial presence and
      request the roster.

   A client requests the roster by sending a roster get over its stream
   with the server.

   C: <iq from='juliet@example.com/balcony'
          id='hu2bac18'
          type='get'>
        <query xmlns='jabber:iq:roster'/>
      </iq>


   S: <iq id='hu2bac18'
          to='juliet@example.com/balcony'
          type='result'>
        <query xmlns='jabber:iq:roster' ver='ver11'>
          <item jid='romeo@example.net'
                name='Romeo'
                subscription='both'>
            <group>Friends</group>
          </item>
          <item jid='mercutio@example.com'
                name='Mercutio'
                subscription='from'/>
          <item jid='benvolio@example.net'
                name='Benvolio'
                subscription='both'/>
        </query>
      </iq>

   If the server cannot process the roster get, it MUST return an
   appropriate stanza error as described in [XMPP-CORE] (such as
   <service-unavailable/> if the roster namespace is not supported or
   <internal-server-error/> if the server experiences trouble processing
   or returning the roster).

2.3.  Adding a Roster Item

2.3.1.  Request

   At any time, a client can add an item to the roster.  This is done by
   sending a roster set containing a new item.

   C: <iq from='juliet@example.com/balcony'
          id='ph1xaz53'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                name='Nurse'>
            <group>Servants</group>
          </item>
        </query>
      </iq>

2.3.2.  Success Case

   If the server can successfully process the roster set for the new
   item (i.e., if no error occurs), it MUST create the item in the
   user's roster and proceed as follows.

   The server MUST return an IQ stanza of type "result" to the connected
   resource that sent the roster set.

   S: <iq id='ph1xaz53'
          to='juliet@example.com/balcony'
          type='result'/>

   The server MUST also send a roster push containing the new roster
   item to all of the user's interested resources, including the
   resource that generated the roster set.

   S: <iq to='juliet@example.com/balcony'
          id='a78b4q6ha463'
          type='set'>
        <query xmlns='jabber:iq:roster' ver='ver13'>
          <item jid='nurse@example.com'
                name='Nurse'
                subscription='none'>
            <group>Servants</group>
          </item>
        </query>
      </iq>

   S: <iq to='juliet@example.com/chamber'
          id='x81g3bdy4n19'
          type='set'>
        <query xmlns='jabber:iq:roster' ver='ver13'>
          <item jid='nurse@example.com'
                name='Nurse'
                subscription='none'>
            <group>Servants</group>
          </item>
        </query>
      </iq>

   As mandated by the semantics of the IQ stanza as defined in
   [XMPP-CORE], each resource that receives a roster push from the
   server is supposed to reply with an IQ stanza of type "result" or
   "error" (however, it is known that many existing clients do not reply
   to roster pushes).

   C: <iq from='juliet@example.com/balcony'
          id='a78b4q6ha463'
          type='result'/>

   C: <iq from='juliet@example.com/chamber'
          id='x81g3bdy4n19'
          type='result'/>

2.3.3.  Error Cases

   If the server cannot successfully process the roster set, it MUST
   return a stanza error.  The following error cases are defined.
   Naturally, other stanza errors can occur, such as <internal-server-
   error/> if the server experiences an internal problem with processing
   the roster get, or even <not-allowed/> if the server only allows
   roster modifications by means of a non-XMPP method such as a web
   interface.

   The server MUST return a <forbidden/> stanza error to the client if
   the sender of the roster set is not authorized to update the roster
   (where typically only an authenticated resource of the account itself
   is authorized).

   The server MUST return a <bad-request/> stanza error to the client if
   the roster set contains any of the following violations:

   1.  The <query/> element contains more than one <item/> child
       element.

   2.  The <item/> element contains more than one <group/> element, but
       there are duplicate groups (one possible comparison method for
       determining duplicates is that described for XMPP resourceparts
       in [XMPP-ADDR]).

   The server MUST return a <not-acceptable/> stanza error to the client
   if the roster set contains any of the following violations:

   1.  The length of the 'name' attribute is greater than a server-
       configured limit.

   2.  The XML character data of the <group/> element is of zero length
       (to remove an item from all groups, the client instead needs to
       exclude any <group/> element from the roster set).

   3.  The XML character data of the <group/> element is larger than a
       server-configured limit.

   Error: Roster set initiated by unauthorized entity

   C: <iq from='juliet@example.com/balcony'
          id='ix7s53v2'
          to='romeo@example.net'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'/>
        </query>
      </iq>

   S: <iq id='ix7s53v2'
          to='juliet@example.com/balcony'
          type='error'>
       <error type='auth'>
         <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       </error>
     </iq>

   Error: Roster set contains more than one item

   C: <iq from='juliet@example.com/balcony'
          id='nw83vcj4'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                name='Nurse'>
            <group>Servants</group>
          </item>
          <item jid='mother@example.com'
                name='Mom'>
            <group>Family</group>
          </item>
        </query>
      </iq>

   S: <iq id='nw83vcj4'
          to='juliet@example.com/balcony'
          type='error'>
       <error type='modify'>
         <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
       </error>
     </iq>

   Error: Roster set contains item with oversized handle

   C: <iq from='juliet@example.com/balcony'
          id='yl491b3d'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                name='[ ... some-very-long-handle ... ]'>
            <group>Servants</group>
          </item>
        </query>
      </iq>

   S: <iq id='yl491b3d'
          to='juliet@example.com/balcony'
          type='error'>
        <error type='modify'>
          <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

   Error: Roster set contains duplicate groups

   C: <iq from='juliet@example.com/balcony'
          id='tk3va749'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                name='Nurse'>
            <group>Servants</group>
            <group>Servants</group>
          </item>
        </query>
      </iq>

   S: <iq id='tk3va749'
          to='juliet@example.com/balcony'
          type='error'>
        <error type='modify'>
          <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

   Error: Roster set contains empty group

   C: <iq from='juliet@example.com/balcony'
          id='fl3b486u'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                name='Nurse'>
            <group></group>
          </item>
        </query>
      </iq>

   S: <iq id='fl3b486u'
          to='juliet@example.com/balcony'
          type='error'>
        <error type='modify'>
          <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

   Error: Roster set contains oversized group name

   C: <iq from='juliet@example.com/balcony'
          id='qh3b4v19'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                name='Nurse'>
            <group>[ ... some-very-long-group-name ... ]</group>
          </item>
        </query>
      </iq>

   S: <iq id='qh3b4v19'
          to='juliet@example.com/balcony'
          type='error'>
        <error type='modify'>
          <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

      Interoperability Note: Some servers return a <not-allowed/> stanza
      error to the client if the value of the <item/> element's 'jid'
      attribute matches the bare JID <localpart@domainpart> of the
      user's account.

2.4.  Updating a Roster Item

2.4.1.  Request

   Updating an existing roster item is done in the same way as adding a
   new roster item, i.e., by sending a roster set to the server.
   Because a roster item is atomic, the item MUST be updated exactly as
   provided in the roster set.

   There are several reasons why a client might update a roster item:

   1.  Adding a group

   2.  Deleting a group

   3.  Changing the handle

   4.  Deleting the handle

   Consider a roster item that is defined as follows:

       <item jid='romeo@example.net'
             name='Romeo'>
         <group>Friends</group>
       </item>

   The user who has this item in her roster might want to add the item
   to another group.

   C: <iq from='juliet@example.com/balcony'
          id='di43b2x9'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='romeo@example.net'
                name='Romeo'>
            <group>Friends</group>
            <group>Lovers</group>
          </item>
        </query>
      </iq>

   Sometime later, the user might want to remove the item from the
   original group.

   C: <iq from='juliet@example.com/balcony'
          id='lf72v157'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='romeo@example.net'
                name='Romeo'>
            <group>Lovers</group>
          </item>
        </query>
      </iq>

   The user might want to remove the item from all groups.

   C: <iq from='juliet@example.com/balcony'
          id='ju4b62a5'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='romeo@example.net'/>
        </query>
      </iq>

   The user might also want to change the handle for the item.

   C: <iq from='juliet@example.com/balcony'
          id='gb3sv487'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='romeo@example.net'
                name='MyRomeo'/>
        </query>
      </iq>

   The user might then want to remove the handle altogether.

   C: <iq from='juliet@example.com/balcony'
          id='o3bx66s5'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='romeo@example.net'
                name=''/>
        </query>
      </iq>

      Implementation Note: Including an empty 'name' attribute is
      equivalent to including no 'name' attribute; both actions set the
      name to the empty string.

2.4.2.  Success Case

   As with adding a roster item, if the roster item can be successfully
   processed then the server MUST update the item in the user's roster,
   send a roster push to all of the user's interested resources, and
   send an IQ result to the initiating resource; details are provided
   under Section 2.3.

2.4.3.  Error Cases

   The error cases described under Section 2.3.3 also apply to updating
   a roster item.

2.5.  Deleting a Roster Item

2.5.1.  Request

   At any time, a client can delete an item from his or her roster by
   sending a roster set and specifying a value of "remove" for the
   'subscription' attribute.

   C: <iq from='juliet@example.com/balcony'
          id='hm4hs97y'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='nurse@example.com'
                subscription='remove'/>
        </query>
      </iq>

2.5.2.  Success Case

   As with adding a roster item, if the server can successfully process
   the roster set then it MUST update the item in the user's roster,
   send a roster push to all of the user's interested resources (with
   the 'subscription' attribute set to a value of "remove"), and send an
   IQ result to the initiating resource; details are provided under
   Section 2.3.

   In addition, the user's server might need to generate one or more
   subscription-related presence stanzas, as follows:

   1.  If the user has a presence subscription to the contact, then the
       user's server MUST send a presence stanza of type "unsubscribe"
       to the contact (in order to unsubscribe from the contact's
       presence).

   2.  If the contact has a presence subscription to the user, then the
       user's server MUST send a presence stanza of type "unsubscribed"
       to the contact (in order to cancel the contact's subscription to
       the user).

   3.  If the presence subscription is mutual, then the user's server
       MUST send both a presence stanza of type "unsubscribe" and a
       presence stanza of type "unsubscribed" to the contact.


   S: <presence from='juliet@example.com'
                id='lm3ba81g'
                to='nurse@example.com'
                type='unsubscribe'/>

   S: <presence from='juliet@example.com'
                id='xb2c1v4k'
                to='nurse@example.com'
                type='unsubscribed'/>

2.5.3.  Error Cases

   If the value of the 'jid' attribute specifies an item that is not in
   the roster, then the server MUST return an <item-not-found/> stanza
   error.

   Error: Roster item not found

   C: <iq from='juliet@example.com/balcony'
          id='uj4b1ca8'
          type='set'>
        <query xmlns='jabber:iq:roster'>
          <item jid='[ ... non-existent-jid ... ]'
                subscription='remove'/>
        </query>
      </iq>

   S: <iq id='uj4b1ca8'
          to='juliet@example.com/balcony'
          type='error'>
        <error type='modify'>
          <item-not-found
              xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
        </error>
      </iq>

2.6.  Roster Versioning

2.6.1.  Stream Feature

   If a server supports roster versioning, then it MUST advertise the
   following stream feature during stream negotiation.

   <ver xmlns='urn:xmpp:features:rosterver'/>

   The roster versioning stream feature is merely informative and
   therefore is never mandatory-to-negotiate.

2.6.2.  Request

   If a client supports roster versioning and the server to which it has
   connected advertises support for roster versioning as described in
   the foregoing section, then the client SHOULD include the 'ver'
   element in its request for the roster.  If the server does not
   advertise support for roster versioning, the client MUST NOT include
   the 'ver' attribute.  If the client includes the 'ver' attribute in
   its roster get, it sets the attribute's value to the version ID
   associated with its last cache of the roster.

   C: <iq from='romeo@example.net/home'
          id='r1h3vzp7'
          to='romeo@example.net'
          type='get'>
        <query xmlns='jabber:iq:roster' ver='ver14'/>
      </iq>

   If the client has not yet cached the roster or the cache is lost or
   corrupted, but the client wishes to bootstrap the use of roster
   versioning, it MUST set the 'ver' attribute to the empty string
   (i.e., ver="").

   Naturally, if the client does not support roster versioning or does
   not wish to bootstrap the use of roster versioning, it will not
   include the 'ver' attribute.

2.6.3.  Success Case

   Whether or not the roster has been modified since the version ID
   enumerated by the client, the server MUST either return the complete
   roster as described under Section 2.1.4 (including a 'ver' attribute
   that signals the latest version) or return an empty IQ-result (thus
   indicating that any roster modifications will be sent via roster
   pushes, as described below).  In general, unless returning the
   complete roster would (1) use less bandwidth than sending individual
   roster pushes to the client (e.g., if the roster contains only a few
   items) or (2) the server cannot associate the version ID with any
   previous version it has on file, the server SHOULD send an empty IQ-
   result and then send the modifications (if any) via roster pushes.

   S: <iq from='romeo@example.net'
          id='r1h3vzp7'
          to='romeo@example.net/home'
          type='result'/>

      Implementation Note: This empty IQ-result is different from an
      empty <query/> element, thus disambiguating this usage from an
      empty roster.

   If roster versioning is enabled and the roster has not been modified
   since the version ID enumerated by the client, the server will simply
   not send any roster pushes to the client (until and unless some
   relevant event triggers a roster push during the lifetime of the
   client's session).

   If the roster has been modified since the version ID enumerated by
   the client, the server MUST then send one roster push to the client
   for each roster item that has been modified since the version ID
   enumerated by the client.  (We call a roster push that is sent for
   purposes of roster version synchronization an "interim roster push".)

      Definition: A "roster modification" is any change to the roster
      data that would result in a roster push to a connected client.
      Therefore, internal states related to roster processing within the
      server that would not result in a roster push to a connected
      client do not necessitate a change to the version.

   S: <iq from='romeo@example.net'
          id='ah382g67'
          to='romeo@example.net/home'
          type='set'>
        <query xmlns='jabber:iq:roster' ver='ver34'>
          <item jid='tybalt@example.org' subscription='remove'/>
        </query>
      </iq>

   S: <iq from='romeo@example.net'
          id='b2gs90j5'
          to='romeo@example.net/home'
          type='set'>
        <query xmlns='jabber:iq:roster' ver='ver42'>
          <item jid='bill@example.org' subscription='both'/>
        </query>
      </iq>

   S: <iq from='romeo@example.net'
          id='c73gs419'
          to='romeo@example.net/home'
          type='set'>
        <query xmlns='jabber:iq:roster' ver='ver72'>
          <item jid='nurse@example.org'
                name='Nurse'
                subscription='to'>
            <group>Servants</group>
          </item>
        </query>
      </iq>

   S: <iq from='romeo@example.net'
          id='dh361f35'
          to='romeo@example.net/home'
          type='set'>
        <query xmlns='jabber:iq:roster' ver='ver96'>
          <item jid='juliet@example.org'
                name='Juliet'
                subscription='both'>
            <group>VIPs</group>
          </item>
        </query>
      </iq>

   These "interim roster pushes" can be understood as follows:

   1.  Imagine that the client had an active presence session for the
       entire time between its cached roster version (say, "ver14") and
       the new roster version (say, "ver96").

   2.  During that time, the client might have received roster pushes
       related to various roster versions (which might have been, say,
       "ver51" and "ver79").  However, some of those roster pushes might
       have contained intermediate updates to the same roster item
       (e.g., modifications to the subscription state for
       bill@example.org from "none" to "to" and from "to" to "both").

   3.  The interim roster pushes would not include all of the
       intermediate steps, only the final result of all modifications
       applied to each item while the client was in fact offline (which
       might have been, say, "ver34", "ver42", "ver72", and "ver96").

   The client MUST handle an "interim roster push" in the same way it
   handles any roster push (indeed, from the client's perspective it
   cannot tell the difference between an "interim" roster push and a
   "live" roster push and therefore it has no way of knowing when it has
   received all of the interim roster pushes).  When requesting the
   roster after reconnection, the client SHOULD request the version
   associated with the last roster push it received during its previous
   session, not the version associated with the roster result it
   received at the start of its previous session.

   When roster versioning is enabled, the server MUST include the
   updated roster version with each roster push.  Roster pushes MUST
   occur in order of modification and the version contained in a roster
   push MUST be unique.  Even if the client has not included the 'ver'
   attribute in its roster gets or sets, the server SHOULD include the
   'ver' attribute on all roster pushes and results that it sends to the
   client.

      Implementation Note: Guidelines and more detailed examples for
      roster versioning are provided in [XEP-0237].

3.  Managing Presence Subscriptions

   In order to protect the privacy of XMPP users, presence information
   is disclosed only to other entities that a user has approved.  When a
   user has agreed that another entity is allowed to view its presence,
   the entity is said to have a "subscription" to the user's presence.
   An entity that has a subscription to a user's presence or to which a
   user has a presence subscription is called a "contact" (in this
   document the term "contact" is also used in a less strict sense to
   refer to a potential contact or any item in a user's roster).

   In XMPP, a subscription lasts across presence sessions; indeed, it
   lasts until the contact unsubscribes or the user cancels the
   previously granted subscription.  (This model is different from that
   used for presence subscriptions in the Session Initiation Protocol
   (SIP), as defined in [SIP-PRES].)

   Subscriptions are managed within XMPP by sending presence stanzas
   containing specially defined attributes ("subscribe", "unsubscribe",
   "subscribed", and "unsubscribed").

      Implementation Note: When a server processes or generates an
      outbound presence stanza of type "subscribe", "subscribed",
      "unsubscribe", or "unsubscribed", the server MUST stamp the
      outgoing presence stanza with the bare JID <localpart@domainpart>
      of the sending entity, not the full JID
      <localpart@domainpart/resourcepart>.  Enforcement of this rule
      simplifies the presence subscription model and helps to prevent
      presence leaks; for information about presence leaks, refer to the
      security considerations of [XMPP-CORE].

   Subscription states are reflected in the rosters of both the user and
   the contact.  This section does not cover every possible case related
   to presence subscriptions, and mainly narrates the protocol flows for
   bootstrapping a mutual subscription between a user and a contact.
   Complete details regarding subscription states can be found under
   Appendix A.

3.1.  Requesting a Subscription

   A "subscription request" is a request from a user for authorization
   to permanently subscribe to a contact's presence information;
   syntactically it is a presence stanza whose 'type' attribute has a
   value of "subscribe".  A subscription request is generated by a

   user's client, processed by the (potential) contact's server, and
   acted on by the contact via the contact's client.  The workflow is
   described in the following sections.

      Implementation Note: Presence subscription requests are sent to
      available resources, whereas the roster pushes associated with
      subscription state changes are sent to interested resources.
      Therefore, if a resource wishes to receive both subscription
      requests and roster pushes, it MUST both send initial presence and
      request the roster.

3.1.1.  Client Generation of Outbound Subscription Request

   A user's client generates a subscription request by sending a
   presence stanza of type "subscribe" and specifying a 'to' address of
   the potential contact's bare JID <contact@domainpart>.

   UC: <presence id='xk3h1v69'
                 to='juliet@example.com'
                 type='subscribe'/>

   When a user sends a presence subscription request to a potential
   instant messaging and presence contact, the value of the 'to'
   attribute MUST be a bare JID <contact@domainpart> rather than a full
   JID <contact@domainpart/resourcepart>, since the desired result is
   for the user to receive presence from all of the contact's resources,
   not merely the particular resource specified in the 'to' attribute.
   Use of bare JIDs also simplifies subscription processing, presence
   probes, and presence notifications by the user's server and the
   contact's server.

   For tracking purposes, a client SHOULD include an 'id' attribute in a
   presence subscription request.

      Implementation Note: Many XMPP clients prompt the user for
      information about the potential contact (e.g., "handle" and
      desired roster group) when generating an outbound presence
      subscription request and therefore send a roster set before
      sending the outbound presence subscription request.  This behavior
      is OPTIONAL, because a client MAY instead wait until receiving the
      initial roster push from the server before uploading user-provided
      information about the contact.  A server MUST process a roster set
      and outbound presence subscription request in either order (i.e.,
      in whatever order generated by the client).

3.1.2.  Server Processing of Outbound Subscription Request

   Upon receiving the outbound presence subscription request, the user's
   server MUST proceed as follows.

   1.  Before processing the request, the user's server MUST check the
       syntax of the JID contained in the 'to' attribute (however, it is
       known that some existing implementations do not perform this
       check).  If the JID is of the form
       <contact@domainpart/resourcepart> instead of
       <contact@domainpart>, the user's server SHOULD treat it as if the
       request had been directed to the contact's bare JID and modify
       the 'to' address accordingly.  The server MAY also verify that
       the JID adheres to the format defined in [XMPP-ADDR] and possibly
       return a <jid-malformed/> stanza error.

   2.  If the potential contact is hosted on the same server as the
       user, then the server MUST adhere to the rules specified under
       Section 3.1.3 when processing the subscription request and
       delivering it to the (local) contact.

   3.  If the potential contact is hosted on a remote server, subject to
       local service policies the user's server MUST then route the
       stanza to that remote domain in accordance with core XMPP stanza
       processing rules.  (This can result in returning an appropriate
       stanza error to the user, such as <remote-server-timeout/>.)

   As mentioned, before locally delivering or remotely routing the
   presence subscription request, the user's server MUST stamp the
   outbound subscription request with the bare JID <user@domainpart> of
   the user.

   US: <presence from='romeo@example.net'
                 id='xk3h1v69'
                 to='juliet@example.com'
                 type='subscribe'/>

   If the presence subscription request cannot be locally delivered or
   remotely routed (e.g., because the request is malformed, the local
   contact does not exist, the remote server does not exist, an attempt
   to contact the remote server times out, or any other error is
   determined or experienced by the user's server), then the user's
   server MUST return an appropriate error stanza to the user.  An
   example follows.

   US: <presence from='juliet@example.com'
                 id='xk3h1v69'
                 to='romeo@example.net'
                 type='error'>
         <error type='modify'>
           <remote-server-not-found
               xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
         </error>
       </presence>

   After locally delivering or remotely routing the presence
   subscription request, the user's server MUST then send a roster push
   to all of the user's interested resources, containing the potential
   contact with a subscription state of "none" and with notation that
   the subscription is pending (via an 'ask' attribute whose value is
   "subscribe").

   US: <iq id='b89c5r7ib574'
           to='romeo@example.net/foo'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item ask='subscribe'
                 jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

   US: <iq id='b89c5r7ib575'
           to='romeo@example.net/bar'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item ask='subscribe'
                 jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

   If a remote contact does not approve or deny the subscription request
   within some configurable amount of time, the user's server SHOULD
   resend the subscription request to the contact based on an
   implementation-specific algorithm (e.g., whenever a new resource
   becomes available for the user, or after a certain amount of time has
   elapsed); this helps to recover from transient, silent errors that
   might have occurred when the original subscription request was routed
   to the remote domain.  When doing so, it is RECOMMENDED for the
   server to include an 'id' attribute so that it can track responses to
   the resent subscription request.

3.1.3.  Server Processing of Inbound Subscription Request

   Before processing the inbound presence subscription request, the
   contact's server SHOULD check the syntax of the JID contained in the
   'to' attribute.  If the JID is of the form
   <contact@domainpart/resourcepart> instead of <contact@domainpart>,
   the contact's server SHOULD treat it as if the request had been
   directed to the contact's bare JID and modify the 'to' address
   accordingly.  The server MAY also verify that the JID adheres to the
   format defined in [XMPP-ADDR] and possibly return a <jid-malformed/>
   stanza error.

   When processing the inbound presence subscription request, the
   contact's server MUST adhere to the following rules:

   1.  Above all, the contact's server MUST NOT automatically approve
       subscription requests on the contact's behalf -- unless the
       contact has (a) pre-approved subscription requests from the user
       as described under Section 3.4, (b) configured its account to
       automatically approve subscription requests, or (c) accepted an
       agreement with its service provider that allows automatic
       approval (for instance, via an employment agreement within an
       enterprise deployment).  Instead, if a subscription request
       requires approval then the contact's server MUST deliver that
       request to the contact's available resource(s) for approval or
       denial by the contact.

   2.  If the contact exists and the user already has a subscription to
       the contact's presence, then the contact's server MUST auto-reply
       on behalf of the contact by sending a presence stanza of type
       "subscribed" from the contact's bare JID to the user's bare JID.
       Likewise, if the contact previously sent a presence stanza of
       type "subscribed" and the contact's server treated that as
       indicating "pre-approval" for the user's presence subscription
       (see Section 3.4), then the contact's server SHOULD also auto-
       reply on behalf of the contact.

   CS: <presence from='juliet@example.com'
                 id='xk3h1v69'
                 to='romeo@example.net'
                 type='subscribed'/>

   3.  Otherwise, if there is at least one available resource associated
       with the contact when the subscription request is received by the
       contact's server, then the contact's server MUST send that
       subscription request to all available resources in accordance
       with Section 8.  As a way of acknowledging receipt of the
       presence subscription request, the contact's server MAY send a

       presence stanza of type "unavailable" from the bare JID of the
       contact to the bare JID of the user (the user's client MUST NOT
       assume that this acknowledgement provides presence information
       about the contact, since it comes from the contact's bare JID and
       is received before the subscription request has been approved).

   4.  Otherwise, if the contact has no available resources when the
       subscription request is received by the contact's server, then
       the contact's server MUST keep a record of the complete presence
       stanza comprising the subscription request, including any
       extended content contained therein (see Section 8.4 of
       [XMPP-CORE]), and then deliver the request when the contact next
       has an available resource.  The contact's server MUST continue to
       deliver the subscription request whenever the contact creates an
       available resource, until the contact either approves or denies
       the request.  (The contact's server MUST NOT deliver more than
       one subscription request from any given user when the contact
       next has an available resource; e.g., if the user sends multiple
       subscription requests to the contact while the contact is
       offline, the contact's server SHOULD store only one of those
       requests, such as the first request or last request, and MUST
       deliver only one of the requests when the contact next has an
       available resource; this helps to prevent "subscription request
       spam".)

      Security Warning: Until and unless the contact approves the
      subscription request as described under Section 3.1.4, the
      contact's server MUST NOT add an item for the user to the
      contact's roster.

      Security Warning: The mandate for the contact's server to store
      the complete stanza of the presence subscription request
      introduces the possibility of an application resource exhaustion
      attack (see Section 2.1.2 of [DOS]), for example, by a rogue
      server or a coordinated group of users (e.g., a botnet) against
      the contact's server or particular contact.  Server implementers
      are advised to consider the possibility of such attacks and
      provide tools for counteracting it, such as enabling service
      administrators to set limits on the number or size of inbound
      presence subscription requests that the server will store in
      aggregate or for any given contact.

3.1.4.  Client Processing of Inbound Subscription Request

   When an interactive client receives a subscription request, it MUST
   present the request to the natural person controlling the client
   (i.e., the "contact") for approval, unless the contact has explicitly
   configured the client to automatically approve or deny some or all

   subscription requests as described above.  An automated client that
   is not controlled by a natural person will have its own application-
   specific rules for approving or denying subscription requests.

   A client approves a subscription request by sending a presence stanza
   of type "subscribed", which is processed as described under
   Section 3.1.5 for the contact's server and Section 3.1.6 for the
   user's server.

   CC: <presence id='h4v1c4kj'
                 to='romeo@example.net'
                 type='subscribed'/>

   A client denies a subscription request by sending a presence stanza
   of type "unsubscribed", which is processed as described under
   Section 3.2 for both the contact's server and the user's server.

   CC: <presence id='tb2m1b59'
                 to='romeo@example.net'
                 type='unsubscribed'/>

   For tracking purposes, a client SHOULD include an 'id' attribute in a
   subscription approval or subscription denial; this 'id' attribute
   MUST NOT mirror the 'id' attribute of the subscription request.

3.1.5.  Server Processing of Outbound Subscription Approval

   When the contact's client sends the subscription approval, the
   contact's server MUST stamp the outbound stanza with the bare JID
   <contact@domainpart> of the contact and locally deliver or remotely
   route the stanza to the user.

   CS: <presence from='juliet@example.com'
                 id='h4v1c4kj'
                 to='romeo@example.net'
                 type='subscribed'/>

   The contact's server then MUST send an updated roster push to all of
   the contact's interested resources, with the 'subscription' attribute
   set to a value of "from".  (Here we assume that the contact does not
   already have a subscription to the user; if that were the case, the
   'subscription' attribute would be set to a value of "both", as
   explained under Appendix A.)

   CS: <iq id='a78b4q6ha463'
           to='juliet@example.com/balcony'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='romeo@example.net'
                 subscription='from'/>
         </query>
       </iq>

   CS: <iq id='x81g3bdy4n19'
           to='juliet@example.com/chamber'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='romeo@example.net'
                 subscription='from'/>
         </query>
       </iq>

   From the perspective of the contact, there now exists a subscription
   from the user, which is why the 'subscription' attribute is set to a
   value of "from".  (Here we assume that the contact does not already
   have a subscription to the user; if that were the case, the
   'subscription' attribute would be set to a value of "both", as
   explained under Appendix A.)

   The contact's server MUST then also send current presence to the user
   from each of the contact's available resources.

   CS: <presence from='juliet@example.com/balcony'
                 id='pw72bc5j'
                 to='romeo@example.net'/>

   CS: <presence from='juliet@example.com/chamber'
                 id='ux31da4q'
                 to='romeo@example.net'/>

   In order to subscribe to the user's presence, the contact would then
   need to send a subscription request to the user.  (XMPP clients will
   often automatically send the subscription request instead of
   requiring the contact to initiate the subscription request, since it
   is assumed that the desired end state is a mutual subscription.)
   Naturally, when the contact sends a subscription request to the user,
   the subscription states will be different from those shown in the
   foregoing examples (see Appendix A) and the roles will be reversed.

3.1.6.  Server Processing of Inbound Subscription Approval

   When the user's server receives a subscription approval, it MUST
   first check if the contact is in the user's roster with
   subscription='none' or subscription='from' and the 'ask' flag set to
   "subscribe" (i.e., a subscription state of "None + Pending Out",
   "None + Pending Out+In", or "From + Pending Out"; see Appendix A).
   If this check is successful, then the user's server MUST:

   1.  Deliver the inbound subscription approval to all of the user's
       interested resources (this helps to give the user's client(s)
       proper context regarding the subscription approval so that they
       can differentiate between a roster push originated by another of
       the user's resources and a subscription approval received from
       the contact).  This MUST occur before sending the roster push
       described in the next step.

   US: <presence from='juliet@example.com'
                 id='h4v1c4kj'
                 to='romeo@example.net'
                 type='subscribed'/>

   2.  Initiate a roster push to all of the user's interested resources,
       containing an updated roster item for the contact with the
       'subscription' attribute set to a value of "to" (if the
       subscription state was "None + Pending Out" or "None + Pending
       Out+In") or "both" (if the subscription state was "From + Pending
       Out").

   US: <iq id='b89c5r7ib576'
           to='romeo@example.net/foo'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 subscription='to'/>
         </query>
       </iq>

   US: <iq id='b89c5r7ib577'
           to='romeo@example.net/bar'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 subscription='to'/>
         </query>
       </iq>

   3.  The user's server MUST also deliver the available presence stanza
       received from each of the contact's available resources to each
       of the user's available resources.

   [ ... to resource1 ... ]

   US: <presence from='juliet@example.com/balcony'
                 id='pw72bc5j'
                 to='romeo@example.net'/>

   [ ... to resource2 ... ]

   US: <presence from='juliet@example.com/balcony'
                 id='pw72bc5j'
                 to='romeo@example.net'/>

   [ ... to resource1 ... ]

   US: <presence from='juliet@example.com/chamber'
                 id='ux31da4q'
                 to='romeo@example.net'/>

   [ ... to resource2 ... ]

   US: <presence from='juliet@example.com/chamber'
                 id='ux31da4q'
                 to='romeo@example.net'/>

      Implementation Note: If the user's account has no available
      resources when the inbound subscription approval notification is
      received, the user's server MAY keep a record of the notification
      (ideally the complete presence stanza) and then deliver the
      notification when the account next has an available resource.
      This behavior provides more complete signaling to the user
      regarding the reasons for the roster change that occurred while
      the user was offline.

   Otherwise -- that is, if the user does not exist, if the contact is
   not in the user's roster, or if the contact is in the user's roster
   with a subscription state other than those described in the foregoing
   check -- then the user's server MUST silently ignore the subscription
   approval notification by not delivering it to the user, not modifying
   the user's roster, and not generating a roster push to the user's
   interested resources.

   From the perspective of the user, there now exists a subscription to
   the contact's presence (which is why the 'subscription' attribute is
   set to a value of "to").

3.2.  Canceling a Subscription

3.2.1.  Client Generation of Subscription Cancellation

   If a contact would like to cancel a subscription that it has
   previously granted to a user, to cancel a subscription pre-approval
   (Section 3.4), or to deny a subscription request, it sends a presence
   stanza of type "unsubscribed".

   CC: <presence id='ij5b1v7g'
                 to='romeo@example.net'
                 type='unsubscribed'/>

3.2.2.  Server Processing of Outbound Subscription Cancellation

   Upon receiving the outbound subscription cancellation, the contact's
   server MUST proceed as follows.

   1.  If the user's bare JID is not yet in the contact's roster or is
       in the contact's roster with a state of "None", "None + Pending
       Out", or "To", the contact's server SHOULD NOT route or deliver
       the presence stanza of type "unsubscribed" to the user and MUST
       NOT send presence notifications of type "unavailable" to the user
       as described below.

   2.  If the user's bare JID is in the contact's roster with a state of
       "None", "None + Pending Out", or "To" and the 'approved' flag is
       set to "true" (thus signaling a subscription pre-approval as
       described under Section 3.4), the contact's server MUST remove
       the pre-approval and MUST NOT route or deliver the presence
       stanza of type "unsubscribed" to the user.

   3.  Otherwise, as shown in the following examples, the contact's
       server MUST route or deliver both presence notifications of type
       "unavailable" and presence stanzas of type "unsubscribed" to the
       user and MUST send a roster push to the contact.

   While the user is still subscribed to the contact's presence (i.e.,
   before the contact's server routes or delivers the presence stanza of
   type "unsubscribed" to the user), the contact's server MUST send a
   presence stanza of type "unavailable" from all of the contact's
   online resources to the user.

   CS: <presence from='juliet@example.com/balcony'
                 id='i8bsg3h3'
                 type='unavailable'/>

   CS: <presence from='juliet@example.com/chamber'
                 id='bvx2c9mk'
                 type='unavailable'/>

   Then the contact's server MUST route or deliver the presence stanza
   of type "unsubscribed" to the user, making sure to stamp the outbound
   subscription cancellation with the bare JID <contact@domainpart> of
   the contact.

   CS: <presence from='juliet@example.com'
                 id='ij5b1v7g'
                 to='romeo@example.net'
                 type='unsubscribed'/>

   The contact's server then MUST send a roster push with the updated
   roster item to all of the contact's interested resources, where the
   subscription state is now either "none" or "to" (see Appendix A).

   CS: <iq id='pw3f2v175b34'
           to='juliet@example.com/balcony'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='romeo@example.net'
                 subscription='none'/>
         </query>
       </iq>

   CS: <iq id='zu2y3f571v35'
           to='juliet@example.com/chamber'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='romeo@example.net'
                 subscription='none'/>
         </query>
       </iq>

3.2.3.  Server Processing of Inbound Subscription Cancellation

   When the user's server receives the inbound subscription
   cancellation, it MUST first check if the contact is in the user's
   roster with subscription='to' or subscription='both' (see
   Appendix A).  If this check is successful, then the user's server
   MUST:

   1.  Deliver the inbound subscription cancellation to all of the
       user's interested resources (this helps to give the user's
       client(s) proper context regarding the subscription cancellation
       so that they can differentiate between a roster push originated
       by another of the user's resources and a subscription
       cancellation received from the contact).  This MUST occur before
       sending the roster push described in the next step.

   US: <presence from='juliet@example.com'
                 id='ij5b1v7g'
                 to='romeo@example.net'
                 type='unsubscribed'/>

   2.  Initiate a roster push to all of the user's interested resources,
       containing an updated roster item for the contact with the
       'subscription' attribute set to a value of "none" (if the
       subscription state was "To" or "To + Pending In") or "from" (if
       the subscription state was "Both").

   US: <iq id='h37h3u1bv400'
           to='romeo@example.net/foo'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

   US: <iq id='h37h3u1bv401'
           to='romeo@example.net/bar'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

   The user's server MUST also deliver the inbound presence stanzas of
   type "unavailable".

      Implementation Note: If the user's account has no available
      resources when the inbound unsubscribed notification is received,
      the user's server MAY keep a record of the notification (ideally
      the complete presence stanza) and then deliver the notification
      when the account next has an available resource.  This behavior
      provides more complete signaling to the user regarding the reasons
      for the roster change that occurred while the user was offline.

   Otherwise -- that is, if the user does not exist, if the contact is
   not in the user's roster, or if the contact is in the user's roster
   with a subscription state other than those described in the foregoing
   check -- then the user's server MUST silently ignore the unsubscribed
   notification by not delivering it to the user, not modifying the
   user's roster, and not generating a roster push to the user's
   interested resources.

3.3.  Unsubscribing

3.3.1.  Client Generation of Unsubscribe

   If a user would like to unsubscribe from a contact's presence, it
   sends a presence stanza of type "unsubscribe".

   UC: <presence id='ul4bs71n'
                 to='juliet@example.com'
                 type='unsubscribe'/>

3.3.2.  Server Processing of Outbound Unsubscribe

   Upon receiving the outbound unsubscribe, the user's server MUST
   proceed as follows.

   1.  If the contact is hosted on the same server as the user, then the
       server MUST adhere to the rules specified under Section 3.3.3
       when processing the subscription request.

   2.  If the contact is hosted on a remote server, subject to local
       service policies the user's server MUST then route the stanza to
       that remote domain in accordance with core XMPP stanza processing
       rules.  (This can result in returning an appropriate stanza error
       to the user, such as <remote-server-timeout/>.)

   As mentioned, before locally delivering or remotely routing the
   unsubscribe, the user's server MUST stamp the stanza with the bare
   JID <user@domainpart> of the user.

   US: <presence from='romeo@example.net'
                 id='ul4bs71n'
                 to='juliet@example.com'
                 type='unsubscribe'/>

   The user's server then MUST send a roster push with the updated
   roster item to all of the user's interested resources, where the
   subscription state is now either "none" or "from" (see Appendix A).

   US: <iq id='h37h3u1bv402'
           to='romeo@example.net/foo'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

   US: <iq to='romeo@example.net/bar'
           type='set'
           id='h37h3u1bv403'>
         <query xmlns='jabber:iq:roster'>
           <item jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

3.3.3.  Server Processing of Inbound Unsubscribe

   When the contact's server receives the unsubscribe notification, it
   MUST first check if the user's bare JID is in the contact's roster
   with subscription='from' or subscription='both' (i.e., a subscription
   state of "From", "From + Pending Out", or "Both"; see Appendix A).
   If this check is successful, then the contact's server MUST:

   1.  Deliver the inbound unsubscribe to all of the contact's
       interested resources (this helps to give the contact's client(s)
       proper context regarding the unsubscribe so that they can
       differentiate between a roster push originated by another of the
       contact's resources and an unsubscribe received from the user).
       This MUST occur before sending the roster push described in the
       next step.

   CS: <presence from='romeo@example.net'
                 id='ul4bs71n'
                 to='juliet@example.com'
                 type='unsubscribe'/>

   2.  Initiate a roster push to all of the contact's interested
       resources, containing an updated roster item for the user with
       the 'subscription' attribute set to a value of "none" (if the
       subscription state was "From" or "From + Pending Out") or "to"
       (if the subscription state was "Both").

   CS: <iq id='tn2b5893g1s4'
           to='juliet@example.com/balcony'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='romeo@example.net'
                 subscription='none'/>
         </query>
       </iq>

   CS: <iq id='sp3b56n27hrp'
           to='juliet@example.com/chamber'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item jid='romeo@example.net'
                 subscription='none'/>
         </query>
       </iq>

   3.  Generate an outbound presence stanza of type "unavailable" from
       each of the contact's available resources to the user.

   CS: <presence from='juliet@example.com/balcony'
                 id='o5v91w49'
                 to='romeo@example.net'
                 type='unavailable'/>

   CS: <presence from='juliet@example.com/chamber'
                 id='n6b1c37k'
                 to='romeo@example.net'
                 type='unavailable'/>

      Implementation Note: If the contact's account has no available
      resources when the inbound unsubscribe notification is received,
      the contact's server MAY keep a record of the notification
      (ideally the complete presence stanza) and then deliver the
      notification when the account next has an available resource.
      This behavior provides more complete signaling to the user
      regarding the reasons for the roster change that occurred while
      the user was offline.

   Otherwise -- that is, if the contact does not exist, if the user is
   not in the contact's roster, or if the user's bare JID is in the
   contact's roster with a subscription state other than those described
   in the foregoing check -- then the contact's server MUST silently
   ignore the unsubscribe stanza by not delivering it to the contact,
   not modifying the contact's roster, and not generating a roster push
   to the contact's interested resources.  However, if the contact's
   server is keeping track of an inbound presence subscription request

   from the user to the contact but the user is not yet in the contact's
   roster (functionally equivalent to a subscription state of "None +
   Pending In" where the contact never added the user to the contact's
   roster), then the contact's server MUST simply remove any record of
   the inbound presence subscription request (it cannot remove the user
   from the contact's roster because the user was never added to the
   contact's roster).

      Implementation Note: The user's client MUST NOT depend on
      receiving the unavailable presence notification from the contact,
      since it MUST consider its presence subscription to the contact,
      and its presence information about the contact, to be null and
      void when it sends the presence stanza of type "unsubscribe" or
      when it receives the roster push triggered by the unsubscribe
      request.

3.4.  Pre-Approving a Subscription Request

   If a user has not received a subscription request from a contact, the
   user can "pre-approve" such a request so that it will be
   automatically approved by the user's server.

   Support for subscription pre-approvals is OPTIONAL on the part of
   clients and servers.  If a server supports subscription pre-
   approvals, then it MUST advertise the following stream feature during
   stream negotiation.

   <sub xmlns='urn:xmpp:features:pre-approval'/>

   The subscription pre-approval stream feature is merely informative
   and therefore is never mandatory-to-negotiate.

3.4.1.  Client Generation of Subscription Pre-Approval

   If the server to which a client connects has advertised support for
   subscription pre-approvals, the client MAY generate a subscription
   pre-approval by sending a presence stanza of type "subscribed" to the
   contact.

   UC: <presence id='pg81vx64'
                 to='juliet@example.com'
                 type='subscribed'/>

   If the server does not advertise support for subscription pre-
   approvals, the client MUST NOT attempt to pre-approve subscription
   requests from potential or actual contacts.

3.4.2.  Server Processing of Subscription Pre-Approval

   Upon receiving the presence stanza of type "subscribed", the user's
   server MUST proceed as follows if it supports subscription pre-
   approvals.

   1.  If the contact is in the user's roster with a state of "Both",
       "From", or "From + Pending Out", the user's server MUST silently
       ignore the stanza.

   2.  If the contact is in the user's roster with a state of "To +
       Pending In", "None + Pending In", or "None + Pending Out+In", the
       user's server MUST handle the stanza as a normal subscription
       approval (see under Section 3.1.5) by updating the existing
       roster item to a state of "Both", "From", or "From + Pending Out"
       (respectively), pushing the modified roster item to all of the
       user's interested resources, and routing the presence stanza of
       type "subscribed" to the contact.

   3.  If the contact is in the user's roster with a state of "To",
       "None", or "None + Pending Out", the user's server MUST note the
       subscription pre-approval by setting the 'approved' flag to a
       value of "true", then push the modified roster item to all of the
       user's interested resources.  However, the user's server MUST NOT
       route the presence stanza of type "subscribed" to the contact.

   4.  If the contact is not yet in the user's roster, the user's server
       MUST create a roster item for the contact with a state of "None"
       and set the 'approved' flag to a value of "true", then push the
       roster item to all of the user's interested resources.  However,
       the user's server MUST NOT route the presence stanza of type
       "subscribed" to the contact.

   An example of the roster push follows.

   US: <iq id='h3bs81vs763f'
           to='romeo@example.net/bar'
           type='set'>
         <query xmlns='jabber:iq:roster'>
           <item approved='true'
                 jid='juliet@example.com'
                 subscription='none'/>
         </query>
       </iq>

   When the 'approved' flag is set to "true", the user's server MUST NOT
   deliver a presence stanza of type "subscribe" from the contact to the
   user, but instead MUST automatically respond to such a stanza on

   behalf of the user by returning a presence stanza of type
   "subscribed" from the bare JID of the user to the bare JID of the
   contact.

      Implementation Note: It is a matter of implementation or local
      service policy whether the server maintains a record of the
      subscription approval after it has received a presence
      subscription request from the contact.  If the server does not
      maintain such a record, upon receiving the subscription request it
      will not include the 'approved' attribute in the roster item for
      the contact (i.e., in subsequent roster pushes and roster
      results).  If the server maintains such a record, it will always
      include the 'approved' attribute (set to "true") in the roster
      item for the contact, until and unless the user sends a presence
      stanza of type "unsubscribed" to the contact (or removes the
      contact from the roster entirely).

      Implementation Note: A client can cancel a pre-approval by sending
      a presence stanza of type "unsubscribed", as described more fully
      under Section 3.2.  In this case, the user's server would send a
      roster push to all of the user's interested resources with the
      'approved' attribute removed.  (Alternatively, the client can
      simply remove the roster item entirely.)