SIMPLE                                                      J. Rosenberg
Internet-Draft                                               dynamicsoft
Expires: August 16, 2004                               February January 16, 2005                                  July 18, 2004

   A Session Initiation Protocol (SIP) Event Package for Modification
  Events for the

   An Extensible Markup Language (XML) Document Format for Indicating
     Changes in XML Configuration Access  Protocol (XCAP) Managed Documents
                   draft-ietf-simple-xcap-package-01 Resources
                   draft-ietf-simple-xcap-package-02

Status of this Memo

   This document is an Internet-Draft

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and is any of which I become aware will be disclosed, in full conformance accordance with
   all provisions of Section 10 of RFC2026.
   RFC 3668.

   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.
   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 August January 16, 2004. 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This specification defines a Session Initiation Protocol (SIP) event
   package for finding out about changes document format that can be used to documents
   describe the differences between versions of resources managed by the
   Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP). XCAP allows a client  Documents of this format can be delivered to manipulate XML documents on clients using a server
   which contain configuration information
   number of means, including the Session Initiation Protocol (SIP)
   event package for application protocols.
   Multiple configuration data.  By subscribing to this event
   package, clients can potentially access the same document, in which
   case the other clients would like to be notified of a change in the learn about document changes made by another. This event package allows a client to do
   that. other
   clients.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Structure of an XCAP Diff Document Change Event Package  . . . . . . . . . . . . . . .   4
   2.1  Package Name . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.2  Event Package Parameters . . . . . . . . . . . . . . . . . .   4
   2.3  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . .   5
   2.4  Subscription Duration  . . . . . . . . . . . . . . . . . . .   5
   2.5  NOTIFY Bodies  . . .
   3.  XML Schema . . . . . . . . . . . . . . . . . . . .   5
   2.6  Notifier Processing of SUBSCRIBE Requests  . . . . . . . . .  6
   2.7  Notifier Generation of NOTIFY Requests . . . . . . . . . . .   7
   2.8  Subscriber Processing of NOTIFY Requests . . . . . . . . . .   7
   2.9  Handling of Forked Requests  . . . . . . . . . . . .
   4.  Example Document . . . .   8
   2.10 Rate of Notifications . . . . . . . . . . . . . . . . . . .  8
   2.11 State Agents . . . . . . . . . . . . . . . . . . . .
   5.  Usage with the Config Framework  . . . .   8
   3.   application/xml-change+xml Media Type . . . . . . . . . . .  9
   3.1  XML Schema .
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . .  11
   3.2  Example Document . . . . . . . . . . . . . . . . 13
     7.1   application/xcap-diff+xml MIME Type  . . . . . .  11
   4.   Security Considerations . . . . . 13
     7.2   URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 13
   5.   IANA Considerations  .
     7.3   Schema Registration  . . . . . . . . . . . . . . . . . . . 14
   5.1  SIP Event Package  . . . . . . . . . . . . .
   8.  References . . . . . . . .  14
   5.2  application/xcap-change+xml MIME Type . . . . . . . . . . .  14
   5.3  URN Sub-Namespace Registration for
        urn:ietf:params:xml:ns:xcap-change . . . . . . . . . . . . . 15
   8.1   Normative References . . . . . . . . . . . . . . . . . . . .  17 15
   8.2   Informative References . . . . . . . . . . . . . . . . . . .  18 15
       Author's Address . . . . . . . . . . . . . . . . . . . . . .  18 . 16
       Intellectual Property and Copyright Statements . . . . . . .  19 . 17

1.  Introduction

   The Extensible Markup Language (XML) Configuration Access Protocol
   (XCAP) [10] [7] is a protocol that allows clients to manipulate XML
   documents stored on a server.  These XML documents serve as
   configuration information for application protocols.  As an example,
   resource list [11] subscriptions (also known as presence lists) allow
   a client to have a single SIP subscription to a list of users, where
   the list is maintained on a server.  The server will obtain presence
   for those users and report it back to the client.  This application
   requires the server, called a Resource List Server (RLS), to have
   access to the list of presentities.  This list needs to be
   manipulated by clients so they can add and remove their friends as
   they desire.

   Complexities arise when multiple clients attempt to simultaneously
   manipulate a document, such as a presence list.  Frequently, a client
   will keep a copy of the current list in memory, so it can render it
   to users.  However, if another client modifies the document, the
   cached version becomes stale.  This information must be made known to
   all clients which have cached copies of the document, so that they
   can fetch the most recent one.

   This problem is addressed by

   To deal with this specification, which provides a problem, clients can use the Session Initiation
   Protocol (SIP) [1]event [9]event package [2] [10] for subscribing to changes in documents managed by
   configuration and profile information [8], including application data
   that resides on an XCAP server. This
   package would be used by any client which is retaining a cached copy
   of  With that package, a document obtained by XCAP, so user gets
   notified that it can find out when a change particular document has been made, invalidating its cached copy. In fact, the
   notifications generated by this package indicate changed.  This notification
   can include the specific change
   which occurred in full content of the new document, so the client or it can decide whether be a
   content indirection [14].  However, in both cases, the
   change transfer of
   the entire document is significant enough to warrant ultimately required.  This may require a refetch from the lot
   of bandwidth, particularly for wireless devices with large documents
   (such as a resource list [11] with hundreds of users listed).

   To resolve this problem, this document defines a data format which
   can convey changes in XML documents managed by an XCAP server.  This
   data format is an XML document format, called an XCAP diff document.
   This specification also explains how this format is used in
   conjunction with the configuration profile framework.

