idnits 2.17.00 (12 Aug 2021) /tmp/idnits38048/draft-ietf-simple-xcap-diff-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 481. ** 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 4 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 228: '... The initial NOTIFY in this case MUST...' (5 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 (February 14, 2005) is 6304 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 -- Possible downref: Normative reference to a draft: ref. '9' -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '11') (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: 10 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIMPLE J. Rosenberg 2 Internet-Draft Cisco Systems 3 Expires: August 15, 2005 February 14, 2005 5 An Extensible Markup Language (XML) Document Format for Indicating 6 Changes in XML Configuration Access Protocol (XCAP) Resources 7 draft-ietf-simple-xcap-diff-00 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 15, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This specification defines a document format that can be used to 43 describe the differences between versions of resources managed by the 44 Extensible Markup Language (XML) Configuration Access Protocol 45 (XCAP). Documents of this format can be delivered to clients using a 46 number of means, including the Session Initiation Protocol (SIP) 47 event package for configuration data. By subscribing to this event 48 package, clients can learn about document changes made by other 49 clients. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 3 55 3. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Usage with the Config Framework . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 7.1 application/xcap-diff+xml MIME Type . . . . . . . . . . . 8 61 7.2 URN Sub-Namespace Registration for 62 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 9 63 7.3 Schema Registration . . . . . . . . . . . . . . . . . . . 9 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 66 8.2 Informative References . . . . . . . . . . . . . . . . . . . 10 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 68 Intellectual Property and Copyright Statements . . . . . . . . 12 70 1. Introduction 72 The Extensible Markup Language (XML) Configuration Access Protocol 73 (XCAP) [7] is a protocol that allows clients to manipulate XML 74 documents stored on a server. These XML documents serve as 75 configuration information for application protocols. As an example, 76 resource list [12] subscriptions (also known as presence lists) allow 77 a client to have a single SIP subscription to a list of users, where 78 the list is maintained on a server. The server will obtain presence 79 for those users and report it back to the client. This application 80 requires the server, called a Resource List Server (RLS), to have 81 access to the list of presentities. This list needs to be 82 manipulated by clients so they can add and remove their friends as 83 they desire. 85 Complexities arise when multiple clients attempt to simultaneously 86 manipulate a document, such as a presence list. Frequently, a client 87 will keep a copy of the current list in memory, so it can render it 88 to users. However, if another client modifies the document, the 89 cached version becomes stale. This information must be made known to 90 all clients which have cached copies of the document, so that they 91 can fetch the most recent one. 93 To deal with this problem, clients can use the Session Initiation 94 Protocol (SIP) [10]event package [11] for subscribing to changes in 95 configuration and profile information [8], including application data 96 that resides on an XCAP server. With that package, a user gets 97 notified that a particular document has changed. This notification 98 can include the full content of the new document, or it can be a 99 content indirection [15]. However, in both cases, the transfer of 100 the entire document is ultimately required. This may require a lot 101 of bandwidth, particularly for wireless devices with large documents 102 (such as a resource list [12] with hundreds of users listed). 104 To resolve this problem, this document defines a data format which 105 can convey changes in XML documents managed by an XCAP server. This 106 data format is an XML document format, called an XCAP diff document. 107 The XCAP diff document is based on a generic format for XML patch 108 operations [9]. This specification also explains how this format is 109 used in 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 . 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 element is a sequence of elements. Each 129 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 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". These are the 149 three XML patch operations, , and defined in 150 [9]. 152 It is possible for the list of instructions for a to be 153 empty. In that case, the entity tag in the "new-etag" may equal the 154 entity tag in the "previous-etag". These entity tags may differ in 155 the event that the document has changed entity tags, but its content 156 has not been altered. 158 3. XML Schema 160 161 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 191 4. Example Document 193 The following is an example of a document compliant to the schema: 195 196 201 203 205 207 208 209 210 212 5. Usage with the Config Framework 214 The framework for user agent profile delivery [8] defines an event 215 package which can be used to subscribe to user, device, application 216 or local-network data. This data can be present in an XCAP server. 217 Normally, content indirection [15] will be used as the NOTIFY body 218 format, to indicate the specific document that has changed, and 219 should be re-fetched. However, if the client includes an Accept 220 header field including the MIME type "application/xcap-diff+xml", the 221 server has the option of returning documents in this format instead. 223 When the client performs an initial subscription, the rules in [8] 224 are used to select the set of documents which the subscription 225 applies to. Upon initial subscription, the server does not know 226 which instance (where each instance is identified by an etag) the 227 client currently posessses, if any. Indeed, upon startup, the client 228 will not have any documents. The initial NOTIFY in this case MUST 229 include a element for each document associated with the 230 subscription. The content of each of those elements MUST 231 be empty. The "previous-etag" and "new-etag" attributes MUST be 232 identical, and contain the entity tag for the current version of that 233 resource. An XML diff document structured this way is called a 234 "reference" XML diff document. It establishes the baseline etags and 235 document URIs for the documents covered by the subscription. 237 Upon receipt of this document, the client can determine whether its 238 local instance documents, if any, match the etags in the XCAP diff 239 document. If they do not match, the client SHOULD perform a 240 conditional GET for each document. The document URI is constructed 241 by appending the XCAP root in the "xcap-root" attribute of the 242 element to the escape coded "doc-selector" from each 243 element. The request is made conditional by including an 244 If-Match header field, with the value of the etag from each 245 element. So long as the documents haven't changed between 246 the NOTIFY and the GET, the client will obtain the reference versions 247 that the server will use for subsequent notifications. 249 If the conditional GET should fail, the client SHOULD generate a 250 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 251 always generate a "reference" XML diff document on receipt of a 252 SUBSCRIBE refresh. This establishes a new set of baseline etags, and 253 the client can then attempt to do another fetch. It is anticipated 254 that future extensions to the profile delivery framework will allow a 255 client to include, in its SUBSCRIBE request, an indicator of the 256 current version of the documents it holds. That would obviate the 257 need for a potentially never-ending stream of SUBSCRIBE/GET sequences 258 should the documents be rapidly changing, for some reason. 260 Once the client has obtained the versions of the documents identified 261 in the reference XML diff, it can process NOTIFY requests on that 262 subscription. To process the NOTIFY requests, it makes sure that its 263 current version matches the version in the "previous-etag" attribute 264 of the element. It then follows the list of instructions, 265 in order, for that as defined in [9]. 267 Once the client has finished applying the instructions to the 268 document, it should end up with the same document the server has. To 269 verify this, the client applies the mandatory XML canonicalization 270 defined in the Canonical XML 1.0 [1] specification, and computes an 271 HMAC [13] using SHA1 over this canonical document, with a key whose 272 value is 0x2238a. The resulting string is compared with the "hash" 273 attribute of the element. If they match, the client can 274 be sure that it has the most up to date version. If they don't 275 match, the client MUST flush its current version of the document from 276 memory. It can then obtain a new XML diff reference by sending a 277 SUBSCRIBE refresh request on the dialog. 279 Of course, this mechanism for computing the most current document 280 from the hash is optional. A client can elect to ignore the 281 information on what changed and simply fetch the most recent document 282 every time it gets a change indication where the new version is not 283 the same as the one cached by the client. Furthermore, the server 284 may elect to not send the hash, in which case this check cannot be 285 made. 287 6. Security Considerations 289 XCAP diff documents contain the same information in the documents 290 whose differences they describe. As such, the security 291 considerations associated with those documents apply to XCAP diff 292 documents. 294 7. IANA Considerations 296 There are several IANA considerations associated with this 297 specification. 299 7.1 application/xcap-diff+xml MIME Type 301 MIME media type name: application 303 MIME subtype name: xcap-diff+xml 305 Mandatory parameters: none 307 Optional parameters: Same as charset parameter application/xml as 308 specified in RFC 3023 [4]. 310 Encoding considerations: Same as encoding considerations of 311 application/xml as specified in RFC 3023 [4]. 313 Security considerations: See Section 10 of RFC 3023 [4] and 314 Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 315 XXXX with the RFC number of this specification.]]. 317 Interoperability considerations: none. 319 Published specification: This document. 321 Applications which use this media type: This document type has 322 been used to support manipulation of resource lists [14] using 323 XCAP. 325 Additional Information: 327 Magic Number: None 329 File Extension: .xdf 331 Macintosh file type code: "TEXT" 332 Personal and email address for further information: Jonathan 333 Rosenberg, jdrosen@jdrosen.net 335 Intended usage: COMMON 337 Author/Change controller: The IETF. 339 7.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-diff 341 This section registers a new XML namespace, as per the guidelines in 342 [6] 344 URI: The URI for this namespace is 345 urn:ietf:params:xml:ns:xcap-diff. 347 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 348 Jonathan Rosenberg (jdrosen@jdrosen.net). 350 XML: 352 BEGIN 353 354 356 357 358 360 XCAP Diff Namespace 361 362 363

Namespace for XCAP Diff

364

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

365

See RFCXXXX[[NOTE 366 TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this 367 specification.]].

368 369 370 END 372 7.3 Schema Registration 374 This section registers a new XML schema per the procedures in [6]. 376 URI: urn:ietf:params:xml:schema:xcap-diff 378 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 379 Jonathan Rosenberg (jdrosen@jdrosen.net). 381 The XML for this schema can be found as the sole content of 382 Section 3. 384 8. References 386 8.1 Normative References 388 [1] Boyer, J., "Canonical XML Version 1.0", W3C REC 389 REC-xml-c14n-20010315, March 2001. 391 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 392 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 393 FirstEdition REC-xml-20001006, October 2000. 395 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 397 [4] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 398 3023, January 2001. 400 [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 401 August 1999. 403 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 404 2004. 406 [7] Rosenberg, J., "The Extensible Markup Language (XML) 407 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-05 408 (work in progress), November 2004. 410 [8] Petrie, D., "A Framework for Session Initiation Protocol User 411 Agent Profile Delivery", draft-ietf-sipping-config-framework-05 412 (work in progress), November 2004. 414 [9] Urpalainen, J., "The Extensible Markup Language (XML) 415 Configuration Access Protocol (XCAP) Patch Operations", Internet 416 Draft draft-urpalainen-simple-xcap-patch-ops-00.txt, February 417 2005. 419 8.2 Informative References 421 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 422 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 424 Session Initiation Protocol", RFC 3261, June 2002. 426 [11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 427 Notification", RFC 3265, June 2002. 429 [12] Roach, A., Rosenberg, J. and B. Campbell, "A Session Initiation 430 Protocol (SIP) Event Notification Extension for Resource 431 Lists", draft-ietf-simple-event-list-07 (work in progress), 432 January 2005. 434 [13] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing 435 for Message Authentication", RFC 2104, February 1997. 437 [14] Rosenberg, J., "Extensible Markup Language (XML) Formats for 438 Representing Resource Lists", 439 draft-ietf-simple-xcap-list-usage-04 (work in progress), 440 October 2004. 442 [15] Burger, E., "A Mechanism for Content Indirection in Session 443 Initiation Protocol (SIP) Messages", 444 draft-ietf-sip-content-indirect-mech-05 (work in progress), 445 October 2004. 447 Author's Address 449 Jonathan Rosenberg 450 Cisco Systems 451 600 Lanidex Plaza 452 Parsippany, NJ 07054 453 US 455 Phone: +1 973 952-5000 456 EMail: jdrosen@cisco.com 457 URI: http://www.jdrosen.net 459 Intellectual Property Statement 461 The IETF takes no position regarding the validity or scope of any 462 Intellectual Property Rights or other rights that might be claimed to 463 pertain to the implementation or use of the technology described in 464 this document or the extent to which any license under such rights 465 might or might not be available; nor does it represent that it has 466 made any independent effort to identify any such rights. Information 467 on the procedures with respect to rights in RFC documents can be 468 found in BCP 78 and BCP 79. 470 Copies of IPR disclosures made to the IETF Secretariat and any 471 assurances of licenses to be made available, or the result of an 472 attempt made to obtain a general license or permission for the use of 473 such proprietary rights by implementers or users of this 474 specification can be obtained from the IETF on-line IPR repository at 475 http://www.ietf.org/ipr. 477 The IETF invites any interested party to bring to its attention any 478 copyrights, patents or patent applications, or other proprietary 479 rights that may cover technology that may be required to implement 480 this standard. Please address the information to the IETF at 481 ietf-ipr@ietf.org. 483 Disclaimer of Validity 485 This document and the information contained herein are provided on an 486 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 487 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 488 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 489 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 490 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 491 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 493 Copyright Statement 495 Copyright (C) The Internet Society (2005). This document is subject 496 to the rights, licenses and restrictions contained in BCP 78, and 497 except as set forth therein, the authors retain all their rights. 499 Acknowledgment 501 Funding for the RFC Editor function is currently provided by the 502 Internet Society.