idnits 2.17.00 (12 Aug 2021) /tmp/idnits40952/draft-ietf-simple-xcap-diff-04.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 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. ** 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. 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 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 17, 2006) is 5694 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-simple-xml-patch-ops has been published as RFC 5261 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '11') (Obsoleted by RFC 6665) == Outdated reference: draft-ietf-simple-xcap-list-usage has been published as RFC 4826 Summary: 7 errors (**), 0 flaws (~~), 6 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: April 20, 2007 October 17, 2006 6 An Extensible Markup Language (XML) Document Format for Indicating A 7 Change in XML Configuration Access Protocol (XCAP) Resources 8 draft-ietf-simple-xcap-diff-04 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 20, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This specification defines a document format that can be used to 42 indicate that a change has occurred in a document managed by the 43 Extensible Markup Language (XML) Configuration Access Protocol 44 (XCAP). This format indicates the document that has changed and its 45 former and new entity tags. It also can indicate the specific change 46 that was made in the document, using an XML patch format. XCAP diff 47 documents can be delivered to clients using a number of means, 48 including a Session Initiation Protocol (SIP) event package. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4 55 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 8 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 58 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 59 7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 8 60 7.2. URN Sub-Namespace Registration for 61 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 9 62 7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 10 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 Intellectual Property and Copyright Statements . . . . . . . . . . 13 69 1. Introduction 71 The Extensible Markup Language (XML) Configuration Access Protocol 72 (XCAP) [8] is a protocol that allows clients to manipulate XML 73 documents stored on a server. These XML documents serve as 74 configuration information for application protocols. As an example, 75 resource list [12] subscriptions (also known as presence lists) allow 76 a client to have a single SIP subscription to a list of users, where 77 the list is maintained on a server. The server will obtain presence 78 for those users and report it back to the client. This application 79 requires the server, called a Resource List Server (RLS), to have 80 access to the list of presentities. This list needs to be 81 manipulated by clients so they can add and remove their friends as 82 they desire. 84 Complexities arise when multiple clients attempt to simultaneously 85 manipulate a document, such as a presence list. Frequently, a client 86 will keep a copy of the current list in memory, so it can render it 87 to users. However, if another client modifies the document, the 88 cached version becomes stale. This modification event must be made 89 known to all clients which have cached copies of the document, so 90 that they can fetch the most recent one. 92 To deal with this problem, clients can use a Session Initiation 93 Protocol (SIP) [10] event package [11] to subscribe to change events 94 in XCAP documents. This notification needs to indicate the specific 95 resource that changed, and how it changed. One solution for the 96 format of such a change notification would be a content indirection 97 object [15]. Though content indirection can tell a client that a 98 document has changed, it provides it with MIME Content-ID indicating 99 the new version of the document. The MIME Content-ID is not the same 100 as the entity tag, which is used by XCAP for document versioning. As 101 such, a client cannot easily ascertain whether an indication of a 102 change in a document is due to a change it just made, or due to a 103 change another client made at around the same time. Furthermore, 104 content indirections don't indicate how a document changed; they 105 would only be able to indicate that it did change. 107 To resolve these problems, this document defines a data format which 108 can convey the fact that an XML document managed by XCAP has changed. 109 This data format is an XML document format, called an XCAP diff 110 document. This format can indicate that a document has changed, and 111 provide its previous and new entity tags. It can also optionally 112 include a set of patch operations [9], which indicate how to 113 transform the document from the version prior to the change, to the 114 version after it. 116 2. Terminology 118 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 119 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 120 and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and 121 indicate requirement levels for compliant implementations. 123 This specification also defines the following additional terms: 125 Document: When the term document is used without the "XCAP diff" in 126 front of it, it refers to the XCAP document resource about whom 127 the XCAP diff document is reporting a change. 129 XCAP diff document: The XML document defined by this specification 130 that reports on a set of changes in an XCAP document resource. 132 Server: Typically an XCAP server, this is a protocol entity that 133 generates XCAP diff documents based on its knowledge of a set of 134 XCAP documents. 136 Client: Typically an XCAP client and SIP User Agent (UA), the client 137 consumes XCAP diff documents in order to reconstruct the document 138 stored on the server. 140 3. Structure of an XCAP Diff Document 142 An XCAP diff document is an XML [2] document that MUST be well-formed 143 and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 144 and MUST be encoded using UTF-8. This specification makes use of XML 145 namespaces for identifying XCAP diff documents and document 146 fragments. The namespace URI for elements defined by this 147 specification is a URN [3], using the namespace identifier 'ietf' 148 defined by [5] and extended by [6]. This URN is: 150 urn:ietf:params:xml:ns:xcap-diff 152 An XCAP diff document begins with the root element tag . 153 This element has a single mandatory attribute, "xcap-root". The 154 value of this attribute is the XCAP root URI for the documents in 155 which the changes have taken place. A single XCAP diff document can 156 only represent changes in documents within the same XCAP root. The 157 content of the element is a sequence of 158 elements. Each element specifies changes in a specific 159 document within the XCAP root. It has one mandatory attribute, "doc- 160 selector", and a three optional attributes, "new-etag", "previous- 161 etag" and "hash". The "doc-selector" identifies the specific 162 document within the XCAP root for which changes are indicated. Its 163 content MUST be a relative path reference, with the base URI being 164 equal to the XCAP root URI. The "new-etag" attribute provides the 165 etag for the document after the application of the changes, assuming 166 the document exists after those changes. If the change being 167 reported is the deletion of the document, the "new-etag" attribute 168 will not be present. A server MUST include the "new-etag" unless the 169 document does not exist subsequent to the changes reported in the 170 XCAP diff document. The "previous-etag" attribute provides an 171 identifier for the document instance prior to the change. If the 172 document did not exist prior to the change (that is, the change was 173 the creation of the document), the "previous-etag" is not present. 175 The "previous-etag" and "new-etag" need not have been sequentially 176 assigned etags at the server. An XCAP diff document can indicate 177 changes that have occurred over a series of XCAP operations. 179 The optional "hash" attribute provides an HMAC of the document 180 instance whose etag is "new-etag", once that document is represented 181 in canonical form. To compute this value, the server MUST apply the 182 mandatory XML canonicalization defined in the Canonical XML 1.0 [1] 183 specification, and then computes an HMAC [13] using SHA1 over this 184 canonical document, with a key whose value is 0x2238a. The result is 185 the value of the "hash" attribute. This attribute is optional, and a 186 server MAY elect not to include it. Even if present, a client MAY 187 elect to ignore it. 189 Each element contains zero or one element, 190 followed by any number of elements from another namespace for the 191 purposes of extensibility. Any such unknown elements MUST be ignored 192 by the client. When present, the element tells the 193 client the specific set of XML patch operations that can be applied 194 to transform the document from the version whose etag was "previous- 195 etag" to the version whose etag is "new-etag". If the "previous- 196 etag" is not present, the element tells the client the 197 specific set of XML patch operations that can be applied to create a 198 document from nothing, and result in the document whose etag is "new- 199 etag". If the "new-etag" attribute is not present, it implies that 200 the document was removed. In that case, the is 201 meaningless and SHOULD be ignored. 203 The series of operations in the do not have to be the 204 same exact series of operations that occurred at the server. The 205 only requirement is that, if the server includes the 206 element, the sequence of events, when executed serially, will result 207 in the transformation of the document with the etag "previous-etag" 208 to the one whose etag is "new-etag". If the element is 209 not present, it means that the document has changed in some way, but 210 the XCAP server has elected not to provide the set of changes. In 211 that case, a client can retrieve the latest document if its cached 212 etag doesn't match the value of "new-etag". 214 It is important to note that a element with no child is not equivalent to a element with a child that is itself empty. The latter means that the document 217 has been assigned a new etag but its content is unchanged. The 218 former means that it has been assigned a new etag as a result of a 219 change, but the specific changes are not being reported in the XCAP 220 diff document. 222 Each element contains a sequence of instructions, each 223 of which can be , and elements. These 224 elements use the corresponding add, replace and remove types defined 225 in [9], and define a set of patch operations that can be applied to 226 transform the document. See [9] for instructions on how this 227 transformation is effected. The element can also 228 contain elements from other namespaces for the purposes of 229 extensibility. Any unknown elements MUST be ignored. 231 4. XML Schema 233 234 239 240 241 242 243 244 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 274 5. Example Document 276 The following is an example of a document compliant to the schema. 278 279 281 284 286 This indicates that the document with URI 287 "http://xcap.example.com/root/resource-lists/users/joe/coworkers" has 288 changed. Its previous entity tag is 8a77f8d and its new one is 289 7ahggs. 291 6. Security Considerations 293 XCAP diff documents can include changes from one document to another. 294 As a consequence, if the document itself is sensitive and requires 295 confidentiality, integrity or authentication, than the same applies 296 to the XCAP diff format. Therefore, protocols which transport XCAP 297 diff documents must provide sufficient security capabilities for 298 transporting the document itself. 300 7. IANA Considerations 302 There are several IANA considerations associated with this 303 specification. 305 7.1. application/xcap-diff+xml MIME Type 307 MIME media type name: application 309 MIME subtype name: xcap-diff+xml 311 Mandatory parameters: none 313 Optional parameters: Same as charset parameter application/xml as 314 specified in RFC 3023 [4]. 316 Encoding considerations: Same as encoding considerations of 317 application/xml as specified in RFC 3023 [4]. 319 Security considerations: See Section 10 of RFC 3023 [4] and 320 Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 321 XXXX with the RFC number of this specification.]]. 323 Interoperability considerations: none. 325 Published specification: This document. 327 Applications which use this media type: This document type has 328 been used to support manipulation of resource lists [14] using 329 XCAP. 331 Additional Information: 333 Magic Number: None 335 File Extension: .xdf 337 Macintosh file type code: "TEXT" 339 Personal and email address for further information: Jonathan 340 Rosenberg, jdrosen@jdrosen.net 342 Intended usage: COMMON 344 Author/Change controller: The IETF. 346 7.2. URN Sub-Namespace Registration for 347 urn:ietf:params:xml:ns:xcap-diff 349 This section registers a new XML namespace, as per the guidelines in 350 [6] 352 URI: The URI for this namespace is 353 urn:ietf:params:xml:ns:xcap-diff. 355 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 356 Jonathan Rosenberg (jdrosen@jdrosen.net). 358 XML: 360 BEGIN 361 362 364 365 366 368 XCAP Diff Namespace 369 370 371

