idnits 2.17.1 draft-zilles-pdf-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 592. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 613), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 (February 23, 2004) is 7368 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 492, 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' ** Downref: Normative reference to an Informational RFC: RFC 2315 (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: 9 errors (**), 0 flaws (~~), 4 warnings (==), 15 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: August 23, 2004 S. Zilles 5 L. Masinter 6 Adobe Systems 7 February 23, 2004 9 The application/pdf Media Type 10 draft-zilles-pdf-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3667. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 23, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 PDF, the 'Portable Document Format', is a general document 43 representation language that has been in use for document exchange on 44 the Internet since 1993. This document provides an overview of the 45 PDF format, explains the mechanisms for digital signatures and 46 encryption within PDF files, and updates the media type registration 47 of 'application/pdf'. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Fragment identifiers . . . . . . . . . . . . . . . . . . . . . 4 54 4. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 6 56 6. PDF implementations . . . . . . . . . . . . . . . . . . . . . 8 57 7. Security considerations . . . . . . . . . . . . . . . . . . . 8 58 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 59 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 Informative References . . . . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 62 Intellectual Property and Copyright Statements . . . . . . . . 14 64 1. Introduction 66 This document is intended to provide updated information on the 67 registration of the MIME Media Type "application/pdf", with 68 particular focus on the features that help mitigate security 69 concerns. This document refers to features documented in the PDF 70 References versions 1 [1], 1.3 [2], 1.4 [3] and 1.5 [4], as updated 71 by errata [5]. 73 PDF is used widely in the Internet Community. Since PDF was 74 introduced in 1993, it has grown to be a widely-used format for 75 capturing and exchanging formatted documents electronically, across 76 the Web, via e-mail, and, for that matter, virtually every other 77 document exchange mechanism. 79 PDF represents formatted documents. These documents may be structured 80 or simple. They may contain text, images, graphics and other 81 multimedia content, such as video and audio. There is support for 82 annotations, metadata, hypertext links, and bookmarks. 84 PDF supports encryption and digital signatures in the document. The 85 encryption capability is also combined with access control 86 information in a way that is intended to manage the uses that a 87 recipient can make of a document. 89 PDF usage is specified in other international standards. ISO 90 15930-1:2001 PDF/X [16] has been adopted as the exchange standard for 91 electronic documents within the Prepress community. PDF/X is a 92 profile of PDF that references the PDF Reference, Third edition [2] 93 as the source specification. 95 Another profile of PDF, known as PDF/A [17], is being developed for 96 use as an international standard as an electronic document file 97 format for long-term preservation. Following the work on PDF/X, the 98 activity is joint work between NPES (The Association for Suppliers of 99 Printing, Publishing and Converting Technologies) and AIIM 100 International (the Association for Information and Image Management, 101 International). AIIM is the secretariat for ISO/TC 171 SC2, Document 102 Imaging Applications. 104 PDF usage is widespread enough for 'application/pdf' to be used in 105 other IETF specifications. RFC2346 [15] describes how to better 106 structure PDF files for international exchange of documents where 107 different paper sizes are used; HTTP byte range retrieval is 108 illustrated using application/pdf (RFC2616 [14], Section 19.2); 109 RFC3297 [13] illustrates how PDF can be sent to a recipient that 110 identifies his ability to accept the PDF using content negotiation. 112 2. History 114 PDF was originally envisioned as a way to communicate and view 115 printed information electronically reliably across a wide variety of 116 machine configurations, operating systems and communication networks. 118 PDF relies on the same imaging model as the PostScript page 119 description language to render complex text, images and graphics in a 120 device and resolution-independent manner, bringing this feature to 121 the screen as well as the printer. To improve performance for 122 interactive viewing, PDF defines a more structured format than that 123 used by most PostScript language programs. PDF also includes objects, 124 such as hypertext links and annotations, that are not part of the 125 page itself but are useful for building collections of related 126 documents and for reviewing and commenting on documents. 128 The application/pdf media type was first registered in 1993 by Paul 129 Lindner for use by the gopher protocol; the registration was 130 subsequently updated in 1994 by Steve Zilles. 132 3. Fragment identifiers 134 The handling of fragment identifiers [6] is currently defined in 135 Adobe Technical Note 5428 [7]. This section summarizes that material. 137 A fragment identifier consists of one or more PDF-open parameters in 138 a single URL, separated by the ampersand (&) or pound (#) character. 139 Each parameter implies an action to be performed and the value to be 140 used for that action. Actions are processed and executed from left to 141 right as they appear in the character string that makes up the 142 fragment identifier. 144 The PDF-open parameters allow the specification of a particular page 145 or named destination to open. Named destinations are similar to the 146 "anchors" used in HTML or the IDs used in XML. Once the target is 147 specified, the view of the page in which it occurs can be specified, 148 either by specifying the position of a viewing rectangle and its 149 scale or size coordinates or by specifying a view relative to the 150 viewing window in which the chosen page is to be presented. 152 The list of PDF-open parameters and the action they imply is: 153 nameddest= 154 Open to a specified named destination (which includes a view). 155 page= 156 Open the specified (physical) page. 157 zoom=,, 158 Set the and scrolling factors. and are 159 measured from the top left corner of the page independent of the 160 size of the page. The pair and are optional but 161 both must appear if present. 163 view=, 164 Set the view to show some specified portion of the page or its 165 bounding box; keywords are defined by Table 8.2 of the PDF 166 Reference, version 1.5. The value is required for 167 some of the keywords and not allowed for others. 168 viewrect=,,, 169 As with the zoom parameter, set the scale and scrolling factors, 170 but using an explicit width and height instead of a scale 171 percentage. 172 highlight=,,, 173 Highlight a rectangle on the chosen page where , , 174 and are the coordinates of the sides of the rectangle 175 measured from the top left corner of the page. 177 All specified actions are executed in order; later actions will 178 override the effects of previous action; for this reason, page 179 actions should appear before zoom actions. Commands are not case 180 sensitive (except for the value of a named destination). 182 4. Encryption 184 PDF files allow access to be controlled using encryption and 185 permission settings. The keys to decrypt document data, and 186 permission settings for a document, are provided by encryption 187 handlers. An 'Encryption Dictionary' is provided in the document 188 trailer to enable encryption handlers to store document-specific 189 information. Different encryption handlers can provide for different 190 sets of permissions. The PDF encoding rules for password and public 191 key encryption handlers is specified in the PDF Reference. 193 A person that is able to 'access' a document is said to be able to 194 open and view the document. Access is possible when a person can 195 provide the key with which to decrypt the document. The key is 196 protected and provided by the encryption handler. Encryption handlers 197 will normally require some sort of authentication before a person can 198 access the document decryption key. 200 Encryption of PDF files is normally applied to all string and stream 201 data in the document, and only to string and stream data. By 202 encrypting only data portions of the PDF file, random access to PDF 203 file contents is maintained. The data is normally encrypted using 40 204 to 128-bit RC4 [8] encryption algorithm. Use of decryption filters 205 allows algorithms other than RC4 to be used. 207 The person that has access to a document will be given certain 208 permissions for the document. A person that has full permissions, 209 including permission to save a document without encryption, is said 210 to be an 'owner'. A person that has restricted permissions is said to 211 be a 'user'. Example permissions include the ability to copy text and 212 other content from the PDF file, the ability to fill in form field 213 data, and the ability to print the PDF file. Enforcement of 214 permissions is the responsibility of the viewing application. 216 Password encryption allows the possibility of two different passwords 217 to be used when providing access to the document. The 'author' 218 password allows access to the document and full permissions, 219 including the permission to save the document without encryption. The 220 'user' password allows access to the document, but access is 221 restricted by a set of permissions. 223 Public key encryption of PDF files uses one or more PKCS#7 [9] 224 objects to store information regarding recipients that are able to 225 open a document. Each PKCS#7 object contains a list of recipients, a 226 document decryption key, and permission settings that apply to all 227 recipients listed for that PKCS#7 object. The document decryption key 228 is protected with a triple-DES key that is encrypted once with the 229 public key of each listed recipient. 231 5. Digital Signatures 233 A digital signature can be used to authenticate the identity of a 234 user and the validity of a document's contents. PDF supports the 235 association of a digital signature with a complete record that is 236 needed to reproduce a visual representation of what a person saw when 237 they signed the PDF file. PDF digital signatures allows for multiple 238 signers to update and sign the same document; a subsequent user may 239 then view the state of the document at each point when any individual 240 signature was applied. 242 The full specification for PDF digital signatures is contained in the 243 PDF Reference [4] section 8.7 and Appendix I; an overview is provided 244 here. 246 PDF signature information is stored in a 'signature dictionary' data 247 structure. A signature is created by computing a digest of the data 248 stored in the document. To verify the signature, the digest is 249 recomputed and compared with the one stored in the document. 250 Differences in the digest values indicate that modifications have 251 been made since the document was signed. 253 All bytes of the PDF file are covered by the signature digest, 254 including the signature dictionary, but excluding the signature value 255 itself. The range of bytes is defined and stored as the value of the 256 ByteRange key in the signature dictionary. The ByteRange value is an 257 array of integer pairs, where each pair includes a starting byte 258 offset and length in bytes. There are two pairs, one describing the 259 range of bytes preceeding the signature value, and the other 260 describing the range of bytes that occur after the signature value. 262 PDF public key digital signature syntax is specified for PKCS#1 [11] 263 and PKCS#7 [9] signatures. In both cases, all bytes of the PDF file 264 are signed, with the exclusion of the PKCS#1 or PKCS#7, signature 265 value, objects. 267 The signature dictionary contains additional attributes. The 268 'SubFilter' attribute describes the encoding of the signature value, 269 and the 'Contents' attribute contains the signature value which is 270 normally hex (base16) encoded. There are currently three recommended 271 SubFilter types: 273 adbe.x509.rsa_sha1 274 In this case the Contents key contains a DER-encoded PKCS#1 [11] 275 binary data object representing the signature obtained as the 276 RSA encryption of the byte range SHA-1 digest with the signer's 277 private key. When using PKCS#1, the certificate chain of the 278 signer is included with other signature information in the 279 signed document. 280 adbe.pkcs7.sha1 281 In this case the value of Contents is a DER-encoded PKCS#7 282 binary data object containing the signature. The SHA1 digest of 283 the byte range is encapsulated in the PKCS#7 signed-data field 284 with ContentInfo of type "data". 285 adbe.pkcs7.detached 286 In this case the value of Contents is a DER-encoded PKCS#7 287 binary data object containing the signature. No data is 288 encapsulated in the PKCS#7 signed-data field. 290 If the type of signature is 'adbe.x509.rsa_sha1', the signature 291 dictionary includes a key named 'Cert', which contains at least the 292 signer's X.509 public-key certificate represented as a binary string. 293 The value could also be an array of strings where the first entry is 294 the signer's certificate and the following entries are one or more 295 issuer certifications from the signer's trust chain. 297 If the type of signature is 'adbe.pkcs7.sha1' or 298 'adbe.pkcs7.detached', the 'Cert' key is not used and the certificate 299 must be put in the PKCS#7 object stored in the 'Contents' key. The 300 minimum required certificate to include in the PKCS#7 object is the 301 signer's X.509 signing certificate. It may optionally contain also 302 one or more issuer certifications from the signer's trust chain. 304 Multiple signatures are supported using the incremental save 305 capabilities of PDF. When changes to a file are made and a new 306 signature is applied to the document, the changes are appended after 307 the last byte of the previously existing document and then the new 308 signature digest is of all bytes of the new file. In this manner 309 changes can be made to a document and new signatures added to a 310 document without invalidating earlier signatures that have been 311 applied to the PDF file. Any change to a document is detected because 312 all bytes of the PDF file are digested. 314 The state of a signed document, when an earlier signature of a 315 multiple signature document was applied, can be viewed by extracting 316 the earlier set of bytes of the file and opening them in a PDF 317 viewing application. This process is called 'rollback' and allows 318 viewing of the exact state of the document when it was signed. 320 PDF syntax allows for 'author' and 'user' signatures. Under normal 321 circumstances the first signature of a document is considered an 322 author signature and all other signatures are considered user 323 signatures. Authors can specify what changes are to be allowed to the 324 PDF file before the author's signature is presented as invalid. 325 Example changes include the ability to fill in form field data, the 326 ability to add comments to a document, the ability to make no 327 changes, and the ability to make any changes. Changes are detected by 328 opening the existing document and the author's version of the 329 document and performing a complete object compare of the two 330 documents. Change detection is not a substitute for the legal value 331 of document rollback. 333 6. PDF implementations 335 There are a number of widely available, independently implemented, 336 interoperable implementations of PDF for a wide variety of platforms 337 and systems. Because PDF is a publicly available specification, 338 hundreds of companies and organizations make PDF creation, viewing, 339 and manipulation tools. For examples, see descriptions or tools 340 lists from Adobe [20], Apple [21], Ghostscript [22], Planet PDF [18] 341 and PDFzone.com [19]. 343 7. Security considerations 345 An "application/pdf" resource contains information to be parsed and 346 processed by the recipient's PDF system. Because PDF is both a 347 representation of formatted documents and a container system for the 348 resources need to reproduce or view said documents, it is possible 349 that a PDF file has embedded resources not described in the PDF 350 Reference. 352 Although it is not a defined feature of PDF, a PDF processor could 353 extract these resources and store them on the recipients system. 354 Furthermore, PDF processor may accept and execute "plug-in" modules 355 accessible to the recipient. These may also access material in the 356 PDF file or on the recipients system. Therefore, care in establishing 357 the source, security and reliability of such plug-ins is recommended. 358 Message-sending software should not make use of arbitrary plug-ins 359 without prior agreement on their presence at the intended recipients. 360 Message-receiving and -displaying software should make sure that any 361 non-standard plug-ins are secure and do not present a security 362 threat. 364 PDF may contain "scripts" to customize the displaying and processing 365 of PDF files. These scripts are expressed in a version of JavaScript 366 [10] based on JavaScript version 1.5 of ISO-16262 (formerly known as 367 ECMAScript). These scripts have access to an API that is similar to 368 the "plug-in" API. They are intended for execution by the PDF 369 processor. User agents executing such scripts or programs must be 370 extremely careful to insure that untrusted software is executed in a 371 protected environment. 373 In addition, JavaScript code might modify the appearance of a PDF 374 document. For this reason, validation of digital signatures should 375 take this into account. 377 In general, any information stored outside of the direct control of 378 the user -- including referenced application software or plug-ins and 379 embedded files, scripts or other material not covered in the PDF 380 reference -- can be a source of insecurity, by either obvious or 381 subtle means. For example, a script can modify the content of a 382 document prior to its being displayed. Thus, the security of any PDF 383 document may be dependent on the resources referenced by that 384 document. 386 As noted above, PDF provides mechanism for helping insure the 387 integrity of a PDF file, Encryption (Section 4), and to be able to 388 digitally sign (Section 5) a PDF file. The latter capability allows a 389 recipient to decide if he is willing to trust the file. 391 Where there is concern that tampering with the PDF file might be a 392 problem it is recommended that the encryption and digital signature 393 features be used to protect and authoritate the PDF. 395 In addition, PDF processors may have mechanisms that track the source 396 of scripts or plug-ins and will execute only those scripts or 397 plug-ins that meet the processors requirements for trustworthiness of 398 the sources. 400 8. IANA considerations 402 This document updates the registration of 'application/pdf', a media 403 type registration as defined in Multipurpose Internet Mail Extensions 404 (MIME) Part Four: Registration Procedures [23]: 406 MIME media type name: application 407 MIME subtype name: pdf 408 Required parameters: none 409 Optional parameter: none 410 Encoding considerations: 411 PDF files frequently contain binary data, and thus must be 412 encoded in non-binary contexts. 413 Security considerations: 414 See Section 7 of this document. 415 Interoperability considerations: 416 See Section 6 of this document. 417 Published specification: 418 Adobe Systems Incorporated, "PDF Reference, 419 Fourth Edition", Version 1.5, August 2003, , as amended by 421 errata . 423 Applications which use this media type: 424 See Section 6 of this document. 425 Additional information: 426 Magic number(s): All PDF files start with the characters '%PDF-' 427 using the PDF version number, e.g., '%PDF-1.4'. These characters 428 are in US-ASCII encoding. 429 File extension(s): .pdf 430 Macintosh File Type Code(s): "PDF " 431 For further information: 432 Adobe Developer Support 433 Adobe Systems Incorporated 434 345 Park Ave 435 San Jose, CA 95110 436 http://www.adobe.com/support/main.html 437 Intended usage: COMMON 438 Author/Change controller: 439 Adobe Developer Support 440 Adobe Systems Incorporated 441 345 Park Ave 442 San Jose, CA 95110 443 http://www.adobe.com/support/main.html 445 References 447 [1] Adobe Systems Incorporated, "Portable Document Format Reference 448 Manual", Version 1.0, ISBN: 0-201-62628-4, Addison-Wesley, New 449 York NY, 1993. 451 [2] Adobe Systems Incorporated, "PDF Reference, Second Edition", 452 Version 1.3, ISBN: 0-201-61588-6, Addison-Wesley, New York NY, 453 2000. 455 [3] Adobe Systems Incorporated, "PDF Reference, Third Edition", 456 Version 1.4, ISBN: 0-201-75839-3, Addison-Wesley, New York NY, 457 November 2001. 459 [4] Adobe Systems Incorporated, "PDF Reference, Fourth Edition", 460 Version 1.5, August 2003, . 463 [5] Adobe Systems Incorporated, "Errata for PDF Reference, Fourth 464 Edition", December 2003, . 467 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 468 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 469 1998. 471 [7] Adobe Systems Incorporated, "PDF Open Parameters", Technical 472 Note 5428, May 2003, . 475 [8] Rivest, R., "RC4 - an unpublished, trade secret encryption 476 algorithm", November 1993, . 479 [9] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 480 1.5", RFC 2315, March 1998. 482 [10] Adobe Systems Incorporated, "Acrobat JavaScript Scripting 483 Reference", Technical Note 5431, September 2003, . 486 [11] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards 487 (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 488 3447, February 2003. 490 Informative References 492 [12] Adobe Systems, "Adobe Patent Clarification Notice", 2003, 493 . 495 [13] Klyne, G., Iwazaki, R. and D. Crocker, "Content Negotiation for 496 Messaging Services based on Email", RFC 3297, July 2002. 498 [14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 499 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 500 HTTP/1.1", RFC 2616, June 1999. 502 [15] Palme, J., "Making Postscript and PDF International", RFC 2346, 503 May 1998. 505 [16] International Standards Organization, "Graphic technology -- 506 Prepress digital data exchange -- Use of PDF -- Part 1: 508 Complete exchange using CMYK data (PDF/X-1 and PDF/X-1a)", ISO 509 15930-1:2001, November 2002. 511 [17] Association for Information and Image Management, "PDF-Archive 512 Committee home page", December 2003, . 515 [18] Planet PDF, "Planet PDF Tools List", December 2003, . 518 [19] InternetBiz.net, "PDF software from the PDF zone toolbox", 519 December 2003, . 521 [20] Adobe Systems Incorporated, "Adobe products page", December 522 2003, . 524 [21] Apple Computer, Inc., "Apple Mac OS X Features - Preview", 525 December 2003, . 527 [22] Artifex Software, Inc, "Ghostscript", December 2003, . 530 [23] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 531 Mail Extensions (MIME) Part Four: Registration Procedures", RFC 532 2048, November 1996. 534 Authors' Addresses 536 Edward A. Taft 537 Adobe Systems 538 345 Park Ave 539 San Jose, CA 95110 540 US 542 EMail: taft@adobe.com 544 James D. Pravetz 545 Adobe Systems 546 345 Park Ave 547 San Jose, CA 95110 548 US 550 EMail: jpravetz@adobe.com 551 Stephen Zilles 552 Adobe Systems 553 345 Park Ave 554 San Jose, CA 95110 555 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 566 Phone: +1 408 536 3024 567 EMail: LMM@acm.org 568 URI: http://larry.masinter.net 570 Intellectual Property Statement 572 The IETF takes no position regarding the validity or scope of any 573 Intellectual Property Rights or other rights that might be claimed to 574 pertain to the implementation or use of the technology described in 575 this document or the extent to which any license under such rights 576 might or might not be available; nor does it represent that it has 577 made any independent effort to identify any such rights. Information 578 on the IETF's procedures with respect to rights in IETF Documents can 579 be found in BCP 78 and BCP 79. 581 Copies of IPR disclosures made to the IETF Secretariat and any 582 assurances of licenses to be made available, or the result of an 583 attempt made to obtain a general license or permission for the use of 584 such proprietary rights by implementers or users of this 585 specification can be obtained from the IETF on-line IPR repository at 586 http://www.ietf.org/ipr. 588 The IETF invites any interested party to bring to its attention any 589 copyrights, patents or patent applications, or other proprietary 590 rights that may cover technology that may be required to implement 591 this standard. Please address the information to the IETF at 592 ietf-ipr@ietf.org. 594 The IETF has been notified of intellectual property rights claimed in 595 regard to some or all of the specification contained in this 596 document. For more information consult the online list of claimed 597 rights. 599 Disclaimer of Validity 601 This document and the information contained herein are provided on an 602 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 603 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 604 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 605 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 606 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 607 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 609 Copyright Statement 611 Copyright (C) The Internet Society (2004). This document is subject 612 to the rights, licenses and restrictions contained in BCP 78, and 613 except as set forth therein, the authors retain all their rights. 615 Acknowledgment 617 Funding for the RFC Editor function is currently provided by the 618 Internet Society.