Network Working Group                                     P. Saint-Andre
Internet-Draft                                                 J. Miller
Expires: August 24, 2003                      Jabber Software Foundation
                                                       February 23, 2003


                         XMPP Instant Messaging
                         draft-ietf-xmpp-im-03

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 24, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This document describes the specific extensions to and applications
   of the Extensible Messaging and Presence Protocol (XMPP) that are
   necessary to create a basic instant messaging and presence
   application.











Saint-Andre & Miller    Expires August 24, 2003                 [Page 1]


Internet-Draft           XMPP Instant Messaging            February 2003


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.2   Requirements . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.3   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.4   Discussion Venue . . . . . . . . . . . . . . . . . . . . . .  5
   1.5   Intellectual Property Notice . . . . . . . . . . . . . . . .  5
   2.    Authentication and Authorization . . . . . . . . . . . . . .  6
   3.    Exchanging Messages  . . . . . . . . . . . . . . . . . . . .  7
   3.1   Specifying an Intended Recipient . . . . . . . . . . . . . .  7
   3.2   Specifying a Message Type  . . . . . . . . . . . . . . . . .  7
   3.3   Specifying a Message Subject . . . . . . . . . . . . . . . .  8
   3.4   Specifying a Conversation Thread . . . . . . . . . . . . . .  8
   3.5   Specifying a Message Body  . . . . . . . . . . . . . . . . .  9
   3.6   Specifying Additional Information  . . . . . . . . . . . . .  9
   3.7   Message-Related Errors . . . . . . . . . . . . . . . . . . . 10
   4.    Exchanging Presence Information  . . . . . . . . . . . . . . 11
   4.1   Client and Server Responsibilities . . . . . . . . . . . . . 11
   4.2   Sending Initial Presence . . . . . . . . . . . . . . . . . . 11
   4.3   Specifying Availability Status . . . . . . . . . . . . . . . 12
   4.4   Specifying Detailed Status Information . . . . . . . . . . . 12
   4.5   Probing for Presence . . . . . . . . . . . . . . . . . . . . 12
   4.6   Sending Final Presence . . . . . . . . . . . . . . . . . . . 12
   4.7   Determining When a Contact Went Offline  . . . . . . . . . . 13
   5.    Managing Subscriptions . . . . . . . . . . . . . . . . . . . 14
   5.1   Requesting a Subscription  . . . . . . . . . . . . . . . . . 14
   5.2   Handling a Subscription Request  . . . . . . . . . . . . . . 14
   5.3   Cancelling a Subscription from Another Entity  . . . . . . . 14
   5.4   Unsubscribing from Another Entity's Presence . . . . . . . . 15
   6.    Managing One's Roster  . . . . . . . . . . . . . . . . . . . 16
   6.1   Retrieving One's Roster on Login . . . . . . . . . . . . . . 16
   6.2   Adding a Roster Item . . . . . . . . . . . . . . . . . . . . 17
   6.3   Deleting a Roster Item . . . . . . . . . . . . . . . . . . . 18
   7.    Integration of Roster Items and Presence Subscriptions . . . 20
   7.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 20
   7.2   User Subscribes to Contact . . . . . . . . . . . . . . . . . 20
   7.3   Creating a Mutual Subscription . . . . . . . . . . . . . . . 24
   7.4   Unsubscribing  . . . . . . . . . . . . . . . . . . . . . . . 26
   7.4.1 Case #1: Subscription Type 'to'  . . . . . . . . . . . . . . 26
   7.4.2 Case #2: Subscription Type 'both'  . . . . . . . . . . . . . 28
   7.5   Cancelling a Subscription  . . . . . . . . . . . . . . . . . 29
   7.5.1 Case #1: Subscription Type 'from'  . . . . . . . . . . . . . 29
   7.5.2 Case #2: Subscription Type 'both'  . . . . . . . . . . . . . 30
   7.6   Removing a Roster Item and Cancelling All Subscriptions  . . 31
   8.    Blocking Communication . . . . . . . . . . . . . . . . . . . 33
   8.1   Retrieving One's Privacy Lists . . . . . . . . . . . . . . . 33
   8.2   Managing Active Lists  . . . . . . . . . . . . . . . . . . . 35



Saint-Andre & Miller    Expires August 24, 2003                 [Page 2]


Internet-Draft           XMPP Instant Messaging            February 2003


   8.3   Managing the Default List  . . . . . . . . . . . . . . . . . 35
   8.4   Editing a Privacy List . . . . . . . . . . . . . . . . . . . 36
   8.5   Removing a Privacy List  . . . . . . . . . . . . . . . . . . 37
   8.6   Blocking Messages  . . . . . . . . . . . . . . . . . . . . . 37
   8.7   Blocking Inbound Presence  . . . . . . . . . . . . . . . . . 39
   8.8   Blocking Outbound Presence . . . . . . . . . . . . . . . . . 40
   8.9   Blocking IQs . . . . . . . . . . . . . . . . . . . . . . . . 42
   8.10  Blocking All Communication . . . . . . . . . . . . . . . . . 43
   8.11  Blocked Entity Attempts to Send Message to User  . . . . . . 45
   8.12  Higher-Level Heuristics  . . . . . . . . . . . . . . . . . . 45
   8.13  Processing Order . . . . . . . . . . . . . . . . . . . . . . 46
   9.    Security Considerations  . . . . . . . . . . . . . . . . . . 48
         References . . . . . . . . . . . . . . . . . . . . . . . . . 49
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 49
   A.    vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
   A.1   Retrieving One's vCard . . . . . . . . . . . . . . . . . . . 50
   A.2   Updating One's vCard . . . . . . . . . . . . . . . . . . . . 51
   A.3   Viewing Another User's vCard . . . . . . . . . . . . . . . . 52
   B.    Formal Definitions . . . . . . . . . . . . . . . . . . . . . 53
   B.1   Schema for jabber:iq:last  . . . . . . . . . . . . . . . . . 53
   B.2   Schema for jabber:iq:privacy . . . . . . . . . . . . . . . . 53
   B.3   Schema for jabber:iq:roster  . . . . . . . . . . . . . . . . 54
   B.4   DTD for vcard-temp . . . . . . . . . . . . . . . . . . . . . 55
   C.    Revision History . . . . . . . . . . . . . . . . . . . . . . 63
   C.1   Changes from draft-ietf-xmpp-im-02 . . . . . . . . . . . . . 63
   C.2   Changes from draft-ietf-xmpp-im-01 . . . . . . . . . . . . . 63
   C.3   Changes from draft-ietf-xmpp-im-00 . . . . . . . . . . . . . 63
   C.4   Changes from draft-miller-xmpp-im-02 . . . . . . . . . . . . 63
         Intellectual Property and Copyright Statements . . . . . . . 65






















Saint-Andre & Miller    Expires August 24, 2003                 [Page 3]


Internet-Draft           XMPP Instant Messaging            February 2003


1. Introduction

1.1 Overview

   The core features of the Extensible Messaging and Presence Protocol
   are defined in XMPP Core [1]. These features -- specifically XML
   streams, stream authentication and encryption, and the <message/>,
   <presence/>, and <iq/> children of the stream root -- provide the
   building blocks for many types of near-real-time applications, which
   may be layered on top of the core by sending application-specific
   data scoped by particular XML namespaces. This document describes the
   extensions to and applications of XMPP Core that are used to create
   the basic functionality expected of an instant messaging and presence
   application as defined in RFC 2779 [2]. Extended namespaces for many
   other functionality areas have been defined and continue to be
   defined by the Jabber Software Foundation [3], including service
   discovery, multi-user chat, data gathering and forms submission,
   feature negotiation, message composing events, message expiration,
   delayed delivery, file transfer, publish-subscribe, and transports
   for XML-RPC and SOAP; however, such functionality is not described
   herein because it is not required by RFC 2779 [2].

1.2 Requirements

   For the purposes of this document, we stipulate that a basic instant
   messaging and presence application needs to enable a user to perform
   the following high-level functionality by using a compliant client:

   o  Authenticate with a server

   o  Exchange messages with other users

   o  Exchange presence information with other users

   o  Manage subscriptions to and from other users

   o  Manage the items in the user's contact list (in XMPP this is
      called a "roster")

   o  Block communications to or from specific other users

   Detailed definitions of these functionality areas are contained in
   RFC 2779 [2]; although XMPP IM meets those requirements, it was not
   designed explicitly with RFC 2779 in mind, since the base protocol
   evolved through an open development process within the Jabber
   open-source community in 1999.





Saint-Andre & Miller    Expires August 24, 2003                 [Page 4]


Internet-Draft           XMPP Instant Messaging            February 2003


1.3 Terminology

   This document inherits the terminology defined in XMPP Core [1].

   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [4].

1.4 Discussion Venue

   The authors welcome discussion and comments related to the topics
   presented in this document. The preferred forum is the
   <xmppwg@jabber.org> mailing list, for which archives and subscription
   information are available at <http://www.jabber.org/cgi-bin/mailman/
   listinfo/xmppwg/>.

1.5 Intellectual Property Notice

   This document is in full compliance with all provisions of Section 10
   of RFC 2026. Parts of this specification use the term "jabber" for
   identifying namespaces and other protocol syntax. Jabber[tm] is a
   registered trademark of Jabber, Inc.  Jabber, Inc. grants permission
   to the IETF for use of the Jabber trademark in association with this
   specification and its successors, if any.


























Saint-Andre & Miller    Expires August 24, 2003                 [Page 5]


Internet-Draft           XMPP Instant Messaging            February 2003


2. Authentication and Authorization

   In order to gain access to the network of XMPP-compliant applications
   and thus engage in standard IM functionality such as exchanging
   messages and presence, a user must first acquire an account on a
   server. Although account provisioning is outside the scope of XMPP,
   methods for doing so include account creation by a server
   administrator as well as in-band account registration using the
   'jabber:iq:register' namespace; the latter method is defined by the
   Jabber Software Foundation [3] and appropriate documentation is
   available at the JSF's website.

   In order to gain access to the network, a user MUST authenticate with
   the server hosting his or her account. If a user's client is capable
   of authenticating by means of SASL, it MUST include a 'version'
   attribute (set to a value of "1.0") within the opening <stream/>
   element with which it initiated communications with the server. The
   protocol describing how a client authenticates with a server using
   SASL is defined in XMPP Core [1].

   After authenticating, a user MUST also provide a resource name for
   the current session, for the purpose of addressing; the protocol for
   providing a resource is also defined in XMPP Core [1].

   NOTE: Earlier iterations of the Jabber protocol contained a
   client-server authentication protocol that was enforced after the
   stream was negotiated; this protocol is not suppoted in XMPP but is
   documented by the Jabber Software Foundation [3] for historical
   purposes.






















