SIMPLE                                                      J. Rosenberg
Internet-Draft                                               dynamicsoft
Expires: August 15, 2004                               February January 15, 2005                                  July 17, 2004

  An

   Extensible Markup Language (XML) Format Formats for Representing Resource
                                 Lists
                  draft-ietf-simple-xcap-list-usage-02
                  draft-ietf-simple-xcap-list-usage-03

Status of this Memo

   This document is an Internet-Draft

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and is any of which I become aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026.
   RFC 3668.

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

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

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

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

   This Internet-Draft will expire on August January 15, 2004. 2005.

Copyright Notice

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

Abstract

   In multimedia communications, presence and instant messaging systems,
   there is a need to represent lists of define Uniform Resource Identifiers
   (URIs). These lists, (URIs) that
   represent services which typically reside on a server, can be
   subscribed to, in order to learn the presence status of are associated with a group of users. A  One
   example is a presence list service.  If a user sends a Session
   Initiation Protocol (SIP) INVITE SUBSCRIBE message can be sent to them, causing the creation URI representing
   the presence list service, the server will obtain the presence of a conference call. This the
   users in the associated group, and provide it to the sender.  To
   facilitate definition of these services, this specification defines an
   two Extensible Markup Language (XML) documents.  One document
   format for representing resource lists. Such
   contains service URIs, along with their service definition and a
   reference to the associated group of users.  The second document
   contains the user lists which are referenced from the first.  Both
   documents can be
   manipulated by clients using created and managed with the XML Configuration Access
   Protocol
   (XCAP), although other techniques are permitted. (XCAP).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  6
   3.  Structure of a  Resource List Lists Documents . . . . . . . . . . . . . . . . .  5
   4.  XML Schema . .  7
     3.1   Structure  . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Example Document
     3.2   Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Usage with XCAP
     3.3   Example Document . . . . . . . . . . . . . . . . . . . . . 11
     3.4   Usage with XCAP  . . 10
   6.1 Application Unique ID . . . . . . . . . . . . . . . . . . . 12
       3.4.1   Application Unique ID  . 10
   6.2 MIME Type . . . . . . . . . . . . . . . 12
       3.4.2   MIME Type  . . . . . . . . . . . 10
   6.3 XML Schema . . . . . . . . . . . 12
       3.4.3   XML Schema . . . . . . . . . . . . . . . . . 10
   6.4 Additional Constraints . . . . . 12
       3.4.4   Additional Constraints . . . . . . . . . . . . . . . 10
   6.5 . 13
       3.4.5   Data Semantics . . . . . . . . . . . . . . . . . . . . 13
       3.4.6   Naming Conventions . . . . 10
   6.6 Naming Conventions . . . . . . . . . . . . . . 13
       3.4.7   Resource Interdependencies . . . . . . . . 10
   6.7 Resource Interdependencies . . . . . . 14
       3.4.8   Authorization Policies . . . . . . . . . . . . 10
   6.8 Authorization Policies . . . . 14
   4.  RLS Services Documents . . . . . . . . . . . . . . . . 11
   7.  Security Considerations . . . . 15
     4.1   Structure  . . . . . . . . . . . . . . . 12
   8.  IANA Considerations . . . . . . . . . 15
     4.2   Schema . . . . . . . . . . . . 13
   8.1 XCAP Application Usage ID . . . . . . . . . . . . . . 16
     4.3   Example Document . . . . 13
   8.2 application/resource-lists+xml MIME Type . . . . . . . . . . . 13
   8.3 URN Sub-Namespace Registration for
       urn:ietf:params:xml:ns:resource-lists . . . . . . 17
     4.4   Usage with XCAP  . . . . . . 14
   8.4 Resource List Schema Registration . . . . . . . . . . . . . . 15
       Normative References . 18
       4.4.1   Application Unique ID  . . . . . . . . . . . . . . . . 18
       4.4.2   MIME Type  . . . . . 16
       Informative References . . . . . . . . . . . . . . . . . 18
       4.4.3   XML Schema . . . 17
       Author's Address . . . . . . . . . . . . . . . . . . . 18
       4.4.4   Additional Constraints . . . . . . . . 17
       Intellectual Property and Copyright Statements . . . . . . . . 18

1. Introduction

   In multimedia communications, presence and instant messaging systems,
   operations are frequently performed on lists of Uniform
       4.4.5   Data Semantics . . . . . . . . . . . . . . . . . . . . 19
       4.4.6   Naming Conventions . . . . . . . . . . . . . . . . . . 19
       4.4.7   Resource
   Identifiers (URIs). One such example is a presence list [13]. These
   lists are used by Session Initiation Protocol (SIP) for Instant
   Messaging and  Presence (SIMPLE) [9]Resource List Servers (RLS) [11]
   for processing list subscriptions. A presence list can also be used
   by a user agent that chooses to subscribe to each user in its
   presence list, rather than using a list subscription. In such a case,
   the client would read the list from local storage, and generate
   subscriptions to each member.

   It is common for users to share presence lists. As an example, user A
   may have three people in their list that they wish to tell user B
   about. User A would like to send Interdependencies . . . . . . . . . . . . . . 20
       4.4.8   Authorization Policies . . . . . . . . . . . . . . . . 22
     4.5   Usage of an email to user B with RLS Services Document by an
   attachment describing these three people. Should user B open the
   attachment, the three people can be added to their RLS  . . . . . . . 23
   5.  SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 25
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
     7.1   XCAP Application Usage IDs . . . . . . . . . . . . . . . . 27
       7.1.1   resource-lists . . . . . . . . . . . . . . . . . . . . 27
       7.1.2   rls-services . . . . . . . . . . . . . . . . . . . . . 27
     7.2   MIME Type Registrations  . . . . . . . . . . . . . . . . . 27
       7.2.1   application/resource-lists+xml . . . . . . . . . . . . 27
       7.2.2   application/rls-services+xml . . . . . . . . . . . . . 28
     7.3   URN Sub-Namespace Registrations  . . . . . . . . . . . . . 28
       7.3.1   urn:ietf:params:xml:ns:resource-lists  . . . . . . . . 28
       7.3.2   urn:ietf:params:xml:ns:rls-services  . . . . . . . . . 29
     7.4   Schema Registrations . . . . . . . . . . . . . . . . . . . 30
       7.4.1   urn:ietf:params:xml:schema:resource-lists  . . . . . . 30
       7.4.2   urn:ietf:params:xml:schema:rls-services  . . . . . . . 30
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 31
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 31
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32
       Intellectual Property and Copyright Statements . . . . . . . . 33

