idnits 2.17.00 (12 Aug 2021)

/tmp/idnits48627/draft-ietf-simple-xcap-package-02.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3667, Section 5.1 on line 14.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 601.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 578.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 585.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 591.

  ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
     607), which is fine, but *also* found old RFC 2026, Section 10.4C,
     paragraph 1 text on line 36.

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement -- however, there's a paragraph with a matching
     beginning. Boilerplate error?

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.

  ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
     instead of verbatim RFC 3978 boilerplate.  After 6 May 2005, submission
     of drafts without verbatim RFC 3978 boilerplate is not accepted.

     The following non-3978 patterns matched text found in the document. 
     That text should be removed or replaced:

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


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There are 13 instances of too long lines in the document, the longest
     one being 7 characters in excess of 72.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

     RFC 2119 keyword, line 110: '...   An XCAP diff document is an XML [2] document that MUST be well-formed...'
     RFC 2119 keyword, line 111: '...   and SHOULD be valid.  XML-change do...'
     RFC 2119 keyword, line 112: '...   and MUST be encoded using UTF-8.  T...'
     RFC 2119 keyword, line 129: '...s are included.  Its content MUST be a...'
     RFC 2119 keyword, line 152: '...   <add-element> MUST be a CDATA secti...'
     (17 more instances...)


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (July 18, 2004) is 6515 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. '1'

  -- Possible downref: Non-RFC (?) normative reference: ref. '2'

  ** Obsolete normative reference: RFC 2141 (ref. '3') (Obsoleted by RFC 8141)

  ** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303)

  ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '5')

  == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825

  == Outdated reference: draft-ietf-sipping-config-framework has been
     published as RFC 6080

  -- Obsolete informational reference (is this intentional?): RFC 3265 (ref.
     '10') (Obsoleted by RFC 6665)

  == Outdated reference: draft-ietf-simple-event-list has been published as
     RFC 4662

  == Outdated reference: draft-ietf-simple-xcap-list-usage has been published
     as RFC 4826

  == Outdated reference: draft-ietf-sip-content-indirect-mech has been
     published as RFC 4483


     Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	SIMPLE                                                      J. Rosenberg
2	Internet-Draft                                               dynamicsoft
3	Expires: January 16, 2005                                  July 18, 2004

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

9	Status of this Memo

11	   By submitting this Internet-Draft, I certify that any applicable
12	   patent or other IPR claims of which I am aware have been disclosed,
13	   and any of which I become aware will be disclosed, in accordance with
14	   RFC 3668.

16	   Internet-Drafts are working documents of the Internet Engineering
17	   Task Force (IETF), its areas, and its working groups.  Note that
18	   other groups may also distribute working documents as
19	   Internet-Drafts.

21	   Internet-Drafts are draft documents valid for a maximum of six months
22	   and may be updated, replaced, or obsoleted by other documents at any
23	   time.  It is inappropriate to use Internet-Drafts as reference
24	   material or to cite them other than as "work in progress."

26	   The list of current Internet-Drafts can be accessed at
27	   http://www.ietf.org/ietf/1id-abstracts.txt.

29	   The list of Internet-Draft Shadow Directories can be accessed at
30	   http://www.ietf.org/shadow.html.

32	   This Internet-Draft will expire on January 16, 2005.

34	Copyright Notice

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

38	Abstract

40	   This specification defines a document format that can be used to
41	   describe the differences between versions of resources managed by the
42	   Extensible Markup Language (XML) Configuration Access Protocol
43	   (XCAP).  Documents of this format can be delivered to clients using a
44	   number of means, including the Session Initiation Protocol (SIP)
45	   event package for configuration data.  By subscribing to this event
46	   package, clients can learn about document changes made by other
47	   clients.

49	Table of Contents

