RFC 8118 INFORMATIONAL MEDIA TYPE · PDF · DOCUMENTS

The application/pdf Media Type

The registration of application/pdf, the file type used to exchange finished documents on the Internet.

On rfc-editor.org ↗
PUBLISHED
March 2017
AUTHORS
M. Hardy, L. Masinter, D. Markovic, D. Johnson, M. Bailey
STREAM
IETF
BUILDS ON
RFC 3778 — application/pdf
MEDIA TYPE
application/pdf, with no parameters of any kind
MAGIC NUMBER
All PDF files start with %PDF- followed by the version number, such as %PDF-1.7
FILE EXTENSION
.pdf
MACINTOSH FILE TYPE CODE
PDF
INTENDED USAGE
COMMON
FRAGMENT IDENTIFIER COORDINATES
1/72 of an inch, measured down and to the right from the upper left corner of the current page
DOI
10.17487/RFC8118

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Internet Engineering Task Force (IETF)                          M. Hardy
Request for Comments: 8118                                   L. Masinter
Obsoletes: 3778                                              D. Markovic
Category: Informational                       Adobe Systems Incorporated
ISSN: 2070-1721                                               D. Johnson
                                                         PDF Association
                                                               M. Bailey
                                                         Global Graphics
                                                              March 2017


                     The application/pdf Media Type

Abstract

   The Portable Document Format (PDF) is an ISO standard (ISO
   32000-1:2008) defining a final-form document representation language
   in use for document exchange, including on the Internet, since 1993.
   This document provides an overview of the PDF format and updates the
   media type registration of "application/pdf".  It obsoletes RFC 3778.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8118.

Copyright Notice

   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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without 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

   This document is intended to provide updated information on the
   registration of the MIME Media Type "application/pdf" for documents
   in the PDF (Portable Document Format) syntax.  It obsoletes
   [RFC3778].

   PDF was originally envisioned as a way to reliably communicate and
   view printed information electronically across a wide variety of
   machine configurations, operating systems, and communication
   networks.

   PDF is used to represent "final form" formatted documents.  PDF pages
   may include text, images, graphics, and multimedia content such as
   video and audio.  PDF is also capable of containing auxiliary
   structures, including annotations, bookmarks, file attachments,
   hyperlinks, logical structures, and metadata.  These features are
   useful for navigation and building collections of related documents,
   as well as for reviewing and commenting on documents.  A rich
   JavaScript model has been defined for interacting with PDF documents.

   The imaging model for PDF was originally based on the PostScript [PS]
   page description language, used to render complex text, images, and
   graphics in a device-independent and resolution-independent manner.

   PDF supports encryption and digital signatures.  The encryption
   capability is combined with access control information to facilitate
   management of the functionality available to the recipient.  PDF
   supports the inclusion of document and object-level metadata through
   the eXtensible Metadata Platform [XMP].

2.  History

   PDF is used widely in the Internet community.  The first version of
   PDF, 1.0, was published in 1993 by Adobe Systems Incorporated.  Since
   then, PDF has grown to be a widely used format for capturing and
   exchanging formatted documents electronically across the Web, via
   email and virtually 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 specification is
   technically identical to Adobe Portable Document Format version 1.7
   [AdobePDF].

   The ISO TC-171 committee developed a "refresh" of PDF, known as
   ISO 32000-2; the version is PDF 2.0 [ISOPDF2].

   In addition to ISO 32000-1:2008 and ISO 32000-2, several subset
   standards have been defined to address specific use cases and
   standardized by the ISO.  These standards 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 capable of being displayed in a general PDF
   viewer.

