idnits 2.17.1 

draft-ietf-simple-xcap-package-03.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 3978, Section 5.1.a on line 17.

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

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

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

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

  ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
     Acknowledgement. 

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

        This document is an Internet-Draft and is subject to all provisions of
        Section 3 of RFC 3667.

        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.


  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 113: '...   An XCAP diff document is an XML [2] document that MUST be well-formed...'
     RFC 2119 keyword, line 114: '...   and SHOULD be valid.  XML-change do...'
     RFC 2119 keyword, line 115: '...   and MUST be encoded using UTF-8.  T...'
     RFC 2119 keyword, line 133: '...s are included.  Its content MUST be a...'
     RFC 2119 keyword, line 157: '...   <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 (January 25, 2005) is 7031 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: A later version (-12) exists of
     draft-ietf-simple-xcap-05

  == Outdated reference: A later version (-18) exists of
     draft-ietf-sipping-config-framework-05

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

  == Outdated reference: A later version (-05) exists of
     draft-ietf-simple-xcap-list-usage-04


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

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

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


2	SIMPLE                                                      J. Rosenberg
3	Internet-Draft                                             Cisco Systems
4	Expires: July 26, 2005                                  January 25, 2005

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

10	Status of this Memo

12	   This document is an Internet-Draft and is subject to all provisions
13	   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
14	   author represents that any applicable patent or other IPR claims of
15	   which he or she is aware have been or will be disclosed, and any of
16	   which he or she become aware will be disclosed, in accordance with
17	   RFC 3668.

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

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

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

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

35	   This Internet-Draft will expire on July 26, 2005.

37	Copyright Notice

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

41	Abstract

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

52	Table of Contents

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

71	1.  Introduction

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

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

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

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

111	2.  Structure of an XCAP Diff Document

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

121	      urn:ietf:params:xml:ns:xcap-diff

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

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

146	   Each <document> element is followed by a series of operations, which
147	   if followed by the client, will convert the document whose etag is
148	   "previous-etag" into the one whose etag is "new-etag".  Each
149	   operation is specified by an XML element.  Six operations are
150	   defined:

152	   <add-element>: Instructs the recipient of the document to add an
153	      element.  The "parent" attribute contains a node-selector which
154	      selects the parent of the new element.  The "position" attribute
155	      indicates that the new element is to be inserted as a child such
156	      that it has that position amongst it siblings.  The content of
157	      <add-element> MUST be a CDATA section enclosing a single XML
158	      element, which is to be added.

160	   <add-attribute>: Instructs the recipient of the document to add an
161	      attribute.  The "element" attribute contains a node-selector which
162	      selects the element into which the attribute is to be inserted.
163	      The "att-name" attribute contains the name of the new attribute.
164	      The content of <add-attribute> is the value of the new attribute.

166	   <remove-element>: Instructs the recipient of the document to delete
167	      an element.  The "element" attribute contains a node-selector
168	      which selects the element to be removed.

170	   <remove-attribute>: Instructs the recipient of the document to remove
171	      an attribute.  The "element" attribute contains a node-selector
172	      which selects the element in which the attribute exists.  The
173	      "att-name" attribute indicates the name of the attribute which is
174	      to be removed.

176	   <replace-element>: Instructs the recipient of the document to replace
177	      an element.  The "element" attribute contains a node-selector
178	      which selects the element to replace.  The content of the
179	      <replace-element> element MUST be a CDATA section containing
180	      single XML element which is to replace the one identified by the
181	      node-selector.

183	   <replace-attribute>: Instructs the recipient of the document to
184	      replace an attribute.  The "element" attribute contains a
185	      node-selector which selects the element to replace.  The
186	      "att-name" attribute contains the name of the attribute to
187	      replace.  The content of the <replace-attribute> element is the
188	      value of the new attribute.

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

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

199	3.  XML Schema

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

