P1L1	
P1L2	
P1L3	
P1L4	Network Working Group                                P. Saint-Andre, Ed.
P1L5	Request for Comments: 3921                    Jabber Software Foundation
P1L6	Category: Standards Track                                   October 2004
P1L7	
P1L8	
P1L9	          Extensible Messaging and Presence Protocol (XMPP):
P1L10	                     Instant Messaging and Presence
P1L11	
P1L12	Status of this Memo
P1L13	
P1L14	   This document specifies an Internet standards track protocol for the
P1L15	   Internet community, and requests discussion and suggestions for
P1L16	   improvements.  Please refer to the current edition of the "Internet
P1L17	   Official Protocol Standards" (STD 1) for the standardization state
P1L18	   and status of this protocol.  Distribution of this memo is unlimited.
P1L19	
P1L20	Copyright Notice
P1L21	
P1L22	   Copyright (C) The Internet Society (2004).
P1L23	
P1L24	Abstract
P1L25	
P1L26	   This memo describes extensions to and applications of the core
P1L27	   features of the Extensible Messaging and Presence Protocol (XMPP)
P1L28	   that provide the basic instant messaging (IM) and presence
P1L29	   functionality defined in RFC 2779.
P1L30	
P1L31	
P1L32	
P1L33	
P1L34	
P1L35	
P1L36	
P1L37	
P1L38	
P1L39	
P1L40	
P1L41	
P1L42	
P1L43	
P1L44	
P1L45	
P1L46	
P1L47	
P1L48	
P2L1	Table of Contents
P2L2	
P2L3	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
P2L4	   2.   Syntax of XML Stanzas  . . . . . . . . . . . . . . . . . . .   4
P2L5	   3.   Session Establishment  . . . . . . . . . . . . . . . . . . .  10
P2L6	   4.   Exchanging Messages  . . . . . . . . . . . . . . . . . . . .  13
P2L7	   5.   Exchanging Presence Information  . . . . . . . . . . . . . .  16
P2L8	   6.   Managing Subscriptions . . . . . . . . . . . . . . . . . . .  26
P2L9	   7.   Roster Management  . . . . . . . . . . . . . . . . . . . . .  27
P2L10	   8.   Integration of Roster Items and Presence Subscriptions . . .  32
P2L11	   9.   Subscription States  . . . . . . . . . . . . . . . . . . . .  56
P2L12	   10.  Blocking Communication . . . . . . . . . . . . . . . . . . .  62
P2L13	   11.  Server Rules for Handling XML Stanzas  . . . . . . . . . . .  85
P2L14	   12.  IM and Presence Compliance Requirements  . . . . . . . . . .  88
P2L15	   13.  Internationalization Considerations  . . . . . . . . . . . .  89
P2L16	   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  89
P2L17	   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  90
P2L18	   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  91
P2L19	   A.   vCards . . . . . . . . . . . . . . . . . . . . . . . . . . .  93
P2L20	   B.   XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . .  93
P2L21	   C.   Differences Between Jabber IM/Presence Protocols and XMPP. . 105
P2L22	   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . .  106
P2L23	   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  106
P2L24	   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106
P2L25	   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107
P2L26	
P2L27	1.  Introduction
P2L28	
P2L29	1.1.  Overview
P2L30	
P2L31	   The Extensible Messaging and Presence Protocol (XMPP) is a protocol
P2L32	   for streaming XML [XML] elements in order to exchange messages and
P2L33	   presence information in close to real time.  The core features of
P2L34	   XMPP are defined in Extensible Messaging and Presence Protocol
P2L35	   (XMPP): Core [XMPP-CORE].  These features -- mainly XML streams, use
P2L36	   of TLS and SASL, and the <message/>, <presence/>, and <iq/> children
P2L37	   of the stream root -- provide the building blocks for many types of
P2L38	   near-real-time applications, which may be layered on top of the core
P2L39	   by sending application-specific data qualified by particular XML
P2L40	   namespaces [XML-NAMES].  This memo describes extensions to and
P2L41	   applications of the core features of XMPP that provide the basic
P2L42	   functionality expected of an instant messaging (IM) and presence
P2L43	   application as defined in RFC 2779 [IMP-REQS].
P2L44	
P2L45	
P2L46	
P2L47	
P2L48	
P3L1	1.2.  Requirements
P3L2	
P3L3	   For the purposes of this memo, the requirements of a basic instant
P3L4	   messaging and presence application are defined by [IMP-REQS], which
P3L5	   at a high level stipulates that a user must be able to complete the
P3L6	   following use cases:
P3L7	
P3L8	   o  Exchange messages with other users
P3L9	   o  Exchange presence information with other users
P3L10	   o  Manage subscriptions to and from other users
P3L11	   o  Manage items in a contact list (in XMPP this is called a "roster")
P3L12	   o  Block communications to or from specific other users
P3L13	
P3L14	   Detailed definitions of these functionality areas are contained in
P3L15	   [IMP-REQS], and the interested reader is directed to that document
P3L16	   regarding the requirements addressed herein.
P3L17	
P3L18	   [IMP-REQS] also stipulates that presence services must be separable
P3L19	   from instant messaging services; i.e., it must be possible to use the
P3L20	   protocol to provide a presence service, an instant messaging service,
P3L21	   or both.  Although the text of this memo assumes that implementations
P3L22	   and deployments will want to offer a unified instant messaging and
P3L23	   presence service, there is no requirement that a service must offer
P3L24	   both a presence service and an instant messaging service, and the
P3L25	   protocol makes it possible to offer separate and distinct services
P3L26	   for presence and for instant messaging.
P3L27	
P3L28	   Note: While XMPP-based instant messaging and presence meets the
P3L29	   requirements of [IMP-REQS], it was not designed explicitly with that
P3L30	   specification in mind, since the base protocol evolved through an
P3L31	   open development process within the Jabber open-source community
P3L32	   before RFC 2779 was written.  Note also that although protocols
P3L33	   addressing many other functionality areas have been defined in the
P3L34	   Jabber community, such protocols are not included in this memo
P3L35	   because they are not required by [IMP-REQS].
P3L36	
P3L37	1.3.  Terminology
P3L38	
P3L39	   This memo inherits the terminology defined in [XMPP-CORE].
P3L40	
P3L41	   The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
P3L42	   "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
P3L43	   "OPTIONAL" in this document are to be interpreted as described in BCP
P3L44	   14, RFC 2119 [TERMS].
P3L45	
P3L46	
P3L47	
P3L48	
P4L1	2.  Syntax of XML Stanzas
P4L2	
P4L3	   The basic semantics and common attributes of XML stanzas qualified by
P4L4	   the 'jabber:client' and 'jabber:server' namespaces are defined in
P4L5	   [XMPP-CORE].  However, these namespaces also define various child
P4L6	   elements, as well as values for the common 'type' attribute, that are
P4L7	   specific to instant messaging and presence applications.  Thus,
P4L8	   before addressing particular "use cases" for such applications, we
P4L9	   here further describe the syntax of XML stanzas, thereby
P4L10	   supplementing the discussion in [XMPP-CORE].
P4L11	
P4L12	2.1.  Message Syntax
P4L13	
P4L14	   Message stanzas qualified by the 'jabber:client' or 'jabber:server'
P4L15	   namespace are used to "push" information to another entity.  Common
P4L16	   uses in instant messaging applications include single messages,
P4L17	   messages sent in the context of a chat conversation, messages sent in
P4L18	   the context of a multi-user chat room, headlines and other alerts,
P4L19	   and errors.
P4L20	
P4L21	2.1.1.  Types of Message
P4L22	
P4L23	   The 'type' attribute of a message stanza is RECOMMENDED; if included,
P4L24	   it specifies the conversational context of the message, thus
P4L25	   providing a hint regarding presentation (e.g., in a GUI).  If
P4L26	   included, the 'type' attribute MUST have one of the following values:
P4L27	
P4L28	   o  chat -- The message is sent in the context of a one-to-one chat
P4L29	      conversation.  A compliant client SHOULD present the message in an
P4L30	      interface enabling one-to-one chat between the two parties,
P4L31	      including an appropriate conversation history.
P4L32	
P4L33	   o  error -- An error has occurred related to a previous message sent
P4L34	      by the sender (for details regarding stanza error syntax, refer to
P4L35	      [XMPP-CORE]).  A compliant client SHOULD present an appropriate
P4L36	      interface informing the sender of the nature of the error.
P4L37	
P4L38	   o  groupchat -- The message is sent in the context of a multi-user
P4L39	      chat environment (similar to that of [IRC]).  A compliant client
P4L40	      SHOULD present the message in an interface enabling many-to-many
P4L41	      chat between the parties, including a roster of parties in the
P4L42	      chatroom and an appropriate conversation history.  Full definition
P4L43	      of XMPP-based groupchat protocols is out of scope for this memo.
P4L44	
P4L45	   o  headline -- The message is probably generated by an automated
P4L46	      service that delivers or broadcasts content (news, sports, market
P4L47	      information, RSS feeds, etc.).  No reply to the message is
P4L48	      expected, and a compliant client SHOULD present the message in an
P5L1	      interface that appropriately differentiates the message from
P5L2	      standalone messages, chat sessions, or groupchat sessions (e.g.,
P5L3	      by not providing the recipient with the ability to reply).
P5L4	
P5L5	   o  normal -- The message is a single message that is sent outside the
P5L6	      context of a one-to-one conversation or groupchat, and to which it
P5L7	      is expected that the recipient will reply.  A compliant client
P5L8	      SHOULD present the message in an interface enabling the recipient
P5L9	      to reply, but without a conversation history.
P5L10	
P5L11	   An IM application SHOULD support all of the foregoing message types;
P5L12	   if an application receives a message with no 'type' attribute or the
P5L13	   application does not understand the value of the 'type' attribute
P5L14	   provided, it MUST consider the message to be of type "normal" (i.e.,
P5L15	   "normal" is the default).  The "error" type MUST be generated only in
P5L16	   response to an error related to a message received from another
P5L17	   entity.
P5L18	
P5L19	   Although the 'type' attribute is OPTIONAL, it is considered polite to
P5L20	   mirror the type in any replies to a message; furthermore, some
P5L21	   specialized applications (e.g., a multi-user chat service) MAY at
P5L22	   their discretion enforce the use of a particular message type (e.g.,
P5L23	   type='groupchat').
P5L24	
P5L25	2.1.2.  Child Elements
P5L26	
P5L27	   As described under extended namespaces (Section 2.4), a message
P5L28	   stanza MAY contain any properly-namespaced child element.
P5L29	
P5L30	   In accordance with the default namespace declaration, by default a
P5L31	   message stanza is qualified by the 'jabber:client' or 'jabber:server'
P5L32	   namespace, which defines certain allowable children of message
P5L33	   stanzas.  If the message stanza is of type "error", it MUST include
P5L34	   an <error/> child; for details, see [XMPP-CORE].  Otherwise, the
P5L35	   message stanza MAY contain any of the following child elements
P5L36	   without an explicit namespace declaration:
P5L37	
P5L38	   1.  <subject/>
P5L39	   2.  <body/>
P5L40	   3.  <thread/>
P5L41	
P5L42	2.1.2.1.  Subject
P5L43	
P5L44	   The <subject/> element contains human-readable XML character data
P5L45	   that specifies the topic of the message.  The <subject/> element MUST
P5L46	   NOT possess any attributes, with the exception of the 'xml:lang'
P5L47	   attribute.  Multiple instances of the <subject/> element MAY be
P5L48	   included for the purpose of providing alternate versions of the same
P6L1	   subject, but only if each instance possesses an 'xml:lang' attribute
P6L2	   with a distinct language value.  The <subject/> element MUST NOT
P6L3	   contain mixed content (as defined in Section 3.2.2 of [XML]).
P6L4	
P6L5	2.1.2.2.  Body
P6L6	
P6L7	   The <body/> element contains human-readable XML character data that
P6L8	   specifies the textual contents of the message; this child element is
P6L9	   normally included but is OPTIONAL.  The <body/> element MUST NOT
P6L10	   possess any attributes, with the exception of the 'xml:lang'
P6L11	   attribute.  Multiple instances of the <body/> element MAY be included
P6L12	   but only if each instance possesses an 'xml:lang' attribute with a
P6L13	   distinct language value.  The <body/> element MUST NOT contain mixed
P6L14	   content (as defined in Section 3.2.2 of [XML]).
P6L15	
P6L16	2.1.2.3.  Thread
P6L17	
P6L18	   The <thread/> element contains non-human-readable XML character data
P6L19	   specifying an identifier that is used for tracking a conversation
P6L20	   thread (sometimes referred to as an "instant messaging session")
P6L21	   between two entities.  The value of the <thread/> element is
P6L22	   generated by the sender and SHOULD be copied back in any replies.  If
P6L23	   used, it MUST be unique to that conversation thread within the stream
P6L24	   and MUST be consistent throughout that conversation (a client that
P6L25	   receives a message from the same full JID but with a different thread
P6L26	   ID MUST assume that the message in question exists outside the
P6L27	   context of the existing conversation thread).  The use of the
P6L28	   <thread/> element is OPTIONAL and is not used to identify individual
P6L29	   messages, only conversations.  A message stanza MUST NOT contain more
P6L30	   than one <thread/> element.  The <thread/> element MUST NOT possess
P6L31	   any attributes.  The value of the <thread/> element MUST be treated
P6L32	   as opaque by entities; no semantic meaning may be derived from it,
P6L33	   and only exact comparisons may be made against it.  The <thread/>
P6L34	   element MUST NOT contain mixed content (as defined in Section 3.2.2
P6L35	   of [XML]).
P6L36	
P6L37	2.2.  Presence Syntax
P6L38	
P6L39	   Presence stanzas are used qualified by the 'jabber:client' or
P6L40	   'jabber:server' namespace to express an entity's current network
P6L41	   availability (offline or online, along with various sub-states of the
P6L42	   latter and optional user-defined descriptive text), and to notify
P6L43	   other entities of that availability.  Presence stanzas are also used
P6L44	   to negotiate and manage subscriptions to the presence of other
P6L45	   entities.
P6L46	
P6L47	
P6L48	
P7L1	2.2.1.  Types of Presence
P7L2	
P7L3	   The 'type' attribute of a presence stanza is OPTIONAL.  A presence
P7L4	   stanza that does not possess a 'type' attribute is used to signal to
P7L5	   the server that the sender is online and available for communication.
P7L6	   If included, the 'type' attribute specifies a lack of availability, a
P7L7	   request to manage a subscription to another entity's presence, a
P7L8	   request for another entity's current presence, or an error related to
P7L9	   a previously-sent presence stanza.  If included, the 'type' attribute
P7L10	   MUST have one of the following values:
P7L11	
P7L12	   o  unavailable -- Signals that the entity is no longer available for
P7L13	      communication.
P7L14	
P7L15	   o  subscribe -- The sender wishes to subscribe to the recipient's
P7L16	      presence.
P7L17	
P7L18	   o  subscribed -- The sender has allowed the recipient to receive
P7L19	      their presence.
P7L20	
P7L21	   o  unsubscribe -- The sender is unsubscribing from another entity's
P7L22	      presence.
P7L23	
P7L24	   o  unsubscribed -- The subscription request has been denied or a
P7L25	      previously-granted subscription has been cancelled.
P7L26	
P7L27	   o  probe -- A request for an entity's current presence; SHOULD be
P7L28	      generated only by a server on behalf of a user.
P7L29	
P7L30	   o  error -- An error has occurred regarding processing or delivery of
P7L31	      a previously-sent presence stanza.
P7L32	
P7L33	   For detailed information regarding presence semantics and the
P7L34	   subscription model used in the context of XMPP-based instant
P7L35	   messaging and presence applications, refer to Exchanging Presence
P7L36	   Information (Section 5) and Managing Subscriptions (Section 6).
P7L37	
P7L38	2.2.2.  Child Elements
P7L39	
P7L40	   As described under extended namespaces (Section 2.4), a presence
P7L41	   stanza MAY contain any properly-namespaced child element.
P7L42	
P7L43	   In accordance with the default namespace declaration, by default a
P7L44	   presence stanza is qualified by the 'jabber:client' or
P7L45	   'jabber:server' namespace, which defines certain allowable children
P7L46	   of presence stanzas.  If the presence stanza is of type "error", it
P7L47	   MUST include an <error/> child; for details, see [XMPP-CORE].  If the
P7L48	   presence stanza possesses no 'type' attribute, it MAY contain any of
P8L1	   the following child elements (note that the <status/> child MAY be
P8L2	   sent in a presence stanza of type "unavailable" or, for historical
P8L3	   reasons, "subscribe"):
P8L4	
P8L5	   1.  <show/>
P8L6	   2.  <status/>
P8L7	   3.  <priority/>
P8L8	
P8L9	2.2.2.1.  Show
P8L10	
P8L11	   The OPTIONAL <show/> element contains non-human-readable XML
P8L12	   character data that specifies the particular availability status of
P8L13	   an entity or specific resource.  A presence stanza MUST NOT contain
P8L14	   more than one <show/> element.  The <show/> element MUST NOT possess
P8L15	   any attributes.  If provided, the XML character data value MUST be
P8L16	   one of the following (additional availability types could be defined
P8L17	   through a properly-namespaced child element of the presence stanza):
P8L18	
P8L19	   o  away -- The entity or resource is temporarily away.
P8L20	
P8L21	   o  chat -- The entity or resource is actively interested in chatting.
P8L22	
P8L23	   o  dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
P8L24	
P8L25	   o  xa -- The entity or resource is away for an extended period (xa =
P8L26	      "eXtended Away").
P8L27	
P8L28	   If no <show/> element is provided, the entity is assumed to be online
P8L29	   and available.
P8L30	
P8L31	2.2.2.2.  Status
P8L32	
P8L33	   The OPTIONAL <status/> element contains XML character data specifying
P8L34	   a natural-language description of availability status.  It is
P8L35	   normally used in conjunction with the show element to provide a
P8L36	   detailed description of an availability state (e.g., "In a meeting").
P8L37	   The <status/> element MUST NOT possess any attributes, with the
P8L38	   exception of the 'xml:lang' attribute.  Multiple instances of the
P8L39	   <status/> element MAY be included but only if each instance possesses
P8L40	   an 'xml:lang' attribute with a distinct language value.
P8L41	
P8L42	2.2.2.3.  Priority
P8L43	
P8L44	   The OPTIONAL <priority/> element contains non-human-readable XML
P8L45	   character data that specifies the priority level of the resource. The
P8L46	   value MUST be an integer between -128 and +127.  A presence stanza
P8L47	   MUST NOT contain more than one <priority/> element.  The <priority/>
P8L48	   element MUST NOT possess any attributes.  If no priority is provided,
P9L1	   a server SHOULD consider the priority to be zero.  For information
P9L2	   regarding the semantics of priority values in stanza routing within
P9L3	   instant messaging and presence applications, refer to Server Rules
P9L4	   for Handling XML Stanzas (Section 11).
P9L5	
P9L6	2.3.  IQ Syntax
P9L7	
P9L8	   IQ stanzas provide a structured request-response mechanism.  The
P9L9	   basic semantics of that mechanism (e.g., that the 'id' attribute is
P9L10	   REQUIRED) are defined in [XMPP-CORE], whereas the specific semantics
P9L11	   required to complete particular use cases are defined in all cases by
P9L12	   an extended namespace (Section 2.4) (note that the 'jabber:client'
P9L13	   and 'jabber:server' namespaces do not define any children of IQ
P9L14	   stanzas other than the common <error/>).  This memo defines two such
P9L15	   extended namespaces, one for Roster Management (Section 7) and the
P9L16	   other for Blocking Communication (Section 10); however, an IQ stanza
P9L17	   MAY contain structured information qualified by any extended
P9L18	   namespace.
P9L19	
P9L20	2.4.  Extended Namespaces
P9L21	
P9L22	   While the three XML stanza kinds defined in the "jabber:client" or
P9L23	   "jabber:server" namespace (along with their attributes and child
P9L24	   elements) provide a basic level of functionality for messaging and
P9L25	   presence, XMPP uses XML namespaces to extend the stanzas for the
P9L26	   purpose of providing additional functionality.  Thus a message or
P9L27	   presence stanza MAY contain one or more optional child elements
P9L28	   specifying content that extends the meaning of the message (e.g., an
P9L29	   XHTML-formatted version of the message body), and an IQ stanza MAY
P9L30	   contain one such child element.  This child element MAY have any name
P9L31	   and MUST possess an 'xmlns' namespace declaration (other than
P9L32	   "jabber:client", "jabber:server", or
P9L33	   "http://etherx.jabber.org/streams") that defines all data contained
P9L34	   within the child element.
P9L35	
P9L36	   Support for any given extended namespace is OPTIONAL on the part of
P9L37	   any implementation (aside from the extended namespaces defined
P9L38	   herein).  If an entity does not understand such a namespace, the
P9L39	   entity's expected behavior depends on whether the entity is (1) the
P9L40	   recipient or (2) an entity that is routing the stanza to the
P9L41	   recipient:
P9L42	
P9L43	   Recipient: If a recipient receives a stanza that contains a child
P9L44	      element it does not understand, it SHOULD ignore that specific XML
P9L45	      data, i.e., it SHOULD not process it or present it to a user or
P9L46	      associated application (if any).  In particular:
P9L47	
P9L48	
P10L1	      *  If an entity receives a message or presence stanza that
P10L2	         contains XML data qualified by a namespace it does not
P10L3	         understand, the portion of the stanza that is in the unknown
P10L4	         namespace SHOULD be ignored.
P10L5	
P10L6	      *  If an entity receives a message stanza whose only child element
P10L7	         is qualified by a namespace it does not understand, it MUST
P10L8	         ignore the entire stanza.
P10L9	
P10L10	      *  If an entity receives an IQ stanza of type "get" or "set"
P10L11	         containing a child element qualified by a namespace it does not
P10L12	         understand, the entity SHOULD return an IQ stanza of type
P10L13	         "error" with an error condition of <service-unavailable/>.
P10L14	
P10L15	   Router: If a routing entity (usually a server) handles a stanza that
P10L16	      contains a child element it does not understand, it SHOULD ignore
P10L17	      the associated XML data by passing it on untouched to the
P10L18	      recipient.
P10L19	
P10L20	3.  Session Establishment
P10L21	
P10L22	   Most instant messaging and presence applications based on XMPP are
P10L23	   implemented via a client-server architecture that requires a client
P10L24	   to establish a session on a server in order to engage in the expected
P10L25	   instant messaging and presence activities.  However, there are
P10L26	   several pre-conditions that MUST be met before a client can establish
P10L27	   an instant messaging and presence session.  These are:
P10L28	
P10L29	   1.  Stream Authentication -- a client MUST complete stream
P10L30	       authentication as documented in [XMPP-CORE] before attempting to
P10L31	       establish a session or send any XML stanzas.
P10L32	   2.  Resource Binding -- after completing stream authentication, a
P10L33	       client MUST bind a resource to the stream so that the client's
P10L34	       address is of the form <user@domain/resource>, after which the
P10L35	       entity is now said to be a "connected resource" in the
P10L36	       terminology of [XMPP-CORE].
P10L37	
P10L38	   If a server supports sessions, it MUST include a <session/> element
P10L39	   qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace in
P10L40	   the stream features it advertises to a client after the completion of
P10L41	   stream authentication as defined in [XMPP-CORE]:
P10L42	
P10L43	
P10L44	
P10L45	
P10L46	
P10L47	
P10L48	
P11L1	   Server advertises session establishment feature to client:
P11L2	
P11L3	   <stream:stream
P11L4	       xmlns='jabber:client'
P11L5	       xmlns:stream='http://etherx.jabber.org/streams'
P11L6	       id='c2s_345'
P11L7	       from='example.com'
P11L8	       version='1.0'>
P11L9	   <stream:features>
P11L10	     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
P11L11	     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
P11L12	   </stream:features>
P11L13	
P11L14	   Upon being so informed that session establishment is required (and
P11L15	   after completing resource binding), the client MUST establish a
P11L16	   session if it desires to engage in instant messaging and presence
P11L17	   functionality; it completes this step by sending to the server an IQ
P11L18	   stanza of type "set" containing an empty <session/> child element
P11L19	   qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace:
P11L20	
P11L21	   Step 1: Client requests session with server:
P11L22	
P11L23	   <iq to='example.com'
P11L24	       type='set'
P11L25	       id='sess_1'>
P11L26	     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
P11L27	   </iq>
P11L28	
P11L29	   Step 2: Server informs client that session has been created:
P11L30	
P11L31	   <iq from='example.com'
P11L32	       type='result'
P11L33	       id='sess_1'/>
P11L34	
P11L35	   Upon establishing a session, a connected resource (in the terminology
P11L36	   of [XMPP-CORE]) is said to be an "active resource".
P11L37	
P11L38	   Several error conditions are possible.  For example, the server may
P11L39	   encounter an internal condition that prevents it from creating the
P11L40	   session, the username or authorization identity may lack permissions
P11L41	   to create a session, or there may already be an active resource
P11L42	   associated with a resource identifier of the same name.
P11L43	
P11L44	   If the server encounters an internal condition that prevents it from
P11L45	   creating the session, it MUST return an error.
P11L46	
P11L47	
P11L48	
P12L1	   Step 2 (alt): Server responds with error (internal server error):
P12L2	
P12L3	   <iq from='example.com' type='error' id='sess_1'>
P12L4	     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
P12L5	     <error type='wait'>
P12L6	       <internal-server-error
P12L7	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P12L8	     </error>
P12L9	   </iq>
P12L10	
P12L11	   If the username or resource is not allowed to create a session, the
P12L12	   server MUST return an error (e.g., forbidden).
P12L13	
P12L14	   Step 2 (alt): Server responds with error (username or resource not
P12L15	   allowed to create session):
P12L16	
P12L17	   <iq from='example.com' type='error' id='sess_1'>
P12L18	     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
P12L19	     <error type='auth'>
P12L20	       <forbidden
P12L21	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P12L22	     </error>
P12L23	   </iq>
P12L24	
P12L25	   If there is already an active resource of the same name, the server
P12L26	   MUST either (1) terminate the active resource and allow the
P12L27	   newly-requested session, or (2) disallow the newly-requested session
P12L28	   and maintain the active resource.  Which of these the server does is
P12L29	   up to the implementation, although it is RECOMMENDED to implement
P12L30	   case #1.  In case #1, the server SHOULD send a <conflict/> stream
P12L31	   error to the active resource, terminate the XML stream and underlying
P12L32	   TCP connection for the active resource, and return a IQ stanza of
P12L33	   type "result" (indicating success) to the newly-requested session. In
P12L34	   case #2, the server SHOULD send a <conflict/> stanza error to the
P12L35	   newly-requested session but maintain the XML stream for that
P12L36	   connection so that the newly-requested session has an opportunity to
P12L37	   negotiate a non-conflicting resource identifier before sending
P12L38	   another request for session establishment.
P12L39	
P12L40	   Step 2 (alt): Server informs existing active resource of resource
P12L41	   conflict (case #1):
P12L42	
P12L43	   <stream:error>
P12L44	     <conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
P12L45	   </stream:error>
P12L46	   </stream:stream>
P12L47	
P12L48	
P13L1	   Step 2 (alt): Server informs newly-requested session of resource
P13L2	   conflict (case #2):
P13L3	
P13L4	   <iq from='example.com' type='error' id='sess_1'>
P13L5	     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
P13L6	     <error type='cancel'>
P13L7	       <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P13L8	     </error>
P13L9	   </iq>
P13L10	
P13L11	   After establishing a session, a client SHOULD send initial presence
P13L12	   and request its roster as described below, although these actions are
P13L13	   OPTIONAL.
P13L14	
P13L15	   Note: Before allowing the creation of instant messaging and presence
P13L16	   sessions, a server MAY require prior account provisioning.  Possible
P13L17	   methods for account provisioning include account creation by a server
P13L18	   administrator as well as in-band account registration using the
P13L19	   'jabber:iq:register' namespace; the latter method is out of scope for
P13L20	   this memo, but is documented in [JEP-0077], published by the Jabber
P13L21	   Software Foundation [JSF].
P13L22	
P13L23	4.  Exchanging Messages
P13L24	
P13L25	   Exchanging messages is a basic use of XMPP and is brought about when
P13L26	   a user generates a message stanza that is addressed to another
P13L27	   entity.  As defined under Server Rules for Handling XML Stanzas
P13L28	   (Section 11), the sender's server is responsible for delivering the
P13L29	   message to the intended recipient (if the recipient is on the same
P13L30	   server) or for routing the message to the recipient's server (if the
P13L31	   recipient is on a different server).
P13L32	
P13L33	   For information regarding the syntax of message stanzas as well as
P13L34	   their defined attributes and child elements, refer to Message Syntax
P13L35	   (Section 2.1).
P13L36	
P13L37	4.1.  Specifying an Intended Recipient
P13L38	
P13L39	   An instant messaging client SHOULD specify an intended recipient for
P13L40	   a message by providing the JID of an entity other than the sender in
P13L41	   the 'to' attribute of the <message/> stanza.  If the message is being
P13L42	   sent in reply to a message previously received from an address of the
P13L43	   form <user@domain/resource> (e.g., within the context of a chat
P13L44	   session), the value of the 'to' address SHOULD be of the form
P13L45	   <user@domain/resource> rather than of the form <user@domain> unless
P13L46	   the sender has knowledge (via presence) that the intended recipient's
P13L47	   resource is no longer available.  If the message is being sent
P13L48	
P14L1	   outside the context of any existing chat session or received message,
P14L2	   the value of the 'to' address SHOULD be of the form <user@domain>
P14L3	   rather than of the form <user@domain/resource>.
P14L4	
P14L5	4.2.  Specifying a Message Type
P14L6	
P14L7	   As noted, it is RECOMMENDED for a message stanza to possess a 'type'
P14L8	   attribute whose value captures the conversational context (if any) of
P14L9	   the message (see Type (Section 2.1.1)).
P14L10	
P14L11	   The following example shows a valid value of the 'type' attribute:
P14L12	
P14L13	   Example: A message of a defined type:
P14L14	
P14L15	   <message
P14L16	       to='romeo@example.net'
P14L17	       from='juliet@example.com/balcony'
P14L18	       type='chat'
P14L19	       xml:lang='en'>
P14L20	     <body>Wherefore art thou, Romeo?</body>
P14L21	   </message>
P14L22	
P14L23	4.3.  Specifying a Message Body
P14L24	
P14L25	   A message stanza MAY (and often will) contain a child <body/> element
P14L26	   whose XML character data specifies the primary meaning of the message
P14L27	   (see Body (Section 2.1.2.2)).
P14L28	
P14L29	   Example: A message with a body:
P14L30	
P14L31	   <message
P14L32	       to='romeo@example.net'
P14L33	       from='juliet@example.com/balcony'
P14L34	       type='chat'
P14L35	       xml:lang='en'>
P14L36	     <body>Wherefore art thou, Romeo?</body>
P14L37	     <body xml:lang='cz'>Pro&#x010D;e&#x017D; jsi ty, Romeo?</body>
P14L38	   </message>
P14L39	
P14L40	4.4.  Specifying a Message Subject
P14L41	
P14L42	   A message stanza MAY contain one or more child <subject/> elements
P14L43	   specifying the topic of the message (see Subject (Section 2.1.2.1)).
P14L44	
P14L45	
P14L46	
P14L47	
P14L48	
P15L1	   Example: A message with a subject:
P15L2	
P15L3	   <message
P15L4	       to='romeo@example.net'
P15L5	       from='juliet@example.com/balcony'
P15L6	       type='chat'
P15L7	       xml:lang='en'>
P15L8	     <subject>I implore you!</subject>
P15L9	     <subject
P15L10	         xml:lang='cz'>&#x00DA;p&#x011B;nliv&#x011B; prosim!</subject>
P15L11	     <body>Wherefore art thou, Romeo?</body>
P15L12	     <body xml:lang='cz'>Pro&#x010D;e&#x017D; jsi ty, Romeo?</body>
P15L13	   </message>
P15L14	
P15L15	4.5.  Specifying a Conversation Thread
P15L16	
P15L17	   A message stanza MAY contain a child <thread/> element specifying the
P15L18	   conversation thread in which the message is situated, for the purpose
P15L19	   of tracking the conversation (see Thread (Section 2.1.2.3)).
P15L20	
P15L21	   Example: A threaded conversation:
P15L22	
P15L23	   <message
P15L24	       to='romeo@example.net/orchard'
P15L25	       from='juliet@example.com/balcony'
P15L26	       type='chat'
P15L27	       xml:lang='en'>
P15L28	     <body>Art thou not Romeo, and a Montague?</body>
P15L29	     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
P15L30	   </message>
P15L31	
P15L32	   <message
P15L33	       to='juliet@example.com/balcony'
P15L34	       from='romeo@example.net/orchard'
P15L35	       type='chat'
P15L36	       xml:lang='en'>
P15L37	     <body>Neither, fair saint, if either thee dislike.</body>
P15L38	     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
P15L39	   </message>
P15L40	
P15L41	   <message
P15L42	       to='romeo@example.net/orchard'
P15L43	       from='juliet@example.com/balcony'
P15L44	       type='chat'
P15L45	       xml:lang='en'>
P15L46	     <body>How cam'st thou hither, tell me, and wherefore?</body>
P15L47	     <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
P15L48	   </message>
P16L1	5.  Exchanging Presence Information
P16L2	
P16L3	   Exchanging presence information is made relatively straightforward
P16L4	   within XMPP by using presence stanzas.  However, we see here a
P16L5	   contrast to the handling of messages: although a client MAY send
P16L6	   directed presence information to another entity by including a 'to'
P16L7	   address, normally presence notifications (i.e., presence stanzas with
P16L8	   no 'type' or of type "unavailable" and with no 'to' address) are sent
P16L9	   from a client to its server and then broadcasted by the server to any
P16L10	   entities that are subscribed to the presence of the sending entity
P16L11	   (in the terminology of RFC 2778 [IMP-MODEL], these entities are
P16L12	   subscribers).  This broadcast model does not apply to
P16L13	   subscription-related presence stanzas or presence stanzas of type
P16L14	   "error", but to presence notifications only as defined above.  (Note:
P16L15	   While presence information MAY be provided on a user's behalf by an
P16L16	   automated service, normally it is provided by the user's client.)
P16L17	
P16L18	   For information regarding the syntax of presence stanzas as well as
P16L19	   their defined attributes and child elements, refer to [XMPP-CORE].
P16L20	
P16L21	5.1.  Client and Server Presence Responsibilities
P16L22	
P16L23	5.1.1.  Initial Presence
P16L24	
P16L25	   After establishing a session, a client SHOULD send initial presence
P16L26	   to the server in order to signal its availability for communications.
P16L27	   As defined herein, the initial presence stanza (1) MUST possess no
P16L28	   'to' address (signalling that it is meant to be broadcasted by the
P16L29	   server on behalf of the client) and (2) MUST possess no 'type'
P16L30	   attribute (signalling the user's availability).  After sending
P16L31	   initial presence, an active resource is said to be an "available
P16L32	   resource".
P16L33	
P16L34	   Upon receiving initial presence from a client, the user's server MUST
P16L35	   do the following if there is not already one or more available
P16L36	   resources for the user (if there is already one or more available
P16L37	   resources for the user, the server obviously does not need to send
P16L38	   the presence probes, since it already possesses the requisite
P16L39	   information):
P16L40	
P16L41	   1.  Send presence probes (i.e., presence stanzas whose 'type'
P16L42	       attribute is set to a value of "probe") from the full JID (e.g.,
P16L43	       <user@example.com/resource>) of the user to all contacts to which
P16L44	       the user is subscribed in order to determine if they are
P16L45	       available; such contacts are those for which a JID is present in
P16L46	       the user's roster with the 'subscription' attribute set to a
P16L47	       value of "to" or "both".  (Note: The user's server MUST NOT send
P16L48	       presence probes to contacts from which the user is blocking
P17L1	       inbound presence notifications, as described under Blocking
P17L2	       Inbound Presence Notifications (Section 10.10).)
P17L3	
P17L4	   2.  Broadcast initial presence from the full JID (e.g.,
P17L5	       <user@example.com/resource>) of the user to all contacts that are
P17L6	       subscribed to the user's presence information; such contacts are
P17L7	       those for which a JID is present in the user's roster with the
P17L8	       'subscription' attribute set to a value of "from" or "both".
P17L9	       (Note: The user's server MUST NOT broadcast initial presence to
P17L10	       contacts to which the user is blocking outbound presence
P17L11	       notifications, as described under Blocking Outbound Presence
P17L12	       Notifications (Section 10.11).)
P17L13	
P17L14	   In addition, the user's server MUST broadcast initial presence from
P17L15	   the user's new available resource to any of the user's existing
P17L16	   available resources (if any).
P17L17	
P17L18	   Upon receiving initial presence from the user, the contact's server
P17L19	   MUST deliver the user's presence stanza to the full JIDs
P17L20	   (<contact@example.org/resource>) associated with all of the contact's
P17L21	   available resources, but only if the user is in the contact's roster
P17L22	   with a subscription state of "to" or "both" and the contact has not
P17L23	   blocked inbound presence notifications from the user's bare or full
P17L24	   JID (as defined under Blocking Inbound Presence Notifications
P17L25	   (Section 10.10)).
P17L26	
P17L27	   If the user's server receives a presence stanza of type "error" in
P17L28	   response to the initial presence that it sent to a contact on behalf
P17L29	   of the user, it SHOULD NOT send further presence updates to that
P17L30	   contact (until and unless it receives a presence stanza from the
P17L31	   contact).
P17L32	
P17L33	5.1.2.  Presence Broadcast
P17L34	
P17L35	   After sending initial presence, the user MAY update its presence
P17L36	   information for broadcasting at any time during its session by
P17L37	   sending a presence stanza with no 'to' address and either no 'type'
P17L38	   attribute or a 'type' attribute with a value of "unavailable". (Note:
P17L39	   A user's client SHOULD NOT send a presence update to broadcast
P17L40	   information that changes independently of the user's presence and
P17L41	   availability.)
P17L42	
P17L43	   If the presence stanza lacks a 'type' attribute (i.e., expresses
P17L44	   availability), the user's server MUST broadcast the full XML of that
P17L45	   presence stanza to all contacts (1) that are in the user's roster
P17L46	   with a subscription type of "from" or "both", (2) to whom the user
P17L47	
P17L48	
P18L1	   has not blocked outbound presence notifications, and (3) from whom
P18L2	   the server has not received a presence error during the user's
P18L3	   session (as well as to any of the user's other available resources).
P18L4	
P18L5	   If the presence stanza has a 'type' attribute set to a value of
P18L6	   "unavailable", the user's server MUST broadcast the full XML of that
P18L7	   presence stanza to all entities that fit the above description, as
P18L8	   well as to any entities to which the user has sent directed available
P18L9	   presence during the user's session (if the user has not yet sent
P18L10	   directed unavailable presence to that entity).
P18L11	
P18L12	5.1.3.  Presence Probes
P18L13	
P18L14	   Upon receiving a presence probe from the user, the contact's server
P18L15	   SHOULD reply as follows:
P18L16	
P18L17	   1.  If the user is not in the contact's roster with a subscription
P18L18	       state of "From", "From + Pending Out", or "Both" (as defined
P18L19	       under Subscription States (Section 9)), the contact's server MUST
P18L20	       return a presence stanza of type "error" in response to the
P18L21	       presence probe (however, if a server receives a presence probe
P18L22	       from a subdomain of the server's hostname or another such trusted
P18L23	       service, it MAY provide presence information about the user to
P18L24	       that entity).  Specifically:
P18L25	
P18L26	       *  if the user is in the contact's roster with a subscription
P18L27	          state of "None", "None + Pending Out", or "To" (or is not in
P18L28	          the contact's roster at all), the contact's server MUST return
P18L29	          a <forbidden/> stanza error in response to the presence probe.
P18L30	
P18L31	       *  if the user is in the contact's roster with a subscription
P18L32	          state of "None + Pending In", "None + Pending Out/In", or "To
P18L33	          + Pending In", the contact's server MUST return a
P18L34	          <not-authorized/> stanza error in response to the presence
P18L35	          probe.
P18L36	
P18L37	   2.  Else, if the contact is blocking presence notifications to the
P18L38	       user's bare JID or full JID (using either a default list or
P18L39	       active list as defined under Blocking Outbound Presence
P18L40	       Notifications (Section 10.11)), the server MUST NOT reply to the
P18L41	       presence probe.
P18L42	
P18L43	   3.  Else, if the contact has no available resources, the server MUST
P18L44	       either (1) reply to the presence probe by sending to the user the
P18L45	       full XML of the last presence stanza of type "unavailable"
P18L46	       received by the server from the contact, or (2) not reply at all.
P18L47	
P18L48	
P19L1	   4.  Else, if the contact has at least one available resource, the
P19L2	       server MUST reply to the presence probe by sending to the user
P19L3	       the full XML of the last presence stanza with no 'to' attribute
P19L4	       received by the server from each of the contact's available
P19L5	       resources (again, subject to privacy lists in force for each
P19L6	       session).
P19L7	
P19L8	5.1.4.  Directed Presence
P19L9	
P19L10	   A user MAY send directed presence to another entity (i.e., a presence
P19L11	   stanza with a 'to' attribute whose value is the JID of the other
P19L12	   entity and with either no 'type' attribute or a 'type' attribute
P19L13	   whose value is "unavailable").  There are three possible cases:
P19L14	
P19L15	   1.  If the user sends directed presence to a contact that is in the
P19L16	       user's roster with a subscription type of "from" or "both" after
P19L17	       having sent initial presence and before sending unavailable
P19L18	       presence broadcast, the user's server MUST route or deliver the
P19L19	       full XML of that presence stanza (subject to privacy lists) but
P19L20	       SHOULD NOT otherwise modify the contact's status regarding
P19L21	       presence broadcast (i.e., it SHOULD include the contact's JID in
P19L22	       any subsequent presence broadcasts initiated by the user).
P19L23	
P19L24	   2.  If the user sends directed presence to an entity that is not in
P19L25	       the user's roster with a subscription type of "from" or "both"
P19L26	       after having sent initial presence and before sending unavailable
P19L27	       presence broadcast, the user's server MUST route or deliver the
P19L28	       full XML of that presence stanza to the entity but MUST NOT
P19L29	       modify the contact's status regarding available presence
P19L30	       broadcast (i.e., it MUST NOT include the entity's JID in any
P19L31	       subsequent broadcasts of available presence initiated by the
P19L32	       user); however, if the available resource from which the user
P19L33	       sent the directed presence become unavailable, the user's server
P19L34	       MUST broadcast that unavailable presence to the entity (if the
P19L35	       user has not yet sent directed unavailable presence to that
P19L36	       entity).
P19L37	
P19L38	   3.  If the user sends directed presence without first sending initial
P19L39	       presence or after having sent unavailable presence broadcast
P19L40	       (i.e., the resource is active but not available), the user's
P19L41	       server MUST treat the entities to which the user sends directed
P19L42	       presence in the same way that it treats the entities listed in
P19L43	       case #2 above.
P19L44	
P19L45	
P19L46	
P19L47	
P19L48	
P20L1	5.1.5.  Unavailable Presence
P20L2	
P20L3	   Before ending its session with a server, a client SHOULD gracefully
P20L4	   become unavailable by sending a final presence stanza that possesses
P20L5	   no 'to' attribute and that possesses a 'type' attribute whose value
P20L6	   is "unavailable" (optionally, the final presence stanza MAY contain
P20L7	   one or more <status/> elements specifying the reason why the user is
P20L8	   no longer available).  However, the user's server MUST NOT depend on
P20L9	   receiving final presence from an available resource, since the
P20L10	   resource may become unavailable unexpectedly or may be timed out by
P20L11	   the server.  If one of the user's resources becomes unavailable for
P20L12	   any reason (either gracefully or ungracefully), the user's server
P20L13	   MUST broadcast unavailable presence to all contacts (1) that are in
P20L14	   the user's roster with a subscription type of "from" or "both", (2)
P20L15	   to whom the user has not blocked outbound presence, and (3) from whom
P20L16	   the server has not received a presence error during the user's
P20L17	   session; the user's server MUST also send that unavailable presence
P20L18	   stanza to any of the user's other available resources, as well as to
P20L19	   any entities to which the user has sent directed presence during the
P20L20	   user's session for that resource (if the user has not yet sent
P20L21	   directed unavailable presence to that entity).  Any presence stanza
P20L22	   with no 'type' attribute and no 'to' attribute that is sent after
P20L23	   sending directed unavailable presence or broadcasted unavailable
P20L24	   presence MUST be broadcasted by the server to all subscribers.
P20L25	
P20L26	5.1.6.  Presence Subscriptions
P20L27	
P20L28	   A subscription request is a presence stanza whose 'type' attribute
P20L29	   has a value of "subscribe".  If the subscription request is being
P20L30	   sent to an instant messaging contact, the JID supplied in the 'to'
P20L31	   attribute SHOULD be of the form <contact@example.org> rather than
P20L32	   <contact@example.org/resource>, since the desired result is normally
P20L33	   for the user to receive presence from all of the contact's resources,
P20L34	   not merely the particular resource specified in the 'to' attribute.
P20L35	
P20L36	   A user's server MUST NOT automatically approve subscription requests
P20L37	   on the user's behalf.  All subscription requests MUST be directed to
P20L38	   the user's client, specifically to one or more available resources
P20L39	   associated with the user.  If there is no available resource
P20L40	   associated with the user when the subscription request is received by
P20L41	   the user's server, the user's server MUST keep a record of the
P20L42	   subscription request and deliver the request when the user next
P20L43	   creates an available resource, until the user either approves or
P20L44	   denies the request.  If there is more than one available resource
P20L45	   associated with the user when the subscription request is received by
P20L46	   the user's server, the user's server MUST broadcast that subscription
P20L47	   request to all available resources in accordance with Server Rules
P20L48	   for Handling XML Stanzas (Section 11).  (Note: If an active resource
P21L1	   has not provided initial presence, the server MUST NOT consider it to
P21L2	   be available and therefore MUST NOT send subscription requests to
P21L3	   it.)   However, if the user receives a presence stanza of type
P21L4	   "subscribe" from a contact to whom the user has already granted
P21L5	   permission to see the user's presence information (e.g., in cases
P21L6	   when the contact is seeking to resynchronize subscription states),
P21L7	   the user's server SHOULD auto-reply on behalf of the user.  In
P21L8	   addition, the user's server MAY choose to re-send an unapproved
P21L9	   pending subscription request to the contact based on an
P21L10	   implementation-specific algorithm (e.g., whenever a new resource
P21L11	   becomes available for the user, or after a certain amount of time has
P21L12	   elapsed); this helps to recover from transient, silent errors that
P21L13	   may have occurred in relation to the original subscription request.
P21L14	
P21L15	5.2.  Specifying Availability Status
P21L16	
P21L17	   A client MAY provide further information about its availability
P21L18	   status by using the <show/> element (see Show (Section 2.2.2.1)).
P21L19	
P21L20	   Example: Availability status:
P21L21	
P21L22	   <presence>
P21L23	     <show>dnd</show>
P21L24	   </presence>
P21L25	
P21L26	5.3.  Specifying Detailed Status Information
P21L27	
P21L28	   In conjunction with the <show/> element, a client MAY provide
P21L29	   detailed status information by using the <status/> element (see
P21L30	   Status (Section 2.2.2.2)).
P21L31	
P21L32	   Example: Detailed status information:
P21L33	
P21L34	   <presence xml:lang='en'>
P21L35	     <show>dnd</show>
P21L36	     <status>Wooing Juliet</status>
P21L37	     <status xml:lang='cz'>Ja dvo&#x0159;&#x00ED;m Juliet</status>
P21L38	   </presence>
P21L39	
P21L40	
P21L41	
P21L42	
P21L43	
P21L44	
P21L45	
P21L46	
P21L47	
P21L48	
P22L1	5.4.  Specifying Presence Priority
P22L2	
P22L3	   A client MAY provide a priority for its resource by using the
P22L4	   <priority/> element (see Priority (Section 2.2.2.3)).
P22L5	
P22L6	   Example: Presence priority:
P22L7	
P22L8	   <presence xml:lang='en'>
P22L9	     <show>dnd</show>
P22L10	     <status>Wooing Juliet</status>
P22L11	     <status xml:lang='cz'>Ja dvo&#x0159;&#x00ED;m Juliet</status>
P22L12	     <priority>1</priority>
P22L13	   </presence>
P22L14	
P22L15	5.5.  Presence Examples
P22L16	
P22L17	   The examples in this section illustrate the presence-related
P22L18	   protocols described above.  The user is romeo@example.net, he has an
P22L19	   available resource whose resource identifier is "orchard", and he has
P22L20	   the following individuals in his roster:
P22L21	
P22L22	   o  juliet@example.com (subscription="both" and she has two available
P22L23	      resources, one whose resource is "chamber" and another whose
P22L24	      resource is "balcony")
P22L25	
P22L26	   o  benvolio@example.org (subscription="to")
P22L27	
P22L28	   o  mercutio@example.org (subscription="from")
P22L29	
P22L30	   Example 1: User sends initial presence:
P22L31	
P22L32	   <presence/>
P22L33	
P22L34	   Example 2: User's server sends presence probes to contacts with
P22L35	   subscription="to" and subscription="both" on behalf of the user's
P22L36	   available resource:
P22L37	
P22L38	   <presence
P22L39	       type='probe'
P22L40	       from='romeo@example.net/orchard'
P22L41	       to='juliet@example.com'/>
P22L42	
P22L43	   <presence
P22L44	       type='probe'
P22L45	       from='romeo@example.net/orchard'
P22L46	       to='benvolio@example.org'/>
P22L47	
P22L48	
P23L1	   Example 3: User's server sends initial presence to contacts with
P23L2	   subscription="from" and subscription="both" on behalf of the user's
P23L3	   available resource:
P23L4	
P23L5	   <presence
P23L6	       from='romeo@example.net/orchard'
P23L7	       to='juliet@example.com'/>
P23L8	
P23L9	   <presence
P23L10	       from='romeo@example.net/orchard'
P23L11	       to='mercutio@example.org'/>
P23L12	
P23L13	   Example 4: Contacts' servers reply to presence probe on behalf of all
P23L14	   available resources:
P23L15	
P23L16	   <presence
P23L17	       from='juliet@example.com/balcony'
P23L18	       to='romeo@example.net/orchard'
P23L19	       xml:lang='en'>
P23L20	     <show>away</show>
P23L21	     <status>be right back</status>
P23L22	     <priority>0</priority>
P23L23	   </presence>
P23L24	
P23L25	   <presence
P23L26	       from='juliet@example.com/chamber'
P23L27	       to='romeo@example.net/orchard'>
P23L28	     <priority>1</priority>
P23L29	   </presence>
P23L30	
P23L31	   <presence
P23L32	       from='benvolio@example.org/pda'
P23L33	       to='romeo@example.net/orchard'
P23L34	       xml:lang='en'>
P23L35	     <show>dnd</show>
P23L36	     <status>gallivanting</status>
P23L37	   </presence>
P23L38	
P23L39	   Example 5: Contacts' servers deliver user's initial presence to all
P23L40	   available resources or return error to user:
P23L41	
P23L42	   <presence
P23L43	       from='romeo@example.net/orchard'
P23L44	       to='juliet@example.com/chamber'/>
P23L45	
P23L46	
P23L47	
P23L48	
P24L1	   <presence
P24L2	       from='romeo@example.net/orchard'
P24L3	       to='juliet@example.com/balcony'/>
P24L4	
P24L5	   <presence
P24L6	       type='error'
P24L7	       from='mercutio@example.org'
P24L8	       to='romeo@example.net/orchard'>
P24L9	     <error type='cancel'>
P24L10	       <gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P24L11	     </error>
P24L12	   </presence>
P24L13	
P24L14	   Example 6: User sends directed presence to another user not in his
P24L15	   roster:
P24L16	
P24L17	   <presence
P24L18	       from='romeo@example.net/orchard'
P24L19	       to='nurse@example.com'
P24L20	       xml:lang='en'>
P24L21	     <show>dnd</show>
P24L22	     <status>courting Juliet</status>
P24L23	     <priority>0</priority>
P24L24	   </presence>
P24L25	
P24L26	   Example 7: User sends updated available presence information for
P24L27	   broadcasting:
P24L28	
P24L29	   <presence xml:lang='en'>
P24L30	     <show>away</show>
P24L31	     <status>I shall return!</status>
P24L32	     <priority>1</priority>
P24L33	   </presence>
P24L34	
P24L35	   Example 8: User's server broadcasts updated presence information only
P24L36	   to one contact (not those from whom an error was received or to whom
P24L37	   the user sent directed presence):
P24L38	
P24L39	   <presence
P24L40	       from='romeo@example.net/orchard'
P24L41	       to='juliet@example.com'
P24L42	       xml:lang='en'>
P24L43	     <show>away</show>
P24L44	     <status>I shall return!</status>
P24L45	     <priority>1</priority>
P24L46	   </presence>
P24L47	
P24L48	
P25L1	   Example 9: Contact's server delivers updated presence information to
P25L2	   all of the contact's available resources:
P25L3	
P25L4	   [to "balcony" resource...]
P25L5	   <presence
P25L6	       from='romeo@example.net/orchard'
P25L7	       to='juliet@example.com'
P25L8	       xml:lang='en'>
P25L9	     <show>away</show>
P25L10	     <status>I shall return!</status>
P25L11	     <priority>1</priority>
P25L12	   </presence>
P25L13	
P25L14	   [to "chamber" resource...]
P25L15	   <presence
P25L16	       from='romeo@example.net/orchard'
P25L17	       to='juliet@example.com'
P25L18	       xml:lang='en'>
P25L19	     <show>away</show>
P25L20	     <status>I shall return!</status>
P25L21	     <priority>1</priority>
P25L22	   </presence>
P25L23	
P25L24	   Example 10: One of the contact's resources broadcasts final presence:
P25L25	
P25L26	   <presence from='juliet@example.com/balcony' type='unavailable'/>
P25L27	
P25L28	   Example 11: Contact's server sends unavailable presence information
P25L29	   to user:
P25L30	
P25L31	   <presence
P25L32	       type='unavailable'
P25L33	       from='juliet@example.com/balcony'
P25L34	       to='romeo@example.net/orchard'/>
P25L35	
P25L36	   Example 12: User sends final presence:
P25L37	
P25L38	   <presence from='romeo@example.net/orchard'
P25L39	             type='unavailable'
P25L40	             xml:lang='en'>
P25L41	     <status>gone home</status>
P25L42	   </presence>
P25L43	
P25L44	
P25L45	
P25L46	
P25L47	
P25L48	
P26L1	   Example 13: User's server broadcasts unavailable presence information
P26L2	   to contact as well as to the person to whom the user sent directed
P26L3	   presence:
P26L4	
P26L5	   <presence
P26L6	       type='unavailable'
P26L7	       from='romeo@example.net/orchard'
P26L8	       to='juliet@example.com'
P26L9	       xml:lang='en'>
P26L10	     <status>gone home</status>
P26L11	   </presence>
P26L12	
P26L13	   <presence
P26L14	       from='romeo@example.net/orchard'
P26L15	       to='nurse@example.com'
P26L16	       xml:lang='en'>
P26L17	     <status>gone home</status>
P26L18	   </presence>
P26L19	
P26L20	6.  Managing Subscriptions
P26L21	
P26L22	   In order to protect the privacy of instant messaging users and any
P26L23	   other entities, presence and availability information is disclosed
P26L24	   only to other entities that the user has approved.  When a user has
P26L25	   agreed that another entity may view its presence, the entity is said
P26L26	   to have a subscription to the user's presence information.  A
P26L27	   subscription lasts across sessions; indeed, it lasts until the
P26L28	   subscriber unsubscribes or the subscribee cancels the
P26L29	   previously-granted subscription.  Subscriptions are managed within
P26L30	   XMPP by sending presence stanzas containing specially-defined
P26L31	   attributes.
P26L32	
P26L33	   Note: There are important interactions between subscriptions and
P26L34	   rosters; these are defined under Integration of Roster Items and
P26L35	   Presence Subscriptions (Section 8), and the reader must refer to that
P26L36	   section for a complete understanding of presence subscriptions.
P26L37	
P26L38	6.1.  Requesting a Subscription
P26L39	
P26L40	   A request to subscribe to another entity's presence is made by
P26L41	   sending a presence stanza of type "subscribe".
P26L42	
P26L43	   Example: Sending a subscription request:
P26L44	
P26L45	   <presence to='juliet@example.com' type='subscribe'/>
P26L46	
P26L47	
P26L48	
P27L1	   For client and server responsibilities regarding presence
P27L2	   subscription requests, refer to Presence Subscriptions (Section
P27L3	   5.1.6).
P27L4	
P27L5	6.2.  Handling a Subscription Request
P27L6	
P27L7	   When a client receives a subscription request from another entity, it
P27L8	   MUST either approve the request by sending a presence stanza of type
P27L9	   "subscribed" or refuse the request by sending a presence stanza of
P27L10	   type "unsubscribed".
P27L11	
P27L12	   Example: Approving a subscription request:
P27L13	
P27L14	   <presence to='romeo@example.net' type='subscribed'/>
P27L15	
P27L16	   Example: Refusing a presence subscription request:
P27L17	
P27L18	   <presence to='romeo@example.net' type='unsubscribed'/>
P27L19	
P27L20	6.3.  Cancelling a Subscription from Another Entity
P27L21	
P27L22	   If a user would like to cancel a previously-granted subscription
P27L23	   request, it sends a presence stanza of type "unsubscribed".
P27L24	
P27L25	   Example: Cancelling a previously granted subscription request:
P27L26	
P27L27	   <presence to='romeo@example.net' type='unsubscribed'/>
P27L28	
P27L29	6.4.  Unsubscribing from Another Entity's Presence
P27L30	
P27L31	   If a user would like to unsubscribe from the presence of another
P27L32	   entity, it sends a presence stanza of type "unsubscribe".
P27L33	
P27L34	   Example: Unsubscribing from an entity's presence:
P27L35	
P27L36	   <presence to='juliet@example.com' type='unsubscribe'/>
P27L37	
P27L38	7.  Roster Management
P27L39	
P27L40	   In XMPP, one's contact list is called a roster, which consists of any
P27L41	   number of specific roster items, each roster item being identified by
P27L42	   a unique JID (usually of the form <contact@domain>).  A user's roster
P27L43	   is stored by the user's server on the user's behalf so that the user
P27L44	   may access roster information from any resource.
P27L45	
P27L46	
P27L47	
P27L48	
P28L1	   Note: There are important interactions between rosters and
P28L2	   subscriptions; these are defined under Integration of Roster Items
P28L3	   and Presence Subscriptions (Section 8), and the reader must refer to
P28L4	   that section for a complete understanding of roster management.
P28L5	
P28L6	7.1.  Syntax and Semantics
P28L7	
P28L8	   Rosters are managed using IQ stanzas, specifically by means of a
P28L9	   <query/> child element qualified by the 'jabber:iq:roster' namespace.
P28L10	   The <query/> element MAY contain one or more <item/> children, each
P28L11	   describing a unique roster item or "contact".
P28L12	
P28L13	   The "key" or unique identifier for each roster item is a JID,
P28L14	   encapsulated in the 'jid' attribute of the <item/> element (which is
P28L15	   REQUIRED).  The value of the 'jid' attribute SHOULD be of the form
P28L16	   <user@domain> if the item is associated with another (human) instant
P28L17	   messaging user.
P28L18	
P28L19	   The state of the presence subscription in relation to a roster item
P28L20	   is captured in the 'subscription' attribute of the <item/> element.
P28L21	   Allowable values for this attribute are:
P28L22	
P28L23	   o  "none" -- the user does not have a subscription to the contact's
P28L24	      presence information, and the contact does not have a subscription
P28L25	      to the user's presence information
P28L26	
P28L27	   o  "to" -- the user has a subscription to the contact's presence
P28L28	      information, but the contact does not have a subscription to the
P28L29	      user's presence information
P28L30	
P28L31	   o  "from" -- the contact has a subscription to the user's presence
P28L32	      information, but the user does not have a subscription to the
P28L33	      contact's presence information
P28L34	
P28L35	   o  "both" -- both the user and the contact have subscriptions to each
P28L36	      other's presence information
P28L37	
P28L38	   Each <item/> element MAY contain a 'name' attribute, which sets the
P28L39	   "nickname" to be associated with the JID, as determined by the user
P28L40	   (not the contact).  The value of the 'name' attribute is opaque.
P28L41	
P28L42	   Each <item/> element MAY contain one or more <group/> child elements,
P28L43	   for use in collecting roster items into various categories.  The XML
P28L44	   character data of the <group/> element is opaque.
P28L45	
P28L46	
P28L47	
P28L48	
P29L1	7.2.  Business Rules
P29L2	
P29L3	   A server MUST ignore any 'to' address on a roster "set", and MUST
P29L4	   treat any roster "set" as applying to the sender.  For added safety,
P29L5	   a client SHOULD check the "from" address of a "roster push" (incoming
P29L6	   IQ of type "set" containing a roster item) to ensure that it is from
P29L7	   a trusted source; specifically, the stanza MUST either have no 'from'
P29L8	   attribute (i.e., implicitly from the server) or have a 'from'
P29L9	   attribute whose value matches the user's bare JID (of the form
P29L10	   <user@domain>) or full JID (of the form <user@domain/resource>);
P29L11	   otherwise, the client SHOULD ignore the "roster push".
P29L12	
P29L13	7.3.  Retrieving One's Roster on Login
P29L14	
P29L15	   Upon connecting to the server and becoming an active resource, a
P29L16	   client SHOULD request the roster before sending initial presence
P29L17	   (however, because receiving the roster may not be desirable for all
P29L18	   resources, e.g., a connection with limited bandwidth, the client's
P29L19	   request for the roster is OPTIONAL).  If an available resource does
P29L20	   not request the roster during a session, the server MUST NOT send it
P29L21	   presence subscriptions and associated roster updates.
P29L22	
P29L23	   Example: Client requests current roster from server:
P29L24	
P29L25	   <iq from='juliet@example.com/balcony' type='get' id='roster_1'>
P29L26	     <query xmlns='jabber:iq:roster'/>
P29L27	   </iq>
P29L28	
P29L29	   Example: Client receives roster from server:
P29L30	
P29L31	   <iq to='juliet@example.com/balcony' type='result' id='roster_1'>
P29L32	     <query xmlns='jabber:iq:roster'>
P29L33	       <item jid='romeo@example.net'
P29L34	             name='Romeo'
P29L35	             subscription='both'>
P29L36	         <group>Friends</group>
P29L37	       </item>
P29L38	       <item jid='mercutio@example.org'
P29L39	             name='Mercutio'
P29L40	             subscription='from'>
P29L41	         <group>Friends</group>
P29L42	       </item>
P29L43	       <item jid='benvolio@example.org'
P29L44	             name='Benvolio'
P29L45	             subscription='both'>
P29L46	         <group>Friends</group>
P29L47	       </item>
P29L48	     </query>
P30L1	   </iq>
P30L2	
P30L3	7.4.  Adding a Roster Item
P30L4	
P30L5	   At any time, a user MAY add an item to his or her roster.
P30L6	
P30L7	   Example: Client adds a new item:
P30L8	
P30L9	   <iq from='juliet@example.com/balcony' type='set' id='roster_2'>
P30L10	     <query xmlns='jabber:iq:roster'>
P30L11	       <item jid='nurse@example.com'
P30L12	             name='Nurse'>
P30L13	         <group>Servants</group>
P30L14	       </item>
P30L15	     </query>
P30L16	   </iq>
P30L17	
P30L18	   The server MUST update the roster information in persistent storage,
P30L19	   and also push the change out to all of the user's available resources
P30L20	   that have requested the roster.  This "roster push" consists of an IQ
P30L21	   stanza of type "set" from the server to the client and enables all
P30L22	   available resources to remain in sync with the server-based roster
P30L23	   information.
P30L24	
P30L25	   Example: Server (1) pushes the updated roster information to all
P30L26	   available resources that have requested the roster and (2) replies
P30L27	   with an IQ result to the sending resource:
P30L28	
P30L29	   <iq to='juliet@example.com/balcony'
P30L30	       type='set'
P30L31	       id='a78b4q6ha463'>
P30L32	     <query xmlns='jabber:iq:roster'>
P30L33	       <item jid='nurse@example.com'
P30L34	             name='Nurse'
P30L35	             subscription='none'>
P30L36	         <group>Servants</group>
P30L37	       </item>
P30L38	     </query>
P30L39	   </iq>
P30L40	
P30L41	   <iq to='juliet@example.com/chamber'
P30L42	       type='set'
P30L43	       id='a78b4q6ha464'>
P30L44	     <query xmlns='jabber:iq:roster'>
P30L45	       <item jid='nurse@example.com'
P30L46	             name='Nurse'
P30L47	             subscription='none'>
P30L48	         <group>Servants</group>
P31L1	       </item>
P31L2	     </query>
P31L3	   </iq>
P31L4	
P31L5	   <iq to='juliet@example.com/balcony' type='result' id='roster_2'/>
P31L6	
P31L7	   As required by the semantics of the IQ stanza kind as defined in
P31L8	   [XMPP-CORE], each resource that received the roster push MUST reply
P31L9	   with an IQ stanza of type "result" (or "error").
P31L10	
P31L11	   Example: Resources reply with an IQ result to the server:
P31L12	
P31L13	   <iq from='juliet@example.com/balcony'
P31L14	       to='example.com'
P31L15	       type='result'
P31L16	       id='a78b4q6ha463'/>
P31L17	   <iq from='juliet@example.com/chamber'
P31L18	       to='example.com'
P31L19	       type='result'
P31L20	       id='a78b4q6ha464'/>
P31L21	
P31L22	7.5.  Updating a Roster Item
P31L23	
P31L24	   Updating an existing roster item (e.g., changing the group) is done
P31L25	   in the same way as adding a new roster item, i.e., by sending the
P31L26	   roster item in an IQ set to the server.
P31L27	
P31L28	   Example: User updates roster item (added group):
P31L29	
P31L30	   <iq from='juliet@example.com/chamber' type='set' id='roster_3'>
P31L31	     <query xmlns='jabber:iq:roster'>
P31L32	       <item jid='romeo@example.net'
P31L33	             name='Romeo'
P31L34	             subscription='both'>
P31L35	         <group>Friends</group>
P31L36	         <group>Lovers</group>
P31L37	       </item>
P31L38	     </query>
P31L39	   </iq>
P31L40	
P31L41	   As with adding a roster item, when updating a roster item the server
P31L42	   MUST update the roster information in persistent storage, and also
P31L43	   initiate a roster push to all of the user's available resources that
P31L44	   have requested the roster.
P31L45	
P31L46	
P31L47	
P31L48	
P32L1	7.6.  Deleting a Roster Item
P32L2	
P32L3	   At any time, a user MAY delete an item from his or her roster by
P32L4	   sending an IQ set to the server and making sure that the value of the
P32L5	   'subscription' attribute is "remove" (a compliant server MUST ignore
P32L6	   any other values of the 'subscription' attribute when received from a
P32L7	   client).
P32L8	
P32L9	   Example: Client removes an item:
P32L10	
P32L11	   <iq from='juliet@example.com/balcony' type='set' id='roster_4'>
P32L12	     <query xmlns='jabber:iq:roster'>
P32L13	       <item jid='nurse@example.com' subscription='remove'/>
P32L14	     </query>
P32L15	   </iq>
P32L16	
P32L17	   As with adding a roster item, when deleting a roster item the server
P32L18	   MUST update the roster information in persistent storage, initiate a
P32L19	   roster push to all of the user's available resources that have
P32L20	   requested the roster (with the 'subscription' attribute set to a
P32L21	   value of "remove"), and send an IQ result to the initiating resource.
P32L22	
P32L23	   For further information about the implications of this command, see
P32L24	   Removing a Roster Item and Cancelling All Subscriptions (Section
P32L25	   8.6).
P32L26	
P32L27	8.  Integration of Roster Items and Presence Subscriptions
P32L28	
P32L29	8.1.  Overview
P32L30	
P32L31	   Some level of integration between roster items and presence
P32L32	   subscriptions is normally expected by an instant messaging user
P32L33	   regarding the user's subscriptions to and from other contacts.  This
P32L34	   section describes the level of integration that MUST be supported
P32L35	   within XMPP instant messaging applications.
P32L36	
P32L37	   There are four primary subscription states:
P32L38	
P32L39	   o  None -- the user does not have a subscription to the contact's
P32L40	      presence information, and the contact does not have a subscription
P32L41	      to the user's presence information
P32L42	
P32L43	
P32L44	
P32L45	
P32L46	
P32L47	
P32L48	
P33L1	   o  To -- the user has a subscription to the contact's presence
P33L2	      information, but the contact does not have a subscription to the
P33L3	      user's presence information
P33L4	
P33L5	   o  From -- the contact has a subscription to the user's presence
P33L6	      information, but the user does not have a subscription to the
P33L7	      contact's presence information
P33L8	
P33L9	   o  Both -- both the user and the contact have subscriptions to each
P33L10	      other's presence information (i.e., the union of 'from' and 'to')
P33L11	
P33L12	   Each of these states is reflected in the roster of both the user and
P33L13	   the contact, thus resulting in durable subscription states.
P33L14	
P33L15	   Narrative explanations of how these subscription states interact with
P33L16	   roster items in order to complete certain defined use cases are
P33L17	   provided in the following sub-sections.  Full details regarding
P33L18	   server and client handling of all subscription states (including
P33L19	   pending states between the primary states listed above) is provided
P33L20	   in Subscription States (Section 9).
P33L21	
P33L22	   The server MUST NOT send presence subscription requests or roster
P33L23	   pushes to unavailable resources, nor to available resources that have
P33L24	   not requested the roster.
P33L25	
P33L26	   The 'from' and 'to' addresses are OPTIONAL in roster pushes; if
P33L27	   included, their values SHOULD be the full JID of the resource for
P33L28	   that session.  A client MUST acknowledge each roster push with an IQ
P33L29	   stanza of type "result" (for the sake of brevity, these stanzas are
P33L30	   not shown in the following examples but are required by the IQ
P33L31	   semantics defined in [XMPP-CORE]).
P33L32	
P33L33	8.2.  User Subscribes to Contact
P33L34	
P33L35	   The process by which a user subscribes to a contact, including the
P33L36	   interaction between roster items and subscription states, is
P33L37	   described below.
P33L38	
P33L39	   1.  In preparation for being able to render the contact in the user's
P33L40	       client interface and for the server to keep track of the
P33L41	       subscription, the user's client SHOULD perform a "roster set" for
P33L42	       the new roster item.  This request consists of sending an IQ
P33L43	       stanza of type='set' containing a <query/> element qualified by
P33L44	       the 'jabber:iq:roster' namespace, which in turn contains an
P33L45	       <item/> element that defines the new roster item; the <item/>
P33L46	       element MUST possess a 'jid' attribute, MAY possess a 'name'
P33L47	       attribute, MUST NOT possess a 'subscription' attribute, and MAY
P33L48	       contain one or more <group/> child elements:
P34L1	   <iq type='set' id='set1'>
P34L2	     <query xmlns='jabber:iq:roster'>
P34L3	       <item
P34L4	           jid='contact@example.org'
P34L5	           name='MyContact'>
P34L6	         <group>MyBuddies</group>
P34L7	       </item>
P34L8	     </query>
P34L9	   </iq>
P34L10	
P34L11	   2.  As a result, the user's server (1) MUST initiate a roster push
P34L12	       for the new roster item to all available resources associated
P34L13	       with this user that have requested the roster, setting the
P34L14	       'subscription' attribute to a value of "none"; and (2) MUST reply
P34L15	       to the sending resource with an IQ result indicating the success
P34L16	       of the roster set:
P34L17	
P34L18	   <iq type='set'>
P34L19	     <query xmlns='jabber:iq:roster'>
P34L20	       <item
P34L21	           jid='contact@example.org'
P34L22	           subscription='none'
P34L23	           name='MyContact'>
P34L24	         <group>MyBuddies</group>
P34L25	       </item>
P34L26	     </query>
P34L27	   </iq>
P34L28	
P34L29	   <iq type='result' id='set1'/>
P34L30	
P34L31	   3.  If the user wants to request a subscription to the contact's
P34L32	       presence information, the user's client MUST send a presence
P34L33	       stanza of type='subscribe' to the contact:
P34L34	
P34L35	   <presence to='contact@example.org' type='subscribe'/>
P34L36	
P34L37	   4.  As a result, the user's server MUST initiate a second roster push
P34L38	       to all of the user's available resources that have requested the
P34L39	       roster, setting the contact to the pending sub-state of the
P34L40	       'none' subscription state; this pending sub-state is denoted by
P34L41	       the inclusion of the ask='subscribe' attribute in the roster
P34L42	       item:
P34L43	
P34L44	
P34L45	
P34L46	
P34L47	
P34L48	
P35L1	   <iq type='set'>
P35L2	     <query xmlns='jabber:iq:roster'>
P35L3	       <item
P35L4	           jid='contact@example.org'
P35L5	           subscription='none'
P35L6	           ask='subscribe'
P35L7	           name='MyContact'>
P35L8	         <group>MyBuddies</group>
P35L9	       </item>
P35L10	     </query>
P35L11	   </iq>
P35L12	
P35L13	   Note: If the user did not create a roster item before sending the
P35L14	   subscription request, the server MUST now create one on behalf of the
P35L15	   user, then send a roster push to all of the user's available
P35L16	   resources that have requested the roster, absent the 'name' attribute
P35L17	   and the <group/> child shown above.
P35L18	
P35L19	   5.  The user's server MUST also stamp the presence stanza of type
P35L20	       "subscribe" with the user's bare JID (i.e., <user@example.com>)
P35L21	       as the 'from' address (if the user provided a 'from' address set
P35L22	       to the user's full JID, the server SHOULD remove the resource
P35L23	       identifier).  If the contact is served by a different host than
P35L24	       the user, the user's server MUST route the presence stanza to the
P35L25	       contact's server for delivery to the contact (this case is
P35L26	       assumed throughout; however, if the contact is served by the same
P35L27	       host, then the server can simply deliver the presence stanza
P35L28	       directly):
P35L29	
P35L30	   <presence
P35L31	       from='user@example.com'
P35L32	       to='contact@example.org'
P35L33	       type='subscribe'/>
P35L34	
P35L35	   Note: If the user's server receives a presence stanza of type "error"
P35L36	   from the contact's server, it MUST deliver the error stanza to the
P35L37	   user, whose client MAY determine that the error is in response to the
P35L38	   outgoing presence stanza of type "subscribe" it sent previously
P35L39	   (e.g., by tracking an 'id' attribute) and then choose to resend the
P35L40	   "subscribe" request or revert the roster to its previous state by
P35L41	   sending a presence stanza of type "unsubscribe" to the contact.
P35L42	
P35L43	   6.  Upon receiving the presence stanza of type "subscribe" addressed
P35L44	       to the contact, the contact's server MUST determine if there is
P35L45	       at least one available resource from which the contact has
P35L46	       requested the roster.  If so, it MUST deliver the subscription
P35L47	       request to the contact (if not, the contact's server MUST store
P35L48	       the subscription request offline for delivery when this condition
P36L1	       is next met; normally this is done by adding a roster item for
P36L2	       the contact to the user's roster, with a state of "None + Pending
P36L3	       In" as defined under Subscription States (Section 9), however a
P36L4	       server SHOULD NOT push or deliver roster items in that state to
P36L5	       the contact).  No matter when the subscription request is
P36L6	       delivered, the contact must decide whether or not to approve it
P36L7	       (subject to the contact's configured preferences, the contact's
P36L8	       client MAY approve or refuse the subscription request without
P36L9	       presenting it to the contact).  Here we assume the "happy path"
P36L10	       that the contact approves the subscription request (the alternate
P36L11	       flow of declining the subscription request is defined in Section
P36L12	       8.2.1).  In this case, the contact's client (1) SHOULD perform a
P36L13	       roster set specifying the desired nickname and group for the user
P36L14	       (if any); and (2) MUST send a presence stanza of type
P36L15	       "subscribed" to the user in order to approve the subscription
P36L16	       request.
P36L17	
P36L18	   <iq type='set' id='set2'>
P36L19	     <query xmlns='jabber:iq:roster'>
P36L20	       <item
P36L21	           jid='user@example.com'
P36L22	           name='SomeUser'>
P36L23	         <group>SomeGroup</group>
P36L24	       </item>
P36L25	     </query>
P36L26	   </iq>
P36L27	
P36L28	   <presence to='user@example.com' type='subscribed'/>
P36L29	
P36L30	   7.  As a result, the contact's server (1) MUST initiate a roster push
P36L31	       to all available resources associated with the contact that have
P36L32	       requested the roster, containing a roster item for the user with
P36L33	       the subscription state set to 'from' (the server MUST send this
P36L34	       even if the contact did not perform a roster set); (2) MUST
P36L35	       return an IQ result to the sending resource indicating the
P36L36	       success of the roster set; (3) MUST route the presence stanza of
P36L37	       type "subscribed" to the user, first stamping the 'from' address
P36L38	       as the bare JID (<contact@example.org>) of the contact; and (4)
P36L39	       MUST send available presence from all of the contact's available
P36L40	       resources to the user:
P36L41	
P36L42	
P36L43	
P36L44	
P36L45	
P36L46	
P36L47	
P36L48	
P37L1	   <iq type='set' to='contact@example.org/resource'>
P37L2	     <query xmlns='jabber:iq:roster'>
P37L3	       <item
P37L4	           jid='user@example.com'
P37L5	           subscription='from'
P37L6	           name='SomeUser'>
P37L7	         <group>SomeGroup</group>
P37L8	       </item>
P37L9	     </query>
P37L10	   </iq>
P37L11	
P37L12	   <iq type='result' to='contact@example.org/resource' id='set2'/>
P37L13	
P37L14	   <presence
P37L15	       from='contact@example.org'
P37L16	       to='user@example.com'
P37L17	       type='subscribed'/>
P37L18	
P37L19	   <presence
P37L20	       from='contact@example.org/resource'
P37L21	       to='user@example.com'/>
P37L22	
P37L23	   Note: If the contact's server receives a presence stanza of type
P37L24	   "error" from the user's server, it MUST deliver the error stanza to
P37L25	   the contact, whose client MAY determine that the error is in response
P37L26	   to the outgoing presence stanza of type "subscribed" it sent
P37L27	   previously (e.g., by tracking an 'id' attribute) and then choose to
P37L28	   resend the "subscribed" notification or revert the roster to its
P37L29	   previous state by sending a presence stanza of type "unsubscribed" to
P37L30	   the user.
P37L31	
P37L32	   8.  Upon receiving the presence stanza of type "subscribed" addressed
P37L33	       to the user, the user's server MUST first verify that the contact
P37L34	       is in the user's roster with either of the following states: (a)
P37L35	       subscription='none' and ask='subscribe' or (b)
P37L36	       subscription='from' and ask='subscribe'.  If the contact is not
P37L37	       in the user's roster with either of those states, the user's
P37L38	       server MUST silently ignore the presence stanza of type
P37L39	       "subscribed" (i.e., it MUST NOT route it to the user, modify the
P37L40	       user's roster, or generate a roster push to the user's available
P37L41	       resources).  If the contact is in the user's roster with either
P37L42	       of those states, the user's server (1) MUST deliver the presence
P37L43	       stanza of type "subscribed" from the contact to the user; (2)
P37L44	       MUST initiate a roster push to all of the user's available
P37L45	       resources that have requested the roster, containing an updated
P37L46	       roster item for the contact with the 'subscription' attribute set
P37L47	
P37L48	
P38L1	       to a value of "to"; and (3) MUST deliver the available presence
P38L2	       stanza received from each of the contact's available resources to
P38L3	       each of the user's available resources:
P38L4	
P38L5	   <presence
P38L6	       to='user@example.com'
P38L7	       from='contact@example.org'
P38L8	       type='subscribed'/>
P38L9	
P38L10	   <iq type='set'>
P38L11	     <query xmlns='jabber:iq:roster'>
P38L12	       <item
P38L13	           jid='contact@example.org'
P38L14	           subscription='to'
P38L15	           name='MyContact'>
P38L16	         <group>MyBuddies</group>
P38L17	       </item>
P38L18	     </query>
P38L19	   </iq>
P38L20	
P38L21	   <presence
P38L22	       from='contact@example.org/resource'
P38L23	       to='user@example.com/resource'/>
P38L24	
P38L25	   9.  Upon receiving the presence stanza of type "subscribed", the user
P38L26	       SHOULD acknowledge receipt of that subscription state
P38L27	       notification through either "affirming" it by sending a presence
P38L28	       stanza of type "subscribe" to the contact or "denying" it by
P38L29	       sending a presence stanza of type "unsubscribe" to the contact;
P38L30	       this step does not necessarily affect the subscription state (see
P38L31	       Subscription States (Section 9) for details), but instead lets
P38L32	       the user's server know that it MUST no longer send notification
P38L33	       of the subscription state change to the user (see Section 9.4).
P38L34	
P38L35	   From the perspective of the user, there now exists a subscription to
P38L36	   the contact's presence information; from the perspective of the
P38L37	   contact, there now exists a subscription from the user.
P38L38	
P38L39	8.2.1.  Alternate Flow: Contact Declines Subscription Request
P38L40	
P38L41	   The above activity flow represents the "happy path" regarding the
P38L42	   user's subscription request to the contact.  The main alternate flow
P38L43	   occurs if the contact refuses the user's subscription request, as
P38L44	   described below.
P38L45	
P38L46	
P38L47	
P38L48	
P39L1	   1.  If the contact wants to refuse the request, the contact's client
P39L2	       MUST send a presence stanza of type "unsubscribed" to the user
P39L3	       (instead of the presence stanza of type "subscribed" sent in Step
P39L4	       6 of Section 8.2):
P39L5	
P39L6	   <presence to='user@example.com' type='unsubscribed'/>
P39L7	
P39L8	   2.  As a result, the contact's server MUST route the presence stanza
P39L9	       of type "unsubscribed" to the user, first stamping the 'from'
P39L10	       address as the bare JID (<contact@example.org>) of the contact:
P39L11	
P39L12	   <presence
P39L13	       from='contact@example.org'
P39L14	       to='user@example.com'
P39L15	       type='unsubscribed'/>
P39L16	
P39L17	   Note: If the contact's server previously added the user to the
P39L18	   contact's roster for tracking purposes, it MUST remove the relevant
P39L19	   item at this time.
P39L20	
P39L21	   3.  Upon receiving the presence stanza of type "unsubscribed"
P39L22	       addressed to the user, the user's server (1) MUST deliver that
P39L23	       presence stanza to the user and (2) MUST initiate a roster push
P39L24	       to all of the user's available resources that have requested the
P39L25	       roster, containing an updated roster item for the contact with
P39L26	       the 'subscription' attribute set to a value of "none" and with no
P39L27	       'ask' attribute:
P39L28	
P39L29	   <presence
P39L30	       from='contact@example.org'
P39L31	       to='user@example.com'
P39L32	       type='unsubscribed'/>
P39L33	
P39L34	   <iq type='set'>
P39L35	     <query xmlns='jabber:iq:roster'>
P39L36	       <item
P39L37	           jid='contact@example.org'
P39L38	           subscription='none'
P39L39	           name='MyContact'>
P39L40	         <group>MyBuddies</group>
P39L41	       </item>
P39L42	     </query>
P39L43	   </iq>
P39L44	
P39L45	   4.  Upon receiving the presence stanza of type "unsubscribed", the
P39L46	       user SHOULD acknowledge receipt of that subscription state
P39L47	       notification through either "affirming" it by sending a presence
P39L48	       stanza of type "unsubscribe" to the contact or "denying" it by
P40L1	       sending a presence stanza of type "subscribe" to the contact;
P40L2	       this step does not necessarily affect the subscription state (see
P40L3	       Subscription States (Section 9) for details), but instead lets
P40L4	       the user's server know that it MUST no longer send notification
P40L5	       of the subscription state change to the user (see Section 9.4).
P40L6	
P40L7	   As a result of this activity, the contact is now in the user's roster
P40L8	   with a subscription state of "none", whereas the user is not in the
P40L9	   contact's roster at all.
P40L10	
P40L11	8.3.  Creating a Mutual Subscription
P40L12	
P40L13	   The user and contact can build on the "happy path" described above to
P40L14	   create a mutual subscription (i.e., a subscription of type "both").
P40L15	   The process is described below.
P40L16	
P40L17	   1.  If the contact wants to create a mutual subscription, the contact
P40L18	       MUST send a subscription request to the user (subject to the
P40L19	       contact's configured preferences, the contact's client MAY send
P40L20	       this automatically):
P40L21	
P40L22	   <presence to='user@example.com' type='subscribe'/>
P40L23	
P40L24	   2.  As a result, the contact's server (1) MUST initiate a roster push
P40L25	       to all available resources associated with the contact that have
P40L26	       requested the roster, with the user still in the 'from'
P40L27	       subscription state but with a pending 'to' subscription denoted
P40L28	       by the inclusion of the ask='subscribe' attribute in the roster
P40L29	       item; and (2) MUST route the presence stanza of type "subscribe"
P40L30	       to the user, first stamping the 'from' address as the bare JID
P40L31	       (<contact@example.org>) of the contact:
P40L32	
P40L33	   <iq type='set'>
P40L34	     <query xmlns='jabber:iq:roster'>
P40L35	       <item
P40L36	           jid='user@example.com'
P40L37	           subscription='from'
P40L38	           ask='subscribe'
P40L39	           name='SomeUser'>
P40L40	         <group>SomeGroup</group>
P40L41	       </item>
P40L42	     </query>
P40L43	   </iq>
P40L44	
P40L45	
P40L46	
P40L47	
P40L48	
P41L1	   <presence
P41L2	       from='contact@example.org'
P41L3	       to='user@example.com'
P41L4	       type='subscribe'/>
P41L5	
P41L6	   Note: If the contact's server receives a presence stanza of type
P41L7	   "error" from the user's server, it MUST deliver the error stanza to
P41L8	   the contact, whose client MAY determine that the error is in response
P41L9	   to the outgoing presence stanza of type "subscribe" it sent
P41L10	   previously (e.g., by tracking an 'id' attribute) and then choose to
P41L11	   resend the "subscribe" request or revert the roster to its previous
P41L12	   state by sending a presence stanza of type "unsubscribe" to the user.
P41L13	
P41L14	   3.  Upon receiving the presence stanza of type "subscribe" addressed
P41L15	       to the user, the user's server must determine if there is at
P41L16	       least one available resource for which the user has requested the
P41L17	       roster.  If so, the user's server MUST deliver the subscription
P41L18	       request to the user (if not, it MUST store the subscription
P41L19	       request offline for delivery when this condition is next met). No
P41L20	       matter when the subscription request is delivered, the user must
P41L21	       then decide whether or not to approve it (subject to the user's
P41L22	       configured preferences, the user's client MAY approve or refuse
P41L23	       the subscription request without presenting it to the user).
P41L24	       Here we assume the "happy path" that the user approves the
P41L25	       subscription request (the alternate flow of declining the
P41L26	       subscription request is defined in Section 8.3.1).  In this case,
P41L27	       the user's client MUST send a presence stanza of type
P41L28	       "subscribed" to the contact in order to approve the subscription
P41L29	       request.
P41L30	
P41L31	   <presence to='contact@example.org' type='subscribed'/>
P41L32	
P41L33	   4.  As a result, the user's server (1) MUST initiate a roster push to
P41L34	       all of the user's available resources that have requested the
P41L35	       roster, containing a roster item for the contact with the
P41L36	       'subscription' attribute set to a value of "both"; (2) MUST route
P41L37	       the presence stanza of type "subscribed" to the contact, first
P41L38	       stamping the 'from' address as the bare JID (<user@example.com>)
P41L39	       of the user; and (3) MUST send to the contact the full XML of the
P41L40	       last presence stanza with no 'to' attribute received by the
P41L41	       server from each of the user's available resources (subject to
P41L42	       privacy lists in force for each session):
P41L43	
P41L44	
P41L45	
P41L46	
P41L47	
P41L48	
P42L1	   <iq type='set'>
P42L2	     <query xmlns='jabber:iq:roster'>
P42L3	       <item
P42L4	           jid='contact@example.org'
P42L5	           subscription='both'
P42L6	           name='MyContact'>
P42L7	         <group>MyBuddies</group>
P42L8	       </item>
P42L9	     </query>
P42L10	   </iq>
P42L11	
P42L12	   <presence
P42L13	       from='user@example.com'
P42L14	       to='contact@example.org'
P42L15	       type='subscribed'/>
P42L16	
P42L17	   <presence
P42L18	       from='user@example.com/resource'
P42L19	       to='contact@example.org'/>
P42L20	
P42L21	   Note: If the user's server receives a presence stanza of type "error"
P42L22	   from the contact's server, it MUST deliver the error stanza to the
P42L23	   user, whose client MAY determine that the error is in response to the
P42L24	   outgoing presence stanza of type "subscribed" it sent previously
P42L25	   (e.g., by tracking an 'id' attribute) and then choose to resend the
P42L26	   subscription request or revert the roster to its previous state by
P42L27	   sending a presence stanza of type "unsubscribed" to the contact.
P42L28	
P42L29	   5.  Upon receiving the presence stanza of type "subscribed" addressed
P42L30	       to the contact, the contact's server MUST first verify that the
P42L31	       user is in the contact's roster with either of the following
P42L32	       states: (a) subscription='none' and ask='subscribe' or (b)
P42L33	       subscription='from' and ask='subscribe'.  If the user is not in
P42L34	       the contact's roster with either of those states, the contact's
P42L35	       server MUST silently ignore the presence stanza of type
P42L36	       "subscribed" (i.e., it MUST NOT route it to the contact, modify
P42L37	       the contact's roster, or generate a roster push to the contact's
P42L38	       available resources).  If the user is in the contact's roster
P42L39	       with either of those states, the contact's server (1) MUST
P42L40	       deliver the presence stanza of type "subscribed" from the user to
P42L41	       the contact; (2) MUST initiate a roster push to all available
P42L42	       resources associated with the contact that have requested the
P42L43	       roster, containing an updated roster item for the user with the
P42L44	       'subscription' attribute set to a value of "both"; and (3) MUST
P42L45	       deliver the available presence stanza received from each of the
P42L46	       user's available resources to each of the contact's available
P42L47	       resources:
P42L48	
P43L1	   <presence
P43L2	       from='user@example.com'
P43L3	       to='contact@example.org'
P43L4	       type='subscribed'/>
P43L5	
P43L6	   <iq type='set'>
P43L7	     <query xmlns='jabber:iq:roster'>
P43L8	       <item
P43L9	           jid='user@example.com'
P43L10	           subscription='both'
P43L11	           name='SomeUser'>
P43L12	         <group>SomeGroup</group>
P43L13	       </item>
P43L14	     </query>
P43L15	   </iq>
P43L16	
P43L17	   <presence
P43L18	       from='user@example.com/resource'
P43L19	       to='contact@example.org/resource'/>
P43L20	
P43L21	   6.  Upon receiving the presence stanza of type "subscribed", the
P43L22	       contact SHOULD acknowledge receipt of that subscription state
P43L23	       notification through either "affirming" it by sending a presence
P43L24	       stanza of type "subscribe" to the user or "denying" it by sending
P43L25	       a presence stanza of type "unsubscribe" to the user; this step
P43L26	       does not necessarily affect the subscription state (see
P43L27	       Subscription States (Section 9) for details), but instead lets
P43L28	       the contact's server know that it MUST no longer send
P43L29	       notification of the subscription state change to the contact (see
P43L30	       Section 9.4).
P43L31	
P43L32	   The user and the contact now have a mutual subscription to each
P43L33	   other's presence -- i.e., the subscription is of type "both".
P43L34	
P43L35	8.3.1.  Alternate Flow: User Declines Subscription Request
P43L36	
P43L37	   The above activity flow represents the "happy path" regarding the
P43L38	   contact's subscription request to the user.  The main alternate flow
P43L39	   occurs if the user refuses the contact's subscription request, as
P43L40	   described below.
P43L41	
P43L42	   1.  If the user wants to refuse the request, the user's client MUST
P43L43	       send a presence stanza of type "unsubscribed" to the contact
P43L44	       (instead of the presence stanza of type "subscribed" sent in Step
P43L45	       3 of Section 8.3):
P43L46	
P43L47	   <presence to='contact@example.org' type='unsubscribed'/>
P43L48	
P44L1	   2.  As a result, the user's server MUST route the presence stanza of
P44L2	       type "unsubscribed" to the contact, first stamping the 'from'
P44L3	       address as the bare JID (<user@example.com>) of the user:
P44L4	
P44L5	   <presence
P44L6	       from='user@example.com'
P44L7	       to='contact@example.org'
P44L8	       type='unsubscribed'/>
P44L9	
P44L10	   3.  Upon receiving the presence stanza of type "unsubscribed"
P44L11	       addressed to the contact, the contact's server (1) MUST deliver
P44L12	       that presence stanza to the contact; and (2) MUST initiate a
P44L13	       roster push to all available resources associated with the
P44L14	       contact that have requested the roster, containing an updated
P44L15	       roster item for the user with the 'subscription' attribute set to
P44L16	       a value of "from" and with no 'ask' attribute:
P44L17	
P44L18	   <presence
P44L19	       from='user@example.com'
P44L20	       to='contact@example.org'
P44L21	       type='unsubscribed'/>
P44L22	
P44L23	   <iq type='set'>
P44L24	     <query xmlns='jabber:iq:roster'>
P44L25	       <item
P44L26	           jid='user@example.com'
P44L27	           subscription='from'
P44L28	           name='SomeUser'>
P44L29	         <group>SomeGroup</group>
P44L30	       </item>
P44L31	     </query>
P44L32	   </iq>
P44L33	
P44L34	   4.  Upon receiving the presence stanza of type "unsubscribed", the
P44L35	       contact SHOULD acknowledge receipt of that subscription state
P44L36	       notification through either "affirming" it by sending a presence
P44L37	       stanza of type "unsubscribe" to the user or "denying" it by
P44L38	       sending a presence stanza of type "subscribe" to the user; this
P44L39	       step does not necessarily affect the subscription state (see
P44L40	       Subscription States (Section 9) for details), but instead lets
P44L41	       the contact's server know that it MUST no longer send
P44L42	       notification of the subscription state change to the contact (see
P44L43	       Section 9.4).
P44L44	
P44L45	   As a result of this activity, there has been no change in the
P44L46	   subscription state; i.e., the contact is in the user's roster with a
P44L47	   subscription state of "to" and the user is in the contact's roster
P44L48	   with a subscription state of "from".
P45L1	8.4.  Unsubscribing
P45L2	
P45L3	   At any time after subscribing to a contact's presence information, a
P45L4	   user MAY unsubscribe.  While the XML that the user sends to make this
P45L5	   happen is the same in all instances, the subsequent subscription
P45L6	   state is different depending on the subscription state obtaining when
P45L7	   the unsubscribe "command" is sent.  Both possible scenarios are
P45L8	   described below.
P45L9	
P45L10	8.4.1.  Case #1: Unsubscribing When Subscription is Not Mutual
P45L11	
P45L12	   In the first case, the user has a subscription to the contact's
P45L13	   presence information but the contact does not have a subscription to
P45L14	   the user's presence information (i.e., the subscription is not yet
P45L15	   mutual).
P45L16	
P45L17	   1.  If the user wants to unsubscribe from the contact's presence
P45L18	       information, the user MUST send a presence stanza of type
P45L19	       "unsubscribe" to the contact:
P45L20	
P45L21	   <presence to='contact@example.org' type='unsubscribe'/>
P45L22	
P45L23	   2.  As a result, the user's server (1) MUST send a roster push to all
P45L24	       of the user's available resources that have requested the roster,
P45L25	       containing an updated roster item for the contact with the
P45L26	       'subscription' attribute set to a value of "none"; and (2) MUST
P45L27	       route the presence stanza of type "unsubscribe" to the contact,
P45L28	       first stamping the 'from' address as the bare JID
P45L29	       (<user@example.com>) of the user:
P45L30	
P45L31	   <iq type='set'>
P45L32	     <query xmlns='jabber:iq:roster'>
P45L33	       <item
P45L34	           jid='contact@example.org'
P45L35	           subscription='none'
P45L36	           name='MyContact'>
P45L37	         <group>MyBuddies</group>
P45L38	       </item>
P45L39	     </query>
P45L40	   </iq>
P45L41	
P45L42	   <presence
P45L43	       from='user@example.com'
P45L44	       to='contact@example.org'
P45L45	       type='unsubscribe'/>
P45L46	
P45L47	
P45L48	
P46L1	   3.  Upon receiving the presence stanza of type "unsubscribe"
P46L2	       addressed to the contact, the contact's server (1) MUST initiate
P46L3	       a roster push to all available resources associated with the
P46L4	       contact that have requested the roster, containing an updated
P46L5	       roster item for the user with the 'subscription' attribute set to
P46L6	       a value of "none" (if the contact is unavailable or has not
P46L7	       requested the roster, the contact's server MUST modify the roster
P46L8	       item and send that modified item the next time the contact
P46L9	       requests the roster); and (2) MUST deliver the "unsubscribe"
P46L10	       state change notification to the contact:
P46L11	
P46L12	   <iq type='set'>
P46L13	     <query xmlns='jabber:iq:roster'>
P46L14	       <item
P46L15	           jid='user@example.com'
P46L16	           subscription='none'
P46L17	           name='SomeUser'>
P46L18	         <group>SomeGroup</group>
P46L19	       </item>
P46L20	     </query>
P46L21	   </iq>
P46L22	
P46L23	   <presence
P46L24	       from='user@example.com'
P46L25	       to='contact@example.org'
P46L26	       type='unsubscribe'/>
P46L27	
P46L28	   4.  Upon receiving the presence stanza of type "unsubscribe", the
P46L29	       contact SHOULD acknowledge receipt of that subscription state
P46L30	       notification through either "affirming" it by sending a presence
P46L31	       stanza of type "unsubscribed" to the user or "denying" it by
P46L32	       sending a presence stanza of type "subscribed" to the user; this
P46L33	       step does not necessarily affect the subscription state (see
P46L34	       Subscription States (Section 9) for details), but instead lets
P46L35	       the contact's server know that it MUST no longer send
P46L36	       notification of the subscription state change to the contact (see
P46L37	       Section 9.4).
P46L38	
P46L39	   5.  The contact's server then (1) MUST send a presence stanza of type
P46L40	       "unsubscribed" to the user; and (2) SHOULD send unavailable
P46L41	       presence from all of the contact's available resources to the
P46L42	       user:
P46L43	
P46L44	   <presence
P46L45	       from='contact@example.org'
P46L46	       to='user@example.com'
P46L47	       type='unsubscribed'/>
P46L48	
P47L1	   <presence
P47L2	       from='contact@example.org/resource'
P47L3	       to='user@example.com'
P47L4	       type='unavailable'/>
P47L5	
P47L6	   6.  When the user's server receives the presence stanzas of type
P47L7	       "unsubscribed" and "unavailable", it MUST deliver them to the
P47L8	       user:
P47L9	
P47L10	   <presence
P47L11	       from='contact@example.org'
P47L12	       to='user@example.com'
P47L13	       type='unsubscribed'/>
P47L14	
P47L15	   <presence
P47L16	       from='contact@example.org/resource'
P47L17	       to='user@example.com'
P47L18	       type='unavailable'/>
P47L19	
P47L20	   7.  Upon receiving the presence stanza of type "unsubscribed", the
P47L21	       user SHOULD acknowledge receipt of that subscription state
P47L22	       notification through either "affirming" it by sending a presence
P47L23	       stanza of type "unsubscribe" to the contact or "denying" it by
P47L24	       sending a presence stanza of type "subscribe" to the contact;
P47L25	       this step does not necessarily affect the subscription state (see
P47L26	       Subscription States (Section 9) for details), but instead lets
P47L27	       the user's server know that it MUST no longer send notification
P47L28	       of the subscription state change to the user (see Section 9.4).
P47L29	
P47L30	8.4.2.  Case #2: Unsubscribing When Subscription is Mutual
P47L31	
P47L32	   In the second case, the user has a subscription to the contact's
P47L33	   presence information and the contact also has a subscription to the
P47L34	   user's presence information (i.e., the subscription is mutual).
P47L35	
P47L36	   1.  If the user wants to unsubscribe from the contact's presence
P47L37	       information, the user MUST send a presence stanza of type
P47L38	       "unsubscribe" to the contact:
P47L39	
P47L40	   <presence to='contact@example.org' type='unsubscribe'/>
P47L41	
P47L42	   2.  As a result, the user's server (1) MUST send a roster push to all
P47L43	       of the user's available resources that have requested the roster,
P47L44	       containing an updated roster item for the contact with the
P47L45	       'subscription' attribute set to a value of "from"; and (2) MUST
P47L46	       route the presence stanza of type "unsubscribe" to the contact,
P47L47	       first stamping the 'from' address as the bare JID
P47L48	       (<user@example.com>) of the user:
P48L1	   <iq type='set'>
P48L2	     <query xmlns='jabber:iq:roster'>
P48L3	       <item
P48L4	           jid='contact@example.org'
P48L5	           subscription='from'
P48L6	           name='MyContact'>
P48L7	         <group>MyBuddies</group>
P48L8	       </item>
P48L9	     </query>
P48L10	   </iq>
P48L11	
P48L12	   <presence
P48L13	       from='user@example.com'
P48L14	       to='contact@example.org'
P48L15	       type='unsubscribe'/>
P48L16	
P48L17	   3.  Upon receiving the presence stanza of type "unsubscribe"
P48L18	       addressed to the contact, the contact's server (1) MUST initiate
P48L19	       a roster push to all available resources associated with the
P48L20	       contact that have requested the roster, containing an updated
P48L21	       roster item for the user with the 'subscription' attribute set to
P48L22	       a value of "to" (if the contact is unavailable or has not
P48L23	       requested the roster, the contact's server MUST modify the roster
P48L24	       item and send that modified item the next time the contact
P48L25	       requests the roster); and (2) MUST deliver the "unsubscribe"
P48L26	       state change notification to the contact:
P48L27	
P48L28	   <iq type='set'>
P48L29	     <query xmlns='jabber:iq:roster'>
P48L30	       <item
P48L31	           jid='user@example.com'
P48L32	           subscription='to'
P48L33	           name='SomeUser'>
P48L34	         <group>SomeGroup</group>
P48L35	       </item>
P48L36	     </query>
P48L37	   </iq>
P48L38	
P48L39	   <presence
P48L40	       from='user@example.com'
P48L41	       to='contact@example.org'
P48L42	       type='unsubscribe'/>
P48L43	
P48L44	   4.  Upon receiving the presence stanza of type "unsubscribe", the
P48L45	       contact SHOULD acknowledge receipt of that subscription state
P48L46	       notification through either "affirming" it by sending a presence
P48L47	       stanza of type "unsubscribed" to the user or "denying" it by
P48L48	       sending a presence stanza of type "subscribed" to the user; this
P49L1	       step does not necessarily affect the subscription state (see
P49L2	       Subscription States (Section 9) for details), but instead lets
P49L3	       the contact's server know that it MUST no longer send
P49L4	       notification of the subscription state change to the contact (see
P49L5	       Section 9.4).
P49L6	
P49L7	   5.  The contact's server then (1) MUST send a presence stanza of type
P49L8	       "unsubscribed" to the user; and (2) SHOULD send unavailable
P49L9	       presence from all of the contact's available resources to the
P49L10	       user:
P49L11	
P49L12	   <presence
P49L13	       from='contact@example.org'
P49L14	       to='user@example.com'
P49L15	       type='unsubscribed'/>
P49L16	
P49L17	   <presence
P49L18	       from='contact@example.org/resource'
P49L19	       to='user@example.com'
P49L20	       type='unavailable'/>
P49L21	
P49L22	   6.  When the user's server receives the presence stanzas of type
P49L23	       "unsubscribed" and "unavailable", it MUST deliver them to the
P49L24	       user:
P49L25	
P49L26	   <presence
P49L27	       from='contact@example.org'
P49L28	       to='user@example.com'
P49L29	       type='unsubscribed'/>
P49L30	
P49L31	   <presence
P49L32	       from='contact@example.org/resource'
P49L33	       to='user@example.com'
P49L34	       type='unavailable'/>
P49L35	
P49L36	   7.  Upon receiving the presence stanza of type "unsubscribed", the
P49L37	       user SHOULD acknowledge receipt of that subscription state
P49L38	       notification through either "affirming" it by sending a presence
P49L39	       stanza of type "unsubscribe" to the contact or "denying" it by
P49L40	       sending a presence stanza of type "subscribe" to the contact;
P49L41	       this step does not necessarily affect the subscription state (see
P49L42	       Subscription States (Section 9) for details), but instead lets
P49L43	       the user's server know that it MUST no longer send notification
P49L44	       of the subscription state change to the user (see Section 9.4).
P49L45	
P49L46	   Note: Obviously this does not result in removal of the roster item
P49L47	   from the user's roster, and the contact still has a subscription to
P49L48	   the user's presence information.  In order to both completely cancel
P50L1	   a mutual subscription and fully remove the roster item from the
P50L2	   user's roster, the user SHOULD update the roster item with
P50L3	   subscription='remove' as defined under Removing a Roster Item and
P50L4	   Cancelling All Subscriptions (Section 8.6).
P50L5	
P50L6	8.5.  Cancelling a Subscription
P50L7	
P50L8	   At any time after approving a subscription request from a user, a
P50L9	   contact MAY cancel that subscription.  While the XML that the contact
P50L10	   sends to make this happen is the same in all instances, the
P50L11	   subsequent subscription state is different depending on the
P50L12	   subscription state obtaining when the cancellation was sent.  Both
P50L13	   possible scenarios are described below.
P50L14	
P50L15	8.5.1.  Case #1: Cancelling When Subscription is Not Mutual
P50L16	
P50L17	   In the first case, the user has a subscription to the contact's
P50L18	   presence information but the contact does not have a subscription to
P50L19	   the user's presence information (i.e., the subscription is not yet
P50L20	   mutual).
P50L21	
P50L22	   1.  If the contact wants to cancel the user's subscription, the
P50L23	       contact MUST send a presence stanza of type "unsubscribed" to the
P50L24	       user:
P50L25	
P50L26	   <presence to='user@example.com' type='unsubscribed'/>
P50L27	
P50L28	   2.  As a result, the contact's server (1) MUST send a roster push to
P50L29	       all of the contact's available resources that have requested the
P50L30	       roster, containing an updated roster item for the user with the
P50L31	       'subscription' attribute set to a value of "none"; (2) MUST route
P50L32	       the presence stanza of type "unsubscribed" to the user, first
P50L33	       stamping the 'from' address as the bare JID
P50L34	       (<contact@example.org>) of the contact; and (3) SHOULD send
P50L35	       unavailable presence from all of the contact's available
P50L36	       resources to the user:
P50L37	
P50L38	   <iq type='set'>
P50L39	     <query xmlns='jabber:iq:roster'>
P50L40	       <item
P50L41	           jid='user@example.com'
P50L42	           subscription='none'
P50L43	           name='SomeUser'>
P50L44	         <group>SomeGroup</group>
P50L45	       </item>
P50L46	     </query>
P50L47	   </iq>
P50L48	
P51L1	   <presence
P51L2	       from='contact@example.org'
P51L3	       to='user@example.com'
P51L4	       type='unsubscribed'/>
P51L5	
P51L6	   <presence
P51L7	       from='contact@example.org/resource'
P51L8	       to='user@example.com'
P51L9	       type='unavailable'/>
P51L10	
P51L11	   3.  Upon receiving the presence stanza of type "unsubscribed"
P51L12	       addressed to the user, the user's server (1) MUST initiate a
P51L13	       roster push to all of the user's available resources that have
P51L14	       requested the roster, containing an updated roster item for the
P51L15	       contact with the 'subscription' attribute set to a value of
P51L16	       "none" (if the user is unavailable or has not requested the
P51L17	       roster, the user's server MUST modify the roster item and send
P51L18	       that modified item the next time the user requests the roster);
P51L19	       (2) MUST deliver the "unsubscribed" state change notification to
P51L20	       all of the user's available resources; and (3) MUST deliver the
P51L21	       unavailable presence to all of the user's available resources:
P51L22	
P51L23	   <iq type='set'>
P51L24	     <query xmlns='jabber:iq:roster'>
P51L25	       <item
P51L26	           jid='contact@example.org'
P51L27	           subscription='none'
P51L28	           name='MyContact'>
P51L29	         <group>MyBuddies</group>
P51L30	       </item>
P51L31	     </query>
P51L32	   </iq>
P51L33	
P51L34	   <presence
P51L35	       from='contact@example.org'
P51L36	       to='user@example.com'
P51L37	       type='unsubscribed'/>
P51L38	
P51L39	   <presence
P51L40	       from='contact@example.org/resource'
P51L41	       to='user@example.com'
P51L42	       type='unavailable'/>
P51L43	
P51L44	   4.  Upon receiving the presence stanza of type "unsubscribed", the
P51L45	       user SHOULD acknowledge receipt of that subscription state
P51L46	       notification through either "affirming" it by sending a presence
P51L47	       stanza of type "unsubscribe" to the contact or "denying" it by
P51L48	       sending a presence stanza of type "subscribe" to the contact;
P52L1	       this step does not necessarily affect the subscription state (see
P52L2	       Subscription States (Section 9) for details), but instead lets
P52L3	       the user's server know that it MUST no longer send notification
P52L4	       of the subscription state change to the user (see Section 9.4).
P52L5	
P52L6	8.5.2.  Case #2: Cancelling When Subscription is Mutual
P52L7	
P52L8	   In the second case, the user has a subscription to the contact's
P52L9	   presence information and the contact also has a subscription to the
P52L10	   user's presence information (i.e., the subscription is mutual).
P52L11	
P52L12	   1.  If the contact wants to cancel the user's subscription, the
P52L13	       contact MUST send a presence stanza of type "unsubscribed" to the
P52L14	       user:
P52L15	
P52L16	   <presence to='user@example.com' type='unsubscribed'/>
P52L17	
P52L18	   2.  As a result, the contact's server (1) MUST send a roster push to
P52L19	       all of the contact's available resources that have requested the
P52L20	       roster, containing an updated roster item for the user with the
P52L21	       'subscription' attribute set to a value of "to"; (2) MUST route
P52L22	       the presence stanza of type "unsubscribed" to the user, first
P52L23	       stamping the 'from' address as the bare JID
P52L24	       (<contact@example.org>) of the contact; and (3) SHOULD send
P52L25	       unavailable presence from all of the contact's available
P52L26	       resources to all of the user's available resources:
P52L27	
P52L28	   <iq type='set'>
P52L29	     <query xmlns='jabber:iq:roster'>
P52L30	       <item
P52L31	           jid='user@example.com'
P52L32	           subscription='to'
P52L33	           name='SomeUser'>
P52L34	         <group>SomeGroup</group>
P52L35	       </item>
P52L36	     </query>
P52L37	   </iq>
P52L38	
P52L39	   <presence
P52L40	       from='contact@example.org'
P52L41	       to='user@example.com'
P52L42	       type='unsubscribed'/>
P52L43	
P52L44	   <presence
P52L45	       from='contact@example.org/resource'
P52L46	       to='user@example.com'
P52L47	       type='unavailable'/>
P52L48	
P53L1	   3.  Upon receiving the presence stanza of type "unsubscribed"
P53L2	       addressed to the user, the user's server (1) MUST initiate a
P53L3	       roster push to all of the user's available resources that have
P53L4	       requested the roster, containing an updated roster item for the
P53L5	       contact with the 'subscription' attribute set to a value of
P53L6	       "from" (if the user is unavailable or has not requested the
P53L7	       roster, the user's server MUST modify the roster item and send
P53L8	       that modified item the next time the user requests the roster);
P53L9	       and (2) MUST deliver the "unsubscribed" state change notification
P53L10	       to all of the user's available resources; and (3) MUST deliver
P53L11	       the unavailable presence to all of the user's available
P53L12	       resources:
P53L13	
P53L14	   <iq type='set'>
P53L15	     <query xmlns='jabber:iq:roster'>
P53L16	       <item
P53L17	           jid='contact@example.org'
P53L18	           subscription='from'
P53L19	           name='MyContact'>
P53L20	         <group>MyBuddies</group>
P53L21	       </item>
P53L22	     </query>
P53L23	   </iq>
P53L24	
P53L25	   <presence
P53L26	       from='contact@example.org'
P53L27	       to='user@example.com'
P53L28	       type='unsubscribed'/>
P53L29	
P53L30	   <presence
P53L31	       from='contact@example.org/resource'
P53L32	       to='user@example.com'
P53L33	       type='unavailable'/>
P53L34	
P53L35	   4.  Upon receiving the presence stanza of type "unsubscribed", the
P53L36	       user SHOULD acknowledge receipt of that subscription state
P53L37	       notification through either "affirming" it by sending a presence
P53L38	       stanza of type "unsubscribe" to the contact or "denying" it by
P53L39	       sending a presence stanza of type "subscribe" to the contact;
P53L40	       this step does not necessarily affect the subscription state (see
P53L41	       Subscription States (Section 9) for details), but instead lets
P53L42	       the user's server know that it MUST no longer send notification
P53L43	       of the subscription state change to the user (see Section 9.4).
P53L44	
P53L45	   Note: Obviously this does not result in removal of the roster item
P53L46	   from the contact's roster, and the contact still has a subscription
P53L47	   to the user's presence information.  In order to both completely
P53L48	   cancel a mutual subscription and fully remove the roster item from
P54L1	   the contact's roster, the contact should update the roster item with
P54L2	   subscription='remove' as defined under Removing a Roster Item and
P54L3	   Cancelling All Subscriptions (Section 8.6).
P54L4	
P54L5	8.6.  Removing a Roster Item and Cancelling All Subscriptions
P54L6	
P54L7	   Because there may be many steps involved in completely removing a
P54L8	   roster item and cancelling subscriptions in both directions, the
P54L9	   roster management protocol includes a "shortcut" method for doing so.
P54L10	   The process may be initiated no matter what the current subscription
P54L11	   state is by sending a roster set containing an item for the contact
P54L12	   with the 'subscription' attribute set to a value of "remove":
P54L13	
P54L14	   <iq type='set' id='remove1'>
P54L15	     <query xmlns='jabber:iq:roster'>
P54L16	       <item
P54L17	           jid='contact@example.org'
P54L18	           subscription='remove'/>
P54L19	     </query>
P54L20	   </iq>
P54L21	
P54L22	   When the user removes a contact from his or her roster by setting the
P54L23	   'subscription' attribute to a value of "remove", the user's server
P54L24	   (1) MUST automatically cancel any existing presence subscription
P54L25	   between the user and the contact (both 'to' and 'from' as
P54L26	   appropriate); (2) MUST remove the roster item from the user's roster
P54L27	   and inform all of the user's available resources that have requested
P54L28	   the roster of the roster item removal; (3) MUST inform the resource
P54L29	   that initiated the removal of success; and (4) SHOULD send
P54L30	   unavailable presence from all of the user's available resources to
P54L31	   the contact:
P54L32	
P54L33	   <presence
P54L34	       from='user@example.com'
P54L35	       to='contact@example.org'
P54L36	       type='unsubscribe'/>
P54L37	
P54L38	   <presence
P54L39	       from='user@example.com'
P54L40	       to='contact@example.org'
P54L41	       type='unsubscribed'/>
P54L42	
P54L43	
P54L44	
P54L45	
P54L46	
P54L47	
P54L48	
P55L1	   <iq type='set'>
P55L2	     <query xmlns='jabber:iq:roster'>
P55L3	       <item
P55L4	           jid='contact@example.org'
P55L5	           subscription='remove'/>
P55L6	     </query>
P55L7	   </iq>
P55L8	
P55L9	   <iq type='result' id='remove1'/>
P55L10	
P55L11	   <presence
P55L12	       from='user@example.com/resource'
P55L13	       to='contact@example.org'
P55L14	       type='unavailable'/>
P55L15	
P55L16	   Upon receiving the presence stanza of type "unsubscribe", the
P55L17	   contact's server (1) MUST initiate a roster push to all available
P55L18	   resources associated with the contact that have requested the roster,
P55L19	   containing an updated roster item for the user with the
P55L20	   'subscription' attribute set to a value of "to" (if the contact is
P55L21	   unavailable or has not requested the roster, the contact's server
P55L22	   MUST modify the roster item and send that modified item the next time
P55L23	   the contact requests the roster); and (2) MUST also deliver the
P55L24	   "unsubscribe" state change notification to all of the contact's
P55L25	   available resources:
P55L26	
P55L27	   <iq type='set'>
P55L28	     <query xmlns='jabber:iq:roster'>
P55L29	       <item
P55L30	           jid='user@example.com'
P55L31	           subscription='to'
P55L32	           name='SomeUser'>
P55L33	         <group>SomeGroup</group>
P55L34	       </item>
P55L35	     </query>
P55L36	   </iq>
P55L37	
P55L38	   <presence
P55L39	       from='user@example.com'
P55L40	       to='contact@example.org'
P55L41	       type='unsubscribe'/>
P55L42	
P55L43	   Upon receiving the presence stanza of type "unsubscribed", the
P55L44	   contact's server (1) MUST initiate a roster push to all available
P55L45	   resources associated with the contact that have requested the roster,
P55L46	   containing an updated roster item for the user with the
P55L47	   'subscription' attribute set to a value of "none" (if the contact is
P55L48	   unavailable or has not requested the roster, the contact's server
P56L1	   MUST modify the roster item and send that modified item the next time
P56L2	   the contact requests the roster); and (2) MUST also deliver the
P56L3	   "unsubscribe" state change notification to all of the contact's
P56L4	   available resources:
P56L5	
P56L6	   <iq type='set'>
P56L7	     <query xmlns='jabber:iq:roster'>
P56L8	       <item
P56L9	           jid='user@example.com'
P56L10	           subscription='none'
P56L11	           name='SomeUser'>
P56L12	         <group>SomeGroup</group>
P56L13	       </item>
P56L14	     </query>
P56L15	   </iq>
P56L16	
P56L17	   <presence
P56L18	       from='user@example.com'
P56L19	       to='contact@example.org'
P56L20	       type='unsubscribed'/>
P56L21	
P56L22	   Upon receiving the presence stanza of type "unavailable" addressed to
P56L23	   the contact, the contact's server MUST deliver the unavailable
P56L24	   presence to all of the user's available resources:
P56L25	
P56L26	   <presence
P56L27	       from='user@example.com/resource'
P56L28	       to='contact@example.org'
P56L29	       type='unavailable'/>
P56L30	
P56L31	   Note: When the user removes the contact from the user's roster, the
P56L32	   end state of the contact's roster is that the user is still in the
P56L33	   contact's roster with a subscription state of "none"; in order to
P56L34	   completely remove the roster item for the user, the contact needs to
P56L35	   also send a roster removal request.
P56L36	
P56L37	9.  Subscription States
P56L38	
P56L39	   This section provides detailed information about subscription states
P56L40	   and server handling of subscription-related presence stanzas (i.e.,
P56L41	   presence stanzas of type "subscribe", "subscribed", "unsubscribe",
P56L42	   and "unsubscribed").
P56L43	
P56L44	9.1.  Defined States
P56L45	
P56L46	   There are nine possible subscription states, which are described here
P56L47	   from the user's (not contact's) perspective:
P56L48	
P57L1	   1.  "None" = contact and user are not subscribed to each other, and
P57L2	       neither has requested a subscription from the other
P57L3	
P57L4	   2.  "None + Pending Out" = contact and user are not subscribed to
P57L5	       each other, and user has sent contact a subscription request but
P57L6	       contact has not replied yet
P57L7	
P57L8	   3.  "None + Pending In" = contact and user are not subscribed to each
P57L9	       other, and contact has sent user a subscription request but user
P57L10	       has not replied yet (note: contact's server SHOULD NOT push or
P57L11	       deliver roster items in this state, but instead SHOULD wait until
P57L12	       contact has approved subscription request from user)
P57L13	
P57L14	   4.  "None + Pending Out/In" = contact and user are not subscribed to
P57L15	       each other, contact has sent user a subscription request but user
P57L16	       has not replied yet, and user has sent contact a subscription
P57L17	       request but contact has not replied yet
P57L18	
P57L19	   5.  "To" = user is subscribed to contact (one-way)
P57L20	
P57L21	   6.  "To + Pending In" = user is subscribed to contact, and contact
P57L22	       has sent user a subscription request but user has not replied yet
P57L23	
P57L24	   7.  "From" = contact is subscribed to user (one-way)
P57L25	
P57L26	   8.  "From + Pending Out" = contact is subscribed to user, and user
P57L27	       has sent contact a subscription request but contact has not
P57L28	       replied yet
P57L29	
P57L30	   9.  "Both" = user and contact are subscribed to each other (two-way)
P57L31	
P57L32	9.2.  Server Handling of Outbound Presence Subscription Stanzas
P57L33	
P57L34	   Outbound presence subscription stanzas enable the user to manage his
P57L35	   or her subscription to the contact's presence information (via the
P57L36	   "subscribe" and "unsubscribe" types), and to manage the contact's
P57L37	   access to the user's presence information (via the "subscribed" and
P57L38	   "unsubscribed" types).
P57L39	
P57L40	   Because it is possible for the user's server and the contact's server
P57L41	   to lose synchronization regarding subscription states, the user's
P57L42	   server MUST without exception route all outbound presence stanzas of
P57L43	   type "subscribe" or "unsubscribe" to the contact so that the user is
P57L44	   able to resynchronize his or her subscription to the contact's
P57L45	   presence information if needed.
P57L46	
P57L47	
P57L48	
P58L1	   The user's server SHOULD NOT route a presence stanza of type
P58L2	   "subscribed" or "unsubscribed" to the contact if the stanza does not
P58L3	   result in a subscription state change from the user's perspective,
P58L4	   and MUST NOT make a state change.  If the stanza results in a
P58L5	   subscription state change, the user's server MUST route the stanza to
P58L6	   the contact and MUST make the appropriate state change.  These rules
P58L7	   are summarized in the following tables.
P58L8	
P58L9	   Table 1: Recommended handling of outbound "subscribed" stanzas
P58L10	
P58L11	   +----------------------------------------------------------------+
P58L12	   |  EXISTING STATE          |  ROUTE?  |  NEW STATE               |
P58L13	   +----------------------------------------------------------------+
P58L14	   |  "None"                  |  no      |  no state change         |
P58L15	   |  "None + Pending Out"    |  no      |  no state change         |
P58L16	   |  "None + Pending In"     |  yes     |  "From"                  |
P58L17	   |  "None + Pending Out/In" |  yes     |  "From + Pending Out"    |
P58L18	   |  "To"                    |  no      |  no state change         |
P58L19	   |  "To + Pending In"       |  yes     |  "Both"                  |
P58L20	   |  "From"                  |  no      |  no state change         |
P58L21	   |  "From + Pending Out"    |  no      |  no state change         |
P58L22	   |  "Both"                  |  no      |  no state change         |
P58L23	   +----------------------------------------------------------------+
P58L24	
P58L25	   Table 2: Recommended handling of outbound "unsubscribed" stanzas
P58L26	
P58L27	   +----------------------------------------------------------------+
P58L28	   |  EXISTING STATE          |  ROUTE?  |  NEW STATE               |
P58L29	   +----------------------------------------------------------------+
P58L30	   |  "None"                  |  no      |  no state change         |
P58L31	   |  "None + Pending Out"    |  no      |  no state change         |
P58L32	   |  "None + Pending In"     |  yes     |  "None"                  |
P58L33	   |  "None + Pending Out/In" |  yes     |  "None + Pending Out"    |
P58L34	   |  "To"                    |  no      |  no state change         |
P58L35	   |  "To + Pending In"       |  yes     |  "To"                    |
P58L36	   |  "From"                  |  yes     |  "None"                  |
P58L37	   |  "From + Pending Out"    |  yes     |  "None + Pending Out"    |
P58L38	   |  "Both"                  |  yes     |  "To"                    |
P58L39	   +----------------------------------------------------------------+
P58L40	
P58L41	9.3.  Server Handling of Inbound Presence Subscription Stanzas
P58L42	
P58L43	   Inbound presence subscription stanzas request a subscription-related
P58L44	   action from the user (via the "subscribe" type), inform the user of
P58L45	   subscription-related actions taken by the contact (via the
P58L46	   "unsubscribe" type), or enable the contact to manage the user's
P58L47	   access to the contact's presence information (via the "subscribed"
P58L48	   and "unsubscribed" types).
P59L1	   When the user's server receives a subscription request for the user
P59L2	   from the contact (i.e., a presence stanza of type "subscribe"), it
P59L3	   MUST deliver that request to the user for approval if the user has
P59L4	   not already granted the contact access to the user's presence
P59L5	   information and if there is no pending inbound subscription request;
P59L6	   however, the user's server SHOULD NOT deliver the new request if
P59L7	   there is a pending inbound subscription request, since the previous
P59L8	   subscription request will have been recorded.  If the user has
P59L9	   already granted the contact access to the user's presence
P59L10	   information, the user's server SHOULD auto-reply to an inbound
P59L11	   presence stanza of type "subscribe" from the contact by sending a
P59L12	   presence stanza of type "subscribed" to the contact on behalf of the
P59L13	   user; this rule enables the contact to resynchronize the subscription
P59L14	   state if needed.  These rules are summarized in the following table.
P59L15	
P59L16	   Table 3: Recommended handling of inbound "subscribe" stanzas
P59L17	
P59L18	   +------------------------------------------------------------------+
P59L19	   |  EXISTING STATE          |  DELIVER?  |  NEW STATE               |
P59L20	   +------------------------------------------------------------------+
P59L21	   |  "None"                  |  yes       |  "None + Pending In"     |
P59L22	   |  "None + Pending Out"    |  yes       |  "None + Pending Out/In" |
P59L23	   |  "None + Pending In"     |  no        |  no state change         |
P59L24	   |  "None + Pending Out/In" |  no        |  no state change         |
P59L25	   |  "To"                    |  yes       |  "To + Pending In"       |
P59L26	   |  "To + Pending In"       |  no        |  no state change         |
P59L27	   |  "From"                  |  no *      |  no state change         |
P59L28	   |  "From + Pending Out"    |  no *      |  no state change         |
P59L29	   |  "Both"                  |  no *      |  no state change         |
P59L30	   +------------------------------------------------------------------+
P59L31	
P59L32	   * Server SHOULD auto-reply with "subscribed" stanza
P59L33	
P59L34	   When the user's server receives a presence stanza of type
P59L35	   "unsubscribe" for the user from the contact, if the stanza results in
P59L36	   a subscription state change from the user's perspective then the
P59L37	   user's server SHOULD auto-reply by sending a presence stanza of type
P59L38	   "unsubscribed" to the contact on behalf of the user, MUST deliver the
P59L39	   "unsubscribe" stanza to the user, and MUST change the state.  If no
P59L40	   subscription state change results, the user's server SHOULD NOT
P59L41	   deliver the stanza and MUST NOT change the state.  These rules are
P59L42	   summarized in the following table.
P59L43	
P59L44	
P59L45	
P59L46	
P59L47	
P59L48	
P60L1	   Table 4: Recommended handling of inbound "unsubscribe" stanzas
P60L2	
P60L3	   +------------------------------------------------------------------+
P60L4	   |  EXISTING STATE          |  DELIVER?  |  NEW STATE               |
P60L5	   +------------------------------------------------------------------+
P60L6	   |  "None"                  |  no        |  no state change         |
P60L7	   |  "None + Pending Out"    |  no        |  no state change         |
P60L8	   |  "None + Pending In"     |  yes *     |  "None"                  |
P60L9	   |  "None + Pending Out/In" |  yes *     |  "None + Pending Out"    |
P60L10	   |  "To"                    |  no        |  no state change         |
P60L11	   |  "To + Pending In"       |  yes *     |  "To"                    |
P60L12	   |  "From"                  |  yes *     |  "None"                  |
P60L13	   |  "From + Pending Out"    |  yes *     |  "None + Pending Out     |
P60L14	   |  "Both"                  |  yes *     |  "To"                    |
P60L15	   +------------------------------------------------------------------+
P60L16	
P60L17	   * Server SHOULD auto-reply with "unsubscribed" stanza
P60L18	
P60L19	   When the user's server receives a presence stanza of type
P60L20	   "subscribed" for the user from the contact, it MUST NOT deliver the
P60L21	   stanza to the user and MUST NOT change the subscription state if
P60L22	   there is no pending outbound request for access to the contact's
P60L23	   presence information.  If there is a pending outbound request for
P60L24	   access to the contact's presence information and the inbound presence
P60L25	   stanza of type "subscribed" results in a subscription state change,
P60L26	   the user's server MUST deliver the stanza to the user and MUST change
P60L27	   the subscription state.  If the user already has access to the
P60L28	   contact's presence information, the inbound presence stanza of type
P60L29	   "subscribed" does not result in a subscription state change;
P60L30	   therefore the user's server SHOULD NOT deliver the stanza to the user
P60L31	   and MUST NOT change the subscription state.  These rules are
P60L32	   summarized in the following table.
P60L33	
P60L34	   Table 5: Recommended handling of inbound "subscribed" stanzas
P60L35	
P60L36	   +------------------------------------------------------------------+
P60L37	   |  EXISTING STATE          |  DELIVER?  |  NEW STATE               |
P60L38	   +------------------------------------------------------------------+
P60L39	   |  "None"                  |  no        |  no state change         |
P60L40	   |  "None + Pending Out"    |  yes       |  "To"                    |
P60L41	   |  "None + Pending In"     |  no        |  no state change         |
P60L42	   |  "None + Pending Out/In" |  yes       |  "To + Pending In"       |
P60L43	   |  "To"                    |  no        |  no state change         |
P60L44	   |  "To + Pending In"       |  no        |  no state change         |
P60L45	   |  "From"                  |  no        |  no state change         |
P60L46	   |  "From + Pending Out"    |  yes       |  "Both"                  |
P60L47	   |  "Both"                  |  no        |  no state change         |
P60L48	   +------------------------------------------------------------------+
P61L1	   When the user's server receives a presence stanza of type
P61L2	   "unsubscribed" for the user from the contact, it MUST deliver the
P61L3	   stanza to the user and MUST change the subscription state if there is
P61L4	   a pending outbound request for access to the contact's presence
P61L5	   information or if the user currently has access to the contact's
P61L6	   presence information.  Otherwise, the user's server SHOULD NOT
P61L7	   deliver the stanza and MUST NOT change the subscription state.  These
P61L8	   rules are summarized in the following table.
P61L9	
P61L10	   Table 6: Recommended handling of inbound "unsubscribed" stanzas
P61L11	
P61L12	   +------------------------------------------------------------------+
P61L13	   |  EXISTING STATE          |  DELIVER?  |  NEW STATE               |
P61L14	   +------------------------------------------------------------------+
P61L15	   |  "None"                  |  no        |  no state change         |
P61L16	   |  "None + Pending Out"    |  yes       |  "None"                  |
P61L17	   |  "None + Pending In"     |  no        |  no state change         |
P61L18	   |  "None + Pending Out/In" |  yes       |  "None + Pending In"     |
P61L19	   |  "To"                    |  yes       |  "None"                  |
P61L20	   |  "To + Pending In"       |  yes       |  "None + Pending In"     |
P61L21	   |  "From"                  |  no        |  no state change         |
P61L22	   |  "From + Pending Out"    |  yes       |  "From"                  |
P61L23	   |  "Both"                  |  yes       |  "From"                  |
P61L24	   +------------------------------------------------------------------+
P61L25	
P61L26	9.4.  Server Delivery and Client Acknowledgement of Subscription
P61L27	      Requests and State Change Notifications
P61L28	
P61L29	   When a server receives an inbound presence stanza of type "subscribe"
P61L30	   (i.e., a subscription request) or of type "subscribed",
P61L31	   "unsubscribe", or "unsubscribed" (i.e., a subscription state change
P61L32	   notification), in addition to sending the appropriate roster push (or
P61L33	   updated roster when the roster is next requested by an available
P61L34	   resource), it MUST deliver the request or notification to the
P61L35	   intended recipient at least once.  A server MAY require the recipient
P61L36	   to acknowledge receipt of all state change notifications (and MUST
P61L37	   require acknowledgement in the case of subscription requests, i.e.,
P61L38	   presence stanzas of type "subscribe").  In order to require
P61L39	   acknowledgement, a server SHOULD send the request or notification to
P61L40	   the recipient each time the recipient logs in, until the recipient
P61L41	   acknowledges receipt of the notification by "affirming" or "denying"
P61L42	   the notification, as shown in the following table:
P61L43	
P61L44	
P61L45	
P61L46	
P61L47	
P61L48	
P62L1	   Table 7: Acknowledgement of subscription state change notifications
P62L2	
P62L3	   +--------------------------------------------------+
P62L4	   |  STANZA TYPE   |  ACCEPT        |  DENY          |
P62L5	   +--------------------------------------------------+
P62L6	   |  subscribe     |  subscribed    |  unsubscribed  |
P62L7	   |  subscribed    |  subscribe     |  unsubscribe   |
P62L8	   |  unsubscribe   |  unsubscribed  |  subscribed    |
P62L9	   |  unsubscribed  |  unsubscribe   |  subscribe     |
P62L10	   +--------------------------------------------------+
P62L11	
P62L12	   Obviously, given the foregoing subscription state charts, some of the
P62L13	   acknowledgement stanzas will be routed to the contact and result in
P62L14	   subscription state changes, while others will not.  However, any such
P62L15	   stanzas MUST result in the server's no longer sending the
P62L16	   subscription state notification to the user.
P62L17	
P62L18	   Because a user's server MUST automatically generate outbound presence
P62L19	   stanzas of type "unsubscribe" and "unsubscribed" upon receiving a
P62L20	   roster set with the 'subscription' attribute set to a value of
P62L21	   "remove" (see Removing a Roster Item and Cancelling All Subscriptions
P62L22	   (Section 8.6)), the server MUST treat a roster remove request as
P62L23	   equivalent to sending both of those presence stanzas for purposes of
P62L24	   determining whether to continue sending subscription state change
P62L25	   notifications of type "subscribe" or "subscribed" to the user.
P62L26	
P62L27	10.  Blocking Communication
P62L28	
P62L29	   Most instant messaging systems have found it necessary to implement
P62L30	   some method for users to block communications from particular other
P62L31	   users (this is also required by sections 5.1.5, 5.1.15, 5.3.2, and
P62L32	   5.4.10 of [IMP-REQS]).  In XMPP this is done by managing one's
P62L33	   privacy lists using the 'jabber:iq:privacy' namespace.
P62L34	
P62L35	   Server-side privacy lists enable successful completion of the
P62L36	   following use cases:
P62L37	
P62L38	   o  Retrieving one's privacy lists.
P62L39	
P62L40	   o  Adding, removing, and editing one's privacy lists.
P62L41	
P62L42	   o  Setting, changing, or declining active lists.
P62L43	
P62L44	   o  Setting, changing, or declining the default list (i.e., the list
P62L45	      that is active by default).
P62L46	
P62L47	   o  Allowing or blocking messages based on JID, group, or subscription
P62L48	      type (or globally).
P63L1	   o  Allowing or blocking inbound presence notifications based on JID,
P63L2	      group, or subscription type (or globally).
P63L3	
P63L4	   o  Allowing or blocking outbound presence notifications based on JID,
P63L5	      group, or subscription type (or globally).
P63L6	
P63L7	   o  Allowing or blocking IQ stanzas based on JID, group, or
P63L8	      subscription type (or globally).
P63L9	
P63L10	   o  Allowing or blocking all communications based on JID, group, or
P63L11	      subscription type (or globally).
P63L12	
P63L13	   Note: Presence notifications do not include presence subscriptions,
P63L14	   only presence information that is broadcasted to entities that are
P63L15	   subscribed to a user's presence information.  Thus this includes
P63L16	   presence stanzas with no 'type' attribute or of type='unavailable'
P63L17	   only.
P63L18	
P63L19	10.1.  Syntax and Semantics
P63L20	
P63L21	   A user MAY define one or more privacy lists, which are stored by the
P63L22	   user's server.  Each <list/> element contains one or more rules in
P63L23	   the form of <item/> elements, and each <item/> element uses
P63L24	   attributes to define a privacy rule type, a specific value to which
P63L25	   the rule applies, the relevant action, and the place of the item in
P63L26	   the processing order.
P63L27	
P63L28	   The syntax is as follows:
P63L29	
P63L30	   <iq>
P63L31	     <query xmlns='jabber:iq:privacy'>
P63L32	       <list name='foo'>
P63L33	         <item
P63L34	             type='[jid|group|subscription]'
P63L35	             value='bar'
P63L36	             action='[allow|deny]'
P63L37	             order='unsignedInt'>
P63L38	           [<message/>]
P63L39	           [<presence-in/>]
P63L40	           [<presence-out/>]
P63L41	           [<iq/>]
P63L42	         </item>
P63L43	       </list>
P63L44	     </query>
P63L45	   </iq>
P63L46	
P63L47	
P63L48	
P64L1	   If the type is "jid", then the 'value' attribute MUST contain a valid
P64L2	   Jabber ID.  JIDs SHOULD be matched in the following order:
P64L3	
P64L4	   1.  <user@domain/resource> (only that resource matches)
P64L5	
P64L6	   2.  <user@domain> (any resource matches)
P64L7	
P64L8	   3.  <domain/resource> (only that resource matches)
P64L9	
P64L10	   4.  <domain> (the domain itself matches, as does any user@domain,
P64L11	       domain/resource, or address containing a subdomain)
P64L12	
P64L13	   If the type is "group", then the 'value' attribute SHOULD contain the
P64L14	   name of a group in the user's roster.  (If a client attempts to
P64L15	   update, create, or delete a list item with a group that is not in the
P64L16	   user's roster, the server SHOULD return to the client an
P64L17	   <item-not-found/> stanza error.)
P64L18	
P64L19	   If the type is "subscription", then the 'value' attribute MUST be one
P64L20	   of "both", "to", "from", or "none" as defined under Roster Syntax and
P64L21	   Semantics (Section 7.1), where "none" includes entities that are
P64L22	   totally unknown to the user and therefore not in the user's roster at
P64L23	   all.
P64L24	
P64L25	   If no 'type' attribute is included, the rule provides the
P64L26	   "fall-through" case.
P64L27	
P64L28	   The 'action' attribute MUST be included and its value MUST be either
P64L29	   "allow" or "deny".
P64L30	
P64L31	   The 'order' attribute MUST be included and its value MUST be a
P64L32	   non-negative integer that is unique among all items in the list.  (If
P64L33	   a client attempts to create or update a list with non-unique order
P64L34	   values, the server MUST return to the client a <bad-request/> stanza
P64L35	   error.)
P64L36	
P64L37	   The <item/> element MAY contain one or more child elements that
P64L38	   enable an entity to specify more granular control over which kinds of
P64L39	   stanzas are to be blocked (i.e., rather than blocking all stanzas).
P64L40	   The allowable child elements are:
P64L41	
P64L42	   o  <message/> -- blocks incoming message stanzas
P64L43	   o  <iq/> -- blocks incoming IQ stanzas
P64L44	   o  <presence-in/> -- blocks incoming presence notifications
P64L45	   o  <presence-out/> -- blocks outgoing presence notifications
P64L46	
P64L47	
P64L48	
P65L1	   Within the 'jabber:iq:privacy' namespace, the <query/> child of an IQ
P65L2	   stanza of type "set" MUST NOT include more than one child element
P65L3	   (i.e., the stanza MUST contain only one <active/> element, one
P65L4	   <default/> element, or one <list/> element); if a sending entity
P65L5	   violates this rule, the receiving entity MUST return a <bad-request/>
P65L6	   stanza error.
P65L7	
P65L8	   When a client adds or updates a privacy list, the <list/> element
P65L9	   SHOULD contain at least one <item/> child element; when a client
P65L10	   removes a privacy list, the <list/> element MUST NOT contain any
P65L11	   <item/> child elements.
P65L12	
P65L13	   When a client updates a privacy list, it must include all of the
P65L14	   desired items (i.e., not a "delta").
P65L15	
P65L16	10.2.  Business Rules
P65L17	
P65L18	   1.  If there is an active list set for a session, it affects only the
P65L19	       session(s) for which it is activated, and only for the duration
P65L20	       of the session(s); the server MUST apply the active list only and
P65L21	       MUST NOT apply the default list (i.e., there is no "layering" of
P65L22	       lists).
P65L23	
P65L24	   2.  The default list applies to the user as a whole, and is processed
P65L25	       if there is no active list set for the target session/resource to
P65L26	       which a stanza is addressed, or if there are no current sessions
P65L27	       for the user.
P65L28	
P65L29	   3.  If there is no active list set for a session (or there are no
P65L30	       current sessions for the user), and there is no default list,
P65L31	       then all stanzas SHOULD BE accepted or appropriately processed by
P65L32	       the server on behalf of the user in accordance with the Server
P65L33	       Rules for Handling XML Stanzas (Section 11).
P65L34	
P65L35	   4.  Privacy lists MUST be the first delivery rule applied by a
P65L36	       server, superseding (1) the routing and delivery rules specified
P65L37	       in Server Rules for Handling XML Stanzas (Section 11), and (2)
P65L38	       the handling of subscription-related presence stanzas (and
P65L39	       corresponding generation of roster pushes) specified in
P65L40	       Integration of Roster Items and Presence Subscriptions (Section
P65L41	       8).
P65L42	
P65L43	   5.  The order in which privacy list items are processed by the server
P65L44	       is important.  List items MUST be processed in ascending order
P65L45	       determined by the integer values of the 'order' attribute for
P65L46	       each <item/>.
P65L47	
P65L48	
P66L1	   6.  As soon as a stanza is matched against a privacy list rule, the
P66L2	       server MUST appropriately handle the stanza in accordance with
P66L3	       the rule and cease processing.
P66L4	
P66L5	   7.  If no fall-through item is provided in a list, the fall-through
P66L6	       action is assumed to be "allow".
P66L7	
P66L8	   8.  If a user updates the definition for an active list, subsequent
P66L9	       processing based on that active list MUST use the updated
P66L10	       definition (for all resources to which that active list currently
P66L11	       applies).
P66L12	
P66L13	   9.  If a change to the subscription state or roster group of a roster
P66L14	       item defined in an active or default list occurs during a user's
P66L15	       session, subsequent processing based on that list MUST take into
P66L16	       account the changed state or group (for all resources to which
P66L17	       that list currently applies).
P66L18	
P66L19	   10. When the definition for a rule is modified, the server MUST send
P66L20	       an IQ stanza of type "set" to all connected resources, containing
P66L21	       a <query/> element with only one <list/> child element, where the
P66L22	       'name' attribute is set to the name of the modified privacy list.
P66L23	       These "privacy list pushes" adhere to the same semantics as the
P66L24	       "roster pushes" used in roster management, except that only the
P66L25	       list name itself (not the full list definition or the "delta") is
P66L26	       pushed to the connected resources.  It is up to the receiving
P66L27	       resource to determine whether to retrieve the modified list
P66L28	       definition, although a connected resource SHOULD do so if the
P66L29	       list currently applies to it.
P66L30	
P66L31	   11. When a resource attempts to remove a list or specify a new
P66L32	       default list while that list applies to a connected resource
P66L33	       other than the sending resource, the server MUST return a
P66L34	       <conflict/> error to the sending resource and MUST NOT make the
P66L35	       requested change.
P66L36	
P66L37	10.3.  Retrieving One's Privacy Lists
P66L38	
P66L39	   Example: Client requests names of privacy lists from server:
P66L40	
P66L41	   <iq from='romeo@example.net/orchard' type='get' id='getlist1'>
P66L42	     <query xmlns='jabber:iq:privacy'/>
P66L43	   </iq>
P66L44	
P66L45	
P66L46	
P66L47	
P66L48	
P67L1	   Example: Server sends names of privacy lists to client, preceded by
P67L2	   active list and default list:
P67L3	
P67L4	   <iq type='result' id='getlist1' to='romeo@example.net/orchard'>
P67L5	     <query xmlns='jabber:iq:privacy'>
P67L6	       <active name='private'/>
P67L7	       <default name='public'/>
P67L8	       <list name='public'/>
P67L9	       <list name='private'/>
P67L10	       <list name='special'/>
P67L11	     </query>
P67L12	   </iq>
P67L13	
P67L14	   Example: Client requests a privacy list from server:
P67L15	
P67L16	   <iq from='romeo@example.net/orchard' type='get' id='getlist2'>
P67L17	     <query xmlns='jabber:iq:privacy'>
P67L18	       <list name='public'/>
P67L19	     </query>
P67L20	   </iq>
P67L21	
P67L22	   Example: Server sends a privacy list to client:
P67L23	
P67L24	   <iq type='result' id='getlist2' to='romeo@example.net/orchard'>
P67L25	     <query xmlns='jabber:iq:privacy'>
P67L26	       <list name='public'>
P67L27	         <item type='jid'
P67L28	               value='tybalt@example.com'
P67L29	               action='deny'
P67L30	               order='1'/>
P67L31	         <item action='allow' order='2'/>
P67L32	       </list>
P67L33	     </query>
P67L34	   </iq>
P67L35	
P67L36	   Example: Client requests another privacy list from server:
P67L37	
P67L38	   <iq from='romeo@example.net/orchard' type='get' id='getlist3'>
P67L39	     <query xmlns='jabber:iq:privacy'>
P67L40	       <list name='private'/>
P67L41	     </query>
P67L42	   </iq>
P67L43	
P67L44	
P67L45	
P67L46	
P67L47	
P67L48	
P68L1	   Example: Server sends another privacy list to client:
P68L2	
P68L3	   <iq type='result' id='getlist3' to='romeo@example.net/orchard'>
P68L4	     <query xmlns='jabber:iq:privacy'>
P68L5	       <list name='private'>
P68L6	         <item type='subscription'
P68L7	               value='both'
P68L8	               action='allow'
P68L9	               order='10'/>
P68L10	         <item action='deny' order='15'/>
P68L11	       </list>
P68L12	     </query>
P68L13	   </iq>
P68L14	
P68L15	   Example: Client requests yet another privacy list from server:
P68L16	
P68L17	   <iq from='romeo@example.net/orchard' type='get' id='getlist4'>
P68L18	     <query xmlns='jabber:iq:privacy'>
P68L19	       <list name='special'/>
P68L20	     </query>
P68L21	   </iq>
P68L22	
P68L23	   Example: Server sends yet another privacy list to client:
P68L24	
P68L25	   <iq type='result' id='getlist4' to='romeo@example.net/orchard'>
P68L26	     <query xmlns='jabber:iq:privacy'>
P68L27	       <list name='special'>
P68L28	         <item type='jid'
P68L29	               value='juliet@example.com'
P68L30	               action='allow'
P68L31	               order='6'/>
P68L32	         <item type='jid'
P68L33	               value='benvolio@example.org'
P68L34	               action='allow'
P68L35	               order='7'/>
P68L36	         <item type='jid'
P68L37	               value='mercutio@example.org'
P68L38	               action='allow'
P68L39	               order='42'/>
P68L40	         <item action='deny' order='666'/>
P68L41	       </list>
P68L42	     </query>
P68L43	   </iq>
P68L44	
P68L45	   In this example, the user has three lists: (1) 'public', which allows
P68L46	   communications from everyone except one specific entity (this is the
P68L47	   default list); (2) 'private', which allows communications only with
P68L48	
P69L1	   contacts who have a bidirectional subscription with the user (this is
P69L2	   the active list); and (3) 'special', which allows communications only
P69L3	   with three specific entities.
P69L4	
P69L5	   If the user attempts to retrieve a list but a list by that name does
P69L6	   not exist, the server MUST return an <item-not-found/> stanza error
P69L7	   to the user:
P69L8	
P69L9	   Example: Client attempts to retrieve non-existent list:
P69L10	
P69L11	   <iq to='romeo@example.net/orchard' type='error' id='getlist5'>
P69L12	     <query xmlns='jabber:iq:privacy'>
P69L13	       <list name='The Empty Set'/>
P69L14	     </query>
P69L15	     <error type='cancel'>
P69L16	       <item-not-found
P69L17	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P69L18	     </error>
P69L19	   </iq>
P69L20	
P69L21	   The user is allowed to retrieve only one list at a time.  If the user
P69L22	   attempts to retrieve more than one list in the same request, the
P69L23	   server MUST return a <bad request/> stanza error to the user:
P69L24	
P69L25	   Example: Client attempts to retrieve more than one list:
P69L26	
P69L27	   <iq to='romeo@example.net/orchard' type='error' id='getlist6'>
P69L28	     <query xmlns='jabber:iq:privacy'>
P69L29	       <list name='public'/>
P69L30	       <list name='private'/>
P69L31	       <list name='special'/>
P69L32	     </query>
P69L33	     <error type='modify'>
P69L34	       <bad-request
P69L35	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P69L36	     </error>
P69L37	   </iq>
P69L38	
P69L39	10.4.  Managing Active Lists
P69L40	
P69L41	   In order to set or change the active list currently being applied by
P69L42	   the server, the user MUST send an IQ stanza of type "set" with a
P69L43	   <query/> element qualified by the 'jabber:iq:privacy' namespace that
P69L44	   contains an empty <active/> child element possessing a 'name'
P69L45	   attribute whose value is set to the desired list name.
P69L46	
P69L47	
P69L48	
P70L1	   Example: Client requests change of active list:
P70L2	
P70L3	   <iq from='romeo@example.net/orchard' type='set' id='active1'>
P70L4	     <query xmlns='jabber:iq:privacy'>
P70L5	       <active name='special'/>
P70L6	     </query>
P70L7	   </iq>
P70L8	
P70L9	   The server MUST activate and apply the requested list before sending
P70L10	   the result back to the client.
P70L11	
P70L12	   Example: Server acknowledges success of active list change:
P70L13	
P70L14	   <iq type='result' id='active1' to='romeo@example.net/orchard'/>
P70L15	
P70L16	   If the user attempts to set an active list but a list by that name
P70L17	   does not exist, the server MUST return an <item-not-found/> stanza
P70L18	   error to the user:
P70L19	
P70L20	   Example: Client attempts to set a non-existent list as active:
P70L21	
P70L22	   <iq to='romeo@example.net/orchard' type='error' id='active2'>
P70L23	     <query xmlns='jabber:iq:privacy'>
P70L24	       <active name='The Empty Set'/>
P70L25	     </query>
P70L26	     <error type='cancel'>
P70L27	       <item-not-found
P70L28	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P70L29	     </error>
P70L30	   </iq>
P70L31	
P70L32	   In order to decline the use of any active list, the connected
P70L33	   resource MUST send an empty <active/> element with no 'name'
P70L34	   attribute.
P70L35	
P70L36	   Example: Client declines the use of active lists:
P70L37	
P70L38	   <iq from='romeo@example.net/orchard' type='set' id='active3'>
P70L39	     <query xmlns='jabber:iq:privacy'>
P70L40	       <active/>
P70L41	     </query>
P70L42	   </iq>
P70L43	
P70L44	   Example: Server acknowledges success of declining any active list:
P70L45	
P70L46	   <iq type='result' id='active3' to='romeo@example.net/orchard'/>
P70L47	
P70L48	
P71L1	10.5.  Managing the Default List
P71L2	
P71L3	   In order to change its default list (which applies to the user as a
P71L4	   whole, not only the sending resource), the user MUST send an IQ
P71L5	   stanza of type "set" with a <query/> element qualified by the
P71L6	   'jabber:iq:privacy' namespace that contains an empty <default/> child
P71L7	   element possessing a 'name' attribute whose value is set to the
P71L8	   desired list name.
P71L9	
P71L10	   Example: User requests change of default list:
P71L11	
P71L12	   <iq from='romeo@example.net/orchard' type='set' id='default1'>
P71L13	     <query xmlns='jabber:iq:privacy'>
P71L14	       <default name='special'/>
P71L15	     </query>
P71L16	   </iq>
P71L17	
P71L18	   Example: Server acknowledges success of default list change:
P71L19	
P71L20	   <iq type='result' id='default1' to='romeo@example.net/orchard'/>
P71L21	
P71L22	   If the user attempts to change which list is the default list but the
P71L23	   default list is in use by at least one connected resource other than
P71L24	   the sending resource, the server MUST return a <conflict/> stanza
P71L25	   error to the sending resource:
P71L26	
P71L27	   Example: Client attempts to change the default list but that list is
P71L28	   in use by another resource:
P71L29	
P71L30	   <iq to='romeo@example.net/orchard' type='error' id='default1'>
P71L31	     <query xmlns='jabber:iq:privacy'>
P71L32	       <default name='special'/>
P71L33	     </query>
P71L34	     <error type='cancel'>
P71L35	       <conflict
P71L36	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P71L37	     </error>
P71L38	   </iq>
P71L39	
P71L40	   If the user attempts to set a default list but a list by that name
P71L41	   does not exist, the server MUST return an <item-not-found/> stanza
P71L42	   error to the user:
P71L43	
P71L44	
P71L45	
P71L46	
P71L47	
P71L48	
P72L1	   Example: Client attempts to set a non-existent list as default:
P72L2	
P72L3	   <iq to='romeo@example.net/orchard' type='error' id='default1'>
P72L4	     <query xmlns='jabber:iq:privacy'>
P72L5	       <default name='The Empty Set'/>
P72L6	     </query>
P72L7	     <error type='cancel'>
P72L8	       <item-not-found
P72L9	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P72L10	     </error>
P72L11	   </iq>
P72L12	
P72L13	   In order to decline the use of a default list (i.e., to use the
P72L14	   domain's stanza routing rules at all times), the user MUST send an
P72L15	   empty <default/> element with no 'name' attribute.
P72L16	
P72L17	   Example: Client declines the use of the default list:
P72L18	
P72L19	   <iq from='romeo@example.net/orchard' type='set' id='default2'>
P72L20	     <query xmlns='jabber:iq:privacy'>
P72L21	       <default/>
P72L22	     </query>
P72L23	   </iq>
P72L24	
P72L25	   Example: Server acknowledges success of declining any default list:
P72L26	
P72L27	   <iq type='result' id='default2' to='romeo@example.net/orchard'/>
P72L28	
P72L29	   If one connected resource attempts to decline the use of a default
P72L30	   list for the user as a whole but the default list currently applies
P72L31	   to at least one other connected resource, the server MUST return a
P72L32	   <conflict/> error to the sending resource:
P72L33	
P72L34	   Example: Client attempts to decline a default list but that list is
P72L35	   in use by another resource:
P72L36	
P72L37	   <iq to='romeo@example.net/orchard' type='error' id='default3'>
P72L38	     <query xmlns='jabber:iq:privacy'>
P72L39	       <default/>
P72L40	     </query>
P72L41	     <error type='cancel'>
P72L42	       <conflict
P72L43	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P72L44	     </error>
P72L45	   </iq>
P72L46	
P72L47	
P72L48	
P73L1	10.6.  Editing a Privacy List
P73L2	
P73L3	   In order to edit a privacy list, the user MUST send an IQ stanza of
P73L4	   type "set" with a <query/> element qualified by the
P73L5	   'jabber:iq:privacy' namespace that contains one <list/> child element
P73L6	   possessing a 'name' attribute whose value is set to the list name the
P73L7	   user would like to edit.  The <list/> element MUST contain one or
P73L8	   more <item/> elements, which specify the user's desired changes to
P73L9	   the list by including all elements in the list (not the "delta").
P73L10	
P73L11	   Example: Client edits a privacy list:
P73L12	
P73L13	   <iq from='romeo@example.net/orchard' type='set' id='edit1'>
P73L14	     <query xmlns='jabber:iq:privacy'>
P73L15	       <list name='public'>
P73L16	         <item type='jid'
P73L17	               value='tybalt@example.com'
P73L18	               action='deny'
P73L19	               order='3'/>
P73L20	         <item type='jid'
P73L21	               value='paris@example.org'
P73L22	               action='deny'
P73L23	               order='5'/>
P73L24	         <item action='allow' order='68'/>
P73L25	       </list>
P73L26	     </query>
P73L27	   </iq>
P73L28	
P73L29	   Example: Server acknowledges success of list edit:
P73L30	
P73L31	   <iq type='result' id='edit1' to='romeo@example.net/orchard'/>
P73L32	
P73L33	   Note: The value of the 'order' attribute for any given item is not
P73L34	   fixed.  Thus in the foregoing example if the user would like to add 4
P73L35	   items between the "tybalt@example.com" item and the
P73L36	   "paris@example.org" item, the user's client MUST renumber the
P73L37	   relevant items before submitting the list to the server.
P73L38	
P73L39	   The server MUST now send a "privacy list push" to all connected
P73L40	   resources:
P73L41	
P73L42	   Example: Privacy list push on list edit:
P73L43	
P73L44	   <iq to='romeo@example.net/orchard' type='set' id='push1'>
P73L45	     <query xmlns='jabber:iq:privacy'>
P73L46	       <list name='public'/>
P73L47	     </query>
P73L48	   </iq>
P74L1	   <iq to='romeo@example.net/home' type='set' id='push2'>
P74L2	     <query xmlns='jabber:iq:privacy'>
P74L3	       <list name='public'/>
P74L4	     </query>
P74L5	   </iq>
P74L6	
P74L7	   In accordance with the semantics of IQ stanzas defined in
P74L8	   [XMPP-CORE], each connected resource MUST return an IQ result to the
P74L9	   server as well:
P74L10	
P74L11	   Example: Acknowledging receipt of privacy list pushes:
P74L12	
P74L13	   <iq from='romeo@example.net/orchard'
P74L14	       type='result'
P74L15	       id='push1'/>
P74L16	
P74L17	   <iq from='romeo@example.net/home'
P74L18	       type='result'
P74L19	       id='push2'/>
P74L20	
P74L21	10.7.  Adding a New Privacy List
P74L22	
P74L23	   The same protocol used to edit an existing list is used to create a
P74L24	   new list.  If the list name matches that of an existing list, the
P74L25	   request to add a new list will overwrite the old one.  As with list
P74L26	   edits, the server MUST also send a "privacy list push" to all
P74L27	   connected resources.
P74L28	
P74L29	10.8.  Removing a Privacy List
P74L30	
P74L31	   In order to remove a privacy list, the user MUST send an IQ stanza of
P74L32	   type "set" with a <query/> element qualified by the
P74L33	   'jabber:iq:privacy' namespace that contains one empty <list/> child
P74L34	   element possessing a 'name' attribute whose value is set to the list
P74L35	   name the user would like to remove.
P74L36	
P74L37	   Example: Client removes a privacy list:
P74L38	
P74L39	   <iq from='romeo@example.net/orchard' type='set' id='remove1'>
P74L40	     <query xmlns='jabber:iq:privacy'>
P74L41	       <list name='private'/>
P74L42	     </query>
P74L43	   </iq>
P74L44	
P74L45	   Example: Server acknowledges success of list removal:
P74L46	
P74L47	   <iq type='result' id='remove1' to='romeo@example.net/orchard'/>
P74L48	
P75L1	   If a user attempts to remove a list that is currently being applied
P75L2	   to at least one resource other than the sending resource, the server
P75L3	   MUST return a <conflict/> stanza error to the user; i.e., the user
P75L4	   MUST first set another list to active or default before attempting to
P75L5	   remove it.  If the user attempts to remove a list but a list by that
P75L6	   name does not exist, the server MUST return an <item-not-found/>
P75L7	   stanza error to the user.  If the user attempts to remove more than
P75L8	   one list in the same request, the server MUST return a <bad request/>
P75L9	   stanza error to the user.
P75L10	
P75L11	10.9.  Blocking Messages
P75L12	
P75L13	   Server-side privacy lists enable a user to block incoming messages
P75L14	   from other entities based on the entity's JID, roster group, or
P75L15	   subscription status (or globally).  The following examples illustrate
P75L16	   the protocol.  (Note: For the sake of brevity, IQ stanzas of type
P75L17	   "result" are not shown in the following examples, nor are "privacy
P75L18	   list pushes".)
P75L19	
P75L20	   Example: User blocks based on JID:
P75L21	
P75L22	   <iq from='romeo@example.net/orchard' type='set' id='msg1'>
P75L23	     <query xmlns='jabber:iq:privacy'>
P75L24	       <list name='message-jid-example'>
P75L25	         <item type='jid'
P75L26	               value='tybalt@example.com'
P75L27	               action='deny'
P75L28	               order='3'>
P75L29	           <message/>
P75L30	         </item>
P75L31	       </list>
P75L32	     </query>
P75L33	   </iq>
P75L34	
P75L35	   As a result of creating and applying the foregoing list, the user
P75L36	   will not receive messages from the entity with the specified JID.
P75L37	
P75L38	   Example: User blocks based on roster group:
P75L39	
P75L40	   <iq from='romeo@example.net/orchard' type='set' id='msg2'>
P75L41	     <query xmlns='jabber:iq:privacy'>
P75L42	       <list name='message-group-example'>
P75L43	         <item type='group'
P75L44	               value='Enemies'
P75L45	               action='deny'
P75L46	               order='4'>
P75L47	           <message/>
P75L48	         </item>
P76L1	       </list>
P76L2	     </query>
P76L3	   </iq>
P76L4	
P76L5	   As a result of creating and applying the foregoing list, the user
P76L6	   will not receive messages from any entities in the specified roster
P76L7	   group.
P76L8	
P76L9	   Example: User blocks based on subscription type:
P76L10	
P76L11	   <iq from='romeo@example.net/orchard' type='set' id='msg3'>
P76L12	     <query xmlns='jabber:iq:privacy'>
P76L13	       <list name='message-sub-example'>
P76L14	         <item type='subscription'
P76L15	               value='none'
P76L16	               action='deny'
P76L17	               order='5'>
P76L18	           <message/>
P76L19	         </item>
P76L20	       </list>
P76L21	     </query>
P76L22	   </iq>
P76L23	
P76L24	   As a result of creating and applying the foregoing list, the user
P76L25	   will not receive messages from any entities with the specified
P76L26	   subscription type.
P76L27	
P76L28	   Example: User blocks globally:
P76L29	
P76L30	   <iq from='romeo@example.net/orchard' type='set' id='msg4'>
P76L31	     <query xmlns='jabber:iq:privacy'>
P76L32	       <list name='message-global-example'>
P76L33	         <item action='deny' order='6'>
P76L34	           <message/>
P76L35	         </item>
P76L36	       </list>
P76L37	     </query>
P76L38	   </iq>
P76L39	
P76L40	   As a result of creating and applying the foregoing list, the user
P76L41	   will not receive messages from any other users.
P76L42	
P76L43	10.10.  Blocking Inbound Presence Notifications
P76L44	
P76L45	   Server-side privacy lists enable a user to block incoming presence
P76L46	   notifications from other entities based on the entity's JID, roster
P76L47	   group, or subscription status (or globally).  The following examples
P76L48	   illustrate the protocol.
P77L1	   Note: Presence notifications do not include presence subscriptions,
P77L2	   only presence information that is broadcasted to the user because the
P77L3	   user is currently subscribed to a contact's presence information.
P77L4	   Thus this includes presence stanzas with no 'type' attribute or of
P77L5	   type='unavailable' only.
P77L6	
P77L7	   Example: User blocks based on JID:
P77L8	
P77L9	   <iq from='romeo@example.net/orchard' type='set' id='presin1'>
P77L10	     <query xmlns='jabber:iq:privacy'>
P77L11	       <list name='presin-jid-example'>
P77L12	         <item type='jid'
P77L13	               value='tybalt@example.com'
P77L14	               action='deny'
P77L15	               order='7'>
P77L16	           <presence-in/>
P77L17	         </item>
P77L18	       </list>
P77L19	     </query>
P77L20	   </iq>
P77L21	
P77L22	   As a result of creating and applying the foregoing list, the user
P77L23	   will not receive presence notifications from the entity with the
P77L24	   specified JID.
P77L25	
P77L26	   Example: User blocks based on roster group:
P77L27	
P77L28	   <iq from='romeo@example.net/orchard' type='set' id='presin2'>
P77L29	     <query xmlns='jabber:iq:privacy'>
P77L30	       <list name='presin-group-example'>
P77L31	         <item type='group'
P77L32	               value='Enemies'
P77L33	               action='deny'
P77L34	               order='8'>
P77L35	           <presence-in/>
P77L36	         </item>
P77L37	       </list>
P77L38	     </query>
P77L39	   </iq>
P77L40	
P77L41	   As a result of creating and applying the foregoing list, the user
P77L42	   will not receive presence notifications from any entities in the
P77L43	   specified roster group.
P77L44	
P77L45	
P77L46	
P77L47	
P77L48	
P78L1	   Example: User blocks based on subscription type:
P78L2	
P78L3	   <iq from='romeo@example.net/orchard' type='set' id='presin3'>
P78L4	     <query xmlns='jabber:iq:privacy'>
P78L5	       <list name='presin-sub-example'>
P78L6	         <item type='subscription'
P78L7	               value='to'
P78L8	               action='deny'
P78L9	               order='9'>
P78L10	           <presence-in/>
P78L11	         </item>
P78L12	       </list>
P78L13	     </query>
P78L14	   </iq>
P78L15	
P78L16	   As a result of creating and applying the foregoing list, the user
P78L17	   will not receive presence notifications from any entities with the
P78L18	   specified subscription type.
P78L19	
P78L20	   Example: User blocks globally:
P78L21	
P78L22	   <iq from='romeo@example.net/orchard' type='set' id='presin4'>
P78L23	     <query xmlns='jabber:iq:privacy'>
P78L24	       <list name='presin-global-example'>
P78L25	         <item action='deny' order='11'>
P78L26	           <presence-in/>
P78L27	         </item>
P78L28	       </list>
P78L29	     </query>
P78L30	   </iq>
P78L31	
P78L32	   As a result of creating and applying the foregoing list, the user
P78L33	   will not receive presence notifications from any other users.
P78L34	
P78L35	10.11.  Blocking Outbound Presence Notifications
P78L36	
P78L37	   Server-side privacy lists enable a user to block outgoing presence
P78L38	   notifications to other entities based on the entity's JID, roster
P78L39	   group, or subscription status (or globally).  The following examples
P78L40	   illustrate the protocol.
P78L41	
P78L42	   Note: Presence notifications do not include presence subscriptions,
P78L43	   only presence information that is broadcasted to contacts because
P78L44	   those contacts are currently subscribed to the user's presence
P78L45	   information.  Thus this includes presence stanzas with no 'type'
P78L46	   attribute or of type='unavailable' only.
P78L47	
P78L48	
P79L1	   Example: User blocks based on JID:
P79L2	
P79L3	   <iq from='romeo@example.net/orchard' type='set' id='presout1'>
P79L4	     <query xmlns='jabber:iq:privacy'>
P79L5	       <list name='presout-jid-example'>
P79L6	         <item type='jid'
P79L7	               value='tybalt@example.com'
P79L8	               action='deny'
P79L9	               order='13'>
P79L10	           <presence-out/>
P79L11	         </item>
P79L12	       </list>
P79L13	     </query>
P79L14	   </iq>
P79L15	
P79L16	   As a result of creating and applying the foregoing list, the user
P79L17	   will not send presence notifications to the entity with the specified
P79L18	   JID.
P79L19	
P79L20	   Example: User blocks based on roster group:
P79L21	
P79L22	   <iq from='romeo@example.net/orchard' type='set' id='presout2'>
P79L23	     <query xmlns='jabber:iq:privacy'>
P79L24	       <list name='presout-group-example'>
P79L25	         <item type='group'
P79L26	               value='Enemies'
P79L27	               action='deny'
P79L28	               order='15'>
P79L29	           <presence-out/>
P79L30	         </item>
P79L31	       </list>
P79L32	     </query>
P79L33	   </iq>
P79L34	
P79L35	   As a result of creating and applying the foregoing list, the user
P79L36	   will not send presence notifications to any entities in the specified
P79L37	   roster group.
P79L38	
P79L39	   Example: User blocks based on subscription type:
P79L40	
P79L41	   <iq from='romeo@example.net/orchard' type='set' id='presout3'>
P79L42	     <query xmlns='jabber:iq:privacy'>
P79L43	       <list name='presout-sub-example'>
P79L44	         <item type='subscription'
P79L45	               value='from'
P79L46	               action='deny'
P79L47	               order='17'>
P79L48	           <presence-out/>
P80L1	         </item>
P80L2	       </list>
P80L3	     </query>
P80L4	   </iq>
P80L5	
P80L6	   As a result of creating and applying the foregoing list, the user
P80L7	   will not send presence notifications to any entities with the
P80L8	   specified subscription type.
P80L9	
P80L10	   Example: User blocks globally:
P80L11	
P80L12	   <iq from='romeo@example.net/orchard' type='set' id='presout4'>
P80L13	     <query xmlns='jabber:iq:privacy'>
P80L14	       <list name='presout-global-example'>
P80L15	         <item action='deny' order='23'>
P80L16	           <presence-out/>
P80L17	         </item>
P80L18	       </list>
P80L19	     </query>
P80L20	   </iq>
P80L21	
P80L22	   As a result of creating and applying the foregoing list, the user
P80L23	   will not send presence notifications to any other users.
P80L24	
P80L25	10.12.  Blocking IQ Stanzas
P80L26	
P80L27	   Server-side privacy lists enable a user to block incoming IQ stanzas
P80L28	   from other entities based on the entity's JID, roster group, or
P80L29	   subscription status (or globally).  The following examples illustrate
P80L30	   the protocol.
P80L31	
P80L32	   Example: User blocks based on JID:
P80L33	
P80L34	   <iq from='romeo@example.net/orchard' type='set' id='iq1'>
P80L35	     <query xmlns='jabber:iq:privacy'>
P80L36	       <list name='iq-jid-example'>
P80L37	         <item type='jid'
P80L38	               value='tybalt@example.com'
P80L39	               action='deny'
P80L40	               order='29'>
P80L41	           <iq/>
P80L42	         </item>
P80L43	       </list>
P80L44	     </query>
P80L45	   </iq>
P80L46	
P80L47	   As a result of creating and applying the foregoing list, the user
P80L48	   will not receive IQ stanzas from the entity with the specified JID.
P81L1	   Example: User blocks based on roster group:
P81L2	
P81L3	   <iq from='romeo@example.net/orchard' type='set' id='iq2'>
P81L4	     <query xmlns='jabber:iq:privacy'>
P81L5	       <list name='iq-group-example'>
P81L6	         <item type='group'
P81L7	               value='Enemies'
P81L8	               action='deny'
P81L9	               order='31'>
P81L10	           <iq/>
P81L11	         </item>
P81L12	       </list>
P81L13	     </query>
P81L14	   </iq>
P81L15	
P81L16	   As a result of creating and applying the foregoing list, the user
P81L17	   will not receive IQ stanzas from any entities in the specified roster
P81L18	   group.
P81L19	
P81L20	   Example: User blocks based on subscription type:
P81L21	
P81L22	   <iq from='romeo@example.net/orchard' type='set' id='iq3'>
P81L23	     <query xmlns='jabber:iq:privacy'>
P81L24	       <list name='iq-sub-example'>
P81L25	         <item type='subscription'
P81L26	               value='none'
P81L27	               action='deny'
P81L28	               order='17'>
P81L29	           <iq/>
P81L30	         </item>
P81L31	       </list>
P81L32	     </query>
P81L33	   </iq>
P81L34	
P81L35	   As a result of creating and applying the foregoing list, the user
P81L36	   will not receive IQ stanzas from any entities with the specified
P81L37	   subscription type.
P81L38	
P81L39	
P81L40	
P81L41	
P81L42	
P81L43	
P81L44	
P81L45	
P81L46	
P81L47	
P81L48	
P82L1	   Example: User blocks globally:
P82L2	
P82L3	   <iq from='romeo@example.net/orchard' type='set' id='iq4'>
P82L4	     <query xmlns='jabber:iq:privacy'>
P82L5	       <list name='iq-global-example'>
P82L6	         <item action='deny' order='1'>
P82L7	           <iq/>
P82L8	         </item>
P82L9	       </list>
P82L10	     </query>
P82L11	   </iq>
P82L12	
P82L13	   As a result of creating and applying the foregoing list, the user
P82L14	   will not receive IQ stanzas from any other users.
P82L15	
P82L16	10.13.  Blocking All Communication
P82L17	
P82L18	   Server-side privacy lists enable a user to block all stanzas from and
P82L19	   to other entities based on the entity's JID, roster group, or
P82L20	   subscription status (or globally).  Note that this includes
P82L21	   subscription-related presence stanzas, which are excluded by Blocking
P82L22	   Inbound Presence Notifications (Section 10.10).  The following
P82L23	   examples illustrate the protocol.
P82L24	
P82L25	   Example: User blocks based on JID:
P82L26	
P82L27	   <iq from='romeo@example.net/orchard' type='set' id='all1'>
P82L28	     <query xmlns='jabber:iq:privacy'>
P82L29	       <list name='all-jid-example'>
P82L30	         <item type='jid'
P82L31	               value='tybalt@example.com'
P82L32	               action='deny'
P82L33	               order='23'/>
P82L34	       </list>
P82L35	     </query>
P82L36	   </iq>
P82L37	
P82L38	   As a result of creating and applying the foregoing list, the user
P82L39	   will not receive any communications from, nor send any stanzas to,
P82L40	   the entity with the specified JID.
P82L41	
P82L42	   Example: User blocks based on roster group:
P82L43	
P82L44	   <iq from='romeo@example.net/orchard' type='set' id='all2'>
P82L45	     <query xmlns='jabber:iq:privacy'>
P82L46	       <list name='all-group-example'>
P82L47	         <item type='group'
P82L48	               value='Enemies'
P83L1	               action='deny'
P83L2	               order='13'/>
P83L3	       </list>
P83L4	     </query>
P83L5	   </iq>
P83L6	
P83L7	   As a result of creating and applying the foregoing list, the user
P83L8	   will not receive any communications from, nor send any stanzas to,
P83L9	   any entities in the specified roster group.
P83L10	
P83L11	   Example: User blocks based on subscription type:
P83L12	
P83L13	   <iq from='romeo@example.net/orchard' type='set' id='all3'>
P83L14	     <query xmlns='jabber:iq:privacy'>
P83L15	       <list name='all-sub-example'>
P83L16	         <item type='subscription'
P83L17	               value='none'
P83L18	               action='deny'
P83L19	               order='11'/>
P83L20	       </list>
P83L21	     </query>
P83L22	   </iq>
P83L23	
P83L24	   As a result of creating and applying the foregoing list, the user
P83L25	   will not receive any communications from, nor send any stanzas to,
P83L26	   any entities with the specified subscription type.
P83L27	
P83L28	   Example: User blocks globally:
P83L29	
P83L30	   <iq from='romeo@example.net/orchard' type='set' id='all4'>
P83L31	     <query xmlns='jabber:iq:privacy'>
P83L32	       <list name='all-global-example'>
P83L33	         <item action='deny' order='7'/>
P83L34	       </list>
P83L35	     </query>
P83L36	   </iq>
P83L37	
P83L38	   As a result of creating and applying the foregoing list, the user
P83L39	   will not receive any communications from, nor send any stanzas to,
P83L40	   any other users.
P83L41	
P83L42	10.14.  Blocked Entity Attempts to Communicate with User
P83L43	
P83L44	   If a blocked entity attempts to send message or presence stanzas to
P83L45	   the user, the user's server SHOULD silently drop the stanza and MUST
P83L46	   NOT return an error to the sending entity.
P83L47	
P83L48	
P84L1	   If a blocked entity attempts to send an IQ stanza of type "get" or
P84L2	   "set" to the user, the user's server MUST return to the sending
P84L3	   entity a <service-unavailable/> stanza error, since this is the
P84L4	   standard error code sent from a client that does not understand the
P84L5	   namespace of an IQ get or set.  IQ stanzas of other types SHOULD be
P84L6	   silently dropped by the server.
P84L7	
P84L8	   Example: Blocked entity attempts to send IQ get:
P84L9	
P84L10	   <iq type='get'
P84L11	       to='romeo@example.net'
P84L12	       from='tybalt@example.com/pda'
P84L13	       id='probing1'>
P84L14	     <query xmlns='jabber:iq:version'/>
P84L15	   </iq>
P84L16	
P84L17	   Example: Server returns error to blocked entity:
P84L18	
P84L19	   <iq type='error'
P84L20	       from='romeo@example.net'
P84L21	       to='tybalt@example.com/pda'
P84L22	       id='probing1'>
P84L23	     <query xmlns='jabber:iq:version'/>
P84L24	     <error type='cancel'>
P84L25	       <service-unavailable
P84L26	           xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P84L27	     </error>
P84L28	   </iq>
P84L29	
P84L30	10.15.  Higher-Level Heuristics
P84L31	
P84L32	   When building a representation of a higher-level privacy heuristic, a
P84L33	   client SHOULD use the simplest possible representation.
P84L34	
P84L35	   For example, the heuristic "block all communications with any user
P84L36	   not in my roster" could be constructed in any of the following ways:
P84L37	
P84L38	   o  allow communications from all JIDs in my roster (i.e., listing
P84L39	      each JID as a separate list item), but block communications with
P84L40	      everyone else
P84L41	
P84L42	   o  allow communications from any user who is in one of the groups
P84L43	      that make up my roster (i.e., listing each group as a separate
P84L44	      list item), but block communications from everyone else
P84L45	
P84L46	   o  allow communications from any user with whom I have a subscription
P84L47	      of 'both' or 'to' or 'from' (i.e., listing each subscription value
P84L48	      separately), but block communications from everyone else
P85L1	   o  block communications from anyone whose subscription state is
P85L2	      'none'
P85L3	
P85L4	   The final representation is the simplest and SHOULD be used; here is
P85L5	   the XML that would be sent in this case:
P85L6	
P85L7	   <iq type='set' id='heuristic1'>
P85L8	     <query xmlns='jabber:iq:privacy'>
P85L9	       <list name='heuristic-example'>
P85L10	         <item type='subscription'
P85L11	               value='none'
P85L12	               action='deny'
P85L13	               order='437'/>
P85L14	       </list>
P85L15	     </query>
P85L16	   </iq>
P85L17	
P85L18	11.  Server Rules for Handling XML Stanzas
P85L19	
P85L20	   Basic routing and delivery rules for servers are defined in
P85L21	   [XMPP-CORE].  This section defines additional rules for
P85L22	   XMPP-compliant instant messaging and presence servers.
P85L23	
P85L24	11.1.  Inbound Stanzas
P85L25	
P85L26	   If the hostname of the domain identifier portion of the JID contained
P85L27	   in the 'to' attribute of an inbound stanza matches a hostname of the
P85L28	   server itself and the JID contained in the 'to' attribute is of the
P85L29	   form <user@example.com> or <user@example.com/resource>, the server
P85L30	   MUST first apply any privacy lists (Section 10) that are in force,
P85L31	   then follow the rules defined below:
P85L32	
P85L33	   1.  If the JID is of the form <user@domain/resource> and an available
P85L34	       resource matches the full JID, the recipient's server MUST
P85L35	       deliver the stanza to that resource.
P85L36	
P85L37	   2.  Else if the JID is of the form <user@domain> or <user@domain/
P85L38	       resource> and the associated user account does not exist, the
P85L39	       recipient's server (a) SHOULD silently ignore the stanza (i.e.,
P85L40	       neither deliver it nor return an error) if it is a presence
P85L41	       stanza, (b) MUST return a <service-unavailable/> stanza error to
P85L42	       the sender if it is an IQ stanza, and (c) SHOULD return a
P85L43	       <service-unavailable/> stanza error to the sender if it is a
P85L44	       message stanza.
P85L45	
P85L46	   3.  Else if the JID is of the form <user@domain/resource> and no
P85L47	       available resource matches the full JID, the recipient's server
P85L48	       (a) SHOULD silently ignore the stanza (i.e., neither deliver it
P86L1	       nor return an error) if it is a presence stanza, (b) MUST return
P86L2	       a <service-unavailable/> stanza error to the sender if it is an
P86L3	       IQ stanza, and (c) SHOULD treat the stanza as if it were
P86L4	       addressed to <user@domain> if it is a message stanza.
P86L5	
P86L6	   4.  Else if the JID is of the form <user@domain> and there is at
P86L7	       least one available resource available for the user, the
P86L8	       recipient's server MUST follow these rules:
P86L9	
P86L10	       1.  For message stanzas, the server SHOULD deliver the stanza to
P86L11	           the highest-priority available resource (if the resource did
P86L12	           not provide a value for the <priority/> element, the server
P86L13	           SHOULD consider it to have provided a value of zero).  If two
P86L14	           or more available resources have the same priority, the
P86L15	           server MAY use some other rule (e.g., most recent connect
P86L16	           time, most recent activity time, or highest availability as
P86L17	           determined by some hierarchy of <show/> values) to choose
P86L18	           between them or MAY deliver the message to all such
P86L19	           resources.  However, the server MUST NOT deliver the stanza
P86L20	           to an available resource with a negative priority; if the
P86L21	           only available resource has a negative priority, the server
P86L22	           SHOULD handle the message as if there were no available
P86L23	           resources (defined below).  In addition, the server MUST NOT
P86L24	           rewrite the 'to' attribute (i.e., it MUST leave it as
P86L25	           <user@domain> rather than change it to <user@domain/
P86L26	           resource>).
P86L27	
P86L28	       2.  For presence stanzas other than those of type "probe", the
P86L29	           server MUST deliver the stanza to all available resources;
P86L30	           for presence probes, the server SHOULD reply based on the
P86L31	           rules defined in Presence Probes (Section 5.1.3).  In
P86L32	           addition, the server MUST NOT rewrite the 'to' attribute
P86L33	           (i.e., it MUST leave it as <user@domain> rather than change
P86L34	           it to <user@domain/resource>).
P86L35	
P86L36	       3.  For IQ stanzas, the server itself MUST reply on behalf of the
P86L37	           user with either an IQ result or an IQ error, and MUST NOT
P86L38	           deliver the IQ stanza to any of the available resources.
P86L39	           Specifically, if the semantics of the qualifying namespace
P86L40	           define a reply that the server can provide, the server MUST
P86L41	           reply to the stanza on behalf of the user; if not, the server
P86L42	           MUST reply with a <service-unavailable/> stanza error.
P86L43	
P86L44	   5.  Else if the JID is of the form <user@domain> and there are no
P86L45	       available resources associated with the user, how the stanza is
P86L46	       handled depends on the stanza type:
P86L47	
P86L48	
P87L1	       1.  For presence stanzas of type "subscribe", "subscribed",
P87L2	           "unsubscribe", and "unsubscribed", the server MUST maintain a
P87L3	           record of the stanza and deliver the stanza at least once
P87L4	           (i.e., when the user next creates an available resource); in
P87L5	           addition, the server MUST continue to deliver presence
P87L6	           stanzas of type "subscribe" until the user either approves or
P87L7	           denies the subscription request (see also Presence
P87L8	           Subscriptions (Section 5.1.6)).
P87L9	
P87L10	       2.  For all other presence stanzas, the server SHOULD silently
P87L11	           ignore the stanza by not storing it for later delivery or
P87L12	           replying to it on behalf of the user.
P87L13	
P87L14	       3.  For message stanzas, the server MAY choose to store the
P87L15	           stanza on behalf of the user and deliver it when the user
P87L16	           next becomes available, or forward the message to the user
P87L17	           via some other means (e.g., to the user's email account).
P87L18	           However, if offline message storage or message forwarding is
P87L19	           not enabled, the server MUST return to the sender a
P87L20	           <service-unavailable/> stanza error.  (Note: Offline message
P87L21	           storage and message forwarding are not defined in XMPP, since
P87L22	           they are strictly a matter of implementation and service
P87L23	           provisioning.)
P87L24	
P87L25	       4.  For IQ stanzas, the server itself MUST reply on behalf of the
P87L26	           user with either an IQ result or an IQ error.  Specifically,
P87L27	           if the semantics of the qualifying namespace define a reply
P87L28	           that the server can provide, the server MUST reply to the
P87L29	           stanza on behalf of the user; if not, the server MUST reply
P87L30	           with a <service-unavailable/> stanza error.
P87L31	
P87L32	11.2.  Outbound Stanzas
P87L33	
P87L34	   If the hostname of the domain identifier portion of the address
P87L35	   contained in the 'to' attribute of an outbound stanza matches a
P87L36	   hostname of the server itself, the server MUST deliver the stanza to
P87L37	   a local entity according the rules for Inbound Stanzas (Section
P87L38	   11.1).
P87L39	
P87L40	   If the hostname of the domain identifier portion of the address
P87L41	   contained in the 'to' attribute of an outbound stanza does not match
P87L42	   a hostname of the server itself, the server MUST attempt to route the
P87L43	   stanza to the foreign domain.  The recommended order of actions is as
P87L44	   follows:
P87L45	
P87L46	
P87L47	
P87L48	
P88L1	   1.  First attempt to resolve the foreign hostname using an [SRV]
P88L2	       Service of "xmpp-server" and Proto of "tcp", resulting in
P88L3	       resource records such as "_xmpp-server._tcp.example.com.", as
P88L4	       specified in [XMPP-CORE].
P88L5	
P88L6	   2.  If the "xmpp-server" address record resolution fails, attempt to
P88L7	       resolve the "_im" or "_pres" [SRV] Service as specified in
P88L8	       [IMP-SRV], using the "_im" Service for <message/> stanzas and the
P88L9	       "_pres" Service for <presence/> stanzas (it is up to the
P88L10	       implementation how to handle <iq/> stanzas).  This will result in
P88L11	       one or more resolutions of the form "_im.<proto>.example.com." or
P88L12	       "_pres.<proto>.example.com.", where "<proto>" would be a label
P88L13	       registered in the Instant Messaging SRV Protocol Label registry
P88L14	       or the Presence SRV Protocol Label registry: either "_xmpp" for
P88L15	       an XMPP-aware domain or some other IANA-registered label (e.g.,
P88L16	       "_simple") for a non-XMPP-aware domain.
P88L17	
P88L18	   3.  If both SRV address record resolutions fail, attempt to perform a
P88L19	       normal IPv4/IPv6 address record resolution to determine the IP
P88L20	       address using the "xmpp-server" port of 5269 registered with the
P88L21	       IANA, as specified in [XMPP-CORE].
P88L22	
P88L23	   Administrators of server deployments are strongly encouraged to keep
P88L24	   the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly
P88L25	   synchronized, since different implementations might perform the "_im"
P88L26	   and "_pres" lookups before the "xmpp-server" lookup.
P88L27	
P88L28	12.  IM and Presence Compliance Requirements
P88L29	
P88L30	   This section summarizes the specific aspects of the Extensible
P88L31	   Messaging and Presence Protocol that MUST be supported by instant
P88L32	   messaging and presence servers and clients in order to be considered
P88L33	   compliant implementations.  All such applications MUST comply with
P88L34	   the requirements specified in [XMPP-CORE].  The text in this section
P88L35	   specifies additional compliance requirements for instant messaging
P88L36	   and presence servers and clients; note well that the requirements
P88L37	   described here supplement but do not supersede the core requirements.
P88L38	   Note also that a server or client MAY support only presence or
P88L39	   instant messaging, and is not required to support both if only a
P88L40	   presence service or an instant messaging service is desired.
P88L41	
P88L42	12.1.  Servers
P88L43	
P88L44	   In addition to core server compliance requirements, an instant
P88L45	   messaging and presence server MUST additionally support the following
P88L46	   protocols:
P88L47	
P88L48	
P89L1	   o  All server-related instant messaging and presence syntax and
P89L2	      semantics defined in this document, including presence broadcast
P89L3	      on behalf of clients, presence subscriptions, roster storage and
P89L4	      manipulation, privacy lists, and IM-specific routing and delivery
P89L5	      rules
P89L6	
P89L7	12.2.  Clients
P89L8	
P89L9	   In addition to core client compliance requirements, an instant
P89L10	   messaging and presence client MUST additionally support the following
P89L11	   protocols:
P89L12	
P89L13	   o  Generation and handling of the IM-specific semantics of XML
P89L14	      stanzas as defined by the XML schemas, including the 'type'
P89L15	      attribute of message and presence stanzas as well as their child
P89L16	      elements
P89L17	
P89L18	   o  All client-related instant messaging syntax and semantics defined
P89L19	      in this document, including presence subscriptions, roster
P89L20	      management, and privacy lists
P89L21	
P89L22	   o  End-to-end object encryption as defined in End-to-End Object
P89L23	      Encryption in the Extensible Messaging and Presence Protocol
P89L24	      (XMPP) [XMPP-E2E]
P89L25	
P89L26	   A client MUST also handle addresses that are encoded as "im:" URIs as
P89L27	   specified in [CPIM], and MAY do so by removing the "im:" scheme and
P89L28	   entrusting address resolution to the server as specified under
P89L29	   Outbound Stanzas (Section 11.2).
P89L30	
P89L31	13.  Internationalization Considerations
P89L32	
P89L33	   For internationalization considerations, refer to the relevant
P89L34	   section of [XMPP-CORE].
P89L35	
P89L36	14.  Security Considerations
P89L37	
P89L38	   Core security considerations for XMPP are defined in the relevant
P89L39	   section of [XMPP-CORE].
P89L40	
P89L41	   Additional considerations that apply only to instant messaging and
P89L42	   presence applications of XMPP are defined in several places within
P89L43	   this memo; specifically:
P89L44	
P89L45	
P89L46	
P89L47	
P89L48	
P90L1	   o  When a server processes an inbound stanza of any kind whose
P90L2	      intended recipient is a user associated with one of the server's
P90L3	      hostnames, the server MUST first apply any privacy lists (Section
P90L4	      10) that are in force (see Server Rules for Handling XML Stanzas
P90L5	      (Section 11)).
P90L6	
P90L7	   o  When a server processes an inbound presence stanza of type "probe"
P90L8	      whose intended recipient is a user associated with one of the
P90L9	      server's hostnames, the server MUST NOT reveal the user's presence
P90L10	      information if the sender is an entity that is not authorized to
P90L11	      receive that information as determined by presence subscriptions
P90L12	      (see Client and Server Presence Responsibilities (Section 5.1)).
P90L13	
P90L14	   o  When a server processes an outbound presence stanza with no type
P90L15	      or of type "unavailable", it MUST follow the rules defined under
P90L16	      Client and Server Presence Responsibilities (Section 5.1) in order
P90L17	      to ensure that such presence information is not broadcasted to
P90L18	      entities that are not authorized to know such information.
P90L19	
P90L20	   o  When a server generates an error stanza in response to receiving a
P90L21	      stanza for a user who does not exist, the use of the
P90L22	      <service-unavailable/> error condition helps protect against
P90L23	      well-known dictionary attacks, since this is the same error
P90L24	      condition that is returned if, for instance, the namespace of an
P90L25	      IQ child element is not understood, or if offline message storage
P90L26	      or message forwarding is not enabled for a domain.
P90L27	
P90L28	15.  IANA Considerations
P90L29	
P90L30	   For a number of related IANA considerations, refer to the relevant
P90L31	   section of [XMPP-CORE].
P90L32	
P90L33	15.1.  XML Namespace Name for Session Data
P90L34	
P90L35	   A URN sub-namespace for session-related data in the Extensible
P90L36	   Messaging and Presence Protocol (XMPP) is defined as follows.  (This
P90L37	   namespace name adheres to the format defined in The IETF XML Registry
P90L38	   [XML-REG].)
P90L39	
P90L40	   URI: urn:ietf:params:xml:ns:xmpp-session
P90L41	   Specification: RFC 3921
P90L42	   Description: This is the XML namespace name for session-related data
P90L43	      in the Extensible Messaging and Presence Protocol (XMPP) as
P90L44	      defined by RFC 3921.
P90L45	   Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
P90L46	
P90L47	
P90L48	
P91L1	15.2.  Instant Messaging SRV Protocol Label Registration
P91L2	
P91L3	   Address Resolution for Instant Messaging and Presence [IMP-SRV]
P91L4	   defines an Instant Messaging SRV Protocol Label registry for
P91L5	   protocols that can provide services that conform to the "_im" SRV
P91L6	   Service label.  Because XMPP is one such protocol, the IANA registers
P91L7	   the "_xmpp" protocol label in the appropriate registry, as follows:
P91L8	
P91L9	   Protocol label: _xmpp
P91L10	   Specification: RFC 3921
P91L11	   Description: Instant messaging protocol label for the Extensible
P91L12	      Messaging and Presence Protocol (XMPP) as defined by RFC 3921.
P91L13	   Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
P91L14	
P91L15	15.3.  Presence SRV Protocol Label Registration
P91L16	
P91L17	   Address Resolution for Instant Messaging and Presence [IMP-SRV]
P91L18	   defines a Presence SRV Protocol Label registry for protocols that can
P91L19	   provide services that conform to the "_pres" SRV Service label.
P91L20	   Because XMPP is one such protocol, the IANA registers the "_xmpp"
P91L21	   protocol label in the appropriate registry, as follows:
P91L22	
P91L23	   Protocol label: _xmpp
P91L24	   Specification: RFC 3921
P91L25	   Description: Presence protocol label for the Extensible Messaging and
P91L26	      Presence Protocol (XMPP) as defined by RFC 3921.
P91L27	   Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
P91L28	
P91L29	16.  References
P91L30	
P91L31	16.1.  Normative References
P91L32	
P91L33	   [CPIM]      Peterson, J., "Common Profile for Instant Messaging
P91L34	               (CPIM)", RFC 3860, August 2004.
P91L35	
P91L36	   [IMP-REQS]  Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
P91L37	               Messaging/Presence Protocol Requirements", RFC 2779,
P91L38	               February 2000.
P91L39	
P91L40	   [IMP-SRV]   Peterson, J., "Address Resolution for Instant Messaging
P91L41	               and Presence", RFC 3861, August 2004.
P91L42	
P91L43	   [SRV]       Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
P91L44	               specifying the location of services (DNS SRV)", RFC 2782,
P91L45	               February 2000.
P91L46	
P91L47	   [TERMS]     Bradner, S., "Key words for use in RFCs to Indicate
P91L48	               Requirement Levels", BCP 14, RFC 2119, March 1997.
P92L1	   [XML]       Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
P92L2	               "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
P92L3	               REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
P92L4	
P92L5	   [XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in
P92L6	               XML", W3C REC-xml-names, January 1999,
P92L7	               <http://www.w3.org/TR/REC-xml-names>.
P92L8	
P92L9	   [XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence
P92L10	               Protocol (XMPP): Core", RFC 3920, October 2004.
P92L11	
P92L12	   [XMPP-E2E]  Saint-Andre, P., "End-to-End Object Encryption in the
P92L13	               Extensible Messaging and Presence Protocol (XMPP)", RFC
P92L14	               3923, October 2004.
P92L15	
P92L16	16.2.  Informative References
P92L17	
P92L18	   [IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
P92L19	               Presence and Instant Messaging", RFC 2778, February 2000.
P92L20	
P92L21	   [IRC]       Oikarinen, J. and D. Reed, "Internet Relay Chat
P92L22	               Protocol", RFC 1459, May 1993.
P92L23	
P92L24	   [JEP-0054]  Saint-Andre, P., "vcard-temp", JSF JEP 0054, March 2003.
P92L25	
P92L26	   [JEP-0077]  Saint-Andre, P., "In-Band Registration", JSF JEP 0077,
P92L27	               August 2004.
P92L28	
P92L29	   [JEP-0078]  Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078,
P92L30	               July 2004.
P92L31	
P92L32	   [JSF]       Jabber Software Foundation, "Jabber Software Foundation",
P92L33	               <http://www.jabber.org/>.
P92L34	
P92L35	   [VCARD]     Dawson, F. and T. Howes, "vCard MIME Directory Profile",
P92L36	               RFC 2426, September 1998.
P92L37	
P92L38	   [XML-REG]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
P92L39	               January 2004.
P92L40	
P92L41	
P92L42	
P92L43	
P92L44	
P92L45	
P92L46	
P92L47	
P92L48	
P93L1	Appendix A.  vCards
P93L2	
P93L3	   Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to
P93L4	   retrieve out-of-band contact information for other users (e.g.,
P93L5	   telephone number or email address).  An XML representation of the
P93L6	   vCard specification defined in RFC 2426 [VCARD] is in common use
P93L7	   within the Jabber community to provide such information but is out of
P93L8	   scope for XMPP (documentation of this protocol is contained in
P93L9	   [JEP-0054], published by the Jabber Software Foundation [JSF]).
P93L10	
P93L11	Appendix B.  XML Schemas
P93L12	
P93L13	   The following XML schemas are descriptive, not normative.  For
P93L14	   schemas defining the core features of XMPP, refer to [XMPP-CORE].
P93L15	
P93L16	B.1  jabber:client
P93L17	
P93L18	   <?xml version='1.0' encoding='UTF-8'?>
P93L19	
P93L20	   <xs:schema
P93L21	       xmlns:xs='http://www.w3.org/2001/XMLSchema'
P93L22	       targetNamespace='jabber:client'
P93L23	       xmlns='jabber:client'
P93L24	       elementFormDefault='qualified'>
P93L25	
P93L26	     <xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P93L27	
P93L28	     <xs:element name='message'>
P93L29	        <xs:complexType>
P93L30	           <xs:sequence>
P93L31	             <xs:choice minOccurs='0' maxOccurs='unbounded'>
P93L32	               <xs:element ref='subject'/>
P93L33	               <xs:element ref='body'/>
P93L34	               <xs:element ref='thread'/>
P93L35	             </xs:choice>
P93L36	             <xs:any     namespace='##other'
P93L37	                         minOccurs='0'
P93L38	                         maxOccurs='unbounded'/>
P93L39	             <xs:element ref='error'
P93L40	                         minOccurs='0'/>
P93L41	
P93L42	
P93L43	
P93L44	
P93L45	
P93L46	
P93L47	
P93L48	
P94L1	           </xs:sequence>
P94L2	           <xs:attribute name='from'
P94L3	                         type='xs:string'
P94L4	                         use='optional'/>
P94L5	           <xs:attribute name='id'
P94L6	                         type='xs:NMTOKEN'
P94L7	                         use='optional'/>
P94L8	           <xs:attribute name='to'
P94L9	                         type='xs:string'
P94L10	                         use='optional'/>
P94L11	           <xs:attribute name='type' use='optional' default='normal'>
P94L12	             <xs:simpleType>
P94L13	               <xs:restriction base='xs:NCName'>
P94L14	                 <xs:enumeration value='chat'/>
P94L15	                 <xs:enumeration value='error'/>
P94L16	                 <xs:enumeration value='groupchat'/>
P94L17	                 <xs:enumeration value='headline'/>
P94L18	                 <xs:enumeration value='normal'/>
P94L19	               </xs:restriction>
P94L20	             </xs:simpleType>
P94L21	           </xs:attribute>
P94L22	           <xs:attribute ref='xml:lang' use='optional'/>
P94L23	        </xs:complexType>
P94L24	     </xs:element>
P94L25	
P94L26	     <xs:element name='body'>
P94L27	       <xs:complexType>
P94L28	         <xs:simpleContent>
P94L29	           <xs:extension base='xs:string'>
P94L30	             <xs:attribute ref='xml:lang' use='optional'/>
P94L31	           </xs:extension>
P94L32	         </xs:simpleContent>
P94L33	       </xs:complexType>
P94L34	     </xs:element>
P94L35	
P94L36	     <xs:element name='subject'>
P94L37	       <xs:complexType>
P94L38	         <xs:simpleContent>
P94L39	           <xs:extension base='xs:string'>
P94L40	             <xs:attribute ref='xml:lang' use='optional'/>
P94L41	           </xs:extension>
P94L42	         </xs:simpleContent>
P94L43	       </xs:complexType>
P94L44	     </xs:element>
P94L45	
P94L46	     <xs:element name='thread' type='xs:NMTOKEN'/>
P94L47	
P94L48	     <xs:element name='presence'>
P95L1	       <xs:complexType>
P95L2	         <xs:sequence>
P95L3	           <xs:choice minOccurs='0' maxOccurs='unbounded'>
P95L4	             <xs:element ref='show'/>
P95L5	             <xs:element ref='status'/>
P95L6	             <xs:element ref='priority'/>
P95L7	           </xs:choice>
P95L8	           <xs:any     namespace='##other'
P95L9	                       minOccurs='0'
P95L10	                       maxOccurs='unbounded'/>
P95L11	           <xs:element ref='error'
P95L12	                       minOccurs='0'/>
P95L13	         </xs:sequence>
P95L14	         <xs:attribute name='from'
P95L15	                       type='xs:string'
P95L16	                       use='optional'/>
P95L17	         <xs:attribute name='id'
P95L18	                       type='xs:NMTOKEN'
P95L19	                       use='optional'/>
P95L20	         <xs:attribute name='to'
P95L21	                       type='xs:string'
P95L22	                       use='optional'/>
P95L23	         <xs:attribute name='type' use='optional'>
P95L24	           <xs:simpleType>
P95L25	             <xs:restriction base='xs:NCName'>
P95L26	               <xs:enumeration value='error'/>
P95L27	               <xs:enumeration value='probe'/>
P95L28	               <xs:enumeration value='subscribe'/>
P95L29	               <xs:enumeration value='subscribed'/>
P95L30	               <xs:enumeration value='unavailable'/>
P95L31	               <xs:enumeration value='unsubscribe'/>
P95L32	               <xs:enumeration value='unsubscribed'/>
P95L33	             </xs:restriction>
P95L34	           </xs:simpleType>
P95L35	         </xs:attribute>
P95L36	         <xs:attribute ref='xml:lang' use='optional'/>
P95L37	       </xs:complexType>
P95L38	     </xs:element>
P95L39	
P95L40	     <xs:element name='show'>
P95L41	       <xs:simpleType>
P95L42	         <xs:restriction base='xs:NCName'>
P95L43	           <xs:enumeration value='away'/>
P95L44	           <xs:enumeration value='chat'/>
P95L45	           <xs:enumeration value='dnd'/>
P95L46	           <xs:enumeration value='xa'/>
P95L47	         </xs:restriction>
P95L48	       </xs:simpleType>
P96L1	     </xs:element>
P96L2	
P96L3	     <xs:element name='status'>
P96L4	       <xs:complexType>
P96L5	         <xs:simpleContent>
P96L6	           <xs:extension base='xs:string'>
P96L7	             <xs:attribute ref='xml:lang' use='optional'/>
P96L8	           </xs:extension>
P96L9	         </xs:simpleContent>
P96L10	       </xs:complexType>
P96L11	     </xs:element>
P96L12	
P96L13	     <xs:element name='priority' type='xs:byte'/>
P96L14	
P96L15	     <xs:element name='iq'>
P96L16	       <xs:complexType>
P96L17	         <xs:sequence>
P96L18	           <xs:any     namespace='##other'
P96L19	                       minOccurs='0'/>
P96L20	           <xs:element ref='error'
P96L21	                       minOccurs='0'/>
P96L22	         </xs:sequence>
P96L23	         <xs:attribute name='from'
P96L24	                       type='xs:string'
P96L25	                       use='optional'/>
P96L26	         <xs:attribute name='id'
P96L27	                       type='xs:NMTOKEN'
P96L28	                       use='required'/>
P96L29	         <xs:attribute name='to'
P96L30	                       type='xs:string'
P96L31	                       use='optional'/>
P96L32	         <xs:attribute name='type' use='required'>
P96L33	           <xs:simpleType>
P96L34	             <xs:restriction base='xs:NCName'>
P96L35	               <xs:enumeration value='error'/>
P96L36	               <xs:enumeration value='get'/>
P96L37	               <xs:enumeration value='result'/>
P96L38	               <xs:enumeration value='set'/>
P96L39	             </xs:restriction>
P96L40	           </xs:simpleType>
P96L41	         </xs:attribute>
P96L42	         <xs:attribute ref='xml:lang' use='optional'/>
P96L43	       </xs:complexType>
P96L44	     </xs:element>
P96L45	
P96L46	     <xs:element name='error'>
P96L47	       <xs:complexType>
P96L48	         <xs:sequence  xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
P97L1	           <xs:group   ref='err:stanzaErrorGroup'/>
P97L2	           <xs:element ref='err:text'
P97L3	                       minOccurs='0'/>
P97L4	         </xs:sequence>
P97L5	         <xs:attribute name='code' type='xs:byte' use='optional'/>
P97L6	         <xs:attribute name='type' use='required'>
P97L7	           <xs:simpleType>
P97L8	             <xs:restriction base='xs:NCName'>
P97L9	               <xs:enumeration value='auth'/>
P97L10	               <xs:enumeration value='cancel'/>
P97L11	               <xs:enumeration value='continue'/>
P97L12	               <xs:enumeration value='modify'/>
P97L13	               <xs:enumeration value='wait'/>
P97L14	             </xs:restriction>
P97L15	           </xs:simpleType>
P97L16	         </xs:attribute>
P97L17	       </xs:complexType>
P97L18	     </xs:element>
P97L19	
P97L20	   </xs:schema>
P97L21	
P97L22	B.2  jabber:server
P97L23	
P97L24	   <?xml version='1.0' encoding='UTF-8'?>
P97L25	
P97L26	   <xs:schema
P97L27	       xmlns:xs='http://www.w3.org/2001/XMLSchema'
P97L28	       targetNamespace='jabber:server'
P97L29	       xmlns='jabber:server'
P97L30	       elementFormDefault='qualified'>
P97L31	
P97L32	     <xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>
P97L33	
P97L34	     <xs:element name='message'>
P97L35	        <xs:complexType>
P97L36	           <xs:sequence>
P97L37	             <xs:choice minOccurs='0' maxOccurs='unbounded'>
P97L38	               <xs:element ref='subject'/>
P97L39	               <xs:element ref='body'/>
P97L40	               <xs:element ref='thread'/>
P97L41	             </xs:choice>
P97L42	             <xs:any     namespace='##other'
P97L43	                         minOccurs='0'
P97L44	                         maxOccurs='unbounded'/>
P97L45	             <xs:element ref='error'
P97L46	                         minOccurs='0'/>
P97L47	           </xs:sequence>
P97L48	
P98L1	           <xs:attribute name='from'
P98L2	                         type='xs:string'
P98L3	                         use='required'/>
P98L4	           <xs:attribute name='id'
P98L5	                         type='xs:NMTOKEN'
P98L6	                         use='optional'/>
P98L7	           <xs:attribute name='to'
P98L8	                         type='xs:string'
P98L9	                         use='required'/>
P98L10	           <xs:attribute name='type' use='optional' default='normal'>
P98L11	             <xs:simpleType>
P98L12	               <xs:restriction base='xs:NCName'>
P98L13	                 <xs:enumeration value='chat'/>
P98L14	                 <xs:enumeration value='error'/>
P98L15	                 <xs:enumeration value='groupchat'/>
P98L16	                 <xs:enumeration value='headline'/>
P98L17	                 <xs:enumeration value='normal'/>
P98L18	               </xs:restriction>
P98L19	             </xs:simpleType>
P98L20	           </xs:attribute>
P98L21	           <xs:attribute ref='xml:lang' use='optional'/>
P98L22	        </xs:complexType>
P98L23	     </xs:element>
P98L24	
P98L25	     <xs:element name='body'>
P98L26	       <xs:complexType>
P98L27	         <xs:simpleContent>
P98L28	           <xs:extension base='xs:string'>
P98L29	             <xs:attribute ref='xml:lang' use='optional'/>
P98L30	           </xs:extension>
P98L31	         </xs:simpleContent>
P98L32	       </xs:complexType>
P98L33	     </xs:element>
P98L34	
P98L35	     <xs:element name='subject'>
P98L36	       <xs:complexType>
P98L37	         <xs:simpleContent>
P98L38	           <xs:extension base='xs:string'>
P98L39	             <xs:attribute ref='xml:lang' use='optional'/>
P98L40	           </xs:extension>
P98L41	         </xs:simpleContent>
P98L42	       </xs:complexType>
P98L43	     </xs:element>
P98L44	
P98L45	     <xs:element name='thread' type='xs:NMTOKEN'/>
P98L46	
P98L47	     <xs:element name='presence'>
P98L48	       <xs:complexType>
P99L1	         <xs:sequence>
P99L2	           <xs:choice minOccurs='0' maxOccurs='unbounded'>
P99L3	             <xs:element ref='show'/>
P99L4	             <xs:element ref='status'/>
P99L5	             <xs:element ref='priority'/>
P99L6	           </xs:choice>
P99L7	           <xs:any     namespace='##other'
P99L8	                       minOccurs='0'
P99L9	                       maxOccurs='unbounded'/>
P99L10	           <xs:element ref='error'
P99L11	                       minOccurs='0'/>
P99L12	         </xs:sequence>
P99L13	         <xs:attribute name='from'
P99L14	                       type='xs:string'
P99L15	                       use='required'/>
P99L16	         <xs:attribute name='id'
P99L17	                       type='xs:NMTOKEN'
P99L18	                       use='optional'/>
P99L19	         <xs:attribute name='to'
P99L20	                       type='xs:string'
P99L21	                       use='required'/>
P99L22	         <xs:attribute name='type' use='optional'>
P99L23	           <xs:simpleType>
P99L24	             <xs:restriction base='xs:NCName'>
P99L25	               <xs:enumeration value='error'/>
P99L26	               <xs:enumeration value='probe'/>
P99L27	               <xs:enumeration value='subscribe'/>
P99L28	               <xs:enumeration value='subscribed'/>
P99L29	               <xs:enumeration value='unavailable'/>
P99L30	               <xs:enumeration value='unsubscribe'/>
P99L31	               <xs:enumeration value='unsubscribed'/>
P99L32	             </xs:restriction>
P99L33	           </xs:simpleType>
P99L34	         </xs:attribute>
P99L35	         <xs:attribute ref='xml:lang' use='optional'/>
P99L36	       </xs:complexType>
P99L37	     </xs:element>
P99L38	
P99L39	     <xs:element name='show'>
P99L40	       <xs:simpleType>
P99L41	         <xs:restriction base='xs:NCName'>
P99L42	           <xs:enumeration value='away'/>
P99L43	           <xs:enumeration value='chat'/>
P99L44	           <xs:enumeration value='dnd'/>
P99L45	           <xs:enumeration value='xa'/>
P99L46	         </xs:restriction>
P99L47	       </xs:simpleType>
P99L48	     </xs:element>
P100L1	     <xs:element name='status'>
P100L2	       <xs:complexType>
P100L3	         <xs:simpleContent>
P100L4	           <xs:extension base='xs:string'>
P100L5	             <xs:attribute ref='xml:lang' use='optional'/>
P100L6	           </xs:extension>
P100L7	         </xs:simpleContent>
P100L8	       </xs:complexType>
P100L9	     </xs:element>
P100L10	
P100L11	     <xs:element name='priority' type='xs:byte'/>
P100L12	
P100L13	     <xs:element name='iq'>
P100L14	       <xs:complexType>
P100L15	         <xs:sequence>
P100L16	           <xs:any     namespace='##other'
P100L17	                       minOccurs='0'/>
P100L18	           <xs:element ref='error'
P100L19	                       minOccurs='0'/>
P100L20	         </xs:sequence>
P100L21	         <xs:attribute name='from'
P100L22	                       type='xs:string'
P100L23	                       use='required'/>
P100L24	         <xs:attribute name='id'
P100L25	                       type='xs:NMTOKEN'
P100L26	                       use='required'/>
P100L27	         <xs:attribute name='to'
P100L28	                       type='xs:string'
P100L29	                       use='required'/>
P100L30	         <xs:attribute name='type' use='required'>
P100L31	           <xs:simpleType>
P100L32	             <xs:restriction base='xs:NCName'>
P100L33	               <xs:enumeration value='error'/>
P100L34	               <xs:enumeration value='get'/>
P100L35	               <xs:enumeration value='result'/>
P100L36	               <xs:enumeration value='set'/>
P100L37	             </xs:restriction>
P100L38	           </xs:simpleType>
P100L39	         </xs:attribute>
P100L40	         <xs:attribute ref='xml:lang' use='optional'/>
P100L41	       </xs:complexType>
P100L42	     </xs:element>
P100L43	
P100L44	     <xs:element name='error'>
P100L45	       <xs:complexType>
P100L46	         <xs:sequence  xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
P100L47	           <xs:group   ref='err:stanzaErrorGroup'/>
P100L48	           <xs:element ref='err:text'
P101L1	                       minOccurs='0'/>
P101L2	         </xs:sequence>
P101L3	         <xs:attribute name='code' type='xs:byte' use='optional'/>
P101L4	         <xs:attribute name='type' use='required'>
P101L5	           <xs:simpleType>
P101L6	             <xs:restriction base='xs:NCName'>
P101L7	               <xs:enumeration value='auth'/>
P101L8	               <xs:enumeration value='cancel'/>
P101L9	               <xs:enumeration value='continue'/>
P101L10	               <xs:enumeration value='modify'/>
P101L11	               <xs:enumeration value='wait'/>
P101L12	             </xs:restriction>
P101L13	           </xs:simpleType>
P101L14	         </xs:attribute>
P101L15	       </xs:complexType>
P101L16	     </xs:element>
P101L17	
P101L18	   </xs:schema>
P101L19	
P101L20	B.3  session
P101L21	
P101L22	   <?xml version='1.0' encoding='UTF-8'?>
P101L23	
P101L24	   <xs:schema
P101L25	       xmlns:xs='http://www.w3.org/2001/XMLSchema'
P101L26	       targetNamespace='urn:ietf:params:xml:ns:xmpp-session'
P101L27	       xmlns='urn:ietf:params:xml:ns:xmpp-session'
P101L28	       elementFormDefault='qualified'>
P101L29	
P101L30	     <xs:element name='session' type='empty'/>
P101L31	
P101L32	     <xs:simpleType name='empty'>
P101L33	       <xs:restriction base='xs:string'>
P101L34	         <xs:enumeration value=''/>
P101L35	       </xs:restriction>
P101L36	     </xs:simpleType>
P101L37	
P101L38	   </xs:schema>
P101L39	
P101L40	B.4  jabber:iq:privacy
P101L41	
P101L42	   <?xml version='1.0' encoding='UTF-8'?>
P101L43	
P101L44	   <xs:schema
P101L45	       xmlns:xs='http://www.w3.org/2001/XMLSchema'
P101L46	       targetNamespace='jabber:iq:privacy'
P101L47	
P101L48	
P102L1	       xmlns='jabber:iq:privacy'
P102L2	       elementFormDefault='qualified'>
P102L3	
P102L4	     <xs:element name='query'>
P102L5	       <xs:complexType>
P102L6	         <xs:sequence>
P102L7	           <xs:element ref='active'
P102L8	                       minOccurs='0'/>
P102L9	           <xs:element ref='default'
P102L10	                       minOccurs='0'/>
P102L11	           <xs:element ref='list'
P102L12	                       minOccurs='0'
P102L13	                       maxOccurs='unbounded'/>
P102L14	         </xs:sequence>
P102L15	       </xs:complexType>
P102L16	     </xs:element>
P102L17	
P102L18	     <xs:element name='active'>
P102L19	       <xs:complexType>
P102L20	         <xs:simpleContent>
P102L21	           <xs:extension base='xs:NMTOKEN'>
P102L22	             <xs:attribute name='name'
P102L23	                           type='xs:string'
P102L24	                           use='optional'/>
P102L25	           </xs:extension>
P102L26	         </xs:simpleContent>
P102L27	       </xs:complexType>
P102L28	     </xs:element>
P102L29	
P102L30	     <xs:element name='default'>
P102L31	       <xs:complexType>
P102L32	         <xs:simpleContent>
P102L33	           <xs:extension base='xs:NMTOKEN'>
P102L34	             <xs:attribute name='name'
P102L35	                           type='xs:string'
P102L36	                           use='optional'/>
P102L37	           </xs:extension>
P102L38	         </xs:simpleContent>
P102L39	       </xs:complexType>
P102L40	     </xs:element>
P102L41	
P102L42	     <xs:element name='list'>
P102L43	       <xs:complexType>
P102L44	         <xs:sequence>
P102L45	           <xs:element ref='item'
P102L46	                       minOccurs='0'
P102L47	                       maxOccurs='unbounded'/>
P102L48	         </xs:sequence>
P103L1	         <xs:attribute name='name'
P103L2	                       type='xs:string'
P103L3	                       use='required'/>
P103L4	       </xs:complexType>
P103L5	     </xs:element>
P103L6	
P103L7	     <xs:element name='item'>
P103L8	       <xs:complexType>
P103L9	         <xs:sequence>
P103L10	           <xs:element name='iq'
P103L11	                       minOccurs='0'
P103L12	                       type='empty'/>
P103L13	           <xs:element name='message'
P103L14	                       minOccurs='0'
P103L15	                       type='empty'/>
P103L16	           <xs:element name='presence-in'
P103L17	                       minOccurs='0'
P103L18	                       type='empty'/>
P103L19	           <xs:element name='presence-out'
P103L20	                       minOccurs='0'
P103L21	                       type='empty'/>
P103L22	         </xs:sequence>
P103L23	         <xs:attribute name='action' use='required'>
P103L24	           <xs:simpleType>
P103L25	             <xs:restriction base='xs:NCName'>
P103L26	               <xs:enumeration value='allow'/>
P103L27	               <xs:enumeration value='deny'/>
P103L28	             </xs:restriction>
P103L29	           </xs:simpleType>
P103L30	         </xs:attribute>
P103L31	         <xs:attribute name='order'
P103L32	                       type='xs:unsignedInt'
P103L33	                       use='required'/>
P103L34	         <xs:attribute name='type' use='optional'>
P103L35	           <xs:simpleType>
P103L36	             <xs:restriction base='xs:NCName'>
P103L37	               <xs:enumeration value='group'/>
P103L38	               <xs:enumeration value='jid'/>
P103L39	               <xs:enumeration value='subscription'/>
P103L40	             </xs:restriction>
P103L41	           </xs:simpleType>
P103L42	         </xs:attribute>
P103L43	         <xs:attribute name='value'
P103L44	                       type='xs:string'
P103L45	                       use='optional'/>
P103L46	       </xs:complexType>
P103L47	     </xs:element>
P103L48	
P104L1	     <xs:simpleType name='empty'>
P104L2	       <xs:restriction base='xs:string'>
P104L3	         <xs:enumeration value=''/>
P104L4	       </xs:restriction>
P104L5	     </xs:simpleType>
P104L6	
P104L7	   </xs:schema>
P104L8	
P104L9	B.5  jabber:iq:roster
P104L10	
P104L11	   <?xml version='1.0' encoding='UTF-8'?>
P104L12	
P104L13	   <xs:schema
P104L14	       xmlns:xs='http://www.w3.org/2001/XMLSchema'
P104L15	       targetNamespace='jabber:iq:roster'
P104L16	       xmlns='jabber:iq:roster'
P104L17	       elementFormDefault='qualified'>
P104L18	
P104L19	     <xs:element name='query'>
P104L20	       <xs:complexType>
P104L21	         <xs:sequence>
P104L22	           <xs:element ref='item'
P104L23	                       minOccurs='0'
P104L24	                       maxOccurs='unbounded'/>
P104L25	         </xs:sequence>
P104L26	       </xs:complexType>
P104L27	     </xs:element>
P104L28	
P104L29	     <xs:element name='item'>
P104L30	       <xs:complexType>
P104L31	         <xs:sequence>
P104L32	           <xs:element ref='group'
P104L33	                       minOccurs='0'
P104L34	                       maxOccurs='unbounded'/>
P104L35	         </xs:sequence>
P104L36	         <xs:attribute name='ask' use='optional'>
P104L37	           <xs:simpleType>
P104L38	             <xs:restriction base='xs:NCName'>
P104L39	               <xs:enumeration value='subscribe'/>
P104L40	             </xs:restriction>
P104L41	           </xs:simpleType>
P104L42	         </xs:attribute>
P104L43	         <xs:attribute name='jid' type='xs:string' use='required'/>
P104L44	         <xs:attribute name='name' type='xs:string' use='optional'/>
P104L45	         <xs:attribute name='subscription' use='optional'>
P104L46	           <xs:simpleType>
P104L47	             <xs:restriction base='xs:NCName'>
P104L48	
P105L1	               <xs:enumeration value='both'/>
P105L2	               <xs:enumeration value='from'/>
P105L3	               <xs:enumeration value='none'/>
P105L4	               <xs:enumeration value='remove'/>
P105L5	               <xs:enumeration value='to'/>
P105L6	             </xs:restriction>
P105L7	           </xs:simpleType>
P105L8	         </xs:attribute>
P105L9	       </xs:complexType>
P105L10	     </xs:element>
P105L11	
P105L12	     <xs:element name='group' type='xs:string'/>
P105L13	
P105L14	   </xs:schema>
P105L15	
P105L16	Appendix C.  Differences Between Jabber IM/Presence Protocols and XMPP
P105L17	
P105L18	   This section is non-normative.
P105L19	
P105L20	   XMPP has been adapted from the protocols originally developed in the
P105L21	   Jabber open-source community, which can be thought of as "XMPP 0.9".
P105L22	   Because there exists a large installed base of Jabber implementations
P105L23	   and deployments, it may be helpful to specify the key differences
P105L24	   between the relevant Jabber protocols and XMPP in order to expedite
P105L25	   and encourage upgrades of those implementations and deployments to
P105L26	   XMPP.  This section summarizes the differences that relate
P105L27	   specifically to instant messaging and presence applications, while
P105L28	   the corresponding section of [XMPP-CORE] summarizes the differences
P105L29	   that relate to all XMPP applications.
P105L30	
P105L31	C.1  Session Establishment
P105L32	
P105L33	   The client-to-server authentication protocol developed in the Jabber
P105L34	   community assumed that every client is an IM client and therefore
P105L35	   initiated an IM session upon successful authentication and resource
P105L36	   binding, which are performed simultaneously (documentation of this
P105L37	   protocol is contained in [JEP-0078], published by the Jabber Software
P105L38	   Foundation [JSF]).  XMPP maintains a stricter separation between core
P105L39	   functionality and IM functionality; therefore, an IM session is not
P105L40	   created until the client specifically requests one using the protocol
P105L41	   defined under Session Establishment (Section 3).
P105L42	
P105L43	
P105L44	
P105L45	
P105L46	
P105L47	
P105L48	
P106L1	C.2  Privacy Lists
P106L2	
P106L3	   The Jabber community began to define a protocol for communications
P106L4	   blocking (privacy lists) in late 2001, but that effort was deprecated
P106L5	   once the XMPP Working Group was formed.  Therefore the protocol
P106L6	   defined under Blocking Communication (Section 10) is the only such
P106L7	   protocol defined for use in the Jabber community.
P106L8	
P106L9	Contributors
P106L10	
P106L11	   Most of the core aspects of the Extensible Messaging and Presence
P106L12	   Protocol were developed originally within the Jabber open-source
P106L13	   community in 1999.  This community was founded by Jeremie Miller, who
P106L14	   released source code for the initial version of the jabberd server in
P106L15	   January 1999.  Major early contributors to the base protocol also
P106L16	   included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave
P106L17	   Smith.  Work specific to instant messaging and presence by the XMPP
P106L18	   Working Group has concentrated especially on IM session establishment
P106L19	   and communication blocking (privacy lists); the session establishment
P106L20	   protocol was mainly developed by Rob Norris and Joe Hildebrand, and
P106L21	   the privacy lists protocol was originally contributed by Peter
P106L22	   Millard.
P106L23	
P106L24	Acknowledgements
P106L25	
P106L26	   Thanks are due to a number of individuals in addition to the
P106L27	   contributors listed.  Although it is difficult to provide a complete
P106L28	   list, the following individuals were particularly helpful in defining
P106L29	   the protocols or in commenting on the specifications in this memo:
P106L30	   Thomas Charron, Richard Dobson, Schuyler Heath, Jonathan Hogg, Craig
P106L31	   Kaes, Jacek Konieczny, Lisa Dusseault, Alexey Melnikov, Keith
P106L32	   Minkler, Julian Missig, Pete Resnick, Marshall Rose, Jean-Louis
P106L33	   Seguineau, Alexey Shchepin, Iain Shigeoka, and David Waite.  Thanks
P106L34	   also to members of the XMPP Working Group and the IETF community for
P106L35	   comments and feedback provided throughout the life of this memo.
P106L36	
P106L37	Author's Address
P106L38	
P106L39	   Peter Saint-Andre (editor)
P106L40	   Jabber Software Foundation
P106L41	
P106L42	   EMail: stpeter@jabber.org
P106L43	
P106L44	
P106L45	
P106L46	
P106L47	
P106L48	
P107L1	Full Copyright Statement
P107L2	
P107L3	   Copyright (C) The Internet Society (2004).
P107L4	
P107L5	   This document is subject to the rights, licenses and restrictions
P107L6	   contained in BCP 78, and except as set forth therein, the authors
P107L7	   retain all their rights.
P107L8	
P107L9	   This document and the information contained herein are provided on an
P107L10	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
P107L11	   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
P107L12	   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
P107L13	   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
P107L14	   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
P107L15	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
P107L16	
P107L17	Intellectual Property
P107L18	
P107L19	   The IETF takes no position regarding the validity or scope of any
P107L20	   Intellectual Property Rights or other rights that might be claimed to
P107L21	   pertain to the implementation or use of the technology described in
P107L22	   this document or the extent to which any license under such rights
P107L23	   might or might not be available; nor does it represent that it has
P107L24	   made any independent effort to identify any such rights.  Information
P107L25	   on the IETF's procedures with respect to rights in IETF Documents can
P107L26	   be found in BCP 78 and BCP 79.
P107L27	
P107L28	   Copies of IPR disclosures made to the IETF Secretariat and any
P107L29	   assurances of licenses to be made available, or the result of an
P107L30	   attempt made to obtain a general license or permission for the use of
P107L31	   such proprietary rights by implementers or users of this
P107L32	   specification can be obtained from the IETF on-line IPR repository at
P107L33	   http://www.ietf.org/ipr.
P107L34	
P107L35	   The IETF invites any interested party to bring to its attention any
P107L36	   copyrights, patents or patent applications, or other proprietary
P107L37	   rights that may cover technology that may be required to implement
P107L38	   this standard.  Please address the information to the IETF at ietf-
P107L39	   ipr@ietf.org.
P107L40	
P107L41	Acknowledgement
P107L42	
P107L43	   Funding for the RFC Editor function is currently provided by the
P107L44	   Internet Society.
P107L45	
P107L46	
P107L47	
P107L48