idnits 2.17.00 (12 Aug 2021) /tmp/idnits44140/draft-ietf-simple-xcap-diff-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 643. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 656. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Each element indicates the existing element content of an XCAP document. It has one mandatory attribute, "sel", and one optional attribute, "exists". The "sel" attribute of the element identifies an XML element of an XCAP document. It is a percent endoced relative URI following XCAP conventions when selecting elements. The XCAP Node Selector MUST always locate a unique node, the "exists" attribute thus shows whether an element exists or not in the XCAP document. When the "exists" attribute is absent from the element, the indicated element still exists in the XCAP document. The located result element exists as a child element of the element. It should be noted, that only the full content of an element is shown if it exists, there are no conventions for patching these elements. In a corner case where the content of this element cannot be presented for some reason, although it exists in the XCAP document, the element MUST not have any child nodes. -- 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 (August 17, 2007) is 5390 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 2141 (ref. '4') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3023 (ref. '5') (Obsoleted by RFC 7303) ** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '6') == Outdated reference: draft-ietf-simple-xml-patch-ops has been published as RFC 5261 -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '12') (Obsoleted by RFC 6665) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 12 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 J. Urpalainen 5 Expires: February 18, 2008 Nokia 6 August 17, 2007 8 An Extensible Markup Language (XML) Document Format for Indicating A 9 Change in XML Configuration Access Protocol (XCAP) Resources 10 draft-ietf-simple-xcap-diff-06 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 18, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines a document format that can be used to 44 indicate that a change has occurred in a document managed by the 45 Extensible Markup Language (XML) Configuration Access Protocol 46 (XCAP). This format indicates the document that has changed and its 47 former and new entity tags. It also can indicate the specific change 48 that was made in the document, using an XML patch format. This 49 format allows also indications of element and attribute content of an 50 XML document. XCAP diff documents can be delivered to clients using 51 a number of means, including a Session Initiation Protocol (SIP) 52 event package. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 4 59 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 10 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 11 64 7.2. URN Sub-Namespace Registration for 65 urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 12 66 7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 12 67 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 74 1. Introduction 76 The Extensible Markup Language (XML) Configuration Access Protocol 77 (XCAP) [9] is a protocol that allows clients to manipulate XML 78 documents stored on a server. These XML documents serve as 79 configuration information for application protocols. As an example, 80 resource list [13] subscriptions (also known as presence lists) allow 81 a client to have a single SIP subscription to a list of users, where 82 the list is maintained on a server. The server will obtain presence 83 for those users and report it back to the client. This application 84 requires the server, called a Resource List Server (RLS), to have 85 access to the list of presentities. This list needs to be 86 manipulated by clients so they can add and remove their friends as 87 they desire. 89 Complexities arise when multiple clients attempt to simultaneously 90 manipulate a document, such as a presence list. Frequently, a client 91 will keep a copy of the current list in memory, so it can render it 92 to users. However, if another client modifies the document, the 93 cached version becomes stale. This modification event must be made 94 known to all clients which have cached copies of the document, so 95 that they can fetch the most recent one. 97 To deal with this problem, clients can use a Session Initiation 98 Protocol (SIP) [11] event package [12] to subscribe to change events 99 in XCAP documents. This notification needs to indicate the specific 100 resource that changed, and how it changed. One solution for the 101 format of such a change notification would be a content indirection 102 object [15]. Though content indirection can tell a client that a 103 document has changed, it provides it with MIME Content-ID indicating 104 the new version of the document. The MIME Content-ID is not the same 105 as the entity tag, which is used by XCAP for document versioning. As 106 such, a client cannot easily ascertain whether an indication of a 107 change in a document is due to a change it just made, or due to a 108 change another client made at around the same time. Furthermore, 109 content indirections don't indicate how a document changed; they 110 would only be able to indicate that it did change. 112 To resolve these problems, this document defines a data format which 113 can convey the fact that an XML document managed by XCAP has changed. 114 This data format is an XML document format, called an XCAP diff 115 document. This format can indicate that a document has changed, and 116 provide its previous and new entity tags. It can also optionally 117 include a set of patch operations [10], which indicate how to 118 transform the document from the version prior to the change, to the 119 version after it. XML element and attribute content of XCAP 120 documents can also be delivered with this format. 122 XML documents that are equivalent for the purposes of many 123 applications may differ in their physical representation. Similar to 124 XCAP, the canonical form with comments [1] of an XML document 125 determines the logical equivalence when this format is used to patch 126 XML documents. 128 2. Terminology 130 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 131 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 132 and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] and 133 indicate requirement levels for compliant implementations. 135 This specification also defines the following additional terms: 137 Document: When the term document is used without the "XCAP diff" in 138 front of it, it refers to the XCAP document resource about whom 139 the XCAP diff document is reporting a change. 141 XCAP diff document: The XML document defined by this specification 142 that reports on a set of changes in an XCAP document resource. 144 Server: Typically an XCAP server, this is a protocol entity that 145 generates XCAP diff documents based on its knowledge of a set of 146 XCAP documents. 148 Client: Typically an XCAP client and SIP User Agent (UA), the client 149 consumes XCAP diff documents in order to reconstruct the document 150 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 [4], using the namespace identifier 'ietf' 160 defined by [6] and extended by [7]. 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 an unordered sequence of 170 , and elements followed by any number 171 of elements from other namespaces for the purposes of extensibility. 172 Any such unknown elements MUST be ignored by the client. Each 173 element specifies changes in a specific document within 174 the XCAP root. It has one mandatory attribute, "sel", and a two 175 optional attributes, "new-etag" and "previous-etag". The "sel" 176 attribute of the element identifies the specific document 177 within the XCAP root for which changes are indicated. Its content 178 MUST be a relative path reference, with the base URI being equal to 179 the XCAP root URI. The "new-etag" attribute provides the entity tag 180 (ETag) for the document after the application of the changes, 181 assuming the document exists after those changes. The "previous- 182 etag" attribute provides an identifier for the document instance 183 prior to the change. If the change being reported is the removal of 184 a document, the "previous-etag" MUST only be included and the "new- 185 etag" attribute will not be present. The "new-etag" attribute MUST 186 only exist alone when the document either exists or it was just 187 created (no patch included). Both attributes are present when a 188 patch (or series of XCAP operations) has been applied to the 189 resource. Also both attributes MAY be used to indicate an ETag 190 change without any document modifications (patches). 192 The "previous-etag" and "new-etag" need not have been sequentially 193 assigned ETags at the server. An XCAP diff document can indicate 194 changes that have occurred over a series of XCAP operations. The 195 only requirement then is that, the sequence of events, when executed 196 serially, will result in the transformation of the document with the 197 ETag "previous-etag" to the one whose ETag is "new-etag". Also the 198 series of operations do not have to be the same exact series of 199 operations that occurred at the server. 201 Each element contains either a sequence of patching 202 instructions or an indication that the body hasn't semantically 203 changed. The latter means that the document has been assigned a new 204 ETag but its content is unchanged and it is indicated by the element. Patching instructions are described by the 206 , and elements. These elements use the 207 corresponding add, replace and remove types defined in [10], and 208 define a set of patch operations that can be applied to transform the 209 document. See [10] for instructions on how this transformation is 210 effected. The element can also contain elements from 211 other namespaces for the purposes of extensibility. Any unknown 212 elements MUST be ignored. 214 Figure 1 shows element content and how corresponding 215 resource or metadata changes. An external document retrieval means 216 in practice an HTTP GET requests for a relevant resource. 218 +-----------+----------+-----------+----------+-------------------+ 219 | previous- | new- | | | not- | metadata change | 221 | | | | changed> | | 222 +-----------+----------+-----------+----------+-------------------+ 223 | xxx | yyy | * | - | resource patched, | 224 | | | | | patch included | 225 +-----------+----------+-----------+----------+-------------------+ 226 | xxx | yyy | - | - | resource patched, | 227 | | | | | external document | 228 | | | | | retrieval | 229 +-----------+----------+-----------+----------+-------------------+ 230 | xxx | yyy | - | * | only ETag changed | 231 +-----------+----------+-----------+----------+-------------------+ 232 | - | yyy | - | - | resource created | 233 | | | | | or exists, | 234 | | | | | external document | 235 | | | | | retrieval | 236 +-----------+----------+-----------+----------+-------------------+ 237 | xxx | - | - | - | resource removed | 238 +-----------+----------+-----------+----------+-------------------+ 240 Figure 1: element content / corresponding resource changes 242 Each element indicates the existing element content of an 243 XCAP document. It has one mandatory attribute, "sel", and one 244 optional attribute, "exists". The "sel" attribute of the 245 element identifies an XML element of an XCAP document. It is a 246 percent endoced relative URI following XCAP conventions when 247 selecting elements. The XCAP Node Selector MUST always locate a 248 unique node, the "exists" attribute thus shows whether an element 249 exists or not in the XCAP document. When the "exists" attribute is 250 absent from the element, the indicated element still exists 251 in the XCAP document. The located result element exists as a child 252 element of the element. It should be noted, that only the 253 full content of an element is shown if it exists, there are no 254 conventions for patching these elements. In a corner case where the 255 content of this element cannot be presented for some reason, although 256 it exists in the XCAP document, the element MUST not have 257 any child nodes. 259 As the result XML element is typically namespace qualified, all 260 needed namespace declarations MUST exist within the 261 document. The possible local namespace declarations within the 262 result element exist unmodified as in the source document, similar to 263 XCAP conventions. Other namespace references MUST be resolved from 264 the context of the or its parent elements. The prefixes of 265 qualified names (QName) [3] of XML nodes also remain as they exist 266 originally in the source XCAP document. 268 Each element indicates the existing attribute content of 269 an XCAP document. It has one mandatory attribute, "sel", and one 270 optional attribute, "exists". The "sel" attribute of the 271 element identifies an XML attribute of an XCAP document. It is a 272 percent endoced relative URI following XCAP conventions when 273 selecting attributes. The "exists" attribute indicates whether an 274 attribute exists or not in the XCAP document. When the "exists" 275 attribute is absent from the element, the indicated 276 attribute exists in the XCAP document. The child text node of the 277 element indicates the value of the located attribute. 279 4. XML Schema 281 The XML Schema for the XCAP diff format. 283 284 290 291 294 295 296 297 299 300 301 302 303 304 305 306 309 310 311 312 313 315 316 318 319 321 322 324 325 326 327 328 329 330 331 332 334 335 336 337 338 339 340 341 342 344 345 346 347 348 349 350 351 352 353 354 355 357 359 360 361 362 363 365 366 367 368 369 370 372 373 375 376 377 378 380 381 382 383 384 387 388 389 390 392 393 395 397 5. Example Document 399 The following is an example of a document compliant to the schema. 401 402 405 409 415 416 417 418 419 420 presence 421 422 424 sip:marketing@example.com 428 430 This indicates that the document with URI "http://xcap.example.com/ 431 root/resource-lists/users/sip:joe@example.com/coworkers" has changed. 432 Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but 433 actual changes are not shown. The element exists in the 434 rls-services "index" document and its full content is shown. Note 435 that the element is attached with a default namespace 436 declaration within the original document. Similarly, a "uri" 437 attribute content is shown from the same "index" document as an 438 illustrative example. 440 6. Security Considerations 442 XCAP diff documents can include changes from one document to another. 444 As a consequence, if the document itself is sensitive and requires 445 confidentiality, integrity or authentication, then the same applies 446 to the XCAP diff format. Therefore, protocols which transport XCAP 447 diff documents must provide sufficient security capabilities for 448 transporting the document itself. 450 7. IANA Considerations 452 There are several IANA considerations associated with this 453 specification. 455 7.1. application/xcap-diff+xml MIME Type 457 MIME media type name: application 459 MIME subtype name: xcap-diff+xml 461 Mandatory parameters: none 463 Optional parameters: Same as charset parameter application/xml as 464 specified in RFC 3023 [5]. 466 Encoding considerations: Same as encoding considerations of 467 application/xml as specified in RFC 3023 [5]. 469 Security considerations: See Section 10 of RFC 3023 [5] and 470 Section 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace 471 XXXX with the RFC number of this specification.]]. 473 Interoperability considerations: none. 475 Published specification: This document. 477 Applications which use this media type: This document type has 478 been used to support manipulation of resource lists [14] using 479 XCAP. 481 Additional Information: 483 Magic Number: None 485 File Extension: .xdf 487 Macintosh file type code: "TEXT" 488 Personal and email address for further information: Jonathan 489 Rosenberg, jdrosen@jdrosen.net 491 Intended usage: COMMON 493 Author/Change controller: The IETF. 495 7.2. URN Sub-Namespace Registration for 496 urn:ietf:params:xml:ns:xcap-diff 498 This section registers a new XML namespace, as per the guidelines in 499 [7] 501 URI: The URI for this namespace is 502 urn:ietf:params:xml:ns:xcap-diff. 504 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 505 Jonathan Rosenberg (jdrosen@jdrosen.net). 507 XML: 509 BEGIN 510 511 513 514 515 517 XCAP Diff Namespace 518 519 520