3.  Fragment Identifiers

   Fragment identifiers appear at the end of a URI and provide a way to
   reference an anchor to subordinate content within the target of the
   URI, or additional parameters to the process of opening the
   identified content.  The syntax and semantics of fragment identifiers
   are referenced in the media type definition.

   The specification of fragment identifiers for PDF appeared originally
   in [RFC3778] and is now included in ISO 32000-2 [ISOPDF2].  This
   section is a summary of that material.  Any disagreements between
   [ISOPDF2] and this document should be resolved in favor of the
   ISO 32000-2 definition.

   A fragment identifier for PDF has one or more parameters, separated
   by the ampersand (&) or pound (#) character.  Each parameter consists
   of 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 (such as <left>, <right>, and <width>) are
   expressed in the default user space coordinate system of the
   document: 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").

   The following parameters identify subordinate content of a PDF file
   but also may be used to set the document view to make the (start of)
   the identified content 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, which 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 is not at the end of the fragment
      identifier, then the rest of the fragment identifier (after the
      ampersand or hash delimiter) is applied to the embedded file
      according to its own media type.  This allows identification of
      content within the embedded file (which itself might 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.

   These parameters operate on the view of the PDF document when it is
   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>
      Set the view rectangle.

   highlight=<left>,<right>,<top>,<bottom>
      Highlight the specified rectangle.

   search=<wordList>
      Open the document and search 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.

4.  Subset Standards

   Several subsets of PDF have been published as distinct ISO standards:

   o  PDF/X [ISOPDFX], initially released in 2001 as PDF/X-1a, specifies
      how to use PDF for graphics exchange, with the aim to facilitate
      correct and predictable printing by print service providers.  The
      standard has gone through multiple revisions over the years and
      has several published parts, the most recently released being
      part 8, specifying different levels of conformance: 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.

   o  PDF/A [ISOPDFA], initially released in 2005, specifies how to use
      PDF for long-term preservation (archiving) of electronic
      documents.  It prohibits PDF features that are not well suited to
      long-term archiving of documents, including JavaScript or
      executable file launches.  Its requirements for PDF/A viewers
      include color management guidelines and support for embedded
      fonts.  There are three parts of this standard and a total of
      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.

   o  PDF/E, initially released in 2008 as PDF/E-1 [ISOPDFE], specifies
      how to use PDF in engineering workflows, such as manufacturing,
      construction, and geospatial analysis.  Future revisions of PDF/E
      are supposed to include support for 3D PDF workflows.

   o  PDF/VT, initially released in 2010, specifies how to use PDF in
      variable and transactional printing.  It is based on PDF/X and
      places additional restrictions on PDF content elements and
      supporting metadata.  It specifies three conformance levels:
      PDF/VT-1, PDF/VT-2, and PDF/VT-2s [ISOPDFVT].

   o  PDF/UA [ISOPDFUA], initially released in 2012 as PDF/UA-1,
      specifies how to create accessible electronic documents.  It
      requires the use of ISO 32000's Tagged PDF feature and adds many
      requirements regarding semantic correctness in applying logical
      structures to content in PDF documents.

   All of these subset standards use the "application/pdf" media type.
   The subset standards are generally not exclusive, so it is possible
   to construct a PDF file that conforms to, for example, both PDF/A-2b
   and PDF/X-4 subset standards.

   PDF documents claiming conformance to one or more of the subset
   standards use XMP metadata to identify levels of conformance.  PDF
   processors should examine document metadata streams for such subset
   standards identifiers and, if appropriate, label documents as such
   when presenting them to the user.

5.  PDF Versions

   The PDF format has gone through several revisions, primarily for the
   addition of features.  PDF features have generally been added in a
   way that older viewers "fail gracefully", because they can just
   ignore features they do not recognize.  Even so, the older the PDF
   version produced, the more legacy viewers will support that version,
   but the fewer features will be enabled.  The "application/pdf" media
   type is used for all versions.  See [ISOPDF2] Annex I, "PDF Versions
   and Compatibility".

6.  PDF Implementations

   PDF files are experienced through a reader or viewer of PDF files.
   For most of the common platforms in use (iOS, OS X, Windows, Android,
   ChromeOS, Kindle) and for most browsers (Edge, Safari, Chrome,
   Firefox), PDF viewing is built in.  In addition, there are many PDF
   viewers available for download and installation.  The PDF
   specification was 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.

7.  Security Considerations

   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)
   contained a detailed analysis of some of the security issues for PDF
   implementations known at the time.  While the analysis isn't
   necessarily wrong, the threat analysis is much too limited, and the
   mitigations are somewhat out of date.  There is now extensive
   literature on security threats involving PDF implementations and how
   to avoid them, consistent with broad implementation over decades.  We
   are not registering a new media type but rather are making a
   primarily administrative update.  With those caveats:

   The PDF file format allows several constructs that may compromise
   security if handled inadequately by PDF processors.  For example:

   o  PDF may contain scripts to customize the displaying and processing
      of PDF files.  These scripts are expressed in a version of
      JavaScript and are intended for execution by the PDF processor.

   o  A PDF file may refer to other PDF files for portions of content.
      PDF processors may be expected to find and use these external
      files when processing the document.

   o  PDF may act as a container for various files embedded in it (for
      example, as attached files).  PDF processors may offer
      functionality to open and display such files or store them on the
      system, such as with the "ef" open action.  The PDF specification
      places no restrictions on types of files that may be embedded, so
      PDF processors should be extremely careful to prevent unwanted
      execution of attached executables or decompression of attached
      archives that may store dangerous files in the host file system.

   o  PDF files may contain links to content on the Internet.  PDF
      processors may offer functionality to show such content upon
      following the link.

   o  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, etc., may be a source of insecurity, by either obvious or
   subtle means.

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]:

   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.  Differences include the following:

   o  To reflect the transition 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.

   o  The overview of PDF capabilities, the history of PDF, and the
      descriptions of PDF subsets were updated to reflect more recent
      relevant history.

   o  The section on fragment identifiers was updated to closely reflect
      the material that has been added to ISO-32000-2.

   o  The status of popular PDF implementations was updated.

   o  The Security Considerations section was updated to match the
      current understanding of PDF vulnerabilities.

   o  The registration template was updated to match RFC 6838.

