< draft-ietf-simple-xcap-list-usage-04.txt		draft-ietf-simple-xcap-list-usage-05.txt >
	SIMPLE J. Rosenberg		SIMPLE J. Rosenberg
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: April 23, 2005 October 23, 2004		Expires: August 8, 2005 February 7, 2005
	Extensible Markup Language (XML) Formats for Representing Resource		Extensible Markup Language (XML) Formats for Representing Resource
	Lists		Lists
	draft-ietf-simple-xcap-list-usage-04		draft-ietf-simple-xcap-list-usage-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she 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
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		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		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 April 23, 2005.		This Internet-Draft will expire on August 8, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2005).
	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 resource 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 resource list service, the server will obtain the state 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. This
	documents can be created and managed with the XML Configuration		list of users can be utilized by other applications and services.
			Both documents can be created and managed with the XML Configuration
	Access Protocol (XCAP).		Access Protocol (XCAP).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 5		3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 5
	3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 10		3.3 Example Document . . . . . . . . . . . . . . . . . . . . . 10
	3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 11		3.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 11
	3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 11		3.4.1 Application Unique ID . . . . . . . . . . . . . . . . 11
	3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 11		3.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 11
	3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 11		3.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 11
	3.4.4 Additional Constraints . . . . . . . . . . . . . . . . 12		3.4.4 Default Namespace . . . . . . . . . . . . . . . . . . 12
	3.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 12		3.4.5 Additional Constraints . . . . . . . . . . . . . . . . 12
	3.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 12		3.4.6 Data Semantics . . . . . . . . . . . . . . . . . . . . 12
	3.4.7 Resource Interdependencies . . . . . . . . . . . . . . 13		3.4.7 Naming Conventions . . . . . . . . . . . . . . . . . . 13
	3.4.8 Authorization Policies . . . . . . . . . . . . . . . . 13		3.4.8 Resource Interdependencies . . . . . . . . . . . . . . 13
			3.4.9 Authorization Policies . . . . . . . . . . . . . . . . 14
	4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 14		4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 14
	4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 14		4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15		4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 16		4.3 Example Document . . . . . . . . . . . . . . . . . . . . . 16
	4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 17		4.4 Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 17
	4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 17		4.4.1 Application Unique ID . . . . . . . . . . . . . . . . 17
	4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 17		4.4.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . 17
	4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 17		4.4.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . 17
	4.4.4 Additional Constraints . . . . . . . . . . . . . . . . 17		4.4.4 Default Namespace . . . . . . . . . . . . . . . . . . 17
	4.4.5 Data Semantics . . . . . . . . . . . . . . . . . . . . 19		4.4.5 Additional Constraints . . . . . . . . . . . . . . . . 18
	4.4.6 Naming Conventions . . . . . . . . . . . . . . . . . . 19		4.4.6 Data Semantics . . . . . . . . . . . . . . . . . . . . 19
	4.4.7 Resource Interdependencies . . . . . . . . . . . . . . 19		4.4.7 Naming Conventions . . . . . . . . . . . . . . . . . . 19
	4.4.8 Authorization Policies . . . . . . . . . . . . . . . . 21		4.4.8 Resource Interdependencies . . . . . . . . . . . . . . 19
			4.4.9 Authorization Policies . . . . . . . . . . . . . . . . 21
	4.5 Usage of an RLS Services Document by an RLS . . . . . . . 22		4.5 Usage of an RLS Services Document by an RLS . . . . . . . 22
	5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 24		5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 23
	6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 25		6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 24
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 25		7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	8.1 XCAP Application Unique IDs . . . . . . . . . . . . . . . 25		8.1 XCAP Application Unique IDs . . . . . . . . . . . . . . . 25
	8.1.1 resource-lists . . . . . . . . . . . . . . . . . . . . 26		8.1.1 resource-lists . . . . . . . . . . . . . . . . . . . . 25
	8.1.2 rls-services . . . . . . . . . . . . . . . . . . . . . 26		8.1.2 rls-services . . . . . . . . . . . . . . . . . . . . . 26
	8.2 MIME Type Registrations . . . . . . . . . . . . . . . . . 26		8.2 MIME Type Registrations . . . . . . . . . . . . . . . . . 26
	8.2.1 application/resource-lists+xml . . . . . . . . . . . . 26		8.2.1 application/resource-lists+xml . . . . . . . . . . . . 26
	8.2.2 application/rls-services+xml . . . . . . . . . . . . . 27		8.2.2 application/rls-services+xml . . . . . . . . . . . . . 27
	8.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 28		8.3 URN Sub-Namespace Registrations . . . . . . . . . . . . . 28
	8.3.1 urn:ietf:params:xml:ns:resource-lists . . . . . . . . 28		8.3.1 urn:ietf:params:xml:ns:resource-lists . . . . . . . . 28
	8.3.2 urn:ietf:params:xml:ns:rls-services . . . . . . . . . 29		8.3.2 urn:ietf:params:xml:ns:rls-services . . . . . . . . . 29
	8.4 Schema Registrations . . . . . . . . . . . . . . . . . . . 29		8.4 Schema Registrations . . . . . . . . . . . . . . . . . . . 29
	8.4.1 urn:ietf:params:xml:schema:resource-lists . . . . . . 29		8.4.1 urn:ietf:params:xml:schema:resource-lists . . . . . . 29
	8.4.2 urn:ietf:params:xml:schema:rls-services . . . . . . . 30		8.4.2 urn:ietf:params:xml:schema:rls-services . . . . . . . 30
	skipping to change at page 7, line 26 ¶		skipping to change at page 7, line 26 ¶
	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 <entry-ref> element also allows		sensitive string comparisons. The <entry-ref> element also allows
	attributes from other namespaces, for the purposes of extensibility.		attributes from other namespaces, for the purposes of extensibility.
	The content of an <entry-ref> element is an optional display name,		The content of an <entry-ref> element is an optional display name,
	followed by any number of elements from other namespaces, for the		followed by any number of elements from other namespaces, for the
	purposes of extensibility. The display name is useful for providing		purposes of extensibility. The display name is useful for providing
	a localized nickname as an alternative to the name defined in the		a localized nickname as an alternative to the name defined in the
	<entry> to which the <entry-ref> refers.		<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 URI [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		URI 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 URI, if resolved into an absolute
	URL according to the procedures in RFC 2396, MUST resolve to an		URI according to the procedures in RFC 3986, 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 URI:
	http://xcap.example.com/root/resource-lists/users/bill/		http://xcap.example.com/root/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
	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 URI and XML attribute above
	are for the purposes of readability only. Also note that, as		are for the purposes of readability only. Also note that, as
	described in RFC 2396, the relative path URI does not begin with the		described in RFC 3986, the relative path URI does not begin with the
	"/". Since the relative URL used within the "ref" attribute must be		"/". Since the relative URI used within the "ref" attribute must be
	a relative path URL, the "/" will never be present as the first		a relative path URI, 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 URI, 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", which specifies the external list by
			means of an absolute HTTP URI. 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 <external> element can also contain attributes from		comparisons. The <external> element can also contain attributes from
	other namespaces, for the purposes of extensibility. The content of		other namespaces, for the purposes of extensibility. The content of
	an <external> element is an optional <display-name> followed by any		an <external> element is an optional <display-name> followed by any
	number of elements from another namespace, for the purposes of		number of elements from another namespace, for the purposes of
	extensibility. The value of the "anchor" attribute MUST be an		extensibility. The value of the "anchor" attribute MUST be an
	absolute HTTP URL. This URL MUST identify an XCAP resource, and in		absolute HTTP URI. This URI MUST identify an XCAP resource, and in
	particular, it MUST represent a <list> element within a resource		particular, it MUST represent a <list> element within a resource
	lists document. The URL MUST be escape coded.		lists document. The URI 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 33 ¶		skipping to change at page 10, line 33 ¶
	<xs:extension base="xs:string">		<xs:extension base="xs:string">
	<xs:attribute ref="xml:lang"/>		<xs:attribute ref="xml:lang"/>
	</xs:extension>		</xs:extension>
	</xs:simpleContent>		</xs:simpleContent>
	</xs:complexType>		</xs:complexType>
	</xs:schema>		</xs:schema>
	3.3 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.		All line feeds within element content are for display purposes only.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"		<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<list name="friends">		<list name="friends">
	<entry uri="sip:bill@example.com">		<entry uri="sip:bill@example.com">
	<display-name>Bill Doe</display-name>		<display-name>Bill Doe</display-name>
	</entry>		</entry>
	<entry-ref ref="resource-lists/users/bill/mylist/~~/resource-lists/l		<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"/>		ist%5b@name=%22list1%22%5d/entry%5b@uri=%22sip:petri@example.com%22%5d"/>
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 5 ¶
	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.
	3.4.4 Additional Constraints		3.4.4 Default Namespace
			The default namespace used in expanding URIs is
			urn:ietf:params:xml:ns:resource-lists.
			3.4.5 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
	skipping to change at page 12, line 37 ¶		skipping to change at page 12, line 42 ¶
	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 URI. Note that the server is not
	responsible for verifying that the URL resolves to a <list>		responsible for verifying that the URI resolves to a <list>
	element in a document. Indeed, since the URL may reference a		element in a document. Indeed, since the URI 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.
	3.4.5 Data Semantics		3.4.6 Data Semantics
	Semantics for the document content are provided in Section 3.1.		Semantics for the document content are provided in Section 3.1.
	3.4.6 Naming Conventions		3.4.7 Naming Conventions
	Resource lists documents are usually identified as references from		Resource lists documents are usually identified as references from
	other application usages. For example, an RLS services document		other application usages. For example, an RLS services document
	contains a reference to the resource list it uses.		contains a reference to the resource list it uses.
	Frequently, an XCAP client will wish to insert or remove an <entry>,		Frequently, an XCAP client will wish to insert or remove an <entry>,
	<entry-ref> or <external> element from a document without having a		<entry-ref> or <external> element from a document without having a
	cached copy of that document. In such a case, the "uri" attribute of		cached copy of that document. In such a case, the "uri" attribute of
	the <entry> element, the "ref" attribute of the <entry-ref> element		the <entry> element, the "ref" attribute of the <entry-ref> element
	or the "anchor" attribute of the <external> element is used as an		or the "anchor" attribute of the <external> element is used as an
	skipping to change at page 13, line 35 ¶		skipping to change at page 13, line 41 ¶
	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 URIs, 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 URI is equal to the default port (80 for http
	URLs), the port is removed. The hostname is converted to all		URIs), 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. In other words, if the grammar for a part of		component of the URI. In other words, if the grammar for a part of
	the URL disallows a certain character, but that character needs to be		the URI disallows a certain character, but that character needs to be
	present, it is escape coded.		present, it is escape coded.
	3.4.7 Resource Interdependencies		3.4.8 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.9 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 privileged 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.
	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
	skipping to change at page 15, line 15 ¶		skipping to change at page 15, line 21 ¶
	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.
	The <list> element is of the list type defined by the schema for		The <list> element is of the list type defined by the schema for
	resource lists. It is discussed in Section 3.1.		resource lists. It is discussed in Section 3.1.
	The <resource-list> element contains a URI. This element is only		The <resource-list> element contains a URI. This element is only
	meaningful when the document was obtained through XCAP. The URI MUST		meaningful when the document was obtained through XCAP. The URI MUST
	be an absolute HTTP URL representing an XCAP element resource. Its		be an absolute HTTP URI representing an XCAP element resource. Its
	XCAP root MUST be the same as the XCAP root of the RLS services		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		document. When the RLS services document is present in a user's home
	directory, the HTTP URL MUST exist underneath the same user's home		directory, the HTTP URI MUST exist underneath that user's home
	directory in the resource-lists application usage. When the RLS		directory in the resource-lists application usage. When the RLS
	services document is in the global directory, the HTTP URL MUST exist		services document is in the global directory, the HTTP URI MUST exist
	underneath any user's home directory in the resource-lists		underneath any user's home directory in the resource-lists
	application usage. In either case, the element referenced by the URI		application usage. In either case, the element referenced by the URI
	MUST be a <list> element within a resource-lists document. All of		MUST be a <list> element within a resource-lists document. All of
	these constraints except for the latter one (which is a referential		these constraints except for the latter one (which is a referential
	integrity constraint) will be enforced by the XCAP server.		integrity constraint) will be enforced by the XCAP server.
	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
	skipping to change at page 17, line 48 ¶		skipping to change at page 17, line 48 ¶
	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.
	4.4.4 Additional Constraints		4.4.4 Default Namespace
			The default namespace used in expanding URIs is
			urn:ietf:params:xml:ns:rls-services.
			4.4.5 Additional Constraints
	In addition to the schema, there are constraints on the URIs present		In addition to the schema, there are constraints on the URIs present
	in the <service> and <resource-list> elements. These constraints are		in the <service> and <resource-list> elements. These constraints are
	defined in Section 3.1. Some of these constraints are enforced by		defined in Section 3.1. Some of these constraints are enforced by
	the XCAP server. Those constraints are:		the XCAP server. Those constraints are:
	o The URI in the "uri" attribute of the <service> element MUST be		o The URI in the "uri" attribute of the <service> element MUST be
	unique amongst all other URIs in "uri" elements in any <service>		unique amongst all other URIs in "uri" elements in any <service>
	element in any document on a particular server. This uniqueness		element in any document on a particular server. This uniqueness
	constraint spans across XCAP roots. Furthermore, the URI MUST NOT		constraint spans across XCAP roots. Furthermore, the URI MUST NOT
	skipping to change at page 18, line 31 ¶		skipping to change at page 18, line 36 ¶
	tree), the server MUST verify that the XUI in the path is the same		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		as the XUI in the URI of to the RLS services document. These
	checks are made by examining the URI value, as opposed to		checks are made by examining the URI value, as opposed to
	de-referencing the URI. The server is not responsible for		de-referencing the URI. The server is not responsible for
	verifying that the URI actually points to a <list> element within		verifying that the URI actually points to a <list> element within
	a valid resource lists document.		a valid resource lists document.
	o In addition, an RLS services document can contain a <list>		o In addition, an RLS services document can contain a <list>
	element, which in turn can contain <entry>, <entry-ref> and		element, which in turn can contain <entry>, <entry-ref> and
	<external> elements. The constraints defined for these elements		<external> elements. The constraints defined for these elements
	in Section 3.4.6 MUST be enforced.		in Section 3.4.7 MUST be enforced.
	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 with a uniqueness conflict, the client can retry with		should fail with a uniqueness conflict, the client can retry with
	different URIs with increasing randomness.		different URIs with increasing randomness.
	4.4.5 Data Semantics		4.4.6 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.7 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
	lists and RLS services documents as they are created or modified by		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 end user. The other XCAP client is the RLS itself, which reads
	the RLS services documents in order to process SUBSCRIBE requests.		the RLS services documents in order to process SUBSCRIBE requests.
	To make it easier for an RLS to find the <service> element for a		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		particular URI, the XCAP server maintains, within the global tree, a
	skipping to change at page 19, line 42 ¶		skipping to change at page 19, line 43 ¶
	its RLS services within the document named "index". If the root		its RLS services within the document named "index". If the root
	services URI is http://xcap.example.com/root, for user "joe" the URI		services URI is http://xcap.example.com/root, for user "joe" the URI
	for this 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.8 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
	resource naming conventions describes most of the resource		resource naming conventions describes most of the resource
	interdependencies applicable to this application usage.		interdependencies applicable to this application usage.
	This application usage defines an additional resource interdependence		This application usage defines an additional resource interdependence
	between a single document in the global tree and all documents in the		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		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		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		XCAP root. In this case, the union operation implies that each
	skipping to change at page 21, line 27 ¶		skipping to change at page 21, line 27 ¶
	<list name="marketing">		<list name="marketing">
	<rl:entry uri="sip:joe@example.com"/>		<rl:entry uri="sip:joe@example.com"/>
	<rl:entry uri="sip:sudhir@example.com"/>		<rl:entry uri="sip:sudhir@example.com"/>
	</list>		</list>
	<packages>		<packages>
	<package>presence</package>		<package>presence</package>
	</packages>		</packages>
	</service>		</service>
	</rls-services>		</rls-services>
	The server MUST, at all times, be capable of processing requests made		Requests made against the global document MUST generate responses
	against the global document, and its contents MUST reflect the		that reflect the most recent state of all the relevant user
	current state of all the relevant user documents. This requirement		documents. This requirement does not imply that the server must
	does not imply that the server must actually store this global		actually store this global document. It is anticipated that most
	document. It is anticipated that most systems will dynamically		systems will dynamically construct the responses to any particular
	construct the responses to any particular request against the		request against the document resource.
	document resource.
	The uniqueness constraint on the "uri" attribute of <service> will		The uniqueness constraint on the "uri" attribute of <service> will
	ensure that no two <service> elements in the global document have the		ensure that no two <service> elements in the global document have the
	same value of that attribute.		same value of that attribute.
	4.4.8 Authorization Policies		4.4.9 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 privileged 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 an RLS services document.		to modify an RLS services document.
	The index document maintained in the global tree represents sensitive		The index document maintained in the global tree represents sensitive
	information, as it contains the union of all of the information for		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		all users on the server. As such, its access MUST be restricted to
	trusted elements within domain of the server. Typically, this would		trusted elements within domain of the server. Typically, this would
	be limited to the RLSs that need access to this document.		be limited to the RLSs that need access to this document.
	skipping to change at page 22, line 21 ¶		skipping to change at page 22, line 20 ¶
	When an RLS receives a SUBSCRIBE request for a URI (present in the		When an RLS receives a SUBSCRIBE request for a URI (present in the
	Request URI), it obtains the <service> element whose uri attribute		Request URI), it obtains the <service> element whose uri attribute
	matches (based on URI equality) the URI in the SUBSCRIBE request.		matches (based on URI equality) the URI in the SUBSCRIBE request.
	This document makes no normative statements on how this might be		This document makes no normative statements on how this might be
	accomplished. The following paragraph provides one possible		accomplished. The following paragraph provides one possible
	approach.		approach.
	The RLS canonicalizes the Request URI as described in Section 5. It		The RLS canonicalizes the Request URI as described in Section 5. It
	then performs an XCAP GET operation against the URI formed by		then performs an XCAP GET operation against the URI formed by
	combining the XCAP root with the document selector of the global		combining the XCAP root with the document selector of the global
	index with a node selector of the form "rls-services/		index with a node selector of the form
	service[@uri=<canonical-uri>]", where <canonical-uri> is the		"rls-services/service[@uri=<canonical-uri>]", where <canonical-uri>
	canonicalized version of the Request URI. If the response is a 200		is the canonicalized version of the Request URI. If the response is
	OK, it will contain the service definition for that URI.		a 200 OK, it will contain the service definition for that URI.
	Once the <service> element has been obtained, it is examined. If the		Once the <service> element has been obtained, it is examined. If the
	<packages> element is present, and the event package in the SUBSCRIBE		<packages> element is present, and the event package in the SUBSCRIBE
	request is not amongst those listed in the <package> elements within		request is not amongst those listed in the <package> elements within
	<packages>, the request MUST be rejected with a 489 (Bad Event)		<packages>, the request MUST be rejected with a 489 (Bad Event)
	response code, as described in [14]. Otherwise, it SHOULD be		response code, as described in [14]. Otherwise, it SHOULD be
	processed. The next step is to authorize that the client is allowed		processed. The next step is to authorize that the client is allowed
	to subscribe to the resource. This can be done using the data		to subscribe to the resource. This can be done using the data
	defined in [13], for example. Assuming the subscriber is authorized		defined in [13], for example. Assuming the subscriber is authorized
	to subscribe to that resource, the subscription is processed		to subscribe to that resource, the subscription is processed
	skipping to change at page 22, line 48 ¶		skipping to change at page 22, line 47 ¶
	extracted. If the <service> element had a <resource-list> element,		extracted. If the <service> element had a <resource-list> element,
	its URI content is dereferenced. The result should be a <list>		its URI content is dereferenced. The result should be a <list>
	element. If it is not, the request SHOULD be rejected with a 502		element. If it is not, the request SHOULD be rejected with a 502
	(Bad Gateway). Otherwise, that <list> element is extracted.		(Bad Gateway). Otherwise, that <list> element is extracted.
	At this point the RLS has a <list> element in its possession. The		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		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 URIs 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 URI. 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 3986 [7], using the XCAP root of the RLS
	services document as the base URL. This absolute URL is resolved.		services document as the base URI. This absolute URI 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 URI 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 URI 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 URI is not on the traversed list, the
	server adds the URL to the traversed list, and de-references the		server adds the URI to the traversed list, and de-references the
	URL. If the result is not a 200 OK containing an <list> element,		URI. 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
	skipping to change at page 27, line 12 ¶		skipping to change at page 27, line 12 ¶
	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
	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.
	skipping to change at page 28, line 9 ¶		skipping to change at page 28, line 9 ¶
	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: .rs or .xml		File Extension: .rs
	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.
	skipping to change at page 30, line 20 ¶		skipping to change at page 30, line 20 ¶
	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.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank Hisham Khartabil and Jari Urpalainen		The authors would like to thank Hisham Khartabil, Jari Urpalainen and
	for their comments and input. Thanks to Ted Hardie for his		Spencer Dawkins for their comments and input. Thanks to Ted Hardie
	encouragement and support of this work.		for his encouragement and support of this work.
	10. References		10. References
	10.1 Normative 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
	skipping to change at page 30, line 48 ¶		skipping to change at page 30, line 48 ¶
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC		[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
	3023, January 2001.		3023, January 2001.
	[6] 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.
	[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform		[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
	Resource Identifiers (URI): Generic Syntax", RFC 2396, August		Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
	1998.		January 2005.
	[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-03 (work in progress), July 2004.		draft-ietf-simple-xcap-05 (work in progress), November 2004.
	10.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)", RFC 3856, August 2004.		Initiation Protocol (SIP)", RFC 3856, August 2004.
	[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-01 (work in progress), October
	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-05 (work in progress),		Lists", draft-ietf-simple-event-list-07 (work in progress),
	August 2004.		January 2005.
	[16] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,		[16] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
	August 2004.		August 2004.
	Author's Address		Author's Address
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco Systems		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@cisco.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 Rights 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; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	skipping to change at page 32, line 41 ¶		skipping to change at page 32, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	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. 55 change blocks.
	94 lines changed or deleted		109 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/