view Side-By-Side changes

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


                         XMPP Instant Messaging
                         draft-ietf-xmpp-im-02
                         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.

   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 4, 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 Extensible Messaging and Presence Protocol (XMPP) that are
   necessary to create a basic instant messaging and presence
   application.











Saint-Andre & Miller    Expires August 4, 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  . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   1.4   Discussion Venue . . . . . . . . . . . . . . . . . . . . . .  5
   1.5   Intellectual Property Notice . . . . . . . . . . . . . . . .  5
   2.    Authentication . . . . . . . . . and Authorization . . . . . . . . . . . . . .  6
   3.    Authorizing a Resource . . . . . . . . . . . . . . . . . . .  7
   4.    Exchanging Messages  . . . . . . . . . . . . . . . . . . . .  9
   4.1  7
   3.1   Specifying an Intended Recipient . . . . . . . . . . . . . .  9
   4.2  7
   3.2   Specifying a Message Type  . . . . . . . . . . . . . . . . .  9
   4.3  7
   3.3   Specifying a Message Subject . . . . . . . . . . . . . . . . 10
   4.4  8
   3.4   Specifying a Conversation Thread . . . . . . . . . . . . . . 10
   4.5  8
   3.5   Specifying a Message Body  . . . . . . . . . . . . . . . . . 11
   4.6  9
   3.6   Specifying Additional Information  . . . . . . . . . . . . . 11
   4.7  9
   3.7   Message-Related Errors . . . . . . . . . . . . . . . . . . . 12
   5. 10
   4.    Exchanging Presence Information  . . . . . . . . . . . . . . 13
   5.1 11
   4.1   Client and Server Responsibilities . . . . . . . . . . . . . 13
   5.2 11
   4.2   Sending Initial Presence . . . . . . . . . . . . . . . . . . 13
   5.3 11
   4.3   Specifying Availability Status . . . . . . . . . . . . . . . 14
   5.4 12
   4.4   Specifying Detailed Status Information . . . . . . . . . . . 14
   5.5 12
   4.5   Probing for Presence . . . . . . . . . . . . . . . . . . . . 14
   5.6 12
   4.6   Sending Final Presence . . . . . . . . . . . . . . . . . . . 14
   5.7 12
   4.7   Determining When a Contact Went Offline  . . . . . . . . . . 15
   6. 13
   5.    Managing Subscriptions . . . . . . . . . . . . . . . . . . . 16
   6.1 14
   5.1   Requesting a Subscription  . . . . . . . . . . . . . . . . . 16
   6.2 14
   5.2   Handling a Subscription Request  . . . . . . . . . . . . . . 16
   6.3 14
   5.3   Cancelling a Subscription from Another Entity  . . . . . . . 17
   6.4 14
   5.4   Unsubscribing from Another Entity's Presence . . . . . . . . 17
   7.    Blocking Communication 15
   6.    Managing One's Roster  . . . . . . . . . . . . . . . . . . . 18
   7.1 16
   6.1   Retrieving One's Privacy Lists . . . Roster on Login . . . . . . . . . . . . 18
   7.2   Changing the Active List . . 16
   6.2   Adding a Roster Item . . . . . . . . . . . . . . . . 19
   7.3   Editing a Privacy List . . . . 17
   6.3   Deleting a Roster Item . . . . . . . . . . . . . . . 19
   7.4   Removing a Privacy List . . . . 18
   7.    Integration of Roster Items and Presence Subscriptions . . . 20
   7.1   Overview . . . . . . . . . . . 20
   7.5   Blacklisted Entity Attempts to Communicate with User . . . . 20
   8.    Managing One's Roster . . . . . . . . . . . 20
   7.2   User Subscribes to Contact . . . . . . . . 22
   8.1   Retrieving One's Roster on Login . . . . . . . . . 20
   7.3   Creating a Mutual Subscription . . . . . 22
   8.2   Adding a Roster Item . . . . . . . . . . 24
   7.4   Unsubscribing  . . . . . . . . . . 23
   8.3   Deleting a Roster Item . . . . . . . . . . . . . 26
   7.4.1 Case #1: Subscription Type 'to'  . . . . . . 24
   9.    Routing and Delivery Guidelines . . . . . . . . 26
   7.4.2 Case #2: Subscription Type 'both'  . . . . . . 26
   10.   Security Considerations . . . . . . . 28
   7.5   Cancelling a Subscription  . . . . . . . . . . . 27
         References . . . . . . 29
   7.5.1 Case #1: Subscription Type 'from'  . . . . . . . . . . . . . 29
   7.5.2 Case #2: Subscription Type 'both'  . . . . . . 28
         Authors' Addresses . . . . . . . 30
   7.6   Removing a Roster Item and Cancelling All Subscriptions  . . 31
   8.    Blocking Communication . . . . . . . . . . . . 28
   A.    In-Band Registration . . . . . . . 33
   8.1   Retrieving One's Privacy Lists . . . . . . . . . . . . . 29
   A.1   Registration Data Flow . . 33
   8.2   Managing Active Lists  . . . . . . . . . . . . . . . . . 29
   A.2   Cancellation Data Flow . . . . . . . . . . . . . . . . . . . 31 35



Saint-Andre & Miller    Expires August 4, 24, 2003                 [Page 2]

Internet-Draft           XMPP Instant Messaging            February 2003


   B.    Authentication Using jabber:iq:auth  . . . . . . . . . . . . 32
   C.    vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
   C.1   Retrieving One's vCard . . . . . . . . . . . . . . . . . . . 34
   C.2   Updating One's vCard . . .


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






