Authors' Addresses

   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

ISO Plain Language

On this page
PROBLEMThe registration of the application/pdf media type dates from 2004 and described a format then owned by one company. It needed to be brought up to date with the ISO standard, the newer PDF versions and what is now known about the security of PDF readers.
MECHANISMThe RFC updates the registration itself and records the facts a receiving program needs: the file name extension, the magic number at the start of a PDF, the fragment identifiers a link may carry and the subset standards a PDF may claim to follow.
WHAT CHANGEDIt is an Informational document that obsoletes RFC 3778. The change controller moved from Adobe to ISO, and the security section was rewritten to match the current understanding of PDF vulnerabilities.

§1What application/pdf Is

The document provides updated information on the registration of the media type application/pdf for documents in the PDF syntax, and it obsoletes RFC 3778.

PDF was originally envisioned as a way to reliably communicate and view printed information electronically across a wide variety of machine configurations, operating systems and communication networks. It is used to represent final form formatted documents. PDF pages may include text, images, graphics and multimedia content such as video and audio. PDF is also capable of containing auxiliary structures, including annotations, bookmarks, file attachments, hyperlinks, logical structures and metadata, which are useful for navigation and for building collections of related documents, as well as for reviewing and commenting on documents. A rich JavaScript model has been defined for interacting with PDF documents.

The imaging model for PDF was originally based on the PostScript page description language, used to render complex text, images and graphics in a device-independent and resolution-independent manner. PDF supports encryption and digital signatures, and the encryption capability is combined with access control information to facilitate management of the functionality available to the recipient. It supports the inclusion of document and object-level metadata through the Extensible Metadata Platform.

The registration itself lists the type name as application and the subtype name as pdf, with no required parameters and no optional parameters, binary encoding, intended usage COMMON and no restrictions on usage. The file extension is .pdf, the Macintosh file type code is PDF, and all PDF files start with the characters %PDF- followed by the PDF version number, such as %PDF-1.7 or %PDF-2.0, in US-ASCII encoding.