262	            </xs:complexType>
263	           </xs:element>
264	          </xs:choice>
265	         </xs:sequence>
266	         <xs:attribute name="doc-selector" type="xs:anyURI" use="required"/>
267	         <xs:attribute name="new-etag" type="xs:string" use="required"/>
268	         <xs:attribute name="previous-etag" type="xs:string" use="required"/>
269	         <xs:attribute name="hash" type="xs:string" use="optional"/>
270	        </xs:complexType>
271	       </xs:element>
272	      </xs:sequence>
273	      <xs:attribute name="xcap-root" type="xs:anyURI" use="required"/>
274	     </xs:complexType>
275	    </xs:element>
276	   </xs:schema>

278	4.  Example Document

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

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

295	5.  Usage with the Config Framework

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

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

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

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

343	   Once the client has obtained the versions of the documents identified
344	   in the reference XML diff, it can process NOTIFY requests on that
345	   subscription.  To process the NOTIFY requests, it makes sure that its
346	   current version matches the version in the "previous-etag" attribute
347	   of the <document> element.  It then follows the list of instructions,
348	   in order, for that <document>.  Specifically:

350	   <add-element>: The "parent" attribute contains a node-selector.  The
351	      client applies the node selector to the document according to the
352	      procedures defined in XCAP [7].  If the result is a single
353	      element, the client takes the content of the <add-element> element
354	      and adds it as the position-th child.  If the node selector doesnt
355	      select a single element, or the selected element has fewer than
356	      position-1 children already, the result is an error.  The client
357	      MUST discard the XCAP-diff document, and MUST flush its current
358	      version of the document from memory.  It can then obtain a new XML
359	      diff reference by sending a SUBSCRIBE refresh request on the
360	      dialog.

362	   <add-attribute>: 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 takes adds a new attribute to the element,
366	      with the name equal to the content of the "att-name" attribute,
367	      and a value equal to the content of the <add-attribute> element.
368	      If the node selector doesnt select a single element, or the
369	      selected element already has an attribute with that name, the
370	      result is an error.  The client MUST discard the XCAP-diff
371	      document, and MUST flush its current version of the document from
372	      memory.  It can then obtain a new XML diff reference by sending a
373	      SUBSCRIBE refresh request on the dialog.

375	   <remove-element>: The "element" attribute contains a node-selector.
376	      The client applies the node selector to the document according to
377	      the procedures defined in XCAP [7].  If the result is a single
378	      element, the client removes that element from the document.  If
379	      the node selector doesnt select a single element the result is an
380	      error.  The client MUST discard the XCAP-diff document, and MUST
381	      flush its current version of the document from memory.  It can
382	      then obtain a new XML diff reference by sending a SUBSCRIBE
383	      refresh request on the dialog.

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

396	   <replace-element>: The "element" attribute contains a node-selector.
397	      The client applies the node selector to the document according to
398	      the procedures defined in XCAP [7].  If the result is a single
399	      element, the client removes that element, and replaces it with the
400	      content of the <add-element> element.  If the node selector doesnt
401	      select a single element, the result is an error.  The client MUST
402	      discard the XCAP-diff document, and MUST flush its current version
403	      of the document from memory.  It can then obtain a new XML diff
404	      reference by sending a SUBSCRIBE refresh request on the dialog.

406	   <replace-attribute>: The "element" attribute contains a
407	      node-selector.  The client applies the node selector to the
408	      document according to the procedures defined in XCAP [7].  If the
409	      result is a single element, the client removes the content of the
410	      attribute whose name is "att-name", and replaces it with the
411	      content of the <replace-attribute> element.  If the node selector
412	      doesnt select a single element, or the selected element doesn't
413	      have an attribute with that name, the result is an error.  The
414	      client MUST discard the XCAP-diff document, and MUST flush its
415	      current version of the document from memory.  It can then obtain a
416	      new XML diff reference by sending a SUBSCRIBE refresh request on
417	      the dialog.

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

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

439	6.  Security Considerations

441	   XCAP diff documents contain the same information in the documents
442	   whose differences they describe.  As such, the security
443	   considerations associated with those documents apply to XCAP diff
444	   documents.

446	7.  IANA Considerations

448	   There are several IANA considerations associated with this
449	   specification.

451	7.1  application/xcap-diff+xml MIME Type

453	      MIME media type name: application

455	      MIME subtype name: xcap-diff+xml

457	      Mandatory parameters: none

459	      Optional parameters: Same as charset parameter application/xml as
460	      specified in RFC 3023 [4].