Saint-Andre & Miller    Expires August 4, 24, 2003                 [Page 3]

Internet-Draft           XMPP Instant Messaging            February 2003


1. Introduction

1.1 Overview

   The core features of the XMPP protocol Extensible Messaging and Presence Protocol
   are defined in XMPP Core [1]. These features, features -- specifically XML streams
   streams, stream authentication and encryption, and the 'jabber:client' <message/>,
   <presence/>, and
   'jabber:server' namespaces, <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 XML stanzas that are application-specific
   data scoped by specific particular XML namespaces. This document describes the specific
   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, search, remote procedure calls, data gathering and forms submission,
   feature negotiation, message composing events, message expiration,
   delayed delivery, and file
   transfer; 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].




Saint-Andre & Miller     Expires August 4, 2003                 [Page 4]

Internet-Draft           XMPP Instant Messaging            February 2003

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 4, 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 client user must first register acquire an account with on a
   server (or
   server. Although account provisioning is outside the scope of XMPP,
   methods for doing so include account creation by a server
   administrator must create such an account); for
   the sake of completeness, an as well as in-band mechanism for account registration using the
   'jabber:iq:register' namespace; the latter method is
   described non-normatively in In-Band Registration (Appendix A).

   Once a user has an account, defined by the user must subsequently authenticate
   with
   Jabber Software Foundation [3] and appropriate documentation is
   available at the server in JSF's website.

   In order to gain access to the network. 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].

   Earlier iterations of the Jabber protocol contained

   After authenticating, a client-server
   authentication protocol that was enforced after the stream was
   negotiated; for the sake of completeness, this protocol, which uses
   the 'jabber:iq:auth' namespace, is described non-normatively in
   Authentication Using jabber:iq:auth (Appendix B).





























Saint-Andre & Miller     Expires August 4, 2003                 [Page 6]

Internet-Draft           XMPP Instant Messaging            February 2003


3. Authorizing a Resource

   Once a client has authenticated with a server using SASL, it user MUST
   define also provide a resource that the server can associate with the connection name for purposes of authorization and addressing.  This is necessary
   because stanzas sent to or received from
   the server within current session, for the
   context purpose of an active session use a "full JID" (user@host/resource) addressing; the protocol for addressing.  Authorizing
   providing a resource is accomplished by means also defined in XMPP Core [1].

   NOTE: Earlier iterations of the 'jabber:iq:auth' namespace as described below.

   Step 1: Client queries server regarding information that is still
   required to begin Jabber protocol contained a session:

   <iq type="get" id="res_1">
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
     </query>
   </iq>

   Step 2: Server responds with
   client-server authentication protocol that was enforced after the required fields (in
   stream was negotiated; this case, only
   the username and authorized resource):

   <iq type="result" id="res_1">
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
       <resource/>
     </query>
   </iq>

   Step 3: Client sends name of authorized resource:

   <iq type="set" id="res_2">
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
       <resource>balcony</resource>
     </query>
   </iq>

   Step 4: Server informs client of successful session initiation:

   <iq type="result" id="res_2"/>










Saint-Andre & Miller     Expires August 4, 2003                 [Page 7]

Internet-Draft protocol is not suppoted in XMPP Instant Messaging            February 2003


   Step 4 (alt): Server informs client of error encountered during
   session initiation:

   <iq type="result" id="res_2">
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
       <resource></resource>
     </query>
     <error code='406'>Not Acceptable (empty resource)</error>
   </iq> but is
   documented by the Jabber Software Foundation [3] for historical
   purposes.






















Saint-Andre & Miller    Expires August 4, 24, 2003                 [Page 8] 6]

Internet-Draft           XMPP Instant Messaging            February 2003


4.


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).

4.1 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 (for exceptions, see the next
   paragraph). 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 no 'to' address is specified, it is implied that the message JID
   is
   addressed to the sending user itself (i.e., the user@host sending the
   stanza); furthermore, a message explicitly invalid or implicitly addressed to
   the sending user itself is processed by cannot be contacted, the server on behalf of entity discovering that
   user.  A message addressed to a specific connected resource
   associated with fact
   (usually the sending user is delivered sender's or recipient's server) SHOULD return an error
   to that user@host/
   resource (which MAY be different from the connected resource that
   generated the message).

4.2 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 4, 24, 2003                 [Page 9] 7]

Internet-Draft           XMPP Instant Messaging            February 2003


4.3


   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 distince distinct value.

4.4

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 4, 24, 2003                 [Page 10] 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>


4.5


3.5 Specifying a Message Body

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

   Multiple <body/> element.

4.6 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
   within the child element.



Saint-Andre & Miller    Expires August 4, 24, 2003                 [Page 11] 9]

Internet-Draft           XMPP Instant Messaging            February 2003


4.7


   within the child element.

3.7 Message-Related Errors

   If a message sent by a sender cannot be delivered, a server 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> eyes.</body>
   </message>

   <message
       to="romeo@montague.net"
       from="juliet@capulet.com"
       type="error">
     <body>Sleep dwell upon thine eyes</body> eyes.</body>
     <error code="404">No Such JID</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 4, 24, 2003                [Page 12] 10]

Internet-Draft           XMPP Instant Messaging            February 2003


5.


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.)

5.1

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@host/resource) (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 associated with
   the client, 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.

5.2

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.

   Initial presence sent from client to server:

   <presence/>




Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 13] 11]

