From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7995.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc7995.txt (limited to 'doc/rfc/rfc7995.txt') 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., ), + 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 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 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 + 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 + .) 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 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., . + + [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, + . + + + + + + + + + + + + + + + + + +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, + . + + [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format + Requirements and Future Development", RFC 6949, + DOI 10.17487/RFC6949, May 2013, + . + + [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, + DOI 10.17487/RFC7322, September 2014, + . + + [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", + RFC 7991, DOI 10.17487/RFC7991, December 2016, + . + + [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in + RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, + . + + [RFC7993] Flanagan, H., "Cascading Style Sheets (CSS) Requirements + for RFCs", RFC 7993, DOI 10.17487/RFC7993, December 2016, + . + + [RFC7992] Hildebrand, J., Ed., and P. Hoffman, "HTML Format for + RFCs", RFC 7992, DOI 10.17487/RFC7992, December 2016, + . + + [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 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 + () 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 + : 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 + 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 + + o Source Serif Pro + + o Source Code Pro + + Another font that looks promising for its broad Unicode support is + 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] + -- cgit v1.2.3