51	   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
52	   2.  Structure of an XCAP Diff Document . . . . . . . . . . . . . .  4
53	   3.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  6
54	   4.  Example Document . . . . . . . . . . . . . . . . . . . . . . .  8
55	   5.  Usage with the Config Framework  . . . . . . . . . . . . . . .  9
56	   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
57	   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
58	     7.1   application/xcap-diff+xml MIME Type  . . . . . . . . . . . 13
59	     7.2   URN Sub-Namespace Registration for
60	           urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 13
61	     7.3   Schema Registration  . . . . . . . . . . . . . . . . . . . 14
62	   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
63	   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 15
64	   8.2   Informative References . . . . . . . . . . . . . . . . . . . 15
65	       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
66	       Intellectual Property and Copyright Statements . . . . . . . . 17

68	1.  Introduction

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

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

91	   To deal with this problem, clients can use the Session Initiation
92	   Protocol (SIP) [9]event package [10] for subscribing to changes in
93	   configuration and profile information [8], including application data
94	   that resides on an XCAP server.  With that package, a user gets
95	   notified that a particular document has changed.  This notification
96	   can include the full content of the new document, or it can be a
97	   content indirection [14].  However, in both cases, the transfer of
98	   the entire document is ultimately required.  This may require a lot
99	   of bandwidth, particularly for wireless devices with large documents
100	   (such as a resource list [11] with hundreds of users listed).

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

108	2.  Structure of an XCAP Diff Document

110	   An XCAP diff document is an XML [2] document that MUST be well-formed
111	   and SHOULD be valid.  XML-change documents MUST be based on XML 1.0
112	   and MUST be encoded using UTF-8.  This specification makes use of XML
113	   namespaces for identifying xml-change documents and document
114	   fragments.  The namespace URI for elements defined by this
115	   specification is a URN [3], using the namespace identifier 'ietf'
116	   defined by [5] and extended by [6].  This URN is:
117	      urn:ietf:params:xml:ns:xcap-diff

119	   An XCAP diff document begins with the root element tag <xcap-diff>.
120	   This element has a single mandatory attribute, "xcap-root".  The
121	   value of this attribute is the XCAP root URI in which the changes
122	   have taken place.  A single XCAP diff document can only represent
123	   changes in documents within the same XCAP root.  The content of the
124	   <xcap-diff> element is a sequence of <document> elements.  Each
125	   <document> element specifies changes in a specific document within
126	   the XCAP root.  It has three mandatory attributes - "new-etag",
127	   "previous-etag" and "doc-selector", and a single optional attribute,
128	   "hash".  The "doc-selector" identifies the specific document within
129	   the XCAP root for which changes are included.  Its content MUST be a
130	   relative path reference, with the base URL being equal to the XCAP
131	   root URL.  The "previous-etag" and "new-etag" provide indentifiers
132	   for the document instance before the change, and then after the
133	   change.  These need not have been sequentially assigned etags at the
134	   server.  An XCAP diff document can describe changes that have
135	   occurred over a series of XCAP operations.

137	   The optional "hash" attribute provides an HMAC of the new document,
138	   represented in canonical form.  See Section 5 for details on how this
139	   value is computed.  This attribute is optional, and a server can
140	   elect not to include it.

142	   Each <document> element is followed by a series of operations, which
143	   if followed by the client, will convert the document whose etag is
144	   "previous-etag" into the one whose etag is "new-etag".  Each
145	   operation is specified by an XML element.  Six operations are
146	   defined:
147	   <add-element>: Instructs the recipient of the document to add an
148	      element.  The "parent" attribute contains a node-selector which
149	      selects the parent of the new element.  The "position" attribute
150	      indicates that the new element is to be inserted as a child such
151	      that it has that position amongst it siblings.  The content of
152	      <add-element> MUST be a CDATA section enclosing a single XML
153	      element, which is to be added.