Internet-Draft           XMPP Instant Messaging            February 2003


5.3


   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>


5.4


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>


5.5


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'.

5.6

4.6 Sending Final Presence

   Upon ending its session with a server, a client SHOULD send 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.






Saint-Andre & Miller     Expires August 4, 2003                [Page 14]

Internet-Draft           XMPP Instant Messaging            February 2003


5.7 Determining When a

   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 SHOULD MUST maintain a record of the time at which a user sent
   final presence. 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 user@host address 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@host'> to='user@domain'>
     <query xmlns='jabber:iq:last'/>
   </iq>

   The

   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@host' 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@host' 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 4, 24, 2003                [Page 15] 13]

Internet-Draft           XMPP Instant Messaging            February 2003


6.


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.

6.1

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"
       from="romeo@montague.net" type="subscribe"/>


6.2


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"
       from="juliet@capulet.com" type="subscribed"/>












Saint-Andre & Miller     Expires August 4, 2003                [Page 16]

Internet-Draft           XMPP Instant Messaging            February 2003

   Denying a presence subscription request:

   <presence to="romeo@montague.net"
       from="juliet@capulet.com" type="unsubscribed"/>


6.3

   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"
       from="juliet@capulet.com" type="unsubscribed"/>


6.4


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"
       from="romeo@montague.net" type="unsubscribe"/>




































Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 17] 15]

Internet-Draft           XMPP Instant Messaging            February 2003


7. Blocking Communication

   Most instant messaging systems have found it necessary to implement
   some method for users to block communications from specific other
   users (this is also required by section 2.3.5 of RFC 2779 [2]).


6. Managing One's Roster

   In
   XMPP this is done using the 'jabber:iq:privacy' namespace by managing XMPP, one's privacy lists (also contact list is called "zebra lists" since they are
   flexible combinations of blacklists and whitelists).

7.1 Retrieving One's Privacy Lists

   Client requests privacy lists from server:

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

   Server sends privacy lists to client:

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

   In this example, a roster. A roster is stored by
   the server on the user's behalf so that a user has three lists: (1) 'public', which allows
   communications from everyone except one specific entity; (2)
   'private', which allows communications only may access roster
   information from contacts who have any connected resource.

6.1 Retrieving One's Roster on Login

   Upon connecting to the server, a
   bi-directional subscription 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 user; and (3) 'special', which
   allows communications only from three specific entities.  The active
   list currently being applied by client's
   request for the server 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 'private' list. 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 4, 24, 2003                [Page 18] 16]

Internet-Draft           XMPP Instant Messaging            February 2003


7.2 Changing the Active List

   In order to change the active list currently being applied by the
   server, the user MUST send an IQ stanza of type 'set' with


6.2 Adding a <query/>
   element scoped by the 'jabber:iq:privacy' namespace that contains an
   empty <active/> child element possessing Roster Item

   At any time, a 'name' attribute whose
   value is set user MAY add an item to the desired list name.

   Client requests change of active list: his or her roster.

   Client adds a new item:

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

   Server acknowledges success of active list change:

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


7.3 Editing a Privacy List

   In order

   The server is responsible for updating the roster information in
   persistent storage, and also for pushing that change out to edit a privacy list, all
   connected resources associated with the user MUST send using 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 "set" (this 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 referred to the list by
   including as a "roster push"). This "roster
   push" enables all elements connected resources to remain in sync with the list (not the "delta"); the same
   protocol is used to create a new list.

   Client edits a privacy list:

   <iq type='set' id='zebra3'>
     <query xmlns='jabber:iq:privacy'>
       <list name='public'>
         <item jid='tybalt@capulet.com' type='deny'/>
         <item jid='paris@shakespeare.lit' type='deny'/>
         <item type='allow'/>
       </list>
     </query>
   </iq>
   server-based roster information.





























Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 19] 17]

Internet-Draft           XMPP Instant Messaging            February 2003


   Server acknowledges success of list edit:

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

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

7.4 Removing a Privacy List

   In order to remove a privacy list, the user MUST send replies with 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 result to the list name sending resource and pushes
   the
   user would like updated roster information to remove.

   Client removes a privacy list: all connected resources:

   <iq type='set' id='zebra3'>
       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:privacy'>
       <list name='private'/> xmlns="jabber:iq:roster">
       <item
           name="Nurse"
           jid="nurse@capulet.com"
           subscription="none">
         <group>Servants</group>
       </item>
     </query>
   </iq>

   Server acknowledges success of list removal:
   <iq type='result' id='zebra3' to='juliet@capulet.com/balcony'/>


7.5 Blacklisted Entity Attempts to Communicate with User

   If
       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 blacklisted entity attempts new roster item, i.e., by sending the
   roster item in an IQ set to communicate with the user, 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
   user's value of the 'subscription' attribute is
   "remove" (a compliant server MUST return an error SHOULD ignore any other values of type 405 (Not Allowed) to the
   sending entity.

   Blacklisted entity attempts communication:

   <message to='romeo@montague.net' from='tybalt@capulet.com/pda'>
     <body>Have at thee, coward!</body>
   </message>
   'subscription' attribute when received from a client).




Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 20] 18]

Internet-Draft           XMPP Instant Messaging            February 2003


   Server returns error


   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 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> 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 4, 24, 2003                [Page 21] 19]

Internet-Draft           XMPP Instant Messaging            February 2003


8. Managing One's