1.  Introduction

   The Session Initiation Protocol (SIP) [4] defines the SIP Uniform
   Resource Identifier (URI) as any resource to which a SIP request can
   be generated for the purposes of establishing some form of
   communications operation.  These URIs can represent users (for
   example, sip:joe@example.com).  The SIP URI can also represent a
   service, such as voicemail, conferencing, or a presence list.  A
   common pattern across such SIP services is that the service is
   defined, and associated with a URI.  In order to operate, that
   service needs to make use of a list of users (or, more generally, a
   list of resources).  When a SIP request is sent to the service URI,
   the server providing the service reads that list, and then performs
   some kind of operation against each resource on the list.  This is
   shown pictorially in Figure 1.

                                    /---\
                                   |     |
                                    \---/ Resource
                              +----|     |  List
                              |    |     |
                              |     \---/
                              |
                              |
                              |
                              |
                              V
                       +-------------+
                       |             | -------->
                       |    SIP      |
      ---------------> |  Service    | -------->
               service |             |
               URI     |             | -------->
                       +-------------+

                                Figure 1

   One important example of such a service is a presence [12] list
   service.  A presence list service allows a client to generate a SIP
   SUBSCRIBE request to ask for presence information for a list of
   users.  The presence list server obtains the presence for the users
   on the list, and provides them back to the client.  A presence list
   server is a specific case of a resource list server (RLS) [15], which
   allows a client to generate a SIP SUBSCRIBE request to ask for
   notifications of SIP events for a list of resources.

   Another example of such a service is an instant conference service.
   If a client sends a SIP INVITE request to the URI representing the
   instance conference service, the conference server will create a
   conference call containing the client and the associated group of
   users.

   It is very useful for a user of these systems to define the groups of
   users or resources (generally called a resource list) separately from
   the services which access those resource lists.  Indeed, there are
   usages for resource lists even in the absence of any associated
   network-based service.  As an example, rather than using a presence
   list service, a client might generate individual SUBSCRIBE requests
   to obtain the presence of each user in a locally stored presence
   list.  In such a case, there is a need for a format for storing the
   list locally on disk.  Furthermore, the user might wish to share the
   list with friends, and desire to email it to those friends.  This
   also requires a standardized format for the resource list.

   As such, this document defines two Extensible Markup Language (XML)
   document formats.  The first is used to represent resource lists,
   independent of any particular service.  The second is used to define
   service URIs for an RLS, and to associate a resource list with the
   service URI.  This document also defines an XML Configuration Access
   Protocol (XCAP) [10] application usage for managing each of these two
   documents.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

3.  Resource Lists Documents

3.1  Structure

   A resource lists document is an XML [2] document that MUST be
   well-formed and SHOULD be valid.  Resource lists documents MUST be
   based on XML 1.0 and MUST be encoded using UTF-8.  This specification
   makes use of XML namespaces for identifying resource lists documents
   and document fragments.  The namespace URI for elements defined by
   this specification is a URN [3], using the namespace identifier
   'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8].  This
   URN is:
      urn:ietf:params:xml:ns:resource-lists

   A resource lists document has the <resource-lists> element as the
   root element of the document.  This element has no attributes.  Its
   content is a sequence of one or more <list> elements, each of which
   defines a single resource list.

   Each <list> element can contain an optional "name" attribute.  This
   attribute is a handle for the list.  When present, it MUST be unique
   amongst all other <list> elements within the same parent element.

   Each <list> element is composed of an optional display name, a
   sequence of zero or more elements, each of which may be an <entry>
   element, a <list> element, an <entry-ref> element, or an <external>
   element, followed by any number of elements from other namespaces,
   for the purposes of extensibility.  The ability of a <list> element
   to contain other <list> elements means that a resource list can be
   hierarchically structured.  The <display-name> then allows for a
   human-friendly name to be associated with each level in the
   hierarchy.  An <entry> element describes a single resource, defined
   by a URI, that is part of the list.  An <entry-ref> element allows an
   entry in a document within the same XCAP root to be included by
   reference, rather than by value.  An <external> element contains a
   reference to a list stored on this or another server.

   The <entry> element describes a single resource.  The <entry> element
   has a single mandatory attribute, "uri".  This attribute is equal to
   the URI that is used to access the resource.  The resource list
   format itself does not constrain the type of URI that can be used.
   However, the service making use of the resource list may require
   specific URI schemes.  For example, RLS services will require URIs
   that represent subscribeable resources.  This includes the SIP and
   pres [16] URIs.  The "uri" attribute MUST be unique amongst all other
   "uri" attributes in <entry> elements within the same parent.
   Uniqueness is determined by case sensitive string comparisons.  As
   such, it is possible that two "uri" attributes will have the same URI
   when compared using the functional equality rules defined for that
   URI scheme, but different ones when compared using case sensitive
   string comparison.

   The <entry> element contains a sequence elements that provide
   information about the entry.  Only one such element is defined at
   this time, which is <display-name>.  This element provides a UTF-8
   encoded string, meant for consumption by a human user, that describes
   the resource.  Unlike the "name" attribute of the <entry> element,
   the <display-name> has no uniqueness requirements.  The
   <display-name> element can contain the "xml:lang" attribute, which
   provides the language of the display name.  The <entry> element can
   contain other elements from other namespaces.  This is meant to
   support the inclusion of other information about the entry, such as a
   phone number or postal address.

   The <entry-ref&gt element allows an entry to be included in the list
   by reference, rather than by value.  This element is only meaningful
   when the document was obtained through XCAP.  In such a case, the
   referenced entry has to exist within the same XCAP root.  The <entry
   element has a single mandatory attribute, "ref".  The "ref" attribute
   MUST be unique amongst all other "ref" attributes in <entry-ref>
   elements within the same parent.  Uniqueness is determined by case
   sensitive string comparisons.  The content of an <entry-ref> element
   is an optional display name, followed by any number of elements from
   other namespaces, for the purposes of extensibility.  The display
   name is useful for providing a localized nickname as an alternative
   to the name defined in the <entry> to which the <entry-ref> refers.

   The content of the "ref" attribute is a relative HTTP URL [7].
   Specifically, it MUST be a relative path reference, where the base
   URL is equal to the XCAP root URI of the document in which the
   <entry-ref> appears.  This relative URL, if resolved into an absolute
   URL according to the procedures in RFC 2396, MUST resolve to an
   <entry> element within a resource-lists document.  For example, if an
   <entry> element within a specific XCAP root was identified by the
   following HTTP URL:

   http://xcap.example.com/root/resource-lists/users/bill/
   mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/
   entry%5b@uri=%22sip:petri@example.com%22%5d

   If http://xcap.example.com/root is the XCAP root URI, then an
   <entry-ref> element pointing to this entry would have the form:

   <entry-ref ref="resource-lists/users/bill/
   mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/
   entry%5b@uri=%22sip:petri@example.com%22%5d"/>

   Note that line folding within the HTTP URL and XML attribute above
   are the purposes of readability only.  Also note that, as described
   in RFC 2396, the relative path URI does not begin with the "/".
   Since the relative URL used within the "ref" attribute must be a
   relative path URL, the "/" will never be present as the first
   character within the content of a "ref" attribute.  Since the content
   of the "ref" attribute is a valid HTTP URL, it must be escape encoded
   within the XML document.

   The <external> element is similar to the <entry-ref> element.  Like
   <entry-ref>, it is only meaningful in documents obtained from an XCAP
   server.  It too is a reference to content stored elsewhere.  However,
   it refers to an entire list, and furthermore, allows that list to be
   present on another server.  The <external> element has a single
   mandatory attribute, "anchor".  The "anchor" attribute MUST be unique
   amongst all other "anchor" attributes in <external> elements within
   the same parent.  Uniqueness is determined by case sensitive string
   comparisons.  The content of an <external> element is an optional
   <display-name> followed by any number of elements from another
   namespace, for the purposes of extensibility.  The value of the
   "anchor" attribute MUST be an absolute HTTP URL.  This URL MUST
   identify an XCAP resource, and in particular, it MUST represent a
   <list> element within a resource lists document.  The URL MUST be
   escape coded.

   For both the <entry-ref> and <external> elements, the responsibility
   of resolving their references falls upon the entity that is making
   use of the document.  When used in conjunction with XCAP, this means
   that the burden falls on the XCAP client.  If the XCAP client is a PC
   based application using the resource-lists document as a presence
   list, the references would likely be resolved upon explicit request
   by the user.  They can, of course, be resolved at any time.  If the
   XCAP client is an RLS itself, the references would be resolved when
   the RLS receives a SUBSCRIBE request for an RLS service associated
   with a resource list that contains one of these references (see
   below).  An XCAP server defined by this specification will not
   attempt to resolve the references before returning the document to
   the client.  Similarly, if, due to network errors or some other
   problem, the references cannot be resolved, the handling is specific
   to the usage of the document.  For resource lists being used by RLS
   services, the handling is discussed below.

