idnits 2.17.1 draft-iab-rfc-framework-05.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 (June 21, 2016) is 2864 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7749 (Obsoleted by RFC 7991) == Outdated reference: A later version (-04) exists of draft-iab-xml2rfc-03 == Outdated reference: A later version (-03) exists of draft-iab-html-rfc-02 == Outdated reference: A later version (-01) exists of draft-iab-rfc-css-00 -- Obsolete informational reference (is this intentional?): RFC 5741 (Obsoleted by RFC 7841) -- Obsolete informational reference (is this intentional?): RFC 6635 (Obsoleted by RFC 8728) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board H. Flanagan 3 Internet-Draft RFC Editor 4 Intended status: Informational June 21, 2016 5 Expires: December 23, 2016 7 RFC Format Framework 8 draft-iab-rfc-framework-05 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 using the XML2RFC version 3 vocabulary. Different 16 publication formats will be rendered from that base document. These 17 changes are intended to increase the usability of the RFC Series by 18 offering documents that match the needs of a wider variety of 19 stakeholders. With these changes, however, comes an increase in 20 complexity for authors, consumers, and the publisher of RFCs. This 21 document serves as the framework that describes the problems being 22 solved and summarizes the many documents that capture the specific 23 requirements for each aspect of the change 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 December 23, 2016. 48 Copyright Notice 50 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . 8 73 7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . 10 81 9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 12 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 91 14. Appendix - Change log . . . . . . . . . . . . . . . . . . . . 12 92 14.1. draft-iab-rfc-framework-04 to -05 . . . . . . . . . . . 13 93 14.2. draft-iab-rfc-framework-03 to -04 . . . . . . . . . . . 13 94 14.3. draft-iab-rfc-framework-02 to -03 . . . . . . . . . . . 13 95 14.4. draft-iab-rfc-framework-01 to -02 . . . . . . . . . . . 13 96 14.5. draft-iab-rfc-framework-00 to -01 . . . . . . . . . . . 13 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 99 15.2. Informative References . . . . . . . . . . . . . . . . . 14 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 "RFC Series Format Requirements and Future Development" discussed the 105 need for additional features within RFCs such as non-ASCII characters 106 to respect author names, more advanced artwork than ASCII art, and 107 documents that could display properly on a wide variety of devices 108 [RFC6949]. Based on the discussions with the IETF community as well 109 as other communities of interest, the RFC Series Editor decided to 110 explore a change to the format of the Series [XML-ANNOUNCE]. This 111 document serves as the framework that describes the problems being 112 solved and summarizes the documents created to-date that capture the 113 specific requirements for each aspect of the change in format. 115 Key changes to the publication of RFCs are highlighted, and a 116 transition plan that will take the Series from a plain-text, ASCII- 117 only format to the new formats is described on the rfc-interest 118 mailing list [RFC-INTEREST]. 120 This document is concerned with the production of RFCs, focusing on 121 the published formats. It does not address any changes to the 122 processes each stream uses to develop and review their submissions 123 (specifically, how Internet-Drafts will be developed). While I-Ds 124 have a similar set of issues and concerns, directly addressing those 125 issues for I-Ds will be discussed within each document stream. 127 The details described in this document are expected to change based 128 on experience gained in implementing the RFC Production Center's 129 toolset. Revised documents will be published capturing those changes 130 as the toolset is completed. Other implementers must not expect 131 those changes to remain backwards-compatible with the details 132 described this document. 134 2. Problem Statement 136 There are nearly three billion people connected to the Internet, and 137 individuals from 45 countries or more regularly attending IETF 138 meetings over the last five years [ISTATS]. The Internet is now 139 global, and while the world has changed from when the first RFCs were 140 published, the Series remains critical to defining protocols, 141 standards, best practices, and more for this global network that 142 continues to grow. In order to make RFCs easily viewable to the 143 largest number of people possible, across a wide array of devices, 144 and to respect the diversity of authors and reference materials while 145 still recognizing the archival aspects of the Series, it is time to 146 update the tightly prescribed format of the RFC Series. 148 All changes to the format of the RFC Series must consider the 149 requirements of a wide set of communities, over an extended length of 150 time. For example, existing authors and implementers, lawyers that 151 argue Intellectual Property Rights (IPR), educators, managers, and 152 policy-makers that need to know what to list in potential RFPs for 153 their organizations, all have preferences and requirements for their 154 specific needs. The immediate needs of today's communities must be 155 balanced with the needs for long-term archival storage. 157 3. Terminology 159 The following terminology is used as described in RFC 6949: 161 ASCII: Coded Character Set - 7-bit American Standard Code for 162 Information Interchange, ANSI X3.4-1986 164 Canonical format: the authorized, recognized, accepted, and 165 archived version of the document 167 Metadata: information associated with a document so as to provide, 168 for example, definitions of its structure, or of elements within 169 the document such as its topic or author 171 Publication format: display and distribution format as it may be 172 read or printed after the publication process has completed 174 Reflowable text: text that automatically wraps to the next line in 175 a document as the user moves the margins of the text, either by 176 resizing the window or changing the font size 178 Revisable format: the format that will provide the information for 179 conversion into a Publication format; it is used or created by the 180 RFC Editor 182 Submission format: the format submitted to the RFC Editor for 183 editorial revision and publication 185 4. Overview of the Decision Making Process 187 Requirements, use cases, concerns, and suggestions were collected 188 from the communities of interest at every stage of the RFC format 189 update project. Input was received through the rfc-interest mailing 190 list, as well as in several face-to-face sessions at IETF meetings. 191 Regular conversations were held with the IETF, IRTF, IAB, and IAOC 192 chairs, and the Independent Stream Editor, to discuss high-level 193 stream requirements. Updates regarding the status of the project 194 were provided to the IETF community during the IETF Technical Plenary 195 as well as Format BoFs or IAB sessions at IETF 84, IETF 85, IETF 88, 196 IETF 89, and IETF 90 [IETF84] [IETF85] [IETF88] [IETF89] [IETF90]. 198 The first document published, RFC 6949, provided the first solid 199 documentation on what the requirements were for the Series and in 200 effect was the output from the first year of discussion on the topic 201 of RFC format. That RFC, as with all of the RFCs that informed the 202 format update work, was published as an IAB stream document, thus 203 following the process described in RFC 4845, "Process for Publication 204 of IAB RFCs" [RFC4845]. 206 After the high-level requirements were published, the RFC Series 207 Editor (RSE) brought together an RFC Format Design Team to start 208 working out the necessary details to develop the code needed to 209 create new and changed formats. The design team discussed moving 210 away from the existing xml2rfc vocabulary, but with such a strong 211 existing support base within the community and no clear value with 212 other XML vocabularies or schemas, the decision was made to work with 213 the XML2RFC version 2 (xml2rfc v2) model and use it as the base for 214 the new format world [RFC7749]. Part of this discussion included a 215 decision to stop using an XML document type definition (DTD) in favor 216 of a Regular Language for XML Next General (Relax NG) model using a 217 defined vocabulary. While the bi-weekly calls for this team were 218 limited to Design Team members, review of the decisions as documented 219 in the drafts produced by this team were done publicly through 220 requests for feedback on the rfc-interest mailing list. Several of 221 the drafts produced by the Design Team, including the xml2rfc v2 and 222 v3 drafts and the SVG profile drafts, were sent through an early 223 GenART review before starting the process to be accepted as an IAB 224 stream draft [GEN-ART] [I-D.iab-xml2rfc]. 226 While the IETF community provided the majority of input on the 227 process, additional outreach opportunities were sought to gain input 228 from an even broader audience. Informal discussions were held with 229 participants at several International Association of Scientific, 230 Technical, and Medical Publisher events, and presentations made at 231 technical conferences such as the TERENA Networking Conference 2014 232 and NORDUnet 2014 [TNC2014] [NDN2014]. 234 In order to respond to concerns regarding responses to subpoenas and 235 to understand the requirements for lawyers, advice was requested from 236 the IETF Trust legal team regarding what format or formats would be 237 considered reasonable when responding to a subpoena request for an 238 RFC. 240 Given that several other standards development organizations (SDOs) 241 do not offer plain-text documents, and in fact may offer more than 242 one format for their standards, informal input was sought from them 243 regarding their experience with supporting one or more non-plain-text 244 formats for their standards. 246 Finally, the entire process was reviewed regularly with the RFC 247 Series Oversight Committee and regular updates provided to the IAB 248 and IESG [RSOC]. They have offered support and input throughout the 249 process. 251 Where consensus was not reached during the process, the RSE made any 252 necessary final decisions, as per the guidance in RFC 6635, "RFC 253 Editor Model (Version 2)" [RFC6635]. 255 5. Key Changes 257 At the highest level, the changes being made to the RFC Format 258 involve breaking away from a pure-ASCII plain text and moving to 259 canonical format that includes all the information required for 260 rendering a document into a wide variety of publication formats. The 261 RFC Editor will become responsible for more than just the plain-text 262 file and the PDF-from-text format created at time of publication; 263 they will be creating several different formats in order to meet the 264 diverse requirements of the community. 266 The final XML file produced by the RFC Editor will be considered the 267 canonical format for RFCs; it is the lowest common denominator that 268 holds all the information intended for an RFC. PDF/A-3 will be the 269 publication format offered in response to subpoenas for RFCs 270 published through this new process, and will be developed with an eye 271 towards long-term archival storage. HTML will be the focus of 272 providing the most flexible set of features for an RFC, including 273 JavaScript to provide pointers to errata and other metadata. Plain- 274 text will continue to be offered in order to support existing tool 275 chains where practicable and the individuals who prefer to read RFCs 276 in this format. 278 6. Canonical Format Documents 280 6.1. XML for RFCs 282 Key points regarding the XML format: 284 o The canonical format for RFCs is XML using the XML2RFC version 3 285 (xml2rfc v3) vocabulary. This file must contain all information 286 necessary to render a variety of formats; any question about what 287 was intended in the publication will be answered from this format. 289 o Authors may submit drafts in xml2rfc v2 vocabulary, but the final 290 publication will convert that to xml2rfc v3 vocabulary. 292 o SVG is supported and will be embedded in the final XML file. 294 o There will be automatically generated identifiers for sections, 295 paragraphs, figures, and tables in the final XML file. 297 o The XML file will not contain any xml2rfc v3 vocabulary elements 298 or attributes that have been marked deprecated. 300 o A Document Type Definition (DTD) will no longer be used. The 301 grammar will be defined using RelaxNG. 303 o The final XML file will contain, verbatim, the appropriate 304 boilerplate as applicable at time of publication specified by RFC 305 5741 or its successors [RFC5741]. 307 o The final XML will be self-contained with all the information 308 known at publication time. For instance, all features that 309 reference externally-defined input will be expanded. This 310 includes all uses of xinclude, src attributes (such as in 311 or elements), include-like processing 312 instructions, and externally defined entities. 314 o The final XML will not contain comments or processing 315 instructions. 317 o The final XML will not contain src attributes for or 318 elements. 320 [RFC7749] Describes the xml2rfc v2 vocabulary. While in wide use 321 today, this vocabulary had not been formally documented. In order to 322 understand what needed to change in the vocabulary to allow for a 323 more simple experience and additional features for authors, the 324 current vocabulary needed to be fully described. This document, when 325 published, will be obsoleted by the RFC published from draft-iab- 326 xml2rfc. 328 [I-D.iab-xml2rfc] Describes the xml2rfc v3 vocabulary. The design 329 goals in this vocabulary were to make the vocabulary more intuitive 330 for authors, and to expand the features to support the changes being 331 made in the publication process. This draft, when published, will 332 obsolete the RFC 7749. 334 7. Publication Format Documents 336 7.1. HTML 338 [I-D.iab-html-rfc] - Describes the semantic HTML that will be 339 produced by the RFC Editor from the xml2rfc v3 files. 341 Key points regarding the HTML output: 343 o The HTML will be rendered from the XML file; it will not be 344 derived from the plain-text publication format. 346 o The body of the document will use a subset of HTML. The documents 347 will include CSS for default visual presentation; it can be 348 overwritten by a local CSS file. 350 o SVG is supported and will be included in the HTML file. 352 o Text will be reflowable. 354 o JavaScript will be supported on a limited basis. It will not be 355 permitted to overwrite or change any text present in the rendered 356 html. It may, on a limited basis, add additional text that 357 provides post-publication metadata or pointers if warranted. All 358 such text will be clearly marked as additional. 360 7.2. PDF 362 [I-D.iab-rfc-use-of-pdf] - Describes the tags and profiles that will 363 be used to create the new PDF format, including both the internal 364 structure and the visible layout of the file. A review of the 365 different versions of PDF is offered, with a recommendation of what 366 PDF standard should apply to RFCs. 368 Key points regarding the PDF output: 370 o The PDF file will be rendered from the XML file; it will not be 371 derived from the plain-text publication format. 373 o The PDF publication format will conform to the PDF/A-3 standard 374 and will embed the canonical XML source. 376 o The PDF will look more like the HTML publication format than the 377 plain-text publication format. 379 o The PDF will include a rich set of tags and metadata within the 380 document 382 o SVG is supported and will be included in the PDF file. 384 7.3. Plain Text 386 [I-D.iab-rfc-plaintext] - Describes the details of the plain text 387 format, focusing in particular on what is changing from the existing 388 plain-text output. 390 Key points regarding the plain-text output: 392 o The plain-text document will no longer be the canonical version of 393 an RFC. 395 o The plain-text format will be UTF-8 encoded; non-ASCII characters 396 will be allowed. 398 o A Byte Order Mark (BOM) will be added at the start of each file. 400 o Widow and orphan control for the plain-text publication format 401 will not have priority for the developers creating the rendering 402 code [TYPOGRAPHY]. 404 o Authors may choose to have pointers to line art in other 405 publication formats in place of ASCII art in the .txt file. 407 o Both a paginated and an unpaginated plain-text file will be 408 created. 410 o Running headers and footers will not be used. 412 7.4. Potential Future Publication Formats 414 7.4.1. EPUB 416 This format is intended for use by ebook readers and will be 417 available for RFCs after the requirements have been defined. No 418 draft is currently available. 420 8. Figures and Artwork 422 8.1. SVG 424 [I-D.iab-svg-rfc] Describes the profile for SVG line art. SVG is an 425 XML-based vocabulary for creating line drawings; SVG information will 426 be embedded within the canonical XML at time of publication. 428 9. Content and Page Layout 430 9.1. Non-ASCII Characters 432 There are security and readability implications to moving outside the 433 ASCII range of characters. [I-D.iab-rfc-nonascii] focuses on exactly 434 where and how non-ASCII characters may be used in an RFC, with an eye 435 towards keeping the documents as secure and readable as possible 436 given the information that needs to be expressed. 438 9.2. Style Guide 440 The RFC Style Guide [RFC7322] was revised to remove as much page 441 formatting information as possible, focusing instead on grammar, 442 structure, and content of RFCs. Some of the changes recommended, 443 however, informed the XML v3 vocabulary. 445 9.3. CSS Requirements 447 [I-D.iab-rfc-css] describe how the CSS classes mentioned in the HTML 448 format draft, "HyperText Markup Language Request for Comments 449 Format", should be used to create an accessible and responsive design 450 for the HTML format. 452 10. Transition Plan 454 10.1. Statement of Work and RFP for Tool Development 456 Existing tools for the creation of RFCs will need to be updated, and 457 new tools created, to implement the updated format. As the 458 requirements gathering effort, described in the various documents 459 described earlier int this draft, finishes the bulk of the work, the 460 Tools Development Team of the IETF will work with the RSE to develop 461 Statements of Work (SoWs). Those SoWs will first be reviewed within 462 the Tools Development Team, the Tools Management Committee, and go 463 out for a public comment period. After public review, the SoWs will 464 be attached to a Request for Proposal (RFP) and posted as per the 465 IASA bid process [IASA-RFP]. 467 Once bids have been received, reviewed, and awarded, coding will 468 begin. 470 10.2. Testing and Transition 472 During the I-D review and approval process, authors and stream- 473 approving bodies will select drafts to run through the proposed new 474 publication process. While the final RFCs published during this time 475 will continue as plain-text and immutable once published, the 476 feedback process is necessary to bootstrap initial testing. These 477 early tests will target finding issues with the proposed xml2rfc v3 478 vocabulary that result in poorly formed publication formats as well 479 as issues that prevent proper review of submitted drafts. 481 Feedback will result in regular iteration of the basic code and XML 482 vocabulary. In order to limit the amount of time the RFC Production 483 Center (RPC) spends on testing and QA, their priority will be to edit 484 and publish documents; therefore, community assistance will be 485 necessary to help move this stage along. A mailing list and 486 experimental source directory on the RFC Editor website will be 487 created for community members willing to assist in the detailed 488 review of the XML and publication formats. Editorial checks of the 489 publication formats by the community are out of scope; the focus will 490 be the QA of each available output, checking for inconsistencies 491 across formats. 493 The purpose of testing phase is to work with the community to 494 identify and fix bugs in the process and the code, before producing 495 canonical, immutable XML, and to collect additional feedback on the 496 usability of the new publication formats. 498 Any modifications to the draft review process, up to and including 499 AUTH48, will happen with the community and the stream approving 500 bodies as we learn more about the features and outputs of the new 501 publication tools. Defining those processes is out of scope for this 502 document. 504 Success will be measured by the closure of all bugs which had been 505 identified by the RPC and the Tools Development team as fatal and 506 consensus on the readiness of the XML vocabulary and final XML files 507 for publication. The actual rendering engine can go through further 508 review and iteration, as the publication formats may be republished 509 as needed. 511 Authors are not required to submit their approved drafts in an XML 512 format, though they are strongly encouraged to do so; plain-text will 513 also remain an option for the foreseeable future. However, documents 514 submitted as plain-text cannot include such features as SVG artwork. 515 The RPC will generate an XML file if necessary for basic processing 516 and subsequent rendering into the approved output formats. 518 A known risk at this point of the transition is the difficulty in 519 quantifying the resources required from the RPC. This phase will 520 require more work on the part of the RPC to support both old and new 521 publication processes for at least six months. There is potential 522 for confusion as consumers of RFCs find some documents published at 523 this time with a full set of outputs, while other documents only have 524 plain text. There may be a delay in publication as new bugs are 525 found that must be fixed before the files can be converted into the 526 canonical format and associated publication formats. 528 Final success of the transition will be measured by the closure of 529 all bugs which had been identified by the RPC and the Tools 530 Development team as major or critical. There must also be rough 531 consensus from the community regarding the utility of the new 532 formats. 534 10.3. Completion 536 Authors may submit XML (preferred) or plain text. The XML drafts 537 submitted for publication will be converted to canonical XML format 538 and published with all available publication formats. All authors 539 will be expected to review the final documents as consistent with the 540 evolving procedures for reviewing drafts. 542 Success for this phase will be measured by a solid understanding by 543 the RSE and the IAOC of the necessary costs and resources required 544 for long-term support of the new format model. 546 11. IANA Considerations 548 This document has no actions for IANA. 550 12. Security Considerations 552 Changing the format for RFCs involves modifying a great number of 553 components to publication. Understanding those changes and the 554 implications for the entire tool chain is critical so as to avoid 555 unintended bugs that would allow unintended changes to text. 556 Unintended changes to text could in turn corrupt a standard, practice 557 or critical piece of information about a protocol. 559 13. Acknowledgements 561 With many thanks to the RFC Format Design Team for their efforts in 562 making this transition successful: Nevil Brownlee (ISE), Tony Hansen, 563 Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, 564 Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler. 566 14. Appendix - Change log 568 To be removed by RFC Editor 570 14.1. draft-iab-rfc-framework-04 to -05 572 Introduction: minor clarifications 574 Updated references 576 14.2. draft-iab-rfc-framework-03 to -04 578 Introduction: editorial changes 580 Clarified that submitted plain text will be converted to XML by the 581 RPC; the XML will be used to render all output formats. 583 14.3. draft-iab-rfc-framework-02 to -03 585 HTML output: clarified expectations around use of JavaScript. 587 14.4. draft-iab-rfc-framework-01 to -02 589 Introduction: Removed some unnecessary history. 591 14.5. draft-iab-rfc-framework-00 to -01 593 Decision Making Process: noted taht other XML schemas and 594 vocabularies were considered by the design team 596 XML for RFCs: "boilerplate at time of publication" 598 HTML: clarified that JavaScript should not impact readability of the 599 document as it looked at time of publication 601 15. References 603 15.1. Normative References 605 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 606 Requirements and Future Development", RFC 6949, 607 DOI 10.17487/RFC6949, May 2013, 608 . 610 [RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", 611 RFC 7749, DOI 10.17487/RFC7749, February 2016, 612 . 614 [I-D.iab-xml2rfc] 615 Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft- 616 iab-xml2rfc-03 (work in progress), February 2016. 618 [I-D.iab-svg-rfc] 619 Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft- 620 iab-svg-rfc-02 (work in progress), February 2016. 622 [I-D.iab-html-rfc] 623 Hildebrand, J. and P. Hoffman, "HyperText Markup Language 624 Request For Comments Format", draft-iab-html-rfc-02 (work 625 in progress), February 2016. 627 [I-D.iab-rfc-use-of-pdf] 628 Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC 629 Series Output Document Format", draft-iab-rfc-use-of- 630 pdf-02 (work in progress), May 2016. 632 [I-D.iab-rfc-plaintext] 633 Flanagan, H., "Requirements for Plain-Text RFCs", draft- 634 iab-rfc-plaintext-03 (work in progress), May 2016. 636 [I-D.iab-rfc-nonascii] 637 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 638 draft-iab-rfc-nonascii-02 (work in progress), April 2016. 640 [I-D.iab-rfc-css] 641 Flanagan, H., "CSS Requirements for RFCs", draft-iab-rfc- 642 css-00 (work in progress), January 2016. 644 15.2. Informative References 646 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 647 for Publication of IAB RFCs", RFC 4845, 648 DOI 10.17487/RFC4845, July 2007, 649 . 651 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 652 Headers, and Boilerplates", RFC 5741, 653 DOI 10.17487/RFC5741, December 2009, 654 . 656 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 657 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 658 2012, . 660 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 661 DOI 10.17487/RFC7322, September 2014, 662 . 664 [GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d., 665 . 667 [IASA-RFP] 668 IETF Administrative Support Activity, "RFPs and RFIs", 669 n.d., . 671 [IETF84] Flanagan, H., "IETF 84 Proceedings: RFC Format (rfcform)", 672 n.d., . 674 [IETF85] Flanagan, H., "IETF 85 Proceedings: RFC Format (rfcform)", 675 n.d., . 677 [IETF88] Flanagan, H., "IETF 88 Proceedings: RFC Format (rfcform)", 678 n.d., . 680 [IETF89] Flanagan, H., "IETF 89 Proceedings: RFC Format (rfcform)", 681 n.d., . 683 [IETF90] Flanagan, H., "IETF 90 Proceedings: RFC Format (rfcform)", 684 n.d., . 686 [ISTATS] "Internet Live Stats", n.d., 687 . 689 [NDN2014] "28th NORDUnet Conference 2014", 2014, 690 . 693 [RFC-INTEREST] 694 RFC Editor, "rfc-interest -- A list for discussion of the 695 RFC series and RFC Editor functions.", n.d., 696 . 699 [RSOC] IAB, "RFC Editor Program: The RSOC", n.d., 700 . 703 [TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 704 n.d., . 706 [TYPOGRAPHY] 707 Butterick, M., "Butterick's Practical Typography", n.d., 708 . 711 [XML-ANNOUNCE] 712 "Subject: [rfc-i] Direction of the RFC Format Development 713 effort", n.d., . 716 Author's Address 718 Heather Flanagan 719 RFC Editor 721 Email: rse@rfc-editor.org 722 URI: http://orcid.org/0000-0002-2647-2220