7. Integration of Roster

   One's list Items and Presence Subscriptions

7.1 Overview

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

   There are four primary subscription states:

   o  None -- Neither the user may access roster information 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 any
   connected resource.

8.1 Retrieving One's Roster on Login

   Upon connecting the contact to the server, user

   o  From -- There is a client MAY request subscription from the roster
   (however, because receiving contact to the roster may user, but
      the user has not be desirable for all
   resources, e.g., a connection with limited bandwidth, subscribed to the client's
   request for contact's presence

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

   Each of these states is OPTIONAL).

   Client requests current reflected in the roster from server:

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

   Client receives of both the user and
   the contact, thus resulting in durable subscription states. The
   details regarding how these subscription states interact with roster from
   items is explained in 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 4, 2003                [Page 22]

Internet-Draft           XMPP Instant Messaging            February 2003


8.2 Adding a Roster Item

   At any time, following sub-sections.

7.2 User Subscribes to Contact

   The process by which a user MAY add an item subscribes 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 contact, including the
   interaction between roster information in
   persistent storage, items and also subscription states, is defined
   below.

   1.  In preparation for pushing that change out being able to all
   connected resources render the contact in the user's
       client interface and for the user using server to keep track of the
       subscription, the user's client MUST send an IQ stanza of type "set".
   This enables all connected resources to remain
       type='set' in sync with the
   server-based roster information. 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 4, 24, 2003                [Page 23] 20]

Internet-Draft           XMPP Instant Messaging            February 2003


   Server replies


   </iq>

   2.  The server then MUST (1) reply with an IQ result to the sending resource stanza of type='result'
       and pushes (2) initiate a "roster push" for the updated new roster information item to all
       connected resources:

   <iq
       from="capulet.com"
       to="juliet@capulet.com/balcony"
       type="result"
       id="roster_2"/> resources associated with this user, setting the
       subscription state set to 'none':

   <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>
       type='result'
       to='user@domain/resource'
       id='int1'/>

   <iq
       from="capulet.com"
       to="juliet@capulet.com/chamber"
       type="set"
       id="roster_3"/> type='set' to='user@domain/resource'>
     <query xmlns="jabber:iq:roster"> xmlns='jabber:iq:roster'>
       <item
           name="Nurse"
           jid="nurse@capulet.com"
           subscription="none">
         <group>Servants</group>
       </item>
           jid='contact@domain'
           name='MyContact'
           subscription='none'/>
     </query>
   </iq>

   Updating an existing roster item (e.g., changing

   3.  In order to initiate the Group) is done
   in subscription, the same way as adding user's client MUST
       then send a new roster item, i.e., by sending the
   roster item in an IQ set presence stanza of type='subscribe' to the server.

8.3 Deleting a Roster Item

   At any time, contact:

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

   4.  The server MUST then initiate a user MAY delete an item from its roster by doing an IQ
   set and making sure that second "roster push" to all
       connected resources associated with the value user, setting the contact
       to the pending sub-state of the 'subscription' attribute 'none' subscription state; this
       pending sub-state is
   "remove" (a compliant server SHOULD ignore any other values denoted by the inclusion of the
   'subscription'
       ask='subscribe' attribute when received from a client).




Saint-Andre & 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 4, 24, 2003                [Page 24] 21]

Internet-Draft           XMPP Instant Messaging            February 2003


   Client removes


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

   6.  If the contact is online (i.e., there is a 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 connected resource
       associated with adding a roster item, 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 deleting 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 item set to the server
   is responsible for updating specifying the roster information in persistent
   storage, desired
       nickname and also group for pushing that change out 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 using an IQ stanza 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 type "set".

   A the fact that the contact has accepted the
       subscription request, the user's server implementation SHOULD cancel any existing MUST (1) deliver the
       presence
   subscriptions when 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 is removed. for
       the contact with the subscription type set to a value of "to":





Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 25] 22]

Internet-Draft           XMPP Instant Messaging            February 2003


9. Routing and Delivery Guidelines

   XML stanzas that are not handled directly by a server (e.g., for


   <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
   purpose perspective of data storage or rebroadcasting) are routed or delivered the user, there is now a subscription to
       the intended recipient contact; from the perspective of the stanza as represented by contact, there is now a JID in
       subscription from the
   'to' attribute.  The following rules apply:

   o user. (Note: If at this point the JID contains a resource identifier (to="user@host/
      resource"), the stanza is delivered first user
       sends another subscription request to the resource contact, the user's
       server will "swallow" that
      exactly matches request and not send it on the resource identifier.

   o  If
       contact.)

   The above activity flow represents the JID contains a resource identifier and there are no
      matching resources, but there are other connected resources
      associated with "happy path" related to the user, then message stanzas are further
      processed as
   user's subscription request to the contact. The main alternate flow
   occurs if no resource is specified (see next item).  For all
      other stanzas, the server should return them contact denies the user's subscription request; in
   order to deny the sender with a
      type of "error" and an appropriate error code (503) and message.

   o  If request, the JID contains only contact's client MUST send a user@host and there is at least one
      connected resource available for the user, presence
   stanza of type "unsubscribed" to the user:

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

   The user's server should MUST then (1) deliver the that presence stanza to an appropriate resource based on the
      availability state, priority, and connect time of the connected
      resource(s).  (Existing XMPP implementations contain some
      hardcoded rules, based on <priority/>
   user and most recent connection
      time, for the routing of such stanzas.  A more flexible approach
      to routing would be desirable.)

   o  If the JID contains only (2) initiate a user@host and there are no "roster push" to all connected resources available for
   associated with the user (e.g., an IM user is offline), user, with the server MAY choose subscription attribute set to store 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 stanza (usually only message
      and presence contact is now in the user's roster
   with a subscription stanzas) on behalf state of "none", whereas the user is not in the
   contact's roster at all.

7.3 Creating a Mutual Subscription

   The user and
      deliver contaact can build on the stanza when foregoing to create a resource becomes available for that
      user. 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 offline storage 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 enabled, to accept the subscription request. (If the user
       is offline, the user's server MUST return 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
      404 ("Not Found") error
       presence stanza of type='subscribed' to the sender. 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 4, 24, 2003                [Page 26] 24]

Internet-Draft           XMPP Instant Messaging            February 2003


10. Security Considerations

   For security considerations, refer to


   <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 relevant section fact that the user has accepted the
       subscription request, the contact's server MUST (1) deliver the
       presence stanza of XMPP
   Core [1]. 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 4, 24, 2003                [Page 27] 25]