3.2  Schema
   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="urn:ietf:params:xml:ns:resource-lists"
    elementFormDefault="qualified"
    attributeFormDefault="unqualified">
    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    <xs:complexType name="listType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:choice>
        <xs:element name="list">
         <xs:complexType>
          <xs:complexContent>
           <xs:extension base="listType"/>
          </xs:complexContent>
         </xs:complexType>
        </xs:element>
        <xs:element name="external" type="externalType"/>
        <xs:element name="entry" type="entryType"/>
        <xs:element name="entry-ref" type="entry-refType"/>
        <xs:any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
       </xs:choice>
      </xs:sequence>
      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="name" type="xs:string" use="optional"/>
    </xs:complexType>
    <xs:complexType name="entryType">
     <xs:sequence>
      <xs:element name="display-name" minOccurs="0">
       <xs:complexType>
        <xs:simpleContent>
         <xs:extension base="display-nameType"/>
        </xs:simpleContent>
       </xs:complexType>
      </xs:element>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="uri" type="xs:anyURI" use="required"/>
    </xs:complexType>
    <xs:complexType name="entry-refType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="ref" type="xs:anyURI" use="required"/>
    </xs:complexType>
    <xs:complexType name="externalType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
      <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="anchor" type="xs:anyURI"/>
    </xs:complexType>
    <xs:element name="resource-lists">
     <xs:complexType>
      <xs:sequence maxOccurs="unbounded">
       <xs:element name="list" type="listType"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>
    <xs:complexType name="display-nameType">
     <xs:simpleContent>
      <xs:extension base="xs:string">
       <xs:attribute ref="xml:lang"/>
      </xs:extension>
     </xs:simpleContent>
    </xs:complexType>
   </xs:schema>

3.3  Example Document

   The following is an example of a document compliant to the schema.
   All line feeds within element content is for display purposes only.

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <list name="friends">
     <entry uri="sip:bill@example.com">
      <display-name>Bill Doe</display-name>
     </entry>
     <entry-ref ref="resource-lists/users/bill/mylist/~~/resource-lists/l
   ist%5b@name=%22list1%22%5d/entry%5b@uri=%22sip:petri@example.com%22%5d"/>
     <list name="close-friends">
      <display-name>Close Friends</display-name>
      <entry uri="sip:joe@example.com">
       <display-name>Joe Smith</display-name>
      </entry>
      <entry uri="sip:nancy@example.com">
       <display-name>Nancy Gross</display-name>
      </entry>
      <external anchor="http://www.example.org/xcap/resource-lists/users/a
   /foo/~~/resource-lists/list%5b@name=%22mkting%22%5d">
        <display-name>Marketing</display-name>
       </external>
     </list>
    </list>
   </resource-lists>

3.4  Usage with XCAP

   Resource lists documents can be manipulated with XCAP.  This section
   provides the details necessary for such a usage.

3.4.1  Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree.  This
   specification defines the "resource-lists" AUID within the IETF tree,
   via the IANA registration in Section 7.

3.4.2  MIME Type

   The MIME type for this document is "application/resource-lists+xml".

3.4.3  XML Schema

   The XML Schema for this document is defined as the sole content of
   Section 3.2.

3.4.4  Additional Constraints

   In addition to the schema, there are constraints on the values
   present in the the "name" attribute of the <list> element, the "uri"
   attribute of the <external> element, the "ref" attribute of the
   <entry-ref> element and the "anchor" attribute of the <external>
   element.  These constraints are defined in Section 3.1.  Some of
   these constraints are enforced by the XCAP server.  Those constraints
   are:
   o  The "name" attribute in a <list> element MUST be unique amongst
      all other "name" attributes of <list> elements within the same
      parent element.
   o  The "uri" attribute in a <entry> element MUST be unique amongst
      all other "uri" attributes of <entry> elements within the same
      parent element.  Uniqueness is determined by case sensitive string
      comparison.
   o  The URI in the "ref" attribute of the <entry-ref> element MUST be
      unique amongst all other "ref" attributes of <entry-ref> elements
      within the same parent element.  Uniqueness is determined by case
      sensitive string comparison.  The value of the attribute MUST be a
      relative path reference.  Note that the server is not responsible
      for verifying that the reference resolves to an <entry> element in
      a document within the same XCAP root.
   o  The URI in the "anchor" attribute of the <external> element MUST
      be unique amongst all other "anchor" attributes of <external>
      elements within the same parent element.  Uniqueness is determined
      by case sensitive string comparison.  The value of the attribute
      MUST be an absolute HTTP URL.  Note that the server is not
      responsible for verifying that the URL resolves to a <list>
      element in a document.  Indeed, since the URL may reference a
      server in another domain, referential integrity cannot be
      guaranteed without adding substantial complexity to the system.

3.4.5  Data Semantics

   Semantics for the document content are provided in Section 3.1.