155	   <add-attribute>: Instructs the recipient of the document to add an
156	      attribute.  The "element" attribute contains a node-selector which
157	      selects the element into which the attribute is to be inserted.
158	      The "att-name" attribute contains the name of the new attribute.
159	      The content of <add-attribute> is the value of the new attribute.
160	   <remove-element>: Instructs the recipient of the document to delete
161	      an element.  The "element" attribute contains a node-selector
162	      which selects the element to be removed.
163	   <remove-attribute>: Instructs the recipient of the document to remove
164	      an attribute.  The "element" attribute contains a node-selector
165	      which selects the element in which the attribute exists.  The
166	      "att-name" attribute indicates the name of the attribute which is
167	      to be removed.
168	   <replace-element>: Instructs the recipient of the document to replace
169	      an element.  The "element" attribute contains a node-selector
170	      which selects the element to replace.  The content of the
171	      <replace-element> element MUST be a CDATA section containing
172	      single XML element which is to replace the one identified by the
173	      node-selector.
174	   <replace-attribute>: Instructs the recipient of the document to
175	      replace an attribute.  The "element" attribute contains a
176	      node-selector which selects the element to replace.  The
177	      "att-name" attribute contains the name of the attribute to
178	      replace.  The content of the <replace-attribute> element is the
179	      value of the new attribute.

181	   When the node selector appears as an attribute value, any quotation
182	   marks MUST be replaced with &quot;.

184	   It is possible for the list of instructions for a <document> to be
185	   empty.  In that case, the entity tag in the "new-etag" may equal the
186	   entity tag in the "previous-etag".  These entity tags may differ in
187	   the event that the document has changed entity tags, but its content
188	   has not been altered.

190	3.  XML Schema

192	   <?xml version="1.0" encoding="UTF-8"?>
193	   <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-diff"
194	    xmlns:tns="urn:ietf:params:xml:ns:xcap-diff"
195	    xmlns:xs="http://www.w3.org/2001/XMLSchema"
196	    elementFormDefault="qualified" attributeFormDefault="unqualified">
197	    <xs:element name="xcap-diff">
198	     <xs:complexType>
199	      <xs:sequence>
200	       <xs:element name="document" maxOccurs="unbounded">
201	        <xs:complexType>
202	         <xs:sequence minOccurs="0" maxOccurs="unbounded">
203	          <xs:choice>
204	           <xs:element name="add-element">
205	            <xs:complexType>
206	             <xs:simpleContent>
207	              <xs:extension base="xs:string">
208	               <xs:attribute name="parent" type="xs:string" use="required"/>
209	               <xs:attribute name="position" type="xs:int" use="required"/>
210	              </xs:extension>
211	             </xs:simpleContent>
212	            </xs:complexType>
213	           </xs:element>
214	           <xs:element name="add-attribute">
215	            <xs:complexType>
216	             <xs:simpleContent>
217	              <xs:extension base="xs:string">
218	               <xs:attribute name="element" type="xs:string" use="required"/>
219	               <xs:attribute name="att-name" type="xs:string" use="required"/>
220	              </xs:extension>
221	             </xs:simpleContent>
222	            </xs:complexType>
223	           </xs:element>
224	           <xs:element name="remove-element">
225	            <xs:complexType>
226	             <xs:attribute name="element" type="xs:string" use="required"/>
227	            </xs:complexType>
228	           </xs:element>
229	           <xs:element name="remove-attribute">
230	            <xs:complexType>
231	             <xs:attribute name="element" type="xs:string" use="required"/>
232	             <xs:attribute name="att-name" type="xs:string" use="required"/>
233	            </xs:complexType>
234	           </xs:element>
235	           <xs:element name="replace-element">
236	            <xs:complexType>
237	             <xs:simpleContent>
238	              <xs:extension base="xs:string">
239	               <xs:attribute name="element" type="xs:string" use="required"/>
240	              </xs:extension>
241	             </xs:simpleContent>
242	            </xs:complexType>
243	           </xs:element>
244	           <xs:element name="replace-attribute">
245	            <xs:complexType>
246	             <xs:simpleContent>
247	              <xs:extension base="xs:string">
248	               <xs:attribute name="element" type="xs:string" use="required"/>
249	               <xs:attribute name="att-name" type="xs:string" use="required"/>
250	              </xs:extension>
251	             </xs:simpleContent>
252	            </xs:complexType>
253	           </xs:element>
254	          </xs:choice>
255	         </xs:sequence>
256	         <xs:attribute name="doc-selector" type="xs:anyURI" use="required"/>
257	         <xs:attribute name="new-etag" type="xs:string" use="required"/>
258	         <xs:attribute name="previous-etag" type="xs:string" use="required"/>
259	         <xs:attribute name="hash" type="xs:string" use="optional"/>
260	        </xs:complexType>
261	       </xs:element>
262	      </xs:sequence>
263	      <xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
264	     </xs:complexType>
265	    </xs:element>
266	   </xs:schema>

