view Side-By-Side changes

SIMPLE WG                                                  J. Urpalainen
Internet-Draft                                     Nokia Research Center
Expires: May 29, July 30, 2006                                  January 26, 2006                                  November 25, 2005


An Extensible Markup Language (XML) Patch Operations Framework Utilizing
                  XML Path Language (XPath) Selectors
                   draft-ietf-simple-xml-patch-ops-00
                   draft-ietf-simple-xml-patch-ops-01

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 May 29, July 30, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005). (2006).

Abstract

   Extensible Markup Language (XML) documents are widely used as
   containers for the exchange and storage of arbitrary data in today's
   systems.  Updates to this data require transporting of the entire XML
   document between hosts, unless there's a mechanism that allows
   exchanging only the updates of XML documents.  This document
   describes an XML patch framework utilizing XML Path language (XPath)
   selectors.  With the aid of these  These selector values and updated new data content
   constitute the basis of patch operations described in this document.



Urpalainen                Expires July 30, 2006                 [Page 1]

Internet-Draft              Patch Operations                January 2006


   In addition to them, with basic <add>, <replace> and <remove>
   directives a set of patches can then be applied to update an existing initial



Urpalainen                Expires May 29, 2006                  [Page 1]

Internet-Draft              Patch Operations               November 2005
   XML document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Basic features Features and requirements Requirements  . . . . . . . . . . . . . . .  4
   4.  Patch operations Operations . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  <add> element  Locating the Target for a Patch  . . . . . . . . . . . . .  6
     4.2.  Namespace Mangling . . . . . . . . . . . . . .  7
     4.2.  <replace> element . . . . . .  6
     4.3.  <add> Element  . . . . . . . . . . . . . . .  9
     4.3.  <remove> element . . . . . . .  8
     4.4.  <replace> Element  . . . . . . . . . . . . . . . . . . . . 11
     4.4.  <patch> element
     4.5.  <remove> Element . . . . . . . . . . . . . . . . . . . . . 12
   5.  Error handling Handling . . . . . . . . . . . . . . . . . . . . . . . . 13 14
   6.  Usage of patch operations Patch Operations  . . . . . . . . . . . . . . . . . . 13 14
   7.  Usage of Selector Values . . . . . . . . . . . . . . . . . . . 14
   8.  Full example Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8. 14
   9.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   9. 16
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     9.1. 18
     10.1. XML Schema Registration  . . . . . . . . . . . . . . . . . 17
   10. 18
   11. Security considerations Considerations  . . . . . . . . . . . . . . . . . . . 17
   11. 18
   12. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   12. 19
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     12.1. 19
     13.1. Normative references References . . . . . . . . . . . . . . . . . . . 18
     12.2. 19
     13.2. Informative references References . . . . . . . . . . . . . . . . . . 18 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 21 22





















Urpalainen                Expires May 29, July 30, 2006                 [Page 2]

Internet-Draft              Patch Operations               November 2005                January 2006


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.  An example of such a system is the Common Presence Profile
   (CPP) [14] [16] compatible presence system, in which presence data is
   represented using the XML based Presence Information Data Format
   (PIDF) [15]. [17].  Updates to this data require transporting of the entire
   XML document between hosts, unless there's a mechanism that allows
   exchanging only the updates of a an XML document.

   This document describes an XML patch framework which utilizes XML
   Path language (XPath) [3] selectors.  With  An XPath selector is used to
   pinpoint the aid of these target for a 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 then be applied to update an
   existing initial XML document in order to transform it into document.  With these patch operations, a
   new patched simple
   semantics for data oriented XML document. 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 operations operation elements
   which can be included embedded within
   the a full format.

   An XPath selector is used to locate a single unique node from the
   existing initial XML document.  Once the XML node which pinpoints the
   target for the modification has been found, modifications like
   additions, removals or substitutions of e.g. elements and attributes
   can be done.

   As an example, in

   As an example, in the Session Initiation Protocol (SIP) [16] [18] based
   presence system a partial PIDF XML document format [13] consists of
   the existing PIDF document format combined with the patch operations
   elements described in this document.  In general, the patch operations
   can be used in any application that exchanges XML documents, e.g. in for
   example within the SIP Events framework [12].  Another example is
   XCAP-diff [14] which uses this framework for sending partial updates
   of changes to XCAP [15] 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 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 May 29, July 30, 2006                 [Page 3]