462	      Encoding considerations: Same as encoding considerations of
463	      application/xml as specified in RFC 3023 [4].

465	      Security considerations: See Section 10 of RFC 3023 [4] and
466	      Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace
467	      XXXX with the RFC number of this specification.]].

469	      Interoperability considerations: none.

471	      Published specification: This document.

473	      Applications which use this media type: This document type has
474	      been used to support manipulation of resource lists [13] using
475	      XCAP.

477	      Additional Information:

479	         Magic Number: None

481	         File Extension: .xdf or .xml

483	         Macintosh file type code: "TEXT"

485	         Personal and email address for further information: Jonathan
486	         Rosenberg, jdrosen@jdrosen.net

488	         Intended usage: COMMON

490	         Author/Change controller: The IETF.

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

494	   This section registers a new XML namespace, as per the guidelines in
495	   [6]
496	      URI: The URI for this namespace is
497	      urn:ietf:params:xml:ns:xcap-diff.

499	      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
500	      Jonathan Rosenberg (jdrosen@jdrosen.net).

502	      XML:

504	                BEGIN
505	                <?xml version="1.0"?>
506	                <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
507	                          "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
508	                <html xmlns="http://www.w3.org/1999/xhtml">
509	                <head>
510	                  <meta http-equiv="content-type"
511	                     content="text/html;charset=iso-8859-1"/>
512	                  <title>XCAP Diff Namespace</title>
513	                </head>
514	                <body>
515	                  <h1>Namespace for XCAP Diff</h1>
516	                  <h2>urn:ietf:params:xml:ns:xcap-diff</h2>
517	                  <p>See <a href="[URL of published RFC]">RFCXXXX[[NOTE
518	   TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this
519	   specification.]]</a>.</p>
520	                </body>
521	                </html>
522	                END

524	7.3  Schema Registration

526	   This section registers a new XML schema per the procedures in [6].

528	      URI: urn:ietf:params:xml:schema:xcap-diff

530	      Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
531	      Jonathan Rosenberg (jdrosen@jdrosen.net).

533	      The XML for this schema can be found as the sole content of
534	      Section 3.

536	8.  References

538	8.1  Normative References

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

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

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

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

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

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

558	   [7]  Rosenberg, J., "The Extensible Markup Language (XML)
559	        Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-05
560	        (work in progress), November 2004.

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

566	8.2  Informative References

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

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

575	   [11]  Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation
576	         Protocol (SIP) Event Notification Extension for  Resource
577	         Lists", draft-ietf-simple-event-list-07 (work in progress),
578	         January 2005.

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

583	   [13]  Rosenberg, J., "Extensible Markup Language (XML) Formats for
584	         Representing Resource Lists",
585	         draft-ietf-simple-xcap-list-usage-04 (work in progress),
586	         October 2004.

588	   [14]  Burger, E., "A Mechanism for Content Indirection in Session
589	         Initiation Protocol (SIP)  Messages",
590	         draft-ietf-sip-content-indirect-mech-05 (work in progress),
591	         October 2004.

593	Author's Address

595	   Jonathan Rosenberg
596	   Cisco Systems
597	   600 Lanidex Plaza
598	   Parsippany, NJ  07054
599	   US

601	   Phone: +1 973 952-5000
602	   EMail: jdrosen@cisco.com
603	   URI:   http://www.jdrosen.net

605	Intellectual Property Statement

607	   The IETF takes no position regarding the validity or scope of any
608	   Intellectual Property Rights or other rights that might be claimed to
609	   pertain to the implementation or use of the technology described in
610	   this document or the extent to which any license under such rights
611	   might or might not be available; nor does it represent that it has
612	   made any independent effort to identify any such rights.  Information
613	   on the procedures with respect to rights in RFC documents can be
614	   found in BCP 78 and BCP 79.

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

623	   The IETF invites any interested party to bring to its attention any
624	   copyrights, patents or patent applications, or other proprietary
625	   rights that may cover technology that may be required to implement
626	   this standard.  Please address the information to the IETF at
627	   ietf-ipr@ietf.org.

629	Disclaimer of Validity

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

639	Copyright Statement

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

645	Acknowledgment

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