3.4.6  Naming Conventions

   Resource lists documents are usually identified as references from
   other application usages.  For example, an RLS services document
   contains a reference to the resource list it uses.

   Frequently, an XCAP client will wish to insert or remove an <entry>,
   <entry-ref> or <external> element from a document without having a
   cached copy of that document.  In such a case, the "uri" attribute of
   the <entry> element, the "ref" attribute of the <entry-ref> element
   or the "anchor" attribute of the <external> element is used as an
   index to select the element to operate upon.  The XCAP server will
   determine uniqueness by case sensitive string comparison.  However,
   each of these attributes contain URIs, and the URI equality rules for
   their schemes may allow for two URI to be the same, even if they are
   different by case sensitive string comparison.  As such, it is
   possible that a client will attempt a PUT or DELETE in an attempt to
   modify or remove an existing element, but instead, the PUT ends up
   inserting a new element, or the DELETE ends up returning an error
   response.

   To mitigate against this case, if the client knows that the user
   intent is to explicitly modify an existing element, as opposed to
   creating a new one, the client SHOULD make the request conditional,
   using an If-None-Match header field with a value of *.  This will
   cause the request to fail if it is not a replacement.

   If the XCAP client cannot determine whether the user intent is to
   create or replace, the client SHOULD canonicalize the URI before
   performing the operation.  For a SIP URI (often present in the "uri"
   attribute of the <entry> element), this canonicalization procedure is
   defined in Section 5.  We expect that the SIP URIs that will be
   placed into resource lists documents will usually be of the form
   sip:user@domain, and possibly include a user parameter.  The
   canonicalization rules work perfectly for these URIs.

   For HTTP URLs, a basic canonicalization algorithm is as follows.  If
   the the port in the URL is equal to the default port (80 for http
   URLs), the port is removed.  The hostname is converted to all
   lowercase.  Any characters that are escape encoded are un-escaped,
   and only re-escaped if they cannot be represented within their
   component of the URL.

3.4.7  Resource Interdependencies

   There are no resource interdependencies identified by this
   application usage.

3.4.8  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which is that only a user can read, write or modify their own
   documents.  A server can allow priveleged users to modify documents
   that they don't own, but the establishment and indication of such
   policies is outside the scope of this document.  It is anticipated
   that a future application usage will define which users are allowed
   to modify a list resource.

4.  RLS Services Documents

4.1  Structure

   An RLS services document is used to define URIs that represent
   services provided by a Resource List Server (RLS) as defined in [15].
   An RLS services document is an XML [2] document that MUST be
   well-formed and SHOULD be valid.  RLS services documents MUST be
   based on XML 1.0 and MUST be encoded using UTF-8.  This specification
   makes use of XML namespaces for identifying RLS services documents
   and document fragments.  The namespace URI for elements defined by
   this specification is a URN [3], using the namespace identifier
   'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8].  This
   URN is:
      urn:ietf:params:xml:ns:rls-services

   The root element of an rls-services document is <rls-services>.  It
   contains a sequence of <service> elements, each of which defines a
   service available at an RLS.

   Each <service> element has a single mandatory attribute, "uri".  This
   URI defines the resource associated with the service.  That is, if a
   client subscribes to that URI, they will obtain the service defined
   by the corresponding <service> element.  The <service> element
   contains child elements that define the service.  For an RLS service,
   very little service definition is needed - just the resource list to
   which the server will perform virtual subscriptions [15] and the set
   of event packages that the service supports.  The former can be
   conveyed in one of two ways.  There can be a <resource-list> element,
   which points to a <list> element in a resource-lists document, or
   there can be a <list> element, which includes the resource list
   directly.  The supported packages are contained in the <packages>
   element.  The <service> element can also contain elements from other
   namespaces, for the purposes of extensibility.

   By including the contents of the resource list directly, a user can
   create lists and add members to them with a single XCAP operation.
   However, the resulting list becomes "hidden" within the RLS service
   definition, and is not usable by other application usages.  For this
   reason, the <resource-list> element exists as an alternative.  It can
   reference a <list> element in a resource-lists document.  Since the
   list is separated from the service definition, it can be easily
   reused by other application usages.

   The <list> element is of the list type defined by the schema for
   resource lists.  It is discussed in Section 3.1.

   The <resource-list> element contains a URI.  This element is only
   meaningful when the document was obtained through XCAP.  The URI MUST
   be an absolute HTTP URL representing an XCAP element resource.  Its
   XCAP root MUST be the same as the XCAP root of the RLS services
   document.  When the RLS services document in present in a user's home
   directory, the HTTP URL MUST exist underneath the same user's home
   directory in the resource-lists application usage.  When the RLS
   services document is in the global directory, the HTTP URL MUST exist
   underneath any user's home directory in the resource-lists
   application usage.  In either case, the element referenced by the URI
   MUST be a <list> element within a resource-lists document.  All of
   these constraints except for the latter one (which is a referential
   integrity constraint) will be enforced by the XCAP server.

   The <packages> element contains a sequence of <package> elements.
   The content of each <package> element is the name of a SIP event
   package [14].  The <packages> element may also contain elements from
   additional namespaces, for the purposes of extensibility.  The
   <packages> element is optional.  When not present, it means that the
   RLS service will accept subscriptions for any event package.

4.2  Schema
   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:rls-services"
     xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
     xmlns="urn:ietf:params:xml:ns:rls-services"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">
    <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"/>
    <xs:element name="rls-services">
     <xs:complexType>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:element name="service" type="serviceType"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>
    <xs:complexType name="serviceType">
     <xs:sequence>
      <xs:choice>
       <xs:element name="resource-list" type="xs:anyURI"/>
       <xs:element name="list" type="rl:listType"/>
      </xs:choice>
      <xs:element name="packages" type="packagesType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
   maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="uri" type="xs:anyURI" use="required"/>
    </xs:complexType>
    <xs:complexType name="packagesType">
     <xs:sequence minOccurs="0" maxOccurs="unbounded">
      <xs:element name="package" type="packageType"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
   maxOccurs="unbounded"/>
     </xs:sequence>
    </xs:complexType>
    <xs:simpleType name="packageType">
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:schema>

4.3  Example Document

   This document shows two services.  One is sip:mybuddies@example.com,
   and the other is sip:marketing@example.com.  The former service
   references a resource list in a resource-lists document, and the
   latter one includes a list locally.  Both services are for the
   presence list.
   Doing event package only.

   <?xml version="1.0" encoding="UTF-8"?>
   <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
      xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <service uri="sip:mybuddies@example.com">
     <resource-list>http://xcap.example.com/resource-lists/users/joe/index/~~/
   resource-lists/list%5b@name=%22l1%22%5d</resource-list>
     <packages>
      <package>presence</package>
     </packages>
    </service>
    <service uri="sip:marketing@example.com">
      <list name="marketing">
        <rl:entry uri="sip:joe@example.com"/>
        <rl:entry uri="sip:sudhir@example.com"/>
      </list>
      <packages>
        <package>presence</package>
      </packages>
    </service>
   </rls-services>

4.4  Usage with XCAP

   RLS services documents can be manipulated with XCAP.  This section
   provides the details necessary for such a usage.

4.4.1  Application Unique ID

   XCAP requires application usages to define a unique application usage
   ID (AUID) in either the IETF tree or a vendor tree.  This
   specification defines the "rls-services" AUID within the IETF tree,
   via the IANA registration in Section 7.