Internet-Draft              Patch Operations               November 2005                January 2006


   XML diff document: A frame XML document that contains patch operation
      elements, namespace declarations and all the document content
      changes that are needed in order to get a patched transform an initial XML
      document
      from the initial 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., 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.

   Whitespace

   White space text node: A text node which contains only whitespace. white space.


3.  Basic features Features and requirements

   The changes of an Requirements

   In this framework, XPath selector values and new data content are
   embedded within XML document content, elements, the names of which imply the type of a
   modification: <add>, <replace> or <remove>.  These elements, or
   synonymously patch operations as used in this document, are described
   by defining their schema types for elements with the W3C Schema language [6].
   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
   defined according to these types MUST then contain the new data content.  In general
   when applicable, the new content SHOULD be embedded within an
   application specific moved unaltered to the
   patched XML diff document.

   The specifications utilizing these element types MUST then define the full
   XML diff format with an appropriate MIME type [11].  For example the [11] and a character



Urpalainen                Expires July 30, 2006                 [Page 4]

Internet-Draft              Patch Operations                January 2006


   set, e.g.  UTF-8 [9].  The partial PIDF format [13] includes these this
   schema element types. and describes additional definitions to produce a complete XML
   diff format for presence information updates.

   As the schema defined in this document does not declare any target
   namespace, elements defined according to these types the type definitions inherit the target namespace of the
   including schema.  Therefore, additional
   unnecessary namespace declarations
   within the instance XML diff



Urpalainen                Expires May 29, 2006                  [Page 4]

Internet-Draft              Patch Operations               November 2005 documents can be avoided.

   It is anticipated that applications using these types will define
   <add>, <replace>, <remove> <replace> and <patch> <remove> elements from based on the corresponding types defined
   type definitions in this schema.  As this specification
   defines only types for elements,  In addition, an application utilizing this
   framework can easily omit some may
   reference only a subset of these type definitions which it
   doesn't need.  With these basic operations a simple patch model for
   data oriented documents [7] is produced.  On the definitions.  A future
   extension can introduce other hand, the
   semantics described in this operations, e.g. with document can easily be extended as these
   patch operations provide only the basic required features. 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 the initial 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 of
   the a document root element is not allowed as
   any valid XML document MUST always contain a root element.  Also note
   that would result in an
   invalid support for external entities is beyond the scope of this
   framework.

   XML document. 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 only a single possible the
   canonical form with comments [4] of an XML document
   exists once the patches have been applied onto it.  Especially
   whitespace determines
   logical equivalence.  For example, white space text nodes MUST be
   processed properly in order to fulfil this requirement as all whitespace white
   space is not insignificant [4].


4.  Patch operations

   A full Operations

   An XML diff document contains a collection of patch operation
   elements:
   elements, including one or more <add>, <replace>, <remove> <replace> and <patch> or a subset of these
   operations.  They <remove>
   elements.  These patch operations will be applied sequentially to the initial XML
   document in the given
   document order of order.  After the XML diff document.  Other
   elements than <patch> first patch has been applied to update an
   initial XML document, the structure of the patched XML document becomes a new initial



Urpalainen                Expires July 30, 2006                 [Page 5]

Internet-Draft              Patch Operations                January 2006


   XML document.  The <patch> element MAY be used with document oriented
   models [7] to update text content.  This procedure repeats until all patches have
   successfully been processed.  In other words, this framework does not
   allow "apply all occurrences" in one pass.

4.1.  Locating the Target for a Patch

   Each of these patch operation elements 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 value of the 'sel'
   attribute value is used to locate
   a single unique target node from the initial XML document.

   While  This
   located node pinpoints the XPath recommendation specifies that prefixes can be used in



Urpalainen                Expires May 29, 2006                  [Page 5]

