draft-ietf-simple-xcap-list-usage-02.txt   draft-ietf-simple-xcap-list-usage-03.txt 
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft dynamicsoft
Expires: August 15, 2004 February 15, 2004 Expires: January 15, 2005 July 17, 2004
An Extensible Markup Language (XML) Format for Representing Resource Extensible Markup Language (XML) Formats for Representing Resource
Lists Lists
draft-ietf-simple-xcap-list-usage-02 draft-ietf-simple-xcap-list-usage-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
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 The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2004. This Internet-Draft will expire on January 15, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
In multimedia communications, presence and instant messaging systems, In multimedia communications, presence and instant messaging systems,
there is a need to represent lists of Uniform Resource Identifiers there is a need to define Uniform Resource Identifiers (URIs) that
(URIs). These lists, which typically reside on a server, can be represent services which are associated with a group of users. One
subscribed to, in order to learn the presence status of a group of example is a presence list service. If a user sends a Session
users. A Session Initiation Protocol (SIP) INVITE message can be sent Initiation Protocol (SIP) SUBSCRIBE message to the URI representing
to them, causing the creation of a conference call. This the presence list service, the server will obtain the presence of the
specification defines an Extensible Markup Language (XML) document users in the associated group, and provide it to the sender. To
format for representing resource lists. Such a document can be facilitate definition of these services, this specification defines
manipulated by clients using the XML Configuration Access Protocol two Extensible Markup Language (XML) documents. One document
(XCAP), although other techniques are permitted. 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 created and managed with the XML Configuration Access
Protocol (XCAP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Structure of a Resource List . . . . . . . . . . . . . . . . . 5 3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 7
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . . 10 3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 11
6.1 Application Unique ID . . . . . . . . . . . . . . . . . . . . 10 3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 12
6.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 12
6.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 12
6.4 Additional Constraints . . . . . . . . . . . . . . . . . . . . 10 3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 12
6.5 Data Semantics . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.4 Additional Constraints . . . . . . . . . . . . . . . . 13
6.6 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 10 3.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 13
6.7 Resource Interdependencies . . . . . . . . . . . . . . . . . . 10 3.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 13
6.8 Authorization Policies . . . . . . . . . . . . . . . . . . . . 11 3.4.7 Resource Interdependencies . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 3.4.8 Authorization Policies . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 15
8.1 XCAP Application Usage ID . . . . . . . . . . . . . . . . . . 13 4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2 application/resource-lists+xml MIME Type . . . . . . . . . . . 13 4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.3 URN Sub-Namespace Registration for 4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 17
urn:ietf:params:xml:ns:resource-lists . . . . . . . . . . . . 14 4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 18
8.4 Resource List Schema Registration . . . . . . . . . . . . . . 15 4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 18
Normative References . . . . . . . . . . . . . . . . . . . . . 16 4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 18
Informative References . . . . . . . . . . . . . . . . . . . . 17 4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.4 Additional Constraints . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 18 4.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 19
4.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 19
4.4.7 Resource Interdependencies . . . . . . . . . . . . . . 20
4.4.8 Authorization Policies . . . . . . . . . . . . . . . . 22
4.5 Usage of an RLS Services Document by an 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 1. Introduction
In multimedia communications, presence and instant messaging systems, The Session Initiation Protocol (SIP) [4] defines the SIP Uniform
operations are frequently performed on lists of Uniform Resource Resource Identifier (URI) as any resource to which a SIP request can
Identifiers (URIs). One such example is a presence list [13]. These be generated for the purposes of establishing some form of
lists are used by Session Initiation Protocol (SIP) for Instant communications operation. These URIs can represent users (for
Messaging and Presence (SIMPLE) [9]Resource List Servers (RLS) [11] example, sip:joe@example.com). The SIP URI can also represent a
for processing list subscriptions. A presence list can also be used service, such as voicemail, conferencing, or a presence list. A
by a user agent that chooses to subscribe to each user in its common pattern across such SIP services is that the service is
presence list, rather than using a list subscription. In such a case, defined, and associated with a URI. In order to operate, that
the client would read the list from local storage, and generate service needs to make use of a list of users (or, more generally, a
subscriptions to each member. 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.
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 an email to user B with an \---/ Resource
attachment describing these three people. Should user B open the +----| | List
attachment, the three people can be added to their own presence list. | | |
Doing this requires a standardized format for exchanging lists over | \---/
email, instant messaging, and other communications protocols. |
|
|
|
V
+-------------+
| | -------->
| SIP |
---------------> | Service | -------->
service | |
URI | | -------->
+-------------+
There are other applications of resource lists besides presence Figure 1
lists. Another example is a list of recipients for an instant
message, or a list of users to invite to a conference bridge.
This specification describes a common format for representing such a One important example of such a service is a presence [12] list
list, and for describing the set of actions which may be performed service. A presence list service allows a client to generate a SIP
against the list. Lists can be hierarchical, and can contain SUBSCRIBE request to ask for presence information for a list of
sub-lists referenced by a URI. 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.
Resource list documents can be manipulated by clients using several Another example of such a service is an instant conference service.
means. One such mechanism is the XML Configuration Access Protocol If a client sends a SIP INVITE request to the URI representing the
(XCAP) [7]. This specification defines the details necessary for instance conference service, the conference server will create a
using XCAP to manage presence authorization documents. 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 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
indicate requirement levels for compliant implementations. indicate requirement levels for compliant implementations.
3. Structure of a Resource List 3. Resource Lists Documents
A resource list is an XML [2] document that MUST be well-formed and 3.1 Structure
SHOULD be valid. Resource list 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 list documents and document
fragments. The namespace URI for elements defined by this
specification is a URN [3], using the namespace identifier 'ietf'
defined by [5] and extended by RFC 3688 [6]. This URN is:
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 urn:ietf:params:xml:ns:resource-lists
A resource list document begins with the root element tag A resource lists document has the <resource-lists> element as the
"resource-lists". It consists of an optional "mandatory-ns" element root element of the document. This element has no attributes. Its
(defined in XCAP [7]), followed by any number of "list" sub-elements, content is a sequence of one or more <list> elements, each of which
each of which is a resource list. Other elements from different defines a single resource list.
namespaces MAY be present for the purposes 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 is a descriptive name for the list. It MUST be
unique amongst all other list elements within 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 Each <list> element can contain an optional "name" attribute. This
specific action that may be made against that list. This attribute is a handle for the list. When present, it MUST be unique
specification defines a single attribute - "subscribeable" - which amongst all other <list> elements within the same parent element.
indicates that the list may be subscribed to using the SIP event list
specification [11]. This application usage does not provide any
information on which users would be authorized to subscribe to the
list, however.
Extensions to this application usage MAY define additional boolean Each <list> element is composed of an optional display name, a
elements, each within a different namespace, for the purposes of sequence of zero or more elements, each of which may be an <entry>
indicating other actions that may be peformed. When an attribute is element, a <list> element, an <entry-ref> element, or an <external>
absent, it implies that the operation is not supported. 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 third other attribute, "uri" MAY be present. It provides a URI The <entry> element describes a single resource. The <entry> element
that can be used to access the list, for example, using the SIP event has a single mandatory attribute, "uri". This attribute is equal to
notification extension for lists [11]. As a result, the URI MUST be the URI that is used to access the resource. The resource list
either a SIP URI or a pres URI [12]. 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.
Each "list" element is composed of a sequence of zero or more The <entry> element contains a sequence elements that provide
elements, each of which may be an "entry" element, a "list" element, information about the entry. Only one such element is defined at
an "entry-ref" element, or an "external" element. The ability of a this time, which is <display-name>. This element provides a UTF-8
"list" element to contain other "list" elements means that a resource encoded string, meant for consumption by a human user, that describes
list can be hierarchically structured. An "entry" element describes a the resource. Unlike the "name" attribute of the <entry> element,
single URI that is part of the list. An "entry-ref" element allows an the <display-name> has no uniqueness requirements. The
entry to be included by reference, rather than by value. The content <display-name> element can contain the "xml:lang" attribute, which
of "entry-ref" is a URI that points to an "entry" element in this provides the language of the display name. The <entry> element can
document or another. This URI MUST be an HTTP URI identifying an XCAP contain other elements from other namespaces. This is meant to
resource. An "external" element contains a reference to a list stored support the inclusion of other information about the entry, such as a
on another server. The content of this element MUST also be an HTTP phone number or postal address.
URI identifying an XCAP resource. A "list" element can also contain
elements from other namespaces, for the purposes of extensibility.
The "entry" element describes a single resource. The "entry" element The <entry-ref&gt element allows an entry to be included in the list
has two attributes: 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.
name: This optional attribute is a unique identifier amongst all The content of the "ref" attribute is a relative HTTP URL [7].
other "entry" elements of the same parent. 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:
uri: This mandatory attribute is a URI that is used to access the http://xcap.example.com/root/resource-lists/users/bill/
resource. It MUST be either a SIP or pres URI. mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/
entry%5b@uri=%22sip:petri@example.com%22%5d
The "entry" element contains a sequence of other elements. Only one If http://xcap.example.com/root is the XCAP root URI, then an
such element is defined at this time, which is "display-name". This <entry-ref> element pointing to this entry would have the form:
element provides a UTF-8 encoded string, meant for consumption by the
user, that describes the resource. Unlike the "name" attribute of the
entry element, the "display-name" has no uniqueness requirements.
Other elements from other namespaces MAY be included. This is meant
to support the inclusion of other information about the entry, such
as a phone number or postal address.
4. XML Schema <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"/>
The following is the XML schema definition of the resource list: 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"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists" <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" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified"> xmlns="urn:ietf:params:xml:ns:resource-lists"
<xs:import namespace="urn:ietf:params:xml:ns:xcap-must-understand"/> elementFormDefault="qualified"
<xs:element name="resource-lists"> attributeFormDefault="unqualified">
<xs:complexType> <xs:import namespace="http://www.w3.org/XML/1998/namespace"
<xs:sequence> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<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:complexType name="listType">
<xs:sequence maxOccurs="unbounded"> <xs:sequence>
<xs:element name="display-name" type="display-nameType" minOccurs="0"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice> <xs:choice>
<xs:element name="list" minOccurs="0" maxOccurs="unbounded"> <xs:element name="list">
<xs:complexType> <xs:complexType>
<xs:complexContent> <xs:complexContent>
<xs:extension base="listType"/> <xs:extension base="listType"/>
</xs:complexContent> </xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="external" type="xs:anyURI" minOccurs="0" <xs:element name="external" type="externalType"/>
maxOccurs="unbounded"/> <xs:element name="entry" type="entryType"/>
<xs:element name="entry" type="entryType" minOccurs="0" <xs:element name="entry-ref" type="entry-refType"/>
maxOccurs="unbounded"/>
<xs:element name="entry-ref" type="xs:anyURI" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:choice> </xs:choice>
</xs:sequence> </xs:sequence>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/> <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>
<xs:complexType name="entryType"> <xs:complexType name="entryType">
<xs:sequence> <xs:sequence>
<xs:element name="display-name" type="display-nameType" minOccurs="0"/> <xs:element name="display-name" minOccurs="0">
<xs:any namespace="##other" processContents="lax" <xs:complexType>
minOccurs="0" maxOccurs="unbounded"/> <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:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="display-nameType"> <xs:complexType name="entry-refType">
<xs:restriction base="xs:string"/> <xs:sequence>
</xs:simpleType> <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> </xs:schema>
5. Example Document 3.3 Example Document
The following is an example of a document compliant to the schema: 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>
6. Usage with XCAP 3.4 Usage with XCAP
Resource list documents can be manipulated with XCAP. This section Resource lists documents can be manipulated with XCAP. This section
provides the details necessary for such a usage. provides the details necessary for such a usage.
6.1 Application Unique ID 3.4.1 Application Unique ID
XCAP requires application usages to define a unique application usage XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "resource-lists" AUID within the IETF tree, specification defines the "resource-lists" AUID within the IETF tree,
via the IANA registration in Section 8. via the IANA registration in Section 7.
6.2 MIME Type 3.4.2 MIME Type
The MIME type for this document is "application/resource-lists+xml". The MIME type for this document is "application/resource-lists+xml".
6.3 XML Schema 3.4.3 XML Schema
The XML Schema for this document is defined as the sole content of The XML Schema for this document is defined as the sole content of
Section 4. Section 3.2.
6.4 Additional Constraints 3.4.4 Additional Constraints
None. 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.
6.5 Data Semantics 3.4.5 Data Semantics
Semantics for the document content are provided in Section 3. Semantics for the document content are provided in Section 3.1.
6.6 Naming Conventions 3.4.6 Naming Conventions
There are no naming conventions that need to be defined for this Resource lists documents are usually identified as references from
application usage. A subscription to a resource list will be to a other application usages. For example, an RLS services document
specific URI. That URI will be one of the "uri" attributes defined in contains a reference to the resource list it uses.
a list within one of the documents managed by an XCAP server.
6.7 Resource Interdependencies 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.
An XCAP server supporting this application usage need only worry To mitigate against this case, if the client knows that the user
about a single data interdependency - the "uri" attribute of the list intent is to explicitly modify an existing element, as opposed to
element. 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 "uri" attribute is absent in a document written to an XCAP If the XCAP client cannot determine whether the user intent is to
server, but the "subscribeable" flag is true, the XCAP server MUST create or replace, the client SHOULD canonicalize the URI before
allocate a URI for this list. This allocated URI MUST be globally performing the operation. For a SIP URI (often present in the "uri"
unique, and MUST route to an RLS which will handle list subscriptions attribute of the <entry> element), this canonicalization procedure is
for the list defined by the document. The server MUST set the uri defined in Section 5. We expect that the SIP URIs that will be
attribute of the document with this URI. 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.
A server MUST NOT delete the "uri" attribute, however, should a For HTTP URLs, a basic canonicalization algorithm is as follows. If
client change the subscribeable flag to false after the server has the the port in the URL is equal to the default port (80 for http
allocated a URI. 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.
If the "uri" attribute is present in a document written to an XCAP 3.4.7 Resource Interdependencies
server, but 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 the body
indicating this condition. The server MAY suggest, using the "alt-ns"
element, alternate suggestions for a URI that is not currently
allocated.
6.8 Authorization Policies 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 This application usage does not modify the default XCAP authorization
policy, which is that only a user can read, write or modify their own policy, which is that only a user can read, write or modify their own
documents. A server can allow priveleged users to modify documents documents. A server can allow priveleged users to modify documents
that they don't own, but the establishment and indication of such that they don't own, but the establishment and indication of such
policies is outside the scope of this document. It is anticipated policies is outside the scope of this document. It is anticipated
that a future application usage will define which users are allowed that a future application usage will define which users are allowed
to modify a list resource. to modify a list resource.
7. Security Considerations 4. RLS Services Documents
The configuration information defined by this application usage is 4.1 Structure
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 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 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
should fail the with a uniqueness conflict, the client can retry
with different URIs with increasing randomness.
4.4.5 Data Semantics
Semantics for 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 and RLS services documents as they are created or modified by
the end user. The other 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 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 application usages, the XML schema along with the XCAP
resource naming conventions describes most of the resource
interdependencies applicable to this application usage.
This application usage defines an additional resource interdependence
between a 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 within the same
XCAP root. In this case, the union operation implies that each
<service> element in a user document will also be present as a
<service> element in the global document. The inverse is true as
well. Every <service> element in the global document exists within a
user document within the same XCAP root.
As an example, consider the RLS services document for 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 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 capable of processing requests made
against the global document, and 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 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 an RLS services document.
The index document maintained in the global tree represents sensitive
information, as it contains the union of all of the information for
all users on the server. As such, its access MUST be 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 section discusses how an RLS, on receipt of a SUBSCRIBE request,
uses XCAP and the RLS services document to guide its operation.
When an RLS receives a SUBSCRIBE request for a URI (present in the
Request URI), it obtains the <service> element whose uri attribute
matches (based on URI equality) the URI in the SUBSCRIBE request.
This document makes no normative statements on how this might be
accomplished. The following paragraph provides one possible
approach.
The RLS canonicalizes the Request URI as described in Section 5. It
then performs an XCAP GET operation against the URI formed by
combining the XCAP root with the document selector of the global
index with a node selector of the form "rls-services/
service[@uri=<canonical-uri>]", where <canonical-uri> is the
canonicalized version of the Request URI. If the response is a 200
OK, it will contain the service definition for that URI.
Once the <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 those listed in the <package> elements within
<packages>, the request MUST be rejected with a 489 (Bad Event)
response code, as described in [14]. Otherwise, it SHOULD be
processed. The next step is to authorize that the client is allowed
to subscribe to the resource. This can be done using the data
defined in [13], for example. Assuming the subscriber is authorized
to subscribe to that resource, the subscription is processed
according to the procedures defined in [15]. This processing
requires the RLS to compute a flat list of URIs that are to be
subscribed to. If the <service> element had a <list> element, it is
extracted. If the <service> element had a <resource-list> element,
its URI content is dereferenced. The result should be a <list>
element. If it is not, the request SHOULD be rejected with a 502
(Bad Gateway). Otherwise, that <list> element is extracted.
At this point the RLS has a <list> element in its possession. The
next step is to obtain a flat list of URIs from this 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 after traversal, and
the "traversed list", which contains a list of HTTP URLs in
<external> elements that have already been visited. Once these lists
are initialized, tree traversal begins. A server can use any
tree-traversal ordering it likes, such as depth first search or
breadth first search. The processing at each element in the tree
depends on the name of the element:
o If the element is <entry> the URI in the "uri" attribute of the
element is 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 can be used to service
subscriptions, such as SIP [4] and pres [16].
o If the element is an <entry-ref>, the relative path reference
making up the value of the "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 XCAP root of the RLS
services document as the base URL. This absolute URL is resolved.
If the result is not a 200 OK containing a <entry> element, the
SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway).
Otherwise, the <entry> element returned is processed as described
in the previous step.
o If the element is an <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 502 (Bad Gateway). If the URL is not on the traversed list, the
server adds the URL to the traversed list, and de-references the
URL. If the result is not a 200 OK containing an <list> element,
the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway).
Otherwise, the RLS replaces the <external< element in its local
copy of the tree with the <list> element that was returned, and
tree traversal continues.
Because the <external> element is used to dynamically construct the
tree, there is a posibility of recursive evaluation of references.
The traversed list is used to prevent this from happening.
Once the tree has been traversed, the RLS can create virtual
subscriptions to each URI in the flat list, as defined in [15].
In the processing steps outlined above, when an <entry-ref> or
<external> element contains a reference that cannot be resolved,
failing the request is at SHOULD strength. In some cases, an RLS may
provide better service by creating virtual subscriptions to the URIs
in the 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 technique for URI canonicalization. This
canonicalization produces a URI that, in most cases, is equal to the
original URI (where equality is based on the URI comparison rules in
RFC 3261). Furthermore, the canonicalized URI will usually be
lexically equivalent to the canonicalized version of any other URI
equal to the original.
To canonicalize the URI, the following steps are followed:
1. First, the domain part of the URI is converted into all
lowercase, and any tokens (such as "user" or "transport" or
"udp") are converted to all lowercase.
2. Secondly, the URI is un-escape coded. Then, it is re-coded.
However, when it is recoded, the only characters that are coded
are those which are not permitted to appear based on the grammar
of that portion of the URI. For example, if a SIP URI is
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 is allowed, but not required, since
the grammar allows a 'j' to 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 appear in
lexical order based on parameter name. The ordering of a
character is determined by the 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 is 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 they are
equal according to 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 URI parameter not defined in RFC
3261, the other does as well.
6. Security Considerations
The information 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.
7. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
8.1 XCAP Application Usage ID 7.1 XCAP Application Usage IDs
This section registers a new XCAP Application Usage ID (AUID) This section registers two new XCAP Application Usage ID (AUID)
according to the IANA procedures defined in [7]. according to the IANA procedures defined in [10].
7.1.1 resource-lists
Name of the AUID: resource-lists Name of the AUID: resource-lists
Description: A resource lists application is any application that
Description: A resource list application is any application that
needs access to a list of resources, identified by a URI, to which needs access to a list of resources, identified by a URI, to which
operations, such as subscriptions, can be applied. operations, such as subscriptions, can be applied.
8.2 application/resource-lists+xml MIME Type 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.
MIME media type name: application 7.2 MIME Type Registrations
MIME subtype name: resource-lists+xml 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 Mandatory parameters: none
Optional parameters: Same as charset parameter application/xml as Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [4]. specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [4]. application/xml as specified in RFC 3023 [5].
Security considerations: See Section 10 of RFC 3023 [5] and
Security considerations: See Section 10 of RFC 3023 [4] and Section 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
Section 7 of this specification. XXXX with the RFC number of this specification]].
Interoperability considerations: none. Interoperability considerations: none.
Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
Published specification: This document. Please replace XXXX with the RFC number of this specification]]
Applications which use this media type: This document type has Applications which use this media type: This document type has
been used to support subscriptions to lists of users [11] for been used to support subscriptions to lists of users [15] for
SIP-based presence [9]. SIP-based presence [12].
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .rl or .xml File Extension: .rl or .xml
Macintosh file type code: "TEXT" Macintosh file type code: "TEXT"
Personal and email address for further information: Jonathan Personal and email address for further information: Jonathan
Rosenberg, jdrosen@jdrosen.net Rosenberg, jdrosen@jdrosen.net
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: The IETF.
7.2.2 application/rls-services+xml
MIME media type name: application
MIME subtype name: rls-services+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]]
Applications which use this media type: This document type has
been used to support subscriptions to lists of 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. Author/Change controller: The IETF.
8.3 URN Sub-Namespace Registration for 7.3 URN Sub-Namespace Registrations
urn:ietf:params:xml:ns:resource-lists
This section registers a new XML namespace, as per the guidelines in This section registers two new XML namespace, as per the guidelines
RFC 3688 [6]. in RFC 3688 [8].
7.3.1 urn:ietf:params:xml:ns:resource-lists
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:resource-lists. urn:ietf:params:xml:ns:resource-lists.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
skipping to change at page 14, line 41 skipping to change at page 29, line 19
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Resource Lists Namespace</title> <title>Resource Lists Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Resource Lists</h1> <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 of published RFC]]]">RFCXXXX</a>.</p> <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> </body>
</html> </html>
END END
8.4 Resource List Schema Registration 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:
This section registers an XML schema per the procedures in [6]. 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
URI: please assign. 7.4 Schema Registrations
This section registers 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), Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net). Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 3.2.
7.4.2 urn:ietf:params:xml:schema:rls-services
URI: 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 The XML for this schema can be found as the sole content of
Section 4. Section 4.2.
Normative References 8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000. FirstEdition REC-xml-20001006, October 2000.
[3] Moats, R., "URN Syntax", RFC 2141, May 1997. [3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC [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. 3023, January 2001.
[5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, [6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999. August 1999.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
2004. Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[7] Rosenberg, J., "The Extensible Markup Language (XML) [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-01 January 2004.
(work in progress), October 2003.
Informative References [9] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
[8] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-02 (work in progress), February 2004.
8.2 Informative References
[11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000. Instant Messaging", RFC 2778, February 2000.
[9] Rosenberg, J., "A Presence Event Package for the Session [12] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003. in progress), January 2003.
[10] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [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. Notification", RFC 3265, June 2002.
[11] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation [15] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
Protocol (SIP) Event Notification Extension for Resource Protocol (SIP) Event Notification Extension for Resource
Lists", draft-ietf-simple-event-list-04 (work in progress), Lists", draft-ietf-simple-event-list-04 (work in progress),
June 2003. June 2003.
[12] Peterson, J., "Common Profile for Presence (CPP)", [16] Peterson, J., "Common Profile for Presence (CPP)",
draft-ietf-impp-pres-04 (work in progress), October 2003. draft-ietf-impp-pres-04 (work in progress), October 2003.
[13] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of [17] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of
Data Elements in Session Initiation Protocol (SIP) for Instant Data Elements in Session Initiation Protocol (SIP) for Instant
Messaging and Presence Leveraging Extensions (SIMPLE) Systems", Messaging and Presence Leveraging Extensions (SIMPLE) Systems",
draft-ietf-simple-data-req-03 (work in progress), June 2003. draft-ietf-simple-data-req-03 (work in progress), June 2003.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft dynamicsoft
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/