4.4.2  MIME Type

   The MIME type for this document is "application/rls-services+xml".

4.4.3  XML Schema

   The XML Schema for this document is defined as the sole content of
   Section 4.2.

4.4.4  Additional Constraints

   In addition to the schema, there are constraints on the URIs present
   in the <service> and <resource-list> elements.  These constraints are
   defined in Section 3.1.  Some of these constraints are enforced by
   the XCAP server.  Those constraints are:
   o  The URI in the "uri" attribute of the <service> element MUST be
      unique amongst all other URIs in "uri" elements in any <service>
      element in any document on a particular server.  This uniqueness
      constraint spans across XCAP roots.  Furthermore, the URI MUST NOT
      correspond to an existing resource within the domain of the URI.
      If a server is asked to set the URI to something that already
      exists, the server MUST reject the request with a 409, and use the
      mechanisms defined in [10] to suggest alternate URIs that have not
      yet been allocated.
   o  The URI in a <resource-list> element MUST be an absolute URI.  The
      server MUST verify that the URI path contains "resource-lists" in
      the path segment corresponding to the AUID.  If the RLS services
      document is within the XCAP user tree (as opposed to the global
      tree), the server MUST verify that the XUI in the path is the same
      as the XUI in the URI of to the RLS services document.  These
      checks are made by examining the URI value, as opposed to
      de-referencing the URI.  The server is not responsible for
      verifying that the URI actually points to a <list> element within
      a valid resource lists document.
   o  In addition, an RLS services document can contain a <list>
      element, which in turn can contain <entry>, <entry-ref> and
      <external> elements.  The constraints defined for these elements
      in Section 3.4.6 MUST be enforced.
   o  In some cases, an XCAP client will wish to create a new RLS
      service, and wish to assign it a "vanity URI", such as
      sip:friends@example.com.  However, the client does not know
      whether this URI meets the uniqueness constraints defined above.
      In that case, it can simply attempt the creation operation, and if
      the result is a 409 that contains a detailed conflict report with
      the <uniqueness-failure> element, the client knows that the URI
      could not be assigned.  It can then retry with a different vanity
      URI, or use one of the suggestions in the detailed conflict
      report.
   o  If the client wishes to create a new RLS service, and it doesnt
      care what the URI is, the client creates a random one, and
      attempts the creation operation.  As discussed in [10], if this requires
      should fail the with a standardized format uniqueness conflict, the client can retry
      with different URIs with increasing randomness.

4.4.5  Data Semantics

   Semantics for exchanging the document content are provided in Section 4.1.

4.4.6  Naming Conventions

   Typically, there are two distinct XCAP clients that access RLS
   services documents.  The first is a client acting on behalf of the
   end user in the system.  This client edits and writes both resource
   lists over
   email, instant messaging, and RLS services documents as they are created or modified by
   the end user.  The other communications protocols. XCAP client is the RLS itself, which reads
   the RLS services documents in order to process SUBSCRIBE requests.

   To make it easier for an RLS to find the <service> element for a
   particular URI, the XCAP server maintains, within the global tree, a
   single RLS services document representing the union of all of the
   <service> elements across all documents created by all users within
   the same XCAP root.  There are is a single instance of this document, and
   its name is "index".  Thus, if the root services URI is
   http://xcap.example.com/root, the following is the URI that an RLS
   would use to fetch this index:

   http://xcap.example.com/root/rls-services/global/index

   As discussed below, this index is created from all of the documents
   in the user tree that have the name "index" as well.  An implication
   of this is that a client operating on behalf of a user SHOULD define
   its RLS services within that document.  If the root services URI is
   http://xcap.example.com/root, for user "joe" the URI for this
   document would be:

   http://xcap.example.com/root/rls-services/users/joe/index

   If a client elects to define RLS services in a different document,
   this document will not be "picked up" in the global index, and
   therefore, not used as an RLS service.

4.4.7  Resource Interdependencies

   As with other applications of application usages, the XML schema along with the XCAP
   resource lists besides presence
   lists. Another example is a list naming conventions describes most of recipients for the resource
   interdependencies applicable to this application usage.

   This application usage defines an instant
   message, or additional resource interdependence
   between a list single document in the global tree and all documents in the
   user tree with the name "index".  This global document is formed as
   the union of all of the index documents for all users to invite to within the same
   XCAP root.  In this case, the union operation implies that each
   <service> element in a conference bridge.

   This specification describes user document will also be present as a common format for representing such
   <service> element in the global document.  The inverse is true as
   well.  Every <service> element in the global document exists within a
   list, and
   user document within the same XCAP root.

   As an example, consider the RLS services document for describing user joe:

   <?xml version="1.0" encoding="UTF-8"?>
   <rls-services>
    <service uri="sip:mybuddies@example.com">
     <resource-list>http://xcap.example.com/resource-lists/users/joe/index/~~/
   resource-lists/list%5b@name=%22l1%22%5d</resource-list>
     <packages>
      <package>presence</package>
     </packages>
    </service>
   </rls-services>

   And consider the set of actions which may RLS services document for user bob:

   <?xml version="1.0" encoding="UTF-8"?>
   <rls-services>
    <service uri="sip:marketing@example.com">
      <list name="marketing">
        <rl:entry uri="sip:joe@example.com"/>
        <rl:entry uri="sip:sudhir@example.com"/>
      </list>
      <packages>
        <package>presence</package>
      </packages>
    </service>
   </rls-services>

   The global document at
   http://xcap.example.com/root/rls-services/global/index would look
   like:

   <?xml version="1.0" encoding="UTF-8"?>
   <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
      xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <service uri="sip:mybuddies@example.com">
     <resource-list>http://xcap.example.com/resource-lists/users/joe/index/~~/
   resource-lists/list%5b@name=%22l1%22%5d</resource-list>
     <packages>
      <package>presence</package>
     </packages>
    </service>
    <service uri="sip:marketing@example.com">
      <list name="marketing">
        <rl:entry uri="sip:joe@example.com"/>
        <rl:entry uri="sip:sudhir@example.com"/>
      </list>
      <packages>
        <package>presence</package>
      </packages>
    </service>
   </rls-services>

   The server MUST, at all times, be performed capable of processing requests made
   against the list. Lists can be hierarchical, global document, and can contain
   sub-lists referenced by its contents MUST reflect the
   current state of all the relevant user documents.  This requirement
   does not imply that the server must actually store this global
   document.  It is anticipated that most systems will dynamically
   construct the responses to any particular request against the
   document resource.

   The uniqueness constraint on the "uri" attribute of <service> will
   ensure that no two <service> elements in the global document have the
   same value of that attribute.

4.4.8  Authorization Policies

   This application usage does not modify the default XCAP authorization
   policy, which is that only a URI.

   Resource list documents user can be manipulated by clients using several
   means. One read, write or modify their own
   documents.  A server can allow priveleged users to modify documents
   that they don't own, but the establishment and indication of such mechanism
   policies is outside the XML Configuration Access Protocol
   (XCAP) [7]. This specification defines the details necessary for
   using XCAP to manage presence authorization documents.

