< draft-ietf-simple-xcap-diff-02.txt		draft-ietf-simple-xcap-diff-03.txt >
	SIMPLE J. Rosenberg		SIMPLE J. Rosenberg
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Expires: April 25, 2006 October 22, 2005		Expires: September 7, 2006 March 6, 2006
	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-02		draft-ietf-simple-xcap-diff-03
	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 34 ¶		skipping to change at page 1, line 34 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on April 25, 2006.		This Internet-Draft will expire on September 7, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	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. XCAP diff documents can be delivered to		former and new entity tags. It also can indicate the specific change
	clients using a number of means, including the Session Initiation		that was made in the document, using an XML patch format. XCAP diff
	Protocol (SIP) event package for configuration data. By subscribing		documents can be delivered to clients using a number of means,
	to this event package, clients can learn about document changes made		including a Session Initiation Protocol (SIP) event package.
	by other clients. The XCAP diff format is extensible, so that
	additional information, such as a description of the actual change,
	can be included.
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 6		5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Usage with the Config Framework . . . . . . . . . . . . . . . 7		6. Usage with an Event Package . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8.1 application/xcap-diff+xml MIME Type . . . . . . . . . . . 8		8.1 application/xcap-diff+xml MIME Type . . . . . . . . . . . 9
	8.2 URN Sub-Namespace Registration for		8.2 URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 9		urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 10
	8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 10		8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 11
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 10		9.1 Normative References . . . . . . . . . . . . . . . . . . . 11
	9.2 Informative References . . . . . . . . . . . . . . . . . . 11		9.2 Informative References . . . . . . . . . . . . . . . . . . 12
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12		Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . 14
	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) [8] 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 [12] 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
	skipping to change at page 3, line 28 ¶		skipping to change at page 3, line 28 ¶
	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 the Session Initiation		To deal with this problem, clients can use a Session Initiation
	Protocol (SIP) [10] event package [11] for subscribing to changes in		Protocol (SIP) [10] event package [11] to subscribe to change events
	configuration and profile information [9], including application data		in XCAP documents. This notification needs to indicate the specific
	that resides on an XCAP server. With that package, a user gets		resource that changed, and how it changed. One solution for the
	notified that a particular document has changed. This notification		format of such a change notification would be a content indirection
	can include the full content of the new document, or it can be a		object [15]. Though content indirection can tell a client that a
	content indirection [15]. 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.		would only be able to indicate that it did change.
	In addition, when an XCAP client inserts a new element or attribute
	into an existing document, the client has no way to know whether the
	insertion was done against its cached version of the document. The
	reasons for this are described in Section 7.10 of XCAP. To help a
	client ascertain whether this has occurred after performing the
	insertion, the XCAP response needs to contain a document which
	indicates the entity tags before and after the document was modified.
	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 has changed. This data		can convey the fact that an XML document managed by XCAP has changed.
	format is an XML document format, called an XCAP diff document. This		This data format is an XML document format, called an XCAP diff
	format can indicate that a document has changed, and provide its		document. This format can indicate that a document has changed, and
	previous and new entity tags. This specification also explains how		provide its previous and new entity tags. It can also optionally
	this format is used in conjunction with the configuration profile		include a set of patch operations [9], which indicate how to
	framework.		transform the document from the version prior to the change, to the
			version after it.
	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 [7] 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:
	skipping to change at page 4, line 30 ¶		skipping to change at page 4, line 25 ¶
	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.
	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) that acts as		Client: Typically an XCAP client and SIP User Agent (UA), the client
	a subscriber to the configuration event package, this is a		consumes XCAP diff documents in order to reconstruct the document
	protocol entity that consumes XCAP diff documents in order to		stored on the server.
	reconstruct the document 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 [3], using the namespace identifier 'ietf'
	defined by [5] and extended by [6]. This URN is:		defined by [5] and extended by [6]. This URN is:
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 30 ¶
	The optional "hash" attribute provides an HMAC of the document		The optional "hash" attribute provides an HMAC of the document
	instance whose etag is "new-etag", once that document is represented		instance whose etag is "new-etag", once that document is represented
	in canonical form. To compute this value, the server MUST apply the		in canonical form. To compute this value, the server MUST apply the
	mandatory XML canonicalization defined in the Canonical XML 1.0 [1]		mandatory XML canonicalization defined in the Canonical XML 1.0 [1]
	specification, and then computes an HMAC [13] using SHA1 over this		specification, and then computes an HMAC [13] using SHA1 over this
	canonical document, with a key whose value is 0x2238a. The result is		canonical document, with a key whose value is 0x2238a. The result is
	the value of the "hash" attribute. This attribute is optional, and a		the value of the "hash" attribute. This attribute is optional, and a
	server MAY elect not to include it. Even if present, a client MAY		server MAY elect not to include it. Even if present, a client MAY
	elect to ignore it.		elect to ignore it.
	This contents of the <document> element are extensible, and can		Each <document> element contains zero or one <change-log> element,
	include elements from other namespaces. It is anticipated that		followed by any number of elements from another namespace for the
	extensions would be defined that allow the actual change in the		purposes of extensibility. Any such unknown elements MUST be ignored
	document to be reported.		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
			only requirement is that, if the server includes the <change-log>
			element, 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". If the <change-log> element is
			not present, it means that the document has changed in some way, but
			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
			etag doesn't match the value of "new-etag".
			It is important to note that a <document> element with no <change-
			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
			of which can be <add>, <replace> and <remove> elements. These
			elements use the corresponding add, replace and remove types defined
			in [9], and define a set of patch operations that can be applied to
			transform the document. See [9] for instructions on how this
			transformation is effected. The <change-log> element can also
			contain elements from other namespaces for the purposes of
			extensibility. Any unknown elements MUST be ignored.
	4. XML Schema		4. XML Schema
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-diff"		<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
	xmlns="urn:ietf:params:xml:ns:xcap-diff"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
			xmlns="urn:ietf:params:xml:ns:xcap-diff"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
			<xs:include schemaLocation="patch-ops.xsd"/>
	<xs:element name="document">		<xs:element name="document">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
			<xs:element name="change-log" type="change-logType" minOccurs="0"/>
	<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>		<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="doc-selector" type="xs:anyURI" use="required"/>		<xs:attribute name="doc-selector" 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:attribute name="hash" type="xs:string" use="optional"/>		<xs:attribute name="hash" type="xs:string" use="optional"/>
	<xs:anyAttribute namespace="##other" processContents="lax"/>		<xs:anyAttribute namespace="##other" processContents="lax"/>
	</xs:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
	<xs:element name="xcap-diff">		<xs:element name="xcap-diff">
	<xs:complexType>		<xs:complexType>
	<xs:sequence>		<xs:sequence>
	<xs:element ref="document"/>		<xs:element ref="document"/>
	</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:complexType>		</xs:complexType>
	</xs:element>		</xs:element>
			<xs:complexType name="change-logType">
			<xs:sequence minOccurs="0" maxOccurs="unbounded">
			<xs:choice>
			<xs:element name="add" type="add"/>
			<xs:element name="remove" type="remove"/>
			<xs:element name="replace" type="replace"/>
			<xs:any namespace="##other"/>
			</xs:choice>
			</xs:sequence>
			</xs:complexType>
	</xs:schema>		</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"		<document new-etag="7ahggs"
	doc-selector="resource-lists/users/joe/coworkers"		doc-selector="resource-lists/users/joe/coworkers"
	previous-etag="8a77f8d"/>		previous-etag="8a77f8d"/>
	</xcap-diff>		</xcap-diff>
	This indicates that the document with URI		This indicates that the document with URI
	http://xcap.example.com/root/resource-lists/users/joe/coworkers has		"http://xcap.example.com/root/resource-lists/users/joe/coworkers" has
	changed. Its previous entity tag is 8a77f8d and its new one is		changed. Its previous entity tag is 8a77f8d and its new one is
	7ahggs.		7ahggs.
	6. Usage with the Config Framework		6. Usage with an Event Package
	The framework for user agent profile delivery [9] defines an event		The XCAP diff format was meant to be used with an event package for
	package which can be used to subscribe to user, device, application		the purposes of indicating changes in a document. This section
	or local-network data that defines the configuration of a client.		provides guidelines for its usage with any event package defined for
	This data can be present in an XCAP server. Normally, content		that purpose.
	indirection [15] will be used as the NOTIFY body format, to indicate
	the specific document that has changed, and should be re-fetched.
	However, if the client includes an Accept header field including the
	MIME type "application/xcap-diff+xml", the server has the option of
	returning documents in this format instead.
	When the client performs an initial subscription, the rules in [9]		Upon receipt of an initial SUBSCRIBE request, the client may have a
	are used to select the set of documents which the subscription		cached version of some documents. However, the server does not know
	applies to. Upon initial subscription, the server does not know
	which instances of each document (where each instance is identified		which instances of each document (where each instance is identified
	by an etag) the client currently posessses, if any. Indeed, upon		by an etag) the client currently posessses, if any. Indeed, upon
	startup, the client will not have any documents. The initial NOTIFY		initial startup, the client will not have any documents. The initial
	in this case MUST include a <document> element for each document		NOTIFY in this case MUST include a <document> element for each
	associated with the subscription. The "previous-etag" attribute MUST		document associated with the subscription. The "previous-etag"
	be absent, and the "new-etag" attribute MUST be present and contain		attribute MUST be absent, and the "new-etag" attribute MUST be
	the entity tag for the current version of that document resource. An		present and contain the entity tag for the current version of that
	XCAP diff document structured this way is called a "reference" XCAP		document resource. An XCAP diff document structured this way is
	diff document. It establishes the baseline etags and document URIs		called a "reference" XCAP diff document. It establishes the baseline
	for the documents covered by the subscription.		etags and document URIs for the documents covered by the
			subscription.
	Upon receipt of this document, the client can determine whether its		Upon receipt of this document, the client can determine whether its
	local instance documents, if any, match the etags in the XCAP diff		local instance documents, if any, match the etags in the XCAP diff
	document. If they do not match, the client SHOULD perform a		document. If they do not match, the client SHOULD perform a
	conditional GET for each document. The document URI is constructed		conditional GET for each document. The document URI is constructed
	by appending the XCAP root in the "xcap-root" attribute of the <xcap-		by appending the XCAP root in the "xcap-root" attribute of the <xcap-
	diff> element to the escape coded "doc-selector" from each <document>		diff> element to the escape coded "doc-selector" from each <document>
	element. The request is made conditional by including an If-Match		element. The request is made conditional by including an If-Match
	header field, with the value of the etag from each <document>		header field, with the value of the etag from each <document>
	element. So long as the documents haven't changed between the NOTIFY		element. So long as the documents haven't changed between the NOTIFY
	and the GET, the client will obtain the reference versions that the		and the GET, the client will obtain the reference versions that the
	server will use for subsequent notifications.		server will use for subsequent notifications.
	If the conditional GET should fail, the client SHOULD generate a		If the conditional GET should fail, the client SHOULD generate a
	SUBSCRIBE refresh request to trigger a new NOTIFY. The server will		SUBSCRIBE refresh request to trigger a new NOTIFY. The server will
	always generate a "reference" XML diff document on receipt of a		always generate a "reference" XML diff document on receipt of a
	SUBSCRIBE refresh. This establishes a new set of baseline etags, and		SUBSCRIBE refresh. This establishes a new set of baseline etags, and
	the client can then attempt to do another fetch. It is anticipated		the client can then attempt to do another fetch. [[ISSUE: this is
	that future extensions to the profile delivery framework will allow a		really awful; we should include a parameter in the subscription which
	client to include, in its SUBSCRIBE request, an indicator of the		allows the client to indicate which version it has. That would
	current version of the documents it holds. That would obviate the		obviate the need for a potentially never-ending stream of SUBSCRIBE/
	need for a potentially never-ending stream of SUBSCRIBE/GET sequences		GET sequences should the documents be rapidly changing, for some
	should the documents be rapidly changing, for some reason.		reason.]]
	Once the client has obtained the versions of the documents identified		Once the client has obtained the versions of the documents identified
	in the reference XML diff, it can process NOTIFY requests on that		in the reference XML diff, it can process NOTIFY requests on that
	subscription. To process the NOTIFY requests, it makes sure that its		subscription. To process the NOTIFY requests, it makes sure that its
	current version matches the version in the "previous-etag" attribute		current version matches the version in the "previous-etag" attribute
	of the <document> element. If not, the client can then fetch the		of the <document> element. If not, the client can then fetch the
	updated document from the server. If they do match, the client has		updated document from the server. If they do match, the client has
	the most current version.		the most current version.
	7. Security Considerations		7. Security Considerations
	XCAP diff documents are not very sensitive; they only contain entity		XCAP diff documents can include changes from one document to another.
	tags and the URI for documents. An attacker that is able to examine		As a consequence, if the document itself is sensitive and requires
	such a document cannot access or modify the referenced document		confidentiality, integrity or authentication, than the same applies
	unless it has also managed to attack XCAP itself. Thus, there is no		to the XCAP diff format. Therefore, protocols which transport XCAP
	requirement for message confidentiality. However, an attacker that		diff documents must provide sufficient security capabilities for
	can modify XCAP diff documents in transit could fool a client into		transporting the document itself.
	thinking that a document hasn't changed, when it has, or vice-a-
	versa. Therefore, protocols which transport XCAP Diff documents
	SHOULD provide message integrity.
	8. IANA Considerations		8. IANA Considerations
	There are several IANA considerations associated with this		There are several IANA considerations associated with this
	specification.		specification.
	8.1 application/xcap-diff+xml MIME Type		8.1 application/xcap-diff+xml MIME Type
	MIME media type name: application		MIME media type name: application
	skipping to change at page 11, line 16 ¶		skipping to change at page 12, line 16 ¶
	[5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,		[5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
	August 1999.		August 1999.
	[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[7] 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)		[8] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-07		Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-08
	(work in progress), June 2005.		(work in progress), October 2005.
	[9] Petrie, D., "A Framework for Session Initiation Protocol User		[9] Urpalainen, J., "An Extensible Markup Language (XML) Patch
	Agent Profile Delivery", draft-ietf-sipping-config-framework-07		Operations Framework Utilizing XML Path Language (XPath)
	(work in progress), July 2005.		Selectors", draft-ietf-simple-xml-patch-ops-01 (work in
			progress), January 2006.
	9.2 Informative References		9.2 Informative References
	[10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[10] 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		[11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
	Notification", RFC 3265, June 2002.		Notification", RFC 3265, June 2002.
	skipping to change at page 13, line 41 ¶		skipping to change at page 14, 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 (2005). This document is subject		Copyright (C) The Internet Society (2006). 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. 26 change blocks.
	104 lines changed or deleted		135 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/