Saint-Andre & Miller    Expires August 24, 2003                 [Page 6]


Internet-Draft           XMPP Instant Messaging            February 2003


3. Exchanging Messages

   Exchanging messages is a basic use of XMPP and is effected when a
   user sends a message stanza to another user (or, more generally,
   another entity). As defined in the "Routing and Delivery Rules"
   section of XMPP Core [1], the sender's server is responsible for
   delivering the message to the intended recipient (if the recipient is
   on the same server) or for routing the message to the recipient's
   server (if the recipient is on a different server).

3.1 Specifying an Intended Recipient

   A client SHOULD specify an intended recipient for the message by
   providing an appropriate JID in the 'to' attribute of the <message/>
   element. Normally, the value of the 'to' attribute specifies an
   entity other than the sending user. The intended recipient MAY be any
   valid JID (e.g., a user on the same server, a user on a different
   server, the server itself, another server, or a service). If the JID
   is invalid or cannot be contacted, the entity discovering that fact
   (usually the sender's or recipient's server) SHOULD return an error
   to the sender.

3.2 Specifying a Message Type

   As mentioned in XMPP Core [1], there are several defined types of
   messages (specified by means of a 'type' attribute within the
   <message/> element). In the context of an instant messaging
   application, a client MAY include a message type in order to capture
   the conversational context of the message, thus providing a hint
   regarding presentation (e.g., in a GUI). If included, the 'type'
   attribute SHOULD have one of the following values (any other value
   MAY be ignored):

   o  chat -- The message is sent in the context of a one-to-one chat
      conversation.

   o  groupchat -- The message is sent in the context of a multi-user
      chat environment.

   o  headline -- The message is generated by an automated service that
      delivers content (news, sports, market information, etc.).

   o  error - A message returned to a sender specifying an error
      associated with a previous message sent by the sender (for a full
      list of error messages, see XMPP Core [1])

   Although the 'type' attribute is OPTIONAL, it is considered polite to
   mirror the type in any replies to a message; furthermore, some



Saint-Andre & Miller    Expires August 24, 2003                 [Page 7]


Internet-Draft           XMPP Instant Messaging            February 2003


   specialized applications (e.g., a multi-user chat service) MAY at
   their discretion enforce the use of a particular message type (e.g.,
   type='groupchat').

3.3 Specifying a Message Subject

   A message stanza MAY contain a child <subject/> element specifying
   the subject of the message. The subject MUST NOT contain mixed
   content.

   A message with a subject:

   <message to="romeo@montague.net" from="juliet@capulet.com/balcony">
     <subject>Imploring</subject>
     <body>Wherefore art thou, Romeo?</body>
   </message>

   Multiple <subject/> elements MAY be included, as long as each
   contains an 'xml:lang' attribute with a distinct value.

3.4 Specifying a Conversation Thread

   A message stanza MAY contain a child <thread/> element specifying the
   conversation thread in which the message is situated, for the purpose
   of tracking the conversation thread. The content of the <thread/>
   element is a random string that is generated by the sender in
   accordance with the algorithm specified in XMPP Core [1]; this string
   MAY be copied back to the sender in subsequent replies. If included,
   the <thread/> element MUST have no attributes and MUST NOT contain
   mixed content.





















Saint-Andre & Miller    Expires August 24, 2003                 [Page 8]


Internet-Draft           XMPP Instant Messaging            February 2003


   A threaded conversation:

   <message
       to="romeo@montague.net/orchard"
       from="juliet@capulet.com/balcony"
       type="chat">
     <body>Art thou not Romeo, and a Montague?</body>
     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
   </message>

   <message
       to="juliet@capulet.com/balcony"
       from="romeo@montague.net/orchard"
       type="chat">
     <body>Neither, fair saint, if either thee dislike.</body>
     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
   </message>

   <message
       to="romeo@montague.net/orchard"
       from="juliet@capulet.com/balcony"
       type="chat">
     <body>How cam'st thou hither, tell me, and wherefore?</body>
     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
   </message>


3.5 Specifying a Message Body

   A message stanza MAY (and often will) contain a child <body/> element
   specifying the main content of the message as CDATA. The body MUST
   NOT contain mixed content. If it is necessary to provide the main
   message content in an alternate form (e.g., encrypted using the
   public key infrastructure or formatted using XHTML), the alternate
   form MUST be contained in an appropriately-namespaced child of the
   message stanza, as defined for any such extended namespace.

   Multiple <body/> elements MAY be included, as long as each contains
   an 'xml:lang' attribute with a distinct value.

3.6 Specifying Additional Information

   A message stanza MAY house an element containing content that extends
   the meaning of the message (e.g., an encrypted form of the message
   body). In common usage this child element is often the <x/> element
   but MAY be any element, as long as the 'xmlns' namespace declaration
   is something other than the streams namespace or the default
   namespace; this extended namespace defines all elements contained



Saint-Andre & Miller    Expires August 24, 2003                 [Page 9]


Internet-Draft           XMPP Instant Messaging            February 2003


   within the child element.

3.7 Message-Related Errors

   If a message sent by a sender cannot be delivered, the entity
   discovering that fact (usually either the sender's or recipient's
   server) SHOULD return that message to the sender in a message stanza
   of type "error" along with an appropriate error message (for a list
   of error messages, see XMPP Core [1]).

   A message-related error:

   <message
       to="juliet@capulet.com"
       from="romeo@montague.net">
     <body>Sleep dwell upon thine eyes.</body>
   </message>

   <message
       to="romeo@montague.net"
       from="juliet@capulet.com"
       type="error">
     <body>Sleep dwell upon thine eyes.</body>
     <error code="404">We're sorry, Juliet just died</error>
   </message>

   An entity that receives a message stanza of type 'error' MUST NOT
   respond to the stanza by sending a further message stanza of type
   'error'; this helps to prevent looping.






















Saint-Andre & Miller    Expires August 24, 2003                [Page 10]


Internet-Draft           XMPP Instant Messaging            February 2003


4. Exchanging Presence Information

   Exchanging presence information is made relatively straightforward
   within XMPP by using presence stanzas. However, we see here a
   contrast to the handling of messages: although a client MAY send
   directed presence information to another entity, in general presence
   information is sent from a client to a server (with no 'to' address)
   and then broadcasted by the server to any entities that are
   subscribed to the presence of the sending entity. (Note: in the
   terminology of RFC 2778 [5], the only watchers in XMPP are
   subscribers.)