2. Terminology

   In scope of this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" document.  It is anticipated
   that a future application usage will define which users are allowed
   to be interpreted as described in RFC 2119 [1] and
   indicate requirement levels for compliant implementations.

3. Structure of a Resource List

   A resource list is modify an XML [2] RLS services document.

   The index document that MUST be well-formed and
   SHOULD be valid. Resource list documents MUST be based maintained in the global tree represents sensitive
   information, as it contains the union of all of the information for
   all users on XML 1.0 and the server.  As such, its access MUST be encoded using UTF-8. restricted to
   trusted elements within domain of the server.  Typically, this would
   be limited to the RLSs that need access to this document.

4.5  Usage of an RLS Services Document by an RLS

   This specification makes use section discusses how an RLS, on receipt of XML
   namespaces for identifying resource list documents a SUBSCRIBE request,
   uses XCAP and the RLS services document
   fragments. The namespace URI to guide its operation.

   When an RLS receives a SUBSCRIBE request for elements defined by this
   specification is a URN [3], using URI (present in the namespace identifier 'ietf'
   defined by [5] and extended by RFC 3688 [6].
   Request URI), it obtains the <service> element whose uri attribute
   matches (based on URI equality) the URI in the SUBSCRIBE request.
   This URN is:

      urn:ietf:params:xml:ns:resource-lists

   A resource list document begins with makes no normative statements on how this might be
   accomplished.  The following paragraph provides one possible
   approach.

   The RLS canonicalizes the root element tag
   "resource-lists". Request URI as described in Section 5.  It consists of
   then performs an optional "mandatory-ns" element
   (defined in XCAP [7]), followed GET operation against the URI formed by any number
   combining the XCAP root with the document selector of "list" sub-elements,
   each the global
   index with a node selector of which the form "rls-services/
   service[@uri=<canonical-uri>]", where <canonical-uri> is a resource list. Other elements from different
   namespaces MAY be present for the purposes
   canonicalized version of extensibility; elements
   or attributes from unknown namespaces MUST be ignored. There are
   three attributes associated with the "list" element. The first is
   "name". This attribute Request URI.  If the response is a descriptive name 200
   OK, it will contain the service definition for that URI.

   Once the list. It MUST be
   unique <service> element has been obtained, it is examined.  If the
   <packages> element is present, and the event package in the SUBSCRIBE
   request is not amongst all other list those listed in the <package> elements within
   <packages>, the same parent
   element. It serves as a useful, but optional handle to identify a
   list.

   Each list element will also have boolean attributes which indicate a
   specific action that may request MUST be made against that list. This
   specification defines rejected with a single attribute - "subscribeable" - which
   indicates that the list may 489 (Bad Event)
   response code, as described in [14].  Otherwise, it SHOULD be subscribed
   processed.  The next step is to using authorize that the SIP event list
   specification [11]. This application usage does not provide any
   information on which users would be authorized client is allowed
   to subscribe to the
   list, however.

   Extensions to this application usage MAY define additional boolean
   elements, each within a different namespace, resource.  This can be done using the data
   defined in [13], for example.  Assuming the purposes of
   indicating other actions that may be peformed. When an attribute subscriber is
   absent, it implies authorized
   to subscribe to that resource, the operation subscription is not supported.

   The third other attribute, "uri" MAY be present. It provides a URI
   that can be used processed
   according to access the list, for example, using the SIP event
   notification extension for lists [11]. As a result, the URI MUST be
   either a SIP URI or a pres URI [12].

   Each "list" element is composed of procedures defined in [15].  This processing
   requires the RLS to compute a sequence of zero or more
   elements, each flat list of which may URIs that are to be an "entry" element,
   subscribed to.  If the <service> element had a "list" <list> element,
   an "entry-ref" it is
   extracted.  If the <service> element had a <resource-list> element, or an "external" element.
   its URI content is dereferenced.  The ability of a
   "list" element to contain other "list" elements means that result should be a resource
   list can <list>
   element.  If it is not, the request SHOULD be hierarchically structured. An "entry" element describes rejected with a
   single URI 502
   (Bad Gateway).  Otherwise, that <list> element is part of extracted.

   At this point the list. An "entry-ref" RLS has a <list> element allows an
   entry to be included by reference, rather than by value. in its possession.  The content
   of "entry-ref"
   next step is a URI that points to an "entry" element in obtain a flat list of URIs from this
   document or another. This URI MUST be an HTTP element.  To do
   that, it traverses the tree of elements rooted in the <list> element.
   Before traversal begins, the RLS initializes two lists - the "flat
   list", which will contain the flat list of URI identifying an XCAP
   resource. An "external" element after traversal, and
   the "traversed list", which contains a reference to a list stored
   on another server. The content of this element MUST also be an HTTP
   URI identifying an XCAP resource. URLs in
   <external> elements that have already been visited.  Once these lists
   are initialized, tree traversal begins.  A "list" element server can also contain
   elements from other namespaces, for the purposes of extensibility. use any
   tree-traversal ordering it likes, such as depth first search or
   breadth first search.  The "entry" processing at each element describes a single resource. The "entry" in the tree
   depends on the name of the element:
   o  If the element
   has two attributes:

      name: This optional attribute is a unique identifier amongst all
      other "entry" elements of <entry> the same parent.

      uri: This mandatory URI in the "uri" attribute of the
      element is a added to the flat list if it is not already present
      (based on case sensitive string equality) in that list, and the
      URI scheme represents one that is can be used to access the
      resource. It MUST be either a service
      subscriptions, such as SIP or [4] and pres URI.

   The "entry" element contains a sequence of other elements. Only one
   such [16].
   o  If the element is defined at this time, which is "display-name". This
   element provides a UTF-8 encoded string, meant for consumption by an <entry-ref>, the
   user, that describes relative path reference
      making up the resource. Unlike value of the "name" "ref" attribute is resolved into an
      absolute URL.  This is done using the procedures defined in
      Section 5.2 of RFC 2396 [7], using the
   entry element, XCAP root of the "display-name" has no uniqueness requirements.
   Other elements from other namespaces MAY be included. RLS
      services document as the base URL.  This absolute URL is meant
   to support resolved.
      If the inclusion of other information about result is not a 200 OK containing a <entry> element, the entry, such
   as
      SUBSCRIBE request SHOULD be rejected with a phone number or postal address.

