< draft-ietf-simple-xcap-list-usage-03.txt   draft-ietf-simple-xcap-list-usage-04.txt >
SIMPLE J. Rosenberg SIMPLE J. Rosenberg
Internet-Draft dynamicsoft Internet-Draft Cisco Systems
Expires: January 15, 2005 July 17, 2004 Expires: April 23, 2005 October 23, 2004
Extensible Markup Language (XML) Formats for Representing Resource Extensible Markup Language (XML) Formats for Representing Resource
Lists Lists
draft-ietf-simple-xcap-list-usage-03 draft-ietf-simple-xcap-list-usage-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 and any of which I become aware will be disclosed, in accordance with
RFC 3668. 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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 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 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 January 15, 2005. This Internet-Draft will expire on April 23, 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 define Uniform Resource Identifiers (URIs) that there is a need to define Uniform Resource Identifiers (URIs) that
represent services which are associated with a group of users. One represent services which are associated with a group of users. One
example is a presence list service. If a user sends a Session example is a resource list service. If a user sends a Session
Initiation Protocol (SIP) SUBSCRIBE message to the URI representing Initiation Protocol (SIP) SUBSCRIBE message to the URI representing
the presence list service, the server will obtain the presence of the the resource list service, the server will obtain the state of the
users in the associated group, and provide it to the sender. To users in the associated group, and provide it to the sender. To
facilitate definition of these services, this specification defines facilitate definition of these services, this specification defines
two Extensible Markup Language (XML) documents. One document two Extensible Markup Language (XML) documents. One document
contains service URIs, along with their service definition and a contains service URIs, along with their service definition and a
reference to the associated group of users. The second document reference to the associated group of users. The second document
contains the user lists which are referenced from the first. Both contains the user lists which are referenced from the first. Both
documents can created and managed with the XML Configuration Access documents can be created and managed with the XML Configuration
Protocol (XCAP). Access Protocol (XCAP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 7 3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 5
3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 11 3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 10
3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 12 3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 12 3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 11
3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 12 3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 12 3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 11
3.4.4 Additional Constraints . . . . . . . . . . . . . . . . 13 3.4.4 Additional Constraints . . . . . . . . . . . . . . . . 12
3.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 13 3.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 12
3.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 13 3.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 12
3.4.7 Resource Interdependencies . . . . . . . . . . . . . . 14 3.4.7 Resource Interdependencies . . . . . . . . . . . . . . 13
3.4.8 Authorization Policies . . . . . . . . . . . . . . . . 14 3.4.8 Authorization Policies . . . . . . . . . . . . . . . . 13
4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 15 4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 14
4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 17 4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 16
4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 18 4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 17
4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 18 4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 17
4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 18 4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 17
4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 17
4.4.4 Additional Constraints . . . . . . . . . . . . . . . . 18 4.4.4 Additional Constraints . . . . . . . . . . . . . . . . 17
4.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 19 4.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 19
4.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 19 4.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 19
4.4.7 Resource Interdependencies . . . . . . . . . . . . . . 20 4.4.7 Resource Interdependencies . . . . . . . . . . . . . . 19
4.4.8 Authorization Policies . . . . . . . . . . . . . . . . 22 4.4.8 Authorization Policies . . . . . . . . . . . . . . . . 21
4.5 Usage of an RLS Services Document by an RLS . . . . . . . 23 4.5 Usage of an RLS Services Document by an RLS . . . . . . . 22
5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 25 5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 24
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1.1 resource-lists . . . . . . . . . . . . . . . . . . . . 27 8.1 XCAP Application Unique IDs . . . . . . . . . . . . . . . 25
7.1.2 rls-services . . . . . . . . . . . . . . . . . . . . . 27 8.1.1 resource-lists . . . . . . . . . . . . . . . . . . . . 26
7.2 MIME Type Registrations . . . . . . . . . . . . . . . . . 27 8.1.2 rls-services . . . . . . . . . . . . . . . . . . . . . 26
7.2.1 application/resource-lists+xml . . . . . . . . . . . . 27 8.2 MIME Type Registrations . . . . . . . . . . . . . . . . . 26
7.2.2 application/rls-services+xml . . . . . . . . . . . . . 28 8.2.1 application/resource-lists+xml . . . . . . . . . . . . 26
7.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 28 8.2.2 application/rls-services+xml . . . . . . . . . . . . . 27
7.3.1 urn:ietf:params:xml:ns:resource-lists . . . . . . . . 28 8.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 28
7.3.2 urn:ietf:params:xml:ns:rls-services . . . . . . . . . 29 8.3.1 urn:ietf:params:xml:ns:resource-lists . . . . . . . . 28
7.4 Schema Registrations . . . . . . . . . . . . . . . . . . . 30 8.3.2 urn:ietf:params:xml:ns:rls-services . . . . . . . . . 29
7.4.1 urn:ietf:params:xml:schema:resource-lists . . . . . . 30 8.4 Schema Registrations . . . . . . . . . . . . . . . . . . . 29
7.4.2 urn:ietf:params:xml:schema:rls-services . . . . . . . 30 8.4.1 urn:ietf:params:xml:schema:resource-lists . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.4.2 urn:ietf:params:xml:schema:rls-services . . . . . . . 30
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
8.2 Informative References . . . . . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 32 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 33 10.2 Informative References . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . 32
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [4] defines the SIP Uniform The Session Initiation Protocol (SIP) [4] defines the SIP Uniform
Resource Identifier (URI) as any resource to which a SIP request can Resource Identifier (URI) as any resource to which a SIP request can
be generated for the purposes of establishing some form of be generated for the purposes of establishing some form of
communications operation. These URIs can represent users (for communications operation. These URIs can represent users (for
example, sip:joe@example.com). The SIP URI can also represent a example, sip:joe@example.com). The SIP URI can also represent a
service, such as voicemail, conferencing, or a presence list. A service, such as voicemail, conferencing, or a presence list. A
common pattern across such SIP services is that the service is common pattern across such SIP services is that the service is
skipping to change at page 7, line 10 skipping to change at page 5, line 43
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. Resource Lists Documents 3. Resource Lists Documents
3.1 Structure 3.1 Structure
A resource lists document is an XML [2] document that MUST be A resource lists document is an XML [2] document that MUST be
well-formed and SHOULD be valid. Resource lists documents MUST be well-formed and MUST be valid according to schemas, including
based on XML 1.0 and MUST be encoded using UTF-8. This specification extension schemas, available to the validater and applicable to the
makes use of XML namespaces for identifying resource lists documents XML document. Resource lists documents MUST be based on XML 1.0 and
and document fragments. The namespace URI for elements defined by MUST be encoded using UTF-8. This specification makes use of XML
this specification is a URN [3], using the namespace identifier namespaces for identifying resource lists documents and document
'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8]. This fragments. The namespace URI for elements defined by this
URN is: 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 lists document has the <resource-lists> element as the A resource lists document has the <resource-lists> element as the
root element of the document. This element has no attributes. Its root element of the document. This element has no attributes. Its
content is a sequence of one or more <list> elements, each of which content is a sequence of one or more <list> elements, each of which
defines a single resource list. defines a single resource list.
Each <list> element can contain an optional "name" attribute. This Each <list> element can contain an optional "name" attribute. This
attribute is a handle for the list. When present, it MUST be unique attribute is a handle for the list. When present, it MUST be unique
amongst all other <list> elements within the same parent element. amongst all other <list> elements within the same parent element.
THe <list> element may also contain attributes from other namespaces,
for the purposes of extensibility.
Each <list> element is composed of an optional display name, a Each <list> element is composed of an optional display name, a
sequence of zero or more elements, each of which may be an <entry> 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, a <list> element, an <entry-ref> element, or an <external>
element, followed by any number of elements from other namespaces, element, followed by any number of elements from other namespaces,
for the purposes of extensibility. The ability of a <list> element for the purposes of extensibility. The ability of a <list> element
to contain other <list> elements means that a resource list can be to contain other <list> elements means that a resource list can be
hierarchically structured. The <display-name> then allows for a hierarchically structured. The <display-name> then allows for a
human-friendly name to be associated with each level in the human-friendly name to be associated with each level in the
hierarchy. An <entry> element describes a single resource, defined hierarchy. An <entry> element describes a single resource, defined
skipping to change at page 8, line 6 skipping to change at page 6, line 45
format itself does not constrain the type of URI that can be used. format itself does not constrain the type of URI that can be used.
However, the service making use of the resource list may require However, the service making use of the resource list may require
specific URI schemes. For example, RLS services will require URIs specific URI schemes. For example, RLS services will require URIs
that represent subscribeable resources. This includes the SIP and that represent subscribeable resources. This includes the SIP and
pres [16] URIs. The "uri" attribute MUST be unique amongst all other pres [16] URIs. The "uri" attribute MUST be unique amongst all other
"uri" attributes in <entry> elements within the same parent. "uri" attributes in <entry> elements within the same parent.
Uniqueness is determined by case sensitive string comparisons. As Uniqueness is determined by case sensitive string comparisons. As
such, it is possible that two "uri" attributes will have the same URI such, it is possible that two "uri" attributes will have the same URI
when compared using the functional equality rules defined for that when compared using the functional equality rules defined for that
URI scheme, but different ones when compared using case sensitive URI scheme, but different ones when compared using case sensitive
string comparison. string comparison. The <entry> element can also contain attributes
from other namespaces for the purposes of extensibility.
The <entry> element contains a sequence elements that provide The <entry> element contains a sequence of elements that provide
information about the entry. Only one such element is defined at information about the entry. Only one such element is defined at
this time, which is <display-name>. This element provides a UTF-8 this time, which is <display-name>. This element provides a UTF-8
encoded string, meant for consumption by a human user, that describes encoded string, meant for consumption by a human user, that describes
the resource. Unlike the "name" attribute of the <entry> element, the resource. Unlike the "name" attribute of the <entry> element,
the <display-name> has no uniqueness requirements. The the <display-name> has no uniqueness requirements. The
<display-name> element can contain the "xml:lang" attribute, which <display-name> element can contain the "xml:lang" attribute, which
provides the language of the display name. The <entry> element can provides the language of the display name. The <entry> element can
contain other elements from other namespaces. This is meant to contain other elements from other namespaces. This is meant to
support the inclusion of other information about the entry, such as a support the inclusion of other information about the entry, such as a
phone number or postal address. phone number or postal address.
The <entry-ref&gt element allows an entry to be included in the list The <entry-ref> element allows an entry to be included in the list by
by reference, rather than by value. This element is only meaningful reference, rather than by value. This element is only meaningful
when the document was obtained through XCAP. In such a case, the when the document was obtained through XCAP. In such a case, the
referenced entry has to exist within the same XCAP root. The <entry referenced entry has to exist within the same XCAP root. The <entry>
element has a single mandatory attribute, "ref". The "ref" attribute element has a single mandatory attribute, "ref". The "ref" attribute
MUST be unique amongst all other "ref" attributes in <entry-ref> MUST be unique amongst all other "ref" attributes in <entry-ref>
elements within the same parent. Uniqueness is determined by case elements within the same parent. Uniqueness is determined by case
sensitive string comparisons. The content of an <entry-ref> element sensitive string comparisons. The <entry-ref> element also allows
is an optional display name, followed by any number of elements from attributes from other namespaces, for the purposes of extensibility.
other namespaces, for the purposes of extensibility. The display The content of an <entry-ref> element is an optional display name,
name is useful for providing a localized nickname as an alternative followed by any number of elements from other namespaces, for the
to the name defined in the <entry> to which the <entry-ref> refers. 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]. The content of the "ref" attribute is a relative HTTP URL [7].
Specifically, it MUST be a relative path reference, where the base 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 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 <entry-ref> appears. This relative URL, if resolved into an absolute
URL according to the procedures in RFC 2396, MUST resolve to an 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 resource-lists document. For example, if an
<entry> element within a specific XCAP root was identified by the <entry> element within a specific XCAP root was identified by the
following HTTP URL: following HTTP URL:
skipping to change at page 9, line 8 skipping to change at page 7, line 47
entry%5b@uri=%22sip:petri@example.com%22%5d entry%5b@uri=%22sip:petri@example.com%22%5d
If http://xcap.example.com/root is the XCAP root URI, then an 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> element pointing to this entry would have the form:
<entry-ref ref="resource-lists/users/bill/ <entry-ref ref="resource-lists/users/bill/
mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/ mylist/~~/resource-lists/list%5b@name=%22list1%22%5d/
entry%5b@uri=%22sip:petri@example.com%22%5d"/> entry%5b@uri=%22sip:petri@example.com%22%5d"/>
Note that line folding within the HTTP URL and XML attribute above Note that line folding within the HTTP URL and XML attribute above
are the purposes of readability only. Also note that, as described are for the purposes of readability only. Also note that, as
in RFC 2396, the relative path URI does not begin with the "/". 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 "/". Since the relative URL used within the "ref" attribute must be
relative path URL, the "/" will never be present as the first a relative path URL, the "/" will never be present as the first
character within the content of a "ref" attribute. Since the content 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 of the "ref" attribute is a valid HTTP URL, it must be escape encoded
within the XML document. within the XML document.
The <external> element is similar to the <entry-ref> element. Like The <external> element is similar to the <entry-ref> element. Like
<entry-ref>, it is only meaningful in documents obtained from an XCAP <entry-ref>, it is only meaningful in documents obtained from an XCAP
server. It too is a reference to content stored elsewhere. However, server. It too is a reference to content stored elsewhere. However,
it refers to an entire list, and furthermore, allows that list to be it refers to an entire list, and furthermore, allows that list to be
present on another server. The <external> element has a single present on another server. The <external> element has a single
mandatory attribute, "anchor". The "anchor" attribute MUST be unique mandatory attribute, "anchor". The "anchor" attribute MUST be unique
amongst all other "anchor" attributes in <external> elements within amongst all other "anchor" attributes in <external> elements within
the same parent. Uniqueness is determined by case sensitive string the same parent. Uniqueness is determined by case sensitive string
comparisons. The content of an <external> element is an optional comparisons. The <external> element can also contain attributes from
<display-name> followed by any number of elements from another other namespaces, for the purposes of extensibility. The content of
namespace, for the purposes of extensibility. The value of the an <external> element is an optional <display-name> followed by any
"anchor" attribute MUST be an absolute HTTP URL. This URL MUST number of elements from another namespace, for the purposes of
identify an XCAP resource, and in particular, it MUST represent a extensibility. The value of the "anchor" attribute MUST be an
<list> element within a resource lists document. The URL MUST be absolute HTTP URL. This URL MUST identify an XCAP resource, and in
escape coded. 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 For both the <entry-ref> and <external> elements, the responsibility
of resolving their references falls upon the entity that is making of resolving their references falls upon the entity that is making
use of the document. When used in conjunction with XCAP, this means 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 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 based application using the resource-lists document as a presence
list, the references would likely be resolved upon explicit request list, the references would likely be resolved upon explicit request
by the user. They can, of course, be resolved at any time. If the 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 XCAP client is an RLS itself, the references would be resolved when
the RLS receives a SUBSCRIBE request for an RLS service associated the RLS receives a SUBSCRIBE request for an RLS service associated
skipping to change at page 10, line 4 skipping to change at page 8, line 45
the RLS receives a SUBSCRIBE request for an RLS service associated the RLS receives a SUBSCRIBE request for an RLS service associated
with a resource list that contains one of these references (see with a resource list that contains one of these references (see
below). An XCAP server defined by this specification will not below). An XCAP server defined by this specification will not
attempt to resolve the references before returning the document to attempt to resolve the references before returning the document to
the client. Similarly, if, due to network errors or some other the client. Similarly, if, due to network errors or some other
problem, the references cannot be resolved, the handling is specific problem, the references cannot be resolved, the handling is specific
to the usage of the document. For resource lists being used by RLS to the usage of the document. For resource lists being used by RLS
services, the handling is discussed below. services, the handling is discussed below.
3.2 Schema 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:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:resource-lists" xmlns="urn:ietf:params:xml:ns:resource-lists"
elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"
attributeFormDefault="unqualified"> elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:complexType name="listType"> <xs:complexType name="listType">
<xs:sequence> <xs:sequence>
<xs:element name="display-name" type="display-nameType" minOccurs="0"/> <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice> <xs:choice>
<xs:element name="list"> <xs:element name="list">
<xs:complexType> <xs:complexType>
<xs:complexContent> <xs:complexContent>
skipping to change at page 10, line 34 skipping to change at page 9, line 28
<xs:element name="external" type="externalType"/> <xs:element name="external" type="externalType"/>
<xs:element name="entry" type="entryType"/> <xs:element name="entry" type="entryType"/>
<xs:element name="entry-ref" type="entry-refType"/> <xs:element name="entry-ref" type="entry-refType"/>
<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:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="name" type="xs:string" 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" minOccurs="0"> <xs:element name="display-name" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:simpleContent> <xs:simpleContent>
<xs:extension base="display-nameType"/> <xs:extension base="display-nameType"/>
</xs:simpleContent> </xs:simpleContent>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="entry-refType"> <xs:complexType name="entry-refType">
<xs:sequence> <xs:sequence>
<xs:element name="display-name" type="display-nameType" minOccurs="0"/> <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="ref" type="xs:anyURI" use="required"/> <xs:attribute name="ref" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="externalType"> <xs:complexType name="externalType">
<xs:sequence> <xs:sequence>
<xs:element name="display-name" type="display-nameType" minOccurs="0"/> <xs:element name="display-name" type="display-nameType" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="anchor" type="xs:anyURI"/> <xs:attribute name="anchor" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType> </xs:complexType>
<xs:element name="resource-lists"> <xs:element name="resource-lists">
<xs:complexType> <xs:complexType>
<xs:sequence maxOccurs="unbounded"> <xs:sequence maxOccurs="unbounded">
<xs:element name="list" type="listType"/> <xs:element name="list" type="listType"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:complexType name="display-nameType"> <xs:complexType name="display-nameType">
<xs:simpleContent> <xs:simpleContent>
skipping to change at page 12, line 40 skipping to change at page 11, line 40
3.4 Usage with XCAP 3.4 Usage with XCAP
Resource lists 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.
3.4.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 7. via the IANA registration in Section 8.
3.4.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".
3.4.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 3.2. Section 3.2.
skipping to change at page 13, line 14 skipping to change at page 12, line 14
3.4.4 Additional Constraints 3.4.4 Additional Constraints
In addition to the schema, there are constraints on the values In addition to the schema, there are constraints on the values
present in the the "name" attribute of the <list> element, the "uri" present in the the "name" attribute of the <list> element, the "uri"
attribute of the <external> element, the "ref" attribute of the attribute of the <external> element, the "ref" attribute of the
<entry-ref> element and the "anchor" attribute of the <external> <entry-ref> element and the "anchor" attribute of the <external>
element. These constraints are defined in Section 3.1. Some of element. These constraints are defined in Section 3.1. Some of
these constraints are enforced by the XCAP server. Those constraints these constraints are enforced by the XCAP server. Those constraints
are: are:
o The "name" attribute in a <list> element MUST be unique amongst o The "name" attribute in a <list> element MUST be unique amongst
all other "name" attributes of <list> elements within the same all other "name" attributes of <list> elements within the same
parent element. parent element. Uniqueness is determined by case sensitive string
comparison.
o The "uri" attribute in a <entry> element MUST be unique amongst o The "uri" attribute in a <entry> element MUST be unique amongst
all other "uri" attributes of <entry> elements within the same all other "uri" attributes of <entry> elements within the same
parent element. Uniqueness is determined by case sensitive string parent element. Uniqueness is determined by case sensitive string
comparison. comparison.
o The URI in the "ref" attribute of the <entry-ref> element MUST be o The URI in the "ref" attribute of the <entry-ref> element MUST be
unique amongst all other "ref" attributes of <entry-ref> elements unique amongst all other "ref" attributes of <entry-ref> elements
within the same parent element. Uniqueness is determined by case within the same parent element. Uniqueness is determined by case
sensitive string comparison. The value of the attribute MUST be a sensitive string comparison. The value of the attribute MUST be a
relative path reference. Note that the server is not responsible relative path reference. Note that the server is not responsible
for verifying that the reference resolves to an <entry> element in for verifying that the reference resolves to an <entry> element in
a document within the same XCAP root. a document within the same XCAP root.
o The URI in the "anchor" attribute of the <external> element MUST o The URI in the "anchor" attribute of the <external> element MUST
be unique amongst all other "anchor" attributes of <external> be unique amongst all other "anchor" attributes of <external>
elements within the same parent element. Uniqueness is determined elements within the same parent element. Uniqueness is determined
by case sensitive string comparison. The value of the attribute by case sensitive string comparison. The value of the attribute
MUST be an absolute HTTP URL. Note that the server is not MUST be an absolute HTTP URL. Note that the server is not
responsible for verifying that the URL resolves to a <list> responsible for verifying that the URL resolves to a <list>
element in a document. Indeed, since the URL may reference a element in a document. Indeed, since the URL may reference a
server in another domain, referential integrity cannot be server in another domain, referential integrity cannot be
guaranteed without adding substantial complexity to the system. guaranteed without adding substantial complexity to the system.
skipping to change at page 14, line 17 skipping to change at page 13, line 23
their schemes may allow for two URI to be the same, even if they are 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 different by case sensitive string comparison. As such, it is
possible that a client will attempt a PUT or DELETE in an attempt to 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 modify or remove an existing element, but instead, the PUT ends up
inserting a new element, or the DELETE ends up returning an error inserting a new element, or the DELETE ends up returning an error
response. response.
To mitigate against this case, if the client knows that the user To mitigate against this case, if the client knows that the user
intent is to explicitly modify an existing element, as opposed to intent is to explicitly modify an existing element, as opposed to
creating a new one, the client SHOULD make the request conditional, creating a new one, the client SHOULD make the request conditional,
using an If-None-Match header field with a value of *. This will using an If-Match header field with a value of *. This will cause
cause the request to fail if it is not a replacement. the request to fail if it is not a replacement.
If the XCAP client cannot determine whether the user intent is to If the XCAP client cannot determine whether the user intent is to
create or replace, the client SHOULD canonicalize the URI before create or replace, the client SHOULD canonicalize the URI before
performing the operation. For a SIP URI (often present in the "uri" performing the operation. For a SIP URI (often present in the "uri"
attribute of the <entry> element), this canonicalization procedure is attribute of the <entry> element), this canonicalization procedure is
defined in Section 5. We expect that the SIP URIs that will be defined in Section 5. We expect that the SIP URIs that will be
placed into resource lists documents will usually be of the form placed into resource lists documents will usually be of the form
sip:user@domain, and possibly include a user parameter. The sip:user@domain, and possibly include a user parameter. The
canonicalization rules work perfectly for these URIs. canonicalization rules work perfectly for these URIs.
For HTTP URLs, a basic canonicalization algorithm is as follows. If 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 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 URLs), the port is removed. The hostname is converted to all
lowercase. Any characters that are escape encoded are un-escaped, lowercase. Any characters that are escape encoded are un-escaped,
and only re-escaped if they cannot be represented within their and only re-escaped if they cannot be represented within their
component of the URL. component of the URL. In other words, if the grammar for a part of
the URL disallows a certain character, but that character needs to be
present, it is escape coded.
3.4.7 Resource Interdependencies 3.4.7 Resource Interdependencies
There are no resource interdependencies identified by this There are no resource interdependencies identified by this
application usage. application usage.
3.4.8 Authorization Policies 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
skipping to change at page 15, line 12 skipping to change at page 14, line 17
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.
4. RLS Services Documents 4. RLS Services Documents
4.1 Structure 4.1 Structure
An RLS services document is used to define URIs that represent An RLS services document is used to define URIs that represent
services provided by a Resource List Server (RLS) as defined in [15]. services provided by a Resource List Server (RLS) as defined in [15].
An RLS services document is an XML [2] document that MUST be An RLS services document is an XML [2] document that MUST be
well-formed and SHOULD be valid. RLS services documents MUST be well-formed and MUST be valid according to schemas, including
based on XML 1.0 and MUST be encoded using UTF-8. This specification extension schemas, available to the validater and applicable to the
makes use of XML namespaces for identifying RLS services documents XML document. RLS services documents MUST be based on XML 1.0 and
and document fragments. The namespace URI for elements defined by MUST be encoded using UTF-8. This specification makes use of XML
this specification is a URN [3], using the namespace identifier namespaces for identifying RLS services documents and document
'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8]. This fragments. The namespace URI for elements defined by this
URN is: 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 urn:ietf:params:xml:ns:rls-services
The root element of an rls-services document is <rls-services>. It The root element of an rls-services document is <rls-services>. It
contains a sequence of <service> elements, each of which defines a contains a sequence of <service> elements, each of which defines a
service available at an RLS. service available at an RLS.
Each <service> element has a single mandatory attribute, "uri". This Each <service> element has a single mandatory attribute, "uri". This
URI defines the resource associated with the service. That is, if a URI defines the resource associated with the service. That is, if a
client subscribes to that URI, they will obtain the service defined client subscribes to that URI, they will obtain the service defined
by the corresponding <service> element. The <service> element by the corresponding <service> element. The <service> element can
contains child elements that define the service. For an RLS service, also contain attributes from other namespaces, for the purposes of
very little service definition is needed - just the resource list to extensibility. The <service> element contains child elements that
which the server will perform virtual subscriptions [15] and the set define the service. For an RLS service, very little service
of event packages that the service supports. The former can be definition is needed - just the resource list to which the server
conveyed in one of two ways. There can be a <resource-list> element, will perform virtual subscriptions [15] and the set of event packages
which points to a <list> element in a resource-lists document, or that the service supports. The former can be conveyed in one of two
there can be a <list> element, which includes the resource list ways. There can be a <resource-list> element, which points to a
directly. The supported packages are contained in the <packages> <list> element in a resource-lists document, or there can be a <list>
element. The <service> element can also contain elements from other element, which includes the resource list directly. The supported
namespaces, for the purposes of extensibility. 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 By including the contents of the resource list directly, a user can
create lists and add members to them with a single XCAP operation. create lists and add members to them with a single XCAP operation.
However, the resulting list becomes "hidden" within the RLS service However, the resulting list becomes "hidden" within the RLS service
definition, and is not usable by other application usages. For this definition, and is not usable by other application usages. For this
reason, the <resource-list> element exists as an alternative. It can reason, the <resource-list> element exists as an alternative. It can
reference a <list> element in a resource-lists document. Since the reference a <list> element in a resource-lists document. Since the
list is separated from the service definition, it can be easily list is separated from the service definition, it can be easily
reused by other application usages. reused by other application usages.
skipping to change at page 17, line 6 skipping to change at page 16, line 6
The <packages> element contains a sequence of <package> elements. The <packages> element contains a sequence of <package> elements.
The content of each <package> element is the name of a SIP event The content of each <package> element is the name of a SIP event
package [14]. The <packages> element may also contain elements from package [14]. The <packages> element may also contain elements from
additional namespaces, for the purposes of extensibility. The additional namespaces, for the purposes of extensibility. The
<packages> element is optional. When not present, it means that the <packages> element is optional. When not present, it means that the
RLS service will accept subscriptions for any event package. RLS service will accept subscriptions for any event package.
4.2 Schema 4.2 Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rls-services" <xs:schema targetNamespace="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:rls-services" xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
elementFormDefault="qualified" elementFormDefault="qualified" attributeFormDefault="unqualified">
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"/>
<xs:element name="rls-services"> <xs:element name="rls-services">
<xs:complexType> <xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="service" type="serviceType"/> <xs:element name="service" type="serviceType"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:complexType name="serviceType"> <xs:complexType name="serviceType">
<xs:sequence> <xs:sequence>
<xs:choice> <xs:choice>
<xs:element name="resource-list" type="xs:anyURI"/> <xs:element name="resource-list" type="xs:anyURI"/>
<xs:element name="list" type="rl:listType"/> <xs:element name="list" type="rl:listType"/>
</xs:choice> </xs:choice>
<xs:element name="packages" type="packagesType" minOccurs="0"/> <xs:element name="packages" type="packagesType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/> <xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="packagesType"> <xs:complexType name="packagesType">
<xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="package" type="packageType"/> <xs:element name="package" type="packageType"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0" <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
<xs:simpleType name="packageType"> <xs:simpleType name="packageType">
<xs:restriction base="xs:string"/> <xs:restriction base="xs:string"/>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
4.3 Example Document 4.3 Example Document
This document shows two services. One is sip:mybuddies@example.com, This document shows two services. One is sip:mybuddies@example.com,
skipping to change at page 18, line 37 skipping to change at page 17, line 37
4.4 Usage with XCAP 4.4 Usage with XCAP
RLS services documents can be manipulated with XCAP. This section RLS services documents can be manipulated with XCAP. This section
provides the details necessary for such a usage. provides the details necessary for such a usage.
4.4.1 Application Unique ID 4.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 "rls-services" AUID within the IETF tree, specification defines the "rls-services" AUID within the IETF tree,
via the IANA registration in Section 7. via the IANA registration in Section 8.
4.4.2 MIME Type 4.4.2 MIME Type
The MIME type for this document is "application/rls-services+xml". The MIME type for this document is "application/rls-services+xml".
4.4.3 XML Schema 4.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.2. Section 4.2.
skipping to change at page 19, line 39 skipping to change at page 18, line 43
o In some cases, an XCAP client will wish to create a new RLS 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 service, and wish to assign it a "vanity URI", such as
sip:friends@example.com. However, the client does not know sip:friends@example.com. However, the client does not know
whether this URI meets the uniqueness constraints defined above. whether this URI meets the uniqueness constraints defined above.
In that case, it can simply attempt the creation operation, and if 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 result is a 409 that contains a detailed conflict report with
the <uniqueness-failure> element, the client knows that the URI the <uniqueness-failure> element, the client knows that the URI
could not be assigned. It can then retry with a different vanity could not be assigned. It can then retry with a different vanity
URI, or use one of the suggestions in the detailed conflict URI, or use one of the suggestions in the detailed conflict
report. report.
o If the client wishes to create a new RLS service, and it doesnt 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 care what the URI is, the client creates a random one, and
attempts the creation operation. As discussed in [10], if this attempts the creation operation. As discussed in [10], if this
should fail the with a uniqueness conflict, the client can retry should fail with a uniqueness conflict, the client can retry with
with different URIs with increasing randomness. different URIs with increasing randomness.
4.4.5 Data Semantics 4.4.5 Data Semantics
Semantics for the document content are provided in Section 4.1. Semantics for the document content are provided in Section 4.1.
4.4.6 Naming Conventions 4.4.6 Naming Conventions
Typically, there are two distinct XCAP clients that access RLS Typically, there are two distinct XCAP clients that access RLS
services documents. The first is a client acting on behalf of the services documents. The first is a client acting on behalf of the
end user in the system. This client edits and writes both resource end user in the system. This client edits and writes both resource
skipping to change at page 20, line 24 skipping to change at page 19, line 32
the same XCAP root. There is a single instance of this document, and the same XCAP root. There is a single instance of this document, and
its name is "index". Thus, if the root services URI is its name is "index". Thus, if the root services URI is
http://xcap.example.com/root, the following is the URI that an RLS http://xcap.example.com/root, the following is the URI that an RLS
would use to fetch this index: would use to fetch this index:
http://xcap.example.com/root/rls-services/global/index http://xcap.example.com/root/rls-services/global/index
As discussed below, this index is created from all of the documents 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 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 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 its RLS services within the document named "index". If the root
http://xcap.example.com/root, for user "joe" the URI for this services URI is http://xcap.example.com/root, for user "joe" the URI
document would be: for this document would be:
http://xcap.example.com/root/rls-services/users/joe/index http://xcap.example.com/root/rls-services/users/joe/index
If a client elects to define RLS services in a different document, If a client elects to define RLS services in a different document,
this document will not be "picked up" in the global index, and this document will not be "picked up" in the global index, and
therefore, not used as an RLS service. therefore, not used as an RLS service.
4.4.7 Resource Interdependencies 4.4.7 Resource Interdependencies
As with other application usages, the XML schema along with the XCAP As with other application usages, the XML schema along with the XCAP
skipping to change at page 24, line 6 skipping to change at page 23, line 6
next step is to obtain a flat list of URIs from this element. To do 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. that, it traverses the tree of elements rooted in the <list> element.
Before traversal begins, the RLS initializes two lists - the "flat Before traversal begins, the RLS initializes two lists - the "flat
list", which will contain the flat list of URI after traversal, and list", which will contain the flat list of URI after traversal, and
the "traversed list", which contains a list of HTTP URLs in the "traversed list", which contains a list of HTTP URLs in
<external> elements that have already been visited. Once these lists <external> elements that have already been visited. Once these lists
are initialized, tree traversal begins. A server can use any are initialized, tree traversal begins. A server can use any
tree-traversal ordering it likes, such as depth first search or tree-traversal ordering it likes, such as depth first search or
breadth first search. The processing at each element in the tree breadth first search. The processing at each element in the tree
depends on the name of the element: depends on the name of the element:
o If the element is <entry> the URI in the "uri" attribute of the 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 element is added to the flat list if it is not already present
(based on case sensitive string equality) in that list, and the (based on case sensitive string equality) in that list, and the
URI scheme represents one that can be used to service URI scheme represents one that can be used to service
subscriptions, such as SIP [4] and pres [16]. subscriptions, such as SIP [4] and pres [16].
o If the element is an <entry-ref>, the relative path reference o If the element is an <entry-ref>, the relative path reference
making up the value of the "ref" attribute is resolved into an making up the value of the "ref" attribute is resolved into an
absolute URL. This is done using the procedures defined in absolute URL. This is done using the procedures defined in
Section 5.2 of RFC 2396 [7], using the XCAP root of the RLS 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. services document as the base URL. This absolute URL is resolved.
If the result is not a 200 OK containing a <entry> element, the If the result is not a 200 OK containing a <entry> element, the
SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway).
Otherwise, the <entry> element returned is processed as described Otherwise, the <entry> element returned is processed as described
in the previous step. in the previous step.
o If the element is an <external> element, the absolute URL making o If the element is an <external> element, the absolute URL making
up the value of the "anchor" attribute of the element is examined. up the value of the "anchor" attribute of the element is examined.
If the URL is on the traversed list, the server MUST cease If the URL is on the traversed list, the server MUST cease
traversing the tree, and SHOULD reject the SUBSCRIBE request with traversing the tree, and SHOULD reject the SUBSCRIBE request with
a 502 (Bad Gateway). If the URL is not on the traversed list, the 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 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, URL. If the result is not a 200 OK containing an <list> element,
the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway).
Otherwise, the RLS replaces the <external< element in its local Otherwise, the RLS replaces the <external> element in its local
copy of the tree with the <list> element that was returned, and copy of the tree with the <list> element that was returned, and
tree traversal continues. tree traversal continues.
Because the <external> element is used to dynamically construct the Because the <external> element is used to dynamically construct the
tree, there is a posibility of recursive evaluation of references. tree, there is a posibility of recursive evaluation of references.
The traversed list is used to prevent this from happening. The traversed list is used to prevent this from happening.
Once the tree has been traversed, the RLS can create virtual Once the tree has been traversed, the RLS can create virtual
subscriptions to each URI in the flat list, as defined in [15]. subscriptions to each URI in the flat list, as defined in [15].
skipping to change at page 25, line 15 skipping to change at page 24, line 15
5. SIP URI Canonicalization 5. SIP URI Canonicalization
This section provides a technique for URI canonicalization. This This section provides a technique for URI canonicalization. This
canonicalization produces a URI that, in most cases, is equal to the canonicalization produces a URI that, in most cases, is equal to the
original URI (where equality is based on the URI comparison rules in original URI (where equality is based on the URI comparison rules in
RFC 3261). Furthermore, the canonicalized URI will usually be RFC 3261). Furthermore, the canonicalized URI will usually be
lexically equivalent to the canonicalized version of any other URI lexically equivalent to the canonicalized version of any other URI
equal to the original. equal to the original.
To canonicalize the URI, the following steps are followed: To canonicalize the URI, the following steps are followed:
1. First, the domain part of the URI is converted into all 1. First, the domain part of the URI is converted into all
lowercase, and any tokens (such as "user" or "transport" or lowercase, and any tokens (such as "user" or "transport" or
"udp") are converted to all lowercase. "udp") are converted to all lowercase.
2. Secondly, the URI is un-escape coded. Then, it is re-coded. 2. Secondly, the URI is un-escape coded. Then, it is re-coded.
However, when it is recoded, the only characters that are coded However, when it is recoded, the only characters that are coded
are those which are not permitted to appear based on the grammar 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 of that portion of the URI. For example, if a SIP URI is
sip:%6aoe%20smith@example.com, it is decoded to "sip:joe sip:%6aoe%20smith@example.com, it is decoded to sip:joe
smith@example.com" and the re-coded to smith@example.com and the re-coded to
sip:joe%20smith@example.com. In the original URI, the character sip:joe%20smith@example.com. In the original URI, the character
'j' was escape coded. This is allowed, but not required, since 'j' was escape coded. This is allowed, but not required, since
the grammar allows a 'j' to appear in the user part. As a the grammar allows a 'j' to appear in the user part. As a
result, it appears as 'j' after this step of canonicalization. result, it appears as 'j' after this step of canonicalization.
3. Thirdly, any URI parameters are reordered so that they appear in 3. Thirdly, any URI parameters are reordered so that they appear in
lexical order based on parameter name. The ordering of a lexical order based on parameter name. The ordering of a
character is determined by the US-ASCII numerical value of that character is determined by the US-ASCII numerical value of that
character, with smaller numbers coming first. Parameters are character, with smaller numbers coming first. Parameters are
ordered with the leftmost character as most significant. For ordered with the leftmost character as most significant. For
parameters that contain only letters, this is equivalent to an parameters that contain only letters, this is equivalent to an
alphabetical ordering. alphabetical ordering.
4. Finally, any header parameters are discarded. This canonicalized 4. Finally, any header parameters are discarded. This canonicalized
URI is used instead of the original URI. URI is used instead of the original URI.
If two URIs A and B are functionally equal (meaning that they are If two URIs A and B are functionally equal (meaning that they are
equal according to the URI comparison rules in RFC 3261), their equal according to the URI comparison rules in RFC 3261), their
canonicalized URIs are equal under case sensitive string comparison canonicalized URIs are equal under case sensitive string comparison
if the following are true: if the following are true:
o Neither URI contains header parameters o Neither URI contains header parameters
o If one of the URI contains a URI parameter not defined in RFC o If one of the URI contains a URI parameter not defined in RFC
3261, the other does as well. 3261, the other does as well.
6. Security Considerations 6. Extensibility
Resource-lists and RLS services documents are meant to be extended.
An extension takes place by defining a new set of elements in a new
namespace, governed by a new schema. Every extension MUST have an
appropriate XML namespace assigned to it. The XML namespace of the
extension MUST be different from the namespaces defined in this
specification. The extension MUST NOT change the syntax or semantics
of the schemas defined in this document. All XML tags and attributes
that are part of the extension MUST be appropriately qualified so as
to place them within that namespace.
This specification defines explict places where new elements or
attributes from an extension can be placed. These are explicitly
indicated in the schemas by the <any> and <anyAttribute> elements.
Extensions to this specification MUST specify where their elements
can be placed within the document.
As a result, a document that contains extensions will require
multiple schemas in order to determine its validity - a schema
defined in this document, along with those defined by extensions
present in the document. Because extensions occur by adding new
elements and attributes governed by new schemas, the schemas defined
in this document are fixed and would only be changed by a revision to
this specification. Such a revision, should it take place, would
endeavor to allow documents compliant to the previous schema to
remain compliant to the new one. As a result, the schemas defined
here don't provide explicit schema versions, as this is not expected
to be needed.
7. Security Considerations
The information contained in rls-services and resource-lists The information contained in rls-services and resource-lists
documents are particularly sensitive. It represents the principle documents are particularly sensitive. It represents the principle
set of people with whom a user would like to communicate. As a set of people with whom a user would like to communicate. As a
result, clients SHOULD use TLS when contacting servers in order to result, clients SHOULD use TLS when contacting servers in order to
fetch this information. Note that this does not represent a change fetch this information. Note that this does not represent a change
in requirement strength from XCAP. in requirement strength from XCAP.
7. IANA Considerations 8. IANA Considerations
There are several IANA considerations associated with this There are several IANA considerations associated with this
specification. specification.
7.1 XCAP Application Usage IDs 8.1 XCAP Application Unique IDs
This section registers two new XCAP Application Usage ID (AUID) This section registers two new XCAP Application Unique ID (AUID)
according to the IANA procedures defined in [10]. according to the IANA procedures defined in [10].
7.1.1 resource-lists 8.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 lists 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.
7.1.2 rls-services 8.1.2 rls-services
Name of the AUID: rls-services Name of the AUID: rls-services
Description: An Resource List Server (RLS) services application is Description: An Resource List Server (RLS) services application is
Session Initiation Protocol (SIP) application whereby a server Session Initiation Protocol (SIP) application whereby a server
receives SIP SUBSCRIBE requests for resource, and generates receives SIP SUBSCRIBE requests for resource, and generates
subscriptions towards the a resource list. subscriptions towards the a resource list.
7.2 MIME Type Registrations 8.2 MIME Type Registrations
This specification requests the registration of two new MIME types This specification requests the registration of two new MIME types
according to the procedures of RFC 2048 [9] and guidelines in RFC according to the procedures of RFC 2048 [9] and guidelines in RFC
3023 [5]. 3023 [5].
7.2.1 application/resource-lists+xml 8.2.1 application/resource-lists+xml
MIME media type name: application MIME media type name: application
MIME subtype name: resource-lists+xml 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 [5]. 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 [5]. 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 [5] and
Section 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace Section 7 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number 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: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this specification]] 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 [15] for been used to support subscriptions to lists of users [15] for
SIP-based presence [12]. 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. Author/Change controller: The IETF.
7.2.2 application/rls-services+xml 8.2.2 application/rls-services+xml
MIME media type name: application MIME media type name: application
MIME subtype name: rls-services+xml MIME subtype name: rls-services+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 [5]. 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 [5]. 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 [5] and
Section 6 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace Section 7 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace
XXXX with the RFC number 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: RFC XXXX [[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this specification]] 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 [15] for been used to support subscriptions to lists of users [15] for
SIP-based presence [12]. SIP-based presence [12].
Additional Information: Additional Information:
Magic Number: None Magic Number: None
File Extension: .rl or .xml
File Extension: .rs 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. Author/Change controller: The IETF.
7.3 URN Sub-Namespace Registrations 8.3 URN Sub-Namespace Registrations
This section registers two new XML namespace, as per the guidelines This section registers two new XML namespace, as per the guidelines
in RFC 3688 [8]. in RFC 3688 [8].
7.3.1 urn:ietf:params:xml:ns:resource-lists 8.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 29, line 27 skipping to change at page 29, line 8
<body> <body>
<h1>Namespace for Resource Lists</h1> <h1>Namespace for Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:resource-lists</h2> <h2>urn:ietf:params:xml:ns:resource-lists</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [NOTE <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
7.3.2 urn:ietf:params:xml:ns:rls-services 8.3.2 urn:ietf:params:xml:ns:rls-services
URI: The URI for this namespace is URI: The URI for this namespace is
urn:ietf:params:xml:ns:rls-services. urn:ietf:params:xml:ns:rls-services.
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">
<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"/>
skipping to change at page 30, line 8 skipping to change at page 29, line 38
<body> <body>
<h1>Namespace for Resource List Server (RLS) Services</h1> <h1>Namespace for Resource List Server (RLS) Services</h1>
<h2>urn:ietf:params:xml:ns:rls-services</h2> <h2>urn:ietf:params:xml:ns:rls-services</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX [NOTE <p>See <a href="[URL of published RFC]">RFCXXXX [NOTE
TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
7.4 Schema Registrations 8.4 Schema Registrations
This section registers two XML schemas per the procedures in [8]. This section registers two XML schemas per the procedures in [8].
7.4.1 urn:ietf:params:xml:schema:resource-lists 8.4.1 urn:ietf:params:xml:schema:resource-lists
URI: 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 The XML for this schema can be found as the sole content of
Section 3.2. Section 3.2.
7.4.2 urn:ietf:params:xml:schema:rls-services 8.4.2 urn:ietf:params:xml:schema:rls-services
URI: urn:ietf:params:xml:schema:rls-services URI: urn:ietf:params:xml:schema:rls-services
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 The XML for this schema can be found as the sole content of
Section 4.2. Section 4.2.
8. References 9. Acknowledgements
8.1 Normative References The authors would like to thank Hisham Khartabil and Jari Urpalainen
for their comments and input. Thanks to Ted Hardie for his
encouragement and support of this work.
10. References
10.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.
skipping to change at page 31, line 41 skipping to change at page 31, line 14
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[9] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet [9] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996. 13, RFC 2048, November 1996.
[10] Rosenberg, J., "The Extensible Markup Language (XML) [10] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-02 (work in progress), February 2004. draft-ietf-simple-xcap-03 (work in progress), July 2004.
8.2 Informative References 10.2 Informative References
[11] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and [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.
[12] 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)", RFC 3856, August 2004.
in progress), January 2003.
[13] Rosenberg, J., "Presence Authorization Rules", [13] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May draft-ietf-simple-presence-rules-00 (work in progress), May
2004. 2004.
[14] Roach, A., "Session Initiation Protocol (SIP)-Specific Event [14] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002. Notification", RFC 3265, June 2002.
[15] 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-05 (work in progress),
June 2003. August 2004.
[16] Peterson, J., "Common Profile for Presence (CPP)",
draft-ietf-impp-pres-04 (work in progress), October 2003.
[17] Rosenberg, J. and M. Isomaki, "Requirements for Manipulation of [16] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
Data Elements in Session Initiation Protocol (SIP) for Instant August 2004.
Messaging and Presence Leveraging Extensions (SIMPLE) Systems",
draft-ietf-simple-data-req-03 (work in progress), June 2003.
Author's Address Author's Address
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft Cisco Systems
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
 End of changes. 113 change blocks. 
159 lines changed or deleted 269 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/