Internet-Draft              Patch Operations               November 2005


   location steps, target for a change and usually it does not specify how associated namespace URIs are
   to be found during the XPath evaluations.  In this framework QName
   [5] expansion within a location step is evaluated according to the
   namespace declarations of the XML diff document.  Thus the namespace
   URIs for the prefixes an
   element, which is e.g. either updated itself or some child node(s)
   are easily found from the XML diff document.
   XPath allows using "namespace-uri()" and "local-name()" node-set
   functions within XPath predicates.  For instance, these functions added into it.  It may
   then also be utilized if there are no other means to "register" prefixes
   with associated namespace URIs.  The schema type definitions for
   these elements do not allow the usage of these node-set functions.

   It should be emphasized that prefixes within the XPath selectors MAY
   not have to be the same than that of the initial XML document because
   the equivalence of nodes is based on the same namespace URIs and
   local names.

   If a patch operation element has an in-scope default namespace
   declaration and a prefix is not used in instance a node test then that name is
   interpreted as if comment node, after
   which some other sibling node(s) are inserted.  In any case, it had had a prefixed name associated with this
   default namespace URI.  That is, unlike in XPath 1.0, a namespace
   qualified element is being searched.

   When locating the target node for a patch operation from an
   error condition if multiple nodes are found during the initial
   XML document, all evaluation of
   this selector value.

   The XPath selections of the 'sel' attribute always start from the
   root node of the a document.  Relative  Thus relative location paths SHOULD then be used
   so that the starting root node selection "/" can be omitted.  When
   locating elements in the a document tree, the a node test can be either be a "*"
   character or a QName.  A "*" character selects all element children
   of the context node.  Attribute value comparisons MAY be used as
   predicates.  Also text content of  Right after the current context node or test, a child
   element MAY location step can
   contain one or more predicates in any order.  An attribute value
   comparison is the most typical predicate.  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()".  Positional "self::
   node()".  Lastly, positional constraints MAY like "[2]" can also be used
   as an additional predicate.  Ordering of these
   positional constraints and value comparisons can interchange.

   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 the an instance document.

   As all

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 [5] expansion within a location step is evaluated
   according to the namespace declarations relevant to of the patch operations XML diff document.
   Thus the namespace URIs for these prefixes are included in found from the in-
   scope namespaces of the patch operation element.  In other words, the
   XML diff document, document contains all needed information for QName
   expansions in order to perform XPath searches from the initial XML



Urpalainen                Expires July 30, 2006                 [Page 6]

Internet-Draft              Patch Operations                January 2006


   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.  As with XPath
   selectors,  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 prefixes patch operation
   element or within its ascendants, these references MUST thus be
   changed.  Like in XPath, the mapping of these nodes are references is based on
   identical namespace URIs, not significant only the prefixes.  The namespace URIs MUST match.  For example when adding with an
   identical URI from the in-scope namespaces of a new qualified
   element to context node of the
   initial XML document, the namespace declaration which



Urpalainen                Expires May 29, 2006                  [Page 6]

Internet-Draft              Patch Operations               November 2005


   has the same namespace URI is attached to this new element. document MUST be chosen.  However, if overlapping in-scope in-
   scope namespaces exist within the evaluation
   context, exist, i.e., there are several in-scope namespaces
   with the same an identical namespace URI, then the namespace with the same
   prefix MUST be
   selected.  This chosen.  If an equivalent prefix is not then found, an
   error occurs.  For instance, this kind of overlapping can happen when e.g.
   a namespace qualified attribute is added while elements are attached



Urpalainen                Expires July 30, 2006                 [Page 7]

Internet-Draft              Patch Operations                January 2006


   with an equal identical default namespace declaration.

   If

   When the intention is to add new added or updated elements contain namespace declarations to
   declarations, the namespace nodes move unaltered from the initial XML document, diff
   document to the new namespaces MUST patched XML document.  Default namespace declarations
   can only be declared within the added or
   changed data content embedded as local by this way but prefixed namespace declarations within elements,
   or they MUST MAY
   be explicitly added by using or removed with XPath namespace axis semantics shown later
   in this document.