4. XML Schema

   The following 502 (Bad Gateway).
      Otherwise, the <entry> element returned is processed as described
      in the XML schema definition of previous step.
   o  If the resource list:

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
   xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand"
   xmlns="urn:ietf:params:xml:ns:resource-lists"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:import namespace="urn:ietf:params:xml:ns:xcap-must-understand"/>
    <xs:element name="resource-lists">
     <xs:complexType>
      <xs:sequence>
       <xs:element ref="xcap:mandatory-ns" minOccurs="0"/>
       <xs:element name="list" type="listType" minOccurs="0"
        maxOccurs="unbounded"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>
    <xs:complexType name="listType">
     <xs:sequence maxOccurs="unbounded">
      <xs:choice>
       <xs:element name="list" minOccurs="0" maxOccurs="unbounded">
        <xs:complexType>
         <xs:complexContent>
          <xs:extension base="listType"/>
         </xs:complexContent>
        </xs:complexType>
       </xs:element>
       <xs:element name="external" type="xs:anyURI" minOccurs="0"
        maxOccurs="unbounded"/>
       <xs:element name="entry" type="entryType" minOccurs="0"
        maxOccurs="unbounded"/>
       <xs:element name="entry-ref" type="xs:anyURI" minOccurs="0"
        maxOccurs="unbounded"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
        maxOccurs="unbounded"/>
      </xs:choice>
     </xs:sequence>
     <xs:attribute name="name" type="xs:string" use="optional"/>
     <xs:attribute name="uri" type="xs:anyURI" use="optional"/>
     <xs:attribute name="subscribeable" type="xs:boolean" use="optional"/>
     <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
    <xs:complexType name="entryType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax"
       minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="name" type="xs:string" use="optional"/>
     <xs:attribute name="uri" type="xs:anyURI" use="required"/>
    </xs:complexType>
    <xs:simpleType name="display-nameType">
     <xs:restriction base="xs:string"/>
    </xs:simpleType>
   </xs:schema>

5. Example Document

   The following element is an example <external> element, the absolute URL making
      up the value of the "anchor" attribute of the element is examined.
      If the URL is on the traversed list, the server MUST cease
      traversing the tree, and SHOULD reject the SUBSCRIBE request with
      a document compliant 502 (Bad Gateway).  If the URL is not on the traversed list, the
      server adds the URL to the schema:

   ]]>

6. Usage with XCAP

   Resource list documents can be manipulated with XCAP. This section
   provides traversed list, and de-references the details necessary for such
      URL.  If the result is not a usage.

6.1 Application Unique ID

   XCAP requires application usages to define 200 OK containing an <list> element,
      the SUBSCRIBE request SHOULD be rejected with a unique application usage
   ID (AUID) 502 (Bad Gateway).
      Otherwise, the RLS replaces the <external< element in either its local
      copy of the IETF tree or a vendor tree. This
   specification defines with the "resource-lists" AUID within <list> element that was returned, and
      tree traversal continues.

   Because the IETF tree,
   via <external> element is used to dynamically construct the IANA registration in Section 8.

6.2 MIME Type

   The MIME type for this document
   tree, there is "application/resource-lists+xml".

6.3 XML Schema a posibility of recursive evaluation of references.
   The XML Schema for this document traversed list is defined as the sole content of
   Section 4.

6.4 Additional Constraints

   None.

6.5 Data Semantics

   Semantics for the document content are provided in Section 3.

6.6 Naming Conventions

   There are no naming conventions that need used to be defined for prevent this
   application usage. A subscription to a resource list will be from happening.

   Once the tree has been traversed, the RLS can create virtual
   subscriptions to a
   specific URI. That each URI will be one of in the "uri" attributes flat list, as defined in
   a list within one of [15].

   In the documents managed by processing steps outlined above, when an XCAP server.

6.7 Resource Interdependencies

   An XCAP server supporting this application usage need only worry
   about <entry-ref> or
   <external> element contains a single data interdependency - reference that cannot be resolved,
   failing the "uri" attribute of request is at SHOULD strength.  In some cases, an RLS may
   provide better service by creating virtual subscriptions to the list
   element.

   If URIs
   in the "uri" attribute is absent flat list that could be obtained, omitting those that could
   not.  Only in those cases should the SHOULD recommendation be
   ignored.

5.  SIP URI Canonicalization

   This section provides a document written technique for URI canonicalization.  This
   canonicalization produces a URI that, in most cases, is equal to an XCAP
   server, but the "subscribeable" flag
   original URI (where equality is true, based on the XCAP server MUST
   allocate a URI for this list. This allocated comparison rules in
   RFC 3261).  Furthermore, the canonicalized URI MUST will usually be globally
   unique, and MUST route
   lexically equivalent to an RLS which will handle list subscriptions
   for the list defined by the document. The server MUST set the uri
   attribute canonicalized version of any other URI
   equal to the document with this URI.

   A server MUST NOT delete original.

   To canonicalize the "uri" attribute, however, should a
   client change URI, the subscribeable flag to false after following steps are followed:
   1.  First, the server has
   allocated a URI.

   If domain part of the "uri" attribute URI is present in a document written converted into all
       lowercase, and any tokens (such as "user" or "transport" or
       "udp") are converted to an XCAP
   server, but all lowercase.
   2.  Secondly, the URI exists in another document managed by the server,
   the document is considered invalid. A server MUST reject such a
   request with a 409, and MAY include an XCAP error report in un-escape coded.  Then, it is re-coded.
       However, when it is recoded, the body
   indicating this condition. The server MAY suggest, using only characters that are coded
       are those which are not permitted to appear based on the "alt-ns"
   element, alternate suggestions for grammar
       of that portion of the URI.  For example, if a SIP URI that is not currently
   allocated.

6.8 Authorization Policies
       sip:%6aoe%20smith@example.com, it is decoded to "sip:joe
       smith@example.com" and the re-coded to
       sip:joe%20smith@example.com.  In the original URI, the character
       'j' was escape coded.  This application usage does is allowed, but not modify required, since
       the default XCAP authorization
   policy, which is that only grammar allows a user can read, write or modify their own
   documents. A server can allow priveleged users 'j' to modify documents appear in the user part.  As a
       result, it appears as 'j' after this step of canonicalization.
   3.  Thirdly, any URI parameters are reordered so that they don't own, but the establishment and indication appear in
       lexical order based on parameter name.  The ordering of such
   policies a
       character is outside determined by the scope US-ASCII numerical value of that
       character, with smaller numbers coming first.  Parameters are
       ordered with the leftmost character as most significant.  For
       parameters that contain only letters, this document. It is anticipated equivalent to an
       alphabetical ordering.
   4.  Finally, any header parameters are discarded.  This canonicalized
       URI is used instead of the original URI.

   If two URIs A and B are functionally equal (meaning that a future application usage will define which users they are allowed
   equal according to modify the URI comparison rules in RFC 3261), their
   canonicalized URIs are equal under case sensitive string comparison
   if the following are true:
   o  Neither URI contains header parameters
   o  If one of the URI contains a list resource.

7. URI parameter not defined in RFC
      3261, the other does as well.

6.  Security Considerations

   The configuration information defined by this application usage is contained in rls-services and resource-lists
   documents are particularly sensitive.  It represents the principle
   set of people with whom a user would like to communicate.  As a
   result, clients SHOULD use TLS when contacting servers in order to
   fetch this information.  Note that this does not represent a change in
   requirement strength from XCAP.

