RFC 8118

The application/pdf Media Type

📅 published March 2017, from ietf

📄 RFC 8118: The application/pdf Media Type 💖✨

okay bestie, let's get into this one 🎀 it's the application/pdf media type doc, and it's giving "PDF has been the final-form king since forever" energy 👑

Quick title-block tea ☕ This RFC was written by M. Hardy, L. Masinter, D. Markovic, D. Johnson and M. Bailey (with Adobe Systems Incorporated, the PDF Association, and Global Graphics in the mix) 🦋. It's Informational (so not a Standards Track thing, just published for info 🌸), it's dated March 2017, and it's ISSN 2070-1721. It obsoletes RFC 3778 💅 and doesn't update anything else.

Abstract ✨

okay so PDF (Portable Document Format) is an ISO standard, ISO 32000-1:2008, and it's a final-form document representation language 📄 that's been used for document exchange, including on the Internet, since 1993 🧚. This doc gives an overview of the PDF format and updates the media type registration for "application/pdf" 💜. It obsoletes RFC 3778 🫶.

Status of This Memo ✨

ngl this part is kind of the legal-ish bit, but the vibe is: this is not an Internet Standards Track spec 🙈. It's published for informational purposes 🎀.

It IS a product of the IETF 💖, it represents the consensus of the IETF community 👑, it got public review, and the IESG approved it for publication 🔥. Not every IESG-approved doc is a candidate for any level of Internet Standard though, so check Section 2 of RFC 7841 for that 💅.

For the current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc8118 🌈.

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the date of publication 🦋. Please read those carefully, bestie, because they describe your rights and restrictions 🫶. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 🎀.

Table of Contents 🗺️

1. Introduction ....................................................2
2. History .........................................................3
3. Fragment Identifiers ............................................3
4. Subset Standards ................................................5
5. PDF Versions ....................................................6
6. PDF Implementations .............................................7
7. Security Considerations .........................................7
8. IANA Considerations .............................................8
9. References ......................................................9
   9.1. Normative References .......................................9
   9.2. Informative References .....................................9
Appendix A. Changes since RFC 3778 ................................11
Authors' Addresses ................................................12

1. Introduction 🧚

okay so this doc is here to give updated info on registering the MIME media type "application/pdf" for documents in the PDF (Portable Document Format) syntax 💖. It obsoletes [RFC3778] 💅.

PDF was originally meant to reliably communicate and view printed info electronically, no matter what machine, OS, or network you were on 🌈. Main character energy from day one ✨.

PDF is used to represent "final form" formatted documents 📄. PDF pages can hold text, images, graphics, and multimedia like video and audio 🎀. It can also hold auxiliary stuff like annotations, bookmarks, file attachments, hyperlinks, logical structures, and metadata 🦋. These are super useful for navigating, building collections of related docs, and reviewing and commenting 🫶. There's also a rich JavaScript model for interacting with PDF documents 💻✨.

The imaging model for PDF was originally based on the PostScript [PS] page description language 🍓. That's what renders complex text, images, and graphics in a device-independent and resolution-independent way 💜.

PDF supports encryption and digital signatures 🔐. The encryption works together with access control info to help manage what the recipient can do 👑. PDF also supports document and object-level metadata through the eXtensible Metadata Platform [XMP] 🌸.

2. History 📜

PDF is used widely in the Internet community 🌐. The first version, PDF 1.0, was published in 1993 by Adobe Systems Incorporated 🧚. Since then it's become the go-to format for capturing and exchanging formatted docs electronically across the Web, over email, and basically every other document-exchange mechanism 💅.

In 2008, PDF 1.7 was adopted as an ISO standard (ISO 32000-1:2008 [ISOPDF]) using the ISO "Fast-Track" process 🔥. That spec is technically identical to Adobe Portable Document Format version 1.7 [AdobePDF] 💖.

The ISO TC-171 committee developed a "refresh" of PDF called ISO 32000-2, which is PDF 2.0 [ISOPDF2] ✨.

