idnits 2.17.00 (12 Aug 2021) /tmp/idnits38836/draft-ietf-simple-xcap-diff-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 498. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 5, 2007) is 5555 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: 4 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 4 Intended status: Standards Track March 5, 2007 5 Expires: September 6, 2007 7 An Extensible Markup Language (XML) Document Format for Indicating A 8 Change in XML Configuration Access Protocol (XCAP) Resources 9 draft-ietf-simple-xcap-diff-05 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 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 September 6, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This specification defines a document format that can be used to 43 indicate that a change has occurred in a document managed by the 44 Extensible Markup Language (XML) Configuration Access Protocol 45 (XCAP). This format indicates the document that has changed and its 46 former and new entity tags. It also can indicate the specific change 47 that was made in the document, using an XML patch format. XCAP diff 48 documents can be delivered to clients using a number of means, 49 including a Session Initiation Protocol (SIP) event package. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4 56 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 Intellectual Property and Copyright Statements . . . . . . . . . . 13 70 1. Introduction 72 The Extensible Markup Language (XML) Configuration Access Protocol 73 (XCAP) [8] 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 modification event must be made 90 known to all clients which have cached copies of the document, so 91 that they can fetch the most recent one. 93 To deal with this problem, clients can use a Session Initiation 94 Protocol (SIP) [10] event package [11] to subscribe to change events 95 in XCAP documents. This notification needs to indicate the specific 96 resource that changed, and how it changed. One solution for the 97 format of such a change notification would be a content indirection 98 object [15]. Though content indirection can tell a client that a 99 document has changed, it provides it with MIME Content-ID indicating 100 the new version of the document. The MIME Content-ID is not the same 101 as the entity tag, which is used by XCAP for document versioning. As 102 such, a client cannot easily ascertain whether an indication of a 103 change in a document is due to a change it just made, or due to a 104 change another client made at around the same time. Furthermore, 105 content indirections don't indicate how a document changed; they 106 would only be able to indicate that it did change. 108 To resolve these problems, this document defines a data format which 109 can convey the fact that an XML document managed by XCAP has changed. 110 This data format is an XML document format, called an XCAP diff 111 document. This format can indicate that a document has changed, and 112 provide its previous and new entity tags. It can also optionally 113 include a set of patch operations [9], which indicate how to 114 transform the document from the version prior to the change, to the 115 version after it. 117 2. Terminology 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and 122 indicate requirement levels for compliant implementations. 124 This specification also defines the following additional terms: 126 Document: When the term document is used without the "XCAP diff" in 127 front of it, it refers to the XCAP document resource about whom 128 the XCAP diff document is reporting a change. 130 XCAP diff document: The XML document defined by this specification 131 that reports on a set of changes in an XCAP document resource. 133 Server: Typically an XCAP server, this is a protocol entity that 134 generates XCAP diff documents based on its knowledge of a set of 135 XCAP documents. 137 Client: Typically an XCAP client and SIP User Agent (UA), the client 138 consumes XCAP diff documents in order to reconstruct the document 139 stored on the server. 141 3. Structure of an XCAP Diff Document 143 An XCAP diff document is an XML [2] document that MUST be well-formed 144 and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 145 and MUST be encoded using UTF-8. This specification makes use of XML 146 namespaces for identifying XCAP diff documents and document 147 fragments. The namespace URI for elements defined by this 148 specification is a URN [3], using the namespace identifier 'ietf' 149 defined by [5] and extended by [6]. This URN is: 151 urn:ietf:params:xml:ns:xcap-diff 153 An XCAP diff document begins with the root element tag . 154 This element has a single mandatory attribute, "xcap-root". The 155 value of this attribute is the XCAP root URI for the documents in 156 which the changes have taken place. A single XCAP diff document can 157 only represent changes in documents within the same XCAP root. The 158 content of the element is a sequence of 159 elements. Each element specifies changes in a specific 160 document within the XCAP root. It has one mandatory attribute, "doc- 161 selector", and a three optional attributes, "new-etag", "previous- 162 etag" and "hash". The "doc-selector" identifies the specific 163 document within the XCAP root for which changes are indicated. Its 164 content MUST be a relative path reference, with the base URI being 165 equal to the XCAP root URI. The "new-etag" attribute provides the 166 etag for the document after the application of the changes, assuming 167 the document exists after those changes. If the change being 168 reported is the deletion of the document, the "new-etag" attribute 169 will not be present. A server MUST include the "new-etag" unless the 170 document does not exist subsequent to the changes reported in the 171 XCAP diff document. The "previous-etag" attribute provides an 172 identifier for the document instance prior to the change. If the 173 document did not exist prior to the change (that is, the change was 174 the creation of the document), the "previous-etag" is not present. 176 The "previous-etag" and "new-etag" need not have been sequentially 177 assigned etags at the server. An XCAP diff document can indicate 178 changes that have occurred over a series of XCAP operations. 180 The optional "hash" attribute provides an HMAC of the document 181 instance whose etag is "new-etag", once that document is represented 182 in canonical form. To compute this value, the server MUST apply the 183 mandatory XML canonicalization defined in the Canonical XML 1.0 [1] 184 specification, and then computes an HMAC [13] using SHA1 over this 185 canonical document, with a key whose value is 0x2238a. The result is 186 the value of the "hash" attribute. This attribute is optional, and a 187 server MAY elect not to include it. Even if present, a client MAY 188 elect to ignore it. 190 Each element contains zero or one element, 191 followed by any number of elements from another namespace for the 192 purposes of extensibility. Any such unknown elements MUST be ignored 193 by the client. When present, the element tells the 194 client the specific set of XML patch operations that can be applied 195 to transform the document from the version whose etag was "previous- 196 etag" to the version whose etag is "new-etag". If the "previous- 197 etag" is not present, the element tells the client the 198 specific set of XML patch operations that can be applied to create a 199 document from nothing, and result in the document whose etag is "new- 200 etag". If the "new-etag" attribute is not present, it implies that 201 the document was removed. In that case, the is 202 meaningless and SHOULD be ignored. 204 The series of operations in the do not have to be the 205 same exact series of operations that occurred at the server. The 206 only requirement is that, if the server includes the 207 element, the sequence of events, when executed serially, will result 208 in the transformation of the document with the etag "previous-etag" 209 to the one whose etag is "new-etag". If the element is 210 not present, it means that the document has changed in some way, but 211 the XCAP server has elected not to provide the set of changes. In 212 that case, a client can retrieve the latest document if its cached 213 etag doesn't match the value of "new-etag". 215 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 218 has been assigned a new etag but its content is unchanged. The 219 former means that it has been assigned a new etag as a result of a 220 change, but the specific changes are not being reported in the XCAP 221 diff document. 223 Each element contains a sequence of instructions, each 224 of which can be , and elements. These 225 elements use the corresponding add, replace and remove types defined 226 in [9], and define a set of patch operations that can be applied to 227 transform the document. See [9] for instructions on how this 228 transformation is effected. The element can also 229 contain elements from other namespaces for the purposes of 230 extensibility. Any unknown elements MUST be ignored. 232 4. XML Schema 234 235 239 240 241 242 243 245 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 272 5. Example Document 274 The following is an example of a document compliant to the schema. 276 277 279 282 284 This indicates that the document with URI 285 "http://xcap.example.com/root/resource-lists/users/joe/coworkers" has 286 changed. Its previous entity tag is 8a77f8d and its new one is 287 7ahggs. 289 6. Security Considerations 291 XCAP diff documents can include changes from one document to another. 292 As a consequence, if the document itself is sensitive and requires 293 confidentiality, integrity or authentication, than the same applies 294 to the XCAP diff format. Therefore, protocols which transport XCAP 295 diff documents must provide sufficient security capabilities for 296 transporting the document itself. 298 7. IANA Considerations 300 There are several IANA considerations associated with this 301 specification. 303 7.1. application/xcap-diff+xml MIME Type 305 MIME media type name: application 307 MIME subtype name: xcap-diff+xml 309 Mandatory parameters: none 311 Optional parameters: Same as charset parameter application/xml as 312 specified in RFC 3023 [4]. 314 Encoding considerations: Same as encoding considerations of 315 application/xml as specified in RFC 3023 [4]. 317 Security considerations: See Section 10 of RFC 3023 [4] and 318 Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 319 XXXX with the RFC number of this specification.]]. 321 Interoperability considerations: none. 323 Published specification: This document. 325 Applications which use this media type: This document type has 326 been used to support manipulation of resource lists [14] using 327 XCAP. 329 Additional Information: 331 Magic Number: None 333 File Extension: .xdf 335 Macintosh file type code: "TEXT" 337 Personal and email address for further information: Jonathan 338 Rosenberg, jdrosen@jdrosen.net 340 Intended usage: COMMON 342 Author/Change controller: The IETF. 344 7.2. URN Sub-Namespace Registration for 345 urn:ietf:params:xml:ns:xcap-diff 347 This section registers a new XML namespace, as per the guidelines in 348 [6] 350 URI: The URI for this namespace is 351 urn:ietf:params:xml:ns:xcap-diff. 353 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 354 Jonathan Rosenberg (jdrosen@jdrosen.net). 356 XML: 358 BEGIN 359 360 362 363 364 366 XCAP Diff Namespace 367 368 369

Namespace for XCAP Diff

370

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

371

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

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