idnits 2.17.1 draft-zilles-pdf-02.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 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 (January 19, 2004) is 7403 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) == Unused Reference: '12' is defined on line 495, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 3447 (ref. '11') (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '14') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. '23') (Obsoleted by RFC 4288, RFC 4289) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Taft 3 Internet-Draft J. Pravetz 4 Expires: July 19, 2004 S. Zilles 5 L. Masinter 6 Adobe Systems 7 January 19, 2004 9 The application/pdf Media Type 10 draft-zilles-pdf-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 except that the right to 16 produce derivative works is not granted. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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 http:// 28 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 July 19, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 PDF, the 'Portable Document Format', is a general document 42 representation language that has been in use for document exchange on 43 the Internet since 1993. This document provides an overview of the 44 PDF format, explains the mechanisms for digital signatures and 45 encryption within PDF files, and updates the media type registration 46 of 'application/pdf'. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Fragment identifiers . . . . . . . . . . . . . . . . . . . . . 4 53 4. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 6 55 6. PDF implementations . . . . . . . . . . . . . . . . . . . . . 8 56 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 57 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 58 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 Informative References . . . . . . . . . . . . . . . . . . . . 11 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 61 Intellectual Property and Copyright Statements . . . . . . . . 14 63 1. Introduction 65 This document is intended to provide updated information on the 66 registration of the MIME Media Type "application/pdf", with 67 particular focus on the features that help mitigate security 68 concerns. This document refers to features documented in the PDF 69 References versions 1 [1], 1.3 [2], 1.4 [3] and 1.5 [4], as updated 70 by errata [5]. 72 PDF is used widely in the Internet Community. Since PDF was 73 introduced in 1993, it has grown to be a widely-used format for 74 capturing and exchanging formatted documents electronically, across 75 the Web, via e-mail, and, for that matter, virtually every other 76 document exchange mechanism. 78 PDF represents formatted documents. These documents may be structured 79 or simple. They may contain text, images, graphics and other 80 multimedia content, such as video and audio. There is support for 81 annotations, metadata, hypertext links, and bookmarks. 83 PDF supports encryption and digital signatures in the document. The 84 encryption capability is also combined with access control 85 information in a way that is intended to manage the uses that a 86 recipient can make of a document. 88 PDF usage is specified in other international standards. ISO 89 15930-1:2001 PDF/X [16] has been adopted as the exchange standard for 90 electronic documents within the Prepress community. PDF/X is a 91 profile of PDF that references the PDF Reference, Third edition [2] 92 as the source specification. 94 Another profile of PDF, known as PDF/A [17], is being developed for 95 use as an international standard as an electronic document file 96 format for long-term preservation. Following the work on PDF/X, the 97 activity is joint work between NPES (The Association for Suppliers of 98 Printing, Publishing and Converting Technologies) and AIIM 99 International (the Association for Information and Image Management, 100 International). AIIM is the secretariat for ISO/TC 171 SC2, Document 101 Imaging Applications. 103 PDF usage is widespread enough for 'application/pdf' to be used in 104 other IETF specifications. RFC2346 [15] describes how to better 105 structure PDF files for international exchange of documents where 106 different paper sizes are used; HTTP byte range retrieval is 107 illustrated using application/pdf (RFC2616 [14], Section 19.2); 108 RFC3297 [13] illustrates how PDF can be sent to a recipient that 109 identifies his ability to accept the PDF using content negotiation. 111 2. History 113 PDF was originally envisioned as a way to communicate and view 114 printed information electronically reliably across a wide variety of 115 machine configurations, operating systems and communication networks. 117 PDF relies on the same imaging model as the PostScript page 118 description language to render complex text, images and graphics in a 119 device and resolution-independent manner, bringing this feature to 120 the screen as well as the printer. To improve performance for 121 interactive viewing, PDF defines a more structured format than that 122 used by most PostScript language programs. PDF also includes objects, 123 such as hypertext links and annotations, that are not part of the 124 page itself but are useful for building collections of related 125 documents and for reviewing and commenting on documents. 127 The application/pdf media type was first registered in 1993 by Paul 128 Lindner for use by the gopher protocol; the registration was 129 subsequently updated in 1994 by Steve Zilles. 131 3. Fragment identifiers 133 The handling of fragment identifiers [6] is currently defined in 134 Adobe Technical Note 5428 [7]. This section summarizes that material. 136 A fragment identifier consists of one or more PDF-open parameters in 137 a single URL, separated by the ampersand (&) or pound (#) character. 138 Each parameter implies an action to be performed and the value to be 139 used for that action. Actions are processed and executed from left to 140 right as they appear in the character string that makes up the 141 fragment identifier. 143 The PDF-open parameters allow the specification of a particular page 144 or named destination to open. Named destinations are similar to the 145 "anchors" used in HTML or the IDs used in XML. Once the target is 146 specified, the view of the page in which it occurs can be specified, 147 either by specifying the position of a viewing rectangle and its 148 scale or size coordinates or by specifying a view relative to the 149 viewing window in which the chosen page is to be presented. 151 The list of PDF-open parameters and the action they imply is: 152 nameddest= 153 Open to a specified named destination (which includes a view). 154 page= 155 Open the specified (physical) page. 156 zoom=,, 157 Set the and scrolling factors. and are 158 measured from the top left corner of the page independent of the 159 size of the page. The pair and are optional but 160 both must appear if present. 162 view=, 163 Set the view to show some specified portion of the page or its 164 bounding box; keywords are defined by Table 8.2 of the PDF 165 Reference, version 1.5. The value is required for 166 some of the keywords and not allowed for others. 167 viewrect=,,, 168 As with the zoom parameter, set the scale and scrolling factors, 169 but using an explicit width and height instead of a scale 170 percentage. 171 highlight=,,, 172 Highlight a rectangle on the chosen page where , , 173 and are the coordinates of the sides of the rectangle 174 measured from the top left corner of the page. 176 All specified actions are executed in order; later actions will 177 override the effects of previous action; for this reason, page 178 actions should appear before zoom actions. Commands are not case 179 sensitive (except for the value of a named destination). 181 4. Encryption 183 PDF files allow access to be controlled using encryption and 184 permission settings. The keys to decrypt document data, and 185 permission settings for a document, are provided by encryption 186 handlers. An 'Encryption Dictionary' is provided in the document 187 trailer to enable encryption handlers to store document-specific 188 information. Different encryption handlers can provide for different 189 sets of permissions. The PDF encoding rules for password and public 190 key encryption handlers is specified in the PDF Reference. 192 A person that is able to 'access' a document is said to be able to 193 open and view the document. Access is possible when a person can 194 provide the key with which to decrypt the document. The key is 195 protected and provided by the encryption handler. Encryption handlers 196 will normally require some sort of authentication before a person can 197 access the document decryption key. 199 Encryption of PDF files is normally applied to all string and stream 200 data in the document, and only to string and stream data. By 201 encrypting only data portions of the PDF file, random access to PDF 202 file contents is maintained. The data is normally encrypted using 40 203 to 128-bit RC4 [8] encryption algorithm. Use of decryption filters 204 allows algorithms other than RC4 to be used. 206 The person that has access to a document will be given certain 207 permissions for the document. A person that has full permissions, 208 including permission to save a document without encryption, is said 209 to be an 'owner'. A person that has restricted permissions is said to 210 be a 'user'. Example permissions include the ability to copy text and 211 other content from the PDF file, the ability to fill in form field 212 data, and the ability to print the PDF file. Enforcement of 213 permissions is the responsibility of the viewing application. 215 Password encryption allows the possibility of two different passwords 216 to be used when providing access to the document. The 'author' 217 password allows access to the document and full permissions, 218 including the permission to save the document without encryption. The 219 'user' password allows access to the document, but access is 220 restricted by a set of permissions. 222 Public key encryption of PDF files uses one or more PKCS#7 [9] 223 objects to store information regarding recipients that are able to 224 open a document. Each PKCS#7 object contains a list of recipients, a 225 document decryption key, and permission settings that apply to all 226 recipients listed for that PKCS#7 object. The document decryption key 227 is protected with a triple-DES key that is encrypted once with the 228 public key of each listed recipient. 230 5. Digital Signatures 232 A digital signature can be used to authenticate the identity of a 233 user and the validity of a document's contents. PDF supports the 234 association of a digital signature with a complete record that is 235 needed to reproduce a visual representation of what a person saw when 236 they signed the PDF file. PDF digital signatures allows for multiple 237 signers to update and sign the same document; a subsequent user may 238 then view the state of the document at each point when any individual 239 signature was applied. 241 The full specification for PDF digital signatures is contained in the 242 PDF Reference [4] section 8.7 and Appendix I; an overview is provided 243 here. 245 PDF signature information is stored in a 'signature dictionary' data 246 structure. A signature is created by computing a digest of the data 247 stored in the document. To verify the signature, the digest is 248 recomputed and compared with the one stored in the document. 249 Differences in the digest values indicate that modifications have 250 been made since the document was signed. 252 All bytes of the PDF file are covered by the signature digest, 253 including the signature dictionary, but excluding the signature value 254 itself. The range of bytes is defined and stored as the value of the 255 ByteRange key in the signature dictionary. The ByteRange value is an 256 array of integer pairs, where each pair includes a starting byte 257 offset and length in bytes. There are two pairs, one describing the 258 range of bytes preceeding the signature value, and the other 259 describing the range of bytes that occur after the signature value. 261 PDF public key digital signature syntax is specified for PKCS#1 [11] 262 and PKCS#7 [9] signatures. In both cases, all bytes of the PDF file 263 are signed, with the exclusion of the PKCS#1 or PKCS#7, signature 264 value, objects. 266 The signature dictionary contains additional attributes. The 267 'SubFilter' attribute describes the encoding of the signature value, 268 and the 'Contents' attribute contains the signature value which is 269 normally hex (base16) encoded. There are currently three recommended 270 SubFilter types: 272 adbe.x509.rsa_sha1 273 In this case the Contents key contains a DER-encoded PKCS#1 [11] 274 binary data object representing the signature obtained as the 275 RSA encryption of the byte range SHA-1 digest with the signer's 276 private key. When using PKCS#1, the certificate chain of the 277 signer is included with other signature information in the 278 signed document. 279 adbe.pkcs7.sha1 280 In this case the Contents key contains a DER-encoded PKCS#7 281 binary data object containing the signature obtained as the RSA 282 encryption of the SHA-1 digest of the byte range SHA-1 digest 283 with the signer's private key. The byte range SHA-1 digest is 284 encapsulated in the PKCS#7 signed-data field. 285 adbe.pkcs7.detached 286 In this case the Contents key contains a DER-encoded PKCS#7 287 detached binary data object containing the signature obtained as 288 the RSA encryption of the byte range SHA-1 digest with the 289 signer's private key. No data is encapsulated in the PKCS#7 290 signed-data field. 292 If the type of signature is 'adbe.x509.rsa_sha1', the signature 293 dictionary includes a key named 'Cert', which contains at least the 294 signer's X.509 public-key certificate represented as a binary string. 295 The value could also be an array of strings where the first entry is 296 the signer's certificate and the following entries are one or more 297 issuer certifications from the signer's trust chain. 299 If the type of signature is 'adbe.pkcs7.sha1' or 300 'adbe.pkcs7.detached', the 'Cert' key is not used and the certificate 301 must be put in the PKCS#7 object stored in the 'Contents' key. The 302 minimum required certificate to include in the PKCS#7 object is the 303 signer's X.509 signing certificate. It may optionally contain also 304 one or more issuer certifications from the signer's trust chain. 306 Multiple signatures are supported using the incremental save 307 capabilities of PDF. When changes to a file are made and a new 308 signature is applied to the document, the changes are appended after 309 the last byte of the previously existing document and then the new 310 signature digest is of all bytes of the new file. In this manner 311 changes can be made to a document and new signatures added to a 312 document without invalidating earlier signatures that have been 313 applied to the PDF file. Any change to a document is detected because 314 all bytes of the PDF file are digested. 316 The state of a signed document, when an earlier signature of a 317 multiple signature document was applied, can be viewed by extracting 318 the earlier set of bytes of the file and opening them in a PDF 319 viewing application. This process is called 'rollback' and allows 320 viewing of the exact state of the document when it was signed. 322 PDF syntax allows for 'author' and 'user' signatures. Under normal 323 circumstances the first signature of a document is considered an 324 author signature and all other signatures are considered user 325 signatures. Authors can specify what changes are to be allowed to the 326 PDF file before the author's signature is presented as invalid. 327 Example changes include the ability to fill in form field data, the 328 ability to add comments to a document, the ability to make no 329 changes, and the ability to make any changes. Changes are detected by 330 opening the existing document and the author's version of the 331 document and performing a complete object compare of the two 332 documents. Change detection is not a substitute for the legal value 333 of document rollback. 335 6. PDF implementations 337 There are a number of widely available, independently implemented, 338 interoperable implementations of PDF for a wide variety of platforms 339 and systems. Because PDF is a publicly available specification, 340 hundreds of companies and organizations make PDF creation, viewing, 341 and manipulation tools. For examples, see descriptions or tools 342 lists from Adobe [20], Apple [21], Ghostscript [22], Planet PDF [18] 343 and PDFzone.com [19]. 345 7. Security considerations 347 An "application/pdf" resource contains information to be parsed and 348 processed by the recipient's PDF system. Because PDF is both a 349 representation of formatted documents and a container system for the 350 resources need to reproduce or view said documents, it is possible 351 that a PDF file has embedded resources not described in the PDF 352 Reference. 354 Although it is not a defined feature of PDF, a PDF processor could 355 extract these resources and store them on the recipients system. 356 Furthermore, PDF processor may accept and execute "plug-in" modules 357 accessible to the recipient. These may also access material in the 358 PDF file or on the recipients system. Therefore, care in establishing 359 the source, security and reliability of such plug-ins is recommended. 360 Message-sending software should not make use of arbitrary plug-ins 361 without prior agreement on their presence at the intended recipients. 362 Message-receiving and -displaying software should make sure that any 363 non-standard plug-ins are secure and do not present a security 364 threat. 366 PDF may contain "scripts" to customize the displaying and processing 367 of PDF files. These scripts are expressed in a version of JavaScript 368 [10] based on JavaScript version 1.5 of ISO-16262 (formerly known as 369 ECMAScript). These scripts have access to an API that is similar to 370 the "plug-in" API. They are intended for execution by the PDF 371 processor. User agents executing such scripts or programs must be 372 extremely careful to insure that untrusted software is executed in a 373 protected environment. 375 In addition, JavaScript code might modify the appearance of a PDF 376 document. For this reason, validation of digital signatures should 377 take this into account. 379 In general, any information stored outside of the direct control of 380 the user -- including referenced application software or plug-ins and 381 embedded files, scripts or other material not covered in the PDF 382 reference -- can be a source of insecurity, by either obvious or 383 subtle means. For example, a script can modify the content of a 384 document prior to its being displayed. Thus, the security of any PDF 385 document may be dependent on the resources referenced by that 386 document. 388 As noted above, PDF provides mechanism for helping insure the 389 integrity of a PDF file, Encryption (Section 4), and to be able to 390 digitally sign (Section 5) a PDF file. The latter capability allows a 391 recipient to decide if he is willing to trust the file. 393 Where there is concern that tampering with the PDF file might be a 394 problem it is recommended that the encryption and digital signature 395 features be used to protect and authoritate the PDF. 397 In addition, PDF processors may have mechanisms that track the source 398 of scripts or plug-ins and will execute only those scripts or 399 plug-ins that meet the processors requirements for trustworthiness of 400 the sources. 402 8. IANA considerations 404 This document updates the registration of 'application/pdf', a media 405 type registration as defined in Multipurpose Internet Mail Extensions 406 (MIME) Part Four: Registration Procedures [23]: 408 MIME media type name: application 409 MIME subtype name: pdf 410 Required parameters: none 411 Optional parameter: none 412 Encoding considerations: 413 PDF files frequently contain binary data, and thus must be 414 encoded in non-binary contexts. 415 Security considerations: 416 See Section 7 of this document. 417 Interoperability considerations: 418 See Section 6 of this document. 419 Published specification: 420 Adobe Systems Incorporated, "PDF Reference, 421 Fourth Edition", Version 1.5, August 2003, , as amended by 423 errata . 425 Applications which use this media type: 426 See Section 6 of this document. 427 Additional information: 428 Magic number(s): All PDF files start with the characters '%PDF-' 429 using the PDF version number, e.g., '%PDF-1.4'. These characters 430 are in US-ASCII encoding. 431 File extension(s): .pdf 432 Macintosh File Type Code(s): "PDF " 433 For further information: 434 Adobe Developer Support 435 Adobe Systems Incorporated 436 345 Park Ave 437 San Jose, CA 95110 438 http://www.adobe.com/support/main.html 439 Intended usage: COMMON 440 Author/Change controller: 441 Adobe Developer Support 442 Adobe Systems Incorporated 443 345 Park Ave 444 San Jose, CA 95110 445 http://www.adobe.com/support/main.html 447 References 449 [1] Adobe Systems Incorporated, "Portable Document Format Reference 450 Manual", Version 1.0, ISBN: 0-201-62628-4, Addison-Wesley, New 451 York NY, 1993. 453 [2] Adobe Systems Incorporated, "PDF Reference, Second Edition", 454 Version 1.3, ISBN: 0-201-61588-6, Addison-Wesley, New York NY, 455 2000. 457 [3] Adobe Systems Incorporated, "PDF Reference, Third Edition", 458 Version 1.4, ISBN: 0-201-75839-3, Addison-Wesley, New York NY, 459 November 2001. 461 [4] Adobe Systems Incorporated, "PDF Reference, Fourth Edition", 462 Version 1.5, August 2003, . 465 [5] Adobe Systems Incorporated, "Errata for PDF Reference, Fourth 466 Edition", December 2003, . 469 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 470 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 471 1998. 473 [7] Adobe Systems Incorporated, "PDF Open Parameters", Technical 474 Note 5428, May 2003, . 477 [8] Rivest, R., "RC4 - an unpublished, trade secret encryption 478 algorithm", November 1993, . 481 [9] RSA Laboratories, "PKCS #7 - Cryptographic Message Syntax 482 Standard", Version 1.5, November 1993, . 485 [10] Adobe Systems Incorporated, "Acrobat JavaScript Scripting 486 Reference", Technical Note 5431, September 2003, . 489 [11] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 490 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 491 3447, February 2003. 493 Informative References 495 [12] Adobe Systems, "Adobe Patent Clarification Notice", 2003, 496 . 498 [13] Klyne, G., Iwazaki, R. and D. Crocker, "Content Negotiation for 499 Messaging Services based on Email", RFC 3297, July 2002. 501 [14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 502 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 503 HTTP/1.1", RFC 2616, June 1999. 505 [15] Palme, J., "Making Postscript and PDF International", RFC 2346, 506 May 1998. 508 [16] International Standards Organization, "Graphic technology -- 509 Prepress digital data exchange -- Use of PDF -- Part 1: 510 Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a)", ISO 511 15930-1:2001, November 2002. 513 [17] Association for Information and Image Management, "PDF-Archive 514 Committee home page", December 2003, . 517 [18] Planet PDF, "Planet PDF Tools List", December 2003, . 520 [19] InternetBiz.net, "PDF software from the PDF zone toolbox", 521 December 2003, . 523 [20] Adobe Systems Incorporated, "Adobe products page", December 524 2003, . 526 [21] Apple Computer, Inc., "Apple Mac OS X Features - Preview", 527 December 2003, . 529 [22] Artifex Software, Inc, "Ghostscript", December 2003, . 532 [23] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 533 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 534 2048, November 1996. 536 Authors' Addresses 538 Edward A. Taft 539 Adobe Systems 540 345 Park Ave 541 San Jose, CA 95110 542 US 544 EMail: taft@adobe.com 545 James D. Pravetz 546 Adobe Systems 547 345 Park Ave 548 San Jose, CA 95110 549 US 550 EMail: jpravetz@adobe.com 552 Stephen Zilles 553 Adobe Systems 554 345 Park Ave 555 San Jose, CA 95110 556 US 557 Phone: +1 408 536 7692 558 EMail: szilles@adobe.com 560 Larry Masinter 561 Adobe Systems 562 345 Park Ave 563 San Jose, CA 95110 564 US 565 Phone: +1 408 536 3024 566 EMail: LMM@acm.org 567 URI: http://larry.masinter.net 569 Intellectual Property Statement 571 The IETF takes no position regarding the validity or scope of any 572 intellectual property or other rights that might be claimed to 573 pertain to the implementation or use of the technology described in 574 this document or the extent to which any license under such rights 575 might or might not be available; neither does it represent that it 576 has made any effort to identify any such rights. Information on the 577 IETF's procedures with respect to rights in standards-track and 578 standards-related documentation can be found in BCP-11. Copies of 579 claims of rights made available for publication and any assurances of 580 licenses to be made available, or the result of an attempt made to 581 obtain a general license or permission for the use of such 582 proprietary rights by implementors or users of this specification can 583 be obtained from the IETF Secretariat. 585 The IETF invites any interested party to bring to its attention any 586 copyrights, patents or patent applications, or other proprietary 587 rights which may cover technology that may be required to practice 588 this standard. Please address the information to the IETF Executive 589 Director. 591 Full Copyright Statement 593 Copyright (C) The Internet Society (2004). All Rights Reserved. 595 This document and translations of it may be copied and furnished to 596 others, and derivative works that comment on or otherwise explain it 597 or assist in its implementation may be prepared, copied, published 598 and distributed, in whole or in part, without restriction of any 599 kind, provided that the above copyright notice and this paragraph are 600 included on all such copies and derivative works. However, this 601 document itself may not be modified in any way, such as by removing 602 the copyright notice or references to the Internet Society or other 603 Internet organizations, except as needed for the purpose of 604 developing Internet standards in which case the procedures for 605 copyrights defined in the Internet Standards process must be 606 followed, or as required to translate it into languages other than 607 English. 609 The limited permissions granted above are perpetual and will not be 610 revoked by the Internet Society or its successors or assignees. 612 This document and the information contained herein is provided on an 613 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 614 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 615 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 616 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 617 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Acknowledgment 621 Funding for the RFC Editor function is currently provided by the 622 Internet Society.