idnits 2.17.1 draft-hansen-rfc-use-of-pdf-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2015) is 3119 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'XMP' is mentioned on line 643, but not defined == Missing Reference: 'PDFA3' is mentioned on line 655, but not defined == Missing Reference: 'PDF' is mentioned on line 638, but not defined == Missing Reference: 'PDFA2' is mentioned on line 651, but not defined == Missing Reference: 'PDFUA' is mentioned on line 659, but not defined -- Looks like a reference, but probably isn't: '1' on line 807 -- Looks like a reference, but probably isn't: '2' on line 809 -- Looks like a reference, but probably isn't: '3' on line 811 -- Looks like a reference, but probably isn't: '4' on line 814 -- Looks like a reference, but probably isn't: '5' on line 815 == Unused Reference: 'RFC3778' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'RFC7322' is defined on line 675, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3778 (Obsoleted by RFC 8118) == Outdated reference: A later version (-06) exists of draft-flanagan-nonascii-05 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen, Ed. 3 Internet-Draft AT&T Laboratories 4 Intended status: Informational L. Masinter 5 Expires: April 14, 2016 M. Hardy 6 Adobe 7 October 12, 2015 9 PDF for an RFC Series Output Document Format 10 draft-hansen-rfc-use-of-pdf-08 12 Abstract 14 This document discusses options and requirements for the PDF 15 rendering of RFCs in the RFC Series, as outlined in RFC 6949. It 16 also discusses the use of PDF for Internet-Drafts, and available or 17 needed software tools for producing and working with PDF. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 14, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Options and Requirements for PDF RFCs . . . . . . . . . . . . 3 55 2.1. "Visible" Requirements . . . . . . . . . . . . . . . . . 4 56 2.1.1. General Visible Requirements . . . . . . . . . . . . 4 57 2.1.2. Page Size, Margins . . . . . . . . . . . . . . . . . 4 58 2.1.3. Headers and Footers . . . . . . . . . . . . . . . . . 4 59 2.1.4. Paragraph Numbering . . . . . . . . . . . . . . . . . 4 60 2.1.5. Paged Content Layout Quality . . . . . . . . . . . . 5 61 2.1.6. Typeface Choices . . . . . . . . . . . . . . . . . . 6 62 2.1.7. Hyphenation and Line Breaks . . . . . . . . . . . . . 7 63 2.1.8. Hyperlinks . . . . . . . . . . . . . . . . . . . . . 7 64 2.1.9. Similarity to Other Outputs . . . . . . . . . . . . . 8 65 2.2. "Invisible" Options and Requirements . . . . . . . . . . 9 66 2.2.1. Internal Text Representation . . . . . . . . . . . . 9 67 2.2.2. Unicode Support . . . . . . . . . . . . . . . . . . . 10 68 2.2.3. Image Processing (Artwork) . . . . . . . . . . . . . 11 69 2.2.4. Text Description of Images (Alt-Text) . . . . . . . . 11 70 2.2.5. Metadata Support . . . . . . . . . . . . . . . . . . 11 71 2.2.6. Document Structure Support . . . . . . . . . . . . . 11 72 2.2.7. Embedded Files . . . . . . . . . . . . . . . . . . . 12 73 2.3. Digital Signatures . . . . . . . . . . . . . . . . . . . 13 74 3. Choosing PDF versions and Standards . . . . . . . . . . . . . 13 75 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 4.1. References . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.2. Informative References . . . . . . . . . . . . . . . . . 15 78 Appendix A. History and Current Use of PDF with RFCs and 79 Internet-Drafts . . . . . . . . . . . . . . . . . . 16 80 A.1. RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 A.2. Internet-Drafts . . . . . . . . . . . . . . . . . . . . . 16 82 Appendix B. Tooling . . . . . . . . . . . . . . . . . . . . . . 16 83 B.1. PDF Viewers . . . . . . . . . . . . . . . . . . . . . . . 16 84 B.2. Printers . . . . . . . . . . . . . . . . . . . . . . . . 17 85 B.3. PDF Generation Libraries . . . . . . . . . . . . . . . . 17 86 B.4. Typefaces . . . . . . . . . . . . . . . . . . . . . . . . 18 87 B.5. Other Tools . . . . . . . . . . . . . . . . . . . . . . . 18 88 Appendix C. Additional Reading . . . . . . . . . . . . . . . . . 18 89 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 The RFC Series is evolving, as outlined in [RFC6949]. Future 95 documents will use an canonical format, XML, with renderings in 96 various formats, including PDF. 98 Because PDF has a wide range of capabilities and alternatives, not 99 all PDFs are "equal". For example, visually similar documents could 100 consist of scanned or rasterized images, or include text layout 101 options, hyperlinks, embedded fonts, and digital signatures. (See 102 for a 103 history of PDF. Also see and 104 for descriptions of PDF/A and 105 PDF/UA, respectively.) 107 This document explains some of the relevant options and makes 108 recommendations, both for the RFC series and Internet-Drafts. 110 The PDF format and the tools to manipulate it are not as well known 111 as those for the other RFC formats, at least in the IETF community. 112 This document discusses some of the processes for creating and using 113 PDFs using both open source and commercial products. 115 The details described in this document are expected to change based 116 on experience gained in implementing the RFC production center's 117 toolset. Revised documents will be published capturing those changes 118 as the toolset is completed. Other implementers must not expect 119 those changes to remain backwards-compatible with the details 120 described in this document. 122 NOTE: see for XML source, 123 related files, and an issue tracker for this document. 125 2. Options and Requirements for PDF RFCs 127 This section lays out options and requirements for PDFs produced by 128 the RFC editor for RFCs. There are two sections: "Visible" options 129 are related to how the PDF appears when it is viewed with a PDF 130 viewer. "Internal Structure" options affect the ability to process 131 PDFs in other ways, but do not control the way the document appears. 132 (Of course, a viewer UI might display processing capabilities, such 133 as showing if a document has been digitally signed.) 135 In many cases, the choice of PDF requirements is heavily influenced 136 by the capabilities of available tools to create PDFs. Most of the 137 discussion of tooling is to be found in Appendix B. 139 2.1. "Visible" Requirements 141 PDF supports rich visible layout of fixed-sized pages. 143 2.1.1. General Visible Requirements 145 For a consistent "look" of RFC and good style, the PDFs produced by 146 the RFC editor should have a clear, consistent, identifiable and 147 easy-to-read style. They should print well on the widest range of 148 printers, and look good on displays of varying resolution. 150 2.1.2. Page Size, Margins 152 PDF files are laid out for a particular size of page and margins. 153 There are two paper sizes in common use: "US Letter" (8.5 x 11 154 inches, 216x279 mm, in popular use in North America) and "A4" 155 (210x297 mm, 8.27x11.7 inches, standard for the rest of the world). 156 Usually PDF printing software is used in a "shrink to fit" mode where 157 the printing is adjusted to fit the paper in the printer. There is 158 some controversy, but the argument that A4 is an international 159 standard is compelling. 161 Recommendation: The Internet-Draft and RFC processors should produce 162 A4 size by default. However, the margins and header positioning will 163 need to be chosen to look good on both paper sizes using common 164 printing methods. 166 2.1.3. Headers and Footers 168 Page headers and footers are part of the page layout. There are a 169 variety of options. Note that page headers and footers in PDF can be 170 typeset in a way that the entire (longer) title might fit. 172 Recommendation: Page headers and footers should contain similar 173 information as the headings in the current text versions of 174 documents, including page numbers, title, author, working group. 175 However, the page headers and footers should be typeset in a way so 176 as to be inobtrusive. The page headers and footers should be placed 177 into the PDF in a way not to interfere with screen readers. 179 2.1.4. Paragraph Numbering 181 One common feature of the Internet-draft output formats are optional 182 visible paragraph numbers, to aid in discussions. In the PDF and 183 thus printed rendition, it is possible to make paragraph numbers 184 unobtrusive, and even to impinge on the margins. 186 Recommendation: When the XML "editing=yes" option has been chosen, 187 show paragraph numbers in the right margin, typeset in a way so as to 188 be inobtrusive. (The right margin instead of the left margin 189 prevents the paragraph numbers from being confused with the section 190 numbers.) If possible, the paragraph numbers should be coded in a 191 way that they do not not interfere with screen readers. 193 2.1.5. Paged Content Layout Quality 195 The process of creating a paged document from running text typically 196 involves insuring that related material is present on the same page 197 together, and that artifacts of pagination don't interfere with easy 198 reading of the document. Typical high-quality layout processors do 199 several things: 201 Widow and Orphan Management: Widows and orphans 202 () should be 203 avoided automatically (unless the entire paragraph is only one 204 line). Insure that a page break does not occur after the first 205 line of a paragraph (orphans), if necessary, using slightly longer 206 page sizes. Similarly, insure that a page break does not occur 207 before the last line of a paragraph (widows). 209 Keep Section Heading Contiguous: Do not page break immediately after 210 a section heading. If there isn't room on a page for the first 211 (two) lines of a section after the section heading, page break 212 before the heading. 214 Avoid Splitting Artwork: Figures should not be split from figure 215 titles. If possible, keep the figure on the same page as the 216 (first) mention of the figure. 218 Headers for Long Tables after Page Breaks: Another common option in 219 producing paginated documents is to include the column headings of 220 a table if the table cannot be displayed on a single page. 221 Similarly, tables should not be split from the table titles. 223 keepWithNext and keepWithPrevious: The XML attributes of 224 "keepWithNext" and "keepWithPrevious" should be followed whenever 225 possible. 227 Whitespace Preservation: The XML entities such as NBSP and NBHYPHEN 228 should be followed as directed whenever possible. 230 Layout engines differ in the quality of the algorithms used to 231 automate these processes. In some cases, the automated processes 232 require some manual assistance to insure, for example, that a text 233 line intended as a heading is "kept" with the text it is heading for. 235 Recommendation: Choose a layout engine so that manual intervention is 236 minimized, and that widow and orphan processing, heading and title 237 contiguation are automatic. 239 2.1.6. Typeface Choices 241 A PDF may refer to a font by name, or it may use an embedded font. 242 When a font is not embedded, a PDF viewer will attempt to locate a 243 locally installed font of the same name. If it can not find an exact 244 match, it will find a "close match". If a close match is not 245 available, it will fall back to something implementation dependent 246 and usually undesirable. 248 In addition, the PDF/A standards mandate the embedding of fonts. 249 Preferably, the software generating the files would produce PDF/ 250 A-conforming files directly, thus ensuring that all glyphs include 251 Unicode mappings and embedded fonts from the outset. 253 If the HTML version of the document is being visually mimicked, the 254 font(s) chosen should have both variable width and constant width 255 components, as well as bold and italic representations. 257 The typefaces used by Internet-Drafts and by RFCs need not be 258 identical. 260 Few fonts have glyphs for the entire repertoire of Unicode 261 characters; for this purpose, the PDF generation tool may need a set 262 of fonts and a way of choosing them. The RFC Editor is defining 263 where Unicode characters may be used within 264 RFCs.[I-D.flanagan-nonascii] 266 Typefaces are typically licensed and, in many cases, there is a fee 267 for use by PDF creation tools; however, not for display or print of 268 the embedded fonts. 270 Recommendations: 272 o Recommendation: for consistent viewing, all fonts should be 273 embedded. The fonts used must be available for use by the IETF 274 community. 276 o The choice of type faces with respect to serif, sans serif, 277 monospace, etc., should follow the recommendations for HTML and 278 CSS rendering [I-D.hildebrand-html-rfc] and 279 [I-D.flanagan-rfc-css]. 281 o The range of Unicode characters allowed in the XML source for 282 Internet-Drafts and RFCs may be bounded by the availability of 283 embeddable fonts with appropriate glyphs [I-D.flanagan-nonascii]. 285 2.1.7. Hyphenation and Line Breaks 287 Typically, when doing page layout of running text, especially with 288 narrow page width and long words, layout processors of English text 289 often have the option of hyphenating words, or using existing hyphens 290 as a place to introduce word breaks. However, line breaks mid-word 291 where the "word" is actually technically a sequence of characters 292 representing a protocol element or protocol sequence is actively 293 harmful. 295 Recommendation: avoid introducing hyphenated line breaks mid-word 296 into the visual display, consistent with requirements for plain text 297 and HTML. 299 2.1.8. Hyperlinks 301 PDF supports hyperlinks both to sections of the same document and to 302 other documents. 304 The conversion to PDF can generate: 306 o hyperlinks within the document 308 o hyperlinks to other RFCs and Internet-Drafts 310 o hyperlinks to external locations 312 o hyperlinks within a table of contents 314 o hyperlinks within an index 316 One question that must be answered is where should hyperlinks to RFCs 317 point? To the info page for the RFC? To the PDF version of the RFC? 319 Similar questions need to be answered on references to Internet- 320 Drafts: Where should hyperlinks to Internet-Drafts point? To the 321 datatracker entry? To the tools entry? To a PDF version of the 322 Internet-Draft? 324 Recommendations: 326 o All hyperlinks available in the HTML rendition of the RFC should 327 also be visible and active in the PDF produced. This includes 328 both internal hyperlinks and hyperlinks to external resources. 330 o The table of contents, including page numbers, are useful when 331 printed. These should also be hyperlinked to their respective 332 sections. 334 o Hyperlinks to RFCs from the references section should point to the 335 RFC "info" page, which then links to the various formats 336 available. 338 o Hyperlinks to Internet-Drafts from the references section should 339 point to the datatracker entry page for the draft, which then 340 links to the various formats available. 342 2.1.9. Similarity to Other Outputs 344 There is some advantage to having the PDF files look like the text or 345 HTML renderings of the same document. There are several options even 346 so. The PDF 348 1. could look like the text version of the document, or 350 2. could look like the text version of the document but with 351 pictures rendered as pictures instead of using their ASCII-art 352 equivalent, or 354 3. could look like the HTML version. 356 Recommendation: the PDF rendition should look like the HTML 357 rendition, at least in spirit. Some differences from the HTML 358 rendition would include different typeface and size (chosen for 359 printing), page numbers in the table of contents and index, and the 360 use of page headers and footers. 362 Most of the choices used for the [I-D.hildebrand-html-rfc] rendering 363 and [I-D.flanagan-rfc-css] are thus applicable. See those document 364 for specifics on the rendering of the specific XML elements. Some 365 notes are: 367 Every place in the document that would receive an HTML ID would be 368 given an identical PDF named destination. In addition, a named 369 destination will be created for each page with the form "pg-#", as 370 in "pg-35". 372 No pilcrows are generated or made visible. 374 The table of contents (generated if the XML's element's 375 tocInclude attribute has the value "true") will have the section 376 number linked to that section named destination, but will also 377 include a page number that is linked to the page named 378 destination. The section title and the page number will be 379 separated by a visually-appropriate separator and the page numbers 380 will be aligned with each other. 382 The index (generated if the XML's element's indexInclude 383 attribute has the value "true") will have the section number 384 linked to that section named destination, but will also include a 385 page number that is linked to the page named destination. 387 The running header in one line (on page 2 and all subsequent 388 pages) has the RFC number on the left (RFC NNNN), the (possibly 389 shortened form) title centered, and the date (Month Year) on the 390 right. The text is rendered in a way that is visually non- 391 intrusive. 393 The running footer in one line (on all pages) has the author's 394 last name on the left, category centered, and the page number on 395 the right ([Page N]). The text is rendered in a way that is 396 visually non-intrusive. 398 2.2. "Invisible" Options and Requirements 400 PDF offers a number of features which improve the utility of PDF 401 files in a variety of workflows, at the cost of extra effort in the 402 xml2rfc conversion process; the tradeoffs may be different for the 403 RFC editor production of RFCs and for Internet-Drafts. 405 2.2.1. Internal Text Representation 407 The contents of a PDF file can be represented in many ways. The PDF 408 file could be generated: 410 o as an image of the visual representation, such as a JPEG image of 411 the word "IETF". That is, there might be no internal 412 representation of letters, words or paragraphs at all. 414 o placing individual characters in position on the page, such as 415 saying "put an 'F' here", then "put an 'T' before it", then "put 416 an 'E' before that", then "put an 'I' before that" to render the 417 word "IETF". That is, there might be no internal representation 418 of words or paragraphs at all. 420 o placing words in position on the page, such as keeping the word 421 "IETF" would be kept together. That is, there might be no 422 internal representation of paragraphs at all. 424 o insuring that the running order of text in the content stream 425 matches the logical reading order. That is, a sentence sentence 426 such as 'The Internet Engineering Task Force (IETF) supports the 427 Internet.' would be kept together as a sentence, and multiple 428 sentences within a paragraph would be kept together. 430 All of these end up with essentially the same visual representation 431 of the output. However, each level has tradeoffs for auxiliary uses, 432 such as searching or indexing, commenting and annotation, and 433 accessibility (text-to-speech). Keeping the running order of text in 434 the content stream in the proper order supports all of these auxiliar 435 uses. 437 In addition, the "role map" feature of PDF 438 () would additionally 440 allow for the mapping of the logical tags found in the original XML 441 into tags in the PDF. 443 Recommendations: 445 o Text in content streams should follow the XML document's logical 446 order (in the order of tags) to the extent possible. This will 447 provide optimal reuse by software that does not understand Tagged 448 PDF. (PDF/UA requires this.) 450 o It might be possible to use the "role map" annotation to capture 451 enough of the xml2rfc source structure, to the point where it is 452 possible to reconstruct the XML source structure completely. 453 However, there is not a compelling case to do so over embedding 454 the original XML, as described in Section 2.2.7. 456 2.2.2. Unicode Support 458 PDF itself does not require use of Unicode. Text is represented as a 459 sequence of glyphs which then can be mapped to Unicode. 461 Recommendations: 463 PDF files generated must have the full text, as it appears in the 464 original XML. 466 Unicode normalization may occur. 468 Text within SVG for SVG images should also have Unicode mappings. 470 Alt-text for images should also support Unicode. 472 2.2.3. Image Processing (Artwork) 474 The XML allows both ASCII art and SVG to be used for artwork. 476 Recommendations: 478 If both ASCII art and SVG are available for a picture, the SVG 479 artwork should be the preferred over the ASCII artwork. 481 ASCII artwork must be rendered using a monospace font. 483 2.2.4. Text Description of Images (Alt-Text) 485 Guidelines for accessibility of PDF recommend that images, formulas, and other non-text 487 items provide textual alternatives, using the '/Alt' Tag in PDF to 488 provide human-readable text that can be vocalized by text-to-speech 489 technology. 491 Recommendation: Any alt-text for artwork and figures available in the 492 XML source should be stored using the PDF /Alt property. Internet 493 draft authors and the RFC editor should insure inclusion of alt-text 494 for all SVG or images, within the XML source. 496 2.2.5. Metadata Support 498 Metadata encodes information about the document authors, the document 499 series, date created, etc. Having this metadata within the PDF file 500 allows it to be used by search engines, viewers and other reuse 501 tools. PDF supports embedded metadata in a variety of ways, 502 including using XMP [XMP], the Extensible Metadata Platform (XMP). 503 The RFC editor maintains metadata about an RFC on its info page. 505 Recommendation: The PDFs generated should have all of the metadata 506 from the XML version embedded directly as XMP metadata, including the 507 author, date, the document series, and a URL for where the document 508 can be retrieved. This information should be consistent with the RFC 509 editor info page at the time of publication. 511 2.2.6. Document Structure Support 513 PDF supports an "outline" feature where sections of the document are 514 marked; this oould be used in addition to the table of contents as a 515 navigation aid. 517 The section structure of an RFC can be mapped into the PDF elements 518 for the document structure. This will allow the bookmark feature of 519 PDF readers to be used to quickly access sections of the document. 521 Recommendation: The section structure of an RFC should be mapped into 522 the PDF elements for the document structure. This would include 523 section headings for the boilerplate sections such as the Abstract, 524 Status of the Document, Table of Contents, and Author Addresses, plus 525 the obvious section headings that are normally included in the 526 Table of Contents. If possible, this should be done in a way that 527 the same fragment identifiers for the HTML version of the RFC will 528 work for the PDF version. 530 2.2.7. Embedded Files 532 PDF has the capability of including other files; the files may be 533 labeled both by a media type and a role, the AFRelationship key 534 [PDFA3]. In this way, the PDF file acts also as a container. 536 Embedded content may be compressed. 538 Many PDF viewers support the ability to view and extract embedded 539 files, although this capability is not universal. 541 Embedding content in the PDF file allows the PDF to act as a complete 542 package, which can be transformed, archived, and digitally signed. 543 Useful possibilities: 545 Embed the source XML input file itself within the PDF. If the 546 source SVG and images for illustrations are also embedded, this 547 would make the PDF file totally self-referential. 549 Embed directly extractable components that are useful for 550 independent processing, including ABNF, MIBs, source code for 551 reference implementations. This capability might be supported 552 through other mechanisms from the XML source files, but could also 553 be supported within the PDF. 555 Finding, extracting and embedding other components may require 556 additional markup to clearly identify them, and additional review 557 to insure the correctness of embedded files that are not visible. 559 Recommendations: 561 Embed the XML source and all illustrations, for RFCs, as a 562 standard feature for xml2rfc's PDF output. 564 If possible, make this a standard feature for Internet-Drafts as 565 well. 567 Named entries should be embedded. 569 Embedded bitmap images (SVG sources, JPEGs, PNGs, etc) should be 570 embedded. 572 2.3. Digital Signatures 574 PDF has supported digital signatures since PDF 1.2. There are 575 multiple methods for signing PDF files. The signature is intended to 576 apply not only to the bits in the file (that they haven't been 577 modified) but also to lock down the visual presentation as well. 579 Normally, the authenticity of RFC files is not an issue, since the 580 RFC editor maintains a repository of all RFCs which is widely 581 replicated. However, the RFC Editor and staff are at times called to 582 provide evidence that a particular RFC is the "original" and has not 583 been visually modified, and there may be other use cases. As 584 signatures also apply to embedded content, embedding the XML source 585 will provide a way of signing the source XML as well. 587 Recommendation: PDFs produced by the RFC editor should be signed with 588 a PDF digital signature. The management of certificates for the RFC 589 editor function needs further review. 591 Recommendation: At this time, the authors see no need for Internet- 592 Drafts to be signed with a PDF digital signature. 594 3. Choosing PDF versions and Standards 596 PDF has gone through several revisions, primarily for the addition of 597 features. PDF features have generally been added in a way that older 598 viewers 'fail gracefully', but even so, the older the PDF version 599 produced, the more legacy viewers will support that version, but the 600 fewer features will be enabled. 602 As PDF has evolved a broad set of capabilities, additional standards 603 for PDF files are applicable. These standards establish ground rules 604 that are important for specific applications. For example PDF/X was 605 specifically designed for Prepress digital data exchange, with 606 careful attention to color management and printing instructions, 607 while the PDF/E standard was designed for engineering documents. 609 Two additional standards families are important to the RFC format, 610 though: long-term preservation (PDF/A), and user acessibility (PDF/ 611 UA). These then have sub-profiles (PDF/A-1, PDF/A-2, PDF/A-3), each 612 of which have conformance levels. These standards are then supported 613 by various software libraries and tools. 615 It is effective and useful to use these standards to capture PDF for 616 RFC requirements, and they will make the PDF files useful in 617 workflows that expect them. 619 Recommendations: 621 Use PDF 1.7; although relatively recent, it is well supported by 622 widely available viewers. 624 For RFCs, require PDF/A-3 with conformance level "U". This 625 captures the archivability and long-term stability of PDF 1.7 626 files, mandatory Unicode mapping, and many of the requirement 627 features. 629 Use PDF/A-3 for embedding additional data (including the XML 630 source file) in RFCs and Internet-Drafts. 632 Use PDF/UA. 634 4. References 636 4.1. References 638 [PDF] ISO, "Portable document format -- Part 1: PDF 1.7", ISO 639 32000-1, 2008. 641 Also available free from Adobe. 643 [XMP] ISO, "Extensible metadata platform (XMP) specification -- 644 Part 1: Data model, serialization and core properties", 645 ISO 16684-1, 2012. 647 Not available free, but there are a number of descriptive 648 resources, e.g., 651 [PDFA2] ISO, "Electronic document file format for long-term 652 preservation -- Part 2: Use of ISO 32000-1 (PDF/A-2).", 653 ISO 19005-2, 2011. 655 [PDFA3] ISO, "Electronic document file format for long-term 656 preservation -- Part 3: Use of ISO 32000-1 with support 657 for embedded files (PDF/A-3)", ISO 19005-3, 2012. 659 [PDFUA] ISO, "Electronic document file format enhancement for 660 accessibility -- Part 1: Use of ISO 32000-1 (PDF/UA-1)", 661 ISO 19005-3, 2012. 663 4.2. Informative References 665 [RFC3778] Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The 666 application/pdf Media Type", RFC 3778, DOI 10.17487/ 667 RFC3778, May 2004, 668 . 670 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 671 Requirements and Future Development", RFC 6949, DOI 672 10.17487/RFC6949, May 2013, 673 . 675 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 676 DOI 10.17487/RFC7322, September 2014, 677 . 679 [I-D.flanagan-nonascii] 680 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 681 draft-flanagan-nonascii-05 (work in progress), August 682 2015. 684 [I-D.flanagan-rfc-css] 685 Flanagan, H., "CSS Requirements for RFCs", draft-flanagan- 686 rfc-css-04 (work in progress), September 2015. 688 [I-D.hildebrand-html-rfc] 689 Hildebrand, J. and P. Hoffman, "HyperText Markup Language 690 Request For Comments Format", draft-hildebrand-html-rfc-10 691 (work in progress), August 2015. 693 4.3. URIs 695 [1] https://sourceforge.net/projects/ 696 sourcesans.adobe/?source=directory 698 [2] https://sourceforge.net/projects/ 699 sourceserifpro.adobe/?source=directory 701 [3] https://sourceforge.net/projects/ 702 sourcecodepro.adobe/?source=drectory 704 [4] https://www.rosettatype.com/Skolar 706 [5] https://www.google.com/get/noto/ 708 Appendix A. History and Current Use of PDF with RFCs and Internet- 709 Drafts 711 NOTE: this section is meant as an overview to give some background. 713 A.1. RFCs 715 The RFC series has for a long time accepted Postscript renderings of 716 RFCs, either in addition to or instead of the text renderings of 717 those same RFCs. These have usually been produced when there was a 718 complicated figure or mathematics within the document. For example, 719 consider the figures and mathematics found in RFC 1119 and RFC 1142, 720 and compare the figures found in the text version of RFC 3550 with 721 those in the Postscript version. The RFC editor has provided a PDF 722 rendering of RFCs. Usually, this has been a print of the text file 723 that does not take advantage of any of the broader PDF functionality, 724 unless there was a Postscript version of the RFC, which would then be 725 used by the RFC editor to generate the PDF. 727 A.2. Internet-Drafts 729 In addition to PDFs generated and published by the RFC editor, the 730 IETF tools community has also long supported PDF for Internet-Drafts. 731 Most RFCs start with Internet-Drafts, edited by individual authors. 732 The Internet-Drafts submission tool at https://datatracker.ietf.org/ 733 submit/ accepts PDF and Postscript files in addition to the 734 (required) text submission and (currently optional) XML. If a PDF 735 wasn't submitted for a particular version of an Internet-Draft, the 736 tools would generate one from the Postscript, HTML, or text. 738 Appendix B. Tooling 740 This section discusses tools for viewing, comparing, creating, 741 manipulating, transforming PDF files, including those currently in 742 use by the RFC editor and Internet-Drafts, as well as outlining 743 available PDF tools for various processes. 745 B.1. PDF Viewers 747 As with most file formats, PDF files are experienced through a reader 748 or viewer of PDF files, and there are numerous viewers. One partial 749 list of PDF viewers can be found at . 752 PDF viewers vary in capabilities, and it is important to note which 753 PDF viewers support the features utilized in PDF RFCs and Internet- 754 Drafts (features such as links, digital signatures, Tagged PDF and 755 others mentioned in Section 2). 757 A survey of the IETF community might broaden the list of viewers in 758 common use, but an initial list to consider include some that are 759 currently maintained and supported viewers and legacy systems. 760 Maintained viewers include: 762 Adobe Reader Multiple platforms. Supports all of the features on 763 most platforms. 765 Google Chrome Multiple platforms. Web browser which includes PDF 766 support. Rapidly moving target, open source. 768 PDF.js Multiple platforms. A JavaScript library to convert PDF 769 files into HTML5, usable as a web-based viewer that can be 770 included in web browsers. Used by Mozilla Firefox. Also rapidly 771 moving target. 773 Foxit Reader Multiple platforms. PDF Viewer / Reader for Desktop 774 computer and Mobile Devices. Recently licensed by Google, and the 775 code for this purpose was made open source; see . 779 Several "legacy" viewers to consider include: Ghostview, Xpdf. 781 B.2. Printers 783 While almost all viewers also support printing of PDF files, printing 784 is one of the most important use cases for PDFs. Some printers have 785 direct PDF support. 787 B.3. PDF Generation Libraries 789 Because the xml2rfc format is a unique format, software for 790 converting XML source documents to the various formats will be 791 needed, including PDF generation. 793 One promising direction is suggested in 794 : using XSLT to generate XSL-FO which 796 is then processed by a formatting object processor such as Apache 797 FOP. 799 Several libraries are also available for generating PDF signatures. 801 B.4. Typefaces 803 This section is intended to discuss available typefaces that might 804 satisfy requirements. Some openly available fixed-width typefaces 805 (without extensive Unicode support, however) include: 807 o Source Sans [1] 809 o Source Serif Pro [2] 811 o Source Code Pro [3] 813 A font that looks promising for its broad Unicode support is Skolar 814 [4], but it requires licensing. Another potentially useful set of 815 typefaces is the Noto [5] family from Google. 817 B.5. Other Tools 819 In addition to generating and viewing PDF, other categories of PDF 820 tools are available and may be useful both during specification 821 development and for published RFCs. These include tools for 822 comparing two PDFs, checkers that could be used to validate the 823 results of conversion, reviewing and commentary tools that attach 824 annotations to PDF files, and digital signature creation and 825 validation. 827 Validation of an arbitrary author-generated PDF file would be quite 828 difficult; there are few PDF validation tools. However, if RFCs and 829 Internet-Drafts are generated by conversion from XML via xml2rfc, 830 then explicit validation of PDF and adherance to expected profiles 831 would mainly be useful to insure that xml2rfc has functioned 832 properly. 834 Recommendations: 836 o Discourage (but allow) submission of a PDF representation for 837 Internet-Drafts. In most cases, the PDF for an Internet-Draft 838 should be produced automatically when XML is suhmitted, with an 839 opportunity to verify the conversion. 841 Appendix C. Additional Reading 843 846 850 Appendix D. Acknowledgements 852 The input of the following people is gratefully acknowledged: Brian 853 Carpenter, Chris Dearlove, Martin Duerst, Heather Flanagan, Joe 854 Hildebrand, Duff Johnson, Leonard Rosenthol, .... 856 Authors' Addresses 858 Tony Hansen (editor) 859 AT&T Laboratories 860 200 Laurel Ave. South 861 Middletown, NJ 07748 862 USA 864 Email: tony+rfc2pdf@maillennium.att.com 866 Larry Masinter 867 Adobe 868 345 Park Ave 869 San Jose, CA 95110 870 USA 872 Email: masinter@adobe.com 873 URI: http://larry.masinter.net 875 Matthew Hardy 876 Adobe 877 345 Park Ave 878 San Jose, CA 95110 879 USA 881 Email: mahardy@adobe.com