268	4.  Example Document

270	   The following is an example of a document compliant to the schema:

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

285	5.  Usage with the Config Framework

287	   The framework for user agent profile delivery [8] defines an event
288	   package which can be used to subscribe to user, device, application
289	   or local-network data.  This data can be present in an XCAP server.
290	   Normally, content indirection [14] will be used as the NOTIFY body
291	   format, to indicate the specific document that has changed, and
292	   should be re-fetched.  However, if the client includes an Accept
293	   header field including the MIME type "application/xcap-diff+xml", the
294	   server has the option of returning documents in this format instead.

296	   When the client performs an initial subscription, the rules in [8]
297	   are used to select the set of documents which the subscription
298	   applies to.  Upon initial subscription, the server does not know
299	   which instance (where each instance is identified by an etag) the
300	   client currently posessses, if any.  Indeed, upon startup, the client
301	   will not have any documents.  The initial NOTIFY in this case MUST
302	   include a <document> element for each document associated with the
303	   subscription.  The content of each of those <document> elements MUST
304	   be empty.  The "previous-etag" and "new-etag" attributes MUST be
305	   identical, and contain the entity tag for the current version of that
306	   resource.  An XML diff document structured this way is called a
307	   "reference" XML diff document.  It establishes the baseline etags and
308	   document URIs for the documents covered by the subscription.

310	   Upon receipt of this document, the client can determine whether its
311	   local instance documents, if any, match the etags in the XCAP diff
312	   document.  If they do not match, the client SHOULD perform a
313	   conditional GET for each document.  The document URI is constructed
314	   by appending the XCAP root in the "xcap-root" attribute of the
315	   <xcap-diff> element to the escape coded "doc-selector" from each
316	   <document> element.  The request is made conditional by including an
317	   If-Match header field, with the value of the etag from each
318	   <document> element.  So long as the documents haven't changed between
319	   the NOTIFY and the GET, the client will obtain the reference versions
320	   that the server will use for subsequent notifications.

322	   If the conditional GET should fail, the client SHOULD generate a
323	   SUBSCRIBE refresh request to trigger a new NOTIFY.  The server will
324	   always generate a "reference" XML diff document on receipt of a
325	   SUBSCRIBE refresh.  This establish a new set of baseline etags, and
326	   the client can then attempt to do another fetch.  It is anticipated
327	   that future extensions to the profile delivery framework will allow a
328	   client to include, in its SUBSCRIBE request, an indicator of the
329	   current version of the documents it holds.  That would obviate the
330	   need for a potentially never-ending stream of SUBSCRIBE/GET sequences
331	   should the documents be rapidly changing, for some reason.