4.1.  <add> element

   The <add> element represents

      Note: In practice, this namespace mangling means that an XML diff
      document MUST only know the addition namespace URIs of some new content to qualified nodes, the
   initial XML document: e.g., a new XML element or an attribute.

   The <add> element type has three attributes: 'sel', 'type' and 'pos'.

   The value
      prefixes of the 'sel' attribute is used to locate a single unique
   element from the initial XML document.  It is an error condition if
   multiple elements document are found during not significant unless
      there are those overlapping namespace declarations.  In other
      words, regardless whether the evaluation prefixes of this selector
   value.

   The value qualified elements of
      the optional 'type' attribute is used to describe initial XML document are empty (default namespace attached) or
      not, the
   type 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 data content. element can be appended into an
   existing element.

   The new data content, which MUST not
   be empty content exists as the child node(s) of this the <add>
   element.  The
   value  When adding attributes and namespaces the child node of 'type' attribute is also an XPath 1.0 compatible selector
   with the
   <add> element MUST be a very limited set of XPath features.  Once single text node.  Otherwise, the new content
   within <add>
   element can contain any mixture of element, text, comment or
   processing instruction nodes in any order.  All children of the <add>
   element contains are then copied into an initial XML document.  The described
   namespace mangling procedure applies to added elements, they will which include
   all the of their attribute, namespace and descendant nodes.  As the default

   The <add> element type has three attributes: 'sel', 'type' and 'pos'.

   The value of the optional 'type' attribute is "node()" the new content can be element,
   text, comment or processing instruction nodes or a mixture of them.
   The "node()" selector value is an abbreviated form of "child::
   node()".  A positional constraint MAY be only used with the "node()"
   selector when only a single adding
   attributes and namespaces.  Then the located target node needs to MUST be added.  If an
   element into which new attributes and namespace declarations are
   inserted.  When the value of
   the this 'type' attribute equals "@attr" the
   purpose is to add a new
   'attr' attribute. attribute node with the name 'attr'.  The
   value of the this new 'attr' attribute is then 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 July 30, 2006                 [Page 8]

Internet-Draft              Patch Operations                January 2006


      Note: The 'type' attribute is then thus also an XPath selector, but it
      only locates attributes and namespaces.  Attribute axis
      "attribute" has an abbreviated form "@" unlike the corresponding namespace URI. "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 the new data content.  As the default value  It is "to", not used when adding attributes or
   namespaces.  When neither 'type' nor 'pos' attribute exist, the new



Urpalainen                Expires May 29, 2006                  [Page 7]

Internet-Draft              Patch Operations               November 2005


   content is
   children of the <add> element are then simply added onto appended as the last child
   node(s) of the located target element.  For
   other node types than  When the value of 'pos'
   attribute and namespace nodes, new content is
   appended "prepend" the new node(s) are added as the last first child node(s).
   node(s) of the located target element.  With the value of "before"
   the added new content node(s) MUST be the closest immediate preceding sibling node(s)
   and with "after" the closest immediate following sibling node(s).  Naturally the usage node(s) of 'pos' attribute is not allowed when adding attributes and
   namespaces.  It can be used e.g. when a comment node or an element is
   added just before or after an existing element.

   Appending elements with all the descendant and attribute nodes is the
   most typical operation.  Because 'type' and 'pos' attributes have
   convenient default values, the <add> element SHOULD then only contain
   the 'sel' attribute with the added content.
   located target node.

   Some examples without any prefixes in XPath selectors and elements follow where nodes are also not namespace qualified.  The initial XML document could be
   like the full example shown later in this document. qualified and
   prefixes are therefore not used.  The full whole XML diff content is not
   shown in these examples, only patch operation elements because of
   simplicity reasons:

   <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.

   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].

   It should be noted that as

      Note: As the 'sel' selector value MAY contain quotation marks,
      escaped forms: "&quot;" or "&apos;" can then 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.



Urpalainen                Expires July 30, 2006                 [Page 9]