Besides ISO 32000-1:2008 and ISO 32000-2, ISO has standardized several subset standards for specific use cases 🎀. These include PDF for Archival (PDF/A) [ISOPDFA] 📚, PDF for Engineering (PDF/E) [ISOPDFE] 🛠️, PDF for Universal Accessibility (PDF/UA) [ISOPDFUA] ♿, PDF for Variable Data and Transactional Printing (PDF/VT) [ISOPDFVT] 🖨️, and PDF for Prepress Digital Data Exchange (PDF/X) [ISOPDFX] 🦋. The subset standards are fully compliant PDF files that any general PDF viewer can display 🫶.

3. Fragment Identifiers 🔖

okay fragment identifiers are the bits at the end of a URI 🦋. They give you a way to point at an anchor for subordinate content inside the URI's target, or pass extra parameters to the process of opening the content 💅. The syntax and semantics are referenced in the media type definition 💖.

The fragment identifier spec for PDF first showed up in [RFC3778] and is now included in ISO 32000-2 [ISOPDF2] 🌸. This section is just a summary of that material 📝. If [ISOPDF2] and this document ever disagree, the ISO 32000-2 definition wins 👑.

A PDF fragment identifier has one or more parameters, separated by the ampersand (&) or pound (#) character 🎀. Each parameter is the parameter name, "=" (equal), and the parameter value 💜. Lists of values are comma-separated, and parameter value strings may be URI-encoded [RFC3986] 🌈. Parameters are processed left to right ➡️.

Coordinate values (like <left>, <right>, and <width>) are expressed in the document's default user space coordinate system 📐: 1/72 of an inch, measured down and to the right from the upper left corner of the (current) page ([ISOPDF2] 8.3.2.3 "User Space") 🧚.

These parameters identify subordinate content in a PDF file, but they can also set the document view so the (start of the) identified content is visible 👀:

page=<pageNum>

Identifies a specified (physical) page 📄. The first page in the document has a pageNum value of 1 🌸.

nameddest=<name>

Identifies a named destination ([ISOPDF2] 12.3.2.4 "Named destinations") 🦋.

structelem=<structID>

A byte string with URI encoding 💜. Identifies the structure element with the ID key within a StructElem dictionary of the document 🫶.

comment=<commentID>

The value of an annotation name 💅. That name is defined by the NM key in the corresponding annotation dictionary of the selected page ([ISOPDF2] 12.5.2 "Annotation dictionaries") 🎀.

ef=<name>

Identifies the embedded file where the parameter string <name> matches a file specification dictionary in the EmbeddedFiles name tree 📎. If the "ef" parameter isn't at the end of the fragment identifier, then the rest of the fragment identifier (after the ampersand or hash delimiter) gets applied to the embedded file according to its own media type 🌈. This lets you point at content inside the embedded file, which might itself be a PDF file 🪆.

NOTE: When attempting to open a PDF file that is not from a trusted source, the processor may choose to prompt the user or even prevent the file from being opened 🚨💀. Be careful out there, bestie 🙈.

These parameters work on the view of the PDF document when it's opened 👀:

zoom=<scale>,<left>,<top>

<scale> is the percentage to which the document should be zoomed, where a value of 100 corresponds to a zoom of 100% 🔍. <left> and <top> are optional, but both must be specified if either is included 💖.

view=<keyword>,<position>

The arguments correspond to those found in [ISOPDF2] 12.3.2.2 "Explicit destinations" 🧚. <keyword> is one of the keywords defined in [ISOPDF2] "Table 149: Destination syntax" with appropriate position values 📋.

viewrect=<left>,<top>,<width>,<height>

Sets the view rectangle 🪟.

highlight=<left>,<right>,<top>,<bottom>

Highlights the specified rectangle ✨.

search=<wordList>

Opens the document and searches for one or more words, selecting the first matching word in the document 🔎. <wordList> is a string enclosed in quotation marks, where individual words are separated by the space character (or %20) 💅.

fdf=<URI>

This parameter imports data into PDF form fields 📝. The URI is either a relative or absolute URI to a Forms Data Format (FDF) or XML FDF (XFDF) file 🌸. The fdf parameter should be specified as the last parameter to a given URI 🏁.

okay that's part 1 of 3 bestie 🫶 it covers the title block, Abstract, Status, Copyright, TOC, Sections 1 to 3 💖. Part 2 is coming with Subset Standards and PDF Versions next 🦋✨

4. Subset Standards ✨

okay so PDF has a bunch of spin-off subsets that got turned into their own ISO standards, and each one is basically PDF with a specific job 💅

  • PDF/X [ISOPDFX] 🖨️ came out in 2001 as PDF/X-1a. It shows you how to use PDF for graphics exchange so print service providers can print stuff correctly and predictably. It's been revised a bunch over the years and has several published parts, with part 8 being the newest. Its conformance levels are PDF/X-1a:2001, PDF/X-3:2002, PDF/X-1a:2003, PDF/X-3:2003, PDF/X-4, PDF/X-4p, PDF/X-5g, PDF/X-5pg, and PDF/X-5n. That's a lot of levels, bestie 😭
  • PDF/A [ISOPDFA] 🗄️ came out in 2005 and is all about long-term preservation (archiving) of electronic documents. It bans PDF features that aren't great for long-term archiving, like JavaScript or executable file launches. Its requirements for PDF/A viewers include color management guidelines and support for embedded fonts. There are three parts and eight conformance levels: PDF/A-1a, PDF/A-1b, PDF/A-2a, PDF/A-2b, PDF/A-2u, PDF/A-3a, PDF/A-3b, and PDF/A-3u. Archival icon behavior 📚✨
  • PDF/E [ISOPDFE] 🏗️ came out in 2008 as PDF/E-1. It's for engineering workflows like manufacturing, construction, and geospatial analysis. Future revisions are supposed to add support for 3D PDF workflows, so keep an eye out 👀
  • PDF/VT 🧾 came out in 2010 and covers variable and transactional printing. It's built on PDF/X and adds extra restrictions on PDF content elements and supporting metadata. It has three conformance levels: PDF/VT-1, PDF/VT-2, and PDF/VT-2s [ISOPDFVT].
  • PDF/UA [ISOPDFUA] ♿ came out in 2012 as PDF/UA-1 and specifies how to create accessible electronic documents. It requires ISO 32000's Tagged PDF feature and adds lots of requirements for semantic correctness when you apply logical structures to content in PDF documents. Accessibility is not optional, periodt 🫶

All of these subset standards use the "application/pdf" media type 🎀. They're generally not exclusive, so you can make a PDF that conforms to more than one at the same time. For example, it's totally possible to build a file that conforms to both PDF/A-2b and PDF/X-4. Iconic overlap energy 🌈

PDF documents that claim conformance to one or more of the subset standards use XMP metadata to show their conformance levels. PDF processors should check the document's metadata streams for these subset standards identifiers and, where it makes sense, label the documents that way when they show them to the user. Little label, big payoff 💜

5. PDF Versions

The PDF format has gone through several revisions, mostly to add features 🌸. New features have usually been added in a way that older viewers "fail gracefully", because they can just ignore features they don't recognize. That's so iconic of them 🥹 Even so, the older the PDF version you produce, the more legacy viewers will support it, but the fewer features will work. The "application/pdf" media type is used for all versions. For more on this, check [ISOPDF2] Annex I, "PDF Versions and Compatibility" 📖

6. PDF Implementations

PDF files get experienced through a reader or viewer of PDF files 👀. For most of the common platforms (iOS, OS X, Windows, Android, ChromeOS, Kindle) and most browsers (Edge, Safari, Chrome, Firefox), PDF viewing is built right in 🦋. There are also tons of PDF viewers you can download and install. The PDF specification has been published and freely available since the format was introduced in 1993, so hundreds of companies and organizations make tools for PDF creation, viewing, and manipulation. The whole ecosystem is giving main character energy 👑

7. Security Considerations

Okay, this is the serious part 🙈 PDF is certainly a complex media type, as per Section 4.6 of [RFC6838], which sets requirements for security analysis of media type registrations. [RFC3778] (which this document obsoletes) had a detailed analysis of some of the security issues for PDF implementations known at the time. The analysis isn't necessarily wrong, but the threat analysis is much too limited, and the mitigations are kinda out of date 💀 There's now extensive literature on security threats involving PDF implementations and how to avoid them, which fits with broad implementation over decades. We aren't registering a new media type here. We're doing a mostly administrative update. With those caveats in mind 🫠

The PDF file format allows several constructs that may compromise security if processors don't handle them carefully. For example:

  • PDF may contain scripts to customize the displaying and processing of PDF files 🚨. These scripts are written in a version of JavaScript and are meant to be run by the PDF processor.
  • A PDF file may refer to other PDF files for portions of its content. PDF processors may be expected to find and use these external files when processing the document.
  • PDF may act as a container for various files embedded in it (for example, as attached files) 📎. PDF processors may offer features to open and display those files or store them on the system, such as with the "ef" open action. The PDF specification places no restrictions on the types of files that may be embedded, so PDF processors should be extremely careful to prevent unwanted execution of attached executables, or unwanted decompression of attached archives that may store dangerous files in the host file system. Please be careful, I'm begging you 😭
  • PDF files may contain links to content on the Internet 🌐. PDF processors may offer features to show that content when someone follows the link.
  • The fragment identifier syntax (Section 3) contains directives for opening ("ef") or including ("fdf") additional material.

PDF interpreters executing any scripts or programs related to these constructs must be extremely careful to ensure that untrusted software is executed in a protected environment 🛡️ In addition, the PDF processor itself, as well as its plugins, scripts, and so on, may be a source of insecurity, through either obvious or subtle means. Stay paranoid, bestie 🫶

8. IANA Considerations

This document updates the registration of "application/pdf", a media type registration previously defined in [RFC3778], using the registration template defined in [RFC6838]. Here's the full template, no cap 💅

Type name: application

Subtype name: pdf

Required parameters: none

Optional parameter: none

Encoding considerations: binary

Security considerations: See Section 7 of this document.

Interoperability considerations: See Section 5 of this document.

Published specification: ISO 32000-2 (PDF 2.0) [ISOPDF2] is the
   most recent.

Applications that use this media type: See Section 6 of this
   document.

Fragment identifier considerations: See Section 3 of this document.

Additional information:

   Deprecated alias names for this type: none

   Magic number(s): All PDF files start with the characters "%PDF-"
      followed by the PDF version number, e.g., "%PDF-1.7" or
      "%PDF-2.0".  These characters are in US-ASCII encoding.

   File extension(s): .pdf

   Macintosh file type code(s): "PDF "

Person & email address to contact for further information:
   Duff Johnson <duff@duff-johnson.com>, Peter Wyatt
   <Peter.wyatt@cisra.canon.com.au>, ISO 32000 Project Leaders.

Intended usage: COMMON

Restrictions on usage: none

Author: Authors of this document

Change controller: ISO; in particular, ISO 32000 is by
   ISO TC 171/SC 02/WG 08, "PDF specification".  Duff Johnson
   <duff@duff-johnson.com> and Peter Wyatt
   <Peter.wyatt@cisra.canon.com.au> are current ISO 32000 Project
   Leaders.

9. References

9.1. Normative References

[ISOPDF]   ISO, "Document management -- Portable document format --
           Part 1: PDF 1.7", ISO 32000-1:2008, 2008.

[ISOPDF2]  ISO, "Document management -- Portable document format --
           Part 2: PDF 2.0", ISO 32000-2:2017, 2017.

9.2. Informative References

[ISOPDFX]  ISO, "Graphic technology -- Prepress digital data exchange
           using PDF -- Part 8: Partial exchange of printing data
           using PDF 1.6 (PDF/X-5)", ISO 15930-8:2008, 2008.

[ISOPDFA]  ISO, "Document management -- Electronic document file
           format for long-term preservation -- Part 3: Use of
           ISO 32000-1 with support for embedded files (PDF/A-3)",
           ISO 19005-3:2012, 2012.

[ISOPDFE]  ISO, "Document management -- Engineering document format
           using PDF -- Part 1: Use of PDF 1.6 (PDF/E-1)",
           ISO 24517-1:2008, 2008.

[ISOPDFVT] ISO, "Graphic technology -- Variable data exchange --
           Part 2: Using PDF/X-4 and PDF/X-5 (PDF/VT-1 and
           PDF/VT-2)", ISO 16612-2:2010, 2010.

[ISOPDFUA] ISO, "Document management applications -- Electronic
           document file format enhancement for accessibility --
           Part 1: Use of ISO 32000-1 (PDF/UA-1)", ISO 14289-1:2014,
           2014.

[XMP]      ISO, "Graphic technology -- Extensible metadata platform
           (XMP) specification -- Part 1: Data model, serialization
           and core properties", ISO 16684-1, 2012.

[PS]       Adobe Systems Incorporated, "PostScript Language
           Reference, third edition", 1999,
           <https://www.adobe.com/products/postscript/pdfs/PLRM.pdf>.

[AdobePDF] Adobe Systems Incorporated, "PDF Reference,
           sixth edition", 2006,
           <http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/
           pdfs/pdf_reference_1-7.pdf>.

[RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
           Specifications and Registration Procedures", BCP 13,
           RFC 6838, DOI 10.17487/RFC6838, January 2013,
           <http://www.rfc-editor.org/info/rfc6838>.

[RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
           Resource Identifier (URI): Generic Syntax", STD 66,
           RFC 3986, DOI 10.17487/RFC3986, January 2005,
           <http://www.rfc-editor.org/info/rfc3986>.

[RFC3778]  Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
           application/pdf Media Type", RFC 3778,
           DOI 10.17487/RFC3778, May 2004,
           <http://www.rfc-editor.org/info/rfc3778>.

Appendix A. Changes since RFC 3778

This specification replaces RFC 3778, which previously defined the "application/pdf" Media Type 🦋 Here's what's different:

  • To reflect the move from a proprietary specification by Adobe to an open ISO standard, the Change Controller has changed from Adobe to ISO, and references have been updated 🔄
  • The overview of PDF capabilities, the history of PDF, and the descriptions of PDF subsets were updated to reflect more recent relevant history 🕰️
  • The section on fragment identifiers was updated to closely reflect the material that has been added to ISO-32000-2 ✨
  • The status of popular PDF implementations was updated 📱
  • The Security Considerations section was updated to match the current understanding of PDF vulnerabilities 🔐
  • The registration template was updated to match RFC 6838 💖

Authors' Addresses 💌

okay bestie, here are the lovely people who wrote this doc and how to reach them 🫶 the Adobe crew sits at the same Park Ave address, and our friends at PDF Association and Global Graphics have their own spots too 🌸

Matthew Hardy
Adobe Systems Incorporated
345 Park Ave.
San Jose, CA  95110
United States of America

Email: mahardy@adobe.com


Larry Masinter
Adobe Systems Incorporated
345 Park Ave.
San Jose, CA  95110
United States of America

Email: masinter@adobe.com
URI:   http://LarryMasinter.net


Dejan Markovic
Adobe Systems Incorporated
345 Park Ave.
San Jose, CA  95110
United States of America

Email: dmarkovi@adobe.com


Duff Johnson
PDF Association
Neue Kantstrasse 14
Berlin  14057
Germany

Email: duff.johnson@pdfa.org


Martin Bailey
Global Graphics
2030 Cambourne Business Park
Cambridge  CB23 6DW
United Kingdom

Email: martin.bailey@globalgraphics.com
URI:   http://www.globalgraphics.com

that's the whole cast! 💜 if you want to reach out to any of them, the emails and links above are all you need, and you are literally the best for reading all the way to the end 🦋✨

📦 where this page comes from