333	   Once the client has obtained the versions of the documents identified
334	   in the reference XML diff, it can process NOTIFY requests on that
335	   subscription.  To process the NOTIFY requests, it makes sure that its
336	   current version matches the version in the "previous-etag" attribute
337	   of the <document> element.  It then follows the list of instructions,
338	   in order, for that <document>.  Specifically:
339	   <add-element>: The "parent" attribute contains a node-selector.  The
340	      client applies the node selector to the document according to the
341	      procedures defined in XCAP [7].  If the result is a single
342	      element, the client takes the content of the <add-element> element
343	      and adds it as the position-th child.  If the node selector doesnt
344	      select a single element, or the selected element has fewer than
345	      position-1 children already, the result is an error.  The client
346	      MUST discard the XCAP-diff document, and MUST flush its current
347	      version of the document from memory.  It can then obtain a new XML
348	      diff reference by sending a SUBSCRIBE refresh request on the
349	      dialog.
350	   <add-attribute>: The "element" attribute contains a node-selector.
351	      The client applies the node selector to the document according to
352	      the procedures defined in XCAP [7].  If the result is a single
353	      element, the client takes adds a new attribute to the element,
354	      with the name equal to the content of the "att-name" attribute,
355	      and a value equal to the content of the <add-attribute> element.
356	      If the node selector doesnt select a single element, or the
357	      selected element already has an attribute with that name, the
358	      result is an error.  The client MUST discard the XCAP-diff
359	      document, and MUST flush its current version of the document from
360	      memory.  It can then obtain a new XML diff reference by sending a
361	      SUBSCRIBE refresh request on the dialog.
362	   <remove-element>: The "element" attribute contains a node-selector.
363	      The client applies the node selector to the document according to
364	      the procedures defined in XCAP [7].  If the result is a single
365	      element, the client removes that element from the document.  If
366	      the node selector doesnt select a single element the result is an
367	      error.  The client MUST discard the XCAP-diff document, and MUST
368	      flush its current version of the document from memory.  It can
369	      then obtain a new XML diff reference by sending a SUBSCRIBE
370	      refresh request on the dialog.
371	   <remove-attribute>: The "element" attribute contains a node-selector.
372	      The client applies the node selector to the document according to
373	      the procedures defined in XCAP [7].  If the result is a single
374	      element, the client removes the attribute whose name is
375	      "att-name".  If the node selector doesnt select a single element,
376	      or the selected element doesn't have an attribute with that name,
377	      the result is an error.  The client MUST discard the XCAP-diff
378	      document, and MUST flush its current version of the document from
379	      memory.  It can then obtain a new XML diff reference by sending a
380	      SUBSCRIBE refresh request on the dialog.

382	   <replace-element>: The "element" attribute contains a node-selector.
383	      The client applies the node selector to the document according to
384	      the procedures defined in XCAP [7].  If the result is a single
385	      element, the client removes that element, and replaces it with the
386	      content of the <add-element> element.  If the node selector doesnt
387	      select a single element, the result is an error.  The client MUST
388	      discard the XCAP-diff document, and MUST flush its current version
389	      of the document from memory.  It can then obtain a new XML diff
390	      reference by sending a SUBSCRIBE refresh request on the dialog.
391	   <replace-attribute>: The "element" attribute contains a
392	      node-selector.  The client applies the node selector to the
393	      document according to the procedures defined in XCAP [7].  If the
394	      result is a single element, the client removes the content of the
395	      attribute whose name is "att-name", and replaces it with the
396	      content of the <replace-attribute> element.  If the node selector
397	      doesnt select a single element, or the selected element doesn't
398	      have an attribute with that name, the result is an error.  The
399	      client MUST discard the XCAP-diff document, and MUST flush its
400	      current version of the document from memory.  It can then obtain a
401	      new XML diff reference by sending a SUBSCRIBE refresh request on
402	      the dialog.

404	   Once the client has finished applying the instructions to the
405	   document, it should end up with the same document the server has.  To
406	   verify this, the client applies the mandatory XML canonicalization
407	   defined in the Canonical XML 1.0 [1] specification, and computes an
408	   HMAC [12] using SHA1 over this canonical document, with a key whose
409	   value is 0x2238a.  The resulting string is compared with the "hash"
410	   attribute of the <document> element.  If they match, the client can
411	   be sure that it has the most up to date version.  If they don't
412	   match, the client MUST flush its current version of the document from
413	   memory.  It can then obtain a new XML diff reference by sending a
414	   SUBSCRIBE refresh request on the dialog.

416	   Of course, this mechanism for computing the most current document
417	   from the hash is optional.  A client can elect to ignore the
418	   information on what changed and simply fetch the most recent document
419	   every time it gets a change indication where the new version is not
420	   the same as the one cached by the client.  Furthermore, the server
421	   may elect to not send the hash, in which case this check cannot be
422	   made.

424	6.  Security Considerations