PDF is meant for a document that is finished: it holds the text, images and layout exactly as they should appear when printed or shown. It can also carry annotations, bookmarks, attachments and links, and it can be encrypted or signed. The registration tells programs what to call the file type and what to look for at the start of the file to recognise it.

§2How PDF Became an ISO Standard

PDF is used widely in the Internet community. The first version, PDF 1.0, was published in 1993 by Adobe Systems Incorporated. Since then PDF has grown to be a widely used format for capturing and exchanging formatted documents electronically across the Web, by email and virtually every other document-exchange mechanism.

In 2008, PDF 1.7 was adopted as an ISO standard, ISO 32000-1:2008, using the ISO Fast-Track process. That specification is technically identical to Adobe Portable Document Format version 1.7. The ISO TC-171 committee later developed a refresh of PDF known as ISO 32000-2, which is the version PDF 2.0.

PDF started as one company's format. In 2008 the same specification was adopted as an ISO standard, and the maintainer of the registration changed with it, so the record of the format now belongs to ISO rather than to Adobe.

THE ROAD FROM A COMPANY FORMAT TO AN ISO STANDARD
  1. 1993PDF 1.0 published by Adobe Systems Incorporated
  2. 2001PDF/X-1a, the first subset standard
  3. 2005PDF/A, the archival subset standard
  4. 2008PDF 1.7 adopted as ISO 32000-1:2008
  5. 2010PDF/VT, the variable and transactional printing subset
  6. 2012PDF/UA-1, the accessibility subset standard
  7. 2017ISO 32000-2, known as PDF 2.0

§3Fragment Identifiers in a PDF Link

Fragment identifiers appear at the end of a URI and provide a way to reference an anchor to subordinate content within the target of the URI, or additional parameters to the process of opening the identified content. A PDF fragment identifier has one or more parameters, separated by the ampersand or pound character. Each parameter consists of the parameter name, an equal sign, and the parameter value; lists of values are comma-separated, and parameter value strings may be URI-encoded. Parameters are processed left to right. The specification of fragment identifiers for PDF appeared originally in RFC 3778 and is now included in ISO 32000-2, and the RFC's section is a summary of that material, with any disagreement resolved in favour of the ISO definition.

Coordinate values are expressed in the default user space coordinate system of the document: 1/72 of an inch measured down and to the right from the upper left corner of the current page.

Several parameters identify subordinate content of a PDF file and may also set the document view to make the identified content visible. The page parameter identifies a physical page, where the first page has a value of 1. The nameddest parameter identifies a named destination. The structelem parameter identifies the structure element with the given ID key within a StructElem dictionary. The comment parameter carries the value of an annotation name, defined by the NM key in the corresponding annotation dictionary of the selected page. The ef parameter identifies the embedded file whose parameter string matches a file specification dictionary in the EmbeddedFiles name tree; if the ef parameter is not at the end of the fragment identifier, the rest of the identifier is applied to the embedded file according to its own media type, which allows identification of content within the embedded file, which itself might be a PDF file. The RFC notes that 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.

Other parameters operate on the view of the document when it is opened. The zoom parameter takes a scale percentage, where 100 corresponds to a zoom of 100 percent, plus optional left and top values, which must both be given if either is. The view parameter takes a keyword and position matching the PDF destination syntax. The viewrect parameter sets the view rectangle, and the highlight parameter highlights a rectangle. The search parameter opens the document and searches for one or more words, selecting the first match, with the word list quoted and individual words separated by a space or %20. The fdf parameter imports data into PDF form fields from a Forms Data Format or XML FDF file, and should be specified as the last parameter of a URI.

A link to a PDF can carry instructions after the pound sign: open at page four, zoom to 150 percent, highlight this rectangle, or search for a word. The instructions are read from left to right, and distances are measured in points, which are seventy-two to the inch.