Internet-Draft           XMPP Instant Messaging            February 2003


References

   [1]  Saint-Andre, P.


   resources associated with the contact, with the subscription
   attribute set to a value of "from" and J. Miller, "XMPP Core (draft-ietf-xmpp-core-
        02, work 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 progress)", February 2003.

   [2]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
        Presence the
   subscription state; i.e., the contact is in the user's roster with a
   subscription state of "to" 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 the user is in RFCs the contact's roster
   with a subscription state of "from".

7.4 Unsubscribing

   At any time after subscribing to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [5]  Day, M., Rosenberg, J. and H. Sugano, "A Model 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 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 the contact with the 'ask' attribute set to unsubscribe
       to indicate that the unsubscribe is pending:





Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 28] 26]

Internet-Draft           XMPP Instant Messaging            February 2003


Appendix A. In-Band Registration

   This section is provided for informational purposes only and is


   <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
   normative.

   Registering with a need to be approved by the
       contact, the contact's server is necessary in order for a user to engage
   in any desired functionality by means then SHOULD auto-reply on behalf of a client.  Certainly such
   registration MAY (and frequently does) occur outside
       the context of
   an instant messaging and contact by sending a presence application.  However, XMPP stanza of type "unsubscribed"
       to the user:

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

   4.  The contact's server also
   enables MUST initiate a user "roster push" to register all
       connected resources associated with a server within the context of an IM
   system.  This functionality is enabled by sending and receiving IQ
   stanzas in contact, containing a request-response pattern, where
       roster item for the IQ stanzas contain
   <query/> elements in user with the 'jabber:iq:register' namespace.  Because in-
   band registration is not required by RFC 2779 or any XMPP-specific
   requirements, this section 'subscription' attribute set to
       a value of "none" (if the contact is non-normative.

A.1 Registration Data Flow

   Step 1: Client queries offline, the contact's
       server regarding information MUST modify the roster item and send that is required
   in order to register:

   <iq type="get"
       to="capulet.com"
       id="reg_1">
     <query xmlns="jabber:iq:register"/>
   </iq>

   Step 2: Server responds with modified item
       the required registration fields: next time the contact requests the roster):

   <iq type="result"
       from="capulet.com"
       id="reg_1"> type='set' to='contact@domain/resource'>
     <query xmlns="jabber:iq:register">
       <instructions>
         Choose a username and password to register with this service.
       </instructions>
       <email/>
       <password/>
       <username/> xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='none'/>
     </query>
   </iq>

   Note: the client is REQUIRED to provide information for all

   5.  As a result of the
   elements (other than <instructions/>) contained in the IQ result.
   (Note also fact that the XML contact has acknowledged the
       unsubscribe command, the user's server MUST (1) deliver the
       presence stanza shown above does not include a 'to'
   attribute, since of type='unsubscribed' from the contact to the
       user, and (2) initiate a "roster push" to all connected socket does not yet have resources
       associated with the user, containing an account.) 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 4, 24, 2003                [Page 29] 27]

Internet-Draft           XMPP Instant Messaging            February 2003


   Step 3: Client provides required information:


   <iq type="set"
       to="capulet.com"
       id="reg_2"> type='set'>
     <query xmlns="jabber:iq:register">
       <email>juliet@capulet.com</email>
       <password>R0m30</password>
       <username>juliet</username> xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           subscription='none'
           name='MyContact'/>
     </query>
   </iq>

   Step 4: Server informs client of successful registration:

   <iq
       type="result"
       from="capulet.com"
       id="reg_2"/>

   Step 4 (alt 1): Server informs client of failed registration
   (required field not provided):

   <iq
       type="error"
       from="capulet.com"
       id="reg_2"/>
     <query xmlns="jabber:iq:register">
       <email>juliet@capulet.com</email>
       <password>R0m30</password>
     </query>
     <error code="406">Not Acceptable</error>
   </iq>



















Saint-Andre & Miller     Expires August 4, 2003                [Page 30]

Internet-Draft           XMPP Instant Messaging            February 2003


   Step 4 (alt 2): Client is already registered:

   <iq
       type="error"
       from="capulet.com"
       id="reg_2"/>
     <query xmlns="jabber:iq:register">
       <registered/>
       <email>juliet@capulet.com</email>
       <password>R0m30</password>
       <username>juliet</username>
     </query>
     <error code="400">Bad Request</error>
   </iq>