2.  Structure of an XCAP Diff Document Change Event Package

   The SIP event framework

   An XCAP diff document is an XML [2] defines a SIP extension document that MUST be well-formed
   and SHOULD be valid.  XML-change documents MUST be based on XML 1.0
   and MUST be encoded using UTF-8.  This specification makes use of XML
   namespaces for subscribing
   to, identifying xml-change documents and receiving notifications of, events. It leaves document
   fragments.  The namespace URI for elements defined by this
   specification is a URN [3], using the definition
   of many aspects of these events to concrete extensions, known as
   event packages. namespace identifier 'ietf'
   defined by [5] and extended by [6].  This URN is:
      urn:ietf:params:xml:ns:xcap-diff

   An XCAP diff document qualifies as an event package. This
   section fills in begins with the information required for all event packages by
   RFC 3265.

2.1 Package Name root element tag <xcap-diff>.
   This element has a single mandatory attribute, "xcap-root".  The name
   value of this package attribute is "xcap-change". As specified in RFC 3265
   [2], this value appears the XCAP root URI in which the Event header field present changes
   have taken place.  A single XCAP diff document can only represent
   changes in
   SUBSCRIBE and NOTIFY requests.

2.2 Event Package Parameters documents within the same XCAP root.  The SIP event framework allows event packages to define additional
   parameters carried in content of the Event header field. This package defines
   <xcap-diff> element is a
   single event header parameter, called "doc-component", which sequence of <document> elements.  Each
   <document> element specifies changes in a particular specific document within
   the XCAP root.  It has three mandatory attributes - "new-etag",
   "previous-etag" and "doc-selector", and a single optional attribute,
   "hash".  The "doc-selector" identifies the specific document component within
   the XCAP root for which is changes are included.  Its content MUST be a
   relative path reference, with the base URL being equal to subscribed to. the XCAP
   root URL.  The request-URI specifies "previous-etag" and "new-etag" provide indentifiers
   for the user whose data document instance before the change, and then after the
   change.  These need not have been sequentially assigned etags at the
   server.  An XCAP diff document can describe changes that have
   occurred over a series of XCAP operations.

   The optional "hash" attribute provides an HMAC of the new document,
   represented in canonical form.  See Section 5 for details on how this
   value is
   being subscribed to. To subscribe to global data, computed.  This attribute is optional, and a user agent would
   subscribed server can
   elect not to include it.

   Each <document> element is followed by a special user name that series of operations, which
   if followed by the client, will convert the document whose etag is configured
   "previous-etag" into the UA. The
   name "global-xcap-user" one whose etag is RECOMMENDED, and SHOULD be used if no
   explicit user name "new-etag".  Each
   operation is provisioned. By default, specified by an XML element.  Six operations are
   defined:
   <add-element>: Instructs the recipient of the document to add an
      element.  The "parent" attribute contains a subscription is for
   all XCAP data associated with that user. node-selector which
      selects the parent of the new element.  The header field parameter
   allows "position" attribute
      indicates that the subscription new element is to specify be inserted as a specific document and document
   sub-tree. child such
      that it has that position amongst it siblings.  The format content of this header field parameter
      <add-element> MUST be a CDATA section enclosing a single XML
      element, which is to be added.

   <add-attribute>: Instructs the recipient of the document to add an
      attribute.  The "element" attribute contains a quoted string. node-selector which
      selects the element into which the attribute is to be inserted.
      The
   value "att-name" attribute contains the name of this string the new attribute.
      The content of <add-attribute> is the portion value of the new attribute.
   <remove-element>: Instructs the recipient of the document to delete
      an XCAP URI element.  The "element" attribute contains a node-selector
      which selects the element to be removed.
   <remove-attribute>: Instructs the right recipient of the directory for document to remove
      an attribute.  The "element" attribute contains a node-selector
      which selects the user, element in which the case attribute exists.  The
      "att-name" attribute indicates the name of user data, or the attribute which is
      to be removed.
   <replace-element>: Instructs the right recipient of the global directory for global data. The XCAP URI can only refer
   to a document or to replace
      an element.  The "element" attribute contains a node-selector
      which selects the element within that document. When to replace.  The content of the URI
   represents
      <replace-element> element MUST be a document, the subscription CDATA section containing
      single XML element which is to changes anywhere in replace the
   document. When it is one identified by the
      node-selector.
   <replace-attribute>: Instructs the recipient of the document to
      replace an element, attribute.  The "element" attribute contains a
      node-selector which selects the subscription is element to changes
   that occur in replace.  The
      "att-name" attribute contains the attributes or content name of that element, including
   all children. For example, if a user wishes to subscribe the attribute to http://
   xcap.example.com/services/presence-lists/users/joe/mydir/friends.xml,
      replace.  The content of the event header parameter would <replace-attribute> element is the
      value of the new attribute.

   When the node selector appears as an attribute value, any quotation
   marks MUST be "mydir/friends.xml".

      OPEN ISSUE: There replaced with &quot;.

   It is no way to specify that possible for the list of instructions for a subscription is <document> to
      multiple documents. Multiple subscriptions would be needed for
      that. Is that limitation OK for now? A filter can fix
   empty.  In that down case, the road.

