idnits 2.17.1 draft-wilde-xml-patch-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 10, 2014) is 3601 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2045' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 392, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft UC Berkeley 4 Intended status: Informational June 10, 2014 5 Expires: December 12, 2014 7 A Media Type for XML Patch Operations 8 draft-wilde-xml-patch-10 10 Abstract 12 The XML Patch document format defines an XML document structure for 13 expressing a sequence of patch operations to be applied to an XML 14 document. The XML Patch document format builds on the foundations 15 defined in RFC 5261. This specification also provides the media type 16 registration "application/xml-patch+xml", to allow the use of XML 17 Patch documents in, for example, HTTP conversations. 19 Note to Readers 21 This draft should be discussed on the apps-discuss mailing list [1]. 23 Online access to all versions and files is available on github [2]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 12, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Patch Documents . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Patch Document Format . . . . . . . . . . . . . . . . . . 4 62 2.2. Patch Examples . . . . . . . . . . . . . . . . . . . . . . 5 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. From -09 to -10 . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. From -08 to -09 . . . . . . . . . . . . . . . . . . . . . 7 68 5.3. From -07 to -08 . . . . . . . . . . . . . . . . . . . . . 7 69 5.4. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 8 70 5.5. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 8 71 5.6. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 8 72 5.7. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 8 73 5.8. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 9 74 5.9. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 9 75 5.10. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 9 76 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 78 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Appendix A. Implementation Hints . . . . . . . . . . . . . . . . 11 80 A.1. Matching Namespaces . . . . . . . . . . . . . . . . . . . 11 81 A.2. Patching Namespaces . . . . . . . . . . . . . . . . . . . 12 82 Appendix B. Implementation Status . . . . . . . . . . . . . . . . 14 83 Appendix C. ABNF for RFC 5261 . . . . . . . . . . . . . . . . . . 15 84 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 16 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 1. Introduction 89 The Extensible Markup Language (XML) [RFC3023] is a common format for 90 the exchange and storage of structured data. HTTP PATCH [RFC5789] 91 extends HTTP [RFC2616] with a method to perform partial modifications 92 to resources. HTTP PATCH requires that patch documents be sent along 93 with the request, and it is therefore useful for there to be 94 standardized patch document formats (identified by media types) for 95 popular media types. 97 The XML Patch media type "application/xml-patch+xml" is an XML 98 document structure for expressing a sequence of operations to apply 99 to a target XML document, suitable for use with the HTTP PATCH 100 method. Servers can freely choose which patch formats they want to 101 accept, and "application/xml-patch+xml" could be a simple default 102 format that can be used unless a server decides to use a different 103 (maybe more sophisticated) patch format for XML. 105 The format for patch documents is based on the XML Patch Framework 106 defined in RFC 5261 [RFC5261]. While RFC 5261 does define a concrete 107 syntax as well as the media type "application/patch-ops-error+xml" 108 for error documents, it only defines XML Schema (XSD) 109 [W3C.REC-xmlschema-1-20041028] types for patch operations. The 110 concrete document format and the media type for patch operations are 111 defined in an XSD defined in this specification. 113 This specification relies on RFC 5261, but also requires that the 114 known errata are taken into account. The main reason for the errata 115 are the problematic ways in which RFC 5261 relies on XPath as the 116 expression language for selecting the location of a patch, while at 117 the same time XPath's data model does not contain sufficient 118 information to determine whether such a selector indeed can be used 119 for a patch operation, or should result in an error. Specifically, 120 the problem occurs with namespaces, where XPath does not expose 121 namespace declaration attributes, while the patch model needs them to 122 determine whether a namespace patch is allowed or not. Appendix A 123 contains more information about the general problem, and the errata 124 themselves are available through the regular IETF errata system. 126 2. Patch Documents 128 The following section describe and illustrate the XML patch document 129 format. 131 2.1. Patch Document Format 133 The XML patch document format is based on a simple schema that uses a 134 "patch" element as the document element, and allows an arbitrary 135 sequence of "add", "remove", and "replace" elements as the children 136 of the document element. These children follow the semantics defined 137 in RFC 5261, which means that each element is treated as an 138 individual patch operation, and the result of each patch operation is 139 a patched XML document that is the target XML document for the next 140 patch operation. 142 The following simple example patch document contains a single patch 143 operation. This operation adds a new attribute called "new- 144 attribute" to the document element of the target XML document. An 145 XML patch document always uses a "patch" element in the 146 "urn:ietf:rfc:XXXX" namespace as the document element, which then 147 contains zero or more patch operation elements, which are also in the 148 "urn:ietf:rfc:XXXX" namespace. 149 150 value 151 153 The following more complex example patch document uses the example 154 from RFC 5261 section A.18 (but changing the example namespaces to 155 example.com URIs); it uses the same "patch" element and XML namespace 156 as shown in the simpler example. It shows the general structure of 157 an XML patch document with multiple operations, as well as an example 158 of each operation. 159 162 163 164 165 166 167 168 Patched doc 169 170 new attr 171 173 As this example demonstrates, both the document element "patch" and 174 the patch operation elements are in the same XML namespace. This is 175 the result of RFC 5261 only defining types for the patch operation 176 elements, which then can be reused in schemas to define concrete 177 patch elements. 179 RFC 5261 defines an XML Schema (XSD) [W3C.REC-xmlschema-1-20041028] 180 for the patch operation types. The following schema for the XML 181 Patch media type is based on the types defined in RFC 5261, which are 182 imported as "rfc5261.xsd" in the following schema. The schema 183 defines a "patch" document element, and then allows an unlimited (and 184 possibly empty) sequence of the "add", "remove", and "replace" 185 operation elements, which are directly based on the respective types 186 from the schema defined in RFC 5261. 187 189 190 191 192 193 194 195 196 197 198 199 201 2.2. Patch Examples 203 Since the semantics of the XML patch operations are defined by RFC 204 5261, please refer to the numerous examples in that specification for 205 more XML patch document examples. All the examples in RFC 5261 can 206 be taken as examples for the XML Patch media type, when looking at 207 them with two minor changes in mind: 209 The two differences are that XML patch documents always use the 210 "patch" element as the document element, and that both the "patch" 211 element as well as the individual operation elements in XML patch 212 documents have to be in the XML namespace with the URI 213 "urn:ietf:rfc:XXXX". 215 For example, consider the patch example in RFC 5621 "Appendix A.1: 216 Adding an Element". In this example, the patch is applied to the 217 following XML document: 218 219 220 This is a sample document 221 223 The patch example is based on the following patch document (with the 224 element and namespace changes described above): 226 227 228 This is a new child 229 231 Applying the patch results in the following XML document: 232 233 234 This is a sample document 235 This is a new child 237 3. IANA Considerations 239 The Internet media type [RFC6838] for an XML Patch Document is 240 application/xml-patch+xml. 242 Type name: application 244 Subtype name: xml-patch+xml 246 Required parameters: none 248 Optional parameters: 250 charset: Same as charset parameter for the media type 251 "application/xml" as specified in RFC 3023 [RFC3023]. 253 Encoding considerations: Same as encoding considerations of media 254 type "application/xml" as specified in RFC 3023 [RFC3023]. 256 Security considerations: This media type has all of the security 257 considerations described in RFC 3023 [RFC3023], RFC 5261 258 [RFC5261], and RFC 3470 [RFC3470], plus those listed in Section 4. 260 Interoperability considerations: N/A 262 Published specification: RFC XXXX 264 Applications that use this media type: Applications that 265 manipulate XML documents. 267 Additional information: 269 Magic number(s): N/A 271 File extension(s): XML documents often use ".xml" as the file 272 extension, and this media type does not propose a specific 273 extension other than this generic one. 275 Macintosh file type code(s): TEXT 277 Person & email address to contact for further information: Erik 278 Wilde 280 Intended usage: COMMON 282 Restrictions on usage: none 284 Author: Erik Wilde 286 Change controller: IETF 288 4. Security Considerations 290 The Security Considerations from RFC 5261 [RFC5261] apply to the 291 application/xml-patch+xml media type. 293 In addition, parsing XML may entail including information from 294 external sources through XML's mechanism of external entities. 295 Implementations therefore should be aware of the fact that standard 296 parsers may resolve external entities, and thus include external 297 information as a result of applying patch operations to an XML 298 document. 300 5. Change Log 302 Note to RFC Editor: Please remove this section before publication. 304 5.1. From -09 to -10 306 o Fixed abstract. 308 5.2. From -08 to -09 310 o Editorial changes suggested by Tony Hansen. 312 5.3. From -07 to -08 314 o Updated author address. 316 o Removed rfc/@updates (this draft no longer updates RFC 5261). 318 o Added simple example of an XML patch document. 320 o No more open issues, thus removed the "open issues" section. 322 5.4. From -06 to -07 324 o Moving category back to "info" (from "std"), because the errata to 325 RFC 5261 are now approved separately. 327 o Removing the section with "Updates to RFC 5261" because that's 328 done via errata now. 330 o Adding reference to RFC 3470 to "Security Considerations". 332 o Updating the ABNF to correctly only allow lowercase characters in 333 the string parts. 335 5.5. From -05 to -06 337 o Updating "Implementation Status" section to refer to RFC 6982 338 [RFC6982]. 340 o Properly listing "charset" as an optional media type parameter 341 (was ill-formatted before). 343 o Adding corrections from Tony Hansen's review, including document 344 structure (section/appendix order), and improvements of the ABNF 345 grammar. 347 o Moving category back to "std" (from "info"), because that's was 348 needed for an RFC that is updating an RFC that has been published 349 on the standards track. 351 5.6. From -04 to -05 353 o Improved formatting of XML/XSD and ABNF code. 355 o Moving category from "std" to "info" (intended to become an 356 informational RFC). 358 5.7. From -03 to -04 360 o Added text and section "Updates to RFC 5261" about updating RFC 361 5261 (instead of relying on errata). 363 5.8. From -02 to -03 365 o Added section on "Implementation Status" (Appendix B). 367 o Improved "Implementation Hints" (Appendix A). 369 5.9. From -01 to -02 371 o Textual edits. 373 o Added section on "Implementation Hints" (Appendix A). 375 5.10. From -00 to -01 377 o Removed Mark Nottingham from author list. 379 o Changed media type name to application/xml-patch+xml (added suffix 380 per draft-ietf-appsawg-media-type-suffix-regs) 382 o Added ABNF grammar derived from XSD (Appendix C) 384 6. References 386 6.1. Normative References 388 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 389 Extensions (MIME) Part One: Format of Internet Message 390 Bodies", RFC 2045, November 1996. 392 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 393 Extensions (MIME) Part Two: Media Types", RFC 2046, 394 November 1996. 396 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 397 Types", RFC 3023, January 2001. 399 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 400 the Use of Extensible Markup Language (XML) within IETF 401 Protocols", BCP 70, RFC 3470, January 2003. 403 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 404 Specifications: ABNF", STD 68, RFC 5234, January 2008. 406 [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch 407 Operations Framework Utilizing XML Path Language (XPath) 408 Selectors", RFC 5261, September 2008. 410 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 411 Specifications and Registration Procedures", BCP 13, 412 RFC 6838, January 2013. 414 6.2. Informative References 416 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 417 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 418 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 420 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 421 RFC 5789, March 2010. 423 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 424 Code: The Implementation Status Section", RFC 6982, 425 July 2013. 427 [W3C.REC-DOM-Level-3-Core-20040407] 428 Robie, J., Wood, L., Champion, M., Hegaret, P., Nicol, G., 429 Le Hors, A., and S. Byrne, "Document Object Model (DOM) 430 Level 3 Core Specification", World Wide Web Consortium 431 Recommendation REC-DOM-Level-3-Core-20040407, April 2004, 432 . 434 [W3C.REC-xml-20081126] 435 Sperberg-McQueen, C., Yergeau, F., Paoli, J., Maler, E., 436 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 437 Edition)", World Wide Web Consortium Recommendation REC- 438 xml-20081126, November 2008, 439 . 441 [W3C.REC-xml-names-20091208] 442 Hollander, D., Layman, A., Bray, T., Tobin, R., and H. 443 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 444 Wide Web Consortium Recommendation REC-xml-names-20091208, 445 December 2009, 446 . 448 [W3C.REC-xmlschema-1-20041028] 449 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 450 "XML Schema Part 1: Structures Second Edition", World Wide 451 Web Consortium Recommendation REC-xmlschema-1-20041028, 452 October 2004, 453 . 455 [W3C.REC-xpath-19991116] 456 DeRose, S. and J. Clark, "XML Path Language (XPath) 457 Version 1.0", World Wide Web Consortium 458 Recommendation REC-xpath-19991116, November 1999, 459 . 461 [W3C.REC-xpath20-20101214] 462 Boag, S., Berglund, A., Kay, M., Simeon, J., Robie, J., 463 Chamberlin, D., and M. Fernandez, "XML Path Language 464 (XPath) 2.0 (Second Edition)", World Wide Web Consortium 465 Recommendation REC-xpath20-20101214, December 2010, 466 . 468 URIs 470 [1] 472 [2] 474 Appendix A. Implementation Hints 476 This section is informative. It describes some issues that might be 477 interesting for implementers, but it might also be interesting for 478 users of XML Patch that want to understand some of the differences 479 between standard XPath 1.0 processing, and the processing model of 480 selectors in RFC 5261. 482 Specifically, the issues described in the following two sections have 483 been identified as technical issues with RFC 5261, and have been 484 filed as errata. Implementers interested in implementing XML Patch 485 are encouraged to take those errata into account when implementing 486 XML patch documents. The issue about "Matching Namespaces" described 487 in Appendix A.1 has been filed as RFC erratum 3477. The issue about 488 "Patching Namespaces" described in Appendix A.2 has been filed as RFC 489 erratum 3478. 491 A.1. Matching Namespaces 493 RFC 5261 defines standard rules for matching prefixed names in 494 expressions: Any prefixes are interpreted according to the namespace 495 bindings of the diff document (the document that the expression is 496 applied against). This means that each prefixed name can be 497 interpreted in the context of the diff document. 499 For unprefixed names in expressions, the rules depart from XPath 1.0 500 [W3C.REC-xpath-19991116]. XPath 1.0 defines that unprefixed names in 501 expressions match namespace-less names (i.e., there is no "default 502 namespace" for names used in XPath 1.0 expressions). RFC 5261 503 requires, however, that unprefixed names in expressions must use the 504 default namespace of the diff document (if there is one). This means 505 that it is not possible to simply take a selector from a patch 506 document and evaluate it in the context of the diff document 507 according to the rules of XPath 1.0, because this would interpret 508 unprefixed names incorrectly. As a consequence, it is not possible 509 to simply take an XPath 1.0 processor and evaluate XML Patch 510 selectors in the context of the diff document. 512 As an extension of XPath 1.0's simple model, XPath 2.0 513 [W3C.REC-xpath20-20101214] specifies different processing rules for 514 unprefixed names: They are matched against the URI of the "default 515 element/type namespace", which is defined as part of an expression's 516 static context. In some XPath 2.0 applications, this can be set; 517 XSLT 2.0 for example has the ability to define an "xpath-default- 518 namespace", which then will be used to match unprefixed names in 519 expressions. Thus, by using an XPath 2.0 implementation that allows 520 to set this URI, and setting it to the default namespace of the diff 521 document (or leaving it undefined if there is no such default 522 namespace), it is possible to use an out-of-the-box XPath 2.0 523 implementation for evaluating XML Patch selectors. 525 Please keep in mind, however, that evaluating selectors is only one 526 part of applying patches. When it comes to applying the actual patch 527 operation, neither XPath 1.0 nor XPath 2.0 are sufficient because 528 they do not preserve some of the information from the XML syntax 529 (specifically: namespace declarations) that is required to correctly 530 apply patch operations. The following section describes this issue 531 in more detail. 533 Please note that RFC 5261's Section 4.2.2 on namespace matching 534 explains XPath 2.0's rules incorrectly 535 . For this reason, 536 RFC erratum 3477 is available for Section 4.2.2 of RFC 5261. 538 A.2. Patching Namespaces 540 One of the issues when patching namespaces based on XPath is that 541 XPath exposes namespaces differently than the XML 1.0 542 [W3C.REC-xml-20081126] syntax for XML Namespaces 543 [W3C.REC-xml-names-20091208]. In the XML syntax, a namespace is 544 declared with an attribute using the reserved name or prefix "xmlns", 545 and this results in this namespace being available recursively 546 through the document tree. In XPath, the namespace declaration is 547 not exposed as an attribute (i.e., the attribute, although 548 syntactically an XML attribute, is not accessible in XPath), but the 549 resulting namespace nodes are exposed recursively through the tree. 551 RFC 5261 uses the terms "namespace declaration" and "namespace" 552 almost interchangeably, but it is important to keep in mind that the 553 namespace declaration is an XML syntax construct that is unavailable 554 in XPath, while the namespace itself is a logical construct that is 555 not visible in the XML syntax, but a result of a namespace 556 declaration. The intent of RFC 5261 is to patch namespaces as if 557 namespace declarations were patched, and thus it only allows patching 558 namespace nodes on the element nodes where the namespace has been 559 declared. 561 Patching namespaces in XML Patch is supposed to "emulate" the effect 562 of actually changing the namespace declaration (which is why a 563 namespace can only be patched at the element where it has been 564 declared). Therefore, when patching a namespace, even though XPath's 565 "namespace" axis is used, implementations have to make sure that not 566 only the single selected namespace node is being patched, but that 567 all namespaces nodes resulting from the namespace declaration of this 568 namespace are also patched accordingly. 570 This means that an implementation might have to descend into the 571 tree, matching all namespace nodes with the selected prefix/URI pair 572 recursively, until it encounters leaf elements or namespace 573 declarations with the same prefix it is patching. Determining this 574 requires access to the diff document beyond XPath, because in XPath 575 itself namespace declarations are not represented, and thus such a 576 recursive algorithm wouldn't know when to stop. Consider the 577 following document: 578 579 580 582 If this document is patched with a selector of /x/namespace::a, then 583 only the namespace node on element x should be patched, even though 584 the namespace node on element y has the same prefix/URI combination 585 as the one on element x. However, determining that the repeated 586 namespace declaration was present at all on element y is impossible 587 when using XPath alone, which means that implementations must have an 588 alternative way to determine the difference between the document 589 above, and this one: 590 591 592 594 In this second example, patching with a selector of /x/namespace::a 595 should indeed change the namespace nodes on elements x and y, because 596 they both have been derived from the same namespace declaration. 598 The conclusion of these considerations is that for implementing XML 599 Patch, access closer to the XML syntax (specifically: access to 600 namespace declarations) is necessary. As a result, implementations 601 attempting to exclusively use the XPath model for implementing XML 602 Patch will fail to correctly address certain edge cases (such as the 603 one shown above). 605 Note that XPath's specific limitations do not mean that it is 606 impossible to use XML technologies other than XPath. The Document 607 Object Model (DOM) [W3C.REC-DOM-Level-3-Core-20040407], for example, 608 does expose namespace declaration attributes as regular attributes in 609 the document tree, and thus could be used to differentiate between 610 the two variants shown above. 612 Please note that RFC 5261's Section 4.4.3 on replacing namespaces 613 mixes the terms "namespace declaration" and "namespace". For this 614 reason, RFC erratum 3478 is available for Section 4.4.3 of RFC 5261. 616 Appendix B. Implementation Status 618 Note to RFC Editor: Please remove this section before publication. 620 This section records the status of known implementations of the 621 protocol defined by this specification at the time of posting of this 622 Internet-Draft, and is based on a proposal described in RFC 6982 623 [RFC6982]. The description of implementations in this section is 624 intended to assist the IETF in its decision processes in progressing 625 drafts to RFCs. Please note that the listing of any individual 626 implementation here does not imply endorsement by the IETF. 627 Furthermore, no effort has been spent to verify the information 628 presented here that was supplied by IETF contributors. This is not 629 intended as, and must not be construed to be, a catalog of available 630 implementations or their features. Readers are advised to note that 631 other implementations may exist. 633 According to RFC 6982, "this will allow reviewers and working groups 634 to assign due consideration to documents that have the benefit of 635 running code, which may serve as evidence of valuable experimentation 636 and feedback that have made the implemented protocols more mature. 637 It is up to the individual working groups to use this information as 638 they see fit". 640 EMC: EMC's IIG unit has implemented the selector part of the 641 specification, which is the trickiest part (see Appendix A.1 for 642 an explanation). By reusing an existing XPath 1.0 implementation 643 and changing it to match the changed default namespace processing 644 model, the required behavior is fairly easy to implement. This 645 does, however, require that the implementation is available in 646 source code, and also does require some changes to the 647 implementation's code. The resulting implementation is closed 648 source and will be made available, if released, as part of EMC's 649 XML database product xDB 650 . 652 Appendix C. ABNF for RFC 5261 654 RFC 5261 [RFC5261] does not contain an ABNF grammar for the allowed 655 subset of XPath expressions, but includes an XSD-based grammar in its 656 type definition for operation types). In order to make 657 implementation easier, this appendix contains an ABNF grammar that 658 has been derived from the XSD expressions in RFC 5261. In the 659 following grammar, "xpath" is the definition for the allowed XPath 660 expressions for remove and replace operations, and "xpath-add" is the 661 definition for the allowed XPath expressions for add operations. The 662 names of all grammar productions are the ones used in the XSD-based 663 grammar of RFC 5261. 665 anychar = %x00-ffffffff 666 ncname = 1*%x00-ffffffff 667 qname = [ ncname ":" ] ncname 668 aname = "@" qname 669 pos = "[" 1*DIGIT "]" 670 attr = ( "[" aname "='" 0*anychar "']" ) / 671 ( "[" aname "=" DQUOTE 0*anychar DQUOTE "]" ) 672 valueq = "[" ( qname / "." ) "=" DQUOTE 0*anychar DQUOTE "]" 673 value = ( "[" ( qname / "." ) "='" 0*anychar "']" ) / valueq 674 cond = attr / value / pos 675 step = ( qname / "*" ) 0*cond 676 piq = %x70.72.6f.63.65.73.73.69.6e.67.2d 677 %x69.6e.73.74.72.75.63.74.69.6f.6e 678 ; "processing-instruction", case-sensitive 679 "(" [ DQUOTE ncname DQUOTE ] ")" 680 pi = ( %x70.72.6f.63.65.73.73.69.6e.67.2d 681 %x69.6e.73.74.72.75.63.74.69.6f.6e 682 ; "processing-instruction", case-sensitive 683 "(" [ "'" ncname "'" ] ")" ) / piq 684 id = ( %x69.64 ; "id", case-sensitive 685 "(" [ "'" ncname "'" ] ")" ) / 686 ( %x69.64 ; "id", case-sensitive 687 "(" [ DQUOTE ncname DQUOTE ] ")" ) 688 com = %x63.6f.6d.6d.65.6e.74 ; "comment", case-sensitive 689 "()" 690 text = %x74.65.78.74 ; "text", case-sensitive 691 "()" 692 nspa = %x6e.61.6d.65.73.70.61.63.65 ; "namespace", case-sensitive 693 "::" ncname 694 cnodes = ( text / com / pi ) [ pos ] 695 child = cnodes / step 696 last = child / aname / nspa 697 xpath = [ "/" ] ( ( id [ 0*( "/" step ) "/" last ] ) / 698 ( 0*( step "/" ) last ) ) 699 xpath-add = [ "/" ] ( ( id [ 0*( "/" step ) "/" child ] ) / 700 ( 0*( step "/" ) child ) ) 702 Please note that the "ncname" production listed above does not fully 703 capture the constraints of the original XSD-based definition, where 704 it is defined as "\i\c*". DIGIT and DQUOTE are defined by the ABNF 705 specification [RFC5234]. 707 Appendix D. Acknowledgements 709 Thanks for comments and suggestions provided by Bas de Bakker, Tony 710 Hansen, Bjoern Hoehrmann, and Julian Reschke. 712 Author's Address 714 Erik Wilde 715 UC Berkeley 717 Email: dret@berkeley.edu 718 URI: http://dret.net/netdret/