idnits 2.17.1 draft-flanagan-rfc-framework-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 : ---------------------------------------------------------------------------- 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 (December 9, 2015) is 3060 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 December 9, 2015 5 Expires: June 11, 2016 7 RFC Format Framework 8 draft-flanagan-rfc-framework-08 10 Abstract 12 The canonical format for the RFC Series has been plain-text, ASCII- 13 encoded for several decades. After extensive community discussion 14 and debate, the RFC Editor will be transitioning to XML as the 15 canonical format, with different publication formats rendered from 16 that base document. These changes are intended to increase the 17 usability of the RFC Series by offering documents that match the 18 needs of a wider variety of stakeholders. With these changes, 19 however, comes an increase in complexity for authors, consumers, and 20 the publisher of RFCs. This document serves as the framework that 21 describes the problems being solved and summarizes the many documents 22 that capture the specific requirements for each aspect of the change 23 in format. 25 Editorial Note (To be removed by RFC Editor) 27 Discussion of this draft takes place on the rfc-interest mailing list 28 (rfc-interest@rfc-editor.org), which has its home page at 29 https://www.rfc-editor.org/mailman/listinfo/rfc-interest. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on June 11, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview of the Decision Making Process . . . . . . . . . . . 4 69 5. Key Changes . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Canonical Format Documents . . . . . . . . . . . . . . . . . 6 71 6.1. XML for RFCs . . . . . . . . . . . . . . . . . . . . . . 6 72 7. Publication Format Documents . . . . . . . . . . . . . . . . 7 73 7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 8 76 7.4. Potential Future Publication Formats . . . . . . . . . . 9 77 7.4.1. EPUB . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. Content and Page Layout . . . . . . . . . . . . . . . . . . . 9 81 9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 9 82 9.2. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.3. CSS Requirements . . . . . . . . . . . . . . . . . . . . 10 84 10. Transition Plan . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Statement of Work and RFP for Tool Development . . . . . 10 86 10.2. Testing and Transition . . . . . . . . . . . . . . . . . 10 87 10.3. Completion . . . . . . . . . . . . . . . . . . . . . . . 11 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 91 14. Appendix - Change log . . . . . . . . . . . . . . . . . . . . 12 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 93 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 94 15.2. Informative References . . . . . . . . . . . . . . . . . 15 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1. Introduction 99 [RFC6949], "RFC Series Format Requirements and Future Development," 100 discussed the need for additional features within RFCs such as non- 101 ASCII characters to respect author names, more advanced artwork than 102 ASCII art, and documents that could display properly on a wide 103 variety of devices. Based on the discussions with the IETF community 104 as well as other communities of interest, the RFC Series Editor 105 decided to explore a change to the format of the Series 106 [XML-ANNOUNCE]. This document serves as the framework that describes 107 the problems being solved and summarizes the documents created to- 108 date that capture the specific requirements for each aspect of the 109 change in format. 111 Key changes to the publication of RFCs are highlighted, and a 112 transition plan that will take the Series from a plain-text, ASCII- 113 only format to the new formats is described [RFC-INTEREST]. 115 This document is concerned with the production of RFCs, focusing on 116 the published formats. It does not address any changes to the 117 processes each stream uses to develop and review their submissions 118 (specifically, how Internet-Drafts will be developed). While I-Ds 119 have a similar set of issues and concerns, directly addressing those 120 issues for I-Ds will be discussed within each document stream. 122 The details described in this document are expected to change based 123 on experience gained in implementing the RFC production center's 124 toolset. Revised documents will be published capturing those changes 125 as the toolset is completed. Other implementers must not expect 126 those changes to remain backwards-compatible with the details 127 described this document. 129 2. Problem Statement 131 When the first RFCs were published 45 years ago, the tools to create 132 and read RFCs were limited. Distribution was in effect restricted to 133 individuals who had access to the network that became the Internet. 135 Today, there are nearly three billion people connected to the 136 Internet, and individuals from 45 countries or more regularly 137 attending IETF meetings over the last 5 years [ISTATS]. The Internet 138 is now global, and while the world has changed from when the first 139 RFCs were published, the Series remains critical to defining 140 protocols, standards, best practices, and more for this global 141 network that continues to grow. In order to make RFCs easily 142 viewable to the largest number of people possible, across a wide 143 array of devices, and to respect the diversity of authors and 144 reference materials, it is time to update the tightly prescribed 145 format of the RFC Series. 147 All changes to the format of the RFC Series must consider the 148 requirements of a wide set of communities, over an extended length of 149 time. For example, existing authors and implementers, lawyers that 150 argue Intellectual Property Rights (IPR) cases, educators, managers, 151 and policy-makers that need to know what to list in potential RFPs 152 for their organizations, all have preferences and requirements for 153 their specific needs. The immediate needs of today's communities 154 must be balanced with the needs for long-term archival storage. 156 3. Terminology 158 The following terminology is used as described in RFC 6949: 160 ASCII: Coded Character Set - 7-bit American Standard Code for 161 Information Interchange, ANSI X3.4-1986 163 Canonical format: the authorized, recognized, accepted, and 164 archived version of the document 166 Metadata: information associated with a document so as to provide, 167 for example, definitions of its structure, or of elements within 168 the document such as its topic or author 170 Publication format: display and distribution format as it may be 171 read or printed after the publication process has completed 173 Reflowable text: text that automatically wraps to the next line in 174 a document as the user moves the margins of the text, either by 175 resizing the window or changing the font size 177 Revisable format: the format that will provide the information for 178 conversion into a Publication format; it is used or created by the 179 RFC Editor 181 Submission format: the format submitted to the RFC Editor for 182 editorial revision and publication 184 4. Overview of the Decision Making Process 186 Requirements, use cases, concerns, and suggestions were collected 187 from the communities of interest at every stage of the RFC format 188 update project. Input was received through the rfc-interest mailing 189 list, as well as in several face-to-face sessions at IETF meetings. 190 Regular conversations were held with the IETF, IRTF, IAB, and IAOC 191 chairs, and the Independent Stream Editor, to discuss high-level 192 stream requirements. Updates regarding the status of the project 193 were provided to the IETF community during the IETF Technical Plenary 194 as well as Format BoFs or IAB sessions at IETF 84, IETF 85, IETF 88, 195 IETF 89, and IETF 90 [IETF84] [IETF85] [IETF88] [IETF89] [IETF90]. 197 The first document published, RFC 6949, provided the first solid 198 documentation on what the requirements were for the Series and in 199 effect was the output from the first year of discussion on the topic 200 of RFC format. That RFC, as with all of the RFCs that informed the 201 format update work, was published as an IAB stream document, thus 202 following the process described in RFC 4845, "Process for Publication 203 of IAB RFCs" [RFC4845]. 205 After the high-level requirements were published, the RFC Series 206 Editor (RSE) brought together an RFC Format Design Team to start 207 working out the necessary details to develop the code needed to 208 create new and changed formats. While the bi-weekly calls for this 209 team were limited to Design Team members, review of the drafts 210 produced by this team were done publicly through requests for 211 feedback on the rfc-interest mailing list. Several of the drafts 212 produced by the Design Team, including the XML v2 and v3 drafts and 213 the SVG profile drafts, were sent through an early GenART review 214 before starting the process to be accepted as an IAB stream draft 215 [GEN-ART]. 217 While the IETF community provided the majority of input on the 218 process, additional outreach opportunities were sought to gain input 219 from an even broader audience. Informal discussions were held with 220 participants at several International Association of Scientific, 221 Technical, and Medical Publisher events, and presentations made at 222 technical conferences such as the TERENA Networking Conference 2014 223 and NORDUnet 2014 [TNC2014] [NDN2014]. 225 In order to respond to concerns regarding responses to subpoenas and 226 to understand the requirements for lawyers, advice was requested from 227 the IETF Trust legal team regarding what format or formats would be 228 considered reasonable when responding to a subpoena request for an 229 RFC. 231 Given that several other standards development organizations (SDOs) 232 do not offer plain-text documents, and in fact may offer more than 233 one format for their standards, informal input was sought from them 234 regarding their experience with supporting one or more non-plain-text 235 formats for their standards. 237 Finally, the entire process was reviewed regularly with the RFC 238 Series Oversight Committee and regular updates provided to the IAB 239 and IESG [RSOC]. 241 Where consensus was not reached during the process, the RSE made any 242 necessary final decisions, as per the guidance in RFC 6635, "RFC 243 Editor Model (Version 2)" [RFC6635]. 245 5. Key Changes 247 At the highest level, the changes being made to the RFC Format 248 involve breaking away from a pure-ASCII plain text and moving to a 249 canonical format that includes all the information required for 250 rendering a document into a wide variety of publication formats. The 251 RFC Editor will become responsible for more than just the plain-text 252 file and the PDF-from-text format created at time of publication; 253 they will be creating several different formats in order to meet the 254 diverse requirements of the community. 256 The final XML file produced by the RFC Editor will be considered the 257 canonical format for RFCs; it is the lowest common denominator that 258 holds all the information intended for an RFC. PDF/A-3 will be the 259 publication format offered in response to subpoenas for RFCs 260 published through this new process, and will be developed with an eye 261 towards long-term archival storage. HTML will be the focus of 262 providing the most flexible set of features for an RFC, including 263 JavaScript to provide pointers to errata and other metadata. Plain- 264 text will continue to be offered in order to support existing tool 265 chains where practicable and the individuals who prefer to read RFCs 266 in this format. 268 6. Canonical Format Documents 270 6.1. XML for RFCs 272 Key points regarding the XML format: 274 o The canonical format for RFCs is XML using the XML2RFC v3 275 vocabulary [I-D.hoffman-xml2rfc]. This file must contain all 276 information necessary to render a variety of formats; any question 277 about what was intended in the publication will be answered from 278 this format. 280 o Authors may submit drafts in XML2RFC v2 vocabulary, but the final 281 publication will convert that to XML2RFC v3 vocabulary. 283 o SVG is supported and will be embedded in the final XML file. 285 o There will be automatically generated identifiers for sections, 286 paragraphs, figures, and tables in the final XML file. 288 o The XML file will not contain any v3 vocabulary elements or 289 attributes that have been marked deprecated. 291 o A Document Type Definition (DTD) will no longer be used. The 292 grammar will be defined using RelaxNG. 294 o The final XML file will contain, verbatim, the appropriate 295 boilerplate specified by RFC 5741. 297 o The final XML will be self-contained. For instance, all features 298 that reference externally-defined input will be expanded. This 299 includes all uses of xinclude, src attributes (such as in 300 or elements), include-like processing 301 instructions, and externally defined entities. 303 o The final XML will not contain comments or processing 304 instructions. 306 o The final XML will not contain src attributes for or 307 elements. 309 [I-D.iab-xml2rfcv2] Describes the xml2rfc v2 vocabulary. While in 310 wide use today, this vocabulary had not been formally documented. In 311 order to understand what needed to change in the vocabulary to allow 312 for a more simple experience and additional features for authors, the 313 current vocabulary needed to be fully described. This document, when 314 published, will be obsoleted by the RFC published from draft-hoffman- 315 xml2rfc. 317 [I-D.hoffman-xml2rfc] Describes the xml2rfc v3 vocabulary. The 318 design goals in this vocabulary were to make the vocabulary more 319 intuitive for authors, and to expand the features to support the 320 changes being made in the publication process. This draft, when 321 published, will obsolete the RFC published from draft-iab-xml2rfcv2. 323 7. Publication Format Documents 325 7.1. HTML 327 [I-D.hildebrand-html-rfc] - Describes the semantic HTML that will be 328 produced by the RFC Editor from the xml2rfc v3 files. 330 Key points regarding the HTML output: 332 o The HTML will not be derived from the plain-text publication 333 format. 335 o The body of the document will use a subset of HTML. The documents 336 will include CSS for default visual presentation; it can be 337 overwritten by a local CSS file. 339 o SVG is supported and will be included in the HTML file. 341 o Text will be reflowable. 343 o JavaScript will be supported only as an additional option for 344 presentation of specific publication formats to provide up-to-date 345 links to post-publication metadata, such as errata or obsoletion. 346 Documents will be complete and readable when JavaScript is 347 disabled. 349 7.2. PDF 351 [I-D.hansen-rfc-use-of-pdf] - Describes the tags and profiles that 352 will be used to create the new PDF format, including both the 353 internal structure and the visible layout of the file. A review of 354 the different versions of PDF is offered, with a recommendation of 355 what PDF standard should apply to RFCs. 357 Key points regarding the PDF output: 359 o The PDF file will not be derived from the plain-text publication 360 format. 362 o The PDF publication format will conform to the PDF/A-3 standard 363 and will embed the canonical XML source. 365 o The PDF will look more like the HTML publication format than the 366 plain-text publication format. 368 o The PDF will include a rich set of tags and metadata within the 369 document 371 o SVG is supported and will be included in the PDF file. 373 7.3. Plain Text 375 [I-D.flanagan-plaintext] - Describes the details of the plain text 376 format, focusing in particular on what is changing from the existing 377 plain-text output. 379 Key points regarding the plain-text output: 381 o The plain-text document will no longer be the canonical version of 382 an RFC. 384 o The plain-text format will be UTF-8 encoded; non-ASCII characters 385 will be allowed. 387 o A Byte Order Mark (BOM) will be added at the start of each file. 389 o Widow and orphan control for the plain-text publication format 390 will not have priority for the developers creating the rendering 391 code [TYPOGRAPHY]. 393 o Authors may choose to have pointers to line art in other 394 publication formats in place of ASCII art in the .txt file. 396 o A paginated plain-text file will be created that includes a form 397 feed instruction every 58 lines (at most), including blank lines. 398 Instructions or a s cript will be made available by and for the 399 community to strip out pagination as per individual preference. 401 o Running headers and footers will not be used. 403 7.4. Potential Future Publication Formats 405 7.4.1. EPUB 407 This format is intended for use by ebook readers and will be 408 available for RFCs after the requirements have been defined. No 409 draft is currently available. 411 8. Figures and Artwork 413 8.1. SVG 415 [I-D.brownlee-svg-rfc] Describes the profile for SVG line art. SVG 416 is an XML-based vocabulary for creating line drawings; SVG 417 information will be embedded within the canonical XML at time of 418 publication. 420 9. Content and Page Layout 422 9.1. Non-ASCII Characters 424 There are security and readability implications to moving outside the 425 ASCII range of characters. [I-D.flanagan-nonascii] focuses on 426 exactly where and how non-ASCII characters may be used in an RFC, 427 with an eye towards keeping the documents as secure and readable as 428 possible given the information that needs to be expressed. 430 9.2. Style Guide 432 The RFC Style Guide [RFC7322] was revised to remove as much page 433 formatting information as possible, focusing instead on grammar, 434 structure, and content of RFCs. Some of the changes recommended, 435 however, informed the XML v3 vocabulary. 437 9.3. CSS Requirements 439 A Cascading Style Sheet (CSS) is required to allow the HTML format to 440 be accessible and flexible across a variety of devices. Requirements 441 for the CSS that will be included with the HTML output are captured 442 in [I-D.flanagan-rfc-css]. 444 10. Transition Plan 446 10.1. Statement of Work and RFP for Tool Development 448 Existing tools for the creation of RFCs will need to be updated, and 449 new tools created, to implement the updated format. As the 450 requirements gathering effort, described in the various documents 451 described earlier int this draft, finishes the bulk of the work, the 452 Tools Development Team of the IETF will work with the RSE to develop 453 Statements of Work (SoWs). Those SoWs will first be reviewed within 454 the Tools Development Team, the Tools Management Committee, and go 455 out for a public comment period. After public review, the SoWs will 456 be attached to a Request for Proposal (RFP) and posted as per the 457 IASA bid process [IASA-RFP]. 459 Once bids have been received, reviewed, and awarded, coding will 460 begin. 462 10.2. Testing and Transition 464 During the I-D review and approval process, authors and stream- 465 approving bodies will select drafts to run through the proposed new 466 publication process. While the final RFCs published during this time 467 will continue as plain-text and immutable once published, the 468 feedback process is necessary to bootstrap initial testing. These 469 early tests will target finding issues with the proposed xml2rfc v3 470 vocabulary that result in poorly formed publication formats as well 471 as issues that prevent proper review of submitted drafts. 473 Feedback will result in regular iteration of the basic code and XML 474 vocabulary. In order to limit the amount of time the RFC Production 475 Center (RPC) spends on testing and QA, note that their priority is to 476 edit and publish documents, community assistance will be necessary to 477 help move this stage along. A mailing list and experimental source 478 directory on the RFC Editor website will be created for community 479 members willing to assist in the detailed review of the XML and 480 publication formats. Editorial checks of the publication formats by 481 the community are out of scope; the focus will be the QA of each 482 available output, checking for inconsistencies across formats. 484 The purpose of testing phase is to work with the community to 485 identify and fix bugs in the process and the code, before producing 486 canonical, immutable XML, and to collect additional feedback on the 487 usability of the new publication formats. 489 Success will be measured by the closure of all bugs which had been 490 identified by the RPC and the Tools Development team as fatal and 491 consensus on the readiness of the XML vocabulary and final XML files 492 for publication. The actual rendering engine can go through further 493 review and iteration, as the publication formats may be republished 494 as needed. 496 Authors are not required to submit their approved drafts in an XML 497 format; plain-text will also remain an option for the foreseeable 498 future. However, documents submitted as plain-text cannot include 499 such features as SVG artwork. 501 A known risk at this point of the transition is the difficulty in 502 quantifying the resources required from the RPC. This phase will 503 require more work on the part of the RPC to support both old and new 504 publication processes for at least six months. There is potential 505 for confusion as consumers of RFCs find some documents published at 506 this time with a full set of outputs, while other documents only have 507 plain text. There may be a delay in publication as new bugs are 508 found that must be fixed before the files can be converted into the 509 canonical format and associated publication formats. 511 Final success of the transition will be measured by the closure of 512 all bugs which had been identified by the RPC and the Tools 513 Development team as major or critical. There must also be rough 514 consensus from the community regarding the utility of the new 515 formats. 517 10.3. Completion 519 Authors may submit XML (preferred) or plain text. The XML drafts 520 submitted for publication will be converted to canonical XML format 521 and published with all available publication formats. All authors 522 will be expected to review the XML and the publication formats prior 523 to publication. Further process detail still under discussion. 525 Success for this phase will be measured by a solid understanding by 526 the RSE and the IAOC of the necessary costs and resources required 527 for long-term support of the new format model. 529 11. IANA Considerations 531 This document has no actions for IANA. 533 12. Security Considerations 535 Changing the format for RFCs involves modifying a great number of 536 components to publication. Understanding those changes and the 537 implications for the entire tool chain is critical so as to avoid 538 unintended bugs that would allow unintended changes to text. 539 Unintended changes to text could in turn corrupt a standard, practice 540 or critical piece of information about a protocol. 542 13. Acknowledgements 544 With many thanks to the RFC Format Design Team for their efforts in 545 making this transition successful: Nevil Brownlee (ISE), Tony Hansen, 546 Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, 547 Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler. 549 14. Appendix - Change log 551 To be removed by RFC Editor 553 draft-flanagan-rfc-framework-08 555 o Fixed empty section on CSS requirements 557 draft-flanagan-rfc-framework-07 559 o Brought old pagination text in alignment with requirements set out 560 in draft-flanagan-plaintext 562 draft-flanagan-rfc-framework-06 564 o Minor wording cleanup; addition of pointer to discussion re: 565 transition plans 567 draft-flanagan-rfc-framework-05 569 o Introduction: added text re: backwards compatibility 571 draft-flanagan-rfc-framework-04 572 Minor wording cleanup 574 draft-flanagan-rfc-framework-03 576 o XML for RFCs: additional details on changes added 578 o Fixed references 580 draft-flanagan-rfc-framework-02 582 o HTML: Fixed the statement on semantic HTML to capture intended 583 balance between CSS and HTML. 585 o Transition: Major changes to overall plan, emphasizing a more 586 iterative process for tool development; also removed statement 587 that I-Ds submitted as plain-text would only be published as 588 plain-text. The final process for publication and review has been 589 marked as under discussion. 591 draft-flanagan-rfc-framework-01 593 o Problem Statement: Added educators and managers to the list of 594 communities impacted by the format of the RFC Series. 596 o Terminology: Removed comment about RFC 2119. 598 o Overview of the Decision Making Process: Added a point about 599 conversation with the IETF, IRTF, IAB, and IAOC chairs, and the 600 ISE. Indicated that the RSE brought together the RFC Format 601 Design Team. Added a proper citation tag for the NORDUnet 2014 602 conference. 604 o Key Changes: Removed "canonical" from description of the plain- 605 text file. 607 o Document Summary: Removed "Section 6. Document Summary" and moved 608 key points for the different formats in the "Canonical Format 609 Documents" and "Publication Format Documents" sections. 611 o XML for RFCs: Reworded bullet points to offer complete sentences. 612 Added a statement regarding the DTD. Changed mention of "v2 613 vocabulary" and "v3 vocabulary: to XML2RFC v2/v3 vocabulary. 615 o HTML: Reworded bullet points to offer complete sentences. Added 616 "complete" to statement about JavaScript. 618 o PDF: Reworded bullet points to offer complete sentences. 620 o Plain Text: Reworded bullet points to offer complete sentences. 621 Added reference for "widow and orphan control." 623 o Transition Plan: Added a "Tool Development Phase" to the 624 Transition Plan. 626 o Transition Phase: Emphasized the possibility of dropping back to 627 publishing plain text documents if bugs are found that prevent 628 timely creation of RFCs. 630 o Completion: Revised the expectation to indicate the RPC may 631 perform the text to XML conversion for the authors. Added the 632 statement that all drafts submitted with an XML file will be 633 published as a canonical XML and all available publication 634 formats. 636 15. References 638 15.1. Normative References 640 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 641 Requirements and Future Development", RFC 6949, 642 DOI 10.17487/RFC6949, May 2013, 643 . 645 [I-D.hoffman-xml2rfc] 646 Hoffman, P., "The 'XML2RFC' version 3 Vocabulary", draft- 647 hoffman-xml2rfc-23 (work in progress), September 2015. 649 [I-D.iab-xml2rfcv2] 650 Reschke, J., "The 'XML2RFC' version 2 Vocabulary", draft- 651 iab-xml2rfcv2-02 (work in progress), September 2015. 653 [I-D.brownlee-svg-rfc] 654 Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft- 655 brownlee-svg-rfc-13 (work in progress), October 2015. 657 [I-D.hildebrand-html-rfc] 658 Hildebrand, J. and P. Hoffman, "HyperText Markup Language 659 Request For Comments Format", draft-hildebrand-html-rfc-10 660 (work in progress), August 2015. 662 [I-D.hansen-rfc-use-of-pdf] 663 Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC 664 Series Output Document Format", draft-hansen-rfc-use-of- 665 pdf-08 (work in progress), October 2015. 667 [I-D.flanagan-plaintext] 668 Flanagan, H., "Requirements for Plain-Text RFCs", draft- 669 flanagan-plaintext-09 (work in progress), November 2015. 671 [I-D.flanagan-nonascii] 672 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 673 draft-flanagan-nonascii-06 (work in progress), November 674 2015. 676 [I-D.flanagan-rfc-css] 677 Flanagan, H., "CSS Requirements for RFCs", draft-flanagan- 678 rfc-css-04 (work in progress), September 2015. 680 15.2. Informative References 682 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 683 for Publication of IAB RFCs", RFC 4845, 684 DOI 10.17487/RFC4845, July 2007, 685 . 687 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 688 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 689 2012, . 691 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 692 DOI 10.17487/RFC7322, September 2014, 693 . 695 [GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d., 696 . 698 [IASA-RFP] 699 IETF Administrative Support Activity, "RFPs and RFIs", 700 n.d., . 702 [IETF84] Flanagan, H., "IETF 84 Proceedings: RFC Format (rfcform)", 703 n.d., . 705 [IETF85] Flanagan, H., "IETF 85 Proceedings: RFC Format (rfcform)", 706 n.d., . 708 [IETF88] Flanagan, H., "IETF 88 Proceedings: RFC Format (rfcform)", 709 n.d., . 711 [IETF89] Flanagan, H., "IETF 89 Proceedings: RFC Format (rfcform)", 712 n.d., . 714 [IETF90] Flanagan, H., "IETF 90 Proceedings: RFC Format (rfcform)", 715 n.d., . 717 [ISTATS] "Internet Live Stats", n.d., 718 . 720 [NDN2014] "28th NORDUnet Conference 2014", 2014, 721 . 724 [RFC-INTEREST] 725 RFC Editor, "rfc-interest -- A list for discussion of the 726 RFC series and RFC Editor functions.", n.d., 727 . 730 [RSOC] IAB, "RFC Editor Program: The RSOC", n.d., 731 . 734 [TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 735 n.d., . 737 [TYPOGRAPHY] 738 Butterick, M., "Butterick's Practical Typography", n.d., 739 . 742 [XML-ANNOUNCE] 743 "Subject: [rfc-i] Direction of the RFC Format Development 744 effort", n.d., . 747 Author's Address 749 Heather Flanagan 750 RFC Editor 752 Email: rse@rfc-editor.org 753 URI: http://orcid.org/0000-0002-2647-2220