idnits 2.17.1 draft-ietf-xmldsig-xpf2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([XML-DSig]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 2003) is 7553 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) -- Looks like a reference, but probably isn't: '1' on line 440 ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Downref: Normative reference to an Informational RFC: RFC 3076 (ref. 'XML-C14N') -- Possible downref: Non-RFC (?) normative reference: ref. 'XML-NS' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPath' -- Possible downref: Non-RFC (?) normative reference: ref. 'XPointer' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT John Boyer 2 PureEdge Solutions 3 Merlin Hughes 4 Baltimore Technologies 5 Joseph Reagle 6 W3C 7 Expires: February 2004 August 2003 9 XML-Signature XPath Filter 2.0 10 ------------- ----- ---------- 11 13 Status of This Document 15 Distribution of this draft is unlimited. Comments should be sent to 16 the XMLDSIG working group mailing list and 17 to the authors. 19 This document is an Internet Draft and is in full conformance with 20 all provisions of Section 10 of RFC 2026. Internet Drafts are 21 working documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working groups. Note that other groups may also 23 distribute working documents as Internet Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) 2003 The Internet Society & W3C (MIT, INRIA, Keio), All 39 Rights Reserved. 41 Abstract 43 XML Signature [XML-DSig] recommends a standard means for specifying 44 information content to be digitally signed and for representing the 45 resulting digital signatures in XML. Some applications require the 46 ability to specify a subset of a given XML document as the 47 information content to be signed. The XML Signature specification 48 meets this requirement with the XPath transform. However, this 49 transform can be difficult to implement efficiently with existing 50 technologies. This specification defines a new XML Signature 51 transform to facilitate the development of efficient document 52 subsetting implementations that interoperate under similar 53 performance profiles. 55 W3C Status of this document 57 W3C Recommendation 08 November 2002 59 This version: 60 http://www.w3.org/TR/2002/REC-xmldsig-filter2-20021108/ 61 Errata: 62 http://www.w3.org/2002/11/xpath-filter2-errata.html 63 Latest version: 64 http://www.w3.org/TR/xmldsig-filter2/ 66 This document is the W3C XML Signature XPath-Filter 2.0 67 Recommendation. This document has been reviewed by W3C Members and 68 other interested parties and has been endorsed by the Director as a 69 W3C Recommendation. It is a stable document and may be used as 70 reference material or cited as a normative reference from another 71 document. W3C's role in making the Recommendation is to draw 72 attention to the specification and to promote its widespread 73 deployment. This enhances the functionality and interoperability of 74 the Web. 76 Table of Contents 78 Status of This Document....................................1 79 Copyright Notice...........................................1 81 Abstract...................................................2 82 W3C Status of this document................................2 84 Table of Contents..........................................3 86 1. Introduction............................................4 87 1.1. Acknowledgements (Informative)........................5 89 2. Terminology.............................................6 91 3. Specification of Signature Filter Transform.............7 92 3.1 Algorithm Identifier...................................7 93 3.2 Syntax of Signature Filter Transform...................7 94 3.3 Input and Evaluation Context of Signature Filter 95 Transform............................................8 96 3.4 Processing Model of Signature Filter Transform.........9 98 4. Examples of Signature Filter Transform.................12 99 5. Normative References...................................16 100 Changes from Draft-00 to Draft-01.........................16 102 Authors Addresses.........................................17 104 Full Copyright Statement..................................18 105 Expiration and File Name..................................18 107 1. Introduction 109 The XML Recommendation [XML] specifies the syntax of a class of 110 objects called XML documents. The Namespaces in XML Recommendation 111 [XML-NS] specifies additional syntax and semantics for XML documents. 112 The XML Signature Recommendation [XML-DSig] defines standard means 113 for specifying information content to be digitally signed, including 114 the ability to select a portion of an XML document to be signed using 115 an XPath transform. 117 This specification describes a new signature filter transform that, 118 like the XPath transform [XML-DSig, section 6.6.3], provides a method 119 for computing a portion of a document to be signed. In the interest 120 of simplifying the creation of efficient implementations, the 121 architecture of this transform is not based on evaluating an [XPath] 122 expression for every node of the XML parse tree (as defined by the 123 [XPath] data model). Instead, a sequence of XPath expressions is used 124 to select the roots of document subtrees -- location sets, in the 125 language of [XPointer] -- which are combined using set intersection, 126 subtraction and union, and then used to filter the input node-set. 127 The principal differences from the XPath transform are: 129 * A sequence of XPath operations can be executed in a single 130 transform, allowing complex filters to be more easily expressed 131 and optimized. 132 * The XPath expressions are evaluated against the input document 133 resulting in a set of nodes, instead of being used as a boolean 134 test against each node of the input node-set. 135 * To increase efficiency, the expansion of a given node to include 136 all nodes having the given node as an ancestor is now implicit 137 so it can be performed by faster means than the evaluation of an 138 XPath expression for each document node. 139 * The resulting node-sets can be combined using the three 140 fundamental set operations (intersection, subtraction, and 141 union), and then applied as a filter against the input node-set, 142 allowing operations such as signing an entire document except 143 for a specified subset, to be expressed more clearly and 144 efficiently. 146 As with the original XPath transform, the primary purpose of this 147 transform is to ensure that only specifically defined changes to the 148 input XML document are permitted after the signature is affixed. This 149 can be done by excluding precisely those nodes that are allowed to 150 change once the signature is affixed, and including all other input 151 nodes in the output. It is the responsibility of the signature filter 152 transform author to ensure that nodes are not excluded which could 153 affect the interpretation of the transform output in the application 154 context. 156 Consider the motivating scenario where an application wishes to affix 157 two enveloped signatures to the document; any other change to the 158 document must cause the signatures to be invalid. When the 159 application creates the first signature that signature is 160 automatically omitted from its own digest calculations. However, it 161 will also be necessary to exclude the subsequent (second) signature 162 element from the digest calculations of the first signature. This 163 specification can be used to efficiently satisfy this requirement 164 using the set subtraction operation. 166 This transform also supports the ability to specify a set of nodes 167 that will be included in a signature, with all non-specified nodes 168 being excluded. This formulation is useful for isolating a portion 169 of a document, such as a chapter of a document, or a payload in a 170 protocol message, and can be expressed using the set intersection 171 operation. 173 Complete familiarity with the first XML Signature XPath Transform 174 [XML-DSig, section 6.6.3] is required. 176 NOTE: Since XPath Filter 2.0 depends on details of XPath, be sure to 177 take into account the XPath Errata at . 180 1.1. Acknowledgements (Informative) 182 The following people provided valuable feedback that improved the 183 quality of this specification: 185 * Christian Geuer-Pollmann, Universitat Siegen 186 * Donald Eastlake 3rd, Motorola 187 * Gregor Karlinger, IAIK TU Graz 188 * Aleksey Sanin 190 2. Terminology 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [Keywords]. 196 The XPath 1.0 Recommendation [XPath] defines the term node-set as 197 "(an unordered collection of nodes without duplicates)" and specifies 198 a data model for representing an input XML document as a set of nodes 199 of various types (element, attribute, namespace, text, comment, 200 processing instruction, and root). 202 An input document is the document that contains all the nodes 203 available to processing by this transform. A document subset is a 204 portion of an XML document indicated by an XPath node-set, which may 205 not include all of the nodes in the document. For example, the input 206 node-set is a collection of XPath nodes from the input document that 207 is passed as a parameter to this transform. A subtree rooted by a 208 given node is a document subset containing the given node and every 209 node having the given node as an ancestor. Subtree expansion is the 210 process of expanding a node-set to include all subtrees rooted at any 211 node in the node-set. For example, the subtree expansion of a node- 212 set consisting of just a single element node would be a node-set 213 containing that element, its attribute nodes, namespace nodes, and 214 all its descendants including their attribute nodes and namespaces 215 nodes. 217 The XML Signature Recommendation [XML-DSig] defines a reference as a 218 sequence of steps performed to obtain an octet stream to be digitally 219 signed. A transform is an identified algorithm to be used as a step 220 in the reference processing model. A transform takes an octet stream 221 or XPath node-set as input, and it produces an octet stream or XPath 222 node-set as output (the reference processing model automatically 223 converts the final output to an octet stream if it is an XPath node- 224 set). 226 3. Specification of Signature Filter Transform 228 The transform operates by computing a node-set that is used to filter 229 the input node-set: The output node-set consists of only those nodes 230 in both the input node-set and the filter node-set. In other words, 231 the output node-set is the intersection of the input node-set and the 232 computed filter node-set. 234 The filter node-set is computed by evaluating a sequence of XPath 235 expressions and combining their results. A node-set is initially 236 computed containing the entire input document. In sequence, each 237 XPath expression is then evaluated, subtree-expanded, and then used 238 to transform the filter node-set according to a specified set 239 operation; intersection, subtraction, or union. After all XPaths have 240 been applied, the resulting node-set is used as the filter node-set. 242 3.1 Algorithm Identifier 244 The XML Signature Recommendation [XML-DSig] uses a [URI] to identify 245 each algorithm to be performed when creating or validating a 246 signature. The signature filter transform is identified as follows: 248 Algorithm Identifier 249 http://www.w3.org/2002/06/xmldsig-filter2 251 3.2 Syntax of Signature Filter Transform 253 The signature filter transform shall be represented by a sequence of 254 one or more elements named XPath. The content of XPath is character 255 data containing an XPath expression. The XPath has an attribute named 256 Filter whose possible values are intersect, subtract, and union. The 257 Filter attribute indicates the set operation that is performed with 258 the resulting node-set when computing the filter node-set. The 259 following is an example of markup for a signature filter that signs 260 the entire input node-set except for elements with identifier foo and 261 bar (and all nodes with one of those elements as an ancestor): 263 265 id("foo bar") 266 268 Schema Definition: 270 271 277 278 279 280 ]> 282 287 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 306 308 DTD: 310 311 314 3.3 Input and Evaluation Context of Signature Filter Transform 316 The input required by this transform is an XPath node-set over the 317 input document. If the input document is an octet stream, then the 318 application MUST convert the octet stream to an XPath node-set that 319 contains all of the document nodes (including comment nodes). The 320 evaluation context for the XPath expressions in the filter transform 321 will be: 323 * A context node equal to the root node of the document whose 324 node-set was provided as input to this transform. The root node 325 is the parent of the document element and any comment and 326 processing instruction nodes outside of the document element. 327 * A context position, initialized to 1. 328 * A context size, initialized to 1. 329 * A library of functions equal to the function set defined in 330 [XPath] plus a function named here(). 331 * A set of variable bindings. No means for initializing these is 332 defined. Thus, the set of variable bindings used when 333 evaluating the XPath expression is empty, and use of a variable 334 reference in the XPath expression results in an error. 335 * The set of namespace declarations in scope for the XPath 336 element. 338 The function here() is defined as follows: 340 Function: node-set here() 342 The here() function returns a node-set containing the attribute or 343 processing instruction node or the parent element of the text node 344 that directly bears the XPath expression. In this transform, this 345 will be the XPath element. This expression results in an error if 346 the containing XPath expression does not appear in the same XML 347 document against which the XPath expression is being evaluated. 349 3.4 Processing Model of Signature Filter Transform 351 Using the aforementioned evaluation context, the signature filter 352 transform evaluates the XPath expressions appearing in the character 353 content of the XPath elements and uses these to compute a filter 354 node-set F, which is then used to filter the input node-set I 355 resulting in an output node-set O: 357 * Initialize the filter node-set F to consist of all nodes in the 358 input document. 359 * Iterate through each XPath expression, X, in sequence, and update 360 the filter node-set F as follows: 361 * 362 o Evaluate the XPath expression X. The result is a node-set S. 363 o Compute the set S' consisting of all nodes in the input 364 document that are either present in S or that have an 365 ancestor in S. This is equal to the union of all the 366 document subtrees rooted by a node in S. 368 o If the Filter attribute value is intersect, then compute the 369 intersection of the selected subtrees, S', with the filter 370 node-set F. The result will include only those nodes that 371 are in both the filter node-set and the selected subtrees: 372 F' = F INTERSECT S'. 373 o If the Filter attribute value is subtract, then compute the 374 subtraction of the selected subtrees, S', from the filter 375 node-set F. The result will include only those nodes that 376 are in the filter node-set, but not the selected subtrees: 377 F' = F - S'. 378 o Otherwise, if the Filter attribute value is union, then 379 compute the union the selected subtrees, S', with the 380 filter node-set F. The result will include all those nodes 381 that are in either the filter node-set, the selected 382 subtrees, or both: F' = F UNION S'. 383 o Update the filter node-set F to be the new node-set F'. 384 * Finally, after applying all the XPath expressions, compute the 385 output node-set O to be the intersection of the computed filter 386 node-set, F, with the input node-set, I. The result will include 387 all nodes from the input node-set that are also in the filter 388 node-set: O = I INTERSECT F. 389 * An empty input node-set will always result in an empty output 390 node-set. 392 In this processing model, the conversion from a subtree 393 interpretation of the XPath expressions to a node-set containing all 394 nodes that must be used during the set operation, along with actual 395 performance of the set operation, is described explicitly. 396 Implementors SHOULD observe that it is possible to compute the 397 effective result of this operation in a single pass through the input 398 document without performing subtree expansion or any set operations: 400 * For each XPath expression X, in sequence, evaluate the expression 401 and store the resulting node-set, S, along with the associated 402 set operation. 403 * Prepend a node-set consisting of just the document node, along 404 with the operation union. 405 * Create a new, empty filter node-set. 406 * Process each node in the input node-set document, adding each 407 node to the output node-set F if a flag Z is true. The flag is 408 computed as follows: 409 o Z is true if and only if the node is present in any subtree- 410 expanded union node-set and all subsequent subtree-expanded 411 intersect node-sets but no subsequent subtree-expanded 412 subtract node-sets, or false otherwise. If there are no 413 subsequent intersect or subtract node-sets, then that part 414 of the test is automatically passed. 415 o Presence in a subtree-expanded node-set can be efficiently 416 determined without actually expanding the node-set, by 417 simply maintaining a stack or count that identifies whether 418 any nodes from that node-set are an ancestor of the node 419 being processed. 421 Implementers MAY further observe that, if this transform is followed 422 by a canonicalization operation (e.g., [XML-C14N]), the described 423 filter computation can be efficiently commingled with the document- 424 order canonicalization processing. 426 4. Examples of Signature Filter Transform 428 The example below illustrates one way to create an enveloped 429 signature with the signature filter transform. The function here() 430 identifies the XPath element, and the subsequent location path 431 obtains the nearest ancestor Signature element. Due to the subtract 432 value of the Filter attribute, the output of the signature filter 433 transform is a node-set containing every node from the input node-set 434 except the nodes in the subtree rooted by the Signature element 435 containing the example signature filter transform below. 437 440 here()/ancestor::dsig:Signature[1] 441 443 A suitable signature reference URI to use with this subtract filter 444 would be URI="" (the entire signature document, without comments), 445 URI="#xpointer(/)" (the entire signature document, with comments) or 446 any same-document reference that includes the signature itself. 448 An example of an intersect filter is a signature that co-signs 449 another signature. In this example, a Signature element identified by 450 PrimaryBorrowSig must be signed. The XPath expression obtains the 451 element node, and the transform expands the output node-set to 452 contain all nodes from the input node-set that are also in the 453 subtree rooted by the element node. 455 457 id("PrimaryBorrowerSig") 458 460 This type of intersect filter is useful for efficiently signing 461 subsets of a document, whether this is the same document as the 462 signature or an external document. For example, if the signature 463 reference URI is URI="document.xml", then this document will be 464 automatically parsed and just the identified element and its 465 descendants will be signed. 467 Union filters, by themselves are of no particular use: The initial 468 filter node-set consists of the entire input document; any union with 469 this will have no effect, so the output of the transform will be 470 identical to the input. The union operation is intended to follow a 471 subtract operation, to allow a subtree to be removed, with the 472 exception of a lower subtree which is still included in the output. 474 Consider the following document which contains a same-document 475 enveloped signature reference with an XPath filter containing three 476 XPath operations: 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 498 499 ... 500 501 502 504 //ToBeSigned 506 //NotToBeSigned 508 //ReallyToBeSigned 510 511 512 ... 513 514 515 ... 516 517 519 The intersect operation computes the intersection of the XPath- 520 selected subtrees with the filter node-set. In this case, the filter 521 node-set initially contains the entire input document, and the XPath 522 expression evaluates to the two ToBeSigned elements; these are 523 expanded to include all their descendents and intersected with the 524 filter node-set, resulting in the following: 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 542 The subtract filter computes the subtraction of the XPath-selected 543 subtrees from the filter node-set. In this case, the XPath expression 544 evaluates to the two NotToBeSigned elements; these are expanded to 545 include all their descendents and subtracted from the filter node- 546 set: 548 549 550 552 553 555 557 Next, the union filter computes the union of the XPath-selected 558 subtrees with the filter node-set. In this case, the XPath expression 559 evaluates to the ReallyToBeSigned element; this is expanded to 560 include all its descendents and added to the filter node-set: 562 563 564 565 566 567 568 569 570 572 574 Finally, this resulting filter node-set is used to transform the 575 input node-set. In this example, the input node-set is the entire 576 document, with comments removed. The transformed node-set will thus 577 be all those nodes from the input document, less comments, that are 578 also in the filter node-set: 580 582 583 585 586 587 588 590 592 Note that the result contains no nodes that were not in the input 593 node-set. Although the filter node-set included comments, these were 594 not present in the input node-set so they are not present in the 595 output node-set. 597 This signature filter does not provide any increased capability over 598 the original XPath transform. For example, this reference could be 599 replicated using the XPath transform as follows. 601 602 603 605 606 (ancestor-or-self::ToBeSigned and 607 not (ancestor-or-self::NotToBeSigned)) 608 or ancestor-or-self::ReallyToBeSigned 609 610 611 612 ... 613 615 The advantage of the signature filter transform over the XPath 616 transform is that the latter requires evaluation of a potentially- 617 complex expression against every node in the input set, which has has 618 proved costly in practice for many useful operations. This 619 specification's filter requires evaluation of simple XPath 620 expressions and then the execution of some basic set operations or 621 their equivalent, which can be implemented significantly more 622 efficiently. 624 5. Normative References 626 [Keywords] - RFC 2119, "Key words for use in RFCs to Indicate 627 Requirement Levels", S. Bradner. Best Current Practice, March 1997. 629 [URI] - RFC 2396, "Uniform Resource Identifiers (URI): Generic 630 Syntax", T. Berners-Lee, R. Fielding, and L. Masinter. Standards 631 Track, August 1998. 633 [XML] - "Extensible Markup Language (XML) 1.0 (Second Edition)", T. 634 Bray, E. Maler, J. Paoli, and C. M. Sperberg-McQueen. W3C 635 Recommendation, October 2000. Available at 636 . 638 [XML-C14N] - RFC 3076, "Canonical XML", J. Boyer, March 2001. Also a 639 W3C Recommendation available at . 642 [XML-DSig] - RFC 3275, "XML-Signature Syntax and Processing", D. 643 Eastlake, J. Reagle, and D. Solo, Standards Track, March 2002. Also 644 a W3C Recommendation available at . 647 [XML-NS] - "Namespaces in XML", T. Bray, D. Hollander, and A. Layman. 648 W3C Recommendation, January 1999. Available at 649 . 651 [XPath] - "XML Path Language (XPath) Version 1.0", J. Clark and S. 652 DeRose. W3C Recommendation, November 1999. Available at 653 . (Note also XPath 654 Errara at .) 656 [XPointer] - "XML Pointer Language (XPointer)", S. DeRose, R. Daniel, 657 and E. Maler. W3C Candidate Recommendation, January 2001. Available 658 at . 660 Changes from Draft-00 to Draft-01 662 Add references to "XPath" and "XPath Filter 2.0" Errata. 664 Change two occurances of "—" to "--". 666 Add "3rd" to one occurance of "Donald Eastlake". 668 Authors Addresses 670 John Boyer 671 PureEdge Solutions Inc. 672 4396 West Saanich Rd. 673 Victoria, BC, Canada V8Z 3E9 675 Phone: 1-888-517-2675 676 EMail: jboyer@PureEdge.com 678 Merlin Hughes 679 Baltimore Technologies, Ltd. 680 77 A Street 681 Needham Heights, MA 02494 683 Telephone: +1-781-455-3333 684 EMail: merlin@baltimore.ie 686 Joseph M. Reagle Jr., W3C 687 Massachusetts Institute of Technology 688 Laboratory for Computer Science 689 NE43-350, 545 Technology Square 690 Cambridge, MA 02139 692 Phone: +1.617.258.7621 693 EMail: reagle@w3.org 695 Full Copyright Statement 697 Copyright (C) 2003 The Internet Society & W3C (MIT, INRIA, Keio), All 698 Rights Reserved. 700 This document and translations of it may be copied and furnished to 701 others, and derivative works that comment on or otherwise explain it 702 or assist in its implementation may be prepared, copied, published 703 and distributed, in whole or in part, without restriction of any 704 kind, provided that the above copyright notice and this paragraph are 705 included on all such copies and derivative works. However, this 706 document itself may not be modified in any way, such as by removing 707 the copyright notice or references to the Internet Society or other 708 Internet organizations, except as needed for the purpose of 709 developing Internet standards in which case the procedures for 710 copyrights defined in the Internet Standards process must be 711 followed, or as required to translate it into languages other than 712 English. 714 The limited permissions granted above are perpetual and will not be 715 revoked by the Internet Society or its successors or assigns. 717 This document and the information contained herein is provided on an 718 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 719 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 720 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 721 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 722 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 724 Expiration and File Name 726 This draft expires February 2004. 728 Its file name is .