426	   XCAP diff documents contain the same information in the documents
427	   whose differences they describe.  As such, the security
428	   considerations associated with those documents apply to XCAP diff
429	   documents.

431	7.  IANA Considerations

433	   There are several IANA considerations associated with this
434	   specification.

436	7.1  application/xcap-diff+xml MIME Type
437	      MIME media type name: application
438	      MIME subtype name: xcap-diff+xml
439	      Mandatory parameters: none
440	      Optional parameters: Same as charset parameter application/xml as
441	      specified in RFC 3023 [4].
442	      Encoding considerations: Same as encoding considerations of
443	      application/xml as specified in RFC 3023 [4].
444	      Security considerations: See Section 10 of RFC 3023 [4] and
445	      Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
446	      XXXX with the RFC number of this specification.]].
447	      Interoperability considerations: none.
448	      Published specification: This document.
449	      Applications which use this media type: This document type has
450	      been used to support manipulation of resource lists [13] using
451	      XCAP.
452	      Additional Information:
453	         Magic Number: None
454	         File Extension: .xdf or .xml
455	         Macintosh file type code: "TEXT"
456	         Personal and email address for further information: Jonathan
457	         Rosenberg, jdrosen@jdrosen.net
458	         Intended usage: COMMON
459	         Author/Change controller: The IETF.

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

463	   This section registers a new XML namespace, as per the guidelines in
464	   [6]
465	      URI: The URI for this namespace is
466	      urn:ietf:params:xml:ns:xcap-diff.
467	      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
468	      Jonathan Rosenberg (jdrosen@jdrosen.net).
469	      XML:

471	                BEGIN
472	                <?xml version="1.0"?>
473	                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
474	                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
475	                <html xmlns="http://www.w3.org/1999/xhtml">
476	                <head>
477	                  <meta http-equiv="content-type"
478	                     content="text/html;charset=iso-8859-1"/>
479	                  <title>XCAP Diff Namespace</title>
480	                </head>
481	                <body>
482	                  <h1>Namespace for XCAP Diff</h1>
483	                  <h2>urn:ietf:params:xml:ns:xcap-diff</h2>
484	                  <p>See <a href="[URL of published RFC]">RFCXXXX[[NOTE
485	   TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
486	   specification.]]</a>.</p>
487	                </body>
488	                </html>
489	                END

491	7.3  Schema Registration

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

500	8.  References

502	8.1  Normative References

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

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

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

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

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

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

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

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

530	8.2  Informative References

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

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

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

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

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

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

557	Author's Address

559	   Jonathan Rosenberg
560	   dynamicsoft
561	   600 Lanidex Plaza
562	   Parsippany, NJ  07054
563	   US

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

569	Intellectual Property Statement

571	   The IETF takes no position regarding the validity or scope of any
572	   Intellectual Property Rights or other rights that might be claimed to
573	   pertain to the implementation or use of the technology described in
574	   this document or the extent to which any license under such rights
575	   might or might not be available; nor does it represent that it has
576	   made any independent effort to identify any such rights.  Information
577	   on the procedures with respect to rights in RFC documents can be
578	   found in BCP 78 and BCP 79.

580	   Copies of IPR disclosures made to the IETF Secretariat and any
581	   assurances of licenses to be made available, or the result of an
582	   attempt made to obtain a general license or permission for the use of
583	   such proprietary rights by implementers or users of this
584	   specification can be obtained from the IETF on-line IPR repository at
585	   http://www.ietf.org/ipr.

587	   The IETF invites any interested party to bring to its attention any
588	   copyrights, patents or patent applications, or other proprietary
589	   rights that may cover technology that may be required to implement
590	   this standard.  Please address the information to the IETF at
591	   ietf-ipr@ietf.org.

593	Disclaimer of Validity

595	   This document and the information contained herein are provided on an
596	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
597	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
598	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
599	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
600	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
601	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

603	Copyright Statement

605	   Copyright (C) The Internet Society (2004).  This document is subject
606	   to the rights, licenses and restrictions contained in BCP 78, and
607	   except as set forth therein, the authors retain all their rights.

609	Acknowledgment

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