2.3 SUBSCRIBE Bodies

   A SUBSCRIBE request MAY contain a body. The purpose of entity tag in the body
   depends on "new-etag" may equal the
   entity tag in the "previous-etag".  These entity tags may differ in
   the event that the document has changed entity tags, but its type. Subscriptions will normally content
   has not contain bodies. been altered.

3.  XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
    xmlns:tns="urn:ietf:params:xml:ns:xcap-diff"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="xcap-diff">
     <xs:complexType>
      <xs:sequence>
       <xs:element name="document" maxOccurs="unbounded">
        <xs:complexType>
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
          <xs:choice>
           <xs:element name="add-element">
            <xs:complexType>
             <xs:simpleContent>
              <xs:extension base="xs:string">
               <xs:attribute name="parent" type="xs:string" use="required"/>
               <xs:attribute name="position" type="xs:int" use="required"/>
              </xs:extension>
             </xs:simpleContent>
            </xs:complexType>
           </xs:element>
           <xs:element name="add-attribute">
            <xs:complexType>
             <xs:simpleContent>
              <xs:extension base="xs:string">
               <xs:attribute name="element" type="xs:string" use="required"/>
               <xs:attribute name="att-name" type="xs:string" use="required"/>
              </xs:extension>
             </xs:simpleContent>
            </xs:complexType>
           </xs:element>
           <xs:element name="remove-element">
            <xs:complexType>
             <xs:attribute name="element" type="xs:string" use="required"/>
            </xs:complexType>
           </xs:element>
           <xs:element name="remove-attribute">
            <xs:complexType>
             <xs:attribute name="element" type="xs:string" use="required"/>
             <xs:attribute name="att-name" type="xs:string" use="required"/>
            </xs:complexType>
           </xs:element>
           <xs:element name="replace-element">
            <xs:complexType>
             <xs:simpleContent>
              <xs:extension base="xs:string">
               <xs:attribute name="element" type="xs:string" use="required"/>
              </xs:extension>
             </xs:simpleContent>
            </xs:complexType>
           </xs:element>
           <xs:element name="replace-attribute">
            <xs:complexType>
             <xs:simpleContent>
              <xs:extension base="xs:string">
               <xs:attribute name="element" type="xs:string" use="required"/>
               <xs:attribute name="att-name" type="xs:string" use="required"/>
              </xs:extension>
             </xs:simpleContent>
            </xs:complexType>
           </xs:element>
          </xs:choice>
         </xs:sequence>
         <xs:attribute name="doc-selector" type="xs:anyURI" use="required"/>
         <xs:attribute name="new-etag" type="xs:string" use="required"/>
         <xs:attribute name="previous-etag" type="xs:string" use="required"/>
         <xs:attribute name="hash" type="xs:string" use="optional"/>
        </xs:complexType>
       </xs:element>
      </xs:sequence>
      <xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
     </xs:complexType>
    </xs:element>
   </xs:schema>

