< draft-ietf-simple-xcap-diff-06.txt		draft-ietf-simple-xcap-diff-07.txt >
	SIMPLE J. Rosenberg		SIMPLE J. Rosenberg
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track J. Urpalainen		Intended status: Standards Track J. Urpalainen
	Expires: February 18, 2008 Nokia		Expires: May 19, 2008 Nokia
	August 17, 2007		November 16, 2007
	An Extensible Markup Language (XML) Document Format for Indicating A		An Extensible Markup Language (XML) Document Format for Indicating A
	Change in XML Configuration Access Protocol (XCAP) Resources		Change in XML Configuration Access Protocol (XCAP) Resources
	draft-ietf-simple-xcap-diff-06		draft-ietf-simple-xcap-diff-07
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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 becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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 36 ¶		skipping to change at page 1, line 36 ¶
	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 February 18, 2008.		This Internet-Draft will expire on May 19, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This specification defines a document format that can be used to		This specification defines a document format that can be used to
	indicate that a change has occurred in a document managed by the		indicate that a change has occurred in a document managed by the
	Extensible Markup Language (XML) Configuration Access Protocol		Extensible Markup Language (XML) Configuration Access Protocol
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	XML document. XCAP diff documents can be delivered to clients using		XML document. XCAP diff documents can be delivered to clients using
	a number of means, including a Session Initiation Protocol (SIP)		a number of means, including a Session Initiation Protocol (SIP)
	event package.		event package.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4		3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4
	4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 10		5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11		7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11
	7.2. URN Sub-Namespace Registration for		7.2. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12		urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12
	7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 12		7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . . 14		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	1. Introduction		1. Introduction
	The Extensible Markup Language (XML) Configuration Access Protocol		The Extensible Markup Language (XML) Configuration Access Protocol
	(XCAP) [9] is a protocol that allows clients to manipulate XML		(XCAP) [RFC4825] is a protocol that allows clients to manipulate XML
	documents stored on a server. These XML documents serve as		documents stored on a server. These XML documents serve as
	configuration information for application protocols. As an example,		configuration information for application protocols. As an example,
	resource list [13] subscriptions (also known as presence lists) allow		resource list [RFC4662] subscriptions (also known as presence lists)
	a client to have a single SIP subscription to a list of users, where		allow a client to have a single SIP subscription to a list of users,
	the list is maintained on a server. The server will obtain presence		where the list is maintained on a server. The server will obtain
	for those users and report it back to the client. This application		presence for those users and report it back to the client. This
	requires the server, called a Resource List Server (RLS), to have		application requires the server, called a Resource List Server (RLS),
	access to the list of presentities. This list needs to be		to have access to the list of presentities. This list needs to be
	manipulated by clients so they can add and remove their friends as		manipulated by clients so they can add and remove their friends as
	they desire.		they desire.
	Complexities arise when multiple clients attempt to simultaneously		Complexities arise when multiple clients attempt to simultaneously
	manipulate a document, such as a presence list. Frequently, a client		manipulate a document, such as a presence list. Frequently, a client
	will keep a copy of the current list in memory, so it can render it		will keep a copy of the current list in memory, so it can render it
	to users. However, if another client modifies the document, the		to users. However, if another client modifies the document, the
	cached version becomes stale. This modification event must be made		cached version becomes stale. This modification event must be made
	known to all clients which have cached copies of the document, so		known to all clients which have cached copies of the document, so
	that they can fetch the most recent one.		that they can fetch the most recent one.
	To deal with this problem, clients can use a Session Initiation		To deal with this problem, clients can use a Session Initiation
	Protocol (SIP) [11] event package [12] to subscribe to change events		Protocol (SIP) [RFC3261] event package [RFC3265] to subscribe to
	in XCAP documents. This notification needs to indicate the specific		change events in XCAP documents. This notification needs to indicate
	resource that changed, and how it changed. One solution for the		the specific resource that changed, and how it changed. One solution
	format of such a change notification would be a content indirection		for the format of such a change notification would be a content
	object [15]. Though content indirection can tell a client that a		indirection object [RFC4483]. Though content indirection can tell a
	document has changed, it provides it with MIME Content-ID indicating		client that a document has changed, it provides it with MIME
	the new version of the document. The MIME Content-ID is not the same		Content-ID indicating the new version of the document. The MIME
	as the entity tag, which is used by XCAP for document versioning. As		Content-ID is not the same as the entity tag, which is used by XCAP
	such, a client cannot easily ascertain whether an indication of a		for document versioning. As such, a client cannot easily ascertain
	change in a document is due to a change it just made, or due to a		whether an indication of a change in a document is due to a change it
	change another client made at around the same time. Furthermore,		just made, or due to a change another client made at around the same
	content indirections don't indicate how a document changed; they		time. Furthermore, content indirections don't indicate how a
	would only be able to indicate that it did change.		document changed; they would only be able to indicate that it did
			change.
	To resolve these problems, this document defines a data format which		To resolve these problems, this document defines a data format which
	can convey the fact that an XML document managed by XCAP has changed.		can convey the fact that an XML document managed by XCAP has changed.
	This data format is an XML document format, called an XCAP diff		This data format is an XML document format, called an XCAP diff
	document. This format can indicate that a document has changed, and		document. This format can indicate that a document has changed, and
	provide its previous and new entity tags. It can also optionally		provide its previous and new entity tags. It can also optionally
	include a set of patch operations [10], which indicate how to		include a set of patch operations [I-D.ietf-simple-xml-patch-ops],
	transform the document from the version prior to the change, to the		which indicate how to transform the document from the version prior
	version after it. XML element and attribute content of XCAP		to the change, to the version after it. XML element and attribute
	documents can also be delivered with this format.		content of XCAP documents can also be delivered with this format.
	XML documents that are equivalent for the purposes of many		XML documents that are equivalent for the purposes of many
	applications may differ in their physical representation. Similar to		applications may differ in their physical representation. Similar to
	XCAP, the canonical form with comments [1] of an XML document		XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of
	determines the logical equivalence when this format is used to patch		an XML document determines the logical equivalence when this format
	XML documents.		is used to patch XML documents.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] and		document are to be interpreted as described in RFC 2119 [RFC2119] and
	indicate requirement levels for compliant implementations.		indicate requirement levels for compliant implementations.
	This specification also defines the following additional terms:		This specification also defines the following additional terms:
	Document: When the term document is used without the "XCAP diff" in		Document: When the term document is used without the "XCAP diff" in
	front of it, it refers to the XCAP document resource about whom		front of it, it refers to the XCAP document resource about whom
	the XCAP diff document is reporting a change.		the XCAP diff document is reporting a change.
	XCAP diff document: The XML document defined by this specification		XCAP diff document: The XML document defined by this specification
	that reports on a set of changes in an XCAP document resource.		that reports on a set of changes in an XCAP document resource.
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	Server: Typically an XCAP server, this is a protocol entity that		Server: Typically an XCAP server, this is a protocol entity that
	generates XCAP diff documents based on its knowledge of a set of		generates XCAP diff documents based on its knowledge of a set of
	XCAP documents.		XCAP documents.
	Client: Typically an XCAP client and SIP User Agent (UA), the client		Client: Typically an XCAP client and SIP User Agent (UA), the client
	consumes XCAP diff documents in order to reconstruct the document		consumes XCAP diff documents in order to reconstruct the document
	stored on the server.		stored on the server.
	3. Structure of an XCAP Diff Document		3. Structure of an XCAP Diff Document
	An XCAP diff document is an XML [2] document that MUST be well-formed		An XCAP diff document is an XML [W3C.REC-xml-20060816] document that
	and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0		MUST be well-formed and SHOULD be valid. XCAP diff documents MUST be
	and MUST be encoded using UTF-8. This specification makes use of XML		based on XML 1.0 and MUST be encoded using UTF-8. This specification
	namespaces for identifying XCAP diff documents and document		makes use of XML namespaces for identifying XCAP diff documents and
	fragments. The namespace URI for elements defined by this		document fragments. The namespace URI for elements defined by this
	specification is a URN [4], using the namespace identifier 'ietf'		specification is a URN [RFC2141], using the namespace identifier
	defined by [6] and extended by [7]. This URN is:		'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is:
	urn:ietf:params:xml:ns:xcap-diff		urn:ietf:params:xml:ns:xcap-diff
	An XCAP diff document begins with the root element tag <xcap-diff>.		An XCAP diff document begins with the root element tag <xcap-diff>.
	This element has a single mandatory attribute, "xcap-root". The		This element has a single mandatory attribute, "xcap-root". The
	value of this attribute is the XCAP root URI for the documents in		value of this attribute is the XCAP root URI for the documents in
	which the changes have taken place. A single XCAP diff document can		which the changes have taken place. A single XCAP diff document can
	only represent changes in documents within the same XCAP root. The		only represent changes in documents within the same XCAP root. The
	content of the <xcap-diff> element is an unordered sequence of		content of the <xcap-diff> element is an unordered sequence of
	<document>, <element> and <attribute> elements followed by any number		<document>, <element> and <attribute> elements followed by any number
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	resource. Also both attributes MAY be used to indicate an ETag		resource. Also both attributes MAY be used to indicate an ETag
	change without any document modifications (patches).		change without any document modifications (patches).
	The "previous-etag" and "new-etag" need not have been sequentially		The "previous-etag" and "new-etag" need not have been sequentially
	assigned ETags at the server. An XCAP diff document can indicate		assigned ETags at the server. An XCAP diff document can indicate
	changes that have occurred over a series of XCAP operations. The		changes that have occurred over a series of XCAP operations. The
	only requirement then is that, the sequence of events, when executed		only requirement then is that, the sequence of events, when executed
	serially, will result in the transformation of the document with the		serially, will result in the transformation of the document with the
	ETag "previous-etag" to the one whose ETag is "new-etag". Also the		ETag "previous-etag" to the one whose ETag is "new-etag". Also the
	series of operations do not have to be the same exact series of		series of operations do not have to be the same exact series of
	operations that occurred at the server.		operations that occurred at the server. If several <document>
			elements with the same "sel" selector value exist in the XCAP diff
			document, i.e. for example, the full ETag change history is
			indicated, the corresponding patches MUST be appliable in the given
			document order.
	Each <document> element contains either a sequence of patching		Each <document> element contains either a sequence of patching
	instructions or an indication that the body hasn't semantically		instructions or an indication that the body hasn't semantically
	changed. The latter means that the document has been assigned a new		changed. The latter means that the document has been assigned a new
	ETag but its content is unchanged and it is indicated by the <body-		ETag but its content is unchanged and it is indicated by the <body-
	not-changed> element. Patching instructions are described by the		not-changed> element. Patching instructions are described by the
	<add>, <replace> and <remove> elements. These elements use the		<add>, <replace> and <remove> elements. These elements use the
	corresponding add, replace and remove types defined in [10], and		corresponding add, replace and remove types defined in
	define a set of patch operations that can be applied to transform the		[I-D.ietf-simple-xml-patch-ops], and define a set of patch operations
	document. See [10] for instructions on how this transformation is		that can be applied to transform the document. See
	effected. The <document> element can also contain elements from		[I-D.ietf-simple-xml-patch-ops] for instructions on how this
	other namespaces for the purposes of extensibility. Any unknown		transformation is effected. The <document> element can also contain
	elements MUST be ignored.		elements from other namespaces for the purposes of extensibility.
			The <add>, <replace> and <remove> elements allow extension attributes
			from any namespace. Any unknown elements <document> element or
			attributes of patch operation elements MUST be ignored.
	Figure 1 shows <document> element content and how corresponding		Figure 1 shows <document> element content and how corresponding
	resource or metadata changes. An external document retrieval means		resource or metadata changes. An external document retrieval means
	in practice an HTTP GET requests for a relevant resource.		in practice an HTTP GET requests for a relevant resource.
	+-----------+----------+-----------+----------+-------------------+		+-----------+----------+-----------+----------+-------------------+
	| previous- | new- | <add> | <body- | XCAP resource/ |		| previous- | new- | <add> | <body- | XCAP resource/ |
	| etag | etag | <replace> | not- | metadata change |		| etag | etag | <replace> | not- | metadata change |
	| | | <remove> | changed> | |		| | | <remove> | changed> | |
	+-----------+----------+-----------+----------+-------------------+		+-----------+----------+-----------+----------+-------------------+
	skipping to change at page 6, line 47 ¶		skipping to change at page 7, line 5 ¶
	percent endoced relative URI following XCAP conventions when		percent endoced relative URI following XCAP conventions when
	selecting elements. The XCAP Node Selector MUST always locate a		selecting elements. The XCAP Node Selector MUST always locate a
	unique node, the "exists" attribute thus shows whether an element		unique node, the "exists" attribute thus shows whether an element
	exists or not in the XCAP document. When the "exists" attribute is		exists or not in the XCAP document. When the "exists" attribute is
	absent from the <element> element, the indicated element still exists		absent from the <element> element, the indicated element still exists
	in the XCAP document. The located result element exists as a child		in the XCAP document. The located result element exists as a child
	element of the <element> element. It should be noted, that only the		element of the <element> element. It should be noted, that only the
	full content of an element is shown if it exists, there are no		full content of an element is shown if it exists, there are no
	conventions for patching these elements. In a corner case where the		conventions for patching these elements. In a corner case where the
	content of this element cannot be presented for some reason, although		content of this element cannot be presented for some reason, although
	it exists in the XCAP document, the <element> element MUST not have		it exists in the XCAP document, the <element> element MUST NOT have
	any child nodes.		any child nodes.
	As the result XML element is typically namespace qualified, all		As the result XML element is typically namespace qualified, all
	needed namespace declarations MUST exist within the <xml-diff>		needed namespace declarations MUST exist within the <xml-diff>
	document. The possible local namespace declarations within the		document. The possible local namespace declarations within the
	result element exist unmodified as in the source document, similar to		result element exist unmodified as in the source document, similar to
	XCAP conventions. Other namespace references MUST be resolved from		XCAP conventions. Other namespace references MUST be resolved from
	the context of the <element> or its parent elements. The prefixes of		the context of the <element> or its parent elements. The prefixes of
	qualified names (QName) [3] of XML nodes also remain as they exist		qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes
	originally in the source XCAP document.		also remain as they exist originally in the source XCAP document.
	Each <attribute> element indicates the existing attribute content of		Each <attribute> element indicates the existing attribute content of
	an XCAP document. It has one mandatory attribute, "sel", and one		an XCAP document. It has one mandatory attribute, "sel", and one
	optional attribute, "exists". The "sel" attribute of the <attribute>		optional attribute, "exists". The "sel" attribute of the <attribute>
	element identifies an XML attribute of an XCAP document. It is a		element identifies an XML attribute of an XCAP document. It is a
	percent endoced relative URI following XCAP conventions when		percent endoced relative URI following XCAP conventions when
	selecting attributes. The "exists" attribute indicates whether an		selecting attributes. The "exists" attribute indicates whether an
	attribute exists or not in the XCAP document. When the "exists"		attribute exists or not in the XCAP document. When the "exists"
	attribute is absent from the <attribute> element, the indicated		attribute is absent from the <attribute> element, the indicated
	attribute exists in the XCAP document. The child text node of the		attribute still exists in the XCAP document. The child text node of
	<attribute> element indicates the value of the located attribute.		the <attribute> element indicates the value of the located attribute.
			Note that if the attribute is namespace qualified, the query
			parameter of the XCAP URI indicates the attached namespace URI and
			the prefix in the XCAP source document.
	4. XML Schema		4. XML Schema
	The XML Schema for the XCAP diff format.		The XML Schema for the XCAP diff format.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns="urn:ietf:params:xml:ns:xcap-diff"		xmlns="urn:ietf:params:xml:ns:xcap-diff"
	targetNamespace="urn:ietf:params:xml:ns:xcap-diff"		targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified">		attributeFormDefault="unqualified">
	<!-- include patch-ops -->		<!-- include patch-ops -->
	<xs:include		<xs:include
	schemaLocation="urn:ietf:params:xml:schema:xml-patch-ops"/>		schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
	<!-- document root -->		<!-- document root -->
	<xs:element name="xcap-diff">		<xs:element name="xcap-diff">
	<xs:complexType>		<xs:complexType>
	<xs:sequence minOccurs="0">		<xs:sequence minOccurs="0">
	<xs:sequence minOccurs="0" maxOccurs="unbounded">		<xs:sequence minOccurs="0" maxOccurs="unbounded">
	<xs:choice>		<xs:choice>
	<xs:element name="document" type="documentType"/>		<xs:element name="document" type="documentType"/>
	<xs:element name="element" type="elementType"/>		<xs:element name="element" type="elementType"/>
	<xs:element name="attribute" type="attributeType"/>		<xs:element name="attribute" type="attributeType"/>
	</xs:choice>		</xs:choice>
	</xs:sequence>		</xs:sequence>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>		<xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute processContents="lax"/>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<!-- xcap document type -->		<!-- xcap document type -->
	<xs:complexType name="documentType">		<xs:complexType name="documentType">
	<xs:choice minOccurs="0">		<xs:choice minOccurs="0">
	<xs:element name="body-not-changed" type="emptyType"/>		<xs:element name="body-not-changed" type="emptyType"/>
	<xs:sequence minOccurs="0" maxOccurs="unbounded">		<xs:sequence minOccurs="0" maxOccurs="unbounded">
	<xs:choice>		<xs:choice>
	<xs:element name="add">		<xs:element name="add">
	<xs:complexType>		<xs:complexType>
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="add">		<xs:extension base="add">
	<xs:anyAttribute processContents="lax"/>		<xs:anyAttribute processContents="lax"/>
	</xs:extension>		</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="remove">		<xs:element name="remove">
	<xs:complexType>		<xs:complexType>
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="remove">		<xs:extension base="remove">
	<xs:anyAttribute processContents="lax"/>		<xs:anyAttribute processContents="lax"/>
	</xs:extension>		</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="replace">		<xs:element name="replace">
	<xs:complexType>		<xs:complexType>
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="replace">		<xs:extension base="replace">
	<xs:anyAttribute processContents="lax"/>		<xs:anyAttribute processContents="lax"/>
	</xs:extension>		</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:any namespace="##other" processContents="lax"/>		<xs:any namespace="##other" processContents="lax"/>
	skipping to change at page 9, line 5 ¶		skipping to change at page 9, line 4 ¶
	<xs:element name="replace">		<xs:element name="replace">
	<xs:complexType>		<xs:complexType>
	<xs:complexContent>		<xs:complexContent>
	<xs:extension base="replace">		<xs:extension base="replace">
	<xs:anyAttribute processContents="lax"/>		<xs:anyAttribute processContents="lax"/>
	</xs:extension>		</xs:extension>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:any namespace="##other" processContents="lax"/>		<xs:any namespace="##other" processContents="lax"/>
	</xs:choice>		</xs:choice>
	</xs:sequence>		</xs:sequence>
	</xs:choice>		</xs:choice>
	<xs:attribute name="sel" type="xs:anyURI" use="required"/>		<xs:attribute name="sel" type="xs:anyURI" use="required"/>
	<xs:attribute name="new-etag" type="xs:string" use="optional"/>		<xs:attribute name="new-etag" type="xs:string" use="optional"/>
	<xs:attribute name="previous-etag" type="xs:string" use="optional"/>		<xs:attribute name="previous-etag" type="xs:string" use="optional"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute processContents="lax"/>
	</xs:complexType>		</xs:complexType>
	<!-- xcap element type -->		<!-- xcap element type -->
	<xs:complexType name="elementType">		<xs:complexType name="elementType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:any processContents="lax" namespace="##any"		<xs:any processContents="lax" namespace="##any"
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	</xs:sequence>		</xs:sequence>
	skipping to change at page 11, line 4 ¶		skipping to change at page 10, line 47 ¶
	actual changes are not shown. The <service> element exists in the		actual changes are not shown. The <service> element exists in the
	rls-services "index" document and its full content is shown. Note		rls-services "index" document and its full content is shown. Note
	that the <service> element is attached with a default namespace		that the <service> element is attached with a default namespace
	declaration within the original document. Similarly, a "uri"		declaration within the original document. Similarly, a "uri"
	attribute content is shown from the same "index" document as an		attribute content is shown from the same "index" document as an
	illustrative example.		illustrative example.
	6. Security Considerations		6. Security Considerations
	XCAP diff documents can include changes from one document to another.		XCAP diff documents can include changes from one document to another.
	As a consequence, if the document itself is sensitive and requires		As a consequence, if the document itself is sensitive and requires
	confidentiality, integrity or authentication, then the same applies		confidentiality, integrity or authentication, then the same applies
	to the XCAP diff format. Therefore, protocols which transport XCAP		to the XCAP diff format. Therefore, protocols which transport XCAP
	diff documents must provide sufficient security capabilities for		diff documents must provide sufficient security capabilities for
	transporting the document itself.		transporting the document itself.
	7. IANA Considerations		7. IANA Considerations
	There are several IANA considerations associated with this		There are several IANA considerations associated with this
	specification.		specification.
	7.1. application/xcap-diff+xml MIME Type		7.1. application/xcap-diff+xml MIME Type
	MIME media type name: application		MIME media type name: application
	MIME subtype name: xcap-diff+xml		MIME subtype name: xcap-diff+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 [RFC3023].
	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 [RFC3023].
	Security considerations: See Section 10 of RFC 3023 [5] and		Security considerations: See Section 10 of RFC 3023 [RFC3023] and
	Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace		Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: 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: This document.		Published specification: This document.
	Applications which use this media type: This document type has		Applications which use this media type: This document type has
	been used to support manipulation of resource lists [14] using		been used to support manipulation of resource lists [RFC4826]
	XCAP.		using XCAP.
	Additional Information:		Additional Information:
	Magic Number: None		Magic Number: None
	File Extension: .xdf		File Extension: .xdf
	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. URN Sub-Namespace Registration for		7.2. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:xcap-diff		urn:ietf:params:xml:ns:xcap-diff
	This section registers a new XML namespace, as per the guidelines in		This section registers a new XML namespace, as per the guidelines in
	[7]		[RFC3688]
	URI: The URI for this namespace is		URI: The URI for this namespace is
	urn:ietf:params:xml:ns:xcap-diff.		urn:ietf:params:xml:ns:xcap-diff.
	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
	skipping to change at page 12, line 47 ¶		skipping to change at page 12, line 44 ¶
	<h2>urn:ietf:params:xml:ns:xcap-diff</h2>		<h2>urn:ietf:params:xml:ns:xcap-diff</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. Schema Registration		7.3. Schema Registration
	This section registers a new XML schema per the procedures in [7].		This section registers a new XML schema per the procedures in
			[RFC3688].
	URI: urn:ietf:params:xml:schema:xcap-diff		URI: urn:ietf:params:xml:schema:xcap-diff
	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.		Section 4.
	8. Acknowledgments		8. Acknowledgments
	The authors would like to thank Pavel Dostal, Jeroen van Bemmel,		The authors would like to thank Pavel Dostal, Jeroen van Bemmel,
	Martin Hynar and Anders Lindgren for their valuable comments.		Martin Hynar and Anders Lindgren for their valuable comments.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[1] "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,		[W3C.REC-xml-20060816]
	March 2001.		Maler, E., Paoli, J., Bray, T., Yergeau, F., and C.
			Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
			(Fourth Edition)", World Wide Web Consortium
			Recommendation REC-xml-20060816, August 2006,
			<http://www.w3.org/TR/2006/REC-xml-20060816>.
	[2] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C		[W3C.REC-xml-c14n-20010315]
	Recommendation REC-xml-20060816 , August 2006.		Boyer, J., "Canonical XML Version 1.0", World Wide Web
			Consortium Recommendation REC-xml-c14n-20010315,
			March 2001,
			<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
	[3] "Namespaces in XML (Second Edition)", W3C Recommendation REC-		[W3C.REC-xml-names-20060816]
	xml-names-20060816 , August 2006.		Hollander, D., Bray, T., Layman, A., and R. Tobin,
			"Namespaces in XML 1.0 (Second Edition)", World Wide Web
			Consortium Recommendation REC-xml-names-20060816,
			August 2006,
			<http://www.w3.org/TR/2006/REC-xml-names-20060816>.
	[4] Moats, R., "URN syntax", RFC 2141, May 1997.		[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
	[5] Murata, M., "XML media types", RFC 3023, January 2001.		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
			Types", RFC 3023, January 2001.
	[6] Moats, R., "A URN namespace for IETF documents", RFC 2648,		[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
	Aug. 1999.		August 1999.
	[7] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[9] Rosenberg, J., "The Extensible Markup Language (XML)		[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)", RFC 4825, May 2007.		Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
	[10] Urpalainen, J., "An Extensible Markup Language (XML) Patch		[I-D.ietf-simple-xml-patch-ops]
	Operations Framework Utilizing XML Path Language (XPath)		Urpalainen, J., "An Extensible Markup Language (XML) Patch
	Selectors", draft-ietf-simple-xml-patch-ops-03, August 2007.		Operations Framework Utilizing XML Path Language (XPath)
			Selectors", draft-ietf-simple-xml-patch-ops-03 (work in
			progress), August 2007.
	9.2. Informative References		9.2. Informative References
	[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		A., Peterson, J., Sparks, R., Handley, M., and E.
	Session Initiation Protocol", RFC 3261, June 2002.		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event		[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
	Notification", RFC 3265, June 2002.		Event Notification", RFC 3265, June 2002.
	[13] Roach, A., Campbell, B., and J. Rosenberg, "A Session		[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session
	Initiation Protocol (SIP) Event Notification Extension for		Initiation Protocol (SIP) Event Notification Extension for
	Resource Lists", RFC 4662, August 2006.		Resource Lists", RFC 4662, August 2006.
	[14] Rosenberg, J., "Extensible Markup Language (XML) Formats for		[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
	Representing Resource Lists", RFC 4826, May 2007.		for Representing Resource Lists", RFC 4826, May 2007.
	[15] Burger, E., Ed., "A Mechanism for Content Indirection in		[RFC4483] Burger, E., "A Mechanism for Content Indirection in
	Session Initiation Protocol (SIP) Messages", RFC 4483,		Session Initiation Protocol (SIP) Messages", RFC 4483,
	May 2006.		May 2006.
	Authors' Addresses		Authors' Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco		Cisco
	Edison, NJ		Edison, NJ
	US		US
	Email: jdrosen@cisco.com		Email: jdrosen@cisco.com
	URI: http://www.jdrosen.net		URI: http://www.jdrosen.net
End of changes. 55 change blocks.
	109 lines changed or deleted		126 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/