SIMPLE WG J. Urpalainen
Internet-Draft Nokia
Intended status: Standards Track August 9, 2007
Expires: February 10, 2008
An Extensible Markup Language (XML) Patch Operations Framework Utilizing
XML Path Language (XPath) Selectors
draft-ietf-simple-xml-patch-ops-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Extensible Markup Language (XML) documents are widely used as
containers for the exchange and storage of arbitrary data in today's
systems. In order to send changes to an XML document, an entire copy
of the new version must be sent, unless there is a means of
indicating only the portions that have changed. This document
describes an XML patch framework utilizing XML Path language (XPath)
selectors. These selector values and updated new data content
Urpalainen Expires February 10, 2008 [Page 1]
Internet-Draft Patch Operations August 2007
constitute the basis of patch operations described in this document.
In addition to them, with basic <add>, <replace> and <remove>
directives a set of patches can then be applied to update an existing
XML document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Features and Requirements . . . . . . . . . . . . . . . 5
4. Patch Operations . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Locating the Target of a Patch . . . . . . . . . . . . . . 7
4.2. Namespace Mangling . . . . . . . . . . . . . . . . . . . . 7
4.3. <add> Element . . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. Adding an Element . . . . . . . . . . . . . . . . . . 10
4.3.2. Adding an Attribute . . . . . . . . . . . . . . . . . 10
4.3.3. Adding a Prefixed Namespace Declaration . . . . . . . 11
4.3.4. Adding Node(s) with the 'pos' Attribute . . . . . . . 11
4.3.5. Adding Multiple Nodes . . . . . . . . . . . . . . . . 11
4.4. <replace> Element . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Replacing an Element . . . . . . . . . . . . . . . . . 12
4.4.2. Replacing an Attribute Value . . . . . . . . . . . . . 13
4.4.3. Replacing a Namespace Declaration URI . . . . . . . . 13
4.4.4. Replacing a Comment Node . . . . . . . . . . . . . . . 13
4.4.5. Replacing a Processing Instruction Node . . . . . . . 13
4.4.6. Replacing a Text Node . . . . . . . . . . . . . . . . 13
4.5. <remove> Element . . . . . . . . . . . . . . . . . . . . . 14
4.5.1. Removing an Element . . . . . . . . . . . . . . . . . 14
4.5.2. Removing an Attribute . . . . . . . . . . . . . . . . 14
4.5.3. Removing a Prefixed Namespace Declaration . . . . . . 15
4.5.4. Removing a Comment Node . . . . . . . . . . . . . . . 15
4.5.5. Removing a Processing Instruction Node . . . . . . . . 15
4.5.6. Removing a Text Node . . . . . . . . . . . . . . . . . 15
5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Usage of Patch Operations . . . . . . . . . . . . . . . . . . 16
7. Usage of Selector Values . . . . . . . . . . . . . . . . . . . 16
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. XML Schema Registration . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 20
A.1. Adding an Element . . . . . . . . . . . . . . . . . . . . 20
A.2. Adding an Attribute . . . . . . . . . . . . . . . . . . . 21
Urpalainen Expires February 10, 2008 [Page 2]
Internet-Draft Patch Operations August 2007
A.3. Adding a Prefixed Namespace Declaration . . . . . . . . . 21
A.4. Adding a Comment Node with the 'pos' Attribute . . . . . . 22
A.5. Adding Multiple Nodes . . . . . . . . . . . . . . . . . . 22
A.6. Replacing an Element . . . . . . . . . . . . . . . . . . . 23
A.7. Replacing an Attribute Value . . . . . . . . . . . . . . . 24
A.8. Replacing a Namespace Declaration URI . . . . . . . . . . 24
A.9. Replacing a Comment Node . . . . . . . . . . . . . . . . . 25
A.10. Replacing a Processing Instruction Node . . . . . . . . . 25
A.11. Replacing a Text Node . . . . . . . . . . . . . . . . . . 26
A.12. Removing an Element . . . . . . . . . . . . . . . . . . . 26
A.13. Removing an Attribute . . . . . . . . . . . . . . . . . . 27
A.14. Removing a Prefixed Namespace Declaration . . . . . . . . 28
A.15. Removing a Comment Node . . . . . . . . . . . . . . . . . 28
A.16. Removing a Processing Instruction Node . . . . . . . . . . 29
A.17. Removing a Text Node . . . . . . . . . . . . . . . . . . . 29
A.18. Several Patches With Namespace Mangling . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . . . 33
Urpalainen Expires February 10, 2008 [Page 3]
Internet-Draft Patch Operations August 2007
1. Introduction
Extensible Markup Language (XML) [2] documents are widely used as
containers for the exchange and storage of arbitrary data in today's
systems. In order to send changes to an XML document, an entire copy
of the new version must be sent, unless there is a means of
indicating only the portions that have changed (patches).
This document describes an XML patch framework which utilizes XML
Path language (XPath) [3] selectors. An XPath selector is used to
pinpoint the specific portion of the XML that is the target for the
change. These selector values and updated new data content
constitute the basis of patch operations described in this document.
In addition to them, with basic <add>, <replace> and <remove>
directives a set of patches can be applied to update an existing
initial XML document. With these patch operations, a simple
semantics for data oriented XML documents [7] is achieved, that is,
modifications like additions, removals or substitutions of elements
and attributes can easily be performed. This document does not
describe a full XML diff format, only basic patch operation elements
which can be embedded within a full format which typically has
additional semantics.
As a one concrete example, in the Session Initiation Protocol (SIP)
[16] based presence system a partial PIDF XML document format [14]
consists of the existing PIDF document format combined with the patch
operations elements described in this document. In general, patch
operations can be used in any application that exchanges XML
documents, for example within the SIP Events framework [13]. Yet
another example is XCAP-diff [15] which uses this framework for
sending partial updates of changes to XCAP [12] resources.
2. Conventions
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14
[1] and indicate requirement levels for compliant implementations.
The following terms are used in this document:
Initial XML document: An initial XML document that is going to be
updated with a set of patches.
Urpalainen Expires February 10, 2008 [Page 4]
Internet-Draft Patch Operations August 2007
XML diff document: An XML document that contains patch operation
elements, namespace declarations and all the document content
changes that are needed in order to transform an initial XML
document into a new patched XML document.
Patched XML document: An XML document that results after applying
one or more patch operations defined in the XML diff document to
the initial XML document.
Patch operation: A single change, i.e. a patch that is being applied
to update an initial XML document.
Patch operation element: An XML element that represents a single
patch operation.
Type definition for an element: A W3C Schema type definition for an
element that describes a patch operation content.
In-scope namespace declaration: A list of all in-scope namespace
declarations within a context node. The QName expansion of a
context node is based on mapping a prefix with one of these
declarations. For an element, one namespace binding may have an
empty prefix.
Positional constraint: A number enclosed with square brackets. It
can be used as a location step predicate.
Located target node: A node which was found from the initial XML
document with the aid of an XPath selector value.
White space text node: A text node which contains only white space.
3. Basic Features and Requirements
In this framework, XPath selector values and new data content are
embedded within XML elements, the names of which specify the
modification to be performed: <add>, <replace> or <remove>. These
elements (patch operations) are defined by schema types with the W3C
Schema language [5]. XPath selectors pinpoint the target for a
change and they are expressed as attributes of these elements. The
child node(s) of patch operation elements contain the new data
content. In general when applicable, the new content SHOULD be moved
unaltered to the patched XML document.
XML documents which are equivalent for the purposes of many
applications MAY differ in their physical representation. The aim of
this document is to describe a deterministic framework where the
Urpalainen Expires February 10, 2008 [Page 5]
Internet-Draft Patch Operations August 2007
canonical form with comments [6] of an XML document determines
logical equivalence. For example, white space text nodes MUST be
processed properly in order to fulfil this requirement as white space
is by default significant [6].
The specifications referencing these element schema types MUST define
the full XML diff format with an appropriate MIME type [11] and a
character set, e.g. UTF-8 [9]. For example, the partial PIDF format
[14] includes this schema and describes additional definitions to
produce a complete XML diff format for partial presence information
updates.
As the schema defined in this document does not declare any target
namespace, the type definitions inherit the target namespace of the
including schema. Therefore, additional namespace declarations
within the XML diff documents can be avoided.
It is anticipated that applications using these types will define
<add>, <replace> and <remove> elements based on the corresponding
type definitions in this schema. In addition, an application may
reference only a subset of these type definitions. A future
extension can introduce other operations, e.g. with document oriented
models [7] a <move> operation and a text node patching algorithm
combined with <move> would undoubtedly produce smaller XML diff
documents.
The instance document elements based on these schema type definitions
MUST be well formed and SHOULD be valid.
The following XPath 1.0 data model node types can be added, replaced
or removed with this framework: elements, attributes, namespaces,
comments, texts and processing instructions. The full XML prolog
including e.g. XML entities [2] and the root node of an XML document
cannot be patched according to this framework. However, patching of
comments and processing instructions of the root node is allowed.
Naturally the removal or addition of a document root element is not
allowed as any valid XML document MUST always contain a single root
element. Also note that support for external entities is beyond the
scope of this framework.
4. Patch Operations
An XML diff document contains a collection of patch operation
elements, including one or more <add>, <replace> and <remove>
elements. These patch operations will be applied sequentially in the
document order. After the first patch has been applied to update an
initial XML document, the patched XML document becomes a new
Urpalainen Expires February 10, 2008 [Page 6]
Internet-Draft Patch Operations August 2007
independent XML document against which the next patch will be
applied. This procedure repeats until all patches have successfully
been processed.
4.1. Locating the Target of a Patch
Each patch operation element contains a 'sel' attribute. The value
of this attribute is an XPath selector with a restricted subset of
the full XPath 1.0 recommendation. The 'sel' value is used to locate
a single unique target node from the initial XML document. This
located node pinpoints the target for a change and usually it is an
element, which is e.g. either updated itself or some child node(s)
are added into it. It MAY also be for instance a comment node, after
which some other sibling node(s) are inserted. In any case, it is an
error condition if multiple nodes are found during the evaluation of
this selector value.
The XPath selections of the 'sel' attribute always start from the
root node of a document. Thus relative location paths SHOULD be used
so that the starting root node selection "/" can be omitted. When
locating elements in a document tree, a node test can either be a "*"
character or a QName. A "*" character selects all element children
of the context node. Right after the node test, a location step can
contain one or more predicates in any order. An attribute value
comparison is one of the most typical predicates. The string value
of the current context node or a child element may alternatively be
used to identify elements in the tree. The character ".", which
denotes a current context node selection, is an abbreviated form of
"self::node()". Lastly, positional constraints like "[2]" can also
be used as an additional predicate.
An XPath 1.0 "id()" node-set function MAY also be used to identify
unique elements from the document tree. The schema that describes
the content model of the document MUST then use an attribute with the
type ID [7] or with non-validating XML parsers, an "xml:id" [8]
attribute MUST have been used within an instance document.
4.2. Namespace Mangling
While the XPath recommendation specifies that prefixes can be used in
location steps, it does not specify how associated namespace URIs are
discovered during these evaluations. In the patch operation
framework QName [4] expansion within a location step is evaluated
according to the namespace declarations of the XML diff document.
Thus the namespace URIs for these prefixes are found from the in-
scope namespaces of the patch operation element. In other words, the
XML diff document contains all needed information for QName
expansions in order to perform XPath searches from the initial XML
Urpalainen Expires February 10, 2008 [Page 7]
Internet-Draft Patch Operations August 2007
document.
Note: It should be emphasized that prefixes within the XPath
selectors MAY be different than those of the initial XML document
because the matching of nodes is based on expanded names, i.e. a
prefix maps to a namespace URI and these URIs and local names MUST
be identical. For example, with a selector "p:foo", "p" maps to a
namespace URI and "foo" is the local name.
In this framework, when a node test is "foo" and the patch operation
element has an in-scope default namespace declaration, a qualified
<foo> element from the initial XML document is being searched. That
is, the namespace URI of the expanded name of the located <foo>
element MUST then be identical compared to this default namespace
declaration. If there's not an in-scope default namespace
declaration within the evaluation context, an unqualified <foo>
element is located.
Note: By contrast, in XPath 1.0 a "foo" selector always locates an
unqualified <foo> element but in XPath 2.0 [10] also a qualified
one which is attached with the default namespace declaration.
Note: The XPath 1.0 recommendation specifies "namespace-uri()" and
"local-name()" node-set functions which can be used within
predicates. These functions may be utilized during XPath
evaluations if there are no other means to "register" prefixes
with associated namespace URIs. They can also be used when
handling selections where default namespaces are attached to
elements. However, the schema type definitions for these patch
operation elements do not allow the usage of these functions.
Also elements within the changed data content are usually namespace
qualified. For example, when adding a new namespace qualified
element to the initial XML document, the namespace declaration
reference of this new element belongs first to the XML diff document.
Naturally after copying or moving this element, the attached
namespace MUST refer to a declaration within the patched XML
document. If this namespace is declared in the patch operation
element or within its ascendants, these references MUST thus be
changed. Like in XPath, the mapping of these references is based on
identical namespace URIs, not prefixes. The namespace with an
identical URI from the in-scope namespaces of a context node of the
initial XML document MUST be chosen. However, if overlapping in-
scope namespaces exist, i.e., there are several in-scope namespaces
with an identical namespace URI, then the namespace with the same
prefix MUST be chosen. If an equivalent prefix is not then found, an
error occurs. For instance, this kind of overlapping can happen when
a namespace qualified attribute is added while elements are attached
Urpalainen Expires February 10, 2008 [Page 8]
Internet-Draft Patch Operations August 2007
with an identical default namespace declaration.
When the new added or updated elements contain namespace
declarations, the namespace nodes move unaltered from the XML diff
document to the patched XML document. Default namespace declarations
can only be added by this way but prefixed namespace declarations MAY
be added or removed with XPath namespace axis semantics shown later
in this document.
Note: In practice, this namespace mangling means that an XML diff
document MUST only know the namespace URIs of qualified nodes, the
prefixes of the initial XML document are not significant unless
there are those overlapping namespace declarations. In other
words, regardless whether the prefixes of qualified elements of
the initial XML document are empty (default namespace attached) or
not, the XML diff document may remain the same.
4.3. <add> Element
The <add> element represents the addition of some new content to the
initial XML document: e.g. a new element can be appended into an
existing element.
The new data content exists as the child node(s) of the <add>
element. When adding attributes and namespaces the child node of the
<add> element MUST be a single text node. Otherwise, the <add>
element MAY contain any mixture of element, text, comment or
processing instruction nodes in any order. All children of the <add>
element are then copied into an initial XML document. The described
namespace mangling procedure applies to added elements, which include
all of their attribute, namespace and descendant nodes.
The <add> element type has three attributes: 'sel', 'type' and 'pos'.
The value of the optional 'type' attribute is only used when adding
attributes and namespaces. Then the located target node MUST be an
element into which new attributes and namespace declarations are
inserted. When the value of this 'type' attribute equals "@attr" the
purpose is to add a new attribute node with the name 'attr'. The
value of this new 'attr' attribute is the text node content of the
<add> element. The less frequently used, prefixed, i.e. namespace
qualified attributes can also be added. If the value of the 'type'
attribute equals "namespace::pref" the aim is to add a new "pref"
prefixed namespace declaration and the text node content of the <add>
element contains the corresponding namespace URI.
Urpalainen Expires February 10, 2008 [Page 9]
Internet-Draft Patch Operations August 2007
Note: The 'type' attribute is thus also an XPath selector, but it
only locates attributes and namespaces. Attribute axis
"attribute" has an abbreviated form "@" unlike the "namespace"
axis which doesn't have an abbreviated form. Double colons "::"
are used as an axis separator in XPath.
The value of the optional 'pos' attribute indicates the positioning
of new data content. It is not used when adding attributes or
namespaces. When neither 'type' nor 'pos' attribute exist, the
children of the <add> element are then appended as the last child
node(s) of the located target element. When the value of 'pos'
attribute is "prepend" the new node(s) are added as the first child
node(s) of the located target element. With the value of "before"
the added new node(s) MUST be the immediate preceding sibling node(s)
and with "after" the immediate following sibling node(s) of the
located target node.
Some examples follow which describe the use cases of these <add>
element attributes. The nodes are not namespace qualified and
prefixes are therefore not used and the whole XML diff content is not
shown in these examples, only patch operation elements. Full
examples are given in an Appendix A.
4.3.1. Adding an Element
An example for an addition of an element:
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
Once the <doc> element has been found from the initial XML document,
a new <foo> element is appended as the last child node of the <doc>
element. The located target node: the <doc> element is naturally the
root element of the initial XML document. The new <foo> element
contains an 'id' attribute and a child text node.
4.3.2. Adding an Attribute
An example for an addition of an attribute:
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
This operation adds a new 'user' attribute to the <foo> element which
was located by using an 'id' attribute value predicate. The value of
this new 'user' attribute is "Bob".
A similar patched XML document is achieved when using a validating
XML parser, if the 'sel' selector value had been 'id("ert4773")' and
if the data type of the 'id' attribute is "ID" [7].
Urpalainen Expires February 10, 2008 [Page 10]
Internet-Draft Patch Operations August 2007
Note: As the 'sel' selector value MAY contain quotation marks,
escaped forms: """ or "'" can be used within attribute
values. However, it is often more appropriate to use the
apostrophe (') character as shown in these examples. An
alternative is also to interchange the apostrophes and quotation
marks.
4.3.3. Adding a Prefixed Namespace Declaration
An example for an addition of a prefixed namespace declaration:
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
This operation adds a new namespace declaration to the <doc> element.
The prefix of this new namespace node is thus "pref" and the
namespace URI is "urn:ns:xxx".
4.3.4. Adding Node(s) with the 'pos' Attribute
An example for an addition of a comment node:
<add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
This operation adds a new comment node just before the <foo> element
as an immediate preceding sibling node. This is also an example how
a 'pos' attribute directive can be used.
4.3.5. Adding Multiple Nodes
Some complexity arises when so called white space text nodes exist
within an initial XML document. The XPath 1.0 data model requires
that a text node MUST not have another text node as an immediate
sibling node. For instance, if an add operation is like this:
<add sel="doc">
<foo id="ert4773">This is a new child</foo></add>
The <add> element has then two child nodes: a white space text node
(a linefeed and two spaces) and a <foo> element. If the existing
last child of the <doc> element is a text node, its content and the
white space text node content MUST then be combined together.
Otherwise (white space) text nodes can be added just like elements
and thus, the canonical form of the patched XML document easily
remains deterministic. As several sibling nodes can be inserted with
a single <add> operation, a "pretty printing" style can easily be
maintained.
Still another example about the handling of text nodes. Consider
Urpalainen Expires February 10, 2008 [Page 11]
Internet-Draft Patch Operations August 2007
this example:
<add sel="*/foo/text()[2]" pos="after">new<bar/>elem</add>
The second text node child of the <foo> element is first located.
The added new content contains two text nodes and an element. As
there can not be immediate sibling text nodes, the located target
text node content and the first new text node content MUST be
combined together. In essence, if the 'pos' value had been "before",
the second new text node content would effectively have been
prepended to the located target text node.
Note: It is still worth noting that text nodes MAY contain CDATA
sections, the latter of which are not treated as separate nodes.
Once these CDATA sections exist within the new text nodes, they
SHOULD be moved unaltered to the patched XML document.
While XML entities [2] cannot be patched with this framework, the
references to other than predefined internal entities can exist
within text nodes or attributes when the XML prolog contains those
declarations. These references may then be preserved if both the XML
diff and the initial XML document have identical declarations within
their prologs. Otherwise, references may be replaced with identical
text as long as the "canonically equivalent" rule is obeyed.
4.4. <replace> Element
The <replace> element represents a replacement operation: e.g. an
existing element is updated with a new element or an attribute value
is replaced with a new value. This <replace> operation always
updates a single node or node content at a time.
The <replace> element type has only a 'sel' attribute. If the
located target node is an element, a comment or a processing
instruction, then the child of the <replace> element MUST also be of
the same type. Otherwise the <replace> element MUST have text
content or it MAY be empty when replacing an attribute value or a
text node content.
4.4.1. Replacing an Element
An example for a replacement of an element:
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
This will update the <foo> element which has an 'a' attribute with
value "1". The located target element is replaced with the <bar>
element. So all descendant nodes, namespace declarations and
Urpalainen Expires February 10, 2008 [Page 12]
Internet-Draft Patch Operations August 2007
attributes of the replaced <foo> element, if any existed, are thus
removed.
4.4.2. Replacing an Attribute Value
An example for a replacement of an attribute value:
<replace sel="doc/@a">new value</replace>
This will replace the 'a' attribute content of the <doc> element with
the value "new value". If the <replace> element is empty, the 'a'
attribute MUST then remain in the patched XML document appearing like
<doc a=""/>.
4.4.3. Replacing a Namespace Declaration URI
An example for a replacement of a namespace URI:
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
This will replace the URI value of 'pref' prefixed namespace node
with "urn:new:xxx". The parent node of the namespace declaration
MUST be the <doc> element, otherwise an error occurs.
4.4.4. Replacing a Comment Node
An example for a replacement of a comment node:
<replace sel="doc/comment()[1]"><!-- This is the new content
--></replace>
This will replace a comment node. The located target node is the
first comment node child of the <doc> element.
4.4.5. Replacing a Processing Instruction Node
An example for a replacement of a processing instruction node:
<replace sel='doc/processing-instruction("test")'><?test bar="foobar"
?></replace>
This will replace the processing instruction node "test" whose parent
is the <doc> element.
4.4.6. Replacing a Text Node
An example for a replacement of a text node:
Urpalainen Expires February 10, 2008 [Page 13]
Internet-Draft Patch Operations August 2007
<replace sel="doc/foo/text()[1]">This is the new text content</
replace>
This will replace the first text node child of the <foo> element.
The positional constraint "[1]" is not usually needed as the element
content is rarely of mixed type [5] where several text node siblings
typically exist.
If a text node is updated and the <replace> element is empty, the
text node MUST thus be removed as a text node MUST always have at
least one character of data.
4.5. <remove> Element
The <remove> element represents a removal operation of e.g. an
existing element or an attribute.
The <remove> element type has two attributes: 'sel' and 'ws'. The
value of the optional 'ws' attribute is used to remove the possible
white space text nodes that exist either as immediate following or
preceding sibling nodes of the located target node. The usage of
'ws' attribute is only allowed when removing other types than text,
attribute and namespace nodes. If the value of 'ws' is "before", the
purpose is to remove the immediate preceding sibling node which MUST
be a white space text node and if the value is "after", the
corresponding following node. If the 'ws' value is "both", both the
preceding and following white space text nodes MUST be removed.
4.5.1. Removing an Element
An example for a removal of an element including all of its
descendant, attribute and namespace nodes:
<remove sel="doc/foo[@a='1']" ws="after"/>
This will remove the <foo> element as well as the immediate following
sibling white space text node of the <foo> element. If the immediate
following sibling node is not a white space text node, an error
occurs.
4.5.2. Removing an Attribute
An example for a removal of an attribute node:
<remove sel="doc/@a"/>
This will remove the 'a' attribute node from the <doc> element.
Urpalainen Expires February 10, 2008 [Page 14]
Internet-Draft Patch Operations August 2007
4.5.3. Removing a Prefixed Namespace Declaration
An example for a removal of a prefixed namespace node:
<remove sel="doc/foo/namespace::pref"/>
This will remove the 'pref' prefixed namespace node from the <foo>
element. Naturally this prefix MUST not be associated with any node
prior to the removal of this namespace node. Also the parent node of
this namespace declaration MUST be the <foo> element.
4.5.4. Removing a Comment Node
An example for a removal of a comment node:
<remove sel="doc/comment()[1]"/>
This will remove the first comment node child of the <doc> element.
4.5.5. Removing a Processing Instruction Node
An example for a removal of a processing instruction node:
<remove sel='doc/processing-instruction("test")'/>
This will remove the "test" processing instruction node child of the
<doc> element.
4.5.6. Removing a Text Node
An example for a removal of a text node:
<remove sel="doc/foo/text()[1]"/>
This will remove the first text node child of the <foo> element.
When removing an element, a comment or a processing instruction node
which has immediate preceding and following sibling text nodes
without the 'ws' directive, the content of these two text nodes MUST
be combined together. The latter text node thus disappears from the
document.
5. Error Handling
It is an error condition if any of the patch operations can not be
unambiguously fulfilled. In other words, once a particular patch
operation fails, it is an error condition and processing of further
Urpalainen Expires February 10, 2008 [Page 15]
Internet-Draft Patch Operations August 2007
patch operations is hardly sensible. Also it is beyond the scope of
this document to describe a generic error response.
6. Usage of Patch Operations
An XML diff document SHOULD contain only the nodes which have been
modified. However, when there's a large collection of changes it
could be desirable to exchange the full document content instead.
How this will be done in practice is beyond the scope of this
document.
7. Usage of Selector Values
It is up to the application to decide what kind of selector values to
use. Positional element selectors like "*/*[3]/*[2]" provide the
shortest selectors, but care must to taken when using them. When
there are several removals of sibling elements, the positional
element indexes change after each update. Likewise these indexes
change when new elements are inserted into the tree. Using names
with possible attribute predicates like "doc[@sel='foo']" is usually
easier for an application, be it e.g. an auto diff tool but it leads
to larger diff documents.
8. XML Schema
The schema types for the patch operation elements.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE schema [
<!ENTITY ncname "\i\c*">
<!ENTITY qname "(&ncname;:)?&ncname;">
<!ENTITY aname "@&qname;">
<!ENTITY pos "\[\d+\]">
<!ENTITY attr "\[&aname;='(.)*'\]|\[&aname;="(.)*"\]">
<!ENTITY valueq "\[(&qname;|\.)="(.)*"\]">
<!ENTITY value "\[(&qname;|\.)='(.)*'\]|&valueq;">
<!ENTITY cond "&attr;|&value;|&pos;">
<!ENTITY step "(&qname;|\*)(&cond;)*">
<!ENTITY piq "processing-instruction\(("&ncname;")?\)">
<!ENTITY pi "processing-instruction\(('&ncname;')?\)|&piq;">
<!ENTITY id "id\(('&ncname;')?\)|id\(("&ncname;")?\)">
<!ENTITY com "comment\(\)">
<!ENTITY text "text\(\)">
<!ENTITY nspa "namespace::&ncname;">
<!ENTITY cnodes "(&text;(&pos;)?)|(&com;(&pos;)?)|(π(&pos;)?)">
Urpalainen Expires February 10, 2008 [Page 16]
Internet-Draft Patch Operations August 2007
<!ENTITY child "&cnodes;|&step;">
<!ENTITY last "&child;|&aname;|&nspa;">
]>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xsd:simpleType name="xpath">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(/)?(&step;/)*(&last;)"/>
<xsd:pattern value="(/)?&id;((/&step;)*(/&last;))?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="xpath-add">
<xsd:restriction base="xsd:string">
<xsd:pattern value="(/)?(&step;/)*(&child;)"/>
<xsd:pattern value="(/)?&id;((/&step;)*(/&child;))?"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="pos">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
<xsd:enumeration value="prepend"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="type">
<xsd:restriction base="xsd:string">
<xsd:pattern value="&aname;"/>
<xsd:pattern value="&nspa;"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="add">
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="sel" type="xpath-add"
use="required"/>
<xsd:attribute name="pos" type="pos"/>
<xsd:attribute name="type" type="type"/>
Urpalainen Expires February 10, 2008 [Page 17]
Internet-Draft Patch Operations August 2007
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="replace">
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="sel" type="xpath" use="required"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:simpleType name="ws">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="before"/>
<xsd:enumeration value="after"/>
<xsd:enumeration value="both"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="remove">
<xsd:attribute name="sel" type="xpath" use="required"/>
<xsd:attribute name="ws" type="ws"/>
</xsd:complexType>
</xsd:schema>
9. IANA Considerations
9.1. XML Schema Registration
This section registers a new XML Schema.
URI:
urn:ietf:params:xml:schema:xml-patch-ops
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
Urpalainen Expires February 10, 2008 [Page 18]
Internet-Draft Patch Operations August 2007
10. Security Considerations
Information exchanged within these patch operations can be highly
sensitive. Thus systems need to protect the integrity and
confidentiality of this data. Especially, the transport protocol
once it is used SHOULD have capabilities to protect from possible
threats. For example, a malicious man-in-the-middle attack could
easily give misinformation. However, all the security considerations
depend very much on the application which utilizes this framework.
11. Acknowledgments
The author would like to thank Eva Leppanen, Mikko Lonnfors, Aki
Niemi, Jonathan Rosenberg, Miguel A. Garcia, Anat Angel, Stephane
Bortzmeyer and Dave Crocker for their valuable comments and Ted
Hardie for his input and support.
12. References
12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C
Recommendation REC-xml-20060816 , August 2006.
[3] "XML Path Language (XPath) Version 1.0", W3C Recommendation
REC-xpath-19991116 , November 1999.
[4] "Namespaces in XML (Second Edition)", W3C Recommendation REC-
xml-names-20060816 , August 2006.
[5] "XML Schema Part 1: Structures Second Edition", W3C
Recommendation REC-xmlschema-1-20041028 , October 2004.
[6] "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,
March 2001.
[7] "XML Schema Part 2: Datatypes Second Edition", W3C
Recommendation PER-xmlschema-2-20040318 , October 2004.
[8] "xml:id Version 1.0 W3C Recommendation 9 September 2005", W3C
Recommendation PR-xml-id-20050712 , September 2005.
[9] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
Urpalainen Expires February 10, 2008 [Page 19]
Internet-Draft Patch Operations August 2007
RFC 2279, January 1998.
12.2. Informative References
[10] "XML Path Language (XPath) Version 2.0", W3C Recommendation
23 , January 2007.
[11] Murata, M., "XML media types", RFC 3023, January 2001.
[12] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[14] Lonnfors, M., Leppanen, E., Khartabil, H., and J. Urpalainen,
"Presence Information Data format (PIDF) Extension for Partial
Presence", draft-ietf-simple-partial-pidf-format-08 (work in
progress), November 2006.
[15] Rosenberg, J., "An Extensible Markup Language (XML) Document
Format For Indicating Changes in XML Configuration Access
Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-05,
March 2007.
[16] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
Appendix A. Informative Examples
All following examples assume an imaginary XML diff document
including these patch operation elements.
A.1. Adding an Element
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
An XML diff document:
Urpalainen Expires February 10, 2008 [Page 20]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc"><foo id="ert4773">This is a new child</foo></add>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
A.2. Adding an Attribute
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc/foo[@id='ert4773']" type="@user">Bob</add>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773" user="Bob">This is a new child</foo></doc>
A.3. Adding a Prefixed Namespace Declaration
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
Urpalainen Expires February 10, 2008 [Page 21]
Internet-Draft Patch Operations August 2007
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc" type="namespace::pref">urn:ns:xxx</add>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:ns:xxx">
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
A.4. Adding a Comment Node with the 'pos' Attribute
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc/foo[@id='ert4773']" pos="before"><!-- comment --></add>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<!-- comment --><foo id="ert4773">This is a new child</foo></doc>
A.5. Adding Multiple Nodes
An example initial XML document:
Urpalainen Expires February 10, 2008 [Page 22]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<add sel="doc">
<foo id="ert4773">This is a new child</foo></add>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
<foo id="ert4773">This is a new child</foo></doc>
A.6. Replacing an Element
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/foo[@a='1']"><bar a="2"/></replace>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<bar a="2"/>
</doc>
Urpalainen Expires February 10, 2008 [Page 23]
Internet-Draft Patch Operations August 2007
A.7. Replacing an Attribute Value
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc a="test">
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/@a">new value</replace>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc a="new value">
<foo a="1">This is a sample document</foo>
</doc>
A.8. Replacing a Namespace Declaration URI
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/namespace::pref">urn:new:xxx</replace>
</diff>
A result XML document:
Urpalainen Expires February 10, 2008 [Page 24]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:new:xxx">
<foo a="1">This is a sample document</foo>
</doc>
A.9. Replacing a Comment Node
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/comment()[1]"><!-- This is the new content
--></replace>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns:pref="urn:test">
<foo a="1">This is a sample document</foo>
<!-- This is the new content
-->
</doc>
A.10. Replacing a Processing Instruction Node
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<?test foo="bar"?>
</doc>
An XML diff document:
Urpalainen Expires February 10, 2008 [Page 25]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel='doc/processing-instruction("test")'
><?test bar="foobar"?></replace>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<?test bar="foobar"?>
</doc>
A.11. Replacing a Text Node
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<replace sel="doc/foo/text()[1]"
>This is the new text content</replace></diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is the new text content</foo>
</doc>
A.12. Removing an Element
An example initial XML document:
Urpalainen Expires February 10, 2008 [Page 26]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo[@a='1']" ws="after"/>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
</doc>
A.13. Removing an Attribute
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc a="foo">
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/@a"/>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
Urpalainen Expires February 10, 2008 [Page 27]
Internet-Draft Patch Operations August 2007
A.14. Removing a Prefixed Namespace Declaration
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1" xmlns:pref="urn:test"
>This is a sample document</foo>
<!-- comment -->
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo/namespace::pref"/>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
A.15. Removing a Comment Node
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<!-- comment -->
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/comment()[1]" ws="after"/>
</diff>
Urpalainen Expires February 10, 2008 [Page 28]
Internet-Draft Patch Operations August 2007
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
A.16. Removing a Processing Instruction Node
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
<?test?>
</doc>
An XML diff document:
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel='doc/processing-instruction("test")'/>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
A.17. Removing a Text Node
An example initial XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1">This is a sample document</foo>
</doc>
An XML diff document:
Urpalainen Expires February 10, 2008 [Page 29]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<diff>
<remove sel="doc/foo/text()[1]"/>
</diff>
A result XML document:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<foo a="1"/>
</doc>
A.18. Several Patches With Namespace Mangling
An example initial XML document where namespace qualified elements
exist:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>This is a sample document</note>
<elem a="foo">
<child/>
</elem>
<elem a="bar">
<z:child/>
</elem>
</doc>
An imaginary XML diff document where prefix "p" corresponds the
targetNamespace of this imaginary schema:
Urpalainen Expires February 10, 2008 [Page 30]
Internet-Draft Patch Operations August 2007
<?xml version="1.0" encoding="UTF-8"?>
<p:diff xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:y="urn:ietf:params:xml:ns:yyy"
xmlns:p="urn:ietf:params:xml:ns:diff">
<p:add sel="doc/elem[@a='foo']"> <!-- This is a new child -->
<child id="ert4773">
<y:node/>
</child>
</p:add>
<p:replace sel="doc/note/text()">Patched doc</p:replace>
<p:remove sel="*/elem[@a='bar']/y:child" ws="both"/>
<p:add sel="*/elem[@a='bar']" type="@b">new attr</p:add>
</p:diff>
One possible form of the result XML document after applying the
patches:
<?xml version="1.0" encoding="UTF-8"?>
<doc xmlns="urn:ietf:params:xml:ns:xxx"
xmlns:z="urn:ietf:params:xml:ns:yyy">
<note>Patched doc</note>
<elem a="foo">
<child/>
<!-- This is a new child -->
<child id="ert4773">
<z:node/>
</child>
</elem>
<elem a="bar" b="new attr"/>
</doc>
The <node> and removed <child> element prefixes within the XML diff
document are different than what are the "identical" namespace
declarations in the initial XML document. If the initial XML
document had used a prefixed namespace declaration instead of the
default one, the XML diff document could still have been the same.
The added new qualified elements would just have inherited that
prefix.
Urpalainen Expires February 10, 2008 [Page 31]
Internet-Draft Patch Operations August 2007
Author's Address
Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com
Urpalainen Expires February 10, 2008 [Page 32]
Internet-Draft Patch Operations August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Urpalainen Expires February 10, 2008 [Page 33]
