< draft-ietf-simple-xcap-diff-05.txt		draft-ietf-simple-xcap-diff-06.txt >
	SIMPLE J. Rosenberg		SIMPLE J. Rosenberg
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Standards Track March 5, 2007		Intended status: Standards Track J. Urpalainen
	Expires: September 6, 2007		Expires: February 18, 2008 Nokia
			August 17, 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-05		draft-ietf-simple-xcap-diff-06
	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 35 ¶		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 September 6, 2007.		This Internet-Draft will expire on February 18, 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
	(XCAP). This format indicates the document that has changed and its		(XCAP). This format indicates the document that has changed and its
	former and new entity tags. It also can indicate the specific change		former and new entity tags. It also can indicate the specific change
	that was made in the document, using an XML patch format. XCAP diff		that was made in the document, using an XML patch format. This
	documents can be delivered to clients using a number of means,		format allows also indications of element and attribute content of an
	including a Session Initiation Protocol (SIP) event package.		XML document. XCAP diff documents can be delivered to clients using
			a number of means, including a Session Initiation Protocol (SIP)
			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 . . . . . . . . . . . . . . . . . . . . . . . 7		5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 8		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 . . . . . . . . . . . . . 9		urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12
	7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 10		7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11		9.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
			Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Extensible Markup Language (XML) Configuration Access Protocol		The Extensible Markup Language (XML) Configuration Access Protocol
	(XCAP) [8] is a protocol that allows clients to manipulate XML		(XCAP) [9] 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 [12] subscriptions (also known as presence lists) allow		resource list [13] subscriptions (also known as presence lists) allow
	a client to have a single SIP subscription to a list of users, where		a client to have a single SIP subscription to a list of users, where
	the list is maintained on a server. The server will obtain presence		the list is maintained on a server. The server will obtain presence
	for those users and report it back to the client. This application		for those users and report it back to the client. This application
	requires the server, called a Resource List Server (RLS), to have		requires the server, called a Resource List Server (RLS), to have
	access to the list of presentities. This list needs to be		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) [10] event package [11] to subscribe to change events		Protocol (SIP) [11] event package [12] to subscribe to change events
	in XCAP documents. This notification needs to indicate the specific		in XCAP documents. This notification needs to indicate the specific
	resource that changed, and how it changed. One solution for the		resource that changed, and how it changed. One solution for the
	format of such a change notification would be a content indirection		format of such a change notification would be a content indirection
	object [15]. Though content indirection can tell a client that a		object [15]. Though content indirection can tell a client that a
	document has changed, it provides it with MIME Content-ID indicating		document has changed, it provides it with MIME Content-ID indicating
	the new version of the document. The MIME Content-ID is not the same		the new version of the document. The MIME Content-ID is not the same
	as the entity tag, which is used by XCAP for document versioning. As		as the entity tag, which is used by XCAP for document versioning. As
	such, a client cannot easily ascertain whether an indication of a		such, a client cannot easily ascertain whether an indication of a
	change in a document is due to a change it just made, or due to a		change in a document is due to a change it just made, or due to a
	change another client made at around the same time. Furthermore,		change another client made at around the same time. Furthermore,
	content indirections don't indicate how a document changed; they		content indirections don't indicate how a document changed; they
	would only be able to indicate that it did change.		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 [9], which indicate how to		include a set of patch operations [10], which indicate how to
	transform the document from the version prior to the change, to the		transform the document from the version prior to the change, to the
	version after it.		version after it. XML element and attribute content of XCAP
			documents can also be delivered with this format.
			XML documents that are equivalent for the purposes of many
			applications may differ in their physical representation. Similar to
			XCAP, the canonical form with comments [1] of an XML document
			determines the logical equivalence when this format is used to patch
			XML documents.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and		and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] 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 36 ¶		skipping to change at page 4, line 42 ¶
	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 [2] document that MUST be well-formed
	and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0		and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0
	and MUST be encoded using UTF-8. This specification makes use of XML		and MUST be encoded using UTF-8. This specification makes use of XML
	namespaces for identifying XCAP diff documents and document		namespaces for identifying XCAP diff documents and document
	fragments. The namespace URI for elements defined by this		fragments. The namespace URI for elements defined by this
	specification is a URN [3], using the namespace identifier 'ietf'		specification is a URN [4], using the namespace identifier 'ietf'
	defined by [5] and extended by [6]. This URN is:		defined by [6] and extended by [7]. 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 a sequence of <document>		content of the <xcap-diff> element is an unordered sequence of
	elements. Each <document> element specifies changes in a specific		<document>, <element> and <attribute> elements followed by any number
	document within the XCAP root. It has one mandatory attribute, "doc-		of elements from other namespaces for the purposes of extensibility.
	selector", and a three optional attributes, "new-etag", "previous-		Any such unknown elements MUST be ignored by the client. Each
	etag" and "hash". The "doc-selector" identifies the specific		<document> element specifies changes in a specific document within
	document within the XCAP root for which changes are indicated. Its		the XCAP root. It has one mandatory attribute, "sel", and a two
	content MUST be a relative path reference, with the base URI being		optional attributes, "new-etag" and "previous-etag". The "sel"
	equal to the XCAP root URI. The "new-etag" attribute provides the		attribute of the <document> element identifies the specific document
	etag for the document after the application of the changes, assuming		within the XCAP root for which changes are indicated. Its content
	the document exists after those changes. If the change being		MUST be a relative path reference, with the base URI being equal to
	reported is the deletion of the document, the "new-etag" attribute		the XCAP root URI. The "new-etag" attribute provides the entity tag
	will not be present. A server MUST include the "new-etag" unless the		(ETag) for the document after the application of the changes,
	document does not exist subsequent to the changes reported in the		assuming the document exists after those changes. The "previous-
	XCAP diff document. The "previous-etag" attribute provides an		etag" attribute provides an identifier for the document instance
	identifier for the document instance prior to the change. If the		prior to the change. If the change being reported is the removal of
	document did not exist prior to the change (that is, the change was		a document, the "previous-etag" MUST only be included and the "new-
	the creation of the document), the "previous-etag" is not present.		etag" attribute will not be present. The "new-etag" attribute MUST
			only exist alone when the document either exists or it was just
			created (no patch included). Both attributes are present when a
			patch (or series of XCAP operations) has been applied to the
			resource. Also both attributes MAY be used to indicate an ETag
			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.		changes that have occurred over a series of XCAP operations. The
			only requirement then is that, the sequence of events, when executed
			serially, will result in the transformation of the document with 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
			operations that occurred at the server.
	The optional "hash" attribute provides an HMAC of the document		Each <document> element contains either a sequence of patching
	instance whose etag is "new-etag", once that document is represented		instructions or an indication that the body hasn't semantically
	in canonical form. To compute this value, the server MUST apply the		changed. The latter means that the document has been assigned a new
	mandatory XML canonicalization defined in the Canonical XML 1.0 [1]		ETag but its content is unchanged and it is indicated by the <body-
	specification, and then computes an HMAC [13] using SHA1 over this		not-changed> element. Patching instructions are described by the
	canonical document, with a key whose value is 0x2238a. The result is		<add>, <replace> and <remove> elements. These elements use the
	the value of the "hash" attribute. This attribute is optional, and a		corresponding add, replace and remove types defined in [10], and
	server MAY elect not to include it. Even if present, a client MAY		define a set of patch operations that can be applied to transform the
	elect to ignore it.		document. See [10] for instructions on how this transformation is
			effected. The <document> element can also contain elements from
			other namespaces for the purposes of extensibility. Any unknown
			elements MUST be ignored.
	Each <document> element contains zero or one <change-log> element,		Figure 1 shows <document> element content and how corresponding
	followed by any number of elements from another namespace for the		resource or metadata changes. An external document retrieval means
	purposes of extensibility. Any such unknown elements MUST be ignored		in practice an HTTP GET requests for a relevant resource.
	by the client. When present, the <change-log> element tells the
	client the specific set of XML patch operations that can be applied
	to transform the document from the version whose etag was "previous-
	etag" to the version whose etag is "new-etag". If the "previous-
	etag" is not present, the <change-log> element tells the client the
	specific set of XML patch operations that can be applied to create a
	document from nothing, and result in the document whose etag is "new-
	etag". If the "new-etag" attribute is not present, it implies that
	the document was removed. In that case, the <change-log> is
	meaningless and SHOULD be ignored.
	The series of operations in the <change-log> do not have to be the		+-----------+----------+-----------+----------+-------------------+
	same exact series of operations that occurred at the server. The		| previous- | new- | <add> | <body- | XCAP resource/ |
	only requirement is that, if the server includes the <change-log>		| etag | etag | <replace> | not- | metadata change |
	element, the sequence of events, when executed serially, will result		| | | <remove> | changed> | |
	in the transformation of the document with the etag "previous-etag"		+-----------+----------+-----------+----------+-------------------+
	to the one whose etag is "new-etag". If the <change-log> element is		| xxx | yyy | * | - | resource patched, |
	not present, it means that the document has changed in some way, but		| | | | | patch included |
	the XCAP server has elected not to provide the set of changes. In		+-----------+----------+-----------+----------+-------------------+
	that case, a client can retrieve the latest document if its cached		| xxx | yyy | - | - | resource patched, |
	etag doesn't match the value of "new-etag".		| | | | | external document |
			| | | | | retrieval |
			+-----------+----------+-----------+----------+-------------------+
			| xxx | yyy | - | * | only ETag changed |
			+-----------+----------+-----------+----------+-------------------+
			| - | yyy | - | - | resource created |
			| | | | | or exists, |
			| | | | | external document |
			| | | | | retrieval |
			+-----------+----------+-----------+----------+-------------------+
			| xxx | - | - | - | resource removed |
			+-----------+----------+-----------+----------+-------------------+
	It is important to note that a <document> element with no <change-		Figure 1: <document> element content / corresponding resource changes
	log> child is not equivalent to a <document> element with a <change-
	log> child that is itself empty. The latter means that the document
	has been assigned a new etag but its content is unchanged. The
	former means that it has been assigned a new etag as a result of a
	change, but the specific changes are not being reported in the XCAP
	diff document.
	Each <change-log> element contains a sequence of instructions, each		Each <element> element indicates the existing element content of an
	of which can be <add>, <replace> and <remove> elements. These		XCAP document. It has one mandatory attribute, "sel", and one
	elements use the corresponding add, replace and remove types defined		optional attribute, "exists". The "sel" attribute of the <element>
	in [9], and define a set of patch operations that can be applied to		element identifies an XML element of an XCAP document. It is a
	transform the document. See [9] for instructions on how this		percent endoced relative URI following XCAP conventions when
	transformation is effected. The <change-log> element can also		selecting elements. The XCAP Node Selector MUST always locate a
	contain elements from other namespaces for the purposes of		unique node, the "exists" attribute thus shows whether an element
	extensibility. Any unknown elements MUST be ignored.		exists or not in the XCAP document. When the "exists" attribute is
			absent from the <element> element, the indicated element still exists
			in the XCAP document. The located result element exists as a child
			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
			conventions for patching these elements. In a corner case where the
			content of this element cannot be presented for some reason, although
			it exists in the XCAP document, the <element> element MUST not have
			any child nodes.
			As the result XML element is typically namespace qualified, all
			needed namespace declarations MUST exist within the <xml-diff>
			document. The possible local namespace declarations within the
			result element exist unmodified as in the source document, similar to
			XCAP conventions. Other namespace references MUST be resolved from
			the context of the <element> or its parent elements. The prefixes of
			qualified names (QName) [3] of XML nodes also remain as they exist
			originally in the source XCAP document.
			Each <attribute> element indicates the existing attribute content of
			an XCAP document. It has one mandatory attribute, "sel", and one
			optional attribute, "exists". The "sel" attribute of the <attribute>
			element identifies an XML attribute of an XCAP document. It is a
			percent endoced relative URI following XCAP conventions when
			selecting attributes. The "exists" attribute indicates whether an
			attribute exists or not in the XCAP document. When the "exists"
			attribute is absent from the <attribute> element, the indicated
			attribute exists in the XCAP document. The child text node of the
			<attribute> element indicates the value of the located attribute.
	4. XML Schema		4. XML Schema
	<?xml version="1.0" encoding="UTF-8"?>		The XML Schema for the XCAP diff format.
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns="urn:ietf:params:xml:ns:xcap-diff"		<?xml version="1.0" encoding="UTF-8"?>
	targetNamespace="urn:ietf:params:xml:ns:xcap-diff"		<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		xmlns="urn:ietf:params:xml:ns:xcap-diff"
	<xs:include schemaLocation="urn:ietf:params:xml:schema:xml-patch-ops"/>		targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
	<xs:complexType name="documentType">		elementFormDefault="qualified"
	<xs:sequence>		attributeFormDefault="unqualified">
	<xs:element name="change-log" type="change-logType" minOccurs="0"/>
	<xs:any namespace="##other" processContents="lax"		<!-- include patch-ops -->
	minOccurs="0" maxOccurs="unbounded"/>		<xs:include
	</xs:sequence>		schemaLocation="urn:ietf:params:xml:schema:xml-patch-ops"/>
	<xs:attribute name="doc-selector" type="xs:anyURI" use="required"/>
	<xs:attribute name="new-etag" type="xs:string" use="optional"/>		<!-- document root -->
	<xs:attribute name="previous-etag" type="xs:string" use="optional"/>		<xs:element name="xcap-diff">
	<xs:attribute name="hash" type="xs:string" use="optional"/>		<xs:complexType>
	<xs:anyAttribute namespace="##other" processContents="lax"/>		<xs:sequence minOccurs="0">
	</xs:complexType>
	<xs:element name="xcap-diff">		<xs:sequence minOccurs="0" maxOccurs="unbounded">
	<xs:complexType>		<xs:choice>
	<xs:sequence maxOccurs="unbounded">		<xs:element name="document" type="documentType"/>
	<xs:element name="document" type="documentType"/>		<xs:element name="element" type="elementType"/>
	</xs:sequence>		<xs:element name="attribute" type="attributeType"/>
	<xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>		</xs:choice>
	</xs:complexType>		</xs:sequence>
	</xs:element>		<xs:any namespace="##other" processContents="lax"
	<xs:complexType name="change-logType">		minOccurs="0" maxOccurs="unbounded"/>
	<xs:sequence minOccurs="0" maxOccurs="unbounded">
	<xs:choice>		</xs:sequence>
	<xs:element name="add" type="add"/>		<xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
	<xs:element name="remove" type="remove"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	<xs:element name="replace" type="replace"/>		</xs:complexType>
	<xs:any namespace="##other" processContents="lax"/>		</xs:element>
	</xs:choice>
	</xs:sequence>		<!-- xcap document type -->
	</xs:complexType>		<xs:complexType name="documentType">
	</xs:schema>
			<xs:choice minOccurs="0">
			<xs:element name="body-not-changed" type="emptyType"/>
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:choice>
			<xs:element name="add">
			<xs:complexType>
			<xs:complexContent>
			<xs:extension base="add">
			<xs:anyAttribute processContents="lax"/>
			</xs:extension>
			</xs:complexContent>
			</xs:complexType>
			</xs:element>
			<xs:element name="remove">
			<xs:complexType>
			<xs:complexContent>
			<xs:extension base="remove">
			<xs:anyAttribute processContents="lax"/>
			</xs:extension>
			</xs:complexContent>
			</xs:complexType>
			</xs:element>
			<xs:element name="replace">
			<xs:complexType>
			<xs:complexContent>
			<xs:extension base="replace">
			<xs:anyAttribute processContents="lax"/>
			</xs:extension>
			</xs:complexContent>
			</xs:complexType>
			</xs:element>
			<xs:any namespace="##other" processContents="lax"/>
			</xs:choice>
			</xs:sequence>
			</xs:choice>
			<xs:attribute name="sel" type="xs:anyURI" use="required"/>
			<xs:attribute name="new-etag" type="xs:string" use="optional"/>
			<xs:attribute name="previous-etag" type="xs:string" use="optional"/>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
			</xs:complexType>
			<!-- xcap element type -->
			<xs:complexType name="elementType">
			<xs:complexContent>
			<xs:restriction base="xs:anyType">
			<xs:sequence>
			<xs:any processContents="lax" namespace="##any"
			minOccurs="0" maxOccurs="1"/>
			</xs:sequence>
			<xs:attribute name="sel" type="xs:string"
			use="required"/>
			<xs:attribute name="exists" type="xs:boolean"/>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
			<!-- xcap attribute type -->
			<xs:complexType name="attributeType">
			<xs:simpleContent>
			<xs:extension base="xs:string">
			<xs:attribute name="sel" type="xs:string"
			use="required"/>
			<xs:attribute name="exists" type="xs:boolean"/>
			</xs:extension>
			</xs:simpleContent>
			</xs:complexType>
			<!-- empty type -->
			<xs:complexType name="emptyType"/>
			</xs:schema>
	5. Example Document		5. 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.
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"		<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
	xcap-root="http://xcap.example.com/root">		xcap-root="http://xcap.example.com/root/">
	<document new-etag="7ahggs"
	doc-selector="resource-lists/users/joe/coworkers"
	previous-etag="8a77f8d"/>
	</xcap-diff>
	This indicates that the document with URI		<document new-etag="7ahggs"
	"http://xcap.example.com/root/resource-lists/users/joe/coworkers" has		sel="resource-lists/users/sip:joe@example.com/coworkers"
	changed. Its previous entity tag is 8a77f8d and its new one is		previous-etag="8a77f8d"/>
	7ahggs.
			<d:element sel="rls-services/users/sip:joe@example.com/index/~~
			/*/service%5b@uri='sip:marketing@example.com'%5d"
			xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
			xmlns="urn:ietf:params:xml:ns:rls-services"
			xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
			><service uri="sip:marketing@example.com">
			<list name="marketing">
			<rl:entry uri="sip:joe@example.com"/>
			<rl:entry uri="sip:sudhir@example.com"/>
			</list>
			<packages>
			<package>presence</package>
			</packages>
			</service></d:element>
			<attribute
			sel="rls-services/users/sip:joe@example.com/index/~~/*/service/@uri"
			>sip:marketing@example.com</attribute>
			</xcap-diff>
			This indicates that the document with URI "http://xcap.example.com/
			root/resource-lists/users/sip:joe@example.com/coworkers" has changed.
			Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but
			actual changes are not shown. The <service> element exists in the
			rls-services "index" document and its full content is shown. Note
			that the <service> element is attached with a default namespace
			declaration within the original document. Similarly, a "uri"
			attribute content is shown from the same "index" document as an
			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, than 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 [4].		specified in RFC 3023 [5].
	Encoding considerations: Same as encoding considerations of		Encoding considerations: Same as encoding considerations of
	application/xml as specified in RFC 3023 [4].		application/xml as specified in RFC 3023 [5].
	Security considerations: See Section 10 of RFC 3023 [4] and		Security considerations: See Section 10 of RFC 3023 [5] 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 [14] using
	XCAP.		XCAP.
	skipping to change at page 9, line 20 ¶		skipping to change at page 12, line 4 ¶
	been used to support manipulation of resource lists [14] using		been used to support manipulation of resource lists [14] using
	XCAP.		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
	[6]		[7]
	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 10, line 27 ¶		skipping to change at page 12, line 47 ¶
	<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 [6].		This section registers a new XML schema per the procedures in [7].
	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. References		8. Acknowledgments
	8.1. Normative References		The authors would like to thank Pavel Dostal, Jeroen van Bemmel,
			Martin Hynar and Anders Lindgren for their valuable comments.
	[1] Boyer, J., "Canonical XML Version 1.0", World Wide Web		9. References
	Consortium Recommendation REC-xml-c14n-20010315, March 2001,
	<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
	[2] Sperberg-McQueen, C., Maler, E., Yergeau, F., Bray, T., and J.		9.1. Normative References
	Paoli, "Extensible Markup Language (XML) 1.0 (Third Edition)",
	World Wide Web Consortium FirstEdition REC-xml-20040204,
	February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
	[3] Moats, R., "URN Syntax", RFC 2141, May 1997.		[1] "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,
			March 2001.
	[4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",		[2] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C
	RFC 3023, January 2001.		Recommendation REC-xml-20060816 , August 2006.
	[5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,		[3] "Namespaces in XML (Second Edition)", W3C Recommendation REC-
	August 1999.		xml-names-20060816 , August 2006.
	[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[4] Moats, R., "URN syntax", RFC 2141, May 1997.
			[5] Murata, M., "XML media types", RFC 3023, January 2001.
			[6] Moats, R., "A URN namespace for IETF documents", RFC 2648,
			Aug. 1999.
			[7] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
	January 2004.		January 2004.
	[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[8] 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.
	[8] Rosenberg, J., "The Extensible Markup Language (XML)		[9] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)",		Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
	draft-ietf-simple-xcap-12 (work in progress), October 2006.
	[9] Urpalainen, J., "An Extensible Markup Language (XML) Patch		[10] Urpalainen, J., "An Extensible Markup Language (XML) Patch
	Operations Framework Utilizing XML Path Language (XPath)		Operations Framework Utilizing XML Path Language (XPath)
	Selectors", draft-ietf-simple-xml-patch-ops-02 (work in		Selectors", draft-ietf-simple-xml-patch-ops-03, August 2007.
	progress), March 2006.
	8.2. Informative References		9.2. Informative References
	[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	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.
	[11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event		[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
	Notification", RFC 3265, June 2002.		Notification", RFC 3265, June 2002.
	[12] Roach, A., Campbell, B., and J. Rosenberg, "A Session		[13] 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.
	[13] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
	for Message Authentication", RFC 2104, February 1997.
	[14] Rosenberg, J., "Extensible Markup Language (XML) Formats for		[14] Rosenberg, J., "Extensible Markup Language (XML) Formats for
	Representing Resource Lists",		Representing Resource Lists", RFC 4826, May 2007.
	draft-ietf-simple-xcap-list-usage-05 (work in progress),
	February 2005.
	[15] Burger, E., "A Mechanism for Content Indirection in Session		[15] Burger, E., Ed., "A Mechanism for Content Indirection in
	Initiation Protocol (SIP) Messages", RFC 4483, May 2006.		Session Initiation Protocol (SIP) Messages", RFC 4483,
			May 2006.
	Author's Address		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
			Jari Urpalainen
			Nokia
			Itamerenkatu 11-13
			Helsinki 00180
			Finland
			Phone: +358 7180 37686
			Email: jari.urpalainen@nokia.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	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
End of changes. 51 change blocks.
	183 lines changed or deleted		341 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/