idnits 2.17.1 draft-hardy-pdf-mime-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document obsoletes RFC3778, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 7, 2016) is 2940 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ISOPDFA' is defined on line 460, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Hardy 3 Internet-Draft L. Masinter 4 Obsoletes: 3778 (if approved) D. Markovic 5 Intended status: Informational Adobe 6 Expires: October 9, 2016 D. Johnson 7 PDF Association 8 M. Bailey 9 Global Graphics 10 April 7, 2016 12 The application/pdf Media Type 13 draft-hardy-pdf-mime-01 15 Abstract 16 <1> 17 The Portable Document Format (PDF) is an ISO standard (ISO 18 32000-1:2008) defining a final-form document representation language 19 in use for document exchange, including on the Internet, since 1993. 20 This document provides an overview of the PDF format and updates the 21 media type registration of "application/pdf". 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 9, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Fragment Identifiers . . . . . . . . . . . . . . . . . . . . 3 60 4. Subset Standards . . . . . . . . . . . . . . . . . . . . . . 7 61 5. PDF Implementations . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Appendix A. Changes since RFC 3778 . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 69 <2> 70 This document is intended to provide updated information on the 71 registration of the MIME Media Type "application/pdf" for documents 72 defined in the PDF [ISOPDF], "Portable Document Format", syntax. 73 <3> 74 PDF was originally envisioned as a way to reliably communicate and 75 view printed information electronically across a wide variety of 76 machine configurations, operating systems, and communication 77 networks. 78 <4> 79 PDF is used to represent "final form" formatted documents. PDF pages 80 may include text, images, graphics and multimedia content such as 81 video and audio. PDF is also capable of containing auxiliary 82 structures including annotations, bookmarks, file attachments, 83 hyperlinks, logical structure and metadata. These features are 84 useful for navigation, building collections of related documents and 85 for reviewing and commenting on documents. A rich JavaScript model 86 has been defined for interacting with PDF documents. 87 <5> 88 PDF used the imaging model of the PostScript [PS] page description 89 language to render complex text, images, and graphics in a device and 90 resolution-independent manner. 91 <6> 92 PDF supports encryption and digital signatures. The encryption 93 capability is combined with access control information to facilitate 94 management of the functionality available to the recipient. PDF 95 supports the inclusion of document and object-level metadata through 96 the eXtensible Metadata Platform[XMP]. 98 2. History 99 <7> 100 PDF is used widely in the Internet community. The first version of 101 PDF, 1.0, was published in 1993 by Adobe Systems. Since then PDF has 102 grown to be a widely-used format for capturing and exchanging 103 formatted documents electronically across the Web, via e-mail and 104 virtually every other document exchange mechanism. In 2008, PDF 1.7 105 was published as an ISO standard [ISOPDF], ISO 32000-1:2008. 106 <8> 107 The ISO TC-171 committee is presently working on a refresh of PDF, 108 known as ISO 32000-2, with a version of PDF 2.0, expected to be 109 published in 2017. 110 <9> 111 In addition to ISO 32000-1:2008 and 32000-2, several subset standards 112 have been defined to address specific use cases and standardized by 113 the ISO. These standards include PDF for Archival (PDF/A), PDF for 114 Engineering (PDF/E), PDF for Universal Accessibility (PDF/UA), PDF 115 for Variable Data and Transactional Printing (PDF/VT) and PDF for 116 Prepress Digital Data Exchange (PDF/X). The subset standards are 117 fully compliant PDF files capable of being displayed in a general PDF 118 viewer. 120 3. Fragment Identifiers 121 <10> 122 A set of fragment identifiers [RFC3986] and their handling are 123 defined in ISO 32000-2 [ISOPDF2]. This section summarizes that 124 material. 125 <11> 126 A fragment identifier is comprised of one or more parameters 127 separated by the AMPERSAND (&) character. Each parameter implies an 128 action to be performed on the document and provides values to be used 129 for that action; the values for a parameter are introduced by an 130 EQUAL SIGN (=) and separated by a COMMA (,); values which are strings 131 appear in the fragment identifier using URI's percent-hex escaping -- 132 spaces, reserved and non-ASCII strings are included by %nn encoding 133 the UTF-8 of each character. Actions shall be processed and executed 134 from left to right as they appear in the character string that makes 135 up the fragment identifier. 136 <12> 137 The parameters listed in this section operate on the document at the 138 point it is opened; for this reason they are sometimes referred to as 139 PDF open parameters. The fragment identifier should be processed 140 immediately after document-specified open parameters have been 141 processed. 142 <13> 143 The table below lists the PDF open parameters relevant to PDF. All 144 coordinate values (left, right, top, and bottom) shall be expressed 145 in the default user space coordinate system. 147 <14> 148 PDF Open Parameters 150 +-------------+-------------------------+---------------------------+ 151 | Parameter | Arguments | Description | 152 | Name | | | 153 +-------------+-------------------------+---------------------------+ 154 | "nameddest" | _name_ | Open the document to the | 155 | | | specified named | 156 | | | destination. The | 157 | | | argument provided is a | 158 | | | string which shall | 159 | | | correspond to the name of | 160 | | | a destination in the | 161 | | | target document. | 162 | "page" | _pageNum_ | Open the document to the | 163 | | | specified page number. | 164 | | | The argument shall be a | 165 | | | positive integer number. | 166 | | | The first page in the | 167 | | | document has a pageNum | 168 | | | value of 1. | 169 | "zoom" | _scale scale,left,top_ | Open the document with | 170 | | | the specified zoom level | 171 | | | and optional offset. The | 172 | | | scale argument shall be | 173 | | | either an integer or | 174 | | | floating point value | 175 | | | representing the | 176 | | | percentage to which the | 177 | | | document should be | 178 | | | zoomed, where a value of | 179 | | | 100 would correspond to a | 180 | | | zoom of 100%. The left | 181 | | | and top arguments are | 182 | | | optional, but shall both | 183 | | | be specified if either is | 184 | | | included. The left and | 185 | | | top arguments shall be | 186 | | | integer or floating point | 187 | | | values representing the | 188 | | | offset from the left and | 189 | | | top of the page in a | 190 | | | coordinate system where | 191 | | | 0,0 represents the top | 192 | | | left corner of the page. | 193 | "view" | _keyword,position_ | Open the document with | 194 | | | the specified destination | 195 | | | set as the view. The | 196 | | | arguments shall | 197 | | | correspond to those found | 198 | | | in [ISOPDF2] 12.3.2.2, | 199 | | | "Explicit destinations". | 200 | | | The keyword shall | 201 | | | correspond to one of the | 202 | | | keywords defined in | 203 | | | [ISOPDF2] Table 149, | 204 | | | "Destination syntax" with | 205 | | | appropriate position | 206 | | | values. | 207 | "viewrect" | _left,top,width,height_ | Open the document with | 208 | | | the specified window view | 209 | | | rectangle. The left and | 210 | | | top arguments shall be | 211 | | | integer or floating point | 212 | | | values representing the | 213 | | | offset from the left and | 214 | | | top of the page in a | 215 | | | coordinate system where | 216 | | | 0,0 represents the top | 217 | | | left corner of the page. | 218 | | | The width and height | 219 | | | arguments shall be | 220 | | | integer or floating point | 221 | | | values representing the | 222 | | | width and height of the | 223 | | | view. | 224 | "highlight" | _left,right,top,bottom_ | Open the document with | 225 | | | the specified rectangle | 226 | | | highlighted. Each | 227 | | | argument shall be an | 228 | | | integer or floating point | 229 | | | value representing the | 230 | | | rectangle measured from | 231 | | | the top left corner of | 232 | | | the page. | 233 | "comment" | _commentID_ | Open the document with | 234 | | | the specified comment | 235 | | | selected. The commentID | 236 | | | shall be the value of an | 237 | | | annotation name, which is | 238 | | | defined by the NM key in | 239 | | | the corresponding | 240 | | | annotation dictionary | 241 | | | (see 12.5.2 "Annotation | 242 | | | dictionaries", Table | 243 | | | 167). If the comment | 244 | | | parameter is combined | 245 | | | with another parameter | 246 | | | that defines a specific | 247 | | | page to be displayed, | 248 | | | then the comment | 249 | | | parameter shall appear | 250 | | | after that in the URI. | 251 | | | Note: The NM key is | 252 | | | unique to a specific | 253 | | | page, but is not | 254 | | | guaranteed to be unique | 255 | | | to a document. Unless | 256 | | | the page on which the | 257 | | | comment resides has been | 258 | | | selected prior to the | 259 | | | comment parameter, the | 260 | | | comment will not be | 261 | | | selected. | 262 | "search" | _wordList_ | Open the document and | 263 | | | search for one or more | 264 | | | words, selecting the | 265 | | | first matching word in | 266 | | | the document. The | 267 | | | wordList argument defines | 268 | | | the search words and | 269 | | | shall be a string | 270 | | | enclosed within quotation | 271 | | | marks comprised of | 272 | | | individual words | 273 | | | separated by space | 274 | | | characters. Note that | 275 | | | the space characters must | 276 | | | be encoded. | 277 | "fdf" | _URI_ | Open the document and | 278 | | | then import the data from | 279 | | | the specified FDF or XFDF | 280 | | | file. The URI shall be | 281 | | | either a relative or | 282 | | | absolute URI to an FDF or | 283 | | | XFDF file. The fdf | 284 | | | parameter should be | 285 | | | specified as the last | 286 | | | parameter to a given URI. | 287 | | | Note: The fdf parameter | 288 | | | is recommended to be the | 289 | | | last parameter so that | 290 | | | the document can open | 291 | | | directly to the | 292 | | | appropriate view. | 293 +-------------+-------------------------+---------------------------+ 295 4. Subset Standards 296 <15> 297 Several subsets of PDF have been published as distinct ISO standards: 298 <16> 299 o PDF/X, initially released in 2001 as PDF/X-1a [ISOPDFX], specifies 300 how to use PDF for graphics exchange, with the aim to fascilitate 301 correct and predictable printing by print service providers. The 302 standard has gone through multiple revisions over the years and 303 has several published parts, the most recently released being part 304 8, specifying different levels of conformance: PDF/X-1a:2001, PDF/ 305 X-3:2002, PDF/X-1a:2003, PDF/X-3:2003, PDF/X-4, PDF/X-4p, PDF/X-5, 306 PDF/X-5g, PDF/X-5pg and PDF/X-5n. 307 <17> 308 o PDF/A, initially released in 2005, specifies how to use PDF for 309 long-term preservation (archiving) of electronic documents. It 310 prohibits PDF features which are not well suited to long term 311 archiving of documents. Its requirements for PDF/A viewers 312 include color management guidelines and support for embedded 313 fonts. There are three parts of this standard and a total of 314 eight conformance levels: PDF/A-1a, PDF/A-1b, PDF/A-2a, PDF/A-2b, 315 PDF/A-2u, PDF/A-3a, PDF/A-3b and PDF/A-3u. 316 <18> 317 o PDF/E, initially released in 2008 as PDF/E-1 [ISOPDFE], specifies 318 how to use PDF in engineering workflows, such as manufacturing, 319 construction and geospatial analysis. Future revisions of PDF/E 320 are supposed to include support for 3D PDF workflows. 321 <19> 322 o PDF/VT, initially released in 2010, specifies how to use PDF in 323 variable and transactional printing. It is based on PDF/X, and 324 adds adidtional restrictions on PDF content elements and 325 supporting metadata. It specifies three conformance levels: PDF/ 326 VT-1, PDF/VT-2 and PDF/VT-2s [ISOPDFVT]. 327 <20> 328 o PDF/UA, initially released in 2012 as PDF/UA-1 [ISOPDFUA], 329 specifies how to create accessible electonic documents. It 330 requires use of ISO 32000's Tagged PDF feature, and adds many 331 requirements regarding semantic correctness in applying logical 332 structures to content in PDF documents. 333 <21> 334 All of these subset standards use "application/pdf" media type. The 335 subset standards are generally not exclusive, so it is possible to 336 construct a PDF file which conforms to, for example, both PDF/A-2b 337 and PDF/X-4 subset standards. 339 <22> 340 PDF documents claiming conformance to one or more of the subset 341 standards use XMP metadata to identify levels of conformance. PDF 342 processors should examine document metadata streams for such subset 343 standards identifiers and, if apropriate, label documents as such 344 when presenting them to the user. 346 5. PDF Implementations 347 <23> 348 PDF format has gone through several revisions, primarily for the 349 addition of features. PDF features have generally been added in a 350 way that older viewers 'fail gracefully' because they can just ignore 351 features they do not recognize, but even so, the older the PDF 352 version produced, the more legacy viewers will support that version, 353 but the fewer features will be enabled. 354 <24> 355 PDF files are experienced through a reader or viewer of PDF files. 356 For most of the common platforms in use (iOS, OS X, Windows, Android, 357 ChromeOS, Kindle) and for most browsers (Edge, Safari, Chrome, 358 Firefox), PDF viewing is built-in. In addition, there are many PDF 359 viewers available for download and install. The PDF specification 360 was published and freely available since the format was introduced in 361 1993, so hundreds of companies and organizations make tools for PDF 362 creation, viewing, and manipulation. 364 6. Security Considerations 365 <25> 366 The PDF file format allows several constructs which may compromise 367 security if handled inadequately by PDF processors. For example: 368 <26> 369 o PDF may contain scripts to customize the displaying and processing 370 of PDF files. These scripts are expressed in a version of 371 JavaScript and are intended for execution by the PDF processor. 372 <27> 373 o PDF file may refer to other PDF files for portions of content 374 using XObjects. PDF processors are expected to find these 375 external files and load them in order to display the document. 376 <28> 377 o PDF may act as a container for various files embedded in it (for 378 example, as attached files). PDF processors may offer 379 functionality to open and display such files or store them on the 380 system. 381 <29> 382 o PDF files may contain links to content on the internet. PDF 383 processors may offer functionality to show such content upon 384 following the link. 385 <30> 386 In addition, the PDF processor itself, as well as its plugins, 387 scripts etc. may be a source of insecurity, by either obvious or 388 subtle means. 390 7. IANA Considerations 391 <31> 392 This document updates the registration of "application/pdf", a media 393 type registration as defined in [RFC6838]: 394 <32> 395 Type name: application 396 <33> 397 Subtype name: pdf 398 <34> 399 Required parameters: none 400 <35> 401 Optional parameter: none 402 <36> 403 Encoding considerations: binary 404 <37> 405 Security considerations: See Section 6 of this document. 406 <38> 407 Interoperability considerations: See Section 5 of this document. 408 <39> 409 Published specification: ISO 32000-1:2008 (PDF 1.7) [ISOPDF]. ISO 410 32000-2 (PDF 2.0) [ISOPDF2] is currently under development. 411 <40> 412 Applications which use this media type: See Section 5 of this 413 document. 414 <41> 415 Fragment identifier considerations: See Section 3 of this document. 416 <42> 417 Additional information: 418 <43> 419 Deprecated alias names for this type: none 420 <44> 421 Magic number(s): All PDF files start with the characters '%PDF-' 422 followed by the PDF version number, e.g., "%PDF-1.7". These 423 characters are in US-ASCII encoding. 424 <45> 425 File extension(s): .pdf 426 <46> 427 Macintosh file type code(s): "PDF " 428 <47> 429 Person & email address to contact for further information: Duff 430 Johnson , Peter Wyatt 431 , ISO 32000 Project Leaders 432 <48> 433 Intended usage: COMMON 435 <49> 436 Restrictions on usage: none 437 <50> 438 Author/Change controller: ISO 32000 is by ISO/TC 171/SC 02/WG 08, 439 "PDF specification". Duff Johnson and Peter 440 Wyatt 488 [PS] Adobe Systems Incorporated, "PostScript Language 489 Reference, third edition", 1999. 491 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 492 Specifications and Registration Procedures", BCP 13, 493 RFC 6838, DOI 10.17487/RFC6838, January 2013, 494 . 496 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 497 Resource Identifier (URI): Generic Syntax", STD 66, 498 RFC 3986, DOI 10.17487/RFC3986, January 2005, 499 . 501 Appendix A. Changes since RFC 3778 502 <51> 503 This specification replaces RFC 3778, which previously defined the 504 "application/pdf" Media Type. Differences include: 505 <52> 506 To reflect the transition from a proprietary specification by Adobe 507 to an open ISO Standard, the Change Controller has changed from Adobe 508 to ISO, and references updated. 509 <53> 510 The overview of PDF capabilitiies, the history of PDF, and the 511 descriptions of PDF subsets were updated to reflect more recent 512 relevant history. 513 <54> 514 The section on Fragment identifiers was updated to closely reflect 515 the material which has been added to ISO-32000-2. 516 <55> 517 The status of popular PDF impelementations was updatd. 518 <56> 519 The Security Considerations were updated to match current status. 520 <57> 521 The registration template was updated to match RFC 6838. 523 Authors' Addresses 524 Matthew Hardy 525 Adobe 526 345 Park Ave 527 San Jose, CA 95110 528 USA 530 Email: mahardy@adobe.com 532 Larry Masinter 533 Adobe 534 345 Park Ave 535 San Jose, CA 95110 536 USA 538 Email: masinter@adobe.com 539 URI: http://larry.masinter.net 541 Dejan Markovic 542 Adobe 543 345 Park Ave 544 San Jose, CA 95110 545 USA 547 Email: dmarkovi@adobe.com 549 Duff Johnson 550 PDF Association 551 Neue Kantstrasse 14 552 Berlin 14057 553 Germany 555 Email: duff.johnson@pdfa.org 557 Martin Bailey 558 Global Graphics 559 2030 Cambourne Business Park 560 Cambridge CB23 6DW 561 UK 563 Email: martin.bailey@globalgraphics.com 564 URI: http://www.globalgraphics.com