4.1 Client and Server Responsibilities

   When a client connects to a server, it SHOULD send an initial
   presence stanza to the server to express default availability. This
   presence stanza MUST possess no 'to' address (signalling that it is
   meant to be handled by the server on behalf of the user) and SHOULD
   have no type.

   Upon receiving initial presence from a client, the server sends
   presence probes from the full JID (user@domain/resource) of the user
   to any remote entities that are subscribed to the user's presence (as
   represented in the user's roster) in order to determine if they are
   available. (The remote server is responsible for responding to the
   presence probe only when (1) the probing entity has been allowed to
   access the probed entity's presence, e.g., by server rules or user
   subscriptions, and (2) the probed entity is available; the probing
   entity's server then informs the probing entity of the probed
   entity's last known available presence, for all of the probed
   entity's resources if applicable.)

   Throughout the active session of a connected resource, the server is
   responsible for broadcasting any changes in the availability status
   of the connected resource to the subscribed entities that are
   available, so that such entities are kept apprised of availability
   changes.

   Finally, the server MUST notify all of the subscribed and available
   entities when a connected resource becomes unavailable.

4.2 Sending Initial Presence

   Upon authenticating, a client SHOULD send initial presence to its
   server indicating that the connected resource is available for
   communications. This presence stanza MUST have no 'to' address and
   SHOULD have no type.




Saint-Andre & Miller    Expires August 24, 2003                [Page 11]


Internet-Draft           XMPP Instant Messaging            February 2003


   Initial presence sent from client to server:

   <presence/>


4.3 Specifying Availability Status

   A client MAY provide further information about its availability
   status by using the <show/> element. As defined in XMPP Core [1], the
   recognized values for the show element are "away", "chat", "xa", and
   "dnd".

   Availability status:

   <presence>
     <show>away</show>
   </presence>


4.4 Specifying Detailed Status Information

   In conjunction with the  <show/> element, a client MAY provide
   detailed status information by using the <status/> element. The
   content of this element is a natural-language description of the
   client's current availability status.

   Detailed status information:

   <presence>
     <show>dnd</show>
     <status>Busy fighting the Romans</status>
   </presence>


4.5 Probing for Presence

   A server MAY probe for the current presence of another entity. A user
   or client SHOULD NOT send presence stanzas of type 'probe'.

4.6 Sending Final Presence

   Upon ending its session with a server, a client SHOULD gracefully
   become unavailable by sending a final presence stanza that is
   explicitly of type unavailable.

   Sending final presence to express unavailable state:

   <presence type="unavailable"/>



Saint-Andre & Miller    Expires August 24, 2003                [Page 12]


Internet-Draft           XMPP Instant Messaging            February 2003


   Optionally, final presence MAY contain one or more <status/> elements
   specifying the reason why the user is no longer available.

   The server MUST NOT depend on receiving final presence from a
   connected resource, since the resource may become unavailable
   unexpectedly. If a server detects that a resource has become
   unavailable for any reason (either gracefully or ungracefully), it
   MUST send <presence type="unavailable"/> to all online entities that
   are subscribed to the associated user's presence.

4.7 Determining When a Contact Went Offline

   The server MUST maintain a record of the time at which a user became
   unavailable (whether gracefully or ungracefully). An authorized
   subscriber to that user's presence MAY determine the time of last
   activity by sending an IQ stanza to the user's bare JID (user@domain)
   containing an empty <query/> element scoped by the 'jabber:iq:last'
   namespace:

   Requesting the last active time of a user:

   <iq type='get' to='user@domain'>
     <query xmlns='jabber:iq:last'/>
   </iq>

   If the entity requesting the time of last activity is an authorized
   subscriber to the user's presence, the server MUST return an IQ
   stanza of type 'result' with the number of seconds since the user was
   last active:

   Returning the last active time of a user:

   <iq from='user@domain' type='result' to='subscriber@domain/resource'>
     <query seconds='76490' xmlns='jabber:iq:last'/>
   </iq>

   If the entity requesting the time of last activity is not an
   authorized subscriber to the user's presence, the server MUST return
   an IQ stanza of type 'error' with an error code of 403 (Forbidden):

   Requester is forbidden to view the last active time of a user:

   <iq from='user@domain' type='result' to='subscriber@domain/resource'>
     <query xmlns='jabber:iq:last'/>
     <error code='403'>Forbidden</error>
   </iq>





Saint-Andre & Miller    Expires August 24, 2003                [Page 13]


Internet-Draft           XMPP Instant Messaging            February 2003


5. Managing Subscriptions

   In order to protect the privacy of instant messaging users and any
   other entities, presence and availability information is made
   available only to other entities that the user has approved. When a
   user has agreed that another entity may view its presence, the entity
   is said to have a subscription to the user's presence information.
   Note well that a subscription lasts across sessions; indeed, it lasts
   until the subscriber unsubscribes or the subscribee cancels the
   previously-granted subscription. Subscriptions are completed within
   XMPP by sending presence stanzas containing specially-defined
   attributes.

5.1 Requesting a Subscription

   A request to subscribe to another entity's presence is made by
   sending a presence stanza of type "subscribe".

   Sending a subscription request:

   <presence to="juliet@capulet.com" type="subscribe"/>


5.2 Handling a Subscription Request

   When a client receives a subscription request from another entity, it
   MAY accept the request by sending a presence stanza of type
   "subscribed" or decline the request by sending a presence stanza of
   type "unsubscribed".

   Accepting a subscription request:

   <presence to="romeo@montague.net" type="subscribed"/>

   Denying a presence subscription request:

   <presence to="romeo@montague.net" type="unsubscribed"/>

   A user's server MUST NOT automatically accept subscription requests
   on the user's behalf. All subscription requests MUST be directed to
   the user's client. If there is no connected resource associated with
   the user when the subscription request is received, the user's server
   MUST store the subscription request offline for delivery when the
   user next becomes available.

5.3 Cancelling a Subscription from Another Entity

   If a user would like to cancel a previously-granted subscription



Saint-Andre & Miller    Expires August 24, 2003                [Page 14]


Internet-Draft           XMPP Instant Messaging            February 2003


   request, it sends a presence stanza of type "unsubscribed".

   Cancelling a previously granted subscription request:

   <presence to="romeo@montague.net" type="unsubscribed"/>


5.4 Unsubscribing from Another Entity's Presence

   If a user would like to unsubscribe from the presence of another
   entity, it sends a presence stanza of type "unsubscribe".

   Unsubscribing from an entity's presence:

   <presence to="juliet@capulet.com" type="unsubscribe"/>




































Saint-Andre & Miller    Expires August 24, 2003                [Page 15]


Internet-Draft           XMPP Instant Messaging            February 2003


6. Managing One's Roster

   In XMPP, one's contact list is called a roster. A roster is stored by
   the server on the user's behalf so that a user may access roster
   information from any connected resource.

6.1 Retrieving One's Roster on Login

   Upon connecting to the server, a client MAY request the roster
   (however, because receiving the roster may not be desirable for all
   resources, e.g., a connection with limited bandwidth, the client's
   request for the roster is OPTIONAL).

   Client requests current roster from server:

   <iq id="roster_1" type="get">
     <query xmlns="jabber:iq:roster"/>
   </iq>

   Client receives roster from the server:

   <iq
       from="capulet.com"
       to="juliet@capulet.com/balcony"
       id="roster_1"
       type="result">
     <query xmlns="jabber:iq:roster>
       <item
           jid="romeo@montague.net"
           name="Romeo"
           subscription="both"/>
       <item
           jid="mercutio@montague.net"
           name="Mercutio"
           subscription="both">
         <group>Friends</group>
       </item>
       <item
           jid="benvolio@montague.net"
           name="Benvolio"
           subscription="both">
         <group>Friends</group>
       </item>
     </query>
   </iq>






Saint-Andre & Miller    Expires August 24, 2003                [Page 16]


Internet-Draft           XMPP Instant Messaging            February 2003


6.2 Adding a Roster Item

   At any time, a user MAY add an item to his or her roster.

   Client adds a new item:

   <iq type="set" id="roster_2">
     <query xmlns="jabber:iq:roster">
       <item
           name="Nurse"
           jid="nurse@capulet.com">
         <group>Servants</group>
       </item>
     </query>
   </iq>

   The server is responsible for updating the roster information in
   persistent storage, and also for pushing that change out to all
   connected resources associated with the user using an IQ stanza of
   type "set" (this is referred to as a "roster push"). This "roster
   push" enables all connected resources to remain in sync with the
   server-based roster information.





























Saint-Andre & Miller    Expires August 24, 2003                [Page 17]


Internet-Draft           XMPP Instant Messaging            February 2003


   Server replies with an IQ result to the sending resource and pushes
   the updated roster information to all connected resources:

   <iq
       from="capulet.com"
       to="juliet@capulet.com/balcony"
       type="result"
       id="roster_2"/>
   <iq
       from="capulet.com"
       to="juliet@capulet.com/balcony"
       type="set"
       id="roster_3"/>
     <query xmlns="jabber:iq:roster">
       <item
           name="Nurse"
           jid="nurse@capulet.com"
           subscription="none">
         <group>Servants</group>
       </item>
     </query>
   </iq>
   <iq
       from="capulet.com"
       to="juliet@capulet.com/chamber"
       type="set"
       id="roster_3"/>
     <query xmlns="jabber:iq:roster">
       <item
           name="Nurse"
           jid="nurse@capulet.com"
           subscription="none">
         <group>Servants</group>
       </item>
     </query>
   </iq>

   Updating an existing roster item (e.g., changing the Group) is done
   in the same way as adding a new roster item, i.e., by sending the
   roster item in an IQ set to the server.

6.3 Deleting a Roster Item

   At any time, a user MAY delete an item from its roster by doing an IQ
   set and making sure that the value of the 'subscription' attribute is
   "remove" (a compliant server SHOULD ignore any other values of the
   'subscription' attribute when received from a client).




Saint-Andre & Miller    Expires August 24, 2003                [Page 18]


Internet-Draft           XMPP Instant Messaging            February 2003


   Client removes an item:

   <iq type="set" id="roster_2">
     <query xmlns="jabber:iq:roster">
       <item
           name="Nurse"
           jid="nurse@capulet.com"
           subscription="remove">
         <group>Servants</group>
       </item>
     </query>
   </iq>

   As with adding a roster item, when deleting a roster item the server
   is responsible for updating the roster information in persistent
   storage, and also for initiating a "roster push" to all connected
   resources associated with the user.

   For further information about the implications of this command, see
   Section 7.6.































Saint-Andre & Miller    Expires August 24, 2003                [Page 19]


Internet-Draft           XMPP Instant Messaging            February 2003


7. Integration of Roster Items and Presence Subscriptions

7.1 Overview

   Some level of integration between roster items and presence
   subscriptions is normally expected by instant messaging users. This
   section describes the level of integration that must be supported
   within XMPP IM.

   There are four primary subscription states:

   o  None -- Neither the user nor the contact is subscribed to the
      other's presence

   o  To -- The user is subscribed to the contact's presence but there
      is no subscription from the contact to the user

   o  From -- There is a subscription from the contact to the user, but
      the user has not subscribed to the contact's presence

   o  Both -- Both the user and the contact are subscribed to each
      other's presence

   Each of these states is reflected in the roster of both the user and
   the contact, thus resulting in durable subscription states. The
   details regarding how these subscription states interact with roster
   items is explained in the following sub-sections.

7.2 User Subscribes to Contact

   The process by which a user subscribes to a contact, including the
   interaction between roster items and subscription states, is defined
   below.

   1.  In preparation for being able to render the contact in the user's
       client interface and for the server to keep track of the
       subscription, the user's client MUST send an IQ stanza of
       type='set' in the jabber:iq:roster namespace; the <item/> element
       MUST possess a 'jid' attribute, MAY possess a 'name' attribute,
       may contain a <group/> child, and MUST NOT posses a
       'subscription' attribute:

   <iq type='set' id='int1'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'/>
     </query>



Saint-Andre & Miller    Expires August 24, 2003                [Page 20]


Internet-Draft           XMPP Instant Messaging            February 2003


   </iq>

   2.  The server then MUST (1) reply with an IQ stanza of type='result'
       and (2) initiate a "roster push" for the new roster item to all
       connected resources associated with this user, setting the
       subscription state set to 'none':

   <iq
       type='result'
       to='user@domain/resource'
       id='int1'/>

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='none'/>
     </query>
   </iq>

   3.  In order to initiate the subscription, the user's client MUST
       then send a presence stanza of type='subscribe' to the contact:

   <presence to='contact@domain' type='subscribe'/>

   4.  The server MUST then initiate a second "roster push" to all
       connected resources associated with the user, 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' attribute in the roster item:

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='none'
           ask='subscribe'/>
     </query>
   </iq>

   5.  The server MUST also deliver the presence stanza to the contact
       or route it to the contact's server for delivery to the contact,
       first stamping the stanza with the user's bare JID as the 'from'
       address:





Saint-Andre & Miller    Expires August 24, 2003                [Page 21]


Internet-Draft           XMPP Instant Messaging            February 2003


   <presence
       to='contact@domain'
       from='user@domain'
       type='subscribe'/>

   6.  If the contact is online (i.e., there is a connected resource
       associated with the contact's account), the contact must now
       decide whether or not to accept the subscription request. (If the
       contact is offline, the contact's server MUST store the
       subscription request offline for delivery when the contact next
       becomes available.) Here we will assume the "happy path" that the
       contact accepts the subscription, in which case the contact's
       client MAY send a roster set to the server specifying the desired
       nickname and group for the user, and MUST send a presence stanza
       of type='subscribed' to the user.

   <iq type='set'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'/>
     </query>
   </iq>

   <presence to='user@domain' type='subscribed'/>

   7.  The contact's server MUST now initiate a "roster push" to all
       connected resources associated with the contact, containing a
       roster item for the user with the subscription state set to
       'from':

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='from'/>
     </query>
   </iq>

   8.  As a result of the fact that the contact has accepted the
       subscription request, the user's server MUST (1) deliver the
       presence stanza of type='subscribed' from the contact to the
       user, and (2) initiate a "roster push" to all connected resources
       associated with the user, containing an updated roster item for
       the contact with the subscription type set to a value of "to":





Saint-Andre & Miller    Expires August 24, 2003                [Page 22]


Internet-Draft           XMPP Instant Messaging            February 2003


   <presence
       to='user@domain'
       type='subscribed'
       from='contact@domain'/>

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
     <item
         jid='contact@domain'
         name='MyContact'
         subscription='to'/>
     </query>
   </iq>

   9.  From the perspective of the user, there is now a subscription to
       the contact; from the perspective of the contact, there is now a
       subscription from the user. (Note: If at this point the user
       sends another subscription request to the contact, the user's
       server will "swallow" that request and not send it on the
       contact.)

   The above activity flow represents the "happy path" related to the
   user's subscription request to the contact. The main alternate flow
   occurs if the contact denies the user's subscription request; in
   order to deny the request, the contact's client MUST send a presence
   stanza of type "unsubscribed" to the user:

   <presence to='user@domain' type='unsubscribed'/>

   The user's server MUST then (1) deliver that presence stanza to the
   user and (2) initiate a "roster push" to all connected resources
   associated with the user, with the subscription attribute set to a
   value of "none":

   <presence
       to='user@domain'
       type='unsubscribed'
       from='contact@domain'/>

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='none'/>
     </query>
   </iq>




Saint-Andre & Miller    Expires August 24, 2003                [Page 23]


Internet-Draft           XMPP Instant Messaging            February 2003


   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.

7.3 Creating a Mutual Subscription

   The user and contaact can build on the foregoing to create a mutual
   subscription (i.e., a subscription of type "both"). The process is
   defined below.

   1.  The contact MUST send a subscription request to the user (subject
       to user preferences, the contact's client MAY send this
       automatically):

   <presence to='user@domain' type='subscribe'/>

   2.  The contact's server MUST then initiate a "roster push" to all
       connected resources associated with the contact, 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:

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='from'
           ask='subscribe'/>
     </query>
   </iq>

   3.  If the user is online (i.e., there is a connected resource
       associated with the user's account), the user must now decide
       whether or not to accept the subscription request. (If the user
       is offline, the user's server MUST store the subscription request
       offline for delivery when the user next becomes available.) Here
       we will assume the "happy path" that the user accepts the
       subscription, in which case the user's client MUST send a
       presence stanza of type='subscribed' to the contact.

   <presence to='contact@domain' type='subscribe'/>

   4.  The user's server MUST then initiate a "roster push" to all
       connected resources associated with the user, containing a roster
       item for the contact with the subscription attribute set to a
       value of "both":




Saint-Andre & Miller    Expires August 24, 2003                [Page 24]


Internet-Draft           XMPP Instant Messaging            February 2003


   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='both'/>
     </query>
   </iq>

   5.  As a result of the fact that the user has accepted the
       subscription request, the contact's server MUST (1) deliver the
       presence stanza of type='subscribed' from the user to the
       contact, and (2) initiate a "roster push" to all connected
       resources associated with the contact, containing an updated
       roster item for the user with the subscription type set to a
       value of "both":

   <presence
       to='contact@domain'
       from='user@domain'
       type='subscribed'/>

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
     <item
         jid='user@domain'
         name='SomeUser'
         subscription='both'/>
     </query>
   </iq>

   The user and the contact now have a mutual subscription to each
   other's presence -- i.e., the subscription is of type 'both'. (Note:
   If at this point the user sends a subscription request to the contact
   or the contact sends a subscription request to the user, the sending
   user's server will "swallow" that request and not send it on the
   intended recipient.)

   The above activity flow represents the "happy path" related to the
   contact's subscription request to the user. The main alternate flow
   occurs if the user denies the contacts's subscription request; in
   order to deny the request, the user's client MUST send a presence
   stanza of type "unsubscribed" to the contact:

   <presence to='contact@domain' type='unsubscribed'/>

   The contact's server MUST then (1) deliver that presence stanza to
   the contact and (2) initiate a "roster push" to all connected



Saint-Andre & Miller    Expires August 24, 2003                [Page 25]


Internet-Draft           XMPP Instant Messaging            February 2003


   resources associated with the contact, with the subscription
   attribute set to a value of "from" and with no 'ask' attribute:

   <presence
       to='contact@domain'
       from='user@domain'
       type='from'/>

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='from'/>
     </query>
   </iq>

   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
   with a subscription state of "from".

7.4 Unsubscribing

   At any time after subscribing to a contact's presence, a user MAY
   unsubscribe. While the 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 command is sent. Both possible scenarios are defined
   below.

7.4.1 Case #1: Subscription Type 'to'

   In the first case, the user has a subscription to the contact but the
   contact does not have a subscription to the user (i.e., the
   subscription is not yet mutual).

   1.  In order to unsubscribe from the contact's presence, the user
       MUST a presence stanza of type "unsubscribe" to the contact:

   <presence to='contact@domain' type='unsubscribe'/>

   2.  As a result, the user's server MUST send a "roster push" to each
       connected resource associated with the user, containing a roster
       item for the contact with the 'ask' attribute set to unsubscribe
       to indicate that the unsubscribe is pending:





Saint-Andre & Miller    Expires August 24, 2003                [Page 26]


Internet-Draft           XMPP Instant Messaging            February 2003


   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='to'
           ask='unsubscribe'/>
     </query>
   </iq>

   3.  Since the unsubscribe command does not need to be approved by the
       contact, the contact's server then SHOULD auto-reply on behalf of
       the contact by sending a presence stanza of type "unsubscribed"
       to the user:

   <presence
       to='user@domain'
       from='contact@domain'
       type='unsubscribed'/>

   4.  The contact's server also MUST initiate a "roster push" to all
       connected resources associated with the contact, containing a
       roster item for the user with the 'subscription' attribute set to
       a value of "none" (if the contact is offline, the contact's
       server MUST modify the roster item and send that modified item
       the next time the contact requests the roster):

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='none'/>
     </query>
   </iq>

   5.  As a result of the fact that the contact has acknowledged the
       unsubscribe command, the user's server MUST (1) deliver the
       presence stanza of type='unsubscribed' from the contact to the
       user, and (2) initiate a "roster push" to all connected resources
       associated with the user, containing an updated roster item for
       the contact with the subscription type set to a value of "none"
       and with no 'ask' attribute:








Saint-Andre & Miller    Expires August 24, 2003                [Page 27]


Internet-Draft           XMPP Instant Messaging            February 2003


   <iq type='set'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           subscription='none'
           name='MyContact'/>
     </query>
   </iq>


7.4.2 Case #2: Subscription Type 'both'

   In the second case, the user has a subscription to the contact and
   the contact also has a subscription to the user.

   1.  In order to unsubscribe from the contact's presence, the user
       MUST a presence stanza of type "unsubscribe" to the contact:

   <presence to='contact@domain' type='unsubscribe'/>

   2.  As a result, the user's server MUST send a "roster push" to each
       connected resource associated with the user, containing a roster
       item for the contact with the 'ask' attribute set to unsubscribe
       to indicate that the unsubscribe is pending:

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='both'
           ask='unsubscribe'/>
     </query>
   </iq>

   3.  Since the unsubscribe command does not need to be approved by the
       contact, the contact's server then SHOULD auto-reply on behalf of
       the contact by sending a presence stanza of type "unsubscribed"
       to the user:

   <presence
       to='user@domain'
       from='contact@domain'
       type='unsubscribed'/>

   4.  The contact's server also MUST initiate a "roster push" to all
       connected resources associated with the contact, containing a
       roster item for the user with the 'subscription' attribute set to



Saint-Andre & Miller    Expires August 24, 2003                [Page 28]


Internet-Draft           XMPP Instant Messaging            February 2003


       a value of "to" (if the contact is offline, the contact's server
       MUST modify the roster item and send that modified item the next
       time the contact requests the roster):

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='to'/>
     </query>
   </iq>

   5.  As a result of the fact that the contact has acknowledged the
       unsubscribe command, the user's server MUST (1) deliver the
       presence stanza of type='unsubscribed' from the contact to the
       user, and (2) initiate a "roster push" to all connected resources
       associated with the user, containing an updated roster item for
       the contact with the subscription type set to a value of "from"
       and with no 'ask' attribute:

   <iq type='set'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           subscription='none'
           name='MyContact'/>
     </query>
   </iq>

   NOTE: Obviously this does not result in removal of the roster item
   from the user's roster, and the contact still has a subscription to
   the user's presence. In order to more completely cancel a mutual
   subscription and fully remove the roster item from the user's roster,
   the user should update the roster item with subscription='remove' as
   defined in Section 7.6.

7.5 Cancelling a Subscription

   At any time after approving a subscription request from a user, a
   contact MAY cancel that subscription. While the 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 is sent. Both
   possible scenarios are defined below.

7.5.1 Case #1: Subscription Type 'from'




Saint-Andre & Miller    Expires August 24, 2003                [Page 29]


Internet-Draft           XMPP Instant Messaging            February 2003


   In the first case, the user has a subscription to the contact but the
   contact does not have a subscription to the user (i.e., the
   subscription is not yet mutual).

   1.  In order to cancel the user's subscription, the contact MUST a
       presence stanza of type "unsubscribed" to the user:

   <presence to='user@domain' type='unsubscribed'/>

   2.  As a result, the contact's server MUST send a "roster push" to
       each connected resource associated with the contact, containing a
       roster item for the user with the 'subscription' attribute set to
       a value of "none":

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='none'/>
     </query>
   </iq>

   3.  The user's server MUST then initiate a "roster push" to all
       connected resources associated with the user, containing a roster
       item for the contact with the 'subscription' attribute set to a
       value of "none" (if the user is offline, the user's server MUST
       modify the roster item and send that modified item the next time
       the user requests the roster):

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='none'/>
     </query>
   </iq>


7.5.2 Case #2: Subscription Type 'both'

   In the second case, the user has a subscription to the contact and
   the contact also has a subscription to the user.

   1.  In order to cancel the user's subscription, the user MUST a
       presence stanza of type "unsubscribed" to the user:




Saint-Andre & Miller    Expires August 24, 2003                [Page 30]


Internet-Draft           XMPP Instant Messaging            February 2003


   <presence to='user@domain' type='unsubscribed'/>

   2.  As a result, the contact's server MUST send a "roster push" to
       each connected resource associated with the contact, containing a
       roster item for the user with the 'subscription' attribute set to
       a value of "to":

   <iq type='set' to='contact@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='to'/>
     </query>
   </iq>

   3.  The user's server MUST then initiate a "roster push" to all
       connected resources associated with the user, containing a roster
       item for the contact with the 'subscription' attribute set to a
       value of "from" (if the user is offline, the user's server MUST
       modify the roster item and send that modified item the next time
       the user requests the roster):

   <iq type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='from'/>
     </query>
   </iq>

   NOTE: Obviously this does not result in removal of the roster item
   from the contact's roster, and the contact still has a subscription
   to the user's presence. In order to more completely cancel a mutual
   subscription and fully remove the roster item from the contact's
   roster, the contact should update the roster item with
   subscription='remove' as defined in Section 7.6.

7.6 Removing a Roster Item and Cancelling All Subscriptions

   Because there may be many steps involved in completely removing a
   roster item and reverting the subscription state to "none", XMPP IM
   includes a "shortcut" method for doing so. The process may be
   initiated by either a contact or a user no matter what the current
   subscription state is, by means of sending a roster set with the
   subscription attribute set to a value of "remove".




Saint-Andre & Miller    Expires August 24, 2003                [Page 31]


Internet-Draft           XMPP Instant Messaging            February 2003


   For example, a user may send the following XML:

   <iq type='set'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='remove'/>
     </query>
   </iq>

   When the user removes a contact from his or her roster by setting the
   'subscription' attribute to a value of "remove", the user's server
   MUST automatically cancel any existing presence subscription between
   the user and the contact by sending presence stanzas of type
   "unsubscribe" and "unsubscribed" from the user to the contact.

   A contact may also send such a command, resulting in the same type of
   system behavior.
































Saint-Andre & Miller    Expires August 24, 2003                [Page 32]


Internet-Draft           XMPP Instant Messaging            February 2003


8. Blocking Communication

   Most instant messaging systems have found it necessary to implement
   some method for users to block communications from particular other
   users (this is also required by sections 5.1.5, 5.1.15, 5.3.2, and
   5.4.10 of RFC 2779 [2]). In XMPP this is done using the
   'jabber:iq:privacy' namespace by managing one's privacy lists (also
   called "zebra lists" since they are flexible combinations of
   blacklists and whitelists).

   Server-side privacy lists enable successful completion of the
   following use cases:

   o  Retreiving one's privacy lists.

   o  Adding, removing, and editing one's privacy lists.

   o  Setting, changing, or declining active lists.

   o  Setting, changing, or declining the default list.

   o  Allowing or denying messages based on JID, group, or subscription
      type (or globally).

   o  Allowing or denying inbound presence information based on JID,
      group, or subscription type (or globally).

   o  Allowing or denying outbound presence information based on JID,
      group, or subscription type (or globally).

   o  Allowing or denying IQs based on JID, group, or subscription type
      (or globally).

   o  Allowing or denying all communications based on JID, group, or
      subscription type (or globally).


8.1 Retrieving One's Privacy Lists

   Client requests names of privacy lists from server:

   <iq type='get' id='getlist1'>
     <query xmlns='jabber:iq:privacy'/>
   </iq>







Saint-Andre & Miller    Expires August 24, 2003                [Page 33]


Internet-Draft           XMPP Instant Messaging            February 2003


   Server sends names of privacy lists to client, including default list
   and active list:

   <iq type='result' id='getlist1' to='romeo@montague.net/orchard'>
     <query xmlns='jabber:iq:privacy'>
       <default name='public'/>
       <active name='private'/>
       <list name='public'>
       <list name='private'/>
       <list name='special'/>
     </query>
   </iq>

   Client requests complete privacy lists from server:

   <iq type='get' id='getlist2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='public'>
       <list name='private'/>
       <list name='special'/>
     </query>
   </iq>

   Server sends complete privacy lists to client:

   <iq type='result' id='getlist2' to='romeo@montague.net/orchard'>
     <query xmlns='jabber:iq:privacy'>
       <list name='public'>
         <item jid='tybalt@capulet.com' type='deny'/>
         <item action='allow'/>
       </list>
       <list name='private'>
         <item filter='subscription' value='both' action='allow'/>
         <item action='deny'/>
       </list>
       <list name='special'>
         <item filter='jid' value='juliet@capulet.com' action='allow'/>
         <item filter='jid' value='benvolio@shakespeare.lit' action='allow'/>
         <item filter='jid' value='mercutio@shakespeare.lit' action='allow'/>
         <item action='deny'/>
       </list>
     </query>
   </iq>

   In this example, the user has three lists: (1) 'public', which allows
   communications from everyone except one specific entity; (2)
   'private', which allows communications only from contacts who have a
   bi-directional subscription with the user; and (3) 'special', which



Saint-Andre & Miller    Expires August 24, 2003                [Page 34]


Internet-Draft           XMPP Instant Messaging            February 2003


   allows communications only from three specific entities. The active
   list currently being applied by the server is the 'private' list.

8.2 Managing Active Lists

   In order to set or change the active list currently being applied by
   the server, the user MUST send an IQ stanza of type 'set' with a
   <query/> element scoped by the 'jabber:iq:privacy' namespace that
   contains an empty <active/> child element possessing a 'name'
   attribute whose value is set to the desired list name.

   Client requests change of active list:

   <iq type='set' id='active1'>
     <query xmlns='jabber:iq:privacy'>
       <active name='special'/>
     </query>
   </iq>

   Server acknowledges success of active list change:

   <iq type='result' id='active1' to='juliet@capulet.com/balcony'/>

   In order to decline the use of any active list (i.e., to use the
   domain's stanza routing rules), a user MUST send an empty <active/>
   element with no name.

   Client declines the use of active lists:

   <iq type='set' id='active2'>
     <query xmlns='jabber:iq:privacy'>
       <active/>
     </query>
   </iq>


8.3 Managing the Default List

   In order to change the default list associated with an account, the
   user MUST send an IQ stanza of type 'set' with a <query/> element
   scoped by the 'jabber:iq:privacy' namespace that contains an empty
   <default/> child element possessing a 'name' attribute whose value is
   set to the desired list name.








Saint-Andre & Miller    Expires August 24, 2003                [Page 35]


Internet-Draft           XMPP Instant Messaging            February 2003


   Client requests change of default list:

   <iq type='set' id='default1'>
     <query xmlns='jabber:iq:privacy'>
       <default name='special'/>
     </query>
   </iq>

   Server acknowledges success of default list change:

   <iq type='result' id='default1' to='juliet@capulet.com/balcony'/>

   In order to decline the use of any default list (i.e., to use the
   domain's stanza routing rules), a user MUST send an empty <default/>
   element with no name.

   Client declines the use of active lists:

   <iq type='set' id='default2'>
     <query xmlns='jabber:iq:privacy'>
       <default/>
     </query>
   </iq>


8.4 Editing a Privacy List

   In order to edit a privacy list, the user MUST send an IQ stanza of
   type 'set' with a <query/> element scoped by the 'jabber:iq:privacy'
   namespace that contains one or more <list/> child elements possessing
   a 'name' attribute whose value is set to the list name the user would
   like to edit. Each <list/> element MUST contain one or more <item/>
   elements, which specify the user's desired changes to the list by
   including all elements in the list (not the "delta"); the same
   protocol is used to create a new list.

   Client edits a privacy list:

   <iq type='set' id='edit1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='public'>
         <item filter='jid' value='tybalt@capulet.com' action='deny'/>
         <item filter='jid' value='paris@shakespeare.lit' action='deny'/>
         <item action='allow'/>
       </list>
     </query>
   </iq>




Saint-Andre & Miller    Expires August 24, 2003                [Page 36]


Internet-Draft           XMPP Instant Messaging            February 2003


   Server acknowledges success of list edit:

   <iq type='result' id='edit1' to='juliet@capulet.com/balcony'/>

   In this example, the user has added one additional entity to the
   "blacklist" portion of this privacy list.

8.5 Removing a Privacy List

   In order to remove a privacy list, the user MUST send an IQ stanza of
   type 'set' with a <query/> element scoped by the 'jabber:iq:privacy'
   namespace that contains one or more empty <list/> child elements
   possessing a 'name' attribute whose value is set to the list name the
   user would like to remove.

   Client removes a privacy list:

   <iq type='set' id='remove1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='private'/>
     </query>
   </iq>

   Server acknowledges success of list removal:

   <iq type='result' id='remove1' to='juliet@capulet.com/balcony'/>


8.6 Blocking Messages

   Server-side privacy lists enable a user to block incoming messages
   from other users based on the other user's JID, roster group, or
   subscription status, or globally. The following examples illustrate
   the required protocol.

   User blocks based on JID:

   <iq type='set' id='msg1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='message-jid-example'>
         <item filter='jid' value='tybalt@capulet.com' type='deny'>
           <message/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user



Saint-Andre & Miller    Expires August 24, 2003                [Page 37]


Internet-Draft           XMPP Instant Messaging            February 2003


   will not receive messages from the user with the specified JID.

   User blocks based on roster group:

   <iq type='set' id='msg2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='message-group-example'>
         <item filter='group' value='Enemies' type='deny'>
           <message/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive messages from any users in the specified roster
   group.

   User blocks based on subscription type:

   <iq type='set' id='msg2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='message-sub-example'>
         <item filter='subscription' value='none' type='deny'>
           <message/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive messages from any users with the specified
   subscription type.

   User blocks globally:

   <iq type='set' id='msg4'>
     <query xmlns='jabber:iq:privacy'>
       <list name='message-global-example'>
         <item type='deny'>
           <message/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive messages from any other users.



Saint-Andre & Miller    Expires August 24, 2003                [Page 38]


Internet-Draft           XMPP Instant Messaging            February 2003


8.7 Blocking Inbound Presence

   Server-side privacy lists enable a user to block incoming presence
   information from other users based on the other user's JID, roster
   group, or subscription status, or globally. The following examples
   illustrate the required protocol.

   User blocks based on JID:

   <iq type='set' id='presin1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presin-jid-example'>
         <item filter='jid' value='tybalt@capulet.com' type='deny'>
           <presence-in/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive presence information from the user with the
   specified JID.

   User blocks based on roster group:

   <iq type='set' id='presin2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presin-group-example'>
         <item filter='group' value='Enemies' type='deny'>
           <presence-in/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive presence information from any users in the specified
   roster group.













Saint-Andre & Miller    Expires August 24, 2003                [Page 39]


Internet-Draft           XMPP Instant Messaging            February 2003


   User blocks based on subscription type:

   <iq type='set' id='presin3'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presin-sub-example'>
         <item filter='subscription' value='none' type='deny'>
           <presence-in/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive presence information from any users with the
   specified subscription type.

   User blocks globally:

   <iq type='set' id='presin4'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presin-global-example'>
         <item type='deny'>
           <presence-in/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive presence information from any other users.

8.8 Blocking Outbound Presence

   Server-side privacy lists enable a user to block outgoing presence
   information to other users based on the other user's JID, roster
   group, or subscription status, or globally. The following examples
   illustrate the required protocol.














Saint-Andre & Miller    Expires August 24, 2003                [Page 40]


Internet-Draft           XMPP Instant Messaging            February 2003


   User blocks based on JID:

   <iq type='set' id='presout1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presout-jid-example'>
         <item filter='jid' value='tybalt@capulet.com' type='deny'>
           <presence-out/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not send presence information to the user with the specified
   JID.

   User blocks based on roster group:

   <iq type='set' id='presout2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presout-group-example'>
         <item filter='group' value='Enemies' type='deny'>
           <presence-out/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not send presence information to any users in the specified
   roster group.

   User blocks based on subscription type:

   <iq type='set' id='presout3'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presout-sub-example'>
         <item filter='subscription' value='none' type='deny'>
           <presence-out/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not send presence information to any users with the specified
   subscription type.




Saint-Andre & Miller    Expires August 24, 2003                [Page 41]


Internet-Draft           XMPP Instant Messaging            February 2003


   User blocks globally:

   <iq type='set' id='presout4'>
     <query xmlns='jabber:iq:privacy'>
       <list name='presout-global-example'>
         <item type='deny'>
           <presence-out/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not send presence information to any other users.

8.9 Blocking IQs

   Server-side privacy lists enable a user to block incoming IQ requests
   from other users based on the other user's JID, roster group, or
   subscription status, or globally. The following examples illustrate
   the required protocol.

   User blocks based on JID:

   <iq type='set' id='msg1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='iq-jid-example'>
         <item filter='jid' value='tybalt@capulet.com' type='deny'>
           <iq/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive IQ requests from the user with the specified JID.

   User blocks based on roster group:

   <iq type='set' id='msg2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='iq-group-example'>
         <item filter='group' value='Enemies' type='deny'>
           <iq/>
         </item>
       </list>
     </query>
   </iq>



Saint-Andre & Miller    Expires August 24, 2003                [Page 42]


Internet-Draft           XMPP Instant Messaging            February 2003


   As a result of creating and applying the foregoing list, the user
   will not receive IQ requests from any users in the specified roster
   group.

   User blocks based on subscription type:

   <iq type='set' id='msg2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='iq-sub-example'>
         <item filter='subscription' value='none' type='deny'>
           <iq/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive IQ requests from any users with the specified
   subscription type.

   User blocks globally:

   <iq type='set' id='msg4'>
     <query xmlns='jabber:iq:privacy'>
       <list name='iq-global-example'>
         <item type='deny'>
           <iq/>
         </item>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive IQ requests from any other users.

8.10 Blocking All Communication

   Server-side privacy lists enable a user to block all communications
   from and presence to other users based on the other user's JID,
   roster group, or subscription status, or globally. The following
   examples illustrate the required protocol.










Saint-Andre & Miller    Expires August 24, 2003                [Page 43]


Internet-Draft           XMPP Instant Messaging            February 2003


   User blocks based on JID:

   <iq type='set' id='all1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='all-jid-example'>
         <item filter='jid' value='tybalt@capulet.com' type='deny'>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive any communications from, nor send presence to, the
   user with the specified JID.

   User blocks based on roster group:

   <iq type='set' id='all2'>
     <query xmlns='jabber:iq:privacy'>
       <list name='all-group-example'>
         <item filter='group' value='Enemies' type='deny'/>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive any communications from, nor send presence to, any
   users in the specified roster group.

   User blocks based on subscription type:

   <iq type='set' id='all3'>
     <query xmlns='jabber:iq:privacy'>
       <list name='all-sub-example'>
         <item filter='subscription' value='none' type='deny'/>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive any communications from, nor send presence to, any
   users with the specified subscription type.










Saint-Andre & Miller    Expires August 24, 2003                [Page 44]


Internet-Draft           XMPP Instant Messaging            February 2003


   User blocks globally:

   <iq type='set' id='all4'>
     <query xmlns='jabber:iq:privacy'>
       <list name='all-global-example'>
         <item type='deny'/>
       </list>
     </query>
   </iq>

   As a result of creating and applying the foregoing list, the user
   will not receive any communications from, nor send presence to, any
   other users.

8.11 Blocked Entity Attempts to Send Message to User

   If a blocked entity attempts to send a message to the user, the
   user's server SHOULD return an error of type 405 (Not Allowed) to the
   sending entity.

   Blocked entity attempts to send message:

   <message to='romeo@montague.net' from='tybalt@capulet.com/pda'>
     <body>Have at thee, coward!</body>
   </message>

   Server returns error to blacklisted entity:

   <message
       type='error'
       from='romeo@montague.net'
       to='tybalt@capulet.com/pda'>
     <body>Have at thee, coward!</body>
     <error code='405'>Not Allowed</error>
   </message>

   Such error messages SHOULD also be sent regarding IQ messages, not
   regarding presence.

8.12 Higher-Level Heuristics

   When building a representation of a higher-level privacy heuristic, a
   client SHOULD use the simplest possible representation. For example,
   the heuristic "block all communications with any user not in my
   roster" could be constructed in any of the following ways:

   o  accept communications from all JIDs in my roster (i.e., listing
      each JID as a separate list item), but deny communications with



Saint-Andre & Miller    Expires August 24, 2003                [Page 45]


Internet-Draft           XMPP Instant Messaging            February 2003


      everyone else

   o  accept communications from any user who is in one of the groups
      that make up my roster (i.e., listing each group as a separate
      list item), but deny communications from everyone else

   o  accept communications from any user with whom I have a
      subscription of 'both' or 'to' or 'from' (i.e., listing each
      subscription value separately), but deny communications from
      everyone else

   o  deny communications from anyone whose subscription state is 'none'

   The final representation is the simplest and SHOULD be used; here is
   the XML that would be sent in this case:

   Client constructs simple representation of heuristic for accepting
   communications only with those in the user's roster:

   <iq type='set' id='heuristic1'>
     <query xmlns='jabber:iq:privacy'>
       <list name='heuristic-example'>
         <item filter='subscription' value='none' type='deny'/>
       </list>
     </query>
   </iq>

   A more complete list of such heuristics and their simplest
   representations may be provided in a future revision of this
   document.

8.13 Processing Order

   The order in which privacy list items are processed by the server is
   important. List items MUST be processed in order of granularity,
   according to the following hierarchy of 'filter' attribute values
   (from most to least granular):

   1.  jid

   2.  group

   3.  subscription

   4.  No 'filter' attribute ("fall-through" case)

   As soon as a rule is matched, the server can appropriately route the
   stanza and cease processing.



Saint-Andre & Miller    Expires August 24, 2003                [Page 46]


Internet-Draft           XMPP Instant Messaging            February 2003


   If no fall-through item is provided in a list, the fall-through
   action is assumed to be "accept".

















































Saint-Andre & Miller    Expires August 24, 2003                [Page 47]


Internet-Draft           XMPP Instant Messaging            February 2003


9. Security Considerations

   For security considerations, refer to the relevant section of XMPP
   Core [1].















































Saint-Andre & Miller    Expires August 24, 2003                [Page 48]


Internet-Draft           XMPP Instant Messaging            February 2003


References

   [1]  Saint-Andre, P. and J. Miller, "XMPP Core
        (draft-ietf-xmpp-core-03, work in progress)", February 2003.

   [2]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
        Presence and Instant Messaging", RFC 2779, February 2000,
        <http://www.ietf.org/rfc/rfc2779.txt>.

   [3]  Jabber Software Foundation, "Jabber Software Foundation", August
        2001, <http://www.jabber.org/>.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
        Instant Messaging", RFC 2778, February 2000, <http://
        www.ietf.org/rfc/rfc2778.txt>.

   [6]  Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC
        2426, September 1998.


Authors' Addresses

   Peter Saint-Andre
   Jabber Software Foundation

   EMail: stpeter@jabber.org
   URI:   http://www.jabber.org/people/stpeter.php


   Jeremie Miller
   Jabber Software Foundation

   EMail: jeremie@jabber.org
   URI:   http://www.jabber.org/people/jer.php














Saint-Andre & Miller    Expires August 24, 2003                [Page 49]


Internet-Draft           XMPP Instant Messaging            February 2003


Appendix A. vCards

   This section is provided for informational purposes only and is not
   normative.

   Sections 3.1.3 and 4.1.4 of RFC 2779 [2] require that it be possible
   to retrieve non-IM contact information for other users (e.g.,
   telephone number or email address). An XML representation of the
   vCard specification defined in RFC 2426 [6] is in common use within
   the Jabber community to provide such information. For the sake of
   completeness, this section describes that protocol. This section is
   non-normative.

   The basic functionality is for a user to store and retrieve an XML
   representation of his or her vCard using the data storage
   capabilities native to all existing Jabber server implementations.
   This is done by sending an <iq/> of type "set" (storage) or "get"
   (retrieval) to one's Jabber server containing a <vCard/> child scoped
   by the 'vcard-temp' namespace, with the <vCard/> element containing
   the actual vCard-XML elements as defined by the vCard-XML DTD. Other
   users may then view one's vCard information. (There is currently no
   access control over who may view vCard information.)

A.1 Retrieving One's vCard

   A user may retrieve his or her own vCard by sending XML of the
   following form to his or her own JID:

   <iq to='stpeter@jabber.org' type='get' id='vcard1'>
     <vCard xmlns='vcard-temp'/>
   </iq>

   The server must then return the vCard to the user:

   <iq
       from='stpeter@jabber.org'
       to='stpeter@jabber.org/Gabber'
       type='result'
       id='v1'>
     <vCard xmlns='vcard-temp'>
       <FN>Peter Saint-Andre</FN>
       <N>
         <FAMILY>Saint-Andre<FAMILY>
         <GIVEN>Peter</GIVEN>
         <MIDDLE/>
       </N>
       <NICKNAME>stpeter</NICKNAME>
       <URL>http://www.jabber.org/people/stpeter.php</URL>



Saint-Andre & Miller    Expires August 24, 2003                [Page 50]


Internet-Draft           XMPP Instant Messaging            February 2003


       <BDAY>1966-08-06</BDAY>
       <ORG>
         <ORGNAME>Jabber Software Foundation</ORGNAME>
         <ORGUNIT/>
       </ORG>
       <TITLE>Executive Director</TITLE>
       <ROLE>Patron Saint</ROLE>
       <TEL><VOICE/><WORK/><NUMBER>303-308-3282</NUMBER></TEL>
       <TEL><FAX/><WORK/><NUMBER/></TEL>
       <TEL><MSG/><WORK/><NUMBER/></TEL>
       <ADR>
         <WORK/>
         <EXTADD>Suite 600</EXTADD>
         <STREET>1899 Wynkoop Street</STREET>
         <LOCALITY>Denver</LOCALITY>
         <REGION>CO</REGION>
         <PCODE>80202</PCODE>
         <CTRY>USA</CTRY>
       </ADR>
       <TEL><VOICE/><HOME/><NUMBER>303-555-1212</NUMBER></TEL>
       <TEL><FAX/><HOME/><NUMBER/></TEL>
       <TEL><MSG/><HOME/><NUMBER/></TEL>
       <ADR>
         <HOME/>
         <EXTADD/>
         <STREET/>
         <LOCALITY>Denver</LOCALITY>
         <REGION>CO</REGION>
         <PCODE>80209</PCODE>
         <CTRY>USA</CTRY>
       </ADR>
       <EMAIL><INTERNET/><PREF/><USERID>stpeter@jabber.org</USERID></EMAIL>
       <JABBERID>stpeter@jabber.org</JABBERID>
       <DESC>
         More information about me is located on my
         personal website: http://www.saint-andre.com/
       </DESC>
     </vCard>
   </iq>


A.2 Updating One's vCard

   A user may update his or her vCard by sending an IQ of type "set" to
   the server, following the format in the previous use case.

   If a user attempts to perform an IQ set on another user's vCard, the
   server must return a 403 "Forbidden" error.



Saint-Andre & Miller    Expires August 24, 2003                [Page 51]


Internet-Draft           XMPP Instant Messaging            February 2003


A.3 Viewing Another User's vCard

   A user may view another user's vCard by sending an IQ of type "get"
   to the other user's bare JID. A compliant server must return the
   vCard to the requestor and not forward the IQ to the requestee's
   connected resource.

   <iq
       to='jer@jabber.org'
       type='get'
       id='v3'>
     <vCard xmlns='vcard-temp'/>
   </iq>

   The server should then return the other user's vCard to the
   requestor:

   <iq
       from='jer@jabber.org'
       to='stpeter@jabber.org/home'
       type='result'
       id='v3'>
     <vCard xmlns='vcard-temp'>
       <FN>JeremieMiller</FN>
       <N>
         <GIVEN>Jeremie</GIVEN>
         <FAMILY>Miller</FAMILY>
         <MIDDLE/>
       </N>
       <NICKNAME>jer</NICKNAME>
       <EMAIL><INTERNET/><PREF/><USERID>jeremie@jabber.org</USERID></EMAIL>
       <JABBERID>jer@jabber.org</JABBERID>
     </vCard>
   </iq>

















Saint-Andre & Miller    Expires August 24, 2003                [Page 52]


Internet-Draft           XMPP Instant Messaging            February 2003


Appendix B. Formal Definitions

B.1 Schema for jabber:iq:last

   <?xml version='1.0' encoding='UTF-8'?>
   <xsd:schema
       xmlns:xsd='http://www.w3.org/2001/XMLSchema'
       targetNamespace='http://www.jabber.org/protocol'
       xmlns='http://www.jabber.org/protocol'
       elementFormDefault='qualified'>

     <xsd:element name='query'>
       <xsd:complexType>
         <xsd:attribute name='seconds' type='xsd:unsignedLong' use='optional'/>
       </xsd:complexType>
     </xsd:element>

   </xsd:schema>


B.2 Schema for jabber:iq:privacy

   <?xml version='1.0' encoding='UTF-8'?>
   <xsd:schema
       xmlns:xsd='http://www.w3.org/2001/XMLSchema'
       targetNamespace='http://www.jabber.org/protocol'
       xmlns='http://www.jabber.org/protocol'
       elementFormDefault='qualified'>

     <xsd:element name='query'>
       <xsd:complexType>
         <xsd:choice minOccurs='0' maxOccurs='unbounded'>
           <xsd:element ref='active' minOccurs='0' maxOccurs='1'/>
           <xsd:element ref='list' minOccurs='0' maxOccurs='unbounded'/>
         </xsd:choice>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='active'>
       <xsd:complexType>
         <xsd:attribute name='name' type='xsd:string' use='required'/>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='list'>
       <xsd:complexType>
         <xsd:choice minOccurs='0' maxOccurs='unbounded'>
           <xsd:element ref='item' minOccurs='0' maxOccurs='unbounded'/>



Saint-Andre & Miller    Expires August 24, 2003                [Page 53]


Internet-Draft           XMPP Instant Messaging            February 2003


         </xsd:choice>
         <xsd:attribute name='name' type='xsd:string' use='required'/>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='item'>
       <xsd:complexType>
         <xsd:choice>
           <xsd:element ref='iq' minOccurs='0' maxOccurs='1'/>
           <xsd:element ref='message' minOccurs='0' maxOccurs='1'/>
           <xsd:element ref='presence' minOccurs='0' maxOccurs='1'/>
         </xsd:choice>
         <xsd:attribute name='jid' type='xsd:string' use='required'/>
         <xsd:attribute name='type' use='required'>
           <xsd:simpleType>
             <xsd:restriction base='xsd:NCName'>
               <xsd:enumeration value='allow'/>
               <xsd:enumeration value='deny'/>
             </xsd:restriction>
           </xsd:simpleType>
         </xsd:attribute>
         <xsd:attribute name='subscription' use='optional'>
           <xsd:simpleType>
             <xsd:restriction base='xsd:NCName'>
               <xsd:enumeration value='to'/>
               <xsd:enumeration value='from'/>
               <xsd:enumeration value='both'/>
             </xsd:restriction>
           </xsd:simpleType>
         </xsd:attribute>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='iq'/>
     <xsd:element name='message'/>
     <xsd:element name='presence'/>

   </xsd:schema>


B.3 Schema for jabber:iq:roster

   <?xml version='1.0' encoding='UTF-8'?>
   <xsd:schema
       xmlns:xsd='http://www.w3.org/2001/XMLSchema'
       targetNamespace='http://www.jabber.org/protocol'
       xmlns='http://www.jabber.org/protocol'
       elementFormDefault='qualified'>



Saint-Andre & Miller    Expires August 24, 2003                [Page 54]


Internet-Draft           XMPP Instant Messaging            February 2003


     <xsd:element name='query'>
       <xsd:complexType>
         <xsd:sequence minOccurs='0' maxOccurs='unbounded'>
           <xsd:element ref='item'/>
         </xsd:sequence>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='item'>
       <xsd:complexType>
         <xsd:sequence minOccurs='0' maxOccurs='unbounded'>
           <xsd:element ref='group'/>
         </xsd:sequence>
         <xsd:attribute name='jid' type='xsd:string' use='required'/>
         <xsd:attribute name='name' type='xsd:string' use='optional'/>
         <xsd:attribute name='subscription' use='optional'>
           <xsd:simpleType>
             <xsd:restriction base='xsd:string'>
               <xsd:enumeration value='to'/>
               <xsd:enumeration value='from'/>
               <xsd:enumeration value='both'/>
               <xsd:enumeration value='none'/>
               <xsd:enumeration value='remove'/>
             </xsd:restriction>
           </xsd:simpleType>
         </xsd:attribute>
         <xsd:attribute name='ask' use='optional'>
           <xsd:simpleType>
             <xsd:restriction base='xsd:string'>
               <xsd:enumeration value='subscribe'/>
               <xsd:enumeration value='unsubscribe'/>
             </xsd:restriction>
           </xsd:simpleType>
         </xsd:attribute>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='group' type='xsd:string'/>

   </xsd:schema>


B.4 DTD for vcard-temp

   The following DTD is a slightly modified version of that contained in
   the second vCard-XML Internet-Draft authored by Frank Dawson. The
   only modifications were to add the JABBERID and DESC elements.




Saint-Andre & Miller    Expires August 24, 2003                [Page 55]


Internet-Draft           XMPP Instant Messaging            February 2003


   <?xml version="1.0" encoding="UTF-8"?>

   <!--
   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and
   furnished to others, and derivative works that comment
   on or otherwise explain it or assist in its implmentation
   may be prepared, copied, published and distributed, in whole
   or in part, without restriction of any kind, provided that
   the above copyright notice and this paragraph are included
   on all such copies and derivative works.

   However, this document itself may not be modified in any
   way, such as by removing the copyright notice or references
   to the Internet Society or other Internet organizations,
   except as needed for the purpose of developing Internet
   standards in which case the procedures for copyrights
   defined in the Internet Standards process MUST be followed,
   or as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or
   assigns.

   This document and the information contained herein is provided
   on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
   USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.
   -->

   <!-- ==== -->

   <!-- Root element and container for one
     or more vCard objects -->
   <!ELEMENT xCard (vCard)+>

   <!-- Individual vCard container -->
   <!ELEMENT vCard (
     (VERSION, FN, N),
     (NICKNAME?,
     PHOTO?,
     BDAY?,
     ADR?,
     LABEL?,



Saint-Andre & Miller    Expires August 24, 2003                [Page 56]


Internet-Draft           XMPP Instant Messaging            February 2003


     TEL?,
     EMAIL?,
     JABBERID?,
     MAILER?,
     TZ?,
     GEO?,
     TITLE?,
     ROLE?,
     LOGO?,
     AGENT?,
     ORG?,
     CATEGORIES?,
     NOTE?,
     PRODID?,
     REV?,
     SORT-STRING?,
     SOUND?,
     UID?,
     URL?,
     CLASS?,
     KEY?,
     DESC?
   )*)>

     <!-- vCard specification version property.
       This MUST be 2.0, if the document conforms to RFC 2426. -->
     <!ELEMENT VERSION (#PCDATA)>

     <!-- Formatted or display name property. -->
     <!ELEMENT FN (#PCDATA)>

     <!-- Structured name property. Name components with multiple
       values must be specified as a comma separated
        list of values. -->
     <!ELEMENT N ( FAMILY?, GIVEN?, MIDDLE?, PREFIX?, SUFFIX?)>

       <!ELEMENT FAMILY (#PCDATA)>
       <!ELEMENT GIVEN (#PCDATA)>
       <!ELEMENT MIDDLE (#PCDATA)>
       <!ELEMENT PREFIX (#PCDATA)>
       <!ELEMENT SUFFIX (#PCDATA)>

     <!-- Nickname property. Multiple nicknames must be
       specified as a comma separated list value. -->
     <!ELEMENT NICKNAME (#PCDATA)>

     <!-- Photograph property. Value is either a BASE64 encoded
       binary value or a URI to the external content. -->



Saint-Andre & Miller    Expires August 24, 2003                [Page 57]


Internet-Draft           XMPP Instant Messaging            February 2003


     <!ELEMENT PHOTO ((TYPE, BINVAL) | EXTVAL)>

     <!-- Birthday property. Value must be an ISO 8601 formatted
       date or date/time value. -->
     <!ELEMENT BDAY (#PCDATA)>

     <!-- Structured address property. Address components with
       multiple values must be specified as a comma separated list
       of values. -->
     <!ELEMENT ADR (
       HOME?,
       WORK?,
       POSTAL?,
       PARCEL?,
       (DOM | INTL)?,
       PREF?,
       POBOX?,
       EXTADR?,
       STREET?,
       LOCALITY?,
       REGION?,
       PCODE?,
       CTRY?
     )>

       <!ELEMENT POBOX (#PCDATA)>
       <!ELEMENT EXTADR (#PCDATA)>
       <!ELEMENT STREET (#PCDATA)>
       <!ELEMENT LOCALITY (#PCDATA)>
       <!ELEMENT REGION (#PCDATA)>
       <!ELEMENT PCODE (#PCDATA)>
       <!ELEMENT CTRY (#PCDATA)>

     <!-- Address label property. -->
     <!ELEMENT LABEL (
       HOME?,
       WORK?,
       POSTAL?,
       PARCEL?,
       (DOM | INTL)?,
       PREF?,
       LINE+
     )>

       <!-- Individual label lines. -->
       <!ELEMENT LINE (#PCDATA)>

     <!-- Telephone number property. -->



Saint-Andre & Miller    Expires August 24, 2003                [Page 58]


Internet-Draft           XMPP Instant Messaging            February 2003


     <!ELEMENT TEL (
       HOME?,
       WORK?,
       VOICE?,
       FAX?,
       PAGER?,
       MSG?,
       CELL?,
       VIDEO?,
       BBS?,
       MODEM?,
       ISDN?,
       PCS?,
       PREF?,
       NUMBER
     )>

       <!-- Phone number value. -->
       <!ELEMENT NUMBER (#PCDATA)>

     <!-- Email address property. Default type is INTERNET. -->
     <!ELEMENT EMAIL (
       HOME?,
       WORK?,
       INTERNET?,
       X400?,
       USERID
     )>

       <!ELEMENT USERID (#PCDATA)>

     <!-- Jabber ID. Value must be in the form of user@domain. -->
     <!ELEMENT JABBERID (#PCDATA)>

     <!-- Mailer (e.g., Mail User Agent Type) property. -->
     <!ELEMENT MAILER (#PCDATA)>

     <!-- Time zone's Standard Time UTC offset. Value must be an
       ISO 8601 formatted UTC offset. -->
     <!ELEMENT TZ (#PCDATA)>

     <!-- Geographical position. Values are the decimal degress of
       LATitude and LONgitude. The value should be specified to
       six decimal places.-->
     <!ELEMENT GEO (LAT, LON)>

       <!-- Latitude value. -->
       <!ELEMENT LAT (#PCDATA)>



Saint-Andre & Miller    Expires August 24, 2003                [Page 59]


Internet-Draft           XMPP Instant Messaging            February 2003


       <!-- Longitude value. -->
       <!ELEMENT LON (#PCDATA)>

     <!-- Title property. -->
     <!ELEMENT TITLE (#PCDATA)>

     <!-- Role property. -->
     <!ELEMENT ROLE (#PCDATA)>

     <!-- Organization logo property. -->
     <!ELEMENT LOGO ((TYPE, BINVAL) | EXTVAL)>

     <!-- Administrative agent property. -->
     <!ELEMENT AGENT (vCard | EXTVAL)>

     <!-- Organizational name and units property. -->
     <!ELEMENT ORG (ORGNAME, ORGUNIT*)>

       <!ELEMENT ORGNAME (#PCDATA)>

       <!ELEMENT ORGUNIT (#PCDATA)>

     <!-- Application specific categories property. -->
     <!ELEMENT CATEGORIES (KEYWORD+)>

       <!ELEMENT KEYWORD (#PCDATA)>

     <!-- Commentary note property. -->
     <!ELEMENT NOTE (#PCDATA)>

     <!-- Identifier of product that generated the vCard property. -->
     <!ELEMENT PRODID (#PCDATA)>

     <!-- Last revised property. The value must be an
          ISO 8601 formatted UTC date/time. -->
     <!ELEMENT REV (#PCDATA)>

     <!-- Sort string property. -->
     <!ELEMENT SORT-STRING (#PCDATA)>

     <!-- Formatted name pronunciation property. The value is
          either a textual phonetic pronunciation, a BASE64
          encoded binary digital audio pronunciation or a URI to
          an external binary digital audio pronunciation.-->
     <!ELEMENT SOUND (PHONETIC | BINVAL | EXTVAL)>

       <!-- Textual phonetic pronunciation. -->
       <!ELEMENT PHONETIC (#PCDATA)>



Saint-Andre & Miller    Expires August 24, 2003                [Page 60]


Internet-Draft           XMPP Instant Messaging            February 2003


     <!-- Unique identifier property. -->
     <!ELEMENT UID (#PCDATA)>

     <!-- Directory URL property. -->
     <!ELEMENT URL (#PCDATA)>

     <!-- Description. -->
     <!ELEMENT DESC (#PCDATA)>

     <!-- Privacy classification property. -->
     <!ELEMENT CLASS (PUBLIC | PRIVATE | CONFIDENTIAL)>

       <!ELEMENT PUBLIC EMPTY>

       <!ELEMENT PRIVATE EMPTY>

       <!ELEMENT CONFIDENTIAL EMPTY>

     <!-- Authentication credential or encryption  key property. -->
     <!ELEMENT KEY (TYPE?, CRED)>

       <!ELEMENT CRED (#PCDATA)>

   <!-- ==== -->

   <!-- Common elements. -->

   <!-- Addressing type indicators. -->
   <!ELEMENT HOME EMPTY>
   <!ELEMENT WORK EMPTY>
   <!ELEMENT POSTAL EMPTY>
   <!ELEMENT PARCEL EMPTY>
   <!ELEMENT DOM EMPTY>
   <!ELEMENT INTL EMPTY>
   <!ELEMENT PREF EMPTY>
   <!ELEMENT VOICE EMPTY>
   <!ELEMENT FAX EMPTY>
   <!ELEMENT PAGER EMPTY>
   <!ELEMENT MSG EMPTY>
   <!ELEMENT CELL EMPTY>
   <!ELEMENT VIDEO EMPTY>
   <!ELEMENT BBS EMPTY>
   <!ELEMENT MODEM EMPTY>
   <!ELEMENT ISDN EMPTY>
   <!ELEMENT PCS EMPTY>
   <!ELEMENT INTERNET EMPTY>
   <!ELEMENT X400 EMPTY>




Saint-Andre & Miller    Expires August 24, 2003                [Page 61]


Internet-Draft           XMPP Instant Messaging            February 2003


   <!-- Format type parameter. -->
   <!ELEMENT TYPE (#PCDATA)>

   <!-- Base64 encoded binary value. -->
   <!ELEMENT BINVAL (#PCDATA)>

   <!-- URI to external binary value -->
   <!ELEMENT EXTVAL (#PCDATA)>

   <!-- ==== -->









































Saint-Andre & Miller    Expires August 24, 2003                [Page 62]


Internet-Draft           XMPP Instant Messaging            February 2003


Appendix C. Revision History

   Note to RFC editor: please remove this entire appendix, and the
   corresponding entries in the table of contents, prior to publication.

C.1 Changes from draft-ietf-xmpp-im-02

   o  Added a great deal more detail to the narrative regarding
      server-side privacy rules as well as the interaction between
      rosters and subscriptions.

   o  Removed DTDs in favor of schemas (with the exception of vCard
      XML).

   o  Removed non-normative documentation of authentication using
      jabber:iq:auth and of in-band registration using
      jabber:iq:register, since these are maintained by the Jabber
      Software Foundation and are not part of the XMPP specification.


C.2 Changes from draft-ietf-xmpp-im-01

   o  Made numerous small editorial changes.


C.3 Changes from draft-ietf-xmpp-im-00

   o  Moved registration and authentication via jabber:iq:auth to
      non-normative appendices.

   o  Changed initial presence stanza from MUST be empty to SHOULD be
      empty.

   o  Specified that user or clients should not send presence stanzas of
      type 'probe'.

   o  Specified the algorithm for digest passwords.


C.4 Changes from draft-miller-xmpp-im-02

   o  Added information about the 'jabber:iq:last' protocol to meet the
      requirement defined in section 3.2.4 of RFC 2779.

   o  Added information about the 'jabber:iq:privacy' protocol to meet
      the requirement defined in section 2.3.5 of RFC 2779.

   o  Added information about the vCard XML protocol to meet the



Saint-Andre & Miller    Expires August 24, 2003                [Page 63]


Internet-Draft           XMPP Instant Messaging            February 2003


      requirement defined in sections 3.1.3 and 4.1.4 of RFC 2779.

   o  Changed the material describing authentication (but not resource
      authorization) with 'jabber:iq:auth' to non-normative.

   o  Noted that the only watchers are subscribers.

   o  Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from
      "host" to "server"; (3) from "node" to "client" or "user" (as
      appropriate).









































Saint-Andre & Miller    Expires August 24, 2003                [Page 64]


Internet-Draft           XMPP Instant Messaging            February 2003


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Saint-Andre & Miller    Expires August 24, 2003                [Page 65]


Internet-Draft           XMPP Instant Messaging            February 2003


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Saint-Andre & Miller    Expires August 24, 2003                [Page 66]