4.  Example Document

   The Request-URI, which identifies the user whose data following is being
   subscribed to, combined an example of a document compliant to the schema:

   <?xml version="1.0" encoding="UTF-8"?>
   <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <document doc-selector="resource-lists/users/joe/friends"
     new-etag="7hahsd" previous-etag="7hahsd"/>
    <document doc-selector="resource-lists/users/joe/coworkers"
     new-etag="ffds66a" previous-etag="xkkkaisu">
      <add-element parent="resource-lists/list[@name=&quot;l1&quot;]"
       position="1"><![CDATA[<entry uri="sip:new-worker@example.com"/>]
   ]></add-element>
    </document>
   </xcap-diff>

5.  Usage with the Config Framework

   The framework for user agent profile delivery [8] defines an event
   package name and parameter, is
   sufficient for this package.

   One type of body that which can be included in a SUBSCRIBE request is a
   filter document. These filters request that only document change
   events generate notifications, used to subscribe to user, device, application
   or would ask for a restriction on the
   set of local-network data.  This data returned can be present in an XCAP server.
   Normally, content indirection [14] will be used as the NOTIFY requests. Filter body
   format, to indicate the specific document that has changed, and
   should be re-fetched.  However, if the client includes an Accept
   header field including the MIME type "application/xcap-diff+xml", the
   server has the option of returning documents are not
   specified in this document, and at format instead.

   When the time of writing, client performs an initial subscription, the rules in [8]
   are expected used to be select the subject of future standardization activity.

   Honoring of these filters is at the policy discretion set of documents which the
   notifier.

   If subscription
   applies to.  Upon initial subscription, the SUBSCRIBE request server does not contain a filter, this tells the
   notifier that no filter know
   which instance (where each instance is to be applied. identified by an etag) the
   client currently posessses, if any.  Indeed, upon startup, the client
   will not have any documents.  The notifier SHOULD send initial NOTIFY requests at in this case MUST
   include a <document> element for each document associated with the discretion
   subscription.  The content of its own policy.

2.4 Subscription Duration

   Generally speaking, changes to application configuration data are
   relatively infrequent. Of course, this depends on each of those <document> elements MUST
   be empty.  The "previous-etag" and "new-etag" attributes MUST be
   identical, and contain the type entity tag for the current version of
   application, but generally configuration data that
   resource.  An XML diff document structured this way is static. As called a result,
   notifications are expected infrequently,
   "reference" XML diff document.  It establishes the baseline etags and subscriptions will
   typically be held
   document URIs for long periods the documents covered by the subscription.

   Upon receipt of time. This would argue for long
   subscription refresh intervals. For this reason, document, the default
   subscription duration is two hours. Of course, a different duration client can be requested by determine whether its
   local instance documents, if any, match the etags in the XCAP diff
   document.  If they do not match, the client SHOULD perform a client, or set
   conditional GET for each document.  The document URI is constructed
   by a server, using appending the XCAP root in the "xcap-root" attribute of the Expires
   <xcap-diff> element to the escape coded "doc-selector" from each
   <document> element.  The request is made conditional by including an
   If-Match header field, with the value of the etag from each
   <document> element.  So long as per RFC 3265 [2].