A.2 Cancellation Data Flow

   The 'jabber:iq:register' namespace


7.4.2 Case #2: Subscription Type 'both'

   In the second case, the user has a subscription to the contact and
   the contact also makes it possible for has a user subscription to cancel the user.

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

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

   2.  As a result, the user's server by sending MUST send a <remove/> element
   as shown below.

   Step 1: Client sends request "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 unregister: indicate that the unsubscribe is pending:

   <iq type="set"
       to="capulet.com"
       id="unreg_1"> type='set' to='user@domain/resource'>
     <query xmlns="jabber:iq:register">
       <remove/> xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='both'
           ask='unsubscribe'/>
     </query>
   </iq>

   Step 2: Server informs client

   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 successful unregistration:

   <iq
       type="result"
       from="capulet.com"
       id="unreg_1"/>
       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 4, 24, 2003                [Page 31] 28]

Internet-Draft           XMPP Instant Messaging            February 2003


Appendix B. Authentication Using jabber:iq:auth

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

   The 'jabber:iq:auth' namespace provides two things: (1) a way for


       a
   client to authenticate with a server and (2) a way to define an
   authorized resource representing a specific connection or session.

   The following value of "to" (if the contact is offline, the data flow for a complete example of
   authentication and authorization with a contact's server using
       MUST modify the
   'jabber:iq:auth' namespace.

   Step 1: Client queries server regarding information roster item and send that is required
   in order to authenticate:

   <iq type="get" id="auth_1">
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
     </query>
   </iq>

   Step 2: Server responds with modified item the required authentication fields:

   <iq type="result" id="auth_1">
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
       <digest/>
       <resource/>
     </query>
   </iq>

   Step 3: Client sends authentication information (encrypted password): next
       time the contact requests the roster):

   <iq type="set" id="auth_2"> type='set' to='contact@domain/resource'>
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
       <digest>64d60e40febe09264c52bc9cbddd5dd1147fae97</digest>
       <resource>balcony</resource> xmlns='jabber:iq:roster'>
       <item
           jid='user@domain'
           name='SomeUser'
           subscription='to'/>
     </query>
   </iq>

   Step 4: Server informs client

   5.  As a result of successful authentication:

   <iq type="result" id="auth_2"/>






Saint-Andre & Miller     Expires August 4, 2003                [Page 32]

Internet-Draft           XMPP Instant Messaging            February 2003


   Step 4 (alt): Server informs client 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 failed authentication: "from"
       and with no 'ask' attribute:

   <iq
       type="error"
       from="capulet.com"
       id="auth_2"/> type='set'>
     <query xmlns="jabber:iq:auth">
       <username>juliet</username>
       <digest>64d60e40febe09264c5wrongpassword2bc9cbddd5dd1147fae97</digest>
       <resource>balcony</resource> xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           subscription='none'
           name='MyContact'/>
     </query>
     <error code="401">Unauthorized</error>
   </iq>

   The algorithm for generating digest passwords is as follows:

   1.  Concatenate

   NOTE: Obviously this does not result in removal of the Stream ID received roster item
   from the server with user's roster, and the
       password.

   2.  Hash contact still has a subscription to
   the concatenated string according user's presence. In order to more completely cancel a mutual
   subscription and fully remove the SHA1 algorithm.

   3.  Ensure that roster item from the hash output is user's roster,
   the user should update the roster item with subscription='remove' as
   defined in hexidecimal format, not binary
       or base64).

   4.  Convert 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 hash output contact
   sends to make this happen is the same in all lowercase characters. 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 4, 24, 2003                [Page 33] 29]

Internet-Draft           XMPP Instant Messaging            February 2003


Appendix C. 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


   In the
   vCard specification defined in RFC 2426 [6] is in common use within first case, the Jabber community user has a subscription to provide such information.  For the sake of
   completeness, this section describes that protocol.  This section is
   non-normative.

   The basic functionality is for contact but the
   contact does not have a user subscription 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 user (i.e., the
   subscription is done by sending an <iq/> not yet mutual).

   1.  In order to cancel the user's subscription, the contact MUST a
       presence stanza of type "set" (storage) or "get"
   (retrieval) "unsubscribed" to one's Jabber server containing the user:

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

   2.  As a <vCard/> child scoped
   by result, the 'vcard-temp' namespace, contact's server MUST send a "roster push" to
       each connected resource associated with the <vCard/> element contact, containing a
       roster item for 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.)

C.1 Retrieving One's vCard

   A user may retrieve his or her own vCard by sending XML of with the
   following form 'subscription' attribute set to his or her own JID:
       a value of "none":

   <iq to='stpeter@jabber.org' type='get' id='vcard1'>
     <vCard xmlns='vcard-temp'/> 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 MUST then return initiate a "roster push" to all
       connected resources associated with the vCard user, containing a roster
       item for the contact with the 'subscription' attribute set to a
       value of "none" (if 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 4, 2003                [Page 34]

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 user is located on my
         personal website: http://www.saint-andre.com/
       </DESC>
     </vCard> 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>


C.2 Updating One's vCard

   A


7.5.2 Case #2: Subscription Type 'both'

   In the second case, the user may update his or her vCard by sending an IQ of type "set" has a subscription to the server, following the format in contact and
   the previous use case.

   If contact also has a user attempts subscription to perform an IQ set on another the user.

   1.  In order to cancel the user's vCard, subscription, the
   server must return user MUST a 403 "Forbidden" error.
       presence stanza of type "unsubscribed" to the user:




Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 35] 30]