Internet-Draft              Patch Operations                January 2006


   An example for an addition of a prefixed namespace declaration:



Urpalainen                Expires May 29, 2006                  [Page 8]

Internet-Draft              Patch Operations               November 2005

   <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".

   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 the closest an immediate preceding sibling node.  This shows is also an example how
   a 'pos' attribute directive MAY can be used.

   Some complexity arises when so called whitespace white space text nodes exist
   within the an initial XML document.  The XPath 1.0 data model requires
   that a text node MUST not have another text node as a 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 in this example <add> element has then two child nodes: a
   whitespace 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 whitespace
   white space text node content MUST then be combined together.
   Otherwise whitespace (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.

   If

   Still another example about the handling of text nodes.  Consider
   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.





Urpalainen                Expires July 30, 2006                [Page 10]

Internet-Draft              Patch Operations                January 2006


      Note: It is still worth noting that text nodes MAY contain other than pre-defined 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] their
   declarations MUST typically 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 of contains those
   declarations.  These references may then be preserved if both the XML
   diff
   document if 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 also referencing these
   entities.

4.2. obeyed.

4.4.  <replace> element Element

   The <replace> element represents a replacement operation: e.g. an
   existing XML element is updated with a new XML 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 an attribute: 'sel'.  The value of
   this attribute is used to select only a single unique node from the
   initial XML document. 'sel' attribute.  If the
   located target node is an element, a comment or a processing
   instruction, then the child of the <replace>



Urpalainen                Expires May 29, 2006                  [Page 9]

Internet-Draft              Patch Operations               November 2005 element MUST also be of
   the same type.  Otherwise the <replace> element MUST have text
   content or it MAY be empty, i.e. it does not
   have any child node. empty when replacing an attribute value or a
   text node content.

   Examples for replace operations, first 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", i.e. the "1".  The located target element is replaced with the <bar>
   element.  So all descendant nodes, namespace declarations and
   attributes of the replaced <foo> element, if any existed, are thus
   removed.

   An example for a replacement of an attribute value:

   <replace sel="doc/@a">new content</replace> value</replace>

   This will replace the attribute 'a' attribute content of the <doc> element with
   the value "new content". value".  If the <replace> element has not a child
   text node, i.e. not any content, is empty, the 'a'
   attribute MUST then remain in the patched XML document appearing like
   <doc a=""/>.

   An example for a replacement of a namespace URI:




Urpalainen                Expires July 30, 2006                [Page 11]

Internet-Draft              Patch Operations                January 2006


   <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.

   An example for a replacement of a comment node:

   <replace sel="doc/comment()[1]"><!-- This is the new content
   --></replace>

   This will replace the a comment node.  The located target node is the
   first child comment node child of the <doc> element.

   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.

   An example for a replacement of a text node:



Urpalainen                Expires May 29, 2006                 [Page 10]

Internet-Draft              Patch Operations               November 2005

   <replace sel="doc/foo/text()[1]">This is the new text content</
   replace>

   This will replace the first child text node child of the <foo> element.
   The positional constraint e.g. "[1]" is not usually needed as the element
   content is rarely of mixed type [6] where several child text
   nodes node siblings
   typically exist.

   If a text node is being updated and the <replace> element has not any
   child node, is empty, the
   text node MUST thus be removed.

4.3. removed as a text node MUST always have at
   least one character of data.

4.5.  <remove> element Element

   The <remove> element represents a removal operation of e.g. an
   existing XML element or an attribute from the initial XML document. attribute.

   The <remove> element type has two attributes: 'sel' and 'ws'.  The
   value of the 'sel' attribute is used to select a single unique node
   from the initial XML document.  The value of the optional 'ws' attribute is used to remove the possible whitespace
   white space text nodes that exist either as the closest immediate following or
   preceding sibling node(s) nodes of the located target node.  The usage of
   'ws' attribute is only allowed when removing other types than text,
   attribute and namespace nodes.
   As the default value of 'ws' attribute is "none", removal of
   whitespace nodes is thus not requested.  If the value of 'ws' is "before", the
   purpose is to remove the closest immediate preceding sibling node which MUST