2.5 NOTIFY Bodies

   As described in RFC 3265 [2], the documents haven't changed between
   the NOTIFY message and the GET, the client will contain bodies obtain the reference versions
   that describe the state of server will use for subsequent notifications.

   If the subscribed resource. conditional GET should fail, the client SHOULD generate a
   SUBSCRIBE refresh request to trigger a new NOTIFY.  The server will
   always generate a "reference" XML diff document on receipt of a
   SUBSCRIBE refresh.  This body establish a new set of baseline etags, and
   the client can then attempt to do another fetch.  It is in anticipated
   that future extensions to the profile delivery framework will allow a
   format listed
   client to include, in its SUBSCRIBE request, an indicator of the Accept header field
   current version of the SUBSCRIBE, or documents it holds.  That would obviate the
   need for a
   package-specific default if potentially never-ending stream of SUBSCRIBE/GET sequences
   should the Accept header field was omitted from documents be rapidly changing, for some reason.

   Once the SUBSCRIBE.

   In this event package, client has obtained the body versions of the notification contains a
   document change document. This document describes documents identified
   in the reference XML diff, it can process NOTIFY requests on that
   subscription.  To process the NOTIFY requests, it makes sure that its
   current version
   of an XML document managed by XCAP, in addition to matches the changes version in
   this document from the previous version. Note that a listing "previous-etag" attribute
   of
   changes from the previous version is only sent <document> element.  It then follows the list of instructions,
   in order, for that <document>.  Specifically:
   <add-element>: The "parent" attribute contains a NOTIFY triggered
   by a change node-selector.  The
      client applies the node selector to the document. NOTIFY requests sent in response document according to an
   initial SUBSCRIBE, or a SUBSCRIBE refresh, only indicate the current
   version of
      procedures defined in XCAP [7].  If the XML document. They do not contain result is a single
      element, the actual full
   contents client takes the content of the XML document. In other words, <add-element> element
      and adds it as the resource being
   subscribed to is NOT position-th child.  If the XML document itself, but rather, node selector doesnt
      select a single element, or the version
   history for selected element has fewer than
      position-1 children already, the document.

      OPEN ISSUE: This result is the main issue in this specification. There
      are three potential scopes. an error.  The first is that subscription is to client
      MUST discard the XCAP-diff document, and MUST flush its current
      version of the document itself, in which case from memory.  It can then obtain a full state update in new XML
      diff reference by sending a NOTIFY
      contains SUBSCRIBE refresh request on the current document.
      dialog.
   <add-attribute>: The second is "element" attribute contains a subscription node-selector.
      The client applies the node selector to the
      revision history, which gives you changes, but not document according to
      the full state
      of procedures defined in XCAP [7].  If the document. The third option result is to just subscribe to a single
      element, the
      etag, so that you know that something changed, but client takes adds a new attribute to the
      notifications don't tell you anything about what changed. Which do
      we need? The latter is element,
      with the simplest, good for name equal to the case where third
      party modification content of documents is rare.

   All subscribers and notifiers MUST support the "application/
   xcap-change+xml" data format described in Section 3. The subscribe
   request MAY contain an Accept header field. If no such header field
   is present, it has "att-name" attribute,
      and a default value equal to the content of "application/xcap-change+xml". the <add-attribute> element.
      If the header field node selector doesnt select a single element, or the
      selected element already has an attribute with that name, the
      result is present, it an error.  The client MUST include "application/
   xcap-change+xml", discard the XCAP-diff
      document, and MAY include any other types capable of
   representing changes in XCAP documents.

2.6 Notifier Processing MUST flush its current version of SUBSCRIBE Requests

   This subsection defines package-specific processing at the notifier
   when it receives document from
      memory.  It can then obtain a SUBSCRIBE request. General processing rules for
   requests are covered in Section 8.2 of RFC 3261 [1], in addition to
   general SUBSCRIBE processing in RFC 3265 [2].

   A notifier for this package SHOULD authenticate all subscribers.
   Generally, subscribers will have new XML diff reference by sending a pre-existing relationship with the
   notifier. This is because
      SUBSCRIBE refresh request on the principle application of this package
   is for dialog.
   <remove-element>: The "element" attribute contains a node-selector.
      The client of XCAP (which will have a relationship with applies the XCAP
   server) node selector to find out about changes in cached documents. Therefore, the
   HTTP Digest mechanism document according to
      the procedures defined in SIP XCAP [7].  If the result is a good match for authentication, and
   MUST be supported by all clients and servers. Note single
      element, the client removes that this
   authentication mechanism is already mandatory for all SIP-compliant
   implementations.

   Once authenticated, element from the server SHOULD authorize document.  If
      the subscriber.
   Generally, this authorization policy SHOULD mirror node selector doesnt select a single element the authorization
   policy defined in result is an XCAP application usage for read access. Thats
   because this package provides a form of read-access,
      error.  The client MUST discard the XCAP-diff document, and MUST
      flush its current version of the
   permissions should not differ based document from memory.  It can
      then obtain a new XML diff reference by sending a SUBSCRIBE
      refresh request on whether the read is performed
   with XCAP or with dialog.
   <remove-attribute>: The "element" attribute contains a SIP SUBSCRIBE request.

