idnits 2.17.1 draft-iab-rfc-framework-01.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 (January 20, 2016) is 2991 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-00 == Outdated reference: A later version (-03) exists of draft-iab-html-rfc-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 (~~), 7 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 January 20, 2016 5 Expires: July 23, 2016 7 RFC Format Framework 8 draft-iab-rfc-framework-01 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 July 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-00 to -01 . . . . . . . . . . . 12 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 15.1. Normative References . . . . . . . . . . . . . . . . . . 13 95 15.2. Informative References . . . . . . . . . . . . . . . . . 14 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 [RFC6949], "RFC Series Format Requirements and Future Development," 102 discussed the need for additional features within RFCs such as non- 103 ASCII characters to respect author names, more advanced artwork than 104 ASCII art, and documents that could display properly on a wide 105 variety of devices. Based on the discussions with the IETF community 106 as well as other communities of interest, the RFC Series Editor 107 decided to explore a change to the format of the Series 108 [XML-ANNOUNCE]. This document serves as the framework that describes 109 the problems being solved and summarizes the documents created to- 110 date that capture the specific requirements for each aspect of the 111 change in format. 113 Key changes to the publication of RFCs are highlighted, and a 114 transition plan that will take the Series from a plain-text, ASCII- 115 only format to the new formats is described [RFC-INTEREST]. 117 This document is concerned with the production of RFCs, focusing on 118 the published formats. It does not address any changes to the 119 processes each stream uses to develop and review their submissions 120 (specifically, how Internet-Drafts will be developed). While I-Ds 121 have a similar set of issues and concerns, directly addressing those 122 issues for I-Ds will be discussed within each document stream. 124 The details described in this document are expected to change based 125 on experience gained in implementing the RFC production center's 126 toolset. Revised documents will be published capturing those changes 127 as the toolset is completed. Other implementers must not expect 128 those changes to remain backwards-compatible with the details 129 described this document. 131 2. Problem Statement 133 When the first RFCs were published 45 years ago, the tools to create 134 and read RFCs were limited. Distribution was originally on paper via 135 postal mail to people living in the United States. 137 Today, there are nearly three billion people connected to the 138 Internet, and individuals from 45 countries or more regularly 139 attending IETF meetings over the last 5 years [ISTATS]. The Internet 140 is now global, and while the world has changed from when the first 141 RFCs were published, the Series remains critical to defining 142 protocols, standards, best practices, and more for this global 143 network that continues to grow. In order to make RFCs easily 144 viewable to the largest number of people possible, across a wide 145 array of devices, and to respect the diversity of authors and 146 reference materials, it is time to update the tightly prescribed 147 format of the RFC Series. 149 All changes to the format of the RFC Series must consider the 150 requirements of a wide set of communities, over an extended length of 151 time. For example, existing authors and implementers, lawyers that 152 argue Intellectual Property Rights (IPR), educators, managers, and 153 policy-makers that need to know what to list in potential RFPs for 154 their organizations, all have preferences and requirements for their 155 specific needs. The immediate needs of today's communities must be 156 balanced with the needs for long-term archival storage. 158 3. Terminology 160 The following terminology is used as described in RFC 6949: 162 ASCII: Coded Character Set - 7-bit American Standard Code for 163 Information Interchange, ANSI X3.4-1986 165 Canonical format: the authorized, recognized, accepted, and 166 archived version of the document 168 Metadata: information associated with a document so as to provide, 169 for example, definitions of its structure, or of elements within 170 the document such as its topic or author 172 Publication format: display and distribution format as it may be 173 read or printed after the publication process has completed 175 Reflowable text: text that automatically wraps to the next line in 176 a document as the user moves the margins of the text, either by 177 resizing the window or changing the font size 179 Revisable format: the format that will provide the information for 180 conversion into a Publication format; it is used or created by the 181 RFC Editor 183 Submission format: the format submitted to the RFC Editor for 184 editorial revision and publication 186 4. Overview of the Decision Making Process 188 Requirements, use cases, concerns, and suggestions were collected 189 from the communities of interest at every stage of the RFC format 190 update project. Input was received through the rfc-interest mailing 191 list, as well as in several face-to-face sessions at IETF meetings. 192 Regular conversations were held with the IETF, IRTF, IAB, and IAOC 193 chairs, and the Independent Stream Editor, to discuss high-level 194 stream requirements. Updates regarding the status of the project 195 were provided to the IETF community during the IETF Technical Plenary 196 as well as Format BoFs or IAB sessions at IETF 84, IETF 85, IETF 88, 197 IETF 89, and IETF 90 [IETF84] [IETF85] [IETF88] [IETF89] [IETF90]. 199 The first document published, RFC 6949, provided the first solid 200 documentation on what the requirements were for the Series and in 201 effect was the output from the first year of discussion on the topic 202 of RFC format. That RFC, as with all of the RFCs that informed the 203 format update work, was published as an IAB stream document, thus 204 following the process described in RFC 4845, "Process for Publication 205 of IAB RFCs" [RFC4845]. 207 After the high-level requirements were published, the RFC Series 208 Editor (RSE) brought together an RFC Format Design Team to start 209 working out the necessary details to develop the code needed to 210 create new and changed formats. The design team discussed moving 211 away from the existing xml2rfc vocabulary, but with such a strong 212 existing support base within the community and no clear value with 213 other XML vocabularies or schemas, the decision was made to work with 214 the XML2RFC version 2 (xml2rfc v2) model and use it as the base for 215 the new format world [I-D.iab-xml2rfcv2]. Part of this discussion 216 included a decision to stop using an XML document type definition 217 (DTD) in favor of a Regular Language for XML Next General (Relax NG) 218 model using a defined vocabulary. While the bi-weekly calls for this 219 team were limited to Design Team members, review of the decisions as 220 documented in the drafts produced by this team were done publicly 221 through requests for feedback on the rfc-interest mailing list. 222 Several of the drafts produced by the Design Team, including the 223 xml2rfc v2 and v3 drafts and the SVG profile drafts, were sent 224 through an early GenART review before starting the process to be 225 accepted as an IAB stream draft [GEN-ART] [I-D.iab-xml2rfc]. 227 While the IETF community provided the majority of input on the 228 process, additional outreach opportunities were sought to gain input 229 from an even broader audience. Informal discussions were held with 230 participants at several International Association of Scientific, 231 Technical, and Medical Publisher events, and presentations made at 232 technical conferences such as the TERENA Networking Conference 2014 233 and NORDUnet 2014 [TNC2014] [NDN2014]. 235 In order to respond to concerns regarding responses to subpoenas and 236 to understand the requirements for lawyers, advice was requested from 237 the IETF Trust legal team regarding what format or formats would be 238 considered reasonable when responding to a subpoena request for an 239 RFC. 241 Given that several other standards development organizations (SDOs) 242 do not offer plain-text documents, and in fact may offer more than 243 one format for their standards, informal input was sought from them 244 regarding their experience with supporting one or more non-plain-text 245 formats for their standards. 247 Finally, the entire process was reviewed regularly with the RFC 248 Series Oversight Committee and regular updates provided to the IAB 249 and IESG [RSOC]. They have offered support and input throughout the 250 process. 252 Where consensus was not reached during the process, the RSE made any 253 necessary final decisions, as per the guidance in RFC 6635, "RFC 254 Editor Model (Version 2)" [RFC6635]. 256 5. Key Changes 258 At the highest level, the changes being made to the RFC Format 259 involve breaking away from a pure-ASCII plain text and moving to 260 canonical format that includes all the information required for 261 rendering a document into a wide variety of publication formats. The 262 RFC Editor will become responsible for more than just the plain-text 263 file and the PDF-from-text format created at time of publication; 264 they will be creating several different formats in order to meet the 265 diverse requirements of the community. 267 The final XML file produced by the RFC Editor will be considered the 268 canonical format for RFCs; it is the lowest common denominator that 269 holds all the information intended for an RFC. PDF/A-3 will be the 270 publication format offered in response to subpoenas for RFCs 271 published through this new process, and will be developed with an eye 272 towards long-term archival storage. HTML will be the focus of 273 providing the most flexible set of features for an RFC, including 274 JavaScript to provide pointers to errata and other metadata. Plain- 275 text will continue to be offered in order to support existing tool 276 chains where practicable and the individuals who prefer to read RFCs 277 in this format. 279 6. Canonical Format Documents 281 6.1. XML for RFCs 283 Key points regarding the XML format: 285 o The canonical format for RFCs is XML using the XML2RFC version 3 286 (xml2rfc v3) vocabulary. This file must contain all information 287 necessary to render a variety of formats; any question about what 288 was intended in the publication will be answered from this format. 290 o Authors may submit drafts in xml2rfc v2 vocabulary, but the final 291 publication will convert that to xml2rfc v3 vocabulary. 293 o SVG is supported and will be embedded in the final XML file. 295 o There will be automatically generated identifiers for sections, 296 paragraphs, figures, and tables in the final XML file. 298 o The XML file will not contain any xml2rfc v3 vocabulary elements 299 or attributes that have been marked deprecated. 301 o A Document Type Definition (DTD) will no longer be used. The 302 grammar will be defined using RelaxNG. 304 o The final XML file will contain, verbatim, the appropriate 305 boilerplate as applicable at time of publication specified by RFC 306 5741 or its successors [RFC5741]. 308 o The final XML will be self-contained. For instance, all features 309 that 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 not be derived from the plain-text publication 344 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 only as an additional option for 355 presentation of specific publication formats to provide up-to-date 356 links to post-publication metadata, such as errata or obsoletion. 357 Documents will be complete and readable as at time of publication, 358 when JavaScript is disabled. 360 7.2. PDF 362 [I-D.hansen-rfc-use-of-pdf] - Describes the tags and profiles that 363 will be used to create the new PDF format, including both the 364 internal structure and the visible layout of the file. A review of 365 the different versions of PDF is offered, with a recommendation of 366 what PDF standard should apply to RFCs. 368 Key points regarding the PDF output: 370 o The PDF file will not be derived from the plain-text publication 371 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. 509 A known risk at this point of the transition is the difficulty in 510 quantifying the resources required from the RPC. This phase will 511 require more work on the part of the RPC to support both old and new 512 publication processes for at least six months. There is potential 513 for confusion as consumers of RFCs find some documents published at 514 this time with a full set of outputs, while other documents only have 515 plain text. There may be a delay in publication as new bugs are 516 found that must be fixed before the files can be converted into the 517 canonical format and associated publication formats. 519 Final success of the transition will be measured by the closure of 520 all bugs which had been identified by the RPC and the Tools 521 Development team as major or critical. There must also be rough 522 consensus from the community regarding the utility of the new 523 formats. 525 10.3. Completion 527 Authors may submit XML (preferred) or plain text. The XML drafts 528 submitted for publication will be converted to canonical XML format 529 and published with all available publication formats. All authors 530 will be expected to review the final documents as consistent with the 531 evolving procedures for reviewing drafts. 533 Success for this phase will be measured by a solid understanding by 534 the RSE and the IAOC of the necessary costs and resources required 535 for long-term support of the new format model. 537 11. IANA Considerations 539 This document has no actions for IANA. 541 12. Security Considerations 543 Changing the format for RFCs involves modifying a great number of 544 components to publication. Understanding those changes and the 545 implications for the entire tool chain is critical so as to avoid 546 unintended bugs that would allow unintended changes to text. 547 Unintended changes to text could in turn corrupt a standard, practice 548 or critical piece of information about a protocol. 550 13. Acknowledgements 552 With many thanks to the RFC Format Design Team for their efforts in 553 making this transition successful: Nevil Brownlee (ISE), Tony Hansen, 554 Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, 555 Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler. 557 14. Appendix - Change log 559 To be removed by RFC Editor 561 14.1. draft-iab-rfc-framework-00 to -01 563 Decision Making Process: noted taht other XML schemas and 564 vocabularies were considered by the design team 566 XML for RFCs: "boilerplate at time of publication" 568 HTML: clarified that JavaScript should not impact readability of the 569 document as it looked at time of publication 571 15. References 573 15.1. Normative References 575 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 576 Requirements and Future Development", RFC 6949, 577 DOI 10.17487/RFC6949, May 2013, 578 . 580 [I-D.iab-xml2rfc] 581 Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft- 582 iab-xml2rfc-02 (work in progress), January 2016. 584 [I-D.iab-xml2rfcv2] 585 Reschke, J., "The 'XML2RFC' version 2 Vocabulary", draft- 586 iab-xml2rfcv2-02 (work in progress), September 2015. 588 [I-D.iab-svg-rfc] 589 Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft- 590 iab-svg-rfc-00 (work in progress), January 2016. 592 [I-D.iab-html-rfc] 593 Hildebrand, J. and P. Hoffman, "HyperText Markup Language 594 Request For Comments Format", draft-iab-html-rfc-01 (work 595 in progress), January 2016. 597 [I-D.hansen-rfc-use-of-pdf] 598 Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC 599 Series Output Document Format", draft-hansen-rfc-use-of- 600 pdf-08 (work in progress), October 2015. 602 [I-D.iab-rfc-plaintext] 603 Flanagan, H., "Requirements for Plain-Text RFCs", draft- 604 iab-rfc-plaintext-01 (work in progress), January 2016. 606 [I-D.iab-rfc-nonascii] 607 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 608 draft-iab-rfc-nonascii-00 (work in progress), January 609 2016. 611 [I-D.iab-rfc-css] 612 Flanagan, H., "CSS Requirements for RFCs", draft-iab-rfc- 613 css-00 (work in progress), January 2016. 615 15.2. Informative References 617 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 618 for Publication of IAB RFCs", RFC 4845, 619 DOI 10.17487/RFC4845, July 2007, 620 . 622 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 623 Headers, and Boilerplates", RFC 5741, 624 DOI 10.17487/RFC5741, December 2009, 625 . 627 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 628 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 629 2012, . 631 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 632 DOI 10.17487/RFC7322, September 2014, 633 . 635 [GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d., 636 . 638 [IASA-RFP] 639 IETF Administrative Support Activity, "RFPs and RFIs", 640 n.d., . 642 [IETF84] Flanagan, H., "IETF 84 Proceedings: RFC Format (rfcform)", 643 n.d., . 645 [IETF85] Flanagan, H., "IETF 85 Proceedings: RFC Format (rfcform)", 646 n.d., . 648 [IETF88] Flanagan, H., "IETF 88 Proceedings: RFC Format (rfcform)", 649 n.d., . 651 [IETF89] Flanagan, H., "IETF 89 Proceedings: RFC Format (rfcform)", 652 n.d., . 654 [IETF90] Flanagan, H., "IETF 90 Proceedings: RFC Format (rfcform)", 655 n.d., . 657 [ISTATS] "Internet Live Stats", n.d., 658 . 660 [NDN2014] "28th NORDUnet Conference 2014", 2014, 661 . 664 [RFC-INTEREST] 665 RFC Editor, "rfc-interest -- A list for discussion of the 666 RFC series and RFC Editor functions.", n.d., 667 . 670 [RSOC] IAB, "RFC Editor Program: The RSOC", n.d., 671 . 674 [TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 675 n.d., . 677 [TYPOGRAPHY] 678 Butterick, M., "Butterick's Practical Typography", n.d., 679 . 682 [XML-ANNOUNCE] 683 "Subject: [rfc-i] Direction of the RFC Format Development 684 effort", n.d., . 687 Author's Address 689 Heather Flanagan 690 RFC Editor 692 Email: rse@rfc-editor.org 693 URI: http://orcid.org/0000-0002-2647-2220