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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/