2.7 Notifier Generation of NOTIFY Requests

   RFC 3265 details node-selector.
      The client applies the formatting and structure of NOTIFY messages.
   However, packages are mandated node selector to provide detailed information on
   when the document according to send
      the procedures defined in XCAP [7].  If the result is a NOTIFY, how to compute single
      element, the state of client removes the resource, how
   to generate neutral or fake state information, and whether state
   information attribute whose name is complete or partial. This section describes those
   details for
      "att-name".  If the presence event package.

   A notifier MAY send a notification at any time. Typically, it will
   send one after node selector doesnt select a document managed by single element,
      or the selected element doesn't have an XCAP server has changed as attribute with that name,
      the result of an XCAP operation. This notification contains is an
   application/xcap-change+xml document that specifies error.  The client MUST discard the XCAP-diff
      document, and MUST flush its current version (as a server modification time) for of the XML document being
   subscribed to. from
      memory.  It also contains information about what changed -
   whether can then obtain a new element or attribute was added, whether an existing one
   changed, or whether an existing one was deleted, and indicates
   against which version those changes were made. XML diff reference by sending a
      SUBSCRIBE refresh request on the dialog.

   <replace-element>: The xcap-change
   document also "element" attribute contains a hash of node-selector.
      The client applies the new XML document.

   Notifications sent in response node selector to SUBSCRIBE requests (either initial
   or refresh), or sent when there is a change in subscription state,
   will normally only contain the current version of the XML document
   being subscribed to.

   The body of the NOTIFY MUST be sent using one of according to
      the types listed procedures defined in XCAP [7].  If the Accept header field in result is a single
      element, the most recent SUBSCRIBE request, or
   using client removes that element, and replaces it with the type "application/xcap-change+xml" if no Accept header
   field was present.

2.8 Subscriber Processing
      content of NOTIFY Requests

   RFC 3265 [2] leaves it to event packages to describe the process
   followed by <add-element> element.  If the subscriber upon receipt of node selector doesnt
      select a NOTIFY request,
   including any logic required to form a coherent resource state.

   In this package, the notifications can be optionally used by single element, the result is an error.  The client to determine MUST
      discard the state XCAP-diff document, and MUST flush its current version
      of the XML document being subscribed
   to. When from memory.  It can then obtain a client receives new XML diff
      reference by sending a notification, it checks SUBSCRIBE refresh request on the version
   against which dialog.
   <replace-attribute>: The "element" attribute contains a
      node-selector.  The client applies the changes are relative. If this is not node selector to the same as
      document according to the version currently cached by procedures defined in XCAP [7].  If the client,
      result is a single element, the client SHOULD use
   XCAP to fetch removes the latest version content of the document. If it
      attribute whose name is "att-name", and replaces it with the same,
      content of the <replace-attribute> element.  If the node selector
      doesnt select a single element, or the selected element doesn't
      have an attribute with that name, the result is an error.  The
      client applies MUST discard the change to XCAP-diff document, and MUST flush its local cache
      current version of the document. To
   apply document from memory.  It can then obtain a
      new XML diff reference by sending a SUBSCRIBE refresh request on
      the changes, dialog.

   Once the client follows has finished applying the procedures defined by XCAP
   [10] as if instructions to the
   document, it were should end up with the HTTP server. After applying same document the changes, server has.  To
   verify this, the client applies the mandatory XML canonicalization
   defined in the Canonical XML 1.0 [3] [1] specification, and computes an
   HMAC [12] using SHA1 over this canonical document, with a key whose
   value is 0x2238a.  The resulting string is compared with the hash "hash"
   attribute of the
   xml-change document. <document> element.  If they match, the client can
   be sure that it has the most up to date version.  If they don't
   match, the client
   SHOULD fetch the most MUST flush its current version of the document. document from
   memory.  It can then obtain a new XML diff reference by sending a
   SUBSCRIBE refresh request on the dialog.

   Of course, this mechanism for computing the most current document
   from the hash is optional.  A client can elect to ignore the
   information on what changed and simply fetch the most recent document
   every time it gets a change indication where the new version is not
   the same as the one cached by the client.

2.9 Handling of Forked Requests

   RFC 3265 [2] requires each package to describe handling of forked
   SUBSCRIBE requests.

   This specification only allows a single dialog to be constructed as a
   result of emitting an initial SUBSCRIBE request. Section 4.4.9 of RFC
   3265 [2] describes  Furthermore, the processing that is required server
   may elect to guarantee not send the
   creation of a single dialog hash, in response to a SUBSCRIBE request.

2.10 Rate of Notifications

   RFC 3265 [2] requires each package to specify the maximum rate at which notifications can be sent. A notifier SHOULD NOT generate
   notifications at a rate of more than once every five seconds.

2.11 State Agents

   RFC 3265 [2] requires each package to consider the role of state
   agents in the package, and if they are used, to specify how
   authentication and authorization are done.

   State agents play no role in case this package.

3. application/xml-change+xml Media Type

   An xml-change document is an XML [4] document that MUST be
   well-formed and SHOULD be valid. XML-change documents MUST check cannot be based
   on XML 1.0 and MUST be encoded using UTF-8. This specification makes
   use of XML namespaces for identifying xml-change
   made.