Urpalainen                Expires July 30, 2006                [Page 12]

Internet-Draft              Patch Operations                January 2006


   be a whitespace 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 whitespace white space text nodes MUST be removed.

   Examples for remove operations, first a removal of an element
   including all descendants, attributes of its descendant, attribute and namespape namespace nodes:

   <remove sel="doc/foo[@a='1']" ws="after"/>

   This will remove the <foo> element as well as the closest immediate following
   sibling whitespace white space text node of the <foo> element.  If the immediate
   following sibling node is not a whitespace white space text node, an error
   occurs.

   An example for a removal of an attribute node:

   <remove sel="doc/@a"/>

   This will remove the 'a' attribute node from the <doc> element.

   An example for a removal of a namespace node:

   <remove sel="doc/foo/namespace::pref"/>



Urpalainen                Expires May 29, 2006                 [Page 11]

Internet-Draft              Patch Operations               November 2005

   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.

   An example for a removal of a comment node:

   <remove sel="doc/comment()[1]"/>

   This will remove the first child comment node of the <doc> element.

   An example for a removal of a processing instruction node:

   <remove sel='doc/processing-instruction("test")'/>

   This will remove the child processing instruction node "test" of the
   <doc> element.

   An example for a removal of a text node:

   <remove sel="doc/foo/text()[1]"/>

   This will remove the first child text node of the <foo> element.

   If an element, a comment node or a processing instruction node which
   has a whitespace text node as both the closest preceding and
   following node, is removed without a request to remove whitespace
   nodes, the content of these two nodes MUST be combined together.  The
   other whitespace text node thus disappears from the initial XML
   document.

4.4.  <patch> element

   This element type describes patching of a text node content or an
   attribute value.  There are several text patching algorithms
   available.  The <patch> element type shows how these algorithms can
   be integrated with this framework.

   The <patch> element type has two attributes: 'sel' and 'method'.  The
   value node child of the 'sel' attribute is used to select <doc> element.

   An example for a single unique text
   node or an attribute from the initial XML document.  The 'method'
   value indicates removal of a processing instruction node:

   <remove sel='doc/processing-instruction("test")'/>

   This will remove the patch algorithm one "test" processing instruction node child of which could be e.g.
   "vcdiff" [9].  As XML is not good at embedding binary data the text
   diffing content MUST be included with BASE64 encoding [10].
   <doc> element.

   An example for a removal of a text node:

   <remove sel="doc/foo/text()[1]"/>

   This will remove the first text node patch operation:

   <patch sel="doc/foo/text()" child of the <foo> element.




Urpalainen                Expires May 29, July 30, 2006                [Page 12] 13]

Internet-Draft              Patch Operations               November 2005


   >1sPEAAAAFhAAEAEAcmVsYXggbmcgaXMgY29vbBGA</patch>

   After locating the child text                January 2006


   When removing an element, a comment or a processing instruction node of
   which has immediate preceding and following sibling text nodes
   without the 'ws' directive, the <foo> element, BASE64 diff content is decoded and a relevant patch is applied to of these two text nodes MUST
   be combined together.  The latter text node thus disappears from the target
   node.
   document.


5.  Error handling Handling

   It is an error condition if any of the given operations can not be
   unambiguously fulfilled.  However, it is beyond the scope of this
   document to describe a generic error response.


6.  Usage of patch operations

   The 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 MAY
   be desirable to transport 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 the verbosity model for
   selector values.  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.  Full example Example

   An example initial XML document where namespace qualified elements
   exist:












Urpalainen                Expires July 30, 2006                [Page 14]

Internet-Draft              Patch Operations                January 2006


   <?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 May 29, 2006                 [Page 13]

Internet-Draft              Patch Operations               November 2005

   <?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:













Urpalainen                Expires July 30, 2006                [Page 15]

Internet-Draft              Patch Operations                January 2006


   <?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 prefix prefixes within the XML diff
   document is are different than what is are the same "identical" namespace declaration
   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 updated added new qualified elements would then just have inherited the prefixes of the initial XML document.