THE PDF FRAGMENT IDENTIFIER PARAMETERS
  • pagepage=pageNum — Identifies a physical page. The first page in the document has a pageNum value of 1.
  • nameddestnameddest=name — Identifies a named destination in the document.
  • structelemstructelem=structID — Identifies the structure element with that ID key within a StructElem dictionary.
  • commentcomment=commentID — The value of an annotation name, defined by the NM key in the annotation dictionary of the selected page.
  • efef=name — Identifies the embedded file whose name matches a file specification in the EmbeddedFiles name tree.
  • zoomzoom=scale,left,top — The percentage to zoom to, where 100 is a zoom of 100 percent, with optional left and top values.
  • viewview=keyword,position — Arguments taken from the PDF destination syntax.
  • viewrectviewrect=left,top,width,height — Sets the view rectangle.
  • highlighthighlight=left,right,top,bottom — Highlights the specified rectangle.
  • searchsearch=wordList — Opens the document and searches for one or more words, selecting the first match.
  • fdffdf=URI — Imports data into PDF form fields from a Forms Data Format or XML FDF file.

§5Versions and How People Meet PDFs

The PDF format has gone through several revisions, primarily for the addition of features. PDF features have generally been added in a way that older viewers fail gracefully, because they can just ignore features they do not recognise. Even so, the older the PDF version produced, the more legacy viewers will support that version, but the fewer features will be enabled. The application/pdf media type is used for all versions.

PDF files are experienced through a reader or viewer of PDF files. For most of the common platforms in use, iOS, OS X, Windows, Android, ChromeOS and Kindle, and for most browsers, including Edge, Safari, Chrome and Firefox, PDF viewing is built in. In addition, there are many PDF viewers available for download and installation. The PDF specification was 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.

Each new PDF version adds features but leaves the old ones working, so an older viewer simply ignores what it does not recognise. The media type name never changes, whatever the version inside the file. Today the ability to view a PDF is built into most operating systems and web browsers, and the format has been open and freely available since 1993.

§7Security Considerations

PDF is certainly a complex media type, which sets requirements for security analysis of media type registrations. RFC 3778, which this document obsoletes, contained a detailed analysis of some of the security issues for PDF implementations known at the time. The RFC says that while that analysis is not necessarily wrong, the threat analysis is much too limited and the mitigations are somewhat out of date, and that there is now extensive literature on security threats involving PDF implementations and how to avoid them.

The file format allows several constructs that may compromise security if handled inadequately by PDF processors. PDF may contain scripts to customise the displaying and processing of PDF files; these scripts are expressed in a version of JavaScript and are intended for execution by the PDF processor. A PDF file may refer to other PDF files for portions of content, and processors may be expected to find and use those external files. PDF may act as a container for various files embedded in it, for example as attached files, and processors may offer functionality to open and display such files or store them on the system, as with the ef open action; the PDF specification places no restrictions on the types of files that may be embedded, so processors should be extremely careful to prevent unwanted execution of attached executables or decompression of attached archives that may store dangerous files in the host file system. PDF files may contain links to content on the Internet. And the fragment identifier syntax contains directives for opening, with ef, or including, with 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. The PDF processor itself, as well as its plugins and scripts, may be a source of insecurity, by either obvious or subtle means.

A PDF file can carry a program that runs when it is opened, it can pull in other files, and it can carry attachments of any kind at all. So the reader has to run any script it finds in a sandbox, and it has to be careful about opening what is attached. The RFC replaces an older, thinner threat analysis with a list of the constructs that have actually caused trouble.

§7References

[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.
[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.
[AdobePDF]Adobe Systems Incorporated, "PDF Reference, sixth edition", 2006.
[RFC6838]RFC 6838Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.January 2013[RFC3986]RFC 3986Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.January 2005[RFC3778]RFC 3778Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The application/pdf Media Type", RFC 3778, May 2004.May 2004