idnits 2.17.1 draft-flanagan-plaintext-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 24, 2015) is 3075 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5741 (Obsoleted by RFC 7841) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Flanagan 3 Internet-Draft RFC Editor 4 Intended status: Informational November 24, 2015 5 Expires: May 27, 2016 7 Requirements for Plain-Text RFCs 8 draft-flanagan-plaintext-09 10 Abstract 12 In 2013, after a great deal of community discussion, the decision was 13 made to shift from the plain-text, ASCII-only canonical format for 14 RFCs to XML as the canonical format. The high-level requirements 15 that informed this change were defined in RFC6949, "RFC Series Format 16 Requirements and Future Development." Plain text is still an 17 important format for many in the IETF community, and will still be 18 one of the publication formats rendered from the XML. This draft 19 documents the rendering requirements for the plain-text RFC 20 publication format. These requirements do not apply to plain-text 21 RFCs published before the format transition. 23 Editorial Note (To be removed by the RFC Editor) 25 Discussion of this draft takes place on the rfc-interest mailing list 26 (rfc-interest@rfc-editor.org), which has its home page at 27 https://www.rfc-editor.org/mailman/listinfo/rfc-interest. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on May 27, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Character Encoding . . . . . . . . . . . . . . . . . . . . . 4 65 3. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 4 66 4. General Page Format Layout . . . . . . . . . . . . . . . . . 4 67 4.1. Headers and Footers . . . . . . . . . . . . . . . . . . . 5 68 4.2. Table of Contents . . . . . . . . . . . . . . . . . . . . 5 69 4.3. Line Width . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.4. Line Spacing . . . . . . . . . . . . . . . . . . . . . . 5 71 4.5. Hyphenation . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. Elements from the xml2rfc v3 vocabulary . . . . . . . . . . . 5 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 76 9. Change Log for the Draft . . . . . . . . . . . . . . . . . . 6 77 9.1. -08 to -09 . . . . . . . . . . . . . . . . . . . . . . . 6 78 9.2. -07 to -08 . . . . . . . . . . . . . . . . . . . . . . . 6 79 9.3. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . 6 80 9.4. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . 6 81 9.5. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . 7 82 9.6. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . 7 83 9.7. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . 7 84 9.8. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . 7 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 87 10.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 In 2013, after a great deal of community discussion, the decision was 93 made to shift from the plain-text, ASCII-only canonical format for 94 RFCs to XML as the canonical format [XML-ANNOUNCE]. The high-level 95 requirements that informed this change were defined in [RFC6949], 96 "RFC Series Format Requirements and Future Development." Plain text 97 is still an important format for many in the IETF community, and will 98 still be one of the publication formats rendered from the XML. This 99 draft documents the rendering requirements for the plain-text RFC 100 publication format. These requirements do not apply to plain-text 101 RFCs published before the format transition. 103 The Unicode Consortium defines 'plain text' as "Computer-encoded text 104 that consists only of a sequence of code points from a given 105 standard, with no other formatting or structural information. Plain 106 text interchange is commonly used between computer systems that do 107 not share higher-level protocols." [UNICODE-GLOSSARY] In other 108 words, plain-text files cannot include embedded character formatting 109 or style information. The actual character encoding, however, is not 110 limited to any particular sequence of code points. 112 A plain-text output for RFCs will continue to be required for the 113 foreseeable future. The details of what that means for RFCs in terms 114 of which character encoding may be used, what the page layout will 115 look like, how to handle figures and artwork, and how pagination will 116 be handled, are documented in this memo. For more details on general 117 style, see "The RFC Style Guide." [RFC7322] 119 The following assumptions drive the changes in the plain-text output 120 for RFCs: 122 o The existing tools used by the RFC Editor and many members of the 123 author community to create the text file are complicated to change 124 and support; manual manipulation is often required for the final 125 output. In particular, handling page breaks and associated widows 126 and orphans for paginated output is tricky [WIDOWS]. 128 o Additional publication formats--for example: PDF, HTML-- will be 129 available that will offer features such as markup, pretty 130 printing, etc. 132 o There is an extensive tool chain in existence among the community 133 to work with plain-text documents. Similar functionality may be 134 possible with other publication formats, but the workflow that 135 uses the existing tool chain should be supported as much as is 136 considered practical. 138 Where practical, the original guidance for the structure of a plain- 139 text RFC has been kept, such as with line lengths, lines per page, 140 etc. [INS2AUTH] 142 Note that this document provides guidance for plain-text RFCs; 143 Internet-Drafts are out of scope. 145 The details described in this document are expected to change based 146 on experience gained in implementing the RFC production center's 147 toolset. Revised documents will be published capturing those changes 148 as the toolset is completed. Other implementers must not expect 149 those changes to remain backwards-compatible with the details 150 described this document. 152 2. Character Encoding 154 Plain-text files for RFCs will use the UTF-8 [RFC3629] character 155 encoding. That said, the use of non-ASCII characters will be only 156 allowed in a limited and controlled fashion. The details regarding 157 the guidance for how to include non-ASCII characters is under 158 development and documented in "The Use of Non-ASCII Characters in 159 RFCs" [I-D.flanagan-nonascii]. Please view the PDF version of that 160 draft. 162 The plain-text file will include a byte order mark (BOM) to provide 163 text reader software with in-band information about the character 164 encoding scheme used. 166 3. Figures and Artwork 168 Authors may continue to include figures drawn with ASCII characters. 169 If the canonical format includes figures or artwork other than ASCII- 170 art, then the plain-text output must include a pointer to the 171 relevant figure in the HTML version of the RFC to allow readers to 172 see the relevant artwork. 174 Authors who wish to include ASCII-art for the plain-text file and SVG 175 art for the other outputs may do so, but they should be aware of the 176 potential for confusion to individuals reading the RFC with two 177 unique diagrams describing the same content. If there is conflicting 178 information between the publication formats, please review the XML 179 and PDF files to resolve the conflict. 181 4. General Page Format Layout 183 One plain-text output will be created during the publication process 184 with basic pagination that includes a form feed instruction every 58 185 lines at most, including blank lines. Instructions or a script will 186 be made available by and for the community to strip out pagination as 187 per individual preference. 189 4.1. Headers and Footers 191 The front matter on the front page (such as the RFC number and 192 category), and the back matter on the last page (the author's full 193 names and contact information) will continue with the structure 194 described in RFC 5741 [RFC5741], "RFC Streams, Headers, and 195 Boilerplates". Running headers and footers will no longer be added. 197 4.2. Table of Contents 199 In order to retain similar content wherever possible between the 200 various publication formats, the Table of Contents will list section 201 and subsection numbers and titles, but will not include page numbers. 203 4.3. Line Width 205 Each line must be limited to 72 characters followed by the character 206 sequence that denotes an end-of-line (EOL). The EOL sequence used by 207 the RFC Editor will be the two-character sequence CR LF (Carriage 208 Return followed by Line Feed). This limit includes any left-side 209 indentation. 211 Note that the EOL used by the RFC Editor may change with different 212 transports and as displayed in different display software. 214 4.4. Line Spacing 216 Use single-spaced text within a paragraph, and one blank line between 217 paragraphs. 219 4.5. Hyphenation 221 Hyphenated words (e.g., "Internet-Draft"), should not be split across 222 successive lines. 224 5. Elements from the xml2rfc v3 vocabulary 226 The plain-text does not attempt to render anything but the most basic 227 document metadata from the XML. The document layout and structure is 228 instead guided directly by the "RFC Style Guide." URIs that occur in 229 targets may be placed into parenthetical expressions or reference 230 entries. [I-D.hoffman-xml2rfc] 231 Since plain-text cannot include any rich-text-style formatting, such 232 as bold or italic fonts, tags such as and will not be 233 rendered in any way in the plain-text draft. 235 6. Acknowledgements 237 This draft owes a great deal of thanks to the efforts of the RFC 238 Format Design Team: Nevil Brownlee, Tony Hansen, Joe Hildebrand, Paul 239 Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert 240 Sparks, and David Thaler. 242 7. IANA Considerations 244 This memo includes no requests to IANA. 246 8. Security Considerations 248 The requirements of the plaintext format involve no significant 249 security considerations. As part of the larger format project, 250 however, unintended changes to the text as a result of the 251 transformation from the base XML file could in turn corrupt a 252 standard, practice or critical piece of information about a protocol. 254 9. Change Log for the Draft 256 9.1. -08 to -09 258 Security Considerations: added text 260 9.2. -07 to -08 262 Change log: forgot to update the change log for the -06 to -07 263 changes. 265 9.3. -06 to -07 267 Introduction: updated to state that this document does not require 268 backwards compatibility. 270 9.4. -05 to -06 272 Abstract: Changed "cut over" to "transition" 274 Elements from xml2rfc v3: emphasized that doc structure is guided by 275 the RFC Style Guide 277 9.5. -04 to -05 279 Abstract and Introduction: Revised for better readability; clarified 280 the definition and implications of the term "plain-text" 282 General Page Format Layout: Added explicit EOL detail and added some 283 clarification regarding pagination 285 Elements from the xml2rfc v3 vocabulary: section added 287 9.6. -03 to -04 289 Change Log for the Draft: forgot to complete the change log between 290 the various revisions of the draft 292 9.7. -02 to -03 294 Abstract: expanded 296 Introduction: adjusted language of assumptions 298 Figures and Artwork: adjusted to indicate where to go in case 299 information for the images conflicts between different formats 301 General Page Layout: switched back to producing one basic paginated 302 format, with an expectation of instructions and/or a script to create 303 local, unpaginated copies for individual use. 305 9.8. -01 to -02 307 Introduction: added pointer to original page layout information 309 Character encoding: clarified language around encoding and use of 310 BOMs 312 General Page Format Layout: removed increased line width requirement; 313 added sections on Line Width, Line Spacing, and Hyphenation (pulled 314 from 2223-bis 316 10. References 318 10.1. Normative References 320 [I-D.flanagan-nonascii] 321 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 322 draft-flanagan-nonascii-06 (work in progress), November 323 2015. 325 [I-D.hoffman-xml2rfc] 326 Hoffman, P., "The 'XML2RFC' version 3 Vocabulary", draft- 327 hoffman-xml2rfc-23 (work in progress), September 2015. 329 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 330 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 331 2003, . 333 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 334 Headers, and Boilerplates", RFC 5741, 335 DOI 10.17487/RFC5741, December 2009, 336 . 338 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 339 Requirements and Future Development", RFC 6949, 340 DOI 10.17487/RFC6949, May 2013, 341 . 343 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 344 DOI 10.17487/RFC7322, September 2014, 345 . 347 10.2. Informative References 349 [INS2AUTH] 350 RFC Editor, "Instructions to Request for Comments (RFC) 351 Authors", August 2004, . 354 [UNICODE-GLOSSARY] 355 The Unicode Consortium, "Glossary of Unicode Terms", 2014, 356 . 358 [WIDOWS] Wikipedia, "Widows and orphans", October 2014, 359 . 361 [XML-ANNOUNCE] 362 Flanagan, H., "Subject: Direction of the RFC Format 363 Development effort", May 2013, . 366 Author's Address 368 Heather Flanagan 369 RFC Editor 371 Email: rse@rfc-editor.org 372 URI: http://orcid.org/0000-0002-2647-2220