8. that
   prefix.


9.  XML Schema




Urpalainen                Expires May 29, 2006                 [Page 14]

Internet-Draft              Patch Operations               November 2005

   The element schema types for the patch operations. operation elements.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE schema [
    <!ENTITY ncname "[^:\I][^:\C]*">
    <!ENTITY qname  "(&ncname;:)?&ncname;">
    <!ENTITY aname  "@&qname;">
    <!ENTITY pos_t pos    "\[\d+\]">
    <!ENTITY attr_t  "\[&aname;=('|&quot;)(.)*('|&quot;)\]"> attr   "\[&aname;='(.)*'\]|\[&aname;=&quot;(.)*&quot;\]">
    <!ENTITY name_t  "\[(&qname;|\.)=('|&quot;)(.)*('|&quot;)\]"> valueq "\[(&qname;|\.)=&quot;(.)*&quot;\]">
    <!ENTITY value  "\[(&qname;|\.)='(.)*'\]|&valueq;">
    <!ENTITY cond    "(&attr_t;|&name_t;)?(&pos_t;)?|(&pos_t;)?(&attr_t;|&name_t;)?">   "&attr;|&value;|&pos;">
    <!ENTITY step    "(&qname;|\*)(&cond;)?">   "(&qname;|\*)(&cond;)*">
    <!ENTITY piq    "processing-instruction\((&quot;&ncname;&quot;)?\)">
    <!ENTITY pi      "processing-instruction\((('|&quot;)&qname;('|&quot;))?\)">     "processing-instruction\(('&ncname;')?\)|&piq;">
    <!ENTITY id      "id\((('|&quot;)&ncname;('|&quot;))?\)">     "id\(('&ncname;')?\)|id\((&quot;&ncname;&quot;)?\)">
    <!ENTITY comm com    "comment\(\)">
    <!ENTITY text   "text\(\)">
    <!ENTITY nspace nspa   "namespace::&ncname;">
    <!ENTITY last    "&step;|&aname;|&nspace;|(&comm;(&pos_t;)?)|&text;(&pos_t;)?|&pi;(&pos_t;)?"> child  "&step;|&com;(&pos;)?|&text;(&pos;)?|&pi;(&pos;)?">
    <!ENTITY patch   "(&text;(&pos_t;)?)|&aname;"> last   "&child;|&aname;|&nspa;">
   ]>



Urpalainen                Expires July 30, 2006                [Page 16]

Internet-Draft              Patch Operations                January 2006


   <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-elem">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="(/)?(&step;/)*(&step;)"/>
         <xsd:pattern value="(/)?&id;(/&step;)*"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="xpath-text"> name="xpath-add">
       <xsd:restriction base="xsd:string">
         <xsd:pattern value="(/)?(&step;/)*&patch;"/> value="(/)?(&step;/)*(&child;)"/>
         <xsd:pattern value="(/)?&id;(/&step;)*/&patch;"/> value="(/)?&id;((/&step;)*(/&child;))?"/>
       </xsd:restriction>
     </xsd:simpleType>

     <xsd:simpleType name="pos">
       <xsd:restriction base="xsd:string">



Urpalainen                Expires May 29, 2006                 [Page 15]

Internet-Draft              Patch Operations               November 2005


         <xsd:enumeration value="to"/>
         <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="node\(\)(&pos_t;)?"/>
         <xsd:pattern value="&aname;"/>
         <xsd:pattern value="&nspace;"/> 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-elem" type="xpath-add"
                          use="required"/>
           <xsd:attribute name="pos" type="pos"
                          default="to"/> type="pos"/>
           <xsd:attribute name="type" type="type"
                          default="node()"/> type="type"/>
         </xsd:restriction>
       </xsd:complexContent>
     </xsd:complexType>



Urpalainen                Expires July 30, 2006                [Page 17]

Internet-Draft              Patch Operations                January 2006


     <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="none"/>



Urpalainen                Expires May 29, 2006                 [Page 16]