Namespace for XCAP Diff

372

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

373

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

376 377 378 END 380 7.3. Schema Registration 382 This section registers a new XML schema per the procedures in [6]. 384 URI: urn:ietf:params:xml:schema:xcap-diff 386 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 387 Jonathan Rosenberg (jdrosen@jdrosen.net). 389 The XML for this schema can be found as the sole content of 390 Section 4. 392 8. References 394 8.1. Normative References 396 [1] Boyer, J., "Canonical XML Version 1.0", World Wide Web 397 Consortium Recommendation REC-xml-c14n-20010315, March 2001, 398 . 400 [2] Paoli, J., Maler, E., Sperberg-McQueen, C., Bray, T., and F. 401 Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", 402 World Wide Web Consortium Recommendation REC-xml-20040204, 403 February 2004, . 405 [3] Moats, R., "URN Syntax", RFC 2141, May 1997. 407 [4] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", 408 RFC 3023, January 2001. 410 [5] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 411 August 1999. 413 [6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 414 January 2004. 416 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 417 Levels", BCP 14, RFC 2119, March 1997. 419 [8] Rosenberg, J., "The Extensible Markup Language (XML) 420 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-12 421 (work in progress), October 2006. 423 [9] Urpalainen, J., "An Extensible Markup Language (XML) Patch 424 Operations Framework Utilizing XML Path Language (XPath) 425 Selectors", draft-ietf-simple-xml-patch-ops-02 (work in 426 progress), March 2006. 428 8.2. Informative References 430 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 431 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 432 Session Initiation Protocol", RFC 3261, June 2002. 434 [11] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 435 Notification", RFC 3265, June 2002. 437 [12] Roach, A., Campbell, B., and J. Rosenberg, "A Session 438 Initiation Protocol (SIP) Event Notification Extension for 439 Resource Lists", RFC 4662, August 2006. 441 [13] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 442 for Message Authentication", RFC 2104, February 1997. 444 [14] Rosenberg, J., "Extensible Markup Language (XML) Formats for 445 Representing Resource Lists", 446 draft-ietf-simple-xcap-list-usage-05 (work in progress), 447 February 2005. 449 [15] Burger, E., "A Mechanism for Content Indirection in Session 450 Initiation Protocol (SIP) Messages", RFC 4483, May 2006. 452 Author's Address 454 Jonathan Rosenberg 455 Cisco Systems 456 600 Lanidex Plaza 457 Parsippany, NJ 07054 458 US 460 Phone: +1 973 952-5000 461 Email: jdrosen@cisco.com 462 URI: http://www.jdrosen.net 464 Intellectual Property Statement 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Disclaimer of Validity 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 493 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 494 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 495 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Copyright Statement 500 Copyright (C) The Internet Society (2006). This document is subject 501 to the rights, licenses and restrictions contained in BCP 78, and 502 except as set forth therein, the authors retain all their rights. 504 Acknowledgment 506 Funding for the RFC Editor function is currently provided by the 507 Internet Society.