Namespace for XCAP Diff

521

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

522

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

525 526 527 END 529 7.3. Schema Registration 531 This section registers a new XML schema per the procedures in [7]. 533 URI: urn:ietf:params:xml:schema:xcap-diff 535 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 536 Jonathan Rosenberg (jdrosen@jdrosen.net). 538 The XML for this schema can be found as the sole content of 539 Section 4. 541 8. Acknowledgments 543 The authors would like to thank Pavel Dostal, Jeroen van Bemmel, 544 Martin Hynar and Anders Lindgren for their valuable comments. 546 9. References 548 9.1. Normative References 550 [1] "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 , 551 March 2001. 553 [2] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C 554 Recommendation REC-xml-20060816 , August 2006. 556 [3] "Namespaces in XML (Second Edition)", W3C Recommendation REC- 557 xml-names-20060816 , August 2006. 559 [4] Moats, R., "URN syntax", RFC 2141, May 1997. 561 [5] Murata, M., "XML media types", RFC 3023, January 2001. 563 [6] Moats, R., "A URN namespace for IETF documents", RFC 2648, 564 Aug. 1999. 566 [7] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, 567 January 2004. 569 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 570 Levels", BCP 14, RFC 2119, March 1997. 572 [9] Rosenberg, J., "The Extensible Markup Language (XML) 573 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 575 [10] Urpalainen, J., "An Extensible Markup Language (XML) Patch 576 Operations Framework Utilizing XML Path Language (XPath) 577 Selectors", draft-ietf-simple-xml-patch-ops-03, August 2007. 579 9.2. Informative References 581 [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 582 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 583 Session Initiation Protocol", RFC 3261, June 2002. 585 [12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 586 Notification", RFC 3265, June 2002. 588 [13] Roach, A., Campbell, B., and J. Rosenberg, "A Session 589 Initiation Protocol (SIP) Event Notification Extension for 590 Resource Lists", RFC 4662, August 2006. 592 [14] Rosenberg, J., "Extensible Markup Language (XML) Formats for 593 Representing Resource Lists", RFC 4826, May 2007. 595 [15] Burger, E., Ed., "A Mechanism for Content Indirection in 596 Session Initiation Protocol (SIP) Messages", RFC 4483, 597 May 2006. 599 Authors' Addresses 601 Jonathan Rosenberg 602 Cisco 603 Edison, NJ 604 US 606 Email: jdrosen@cisco.com 607 URI: http://www.jdrosen.net 609 Jari Urpalainen 610 Nokia 611 Itamerenkatu 11-13 612 Helsinki 00180 613 Finland 615 Phone: +358 7180 37686 616 Email: jari.urpalainen@nokia.com 618 Full Copyright Statement 620 Copyright (C) The IETF Trust (2007). 622 This document is subject to the rights, licenses and restrictions 623 contained in BCP 78, and except as set forth therein, the authors 624 retain all their rights. 626 This document and the information contained herein are provided on an 627 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 628 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 629 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 630 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 631 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 632 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 634 Intellectual Property 636 The IETF takes no position regarding the validity or scope of any 637 Intellectual Property Rights or other rights that might be claimed to 638 pertain to the implementation or use of the technology described in 639 this document or the extent to which any license under such rights 640 might or might not be available; nor does it represent that it has 641 made any independent effort to identify any such rights. Information 642 on the procedures with respect to rights in RFC documents can be 643 found in BCP 78 and BCP 79. 645 Copies of IPR disclosures made to the IETF Secretariat and any 646 assurances of licenses to be made available, or the result of an 647 attempt made to obtain a general license or permission for the use of 648 such proprietary rights by implementers or users of this 649 specification can be obtained from the IETF on-line IPR repository at 650 http://www.ietf.org/ipr. 652 The IETF invites any interested party to bring to its attention any 653 copyrights, patents or patent applications, or other proprietary 654 rights that may cover technology that may be required to implement 655 this standard. Please address the information to the IETF at 656 ietf-ipr@ietf.org. 658 Acknowledgment 660 Funding for the RFC Editor function is provided by the IETF 661 Administrative Support Activity (IASA).