summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7995.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7995.txt')
-rw-r--r--doc/rfc/rfc7995.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7995.txt b/doc/rfc/rfc7995.txt
new file mode 100644
index 0000000..0463aa0
--- /dev/null
+++ b/doc/rfc/rfc7995.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB) T. Hansen, Ed.
+Request for Comments: 7995 AT&T Laboratories
+Category: Informational L. Masinter
+ISSN: 2070-1721 M. Hardy
+ Adobe
+ December 2016
+
+
+ PDF Format for RFCs
+
+Abstract
+
+ This document discusses options and requirements for the PDF
+ rendering of RFCs in the RFC Series, as outlined in RFC 6949. It
+ also discusses the use of PDF for Internet-Drafts, and available or
+ needed software tools for producing and working with PDF.
+
+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 Architecture Board (IAB)
+ and represents information that the IAB has deemed valuable to
+ provide for permanent record. It represents the consensus of the
+ Internet Architecture Board (IAB). Documents approved for
+ publication by the IAB are not 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/rfc7995.
+
+Copyright Notice
+
+ Copyright (c) 2016 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.
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 1]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Choosing PDF Versions and Standards .............................3
+ 3. Options and Requirements for PDF RFCs ...........................4
+ 3.1. "Visible" Requirements .....................................5
+ 3.1.1. General Visible Requirements ........................5
+ 3.1.2. Page Size and Margins ...............................5
+ 3.1.3. Headers and Footers .................................5
+ 3.1.4. Paragraph Numbering .................................6
+ 3.1.5. Paged Content Layout ................................6
+ 3.1.6. Typeface Choices ....................................7
+ 3.1.7. Hyphenation and Line Breaks .........................8
+ 3.1.8. Hyperlinks ..........................................8
+ 3.1.9. Similarity to Other Outputs .........................9
+ 3.2. "Invisible" Options and Requirements ......................10
+ 3.2.1. Internal Text Representation .......................10
+ 3.2.2. Unicode Support ....................................11
+ 3.2.3. Image Processing (Artwork) .........................12
+ 3.2.4. Text Description of Images (Alt-Text) ..............12
+ 3.2.5. Metadata Support ...................................12
+ 3.2.6. Document Structure Support .........................13
+ 3.2.7. Embedded Files .....................................13
+ 3.3. Digital Signatures ........................................14
+ 4. Security Considerations ........................................15
+ 5. References .....................................................16
+ 5.1. Normative References ......................................16
+ 5.2. Informative References ....................................17
+ Appendix A. History and Current Use of PDF with RFCs and
+ Internet-Drafts .......................................18
+ A.1. RFCs .......................................................18
+ A.2. Internet-Drafts ............................................18
+ Appendix B. Paged Content Layout Quality ..........................18
+ Appendix C. Tooling ...............................................19
+ C.1. PDF Viewers ................................................19
+ C.2. Printers ...................................................19
+ C.3. PDF Generation Libraries ...................................20
+ C.4. Typefaces ..................................................20
+ C.5. Other Tools ................................................20
+ IAB Members at the Time of Approval ...............................21
+ Acknowledgements ..................................................21
+ Authors' Addresses ................................................22
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 2]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+1. Introduction
+
+ The RFC Series is evolving, as outlined in [RFC6949]. Future
+ documents will use a canonical format, XML, with renderings in
+ various formats, including PDF.
+
+ Because PDF has a wide range of capabilities and alternatives, not
+ all PDFs are "equal". For example, visually similar documents could
+ consist of scanned or rasterized images, or include text layout
+ options, hyperlinks, embedded fonts, and digital signatures. (See
+ [APP-PDF] for a history of PDF.)
+
+ This document explains some of the relevant options and makes
+ recommendations, for both the RFC Series and Internet-Drafts.
+
+ The PDF format and the tools to manipulate it are not as well known
+ as those for the other RFC formats, at least in the IETF community.
+ This document discusses some of the processes for creating and using
+ PDFs using both open source and commercial products.
+
+ The details described in this document are expected to change based
+ on experience gained in implementing the new publication toolsets.
+ Revised documents will be published capturing those changes as the
+ toolsets are completed. Other implementers must not expect those
+ changes to remain backwards-compatible with the details described in
+ this document.
+
+2. Choosing PDF Versions and Standards
+
+ PDF [PDF] 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", but even so, the older the
+ PDF version produced, the more legacy viewers will support that
+ version but the fewer features will be enabled.
+
+ As PDF has evolved a broad set of capabilities, additional standards
+ for PDF files are applicable. These standards establish ground rules
+ that are important for specific applications. For example, PDF/X was
+ specifically designed for Prepress digital data exchange, with
+ careful attention to color management and printing instructions. The
+ PDF/E standard was designed for engineering documents with dynamic
+ workflows (where a document continues to be revised after
+ publication) and allows interactive media (including animation
+ and 3D).
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 3]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ Two additional standards families are important to the RFC format,
+ though: long-term preservation (PDF/A), and user accessibility
+ (PDF/UA [PDFUA]). These then have sub-profiles (PDF/A-1, PDF/A-2
+ [PDFA2], PDF/A-3 [PDFA3]), each of which has conformance levels.
+ These standards are then supported by various software libraries and
+ tools.
+
+ It is effective and useful to use these standards to capture PDF for
+ RFC requirements, and they will make the PDF files useful in
+ workflows that expect them.
+
+ Recommendations:
+
+ o Use PDF 1.7; although relatively recent, it is well supported by
+ widely available viewers.
+
+ o For RFCs, require PDF/A-3 with conformance level "U". This
+ captures the archivability and long-term stability of PDF 1.7
+ files, mandatory Unicode mapping (Sections 14.8.2.4.2 ("Unicode
+ Mapping in Tagged PDF") and 9.10.2 ("Mapping Character Codes to
+ Unicode Values") of [PDF]), and many of the requirement features.
+
+ o Use PDF/A-3 for embedding additional data (including the XML
+ source file) in RFCs and Internet-Drafts.
+
+ o Use PDF/UA for user accessibility.
+
+3. Options and Requirements for PDF RFCs
+
+ This section lays out options and requirements for PDFs produced by
+ the RFC Editor for RFCs. There are two subsections: Section 3.1
+ covers "visible" requirements related to how the PDF normally appears
+ when it is viewed with a PDF viewer; Section 3.2 covers "invisible"
+ options and requirements, which primarily affect the ability to
+ process PDFs in other ways but do not ordinarily control the way the
+ document appears. (Of course, a viewer UI might display processing
+ capabilities, such as showing whether a document has been digitally
+ signed.)
+
+ In many cases, the choice of PDF requirements is heavily influenced
+ by the capabilities of available tools to create PDFs. Most of the
+ discussion of tooling is to be found in Appendix C.
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 4]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+3.1. "Visible" Requirements
+
+ PDF supports rich visible layout of fixed-sized pages.
+
+3.1.1. General Visible Requirements
+
+ For a consistent "look" of RFCs and good style, the PDFs produced by
+ the RFC Editor should have a clear, consistent, identifiable, and
+ easy-to-read style. They should print well on the widest range of
+ printers and should look good on displays of varying resolution.
+
+3.1.2. Page Size and Margins
+
+ PDF files are laid out for a particular size of page and margins.
+ There are two paper sizes in common use: "US Letter" (8.5x11 inches,
+ 216x279 mm, in popular use in North America) and "A4" (210x297 mm,
+ 8.27x11.7 inches, standard for the rest of the world). Usually, PDF
+ printing software is used in a "shrink to fit" mode where the
+ printing is adjusted to fit the paper in the printer. There is some
+ controversy, but the argument that A4 is an international standard is
+ compelling. However, if the margins and header positioning are
+ chosen appropriately, the document can be printed without any
+ scaling.
+
+ Recommendation: The Internet-Draft and RFC processors should produce
+ A4 size by default. However, the margins and header positioning
+ need to be chosen to look good on both paper sizes without
+ scaling. Following the advice found in [RFC2346], this means that
+ we should use A4 portrait mode with left and right margins of
+ 20 mm, and top and bottom margins of 33 mm.
+
+3.1.3. Headers and Footers
+
+ Page headers and footers are part of the page layout. There are a
+ variety of options. Note that page headers and footers in PDF can be
+ typeset in a way that the entire (longer) title might fit.
+
+ Recommendation: Page headers and footers should contain information
+ similar to the headings in the current text versions of documents,
+ including page numbers, title, author, and date. However, the
+ page headers and footers should be typeset in a way so as to be
+ unobtrusive. The page headers and footers should be placed into
+ the PDF in such a way that they do not interfere with screen
+ readers.
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 5]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+3.1.4. Paragraph Numbering
+
+ One common feature of the Internet-Draft output formats is optional
+ visible paragraph numbers, to aid in discussions. In the PDF, and
+ thus in the printed rendition, it is possible to make paragraph
+ numbers unobtrusive and even to impinge on the margins.
+
+ Recommendation: When the XML "editing=yes" option has been chosen,
+ show paragraph numbers in the right margin, typeset in a way so as
+ to be unobtrusive. (The right margin instead of the left margin
+ prevents the paragraph numbers from being confused with the
+ section numbers.) If possible, the paragraph numbers should be
+ coded in such a way that they do not interfere with screen
+ readers.
+
+3.1.5. Paged Content Layout
+
+ By its nature, PDF is paginated, so pagination issues must be
+ considered. This is reflected in two areas: running headers and
+ footers, and how text is laid out on a page for optimal reading.
+
+ Appendix B describes the process of creating a paged document from
+ running text such that related material is present on the same page
+ together and artifacts of pagination don't interfere with easy
+ reading of the document.
+
+ Layout engines differ in the quality of the algorithms used to
+ automate these processes. In some cases, the automated processes
+ require some manual assistance to ensure, for example, that a text
+ line intended as a heading is "kept" with the text for which it is a
+ heading.
+
+ Recommendations:
+
+ o Headers and footers should be printed on each page. The
+ information should include the RFC number or Internet-Draft name,
+ the page number, the category (e.g., Informational), a shortened
+ version of the authors' names, the date of the RFC or
+ Internet-Draft, and the short form of the document title.
+
+ o Choose a layout engine so that
+
+ * manual intervention is minimized
+
+ * widow and orphan processing is automatic
+
+ * heading and title contiguation is automatic
+
+
+
+
+Hansen, et al. Informational [Page 6]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+3.1.6. Typeface Choices
+
+ A PDF may refer to a font by name, or it may use an embedded font.
+ When a font is not embedded, a PDF viewer will attempt to locate a
+ locally installed font of the same name. If it cannot find an exact
+ match, it will find a "close match". If a close match is not
+ available, it will fall back to something implementation dependent
+ and usually undesirable.
+
+ In addition, the PDF/A standards mandate the embedding of fonts.
+ Instead of using additional software to embed the fonts, the software
+ generating the PDF files should produce PDF/A-conforming files
+ directly, thus ensuring that all glyphs include Unicode mappings and
+ embedded fonts from the outset.
+
+ If the HTML version of the document is being visually mimicked, the
+ font(s) chosen should have both variable-width and constant-width
+ components, as well as bold and italic representations.
+
+ The typefaces used by Internet-Drafts and by RFCs need not be
+ identical.
+
+ Few fonts have glyphs for the entire repertoire of Unicode
+ characters; for this purpose, the PDF generation tool may need a set
+ of fonts and a way of choosing them. The RFC Editor is defining
+ where Unicode characters may be used within RFCs [RFC7997].
+
+ Typefaces are typically licensed, and in many cases there is a fee
+ for use by PDF creation tools; however, there is usually no fee for
+ display or print of the embedded fonts.
+
+ Recommendations:
+
+ o For consistent viewing, all fonts should be embedded. The fonts
+ used must be available for use by the IETF community. Some
+ discussion of available typefaces can be found in Appendix C.4.
+
+ o The choice of typefaces with respect to serif, sans-serif,
+ monospace, etc., should follow the recommendations for HTML and
+ CSS renderings ("CSS" refers to a Cascading Style Sheet) [RFC7992]
+ and [RFC7993].
+
+ o The range of Unicode characters allowed in the XML source for
+ Internet-Drafts and RFCs may be bounded by the availability of
+ embeddable fonts with appropriate glyphs [RFC7997].
+
+
+
+
+
+
+Hansen, et al. Informational [Page 7]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+3.1.7. Hyphenation and Line Breaks
+
+ Typically, when doing page layout of running text, especially with
+ narrow page width and long words, layout processors of English text
+ often have the option of either hyphenating words or using existing
+ hyphens as a place to introduce word breaks. However, inserting line
+ breaks mid-word can be harmful when the "word" is actually a sequence
+ of characters representing a protocol element or protocol sequence.
+
+ Recommendation: Avoid introducing hyphenated line breaks mid-word
+ into the visual display, consistent with requirements for
+ plain text and HTML.
+
+3.1.8. Hyperlinks
+
+ PDF supports hyperlinks to sections of the same document and also to
+ sections of other documents.
+
+ The conversion to PDF can generate:
+
+ o hyperlinks within the document
+
+ o hyperlinks to other RFCs and Internet-Drafts
+
+ o hyperlinks to external locations
+
+ o hyperlinks within a table of contents
+
+ o hyperlinks within an index
+
+ Recommendations:
+
+ o All hyperlinks available in the HTML rendition of the RFC should
+ also be visible and active in the PDF produced. This includes
+ both internal hyperlinks and hyperlinks to external resources.
+
+ o The table of contents, including page numbers, is useful when
+ printed. Section numbers and page numbers in the table of
+ contents should also be hyperlinked to their respective sections
+ in the body of the document.
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 8]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ o As specified in Section 4.8.6.2 ("Referencing RFCs") of [RFC7322],
+ hyperlinks to RFCs from the references section should point to the
+ RFC "info" page (e.g., <https://www.rfc-editor.org/info/rfc7322>),
+ which then links to the various formats available.
+
+ o Hyperlinks to Internet-Drafts from the references section should
+ point to the Datatracker entry page for the draft, which then
+ links to the various formats available.
+
+3.1.9. Similarity to Other Outputs
+
+ There is some advantage to having the PDF files look like the text or
+ HTML renderings of the same document. Even so, there are several
+ options. The PDF
+
+ 1. could look like the text version of the document, or
+
+ 2. could look like the text version of the document but with
+ pictures rendered as pictures instead of using their ASCII art
+ equivalent, or
+
+ 3. could look like the HTML version.
+
+ Recommendation: The PDF rendition should look like the HTML
+ rendition, at least in spirit. Some differences from the HTML
+ rendition would include different typeface and size (chosen for
+ printing), page numbers in the table of contents and index, and
+ the use of page headers and footers.
+
+ Most of the choices used for the renderings per [RFC7992] and
+ [RFC7993] are thus applicable. See those documents for specifics on
+ the rendering of the specific XML elements. Some notes:
+
+ o Every place in the document that would receive an HTML ID would be
+ given an identical PDF named destination. In addition, a named
+ destination will be created for each page with the form "pg-#", as
+ in "pg-35".
+
+ o No pilcrows are generated or made visible.
+
+ o The table of contents (generated if the XML's <rfc> element's
+ tocInclude attribute has the value "true") [RFC7991] will have the
+ section number linked to the section start but will also include a
+ page number that is linked to the corresponding page. The section
+ title and the page number will be separated by a visually
+ appropriate separator, and the page numbers will be aligned with
+ each other.
+
+
+
+
+Hansen, et al. Informational [Page 9]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ o The index (generated if the XML's <rfc> element's indexInclude
+ attribute has the value "true") will have the section number
+ linked to that section named destination but will also include a
+ page number that is linked to the page named destination.
+
+ o The running header in one line (on page 2 and all subsequent
+ pages) has the RFC number on the left (RFC NNNN), the (possibly
+ shortened form) title centered, and the date (Month Year) on the
+ right. The text is rendered in a way that is visually
+ unobtrusive.
+
+ o The running footer in one line (on all pages) has the author's
+ last name on the left, category centered, and the page number on
+ the right ([Page N]). The text is rendered in a way that is
+ visually unobtrusive.
+
+ o We should not attempt to replicate in PDF the feature of the HTML
+ format that includes a dynamic block that displays up-to-date
+ information on updates, obsoletions, and errata.
+
+3.2. "Invisible" Options and Requirements
+
+ PDF offers a number of features that improve the utility of PDF files
+ in a variety of workflows, at the cost of extra effort in the xml2rfc
+ conversion process; the trade-offs may be different for the
+ RFC Editor production of RFCs and for Internet-Drafts.
+
+3.2.1. Internal Text Representation
+
+ The contents of a PDF file can be represented in many ways. The PDF
+ file could be generated:
+
+ o as an image of the visual representation, such as a JPEG image of
+ the word "IETF". That is, there might be no internal
+ representation of letters, words, or paragraphs at all.
+
+ o placing individual characters in position on the page, such as
+ saying "put an 'F' here," then "put a 'T' before it," then "put an
+ 'E' before that," then "put an 'I' before that" to render the word
+ "IETF". That is, there might be no internal representation of
+ words or paragraphs at all.
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 10]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ o placing words in position on the page, such as keeping the
+ characters of the word "IETF" together. That is, there might be
+ no internal representation of paragraphs at all.
+
+ o ensuring that the running order of text in the content stream
+ matches the logical reading order. That is, a sentence such as
+ "The Internet Engineering Task Force (IETF) supports the
+ Internet." would be kept together as a sentence, and multiple
+ sentences within a paragraph would be kept together.
+
+ All of these end up with essentially the same visual representation
+ of the output. However, each level has trade-offs for auxiliary
+ uses, such as searching or indexing, commenting and annotation, and
+ accessibility (text-to-speech). Keeping the running order of text in
+ the content stream in the proper order supports all of these
+ auxiliary uses.
+
+ In addition, the "role map" feature of PDF (Section 14.7.3
+ ("Structure Types") of [PDF]) would allow for the mapping of the
+ logical tags found in the original XML into tags in the PDF.
+
+ Recommendations:
+
+ o Text in content streams should follow the XML document's logical
+ order (in the order of tags) to the extent possible. This will
+ provide optimal reuse by software that does not understand
+ Tagged PDF. (PDF/UA requires this.)
+
+ o It might be possible to use the "role map" annotation to capture
+ enough of the xml2rfc source structure, to the point where it is
+ possible to reconstruct the XML source structure completely.
+ However, there is not a compelling case to do so over embedding
+ the original XML, as described in Section 3.2.7.
+
+3.2.2. Unicode Support
+
+ PDF itself does not require the use of Unicode. Text is represented
+ as a sequence of glyphs that can then be mapped to Unicode.
+
+ Recommendations:
+
+ o PDF files generated must have the full text, as it appears in the
+ original XML.
+
+ o Unicode normalization may occur.
+
+
+
+
+
+
+Hansen, et al. Informational [Page 11]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ o Text within SVG for SVG images should also have Unicode mappings.
+
+ o Alt-text for images should also support Unicode.
+
+3.2.3. Image Processing (Artwork)
+
+ The XML allows both ASCII art and SVG to be used for artwork.
+
+ Recommendations:
+
+ o If both ASCII art and SVG are available for a picture, the SVG
+ artwork should be preferred over the ASCII artwork.
+
+ o ASCII artwork must be rendered using a monospace font.
+
+3.2.4. Text Description of Images (Alt-Text)
+
+ Guidelines for the accessibility of PDF
+ <http://www.w3.org/TR/WCAG20-TECHS/PDF1.html> recommend that images,
+ formulas, and other non-text items provide textual alternatives,
+ using the "/Alt" Tag in PDF to provide human-readable text that can
+ be vocalized by text-to-speech technology.
+
+ Recommendation: Any alt-text for artwork and figures available in
+ the XML source should be stored using the PDF /Alt property.
+ Internet-Draft authors and the RFC Editor should ensure that
+ alt-text for all SVG or images is included within the XML source.
+
+3.2.5. Metadata Support
+
+ Metadata encodes information about the document authors, the document
+ series, date created, etc. Having this metadata within the PDF file
+ allows it to be used by search engines, viewers, and other reuse
+ tools. PDF supports embedded metadata in a variety of ways,
+ including using the Extensible Metadata Platform (XMP) [XMP]. The
+ RFC Editor maintains metadata about an RFC on its info page.
+
+ Recommendation: The PDFs generated should have all of the metadata
+ from the XML version embedded directly as XMP metadata, including
+ the author, date, the document series, and a URL for where the
+ document can be retrieved. This information should be consistent
+ with the RFC Editor info page at the time of publication.
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 12]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+3.2.6. Document Structure Support
+
+ PDF supports an "outline" feature where sections of the document are
+ marked; this could be used in addition to the table of contents as a
+ navigation aid.
+
+ The section structure of an RFC can be mapped into the PDF elements
+ for the document structure. This will allow the bookmark feature of
+ PDF readers to be used to quickly access sections of the document.
+
+ Recommendation: The section structure of an RFC should be mapped
+ into the PDF elements for the document structure. This would
+ include section headings for the boilerplate sections, such as the
+ Abstract, the Status of This Memo section, the table of contents,
+ and the Author's Address section, plus the obvious section
+ headings that are normally included in the table of contents. If
+ possible, this should be done in a way that the same fragment
+ identifiers for the HTML version of the RFC will work for the PDF
+ version.
+
+3.2.7. Embedded Files
+
+ PDF has the capability of including other files; the files may be
+ labeled by both a media type and a role, the AFRelationship key
+ [PDFA3]. In this way, the PDF file also acts as a container.
+
+ Embedded content may be compressed.
+
+ Many PDF viewers support the ability to view and extract embedded
+ files, although this capability is not universal.
+
+ Embedding content in the PDF file allows the PDF to act as a complete
+ package that can be transformed, archived, and digitally signed.
+ (Some sample code illustrating how items can be attached to a PDF
+ file and subsequently extracted can be found at
+ <https://github.com/Aiybe/xmptest>.) Useful possibilities:
+
+ o Embed the source XML input file itself within the PDF. If the
+ source SVG and images for illustrations are also embedded, this
+ would make the PDF file totally self-referential.
+
+ o Embed directly extractable components that are useful for
+ independent processing, including ABNF, MIBs, and source code for
+ reference implementations. This capability might be supported
+ through other mechanisms from the XML source files but could also
+ be supported within the PDF.
+
+
+
+
+
+Hansen, et al. Informational [Page 13]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ o Finding, extracting, and embedding other components may require
+ additional markup to clearly identify them and additional review
+ to ensure the correctness of embedded files that are not visible.
+
+ Recommendations:
+
+ o Embed the XML source and all illustrations, for RFCs, as a
+ standard feature for xml2rfc's PDF output.
+
+ o If possible, make this a standard feature for Internet-Drafts
+ as well.
+
+ o Named <sourcecode> entries should be embedded.
+
+ o Bitmap images (SVG sources, JPEGs, PNGs, etc.) should be embedded.
+
+3.3. Digital Signatures
+
+ The RFC Editor and staff are at times called to provide evidence that
+ a particular RFC is the "original" and has not been modified; digital
+ signatures can provide that verification. As signatures also apply
+ to embedded content, embedding the XML source will provide a way of
+ signing the source XML that was used to produce the PDF file as well.
+
+ PDF has supported digital signatures since PDF 1.2, and there are
+ multiple methods and options available for signing PDF files. The
+ method chosen for the signing of Internet-Drafts and RFCs will be
+ determined by separate policy.
+
+ If PDF digital signatures are chosen, the authors suggest the
+ following:
+
+ o PDF documents generated by the Internet-Draft upload tools should
+ be signed with no restrictions on what can be done to the
+ documents afterwards.
+
+ o If Internet-Drafts are allowed to be uploaded in PDF form by an
+ individual, the signature being added should be set in the same
+ way as that noted in the previous paragraph. A PDF that would not
+ allow the IETF Secretariat to re-sign it in that fashion should be
+ rejected.
+
+ o PDF documents generated by the RFC Editor should be signed and
+ certified, and restrictions placed on them to only allow
+ additional signatures and comments (markup) to be added.
+
+
+
+
+
+
+Hansen, et al. Informational [Page 14]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+4. Security Considerations
+
+ The following security considerations apply:
+
+ Threats:
+
+ o There is a risk that user-submitted Internet-Drafts in PDF might
+ contain malware that targets a vulnerability in one of the
+ deployed PDF consumers (readers, printers, validation tools, etc.)
+ in use.
+
+ o There is a small risk that a PDF production toolset might itself
+ have some vulnerability by which it could be tricked into
+ producing malware-bearing PDF files.
+
+ o Section 7 of [RFC3778] describes some additional security
+ considerations for PDF, although this specification is intended to
+ avoid features (like scripting) that might trigger some of those
+ concerns.
+
+ Mitigations:
+
+ o The toolsets for producing PDFs need careful security reviews
+ before deploying broadly.
+
+ o If users are allowed to submit Internet-Drafts in PDF, such PDF
+ files should be examined carefully for conformance to this
+ specification, as well as any known exploits of deployed PDF
+ software.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 15]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+5. References
+
+5.1. Normative References
+
+ [PDF] ISO, "Document management -- Portable document format --
+ Part 1: PDF 1.7", ISO 32000-1, 2008.
+
+ Also available free from Adobe.
+
+ [XMP] ISO, "Graphic technology -- Extensible metadata platform
+ (XMP) specification -- Part 1: Data model, serialization
+ and core properties", ISO 16684-1, 2012.
+
+ Not available free, but there are a number of descriptive
+ resources, e.g., <http://en.wikipedia.org/wiki/
+ Extensible_Metadata_Platform>.
+
+ [PDFA2] ISO, "Document management -- Electronic document file
+ format for long-term preservation -- Part 2: Use of
+ ISO 32000-1 (PDF/A-2)", ISO 19005-2, 2011.
+
+ [PDFA3] 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.
+
+ [PDFUA] 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.
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 16]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+5.2. Informative References
+
+ [RFC2346] Palme, J., "Making Postscript and PDF International",
+ RFC 2346, DOI 10.17487/RFC2346, May 1998,
+ <http://www.rfc-editor.org/info/rfc2346>.
+
+ [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
+ Requirements and Future Development", RFC 6949,
+ DOI 10.17487/RFC6949, May 2013,
+ <http://www.rfc-editor.org/info/rfc6949>.
+
+ [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
+ DOI 10.17487/RFC7322, September 2014,
+ <http://www.rfc-editor.org/info/rfc7322>.
+
+ [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
+ RFC 7991, DOI 10.17487/RFC7991, December 2016,
+ <http://www.rfc-editor.org/info/rfc7991>.
+
+ [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in
+ RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
+ <http://www.rfc-editor.org/info/rfc7997>.
+
+ [RFC7993] Flanagan, H., "Cascading Style Sheets (CSS) Requirements
+ for RFCs", RFC 7993, DOI 10.17487/RFC7993, December 2016,
+ <http://www.rfc-editor.org/info/rfc7993>.
+
+ [RFC7992] Hildebrand, J., Ed., and P. Hoffman, "HTML Format for
+ RFCs", RFC 7992, DOI 10.17487/RFC7992, December 2016,
+ <http://www.rfc-editor.org/info/rfc7992>.
+
+ [APP-PDF] Hardy, M., Masinter, L., Markovic, D., Johnson, D., and M.
+ Bailey, "The application/pdf Media Type", Work in
+ Progress, draft-hardy-pdf-mime-04, September 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 17]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+Appendix A. History and Current Use of PDF with RFCs and
+ Internet-Drafts
+
+ NOTE: This section is meant as an overview to give some background.
+
+A.1. RFCs
+
+ The RFC Series has for a long time accepted Postscript renderings of
+ RFCs, either in addition to or instead of the text renderings of
+ those same RFCs. These have usually been produced when there was a
+ complicated figure or mathematics within the document. For example,
+ consider the figures and mathematics found in RFCs 1119 and 1142, and
+ compare the figures found in the text version of RFC 3550 with those
+ in the Postscript version. The RFC Editor has provided a PDF
+ rendering of RFCs. Usually, this has been a print of the text file
+ that does not take advantage of any of the broader PDF functionality,
+ unless there was a Postscript version of the RFC, which would then be
+ used by the RFC Editor to generate the PDF.
+
+A.2. Internet-Drafts
+
+ In addition to PDFs generated and published by the RFC Editor, the
+ IETF tools community has also long supported PDF for Internet-Drafts.
+ Most RFCs start with Internet-Drafts, edited by individual authors.
+ The Internet-Drafts submission tool at <https://datatracker.ietf.org/
+ submit/> accepts PDF and Postscript files in addition to the
+ (required) text submission and (currently optional) XML. If a PDF
+ wasn't submitted for a particular version of an Internet-Draft, the
+ tools would generate one from the Postscript, HTML, or text.
+
+Appendix B. Paged Content Layout Quality
+
+ The process of creating a paged document from running text typically
+ involves ensuring that related material is present on the same page
+ together and that artifacts of pagination don't interfere with easy
+ reading of the document. Typical high-quality layout processors do
+ several things:
+
+ Widow and Orphan Management: Widows and orphans
+ (<https://en.wikipedia.org/wiki/Widows_and_orphans>) should be
+ avoided automatically (unless the entire paragraph is only one
+ line). Ensure that a page break does not occur after the first
+ line of a paragraph (orphans), if necessary, using slightly longer
+ page sizes. Similarly, ensure that a page break does not occur
+ before the last line of a paragraph (widows).
+
+
+
+
+
+
+Hansen, et al. Informational [Page 18]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ Keep Section Heading Contiguous: Do not insert a page break
+ immediately after a section heading. If there isn't room on a
+ page for the first (two) lines of a section after the section
+ heading, insert a page break before the heading.
+
+ Avoid Splitting Artwork: Figures should not be split from figure
+ titles. If possible, keep the figure on the same page as the
+ (first) mention of the figure.
+
+ Headers for Long Tables after Page Breaks: Another common option in
+ producing paginated documents is to include the column headings of
+ a table if the table cannot be displayed on a single page.
+ Similarly, tables should not be split from the table titles.
+
+ keepWithNext and keepWithPrevious: The XML attributes "keepWithNext"
+ and "keepWithPrevious" should be used and followed whenever
+ possible.
+
+ Whitespace Preservation: The Unicode Points for XML entities such as
+ Non-Breaking Space (nbsp) and Non-Breaking Hyphen (nbhy) should be
+ followed as directed whenever possible.
+
+Appendix C. Tooling
+
+ This section discusses tools for viewing, comparing, creating,
+ manipulating, and transforming PDF files, including those currently
+ in use by the RFC Editor and Internet-Drafts, as well as outlining
+ available PDF tools for various processes.
+
+C.1. PDF Viewers
+
+ As with most file formats, 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.
+
+ PDF viewers vary in capabilities, and it is important to note which
+ PDF viewers support the features utilized in PDF RFCs and
+ Internet-Drafts (features such as links, digital signatures, Tagged
+ PDF, and others mentioned in Section 3).
+
+C.2. Printers
+
+ While almost all viewers also support the printing of PDF files,
+ printing is one of the most important use cases for PDFs. Some
+ printers have direct PDF support.
+
+
+
+Hansen, et al. Informational [Page 19]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+C.3. PDF Generation Libraries
+
+ Because the xml2rfc format is a unique format, software for
+ converting XML source documents to the various formats will be
+ needed, including PDF generation.
+
+ One promising direction is suggested in
+ <http://greenbytes.de/tech/webdav/rfc2629xslt/
+ rfc2629xslt.html#output.pdf.fop>: using XSLT (Extensible Stylesheet
+ Language Transformations) to generate XSL-FO (XSL Formatting
+ Objects); XSL-FO is then processed by a FOP (Formatting Objects
+ Processor) such as Apache FOP.
+
+ Several libraries are also available for generating PDF signatures.
+ The choice of library to use for xml2pdf will depend on many factors:
+ programming language, quality of implementation, quality of PDF
+ generated, support, cost, availability, and so forth.
+
+C.4. Typefaces
+
+ Various typefaces are available that might satisfy the requirements
+ of this document. Google's Noto typeface family
+ <https://www.google.com/get/noto/> supports a significant subset of
+ Unicode and includes fixed-width, serif, and sans-serif styles.
+ Another potentially useful set of typefaces (without extensive
+ Unicode support, however) includes:
+
+ o Source Sans Pro <https://en.wikipedia.org/wiki/Source_Sans_Pro>
+
+ o Source Serif Pro <https://en.wikipedia.org/wiki/Source_Serif_Pro>
+
+ o Source Code Pro <https://en.wikipedia.org/wiki/Source_Code_Pro>
+
+ Another font that looks promising for its broad Unicode support is
+ Skolar <https://www.rosettatype.com/Skolar>, but it requires
+ licensing.
+
+C.5. Other Tools
+
+ In addition to generating and viewing PDF, other categories of PDF
+ tools are available and may be useful both during specification
+ development and for published RFCs. These include tools for
+ comparing two PDFs, checkers that could be used to validate the
+ results of conversion, reviewing and commentary tools that attach
+ annotations to PDF files, and digital signature creation and
+ validation.
+
+
+
+
+
+Hansen, et al. Informational [Page 20]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+ Validation of an arbitrary author-generated PDF file would be quite
+ difficult; there are few PDF validation tools. However, if RFCs and
+ Internet-Drafts are generated by conversion from XML via xml2rfc,
+ then explicit validation of PDF and adherence to expected profiles
+ would mainly be useful to ensure that xml2rfc has functioned
+ properly.
+
+ Recommendation: Discourage (but allow) submission of a PDF
+ representation for Internet-Drafts. In most cases, the PDF for an
+ Internet-Draft should be produced automatically when XML is
+ submitted, with an opportunity to verify the conversion.
+
+IAB Members at the Time of Approval
+
+ The IAB members at the time this memo was approved were
+ (in alphabetical order):
+
+ Jari Arkko
+ Ralph Droms
+ Ted Hardie
+ Joe Hildebrand
+ Russ Housley
+ Lee Howard
+ Erik Nordmark
+ Robert Sparks
+ Andrew Sullivan
+ Dave Thaler
+ Martin Thomson
+ Brian Trammell
+ Suzanne Woolf
+
+Acknowledgements
+
+ The input of the following people is gratefully acknowledged: Nevil
+ Brownlee (ISE), Brian Carpenter, Chris Dearlove, Martin Duerst,
+ Heather Flanagan (RSE), Joe Hildebrand, Paul Hoffman, Duff Johnson,
+ Ted Lemon, Sean Leonard, Henrik Levkowetz, Julian Reschke,
+ Adam Roach, Leonard Rosenthol, Alice Russo, Robert Sparks, Andrew
+ Sullivan, and Dave Thaler.
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 21]
+
+RFC 7995 PDF for RFCs December 2016
+
+
+Authors' Addresses
+
+ Tony Hansen (editor)
+ AT&T Laboratories
+ 200 Laurel Ave. South
+ Middletown, NJ 07748
+ United States of America
+
+ Email: tony@att.com
+
+
+ Larry Masinter
+ Adobe
+ 345 Park Ave.
+ San Jose, CA 95110
+ United States of America
+
+ Email: masinter@adobe.com
+ URI: http://larrymasinter.net
+
+
+ Matthew Hardy
+ Adobe
+ 345 Park Ave.
+ San Jose, CA 95110
+ United States of America
+
+ Email: mahardy@adobe.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al. Informational [Page 22]
+