8. IANA Considerations

   There are several IANA considerations associated does not represent a change
   in requirement strength from XCAP.

7.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

7.1  XCAP Application Usage IDs

   This section registers two new XCAP Application Usage ID (AUID)
   according to the IANA procedures defined in [10].

7.1.1  resource-lists
      Name of the AUID: resource-lists
      Description: A resource lists application is any application that
      needs access to a list of resources, identified by a URI, to which
      operations, such as subscriptions, can be applied.

7.1.2  rls-services
      Name of the AUID: rls-services
      Description: An Resource List Server (RLS) services application is
      Session Initiation Protocol (SIP) application whereby a server
      receives SIP SUBSCRIBE requests for resource, and generates
      subscriptions towards the a resource list.

7.2  MIME Type Registrations

   This specification requests the registration of two new MIME types
   according to the procedures of RFC 2048 [9] and guidelines in RFC
   3023 [5].

7.2.1  application/resource-lists+xml
      MIME media type name: application
      MIME subtype name: resource-lists+xml
      Mandatory parameters: none
      Optional parameters: Same as charset parameter application/xml as
      specified in RFC 3023 [5].
      Encoding considerations: Same as encoding considerations of
      application/xml as specified in RFC 3023 [5].
      Security considerations: See Section 10 of RFC 3023 [5] and
      Section 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
      XXXX with the RFC number of this specification]].
      Interoperability considerations: none.
      Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
      Please replace XXXX with the RFC number of this
   specification.

8.1 XCAP Application Usage ID specification]]
      Applications which use this media type: This section registers a new XCAP Application Usage ID (AUID)
   according document type has
      been used to the IANA procedures defined in [7].

      Name of the AUID: resource-lists

      Description: A resource list application is any application that
      needs access support subscriptions to a list lists of resources, identified by a URI, to which
      operations, such as subscriptions, can be applied.

8.2 application/resource-lists+xml MIME Type users [15] for
      SIP-based presence [12].

      Additional Information:
         Magic Number: None
         File Extension: .rl or .xml
         Macintosh file type code: "TEXT"
         Personal and email address for further information: Jonathan
         Rosenberg, jdrosen@jdrosen.net
         Intended usage: COMMON
         Author/Change controller: The IETF.

7.2.2  application/rls-services+xml
      MIME media type name: application
      MIME subtype name: resource-lists+xml rls-services+xml
      Mandatory parameters: none
      Optional parameters: Same as charset parameter application/xml as
      specified in RFC 3023 [4]. [5].
      Encoding considerations: Same as encoding considerations of
      application/xml as specified in RFC 3023 [4]. [5].
      Security considerations: See Section 10 of RFC 3023 [4] [5] and
      Section 7 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
      XXXX with the RFC number of this specification. specification]].
      Interoperability considerations: none.
      Published specification: This document. RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
      Please replace XXXX with the RFC number of this specification]]
      Applications which use this media type: This document type has
      been used to support subscriptions to lists of users [11] [15] for
      SIP-based presence [9]. [12].
      Additional Information:
         Magic Number: None
         File Extension: .rl or .xml
         Macintosh file type code: "TEXT"
         Personal and email address for further information: Jonathan
         Rosenberg, jdrosen@jdrosen.net
         Intended usage: COMMON
         Author/Change controller: The IETF.

8.3

7.3  URN Sub-Namespace Registration for
    urn:ietf:params:xml:ns:resource-lists Registrations

   This section registers a two new XML namespace, as per the guidelines
   in RFC 3688 [6]. [8].

7.3.1  urn:ietf:params:xml:ns:resource-lists
      URI: The URI for this namespace is
      urn:ietf:params:xml:ns:resource-lists.
      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).

      XML:

                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>Resource Lists Namespace</title>
                </head>
                <body>
                  <h1>Namespace for Resource Lists</h1>
                  <h2>application/resource-lists+xml</h2>
                  <h2>urn:ietf:params:xml:ns:resource-lists</h2>
                  <p>See <a href="[[[URL href="[URL of published RFC]]]">RFCXXXX</a>.</p> RFC]">RFCXXXX [NOTE
   TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
   specification.]</a>.</p>
                </body>
                </html>
                END

8.4

7.3.2  urn:ietf:params:xml:ns:rls-services
      URI: The URI for this namespace is
      urn:ietf:params:xml:ns:rls-services.
      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).
      XML:

                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>Resource List Server (RLS) Services Namespace</title>
                </head>
                <body>
                  <h1>Namespace for Resource List Server (RLS) Services</h1>
                  <h2>urn:ietf:params:xml:ns:rls-services</h2>
                  <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE
   TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
   specification.]</a>.</p>
                </body>
                </html>
                END

7.4  Schema Registration Registrations

   This section registers an two XML schemas per the procedures in [8].

7.4.1  urn:ietf:params:xml:schema:resource-lists
      URI: urn:ietf:params:xml:schema:resource-lists
      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).
      The XML for this schema per can be found as the procedures in [6]. sole content of
      Section 3.2.

7.4.2  urn:ietf:params:xml:schema:rls-services
      URI: please assign. urn:ietf:params:xml:schema:rls-services
      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).
      The XML for this schema can be found as the sole content of
      Section 4. 4.2.

8.  References

8.1  Normative References

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

   [2]   Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         FirstEdition REC-xml-20001006, October 2000.

   [3]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [4]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [5]   Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
         3023, January 2001.

   [5]

   [6]   Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
         August 1999.

   [6]

   [7]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998.

   [8]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
         January 2004.

   [7]

   [9]   Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
         Mail Extensions (MIME) Part Four: Registration Procedures", BCP
         13, RFC 2048, November 1996.

   [10]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-01
         draft-ietf-simple-xcap-02 (work in progress), October 2003. February 2004.

8.2  Informative References

   [8]

   [11]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
         Instant Messaging", RFC 2778, February 2000.

   [9]

   [12]  Rosenberg, J., "A Presence Event Package for the Session
         Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
         in progress), January 2003.

   [10]

   [13]  Rosenberg, J., "Presence Authorization Rules",
         draft-ietf-simple-presence-rules-00 (work in progress), May
         2004.

   [14]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [11]

   [15]  Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
         Protocol (SIP) Event Notification Extension for  Resource
         Lists", draft-ietf-simple-event-list-04 (work in progress),
         June 2003.

   [12]

   [16]  Peterson, J., "Common Profile for Presence (CPP)",
         draft-ietf-impp-pres-04 (work in progress), October 2003.

   [13]

   [17]  Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
         Data Elements in Session Initiation  Protocol (SIP) for Instant
         Messaging and Presence Leveraging Extensions (SIMPLE) Systems",
         draft-ietf-simple-data-req-03 (work in progress), June 2003.

Author's Address

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. on-line IPR repository at
   http://www.ietf.org/ipr.

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

Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.

Disclaimer of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

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

   This document and the information contained herein is are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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