idnits 2.17.1 draft-zilles-pdf-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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 723 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 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 (December 17, 2003) is 7408 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) ** 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 (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Taft 2 Internet-Draft J. Pravetz 3 Expires: June 16, 2004 S. Zilles 4 Intended Status: Informational L. Masinter 5 Adobe Systems 6 December 17, 2003 8 The application/pdf Media Type 9 draft-zilles-pdf-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 except that the right to 15 produce derivative works is not granted. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on June 16, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 PDF, the 'Portable Document Format', is a general document 41 representation language that has been in use for document exchange on 42 the Internet since 1993. This document provides an overview of the 43 PDF format, explains the mechanisms for digital signatures and 44 encryption within PDF files, and updates the media type registration 45 of 'application/pdf'. 47 1. Introduction 49 This document is intended to provide updated information on the 50 registration of the MIME Media Type "application/pdf", with 51 particular focus on the features that help mitigate security 52 concerns. This document refers to features documented in the PDF 53 References versions 1 [1], 1.3 [2], 1.4 [3] and 1.5 [4], as updated 54 by errata [5]. 56 PDF is used widely in the Internet Community. Since PDF was 57 introduced in 1993, it has grown to be a widely-used format for 58 capturing and exchanging formatted documents electronically, across 59 the Web, via e-mail, and, for that matter, virtually every other 60 document exchange mechanism. 62 PDF represents formatted documents. These documents may be structured 63 or simple. They may contain text, images, graphics and other 64 multimedia content, such as video and audio. There is support for 65 annotations, metadata, hypertext links, and bookmarks. 67 PDF supports encryption and digital signatures in the document. The 68 encryption capability is also combined with access control 69 information in a way that is intended to manage the uses that a 70 recipient can make of a document. 72 PDF usage is specified in other international standards. ISO 73 15930-1:2001 PDF/X [16] has been adopted as the exchange standard for 74 electronic documents within the Prepress community. PDF/X is a 75 profile of PDF that references the PDF Reference, Third edition [2] 76 as the source specification. 78 Another profile of PDF, known as PDF/A [17], is being developed for 79 use as an international standard as an electronic document file 80 format for long-term preservation. Following the work on PDF/X, the 81 activity is joint work between NPES (The Association for Suppliers of 82 Printing, Publishing and Converting Technologies) and AIIM 83 International (the Association for Information and Image Management, 84 International). AIIM is the secretariat for ISO/TC 171 SC2, Document 85 Imaging Applications. 87 PDF usage is widespread enough for 'application/pdf' to be used in 88 other IETF specifications. RFC2346 [15] describes how to better 89 structure PDF files for international exchange of documents where 90 different paper sizes are used; HTTP byte range retrieval is 91 illustrated using application/pdf (RFC2616 [14], Section 19.2); 92 RFC3297 [13] illustrates how PDF can be sent to a recipient that 93 identifies his ability to accept the PDF using content negotiation. 95 2. History 97 PDF was originally envisioned as a way to communicate and view 98 printed information electronically reliably across a wide variety of 99 machine configurations, operating systems and communication networks. 101 PDF relies on the same imaging model as the PostScript page 102 description language to render complex text, images and graphics in a 103 device and resolution-independent manner, bringing this feature to 104 the screen as well as the printer. To improve performance for 105 interactive viewing, PDF defines a more structured format than that 106 used by most PostScript language programs. PDF also includes objects, 107 such as hypertext links and annotations, that are not part of the 108 page itself but are useful for building collections of related 109 documents and for reviewing and commenting on documents. 111 The application/pdf media type was first registered in 1993 by Paul 112 Lindner for use by the gopher protocol; the registration was 113 subsequently updated in 1994 by Steve Zilles. 115 3. Fragment identifiers 117 The handling of fragment identifiers [6] is currently defined in 118 Adobe Technical Note 5428 [7]. This section summarizes that material. 120 A fragment identifier consists of one or more PDF-open parameters in 121 a single URL, separated by the ampersand (&) or pound (#) character. 122 Each parameter implies an action to be performed and the value to be 123 used for that action. Actions are processed and executed from left to 124 right as they appear in the character string that makes up the 125 fragment identifier. 127 The PDF-open parameters allow the specification of a particular page 128 or named destination to open. Named destinations are similar to the 129 "anchors" used in HTML or the IDs used in XML. Once the target is 130 specified, the view of the page in which it occurs can be specified, 131 either by specifying the position of a viewing rectangle and its 132 scale or size coordinates or by specifying a view relative to the 133 viewing window in which the chosen page is to be presented. 135 The list of PDF-open parameters and the action they imply is: 137 nameddest= 138 Open to a specified named destination (which includes a view). 140 page= 141 Open the specified (physical) page. 143 zoom=,, 144 Set the and scrolling factors. and are 145 measured from the top left corner of the page independent of the 146 size of the page. The pair and are optional but 147 both must appear if present. 149 view=, 150 Set the view to show some specified portion of the page or its 151 bounding box; keywords are defined by Table 8.2 of the PDF 152 Reference, version 1.5. The value is required for 153 some of the keywords and not allowed for others. 155 viewrect=,,, 156 As with the zoom parameter, set the scale and scrolling factors, 157 but using an explicit width and height instead of a scale 158 percentage. 160 highlight=,,, 161 Highlight a rectangle on the chosen page where , , 162 and are the coordinates of the sides of the rectangle 163 measured from the top left corner of the page. 165 All specified actions are executed in order; later actions will 166 override the effects of previous action; for this reason, page 167 actions should appear before zoom actions. Commands are not case 168 sensitive (except for the value of a named destination). 170 4. Encryption 172 PDF files allow access to be controlled using encryption and 173 permission settings. The keys to decrypt document data, and 174 permission settings for a document, are provided by encryption 175 handlers. An 'Encryption Dictionary' is provided in the document 176 trailer to enable encryption handlers to store document-specific 177 information. Different encryption handlers can provide for different 178 sets of permissions. The PDF encoding rules for password and public 179 key encryption handlers is specified in the PDF Reference. 181 A person that is able to 'access' a document is said to be able to 182 open and view the document. Access is possible when a person can 183 provide the key with which to decrypt the document. The key is 184 protected and provided by the encryption handler. Encryption handlers 185 will normally require some sort of authentication before a person can 186 access the document decryption key. 188 Encryption of PDF files is normally applied to all string and 189 stream data in the document, and only to string and stream data. By 190 encrypting only data portions of the PDF file, random access to PDF 191 file contents is maintained. The data is normally encrypted using 192 40 to 128-bit RC4 [8] encryption algorithm. Use of decryption 193 filters allows algorithms other than RC4 to be used. 195 The person that has access to a document will be given certain 196 permissions for the document. A person that has full permissions, 197 including permission to save a document without encryption, is said 198 to be an 'owner'. A person that has restricted permissions is said to 199 be a 'user'. Example permissions include the ability to copy text and 200 other content from the PDF file, the ability to fill in form field 201 data, and the ability to print the PDF file. Enforcement of 202 permissions is the responsibility of the viewing application. 204 Password encryption allows the possibility of two different passwords 205 to be used when providing access to the document. The 'author' 206 password allows access to the document and full permissions, 207 including the permission to save the document without encryption. The 208 'user' password allows access to the document, but access is 209 restricted by a set of permissions. 211 Public key encryption of PDF files uses one or more PKCS#7 [9] 212 objects to store information regarding recipients that are able to 213 open a document. Each PKCS#7 object contains a list of recipients, a 214 document decryption key, and permission settings that apply to all 215 recipients listed for that PKCS#7 object. The document decryption key 216 is protected with a triple-DES key that is encrypted once with the 217 public key of each listed recipient. 219 5. Digital Signatures 221 A digital signature can be used to authenticate the identity of a 222 user and the validity of a document's contents. PDF supports the 223 association of a digital signature with a complete record that is 224 needed to reproduce a visual representation of what a person saw when 225 they signed the PDF file. PDF digital signatures allows for multiple 226 signers to update and sign the same document; a subsequent user may 227 then view the state of the document at each point when any individual 228 signature was applied. 230 The full specification for PDF digital signatures is contained in the 231 PDF Reference [4] section 8.7 and Appendix I; an overview is provided 232 here. 234 PDF signature information is stored in a 'signature dictionary' data 235 structure. A signature is created by computing a digest of the data 236 stored in the document. To verify the signature, the digest is 237 recomputed and compared with the one stored in the document. 238 Differences in the digest values indicate that modifications have 239 been made since the document was signed. 241 All bytes of the PDF file are covered by the signature digest, 242 including the signature dictionary, but excluding the signature value 243 itself. The range of bytes is defined and stored as the value of the 244 ByteRange key in the signature dictionary. The ByteRange value is an 245 array of integer pairs, where each pair includes a starting byte 246 offset and length in bytes. There are two pairs, one describing the 247 range of bytes preceeding the signature value, and the other 248 describing the range of bytes that occur after the signature value. 250 PDF public key digital signature syntax is specified for PKCS#1 [11] 251 and PKCS#7 [9] signatures. In both cases, all bytes of the PDF file 252 are signed, with the exclusion of the PKCS#1 or PKCS#7, signature 253 value, objects. 255 The signature dictionary contains additional attributes. The 256 'SubFilter' attribute describes the encoding of the signature 257 value, and the 'Contents' attribute contains the signature value 258 which is normally hex (base16) encoded. There are currently three 259 recommended SubFilter types: 261 adbe.x509.rsa_sha1 262 In this case the Contents key contains a DER-encoded PKCS#1 [11] 263 binary data object representing the signature obtained as the 264 RSA encryption of the byte range SHA-1 digest with the signer's 265 private key. When using PKCS#1, the certificate chain of the 266 signer is included with other signature information in the 267 signed document. 269 adbe.pkcs7.sha1 270 In this case the Contents key contains a DER-encoded PKCS#7 271 binary data object containing the signature obtained as the RSA 272 encryption of the SHA-1 digest of the byte range SHA-1 digest 273 with the signer's private key. The byte range SHA-1 digest is 274 encapsulated in the PKCS#7 signed-data field. 276 adbe.pkcs7.detached 277 In this case the Contents key contains a DER-encoded PKCS#7 278 detached binary data object containing the signature obtained as 279 the RSA encryption of the byte range SHA-1 digest with the 280 signer's private key. No data is encapsulated in the PKCS#7 281 signed-data field. 283 If the type of signature is 'adbe.x509.rsa_sha1', the signature 284 dictionary includes a key named 'Cert', which contains at least the 285 signer's X.509 public-key certificate represented as a binary string. 286 The value could also be an array of strings where the first entry is 287 the signer's certificate and the following entries are one or more 288 issuer certifications from the signer's trust chain. 290 If the type of signature is 'adbe.pkcs7.sha1' or 291 'adbe.pkcs7.detached', the 'Cert' key is not used and the certificate 292 must be put in the PKCS#7 object stored in the 'Contents' key. The 293 minimum required certificate to include in the PKCS#7 object is the 294 signer's X.509 signing certificate. It may optionally contain also 295 one or more issuer certifications from the signer's trust chain. 297 Multiple signatures are supported using the incremental save 298 capabilities of PDF. When changes to a file are made and a new 299 signature is applied to the document, the changes are appended after 300 the last byte of the previously existing document and then the new 301 signature digest is of all bytes of the new file. In this manner 302 changes can be made to a document and new signatures added to a 303 document without invalidating earlier signatures that have been 304 applied to the PDF file. Any change to a document is detected because 305 all bytes of the PDF file are digested. 307 The state of a signed document, when an earlier signature of a 308 multiple signature document was applied, can be viewed by extracting 309 the earlier set of bytes of the file and opening them in a PDF 310 viewing application. This process is called 'rollback' and allows 311 viewing of the exact state of the document when it was signed. 313 PDF syntax allows for 'author' and 'user' signatures. Under normal 314 circumstances the first signature of a document is considered an 315 author signature and all other signatures are considered user 316 signatures. Authors can specify what changes are to be allowed to the 317 PDF file before the author's signature is presented as invalid. 318 Example changes include the ability to fill in form field data, the 319 ability to add comments to a document, the ability to make no 320 changes, and the ability to make any changes. Changes are detected by 321 opening the existing document and the author's version of the 322 document and performing a complete object compare of the two 323 documents. Change detection is not a substitute for the legal value 324 of document rollback. 326 6. Intellectual Property 328 Adobe Systems Incorporated makes intellectual property claims and 329 grants rights, related to PDF, in the PDF Reference, Fourth 330 Edition[4], as amended by errata[5]. Those claims and grants (as 331 amended, and with references to 'this book' modified appropriately) 332 are reproduced here: 334 The general idea of using an interchange format for electronic 335 documents is in the public domain. Anyone is free to devise a set 336 of unique data structures and operators that define an interchange 337 format for electronic documents. However, Adobe Systems 338 Incorporated owns the copyright for the particular data structures 339 and operators and the written specification constituting the 340 interchange format called the Portable Document Format. Thus, 341 these elements of the Portable Document Format may not be copied 342 without Adobe's permission. 344 Adobe will enforce its copyright. Adobe's intention is to maintain 345 the integrity of the Portable Document Format standard. This 346 enables the public to distinguish between the Portable Document 347 Format and other interchange formats for electronic documents. 348 However, Adobe desires to promote the use of the Portable Document 349 Format for information interchange among diverse products and 350 applications. Accordingly, Adobe gives anyone copyright 351 permission, subject to the conditions stated below, to: 353 * Prepare files whose content conforms to the Portable Document 354 Format 356 * Write drivers and applications that produce output represented 357 in the Portable Document Format 359 * Write software that accepts input in the form of the Portable 360 Document Format and displays, prints, or otherwise interprets 361 the contents 363 * Copy Adobe's copyrighted list of data structures and operators, 364 as well as the example code and PostScript language function 365 definitions in the written specification, to the extent 366 necessary to use the Portable Document Format for the purposes 367 above. 369 The conditions of such copyright permission are: 371 * Authors of software that accepts input in the form of the 372 Portable Document Format must make reasonable efforts to ensure 373 that the software they create respects the access permissions 374 and permissions controls listed in Table 3.20 of the PDF 375 Reference [4]}, to the extent that they are used in any 376 particular document. These access permissions express the 377 rights that the document's author has granted to users of the 378 document. It is the responsibility of Portable Document Format 379 consuming software to respect the author's intent. 381 * Anyone who uses the copyrighted list of data structures and 382 operators, as stated above, must include an appropriate 383 copyright notice. 385 This limited right to use the copyrighted list of data structures 386 and operators does not include the right to copy the PDF 387 Reference, other copyrighted material from Adobe, or the software 388 in any of Adobe's products that use the Portable Document Format, 389 in whole or in part, nor does it include the right to use any 390 Adobe patents, except as may be permitted by an official Adobe 391 Patent Clarification Notice [12]. 393 Acrobat, Acrobat Capture, Adobe Reader, ePaper, the "Get Adobe 394 Reader" Web logo, the "Adobe PDF" Web logo, and all other 395 trademarks, service marks, and logos used by Adobe (the "Marks") 396 are the registered trademarks or trademarks of Adobe Systems 397 Incorporated in the United States and other countries. Nothing in 398 the PDF Reference is intended to grant you any right or license to 399 use the Marks for any purpose. 401 7. PDF implementations 403 There are a number of widely available, independently implemented, 404 interoperable implementations of PDF for a wide variety of platforms 405 and systems. Because PDF is a publicly available specification, 406 hundreds of companies and organizations make PDF creation, viewing, 407 and manipulation tools. For examples, see descriptions or tools 408 lists from Adobe [20], Apple [21], Ghostscript [22], Planet PDF [18] 409 and PDFzone.com [19]. 411 8. Security considerations 413 An "application/pdf" resource contains information to be parsed and 414 processed by the recipient's PDF system. Because PDF is both a 415 representation of formatted documents and a container system for the 416 resources need to reproduce or view said documents, it is possible 417 that a PDF file has embedded resources not described in the PDF 418 Reference. 420 Although it is not a defined feature of PDF, a PDF processor could 421 extract these resources and store them on the recipients system. 422 Furthermore, PDF processor may accept and execute "plug-in" modules 423 accessible to the recipient. These may also access material in the 424 PDF file or on the recipients system. Therefore, care in establishing 425 the source, security and reliability of such plug-ins is recommended. 426 Message-sending software should not make use of arbitrary plug-ins 427 without prior agreement on their presence at the intended recipients. 428 Message-receiving and -displaying software should make sure that any 429 non-standard plug-ins are secure and do not present a security 430 threat. 432 PDF may contain "scripts" to customize the displaying and processing 433 of PDF files. These scripts are expressed in a version of JavaScript 434 [10] based on JavaScript version 1.5 of ISO-16262 (formerly known as 435 ECMAScript). These scripts have access to an API that is similar to 436 the "plug-in" API. They are intended for execution by the PDF 437 processor. Some such script might compromise the security of the 438 system when executed. 440 In addition, JavaScript code might modify the appearance of a PDF 441 document. For this reason, validation of digital signatures should 442 take this into account. 444 In general, any information stored outside of the direct control of 445 the user -- including referenced application software or plug-ins and 446 embedded files, scripts or other material not covered in the PDF 447 reference -- can be a source of insecurity, by either obvious or 448 subtle means. For example, a script can modify the content of a 449 document prior to its being displayed. Thus, the security of any PDF 450 document may be dependent on the resources referenced by that 451 document. 453 As noted above, PDF provides mechanism for helping insure the 454 integrity of a PDF file, Encryption (Section 4), and to be able to 455 digitally sign (Section 5) a PDF file. The latter capability allows a 456 recipient to decide if he is willing to trust the file. 458 Where there is concern that tampering with the PDF file might be a 459 problem it is recommended that the encryption and digital signature 460 features be used to protect and authoritate the PDF. 462 In addition, PDF processors may have mechanisms that track the source 463 of scripts or plug-ins and will execute only those scripts or 464 plug-ins that meet the processors requirements for trustworthiness of 465 the sources. 467 9. IANA considerations 469 This document updates the registration of 'application/pdf', a media 470 type registration as defined in Multipurpose Internet Mail Extensions 471 (MIME) Part Four: Registration Procedures [23]: 473 MIME media type name: 474 application 476 MIME subtype name: 477 pdf 479 Required parameters: 480 none 482 Optional parameter: 483 none 485 Encoding considerations: 486 PDF files frequently contain binary data, and thus must be 487 encoded in non-binary contexts. 489 Security considerations: 490 See Security Considerations section of this document. 492 Interoperability considerations: 493 See PDF Implementations section of this document. 495 Published specification: 496 Adobe Systems Incorporated, "PDF Reference, Fourth Edition", 497 Version 1.5, August 2003, 498 http://partners.adobe.com/asn/tech/pdf/specifications.jsp, 499 as amended by errata 500 http://partners.adobe.com/asn/acrobat/sdk/public/docs/errata.txt. 502 Applications which use this media type: 503 See PDF Implementations section of this document. 505 Additional information: 507 Magic number(s): 508 All PDF files start with the characters '%PDF-' using the PDF 509 version number, e.g., '%PDF-1.4'. These characters are in 510 US-ASCII encoding. 512 File extension(s): 513 .pdf 515 Macintosh File Type Code(s): 516 "PDF " 518 For further information: 519 Adobe Developer Support 520 Adobe Systems Incorporated 521 345 Park Ave 522 San Jose, CA 95110 523 http://www.adobe.com/support/main.html 525 Intended usage: 526 COMMON 528 Author/Change controller: 529 Adobe Developer Support 530 Adobe Systems Incorporated 531 345 Park Ave 532 San Jose, CA 95110 533 http://www.adobe.com/support/main.html 535 References 537 [1] Adobe Systems Incorporated, "Portable Document Format Reference 538 Manual", Version 1.0, ISBN: 0-201-62628-4, Addison-Wesley, New 539 York NY, 1993. 541 [2] Adobe Systems Incorporated, "PDF Reference, Second Edition", 542 Version 1.3, ISBN: 0-201-61588-6, Addison-Wesley, New York NY, 543 2000. 545 [3] Adobe Systems Incorporated, "PDF Reference, Third Edition", 546 Version 1.4, ISBN: 0-201-75839-3, Addison-Wesley, New York NY, 547 November 2001. 549 [4] Adobe Systems Incorporated, "PDF Reference, Fourth Edition", 550 Version 1.5, August 2003, . 553 [5] Adobe Systems Incorporated, "Errata for PDF Reference, Fourth 554 Edition", December 2003, . 557 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 558 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 559 1998. 561 [7] Adobe Systems Incorporated, "PDF Open Parameters", Technical 562 Note 5428, May 2003, . 565 [8] Rivest, R., "RC4 - an unpublished, trade secret encryption 566 algorithm", November 1993, . 569 [9] RSA Laboratories, "PKCS #7 - Cryptographic Message Syntax 570 Standard", Version 1.5, November 1993, . 573 [10] Adobe Systems Incorporated, "Acrobat JavaScript Scripting 574 Reference", Technical Note 5431, September 2003, . 577 [11] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 578 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 579 3447, February 2003. 581 Informative References 583 [12] Adobe Systems, "Adobe Patent Clarification Notice", . 586 [13] Klyne, G., Iwazaki, R. and D. Crocker, "Content Negotiation for 587 Messaging Services based on Email", RFC 3297, July 2002. 589 [14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 590 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 591 HTTP/1.1", RFC 2616, June 1999. 593 [15] Palme, J., "Making Postscript and PDF International", RFC 2346, 594 May 1998. 596 [16] International Standards Organization, "Graphic technology -- 597 Prepress digital data exchange -- Use of PDF -- Part 1: 598 Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a)", ISO 599 15930-1:2001, November 2002. 601 [17] Association for Information and Image Management, "PDF-Archive 602 Committee home page", December 2003, . 605 [18] Planet PDF, "Planet PDF Tools List", December 2003, . 608 [19] InternetBiz.net, "PDF software from the PDF zone toolbox", 609 December 2003, . 611 [20] Adobe Systems Incorporated, "Adobe products page", December 612 2003, . 614 [21] Apple Computer, Inc., "Apple Mac OS X Features - Preview", 615 December 2003, . 617 [22] Artifex Software, Inc, "Ghostscript", December 2003, . 620 [23] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 621 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 622 2048, November 1996. 624 Authors' Addresses 626 Edward A. Taft 627 Adobe Systems 628 345 Park Ave 629 San Jose, CA 95110 630 US 632 EMail: taft@adobe.com 634 James D. Pravetz 635 Adobe Systems 636 345 Park Ave 637 San Jose, CA 95110 638 US 640 EMail: jpravetz@adobe.com 642 Stephen Zilles 643 Adobe Systems 644 345 Park Ave 645 San Jose, CA 95110 646 US 648 Phone: +1 408 536 7692 649 EMail: szilles@adobe.com 651 Larry Masinter 652 Adobe Systems 653 345 Park Ave 654 San Jose, CA 95110 655 US 657 Phone: +1 408 536 3024 658 EMail: LMM@acm.org 659 URI: http://larry.masinter.net 661 Intellectual Property Statement 663 The IETF takes no position regarding the validity or scope of any 664 intellectual property or other rights that might be claimed to 665 pertain to the implementation or use of the technology described in 666 this document or the extent to which any license under such rights 667 might or might not be available; neither does it represent that it 668 has made any effort to identify any such rights. Information on the 669 IETF's procedures with respect to rights in standards-track and 670 standards-related documentation can be found in BCP-11. Copies of 671 claims of rights made available for publication and any assurances of 672 licenses to be made available, or the result of an attempt made to 673 obtain a general license or permission for the use of such 674 proprietary rights by implementors or users of this specification can 675 be obtained from the IETF Secretariat. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights which may cover technology that may be required to practice 680 this standard. Please address the information to the IETF Executive 681 Director. 683 Full Copyright Statement 685 Copyright (C) The Internet Society (2003). All Rights Reserved. 687 This document and translations of it may be copied and furnished to 688 others, and derivative works that comment on or otherwise explain it 689 or assist in its implementation may be prepared, copied, published 690 and distributed, in whole or in part, without restriction of any 691 kind, provided that the above copyright notice and this paragraph are 692 included on all such copies and derivative works. However, this 693 document itself may not be modified in any way, such as by removing 694 the copyright notice or references to the Internet Society or other 695 Internet organizations, except as needed for the purpose of 696 developing Internet standards in which case the procedures for 697 copyrights defined in the Internet Standards process must be 698 followed, or as required to translate it into languages other than 699 English. 701 The limited permissions granted above are perpetual and will not be 702 revoked by the Internet Society or its successors or assignees. 704 This document and the information contained herein is provided on an 705 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 706 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 707 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 708 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 709 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 711 Acknowledgment 713 Funding for the RFC Editor function is currently provided by the 714 Internet Society.