Internet-Draft           XMPP Instant Messaging            February 2003


C.3 Viewing Another User's vCard

   A user may view another user's vCard by sending an IQ of type "get"
   to


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

   2.  As a result, the other user's bare JID.  A compliant contact's server must return the
   vCard MUST send a "roster push" to
       each connected resource associated with the requestor and not forward contact, containing a
       roster item for the IQ to user with the requestee's
   connected resource. 'subscription' attribute set to
       a value of "to":

   <iq
       to='jer@jabber.org'
       type='get'
       id='v3'>
     <vCard xmlns='vcard-temp'/> 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 should MUST then return initiate a "roster push" to all
       connected resources associated with the other user's vCard user, containing a roster
       item for the contact with the 'subscription' attribute set to a
       value of "from" (if the
   requestor: 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
       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> type='set' to='user@domain/resource'>
     <query xmlns='jabber:iq:roster'>
       <item
           jid='contact@domain'
           name='MyContact'
           subscription='from'/>
     </query>
   </iq>

















Saint-Andre & Miller     Expires August 4, 2003                [Page 36]

Internet-Draft

   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 Instant Messaging            February 2003


Appendix D. Formal Definitions

D.1 jabber:iq:auth

D.1.1 DTD

   <!ELEMENT query ((username? | (password | digest)? | resource)*)>

   <!ELEMENT username (#PCDATA)>
   <!ELEMENT password (#PCDATA)>
   <!ELEMENT digest (#PCDATA)>
   <!ELEMENT resource (#PCDATA)>


D.1.2 Schema

   <?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='username'/>
         <xsd:choice minOccurs='0' maxOccurs='1'>
           <xsd:element ref='password'/>
           <xsd:element ref='digest'/>
         </xsd:choice>
         <xsd:element ref='resource'/>
       </xsd:choice>
     </xsd:complexType>
   </xsd:element>

   <xsd:element name='username' type='xsd:string'/>
   <xsd:element name='password' type='xsd:string'/>
   <xsd:element name='digest' type='xsd:string'/>
   <xsd:element name='resource' type='xsd:string'/>


D.2 jabber:iq:last 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 4, 24, 2003                [Page 37] 31]

Internet-Draft           XMPP Instant Messaging            February 2003


D.2.1 DTD

   <!ELEMENT query EMPTY>
   <!ATTLIST query seconds #IMPLIED>


D.2.2 Schema

   <?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>


D.3 jabber:iq:privacy

D.3.1 DTD

   <!ELEMENT query (active? | list*)>
   <!ELEMENT active EMPTY>
   <!ATTLIST


   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 name CDATA #REQUIRED>
   <!ELEMENT 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 (item*)>
   <!ATTLIST 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 name CDATA #REQUIRED>
   <!ELEMENT item ((iq? | message? | presence?)*)>
   <!ATTLIST item 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 CDATA #IMPLIED
       type (allow | deny) #REQUIRED

   2.  group

   3.  subscription (from | to) #IMPLIED>
   <!ELEMENT iq EMPTY>
   <!ELEMENT message EMPTY>
   <!ELEMENT presence EMPTY>


D.3.2 Schema

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

   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 4, 2003                [Page 38]

Internet-Draft           XMPP 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 Messaging", RFC 2778, February 2003


       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'/>
         </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'/> 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 4, 24, 2003                [Page 39] 49]

Internet-Draft           XMPP Instant Messaging            February 2003


               <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>


D.4 jabber:iq:register

D.4.1 Children

   While numerous fields are available


Appendix A. vCards

   This section is provided for use in the
   'jabber:iq:register' namespace, informational purposes only those fields (other than
   <instructions/>) sent from 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 server
   vCard specification defined in an IQ result are REQUIRED RFC 2426 [6] is in
   order common use within
   the Jabber community to register. provide such information. For the sake of
   completeness, this section describes that protocol. This section is
   non-normative.

   The following are basic functionality is for a user to store and retrieve an XML
   representation of his or her vCard using the allowable children 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
   <query/> element <vCard/> child scoped
   by the 'jabber:iq:register' namespace:

   o  instructions

   o  username

   o  password

   o  name

   o  email

   o  address

   o  city

   o  state

   o  zip

   o  phone

   o  url

   o  date '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 4, 24, 2003                [Page 40] 50]

Internet-Draft           XMPP Instant Messaging            February 2003


   o  misc

   o  text

   o  remove - request


       <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 unregister (sent only
   the server, following the format in the previous use case.

   If a user attempts to perform an IQ set)


D.4.2 DTD

   <!ELEMENT query ((instructions? | username? |
       password? | name? | email? | address? |
       city? | state? | zip? | phone? | url? |
       date? | misc? | text? | remove?)*)>

   <!ELEMENT instructions (#PCDATA)>
   <!ELEMENT username (#PCDATA)>
   <!ELEMENT password (#PCDATA)>
   <!ELEMENT name (#PCDATA)>
   <!ELEMENT email (#PCDATA)>
   <!ELEMENT address (#PCDATA)>
   <!ELEMENT city (#PCDATA)>
   <!ELEMENT state (#PCDATA)>
   <!ELEMENT zip (#PCDATA)>
   <!ELEMENT phone (#PCDATA)>
   <!ELEMENT url (#PCDATA)>
   <!ELEMENT date (#PCDATA)>
   <!ELEMENT misc (#PCDATA)>
   <!ELEMENT text (#PCDATA)>
   <!ELEMENT remove EMPTY>


D.4.3 Schema

   <?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='instructions'/>
           <xsd:element ref='username'/>
           <xsd:element ref='password'/>
           <xsd:element ref='name'/>
           <xsd:element ref='email'/> set on another user's vCard, the
   server must return a 403 "Forbidden" error.



Saint-Andre & Miller    Expires August 4, 24, 2003                [Page 41] 51]

Internet-Draft           XMPP Instant Messaging            February 2003


           <xsd:element ref='address'/>
           <xsd:element ref='city'/>
           <xsd:element ref='state'/>
           <xsd:element ref='zip'/>
           <xsd:element ref='phone'/>
           <xsd:element ref='url'/>
           <xsd:element ref='date'/>
           <xsd:element ref='misc'/>
           <xsd:element ref='text'/>
           <xsd:element ref='remove'/>
         </xsd:choice>
       </xsd:complexType>
     </xsd:element>

     <xsd:element name='instructions' type='xsd:string'/>
     <xsd:element name='username' type='xsd:string'/>
     <xsd:element name='password' type='xsd:string'/>
     <xsd:element name='name' type='xsd:string'/>
     <xsd:element name='email' type='xsd:string'/>
     <xsd:element name='address' type='xsd:string'/>
     <xsd:element name='city' type='xsd:string'/>
     <xsd:element name='state' type='xsd:string'/>
     <xsd:element name='zip' type='xsd:string'/>
     <xsd:element name='phone' type='xsd:string'/>
     <xsd:element name='url' type='xsd:string'/>
     <xsd:element name='date' type='xsd:string'/>
     <xsd:element name='misc' type='xsd:string'/>
     <xsd:element name='text' type='xsd:string'/>
     <xsd:element name='remove'/>

   </xsd:schema>


D.5 jabber:iq:roster

D.5.1 Children


A.3 Viewing Another User's vCard

   A <query/> element scoped user may view another user's vCard by sending an IQ of type "get"
   to the 'jabber:iq:roster' namespace MAY
   contain zero or more <item/> elements.  An item element MAY contain
   the following attributes:

   o  jid - other user's bare JID. A REQUIRED attribute that contains compliant server must return the complete JID of
   vCard to the
      contact that this item represents

   o  name - An OPTIONAL attribute that contains a natural-language name
      for requestor and not forward the contact

   o  subscription - An OPTIONAL attribute that captures IQ to the current 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 4, 24, 2003                [Page 42] 52]

Internet-Draft           XMPP Instant Messaging            February 2003


      status of the subscription related to this item.  Should be one of
      the following (all other values are ignored):

      *  none - no subscription.

      *  from - this entity has a subscription to the contact.

      *  to - the contact has a subscription to this entity.

      *  both - subscription is both to and from.

      *  remove - item is to be removed.

   o  ask - An OPTIONAL attribute specifying the current status of a
      request to this contact.  Should be one of the following (all
      other values are ignored):

      *  subscribe - this entity is asking to subscribe to that
         contact's presence.

      *  unsubscribe - this entity is asking unsubscribe from that
         contact's presence.

   An <item/> element MAY contain zero or more instances of the
   following element:

   o  group - Natural-language name of a user-specified group


Appendix B. Formal Definitions

B.1 Schema for the
      purpose of categorizing contacts into groups.


D.5.2 DTD

   <!ELEMENT query ((item)*)>

   <!ELEMENT item ((group)*)>
   <!ATTLIST item
       jid CDATA #REQUIRED
       name CDATA #IMPLIED
       subscription ( to | from | both | none | remove ) #IMPLIED
       ask ( subscribe | unsubscribe ) #IMPLIED
       >
   <!ELEMENT group (#PCDATA)>


D.5.3 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 4, 24, 2003                [Page 43] 54]

Internet-Draft           XMPP Instant Messaging            February 2003


       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: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>






Saint-Andre & Miller     Expires August 4, 2003                [Page 44]

Internet-Draft           XMPP Instant Messaging            February 2003


D.6


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 4, 24, 2003                [Page 45] 56]

Internet-Draft           XMPP Instant Messaging            February 2003


     (VERSION, FN, N),
     (NICKNAME?,
     PHOTO?,
     BDAY?,
     ADR?,
     LABEL?,


     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)>




Saint-Andre & Miller     Expires August 4, 2003                [Page 46]

Internet-Draft           XMPP Instant Messaging            February 2003

     <!-- 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+



Saint-Andre & Miller     Expires August 4, 2003                [Page 47]

Internet-Draft           XMPP Instant Messaging            February 2003
     )>

       <!-- 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@host. 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



Saint-Andre & Miller     Expires August 4, 2003                [Page 48]

Internet-Draft           XMPP Instant Messaging            February 2003
       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



Saint-Andre & Miller     Expires August 4, 2003                [Page 49]

Internet-Draft           XMPP Instant Messaging            February 2003 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>



Saint-Andre & Miller     Expires August 4, 2003                [Page 50]

Internet-Draft           XMPP Instant Messaging            February 2003
   <!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 4, 24, 2003                [Page 51] 62]

Internet-Draft           XMPP Instant Messaging            February 2003


Appendix E. C. Revision History

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

E.1

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.


E.2


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

   o  Moved registration and authentication via jabber:iq:auth to non-
      normative
      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.


E.3


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 4, 24, 2003                [Page 52] 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 assigns. 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 4, 24, 2003                [Page 53] 66]

----