6.  Security Considerations

   XCAP diff documents and
   document fragments. The namespace URI for elements defined by this
   specification is a URN [5], using the namespace identifier 'ietf'
   defined by [7] and extended by [8]. This URN is:

      urn:ietf:params:xml:ns:xml-change

   An xml-change document begins with the root element tag "documents".
   It consists of any number of "document" sub-elements, each of which
   conveys information on a particular document. Other elements from
   different namespaces MAY be present for contain the purposes of
   extensibility; elements or attributes from unknown namespaces MUST be
   ignored.

   Each "document" element consists of zero or more "change" elements,
   each of which conveys same information about a specific change to the
   document. Other elements from different namespaces MAY be present for
   the purposes of extensibility; elements or attributes from unknown
   namespaces MUST be ignored. There are four attributes associated with
   the "document" element:

   uri: specifies the HTTP URI that identifies the document.

   new-etag: specifies the etag of the document after the application of
      the change. This attribute is mandatory.

   previous-etag: specifies the etag of the version of the document
      against which the change was made. This attribute MUST be present
      if any change sub-elements are present.

   hash: specifies an HMAC of the new document, represented in canonical
      form. See Section 2.8 for details on how this value is computed.
      This attribute MUST be present if any change sub-elements are
      present.

   Each "change" element contains text. This text contains the exact
   value present in the HTTP request that caused the change in the
   document. If that content was XML, it is represented in the
   xml-change document as CDATA. There are two attributes associated
   with this element:

   uri: contains the URI that the HTTP request contained in the
      Request-URI. This attribute is mandatory.

   method: contains the method of the HTTP request. This attribute is
      mandatory.

      OPEN ISSUE: Probably it would be better to describe the changes
      more generically, rather than binding them to the specifics of
      XCAP. Indeed, if there is any non-determinism in how the server
      computes the document resulting from an XCAP operation, this
      approach will not work. We can either use patch or define a
      specific XML patch format.

3.1 XML Schema

   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema targetNamespace="urn:ietf:params:xml:ns:xml-change"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:tns="urn:ietf:params:xml:ns:xml-change"
   elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:element name="documents">
     <xs:complexType>
      <xs:sequence>
       <xs:element name="tns:document" maxOccurs="unbounded">
        <xs:complexType>
         <xs:sequence>
          <xs:element name="tns:change" type="xs:string" maxOccurs="unbounded"/>
          <xs:any namespace="##other" processContents="lax" minOccurs="0"
            maxOccurs="unbounded"/>
         </xs:sequence>
         <xs:attribute name="tns:uri" type="xs:anyURI" use="required"/>
         <xs:attribute name="tns:new-etag" type="xs:string" use="required"/>
         <xs:attribute name="tns:previous-etag" type="xs:string" use="optional"/>
         <xs:attribute name="tns:hash" type="xs:string" use="optional"/>
        </xs:complexType>
       </xs:element>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
        maxOccurs="unbounded"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>
    <xs:simpleType name="httpMethod">
     <xs:restriction base="xs:string">
      <xs:enumeration value="PUT"/>
      <xs:enumeration value="DELETE"/>
     </xs:restriction>
    </xs:simpleType>
   </xs:schema>

3.2 Example Document

   The following is an example of a document compliant to documents
   whose differences they describe.  As such, the schema:

   <?xml version="1.0" encoding="UTF-8"?>
   <documents xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <document
        uri="http://xcap.example.com/s/presence-lists/users/bill/foo.xml"
        new-etag="asdnasd9asd8asd7"
        previous-etag="s99s99s9s9sjja"
        hash="<hash value>">
       <change method="DELETE"
        uri="http://xcap.example.com/s/presence-lists/
        users/bill/foo.xml?presence-lists/entry[@name="bob"]/uri"/>
     </document>
   </documents>

4. Security Considerations

   The security
   considerations for this package are similar to associated with those of
   XCAP. The configuration data can contain sensitive information, and
   both the client and the server need to authenticate each other. As
   such, a notifier for this package MUST support HTTP Digest to
   authenticate subscribers. Notifiers and subscribers MAY use SIPs S/
   MIME feature documents apply to provide authentication and message integrity.

5. XCAP diff
   documents.

7.  IANA Considerations

   There are several IANA considerations associated with this
   specification.

5.1 SIP Event Package

   This specification registers an event package, based on the
   registration procedures defined in RFC 3265 [2]. The following is the
   information required for such a registration:

   Package Name: xml-change

   Package or Template-Package: This is a package.

   Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX
      with the RFC number of this specification).

   Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.

5.2 application/xcap-change+xml

