idnits 2.17.1 draft-iab-rfc-framework-04.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 (February 5, 2016) is 3002 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-iab-xml2rfc-02 == Outdated reference: A later version (-02) exists of draft-iab-svg-rfc-01 == Outdated reference: A later version (-03) exists of draft-iab-html-rfc-01 == Outdated reference: A later version (-02) exists of draft-iab-rfc-use-of-pdf-01 == Outdated reference: A later version (-03) exists of draft-iab-rfc-plaintext-01 == Outdated reference: A later version (-02) exists of draft-iab-rfc-nonascii-00 == 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: 0 errors (**), 0 flaws (~~), 8 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 February 5, 2016 5 Expires: August 8, 2016 7 RFC Format Framework 8 draft-iab-rfc-framework-04 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 August 8, 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-03 to -04 . . . . . . . . . . . 12 93 14.2. draft-iab-rfc-framework-02 to -03 . . . . . . . . . . . 13 94 14.3. draft-iab-rfc-framework-01 to -02 . . . . . . . . . . . 13 95 14.4. 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 102 1. Introduction 104 [RFC6949], "RFC Series Format Requirements and Future Development," 105 discussed the need for additional features within RFCs such as non- 106 ASCII characters to respect author names, more advanced artwork than 107 ASCII art, and documents that could display properly on a wide 108 variety of devices. Based on the discussions with the IETF community 109 as well as other communities of interest, the RFC Series Editor 110 decided to explore a change to the format of the Series 111 [XML-ANNOUNCE]. This document serves as the framework that describes 112 the problems being solved and summarizes the documents created to- 113 date that capture the specific requirements for each aspect of the 114 change in format. 116 Key changes to the publication of RFCs are highlighted, and a 117 transition plan that will take the Series from a plain-text, ASCII- 118 only format to the new formats is described on the rfc-interest 119 mailing list [RFC-INTEREST]. 121 This document is concerned with the production of RFCs, focusing on 122 the published formats. It does not address any changes to the 123 processes each stream uses to develop and review their submissions 124 (specifically, how Internet-Drafts will be developed). While I-Ds 125 have a similar set of issues and concerns, directly addressing those 126 issues for I-Ds will be discussed within each document stream. 128 The details described in this document are expected to change based 129 on experience gained in implementing the RFC production center's 130 toolset. Revised documents will be published capturing those changes 131 as the toolset is completed. Other implementers must not expect 132 those changes to remain backwards-compatible with the details 133 described this document. 135 2. Problem Statement 137 There are nearly three billion people connected to the Internet, and 138 individuals from 45 countries or more regularly attending IETF 139 meetings over the last 5 years [ISTATS]. The Internet is now global, 140 and while the world has changed from when the first RFCs were 141 published, the Series remains critical to defining protocols, 142 standards, best practices, and more for this global network that 143 continues to grow. In order to make RFCs easily viewable to the 144 largest number of people possible, across a wide array of devices, 145 and to respect the diversity of authors and reference materials, it 146 is time to 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 [I-D.iab-xml2rfcv2]. Part of this discussion 215 included a decision to stop using an XML document type definition 216 (DTD) in favor of a Regular Language for XML Next General (Relax NG) 217 model using a defined vocabulary. While the bi-weekly calls for this 218 team were limited to Design Team members, review of the decisions as 219 documented in the drafts produced by this team were done publicly 220 through requests for feedback on the rfc-interest mailing list. 221 Several of the drafts produced by the Design Team, including the 222 xml2rfc v2 and v3 drafts and the SVG profile drafts, were sent 223 through an early GenART review before starting the process to be 224 accepted as an IAB 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 [I-D.iab-xml2rfcv2] Describes the xml2rfc v2 vocabulary. While in 321 wide use today, this vocabulary had not been formally documented. In 322 order to understand what needed to change in the vocabulary to allow 323 for a 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 published from draft-iab-xml2rfcv2. 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, note that their priority is to 484 edit and publish documents, community assistance will be necessary to 485 help move this stage along. A mailing list and experimental source 486 directory on the RFC Editor website will be created for community 487 members willing to assist in the detailed review of the XML and 488 publication formats. Editorial checks of the publication formats by 489 the community are out of scope; the focus will be the QA of each 490 available output, checking for inconsistencies across formats. 492 The purpose of testing phase is to work with the community to 493 identify and fix bugs in the process and the code, before producing 494 canonical, immutable XML, and to collect additional feedback on the 495 usability of the new publication formats. 497 Success will be measured by the closure of all bugs which had been 498 identified by the RPC and the Tools Development team as fatal and 499 consensus on the readiness of the XML vocabulary and final XML files 500 for publication. The actual rendering engine can go through further 501 review and iteration, as the publication formats may be republished 502 as needed. 504 Authors are not required to submit their approved drafts in an XML 505 format, though they are strongly encouraged to do so; plain-text will 506 also remain an option for the foreseeable future. However, documents 507 submitted as plain-text cannot include such features as SVG artwork. 508 The RPC will generate an XML file if necessary for basic processing 509 and subsequent rendering into the approved output formats. 511 A known risk at this point of the transition is the difficulty in 512 quantifying the resources required from the RPC. This phase will 513 require more work on the part of the RPC to support both old and new 514 publication processes for at least six months. There is potential 515 for confusion as consumers of RFCs find some documents published at 516 this time with a full set of outputs, while other documents only have 517 plain text. There may be a delay in publication as new bugs are 518 found that must be fixed before the files can be converted into the 519 canonical format and associated publication formats. 521 Final success of the transition will be measured by the closure of 522 all bugs which had been identified by the RPC and the Tools 523 Development team as major or critical. There must also be rough 524 consensus from the community regarding the utility of the new 525 formats. 527 10.3. Completion 529 Authors may submit XML (preferred) or plain text. The XML drafts 530 submitted for publication will be converted to canonical XML format 531 and published with all available publication formats. All authors 532 will be expected to review the final documents as consistent with the 533 evolving procedures for reviewing drafts. 535 Success for this phase will be measured by a solid understanding by 536 the RSE and the IAOC of the necessary costs and resources required 537 for long-term support of the new format model. 539 11. IANA Considerations 541 This document has no actions for IANA. 543 12. Security Considerations 545 Changing the format for RFCs involves modifying a great number of 546 components to publication. Understanding those changes and the 547 implications for the entire tool chain is critical so as to avoid 548 unintended bugs that would allow unintended changes to text. 549 Unintended changes to text could in turn corrupt a standard, practice 550 or critical piece of information about a protocol. 552 13. Acknowledgements 554 With many thanks to the RFC Format Design Team for their efforts in 555 making this transition successful: Nevil Brownlee (ISE), Tony Hansen, 556 Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, 557 Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler. 559 14. Appendix - Change log 561 To be removed by RFC Editor 563 14.1. draft-iab-rfc-framework-03 to -04 565 Introduction: editorial changes 567 Clarified that submitted plain text will be converted to XML by the 568 RPC; the XML will be used to render all output formats. 570 14.2. draft-iab-rfc-framework-02 to -03 572 HTML output: clarified expectations around use of JavaScript. 574 14.3. draft-iab-rfc-framework-01 to -02 576 Introduction: Removed some unnecessary history. 578 14.4. draft-iab-rfc-framework-00 to -01 580 Decision Making Process: noted taht other XML schemas and 581 vocabularies were considered by the design team 583 XML for RFCs: "boilerplate at time of publication" 585 HTML: clarified that JavaScript should not impact readability of the 586 document as it looked at time of publication 588 15. References 590 15.1. Normative References 592 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 593 Requirements and Future Development", RFC 6949, 594 DOI 10.17487/RFC6949, May 2013, 595 . 597 [I-D.iab-xml2rfc] 598 Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft- 599 iab-xml2rfc-02 (work in progress), January 2016. 601 [I-D.iab-xml2rfcv2] 602 Reschke, J., "The 'XML2RFC' version 2 Vocabulary", draft- 603 iab-xml2rfcv2-02 (work in progress), September 2015. 605 [I-D.iab-svg-rfc] 606 Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft- 607 iab-svg-rfc-01 (work in progress), January 2016. 609 [I-D.iab-html-rfc] 610 Hildebrand, J. and P. Hoffman, "HyperText Markup Language 611 Request For Comments Format", draft-iab-html-rfc-01 (work 612 in progress), January 2016. 614 [I-D.iab-rfc-use-of-pdf] 615 Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC 616 Series Output Document Format", draft-iab-rfc-use-of- 617 pdf-01 (work in progress), January 2016. 619 [I-D.iab-rfc-plaintext] 620 Flanagan, H., "Requirements for Plain-Text RFCs", draft- 621 iab-rfc-plaintext-01 (work in progress), January 2016. 623 [I-D.iab-rfc-nonascii] 624 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 625 draft-iab-rfc-nonascii-00 (work in progress), January 626 2016. 628 [I-D.iab-rfc-css] 629 Flanagan, H., "CSS Requirements for RFCs", draft-iab-rfc- 630 css-00 (work in progress), January 2016. 632 15.2. Informative References 634 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 635 for Publication of IAB RFCs", RFC 4845, 636 DOI 10.17487/RFC4845, July 2007, 637 . 639 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 640 Headers, and Boilerplates", RFC 5741, 641 DOI 10.17487/RFC5741, December 2009, 642 . 644 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 645 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 646 2012, . 648 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 649 DOI 10.17487/RFC7322, September 2014, 650 . 652 [GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d., 653 . 655 [IASA-RFP] 656 IETF Administrative Support Activity, "RFPs and RFIs", 657 n.d., . 659 [IETF84] Flanagan, H., "IETF 84 Proceedings: RFC Format (rfcform)", 660 n.d., . 662 [IETF85] Flanagan, H., "IETF 85 Proceedings: RFC Format (rfcform)", 663 n.d., . 665 [IETF88] Flanagan, H., "IETF 88 Proceedings: RFC Format (rfcform)", 666 n.d., . 668 [IETF89] Flanagan, H., "IETF 89 Proceedings: RFC Format (rfcform)", 669 n.d., . 671 [IETF90] Flanagan, H., "IETF 90 Proceedings: RFC Format (rfcform)", 672 n.d., . 674 [ISTATS] "Internet Live Stats", n.d., 675 . 677 [NDN2014] "28th NORDUnet Conference 2014", 2014, 678 . 681 [RFC-INTEREST] 682 RFC Editor, "rfc-interest -- A list for discussion of the 683 RFC series and RFC Editor functions.", n.d., 684 . 687 [RSOC] IAB, "RFC Editor Program: The RSOC", n.d., 688 . 691 [TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 692 n.d., . 694 [TYPOGRAPHY] 695 Butterick, M., "Butterick's Practical Typography", n.d., 696 . 699 [XML-ANNOUNCE] 700 "Subject: [rfc-i] Direction of the RFC Format Development 701 effort", n.d., . 704 Author's Address 706 Heather Flanagan 707 RFC Editor 709 Email: rse@rfc-editor.org 710 URI: http://orcid.org/0000-0002-2647-2220