Internet-Draft              Patch Operations               November 2005


         <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" default="none"/>
     </xsd:complexType>

     <xsd:complexType name="patch">
       <xsd:simpleContent>
         <xsd:extension base="xsd:base64Binary">
           <xsd:attribute name="sel" type="xpath-text"
                          use="required"/>
           <xsd:attribute name="method" type="xsd:string"
                          default="vcdiff"/>
         </xsd:extension>
       </xsd:simpleContent> type="ws"/>
     </xsd:complexType>

   </xsd:schema>



9.



10.  IANA Considerations

9.1.

10.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>


10.


11.  Security considerations Considerations

   Information exchanged within these patch operations can be highly
   sensitive.  Thus systems need to protect the integrity and



Urpalainen                Expires July 30, 2006                [Page 18]

Internet-Draft              Patch Operations                January 2006


   confidentiality of this data.  Especially, the transport protocol
   once it is used SHOULD have capabilities to protect from possible
   threats.





Urpalainen                Expires May 29, 2006                 [Page 17]

Internet-Draft              Patch Operations               November 2005


11.  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.


12.  Acknowledgments

   The author would like to thank Eva Leppanen, Mikko Lonnfors, Aki
   Niemi, Jonathan Rosenberg and Rosenberg, Miguel A. Garcia and Anat Angel for their
   valuable
   comments.


12. comments and Ted Hardie for his input and support.


13.  References

12.1.

13.1.  Normative references 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 (Third Edition)", W3C
        Recommendation REC-xml-20040204 , February 2004.

   [3]  "XML Path Language (XPath) Version 1.0", W3C Recommendation
         REC-xpath-19991116 REC-
        xpath-19991116 , November 1999.

   [4]  "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 ,
        March 2001.

   [5]  "Namespaces in XML", W3C Recommendation REC-xml-names-
         19990114 REC-xml-names-19990114 ,
        January 1999.

   [6]  "XML Schema Part 1: Structures Second Edition", W3C
        Recommendation REC-xmlschema-1-20041028 , October 2004.

   [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]   Korn, D., MacDonald, J., Mogul, J., and K. Vo, "The VCDIFF
         Generic Differencing and Compression Data Format", RFC 3284,
         June 2002.

   [10]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        RFC 3548, 2279, January 1998.







Urpalainen                Expires July 2003.

12.2. 30, 2006                [Page 19]

Internet-Draft              Patch Operations                January 2006


13.2.  Informative references References

   [10]  "XML Path Language (XPath) Version 2.0", W3C Candidate
         Recommendation 3 20051103 , November 2005.

   [11]  Murata, M., "XML media types", RFC 3023, January 2001.

   [12]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.



Urpalainen                Expires May 29, 2006                 [Page 18]

Internet-Draft              Patch Operations               November 2005

   [13]  Lonnfors, M., Leppanen, E., Khartabil, H., and J. Urpalainen,
         "Presence Information Data format (PIDF) Extension for Partial
         Presence",  draft-ietf-simple-partial-pidf-format-05 (work in
         progress), September 2005.

   [14]  Rosenberg, J., "An Extensible Markup Language (XML) Document
         Format For Indicating Changes in XML Configuration Access
         Protocol (XCAP) Resources",  draft-ietf-simple-xcap-diff-0x
         (work in progress), ? 2006.

   [15]  Rosenberg, J., "The Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)",
          draft-ietf-simple-xcap-08, October 2005.

   [16]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
         August 2004.

   [15]

   [17]  Sugano, H., "CPIM presence information data format", RFC 3863,
         May 2003.

   [16]

   [18]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.



















Urpalainen                Expires May 29, July 30, 2006                [Page 19] 20]

Internet-Draft              Patch Operations               November 2005                January 2006


Author's Address

   Jari Urpalainen
   Nokia Research Center
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   Phone: +358 7180 37686
   Email: jari.urpalainen@nokia.com









































Urpalainen                Expires May 29, July 30, 2006                [Page 20] 21]

Internet-Draft              Patch Operations               November 2005                January 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2005). (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Urpalainen                Expires May 29, July 30, 2006                [Page 21] 22]

----