7.1  application/xcap-diff+xml MIME Type
      MIME media type name: application
      MIME subtype name: xcap-change+xml xcap-diff+xml
      Mandatory parameters: none
      Optional parameters: Same as charset parameter application/xml as
      specified in RFC 3023 [6]. [4].
      Encoding considerations: Same as encoding considerations of
      application/xml as specified in RFC 3023 [6]. [4].
      Security considerations: See Section 10 of RFC 3023 [6] [4] and
      Section 4 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
      XXXX with the RFC number of this specification. specification.]].
      Interoperability considerations: none.
      Published specification: This document.
      Applications which use this media type: This document type has
      been used to support manipulation of presence resource lists [13] using
      XCAP.
      Additional Information:
         Magic Number: None
         File Extension: .xcd .xdf or .xml
         Macintosh file type code: "TEXT"
         Personal and email address for further information: Jonathan
         Rosenberg, jdrosen@jdrosen.net
         Intended usage: COMMON
         Author/Change controller: The IETF.

5.3

7.2  URN Sub-Namespace Registration for
    urn:ietf:params:xml:ns:xcap-change urn:ietf:params:xml:ns:xcap-diff

   This section registers a new XML namespace, as per the guidelines in
   [8]
   [6]
      URI: The URI for this namespace is
      urn:ietf:params:xml:ns:xcap-change.
      urn:ietf:params:xml:ns:xcap-diff.
      Registrant Contact: IETF, SIMPLE working group,
      (simple@mailman.dynamicsoft.com), (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).
      XML:

                BEGIN
                <?xml version="1.0"?>
                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
                <html xmlns="http://www.w3.org/1999/xhtml">
                <head>
                  <meta http-equiv="content-type"
                     content="text/html;charset=iso-8859-1"/>
                  <title>XCAP Change Diff Namespace</title>
                </head>
                <body>
                  <h1>Namespace for XCAP Change</h1>
                  <h2>urn:ietf:params:xml:ns:change-xml</h2> Diff</h1>
                  <h2>urn:ietf:params:xml:ns:xcap-diff</h2>
                  <p>See <a href="[[[URL href="[URL of published RFC]]]">RFCXXXX</a>.</p> RFC]">RFCXXXX[[NOTE
   TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
   specification.]]</a>.</p>
                </body>
                </html>
                END

7.3  Schema Registration

   This section registers a new XML schema per the procedures in [6].
      URI: urn:ietf:params:xml:schema:xcap-diff
      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
      Jonathan Rosenberg (jdrosen@jdrosen.net).
      The XML for this schema can be found as the sole content of
      Section 3.

8.  References

8.1  Normative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

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

   [3]  Boyer, J., "Canonical XML Version 1.0", W3C REC
        REC-xml-c14n-20010315, March 2001.

   [4]

   [2]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
        "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
        FirstEdition REC-xml-20001006, October 2000.

   [5]

   [3]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [6]

   [4]  Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
        3023, January 2001.

   [7]

   [5]  Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
        August 1999.

   [8]

   [6]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
        2004.

   [9]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [10]

   [7]  Rosenberg, J., "The Extensible Markup Language (XML)
        Configuration Access Protocol (XCAP)",
         draft-ietf-simple-xcap-01 draft-ietf-simple-xcap-02
        (work in progress), October 2003. February 2004.

   [8]  Petrie, D., "A Framework for Session Initiation Protocol User
        Agent Profile Delivery", draft-ietf-sipping-config-framework-03
        (work in progress), May 2004.

8.2  Informative References

   [9]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

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

   [11]  Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
         Protocol (SIP) Event Notification Extension for  Resource
         Lists", draft-ietf-simple-event-list-04 (work in progress),
         June 2003.

   [12]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
         for Message Authentication", RFC 2104, February 1997.

   [13]  Rosenberg, J., "An Extensible Markup Language (XML)
         Configuration Access Protocol (XCAP)  Usage for Presence
         Lists", draft-ietf-simple-xcap-list-usage-01 draft-ietf-simple-xcap-list-usage-02 (work in
         progress), October February 2004.

   [14]  Olson, S., "A Mechanism for Content Indirection in Session
         Initiation Protocol (SIP)  Messages",
         draft-ietf-sip-content-indirect-mech-03 (work in progress),
         June 2003.

Author's Address

   Jonathan Rosenberg
   dynamicsoft
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   EMail: jdrosen@dynamicsoft.com
   URI:   http://www.jdrosen.net

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.

Disclaimer of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees. Validity

   This document and the information contained herein is 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 DISCLAIMS 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 (2004).  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.