idnits 2.17.1 draft-ietf-simple-xcap-diff-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 516. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 506. ** 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 3 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 22, 2005) is 6760 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-07 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-07 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '11') (Obsoleted by RFC 6665) Summary: 7 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: April 25, 2006 October 22, 2005 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-02 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 25, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 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. XCAP diff documents can be delivered to 46 clients using a number of means, including the Session Initiation 47 Protocol (SIP) event package for configuration data. By subscribing 48 to this event package, clients can learn about document changes made 49 by other clients. The XCAP diff format is extensible, so that 50 additional information, such as a description of the actual change, 51 can be included. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4 58 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Usage with the Config Framework . . . . . . . . . . . . . . . 7 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8.1 application/xcap-diff+xml MIME Type . . . . . . . . . . . 8 64 8.2 URN Sub-Namespace Registration for 65 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 9 66 8.3 Schema Registration . . . . . . . . . . . . . . . . . . . 10 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 9.1 Normative References . . . . . . . . . . . . . . . . . . . 10 69 9.2 Informative References . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 71 Intellectual Property and Copyright Statements . . . . . . . . 13 73 1. Introduction 75 The Extensible Markup Language (XML) Configuration Access Protocol 76 (XCAP) [8] is a protocol that allows clients to manipulate XML 77 documents stored on a server. These XML documents serve as 78 configuration information for application protocols. As an example, 79 resource list [12] subscriptions (also known as presence lists) allow 80 a client to have a single SIP subscription to a list of users, where 81 the list is maintained on a server. The server will obtain presence 82 for those users and report it back to the client. This application 83 requires the server, called a Resource List Server (RLS), to have 84 access to the list of presentities. This list needs to be 85 manipulated by clients so they can add and remove their friends as 86 they desire. 88 Complexities arise when multiple clients attempt to simultaneously 89 manipulate a document, such as a presence list. Frequently, a client 90 will keep a copy of the current list in memory, so it can render it 91 to users. However, if another client modifies the document, the 92 cached version becomes stale. This modification event must be made 93 known to all clients which have cached copies of the document, so 94 that they can fetch the most recent one. 96 To deal with this problem, clients can use the Session Initiation 97 Protocol (SIP) [10] event package [11] for subscribing to changes in 98 configuration and profile information [9], including application data 99 that resides on an XCAP server. With that package, a user gets 100 notified that a particular document has changed. This notification 101 can include the full content of the new document, or it can be a 102 content indirection [15]. Though content indirection can tell a 103 client that a document has changed, it provides it with MIME 104 Content-ID indicating the new version of the document. The MIME 105 Content-ID is not the same as the entity tag, which is used by XCAP 106 for document versioning. As such, a client cannot easily ascertain 107 whether an indication of a change in a document is due to a change it 108 just made, or due to a change another client made at around the same 109 time. 111 In addition, when an XCAP client inserts a new element or attribute 112 into an existing document, the client has no way to know whether the 113 insertion was done against its cached version of the document. The 114 reasons for this are described in Section 7.10 of XCAP. To help a 115 client ascertain whether this has occurred after performing the 116 insertion, the XCAP response needs to contain a document which 117 indicates the entity tags before and after the document was modified. 119 To resolve these problems, this document defines a data format which 120 can convey the fact that an XML document has changed. This data 121 format is an XML document format, called an XCAP diff document. This 122 format can indicate that a document has changed, and provide its 123 previous and new entity tags. This specification also explains how 124 this format is used in conjunction with the configuration profile 125 framework. 127 2. Terminology 129 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 130 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 131 and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and 132 indicate requirement levels for compliant implementations. 134 This specification also defines the following additional terms: 136 Document: When the term document is used without the "XCAP diff" in 137 front of it, it refers to the XCAP document resource about whom 138 the XCAP diff document is reporting a change. 140 XCAP diff document: The XML document defined by this specification 141 that reports on a set of changes in an XCAP document resource. 143 Server: Typically an XCAP server, this is a protocol entity that 144 generates XCAP diff documents based on its knowledge of a set of 145 XCAP documents. 147 Client: Typically an XCAP client and SIP User Agent (UA) that acts as 148 a subscriber to the configuration event package, this is a 149 protocol entity that consumes XCAP diff documents in order to 150 reconstruct the document stored on the server. 152 3. Structure of an XCAP Diff Document 154 An XCAP diff document is an XML [2] document that MUST be well-formed 155 and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 156 and MUST be encoded using UTF-8. This specification makes use of XML 157 namespaces for identifying XCAP diff documents and document 158 fragments. The namespace URI for elements defined by this 159 specification is a URN [3], using the namespace identifier 'ietf' 160 defined by [5] and extended by [6]. This URN is: 162 urn:ietf:params:xml:ns:xcap-diff 164 An XCAP diff document begins with the root element tag . 165 This element has a single mandatory attribute, "xcap-root". The 166 value of this attribute is the XCAP root URI for the documents in 167 which the changes have taken place. A single XCAP diff document can 168 only represent changes in documents within the same XCAP root. The 169 content of the element is a sequence of 170 elements. Each element specifies changes in a specific 171 document within the XCAP root. It has one mandatory attribute, "doc- 172 selector", and a three optional attributes, "new-etag", "previous- 173 etag" and "hash". The "doc-selector" identifies the specific 174 document within the XCAP root for which changes are indicated. Its 175 content MUST be a relative path reference, with the base URI being 176 equal to the XCAP root URI. The "new-etag" attribute provides the 177 etag for the document after the application of the changes, assuming 178 the document exists after those changes. If the change being 179 reported is the deletion of the document, the "new-etag" attribute 180 will not be present. A server MUST include the "new-etag" unless the 181 document does not exist subsequent to the changes reported in the 182 XCAP diff document. The "previous-etag" attribute provides an 183 identifier for the document instance prior to the change. If the 184 document did not exist prior to the change (that is, the change was 185 the creation of the document), the "previous-etag" is not present. 187 The "previous-etag" and "new-etag" need not have been sequentially 188 assigned etags at the server. An XCAP diff document can indicate 189 changes that have occurred over a series of XCAP operations. 191 The optional "hash" attribute provides an HMAC of the document 192 instance whose etag is "new-etag", once that document is represented 193 in canonical form. To compute this value, the server MUST apply the 194 mandatory XML canonicalization defined in the Canonical XML 1.0 [1] 195 specification, and then computes an HMAC [13] using SHA1 over this 196 canonical document, with a key whose value is 0x2238a. The result is 197 the value of the "hash" attribute. This attribute is optional, and a 198 server MAY elect not to include it. Even if present, a client MAY 199 elect to ignore it. 201 This contents of the element are extensible, and can 202 include elements from other namespaces. It is anticipated that 203 extensions would be defined that allow the actual change in the 204 document to be reported. 206 4. XML Schema 208 209 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 235 5. Example Document 237 The following is an example of a document compliant to the schema. 239 240 242 245 247 This indicates that the document with URI 248 http://xcap.example.com/root/resource-lists/users/joe/coworkers has 249 changed. Its previous entity tag is 8a77f8d and its new one is 250 7ahggs. 252 6. Usage with the Config Framework 254 The framework for user agent profile delivery [9] defines an event 255 package which can be used to subscribe to user, device, application 256 or local-network data that defines the configuration of a client. 257 This data can be present in an XCAP server. Normally, content 258 indirection [15] will be used as the NOTIFY body format, to indicate 259 the specific document that has changed, and should be re-fetched. 260 However, if the client includes an Accept header field including the 261 MIME type "application/xcap-diff+xml", the server has the option of 262 returning documents in this format instead. 264 When the client performs an initial subscription, the rules in [9] 265 are used to select the set of documents which the subscription 266 applies to. Upon initial subscription, the server does not know 267 which instances of each document (where each instance is identified 268 by an etag) the client currently posessses, if any. Indeed, upon 269 startup, the client will not have any documents. The initial NOTIFY 270 in this case MUST include a element for each document 271 associated with the subscription. The "previous-etag" attribute MUST 272 be absent, and the "new-etag" attribute MUST be present and contain 273 the entity tag for the current version of that document resource. An 274 XCAP diff document structured this way is called a "reference" XCAP 275 diff document. It establishes the baseline etags and document URIs 276 for the documents covered by the subscription. 278 Upon receipt of this document, the client can determine whether its 279 local instance documents, if any, match the etags in the XCAP diff 280 document. If they do not match, the client SHOULD perform a 281 conditional GET for each document. The document URI is constructed 282 by appending the XCAP root in the "xcap-root" attribute of the element to the escape coded "doc-selector" from each 284 element. The request is made conditional by including an If-Match 285 header field, with the value of the etag from each 286 element. So long as the documents haven't changed between the NOTIFY 287 and the GET, the client will obtain the reference versions that the 288 server will use for subsequent notifications. 290 If the conditional GET should fail, the client SHOULD generate a 291 SUBSCRIBE refresh request to trigger a new NOTIFY. The server will 292 always generate a "reference" XML diff document on receipt of a 293 SUBSCRIBE refresh. This establishes a new set of baseline etags, and 294 the client can then attempt to do another fetch. It is anticipated 295 that future extensions to the profile delivery framework will allow a 296 client to include, in its SUBSCRIBE request, an indicator of the 297 current version of the documents it holds. That would obviate the 298 need for a potentially never-ending stream of SUBSCRIBE/GET sequences 299 should the documents be rapidly changing, for some reason. 301 Once the client has obtained the versions of the documents identified 302 in the reference XML diff, it can process NOTIFY requests on that 303 subscription. To process the NOTIFY requests, it makes sure that its 304 current version matches the version in the "previous-etag" attribute 305 of the element. If not, the client can then fetch the 306 updated document from the server. If they do match, the client has 307 the most current version. 309 7. Security Considerations 311 XCAP diff documents are not very sensitive; they only contain entity 312 tags and the URI for documents. An attacker that is able to examine 313 such a document cannot access or modify the referenced document 314 unless it has also managed to attack XCAP itself. Thus, there is no 315 requirement for message confidentiality. However, an attacker that 316 can modify XCAP diff documents in transit could fool a client into 317 thinking that a document hasn't changed, when it has, or vice-a- 318 versa. Therefore, protocols which transport XCAP Diff documents 319 SHOULD provide message integrity. 321 8. IANA Considerations 323 There are several IANA considerations associated with this 324 specification. 326 8.1 application/xcap-diff+xml MIME Type 328 MIME media type name: application 330 MIME subtype name: xcap-diff+xml 332 Mandatory parameters: none 334 Optional parameters: Same as charset parameter application/xml as 335 specified in RFC 3023 [4]. 337 Encoding considerations: Same as encoding considerations of 338 application/xml as specified in RFC 3023 [4]. 340 Security considerations: See Section 10 of RFC 3023 [4] and 341 Section 7 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 342 XXXX with the RFC number of this specification.]]. 344 Interoperability considerations: none. 346 Published specification: This document. 348 Applications which use this media type: This document type has 349 been used to support manipulation of resource lists [14] using 350 XCAP. 352 Additional Information: 354 Magic Number: None 356 File Extension: .xdf 358 Macintosh file type code: "TEXT" 360 Personal and email address for further information: Jonathan 361 Rosenberg, jdrosen@jdrosen.net 363 Intended usage: COMMON 365 Author/Change controller: The IETF. 367 8.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-diff 369 This section registers a new XML namespace, as per the guidelines in 370 [6] 372 URI: The URI for this namespace is 373 urn:ietf:params:xml:ns:xcap-diff. 375 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 376 Jonathan Rosenberg (jdrosen@jdrosen.net). 378 XML: 380 BEGIN 381 382 384 385 386 388 XCAP Diff Namespace 389 390 391

Namespace for XCAP Diff

392

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

393

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

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