idnits 2.17.1 draft-iab-rfc-framework-03.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 2, 2016) is 3005 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 2, 2016 5 Expires: August 5, 2016 7 RFC Format Framework 8 draft-iab-rfc-framework-03 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 5, 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 . . . . . . . . . . . . . . . . 7 73 7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 8 76 7.4. Potential Future Publication Formats . . . . . . . . . . 9 77 7.4.1. EPUB . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. Content and Page Layout . . . . . . . . . . . . . . . . . . . 9 81 9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 9 82 9.2. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 10 83 9.3. CSS Requirements . . . . . . . . . . . . . . . . . . . . 10 84 10. Transition Plan . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Statement of Work and RFP for Tool Development . . . . . 10 86 10.2. Testing and Transition . . . . . . . . . . . . . . . . . 10 87 10.3. Completion . . . . . . . . . . . . . . . . . . . . . . . 11 88 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 89 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 90 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 91 14. Appendix - Change log . . . . . . . . . . . . . . . . . . . . 12 92 14.1. draft-iab-rfc-framework-00 to -01 . . . . . . . . . . . 12 93 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 95 15.2. Informative References . . . . . . . . . . . . . . . . . 13 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 There are nearly three billion people connected to the Internet, and 134 individuals from 45 countries or more regularly attending IETF 135 meetings over the last 5 years [ISTATS]. The Internet is now global, 136 and while the world has changed from when the first RFCs were 137 published, the Series remains critical to defining protocols, 138 standards, best practices, and more for this global network that 139 continues to grow. In order to make RFCs easily viewable to the 140 largest number of people possible, across a wide array of devices, 141 and to respect the diversity of authors and reference materials, it 142 is time to update the tightly prescribed format of the RFC Series. 144 All changes to the format of the RFC Series must consider the 145 requirements of a wide set of communities, over an extended length of 146 time. For example, existing authors and implementers, lawyers that 147 argue Intellectual Property Rights (IPR), educators, managers, and 148 policy-makers that need to know what to list in potential RFPs for 149 their organizations, all have preferences and requirements for their 150 specific needs. The immediate needs of today's communities must be 151 balanced with the needs for long-term archival storage. 153 3. Terminology 155 The following terminology is used as described in RFC 6949: 157 ASCII: Coded Character Set - 7-bit American Standard Code for 158 Information Interchange, ANSI X3.4-1986 160 Canonical format: the authorized, recognized, accepted, and 161 archived version of the document 163 Metadata: information associated with a document so as to provide, 164 for example, definitions of its structure, or of elements within 165 the document such as its topic or author 167 Publication format: display and distribution format as it may be 168 read or printed after the publication process has completed 170 Reflowable text: text that automatically wraps to the next line in 171 a document as the user moves the margins of the text, either by 172 resizing the window or changing the font size 174 Revisable format: the format that will provide the information for 175 conversion into a Publication format; it is used or created by the 176 RFC Editor 178 Submission format: the format submitted to the RFC Editor for 179 editorial revision and publication 181 4. Overview of the Decision Making Process 183 Requirements, use cases, concerns, and suggestions were collected 184 from the communities of interest at every stage of the RFC format 185 update project. Input was received through the rfc-interest mailing 186 list, as well as in several face-to-face sessions at IETF meetings. 187 Regular conversations were held with the IETF, IRTF, IAB, and IAOC 188 chairs, and the Independent Stream Editor, to discuss high-level 189 stream requirements. Updates regarding the status of the project 190 were provided to the IETF community during the IETF Technical Plenary 191 as well as Format BoFs or IAB sessions at IETF 84, IETF 85, IETF 88, 192 IETF 89, and IETF 90 [IETF84] [IETF85] [IETF88] [IETF89] [IETF90]. 194 The first document published, RFC 6949, provided the first solid 195 documentation on what the requirements were for the Series and in 196 effect was the output from the first year of discussion on the topic 197 of RFC format. That RFC, as with all of the RFCs that informed the 198 format update work, was published as an IAB stream document, thus 199 following the process described in RFC 4845, "Process for Publication 200 of IAB RFCs" [RFC4845]. 202 After the high-level requirements were published, the RFC Series 203 Editor (RSE) brought together an RFC Format Design Team to start 204 working out the necessary details to develop the code needed to 205 create new and changed formats. The design team discussed moving 206 away from the existing xml2rfc vocabulary, but with such a strong 207 existing support base within the community and no clear value with 208 other XML vocabularies or schemas, the decision was made to work with 209 the XML2RFC version 2 (xml2rfc v2) model and use it as the base for 210 the new format world [I-D.iab-xml2rfcv2]. Part of this discussion 211 included a decision to stop using an XML document type definition 212 (DTD) in favor of a Regular Language for XML Next General (Relax NG) 213 model using a defined vocabulary. While the bi-weekly calls for this 214 team were limited to Design Team members, review of the decisions as 215 documented in the drafts produced by this team were done publicly 216 through requests for feedback on the rfc-interest mailing list. 217 Several of the drafts produced by the Design Team, including the 218 xml2rfc v2 and v3 drafts and the SVG profile drafts, were sent 219 through an early GenART review before starting the process to be 220 accepted as an IAB stream draft [GEN-ART] [I-D.iab-xml2rfc]. 222 While the IETF community provided the majority of input on the 223 process, additional outreach opportunities were sought to gain input 224 from an even broader audience. Informal discussions were held with 225 participants at several International Association of Scientific, 226 Technical, and Medical Publisher events, and presentations made at 227 technical conferences such as the TERENA Networking Conference 2014 228 and NORDUnet 2014 [TNC2014] [NDN2014]. 230 In order to respond to concerns regarding responses to subpoenas and 231 to understand the requirements for lawyers, advice was requested from 232 the IETF Trust legal team regarding what format or formats would be 233 considered reasonable when responding to a subpoena request for an 234 RFC. 236 Given that several other standards development organizations (SDOs) 237 do not offer plain-text documents, and in fact may offer more than 238 one format for their standards, informal input was sought from them 239 regarding their experience with supporting one or more non-plain-text 240 formats for their standards. 242 Finally, the entire process was reviewed regularly with the RFC 243 Series Oversight Committee and regular updates provided to the IAB 244 and IESG [RSOC]. They have offered support and input throughout the 245 process. 247 Where consensus was not reached during the process, the RSE made any 248 necessary final decisions, as per the guidance in RFC 6635, "RFC 249 Editor Model (Version 2)" [RFC6635]. 251 5. Key Changes 253 At the highest level, the changes being made to the RFC Format 254 involve breaking away from a pure-ASCII plain text and moving to 255 canonical format that includes all the information required for 256 rendering a document into a wide variety of publication formats. The 257 RFC Editor will become responsible for more than just the plain-text 258 file and the PDF-from-text format created at time of publication; 259 they will be creating several different formats in order to meet the 260 diverse requirements of the community. 262 The final XML file produced by the RFC Editor will be considered the 263 canonical format for RFCs; it is the lowest common denominator that 264 holds all the information intended for an RFC. PDF/A-3 will be the 265 publication format offered in response to subpoenas for RFCs 266 published through this new process, and will be developed with an eye 267 towards long-term archival storage. HTML will be the focus of 268 providing the most flexible set of features for an RFC, including 269 JavaScript to provide pointers to errata and other metadata. Plain- 270 text will continue to be offered in order to support existing tool 271 chains where practicable and the individuals who prefer to read RFCs 272 in this format. 274 6. Canonical Format Documents 276 6.1. XML for RFCs 278 Key points regarding the XML format: 280 o The canonical format for RFCs is XML using the XML2RFC version 3 281 (xml2rfc v3) vocabulary. This file must contain all information 282 necessary to render a variety of formats; any question about what 283 was intended in the publication will be answered from this format. 285 o Authors may submit drafts in xml2rfc v2 vocabulary, but the final 286 publication will convert that to xml2rfc v3 vocabulary. 288 o SVG is supported and will be embedded in the final XML file. 290 o There will be automatically generated identifiers for sections, 291 paragraphs, figures, and tables in the final XML file. 293 o The XML file will not contain any xml2rfc v3 vocabulary elements 294 or attributes that have been marked deprecated. 296 o A Document Type Definition (DTD) will no longer be used. The 297 grammar will be defined using RelaxNG. 299 o The final XML file will contain, verbatim, the appropriate 300 boilerplate as applicable at time of publication specified by RFC 301 5741 or its successors [RFC5741]. 303 o The final XML will be self-contained. For instance, all features 304 that reference externally-defined input will be expanded. This 305 includes all uses of xinclude, src attributes (such as in 306 or elements), include-like processing 307 instructions, and externally defined entities. 309 o The final XML will not contain comments or processing 310 instructions. 312 o The final XML will not contain src attributes for or 313 elements. 315 [I-D.iab-xml2rfcv2] Describes the xml2rfc v2 vocabulary. While in 316 wide use today, this vocabulary had not been formally documented. In 317 order to understand what needed to change in the vocabulary to allow 318 for a more simple experience and additional features for authors, the 319 current vocabulary needed to be fully described. This document, when 320 published, will be obsoleted by the RFC published from draft-iab- 321 xml2rfc. 323 [I-D.iab-xml2rfc] Describes the xml2rfc v3 vocabulary. The design 324 goals in this vocabulary were to make the vocabulary more intuitive 325 for authors, and to expand the features to support the changes being 326 made in the publication process. This draft, when published, will 327 obsolete the RFC published from draft-iab-xml2rfcv2. 329 7. Publication Format Documents 331 7.1. HTML 333 [I-D.iab-html-rfc] - Describes the semantic HTML that will be 334 produced by the RFC Editor from the xml2rfc v3 files. 336 Key points regarding the HTML output: 338 o The HTML will not be derived from the plain-text publication 339 format. 341 o The body of the document will use a subset of HTML. The documents 342 will include CSS for default visual presentation; it can be 343 overwritten by a local CSS file. 345 o SVG is supported and will be included in the HTML file. 347 o Text will be reflowable. 349 o JavaScript will be supported on a limited basis. It will not be 350 permitted to overwrite or change any text present in the rendered 351 html. It may, on a limited basis, add additional text that 352 provides post-publication metadata or pointers if warranted. All 353 such text will be clearly marked as additional. 355 7.2. PDF 357 [I-D.iab-rfc-use-of-pdf] - Describes the tags and profiles that will 358 be used to create the new PDF format, including both the internal 359 structure and the visible layout of the file. A review of the 360 different versions of PDF is offered, with a recommendation of what 361 PDF standard should apply to RFCs. 363 Key points regarding the PDF output: 365 o The PDF file will not be derived from the plain-text publication 366 format. 368 o The PDF publication format will conform to the PDF/A-3 standard 369 and will embed the canonical XML source. 371 o The PDF will look more like the HTML publication format than the 372 plain-text publication format. 374 o The PDF will include a rich set of tags and metadata within the 375 document 377 o SVG is supported and will be included in the PDF file. 379 7.3. Plain Text 381 [I-D.iab-rfc-plaintext] - Describes the details of the plain text 382 format, focusing in particular on what is changing from the existing 383 plain-text output. 385 Key points regarding the plain-text output: 387 o The plain-text document will no longer be the canonical version of 388 an RFC. 390 o The plain-text format will be UTF-8 encoded; non-ASCII characters 391 will be allowed. 393 o A Byte Order Mark (BOM) will be added at the start of each file. 395 o Widow and orphan control for the plain-text publication format 396 will not have priority for the developers creating the rendering 397 code [TYPOGRAPHY]. 399 o Authors may choose to have pointers to line art in other 400 publication formats in place of ASCII art in the .txt file. 402 o Both a paginated and an unpaginated plain-text file will be 403 created. 405 o Running headers and footers will not be used. 407 7.4. Potential Future Publication Formats 409 7.4.1. EPUB 411 This format is intended for use by ebook readers and will be 412 available for RFCs after the requirements have been defined. No 413 draft is currently available. 415 8. Figures and Artwork 417 8.1. SVG 419 [I-D.iab-svg-rfc] Describes the profile for SVG line art. SVG is an 420 XML-based vocabulary for creating line drawings; SVG information will 421 be embedded within the canonical XML at time of publication. 423 9. Content and Page Layout 425 9.1. Non-ASCII Characters 427 There are security and readability implications to moving outside the 428 ASCII range of characters. [I-D.iab-rfc-nonascii] focuses on exactly 429 where and how non-ASCII characters may be used in an RFC, with an eye 430 towards keeping the documents as secure and readable as possible 431 given the information that needs to be expressed. 433 9.2. Style Guide 435 The RFC Style Guide [RFC7322] was revised to remove as much page 436 formatting information as possible, focusing instead on grammar, 437 structure, and content of RFCs. Some of the changes recommended, 438 however, informed the XML v3 vocabulary. 440 9.3. CSS Requirements 442 [I-D.iab-rfc-css] describe how the CSS classes mentioned in the HTML 443 format draft, "HyperText Markup Language Request for Comments 444 Format", should be used to create an accessible and responsive design 445 for the HTML format. 447 10. Transition Plan 449 10.1. Statement of Work and RFP for Tool Development 451 Existing tools for the creation of RFCs will need to be updated, and 452 new tools created, to implement the updated format. As the 453 requirements gathering effort, described in the various documents 454 described earlier int this draft, finishes the bulk of the work, the 455 Tools Development Team of the IETF will work with the RSE to develop 456 Statements of Work (SoWs). Those SoWs will first be reviewed within 457 the Tools Development Team, the Tools Management Committee, and go 458 out for a public comment period. After public review, the SoWs will 459 be attached to a Request for Proposal (RFP) and posted as per the 460 IASA bid process [IASA-RFP]. 462 Once bids have been received, reviewed, and awarded, coding will 463 begin. 465 10.2. Testing and Transition 467 During the I-D review and approval process, authors and stream- 468 approving bodies will select drafts to run through the proposed new 469 publication process. While the final RFCs published during this time 470 will continue as plain-text and immutable once published, the 471 feedback process is necessary to bootstrap initial testing. These 472 early tests will target finding issues with the proposed xml2rfc v3 473 vocabulary that result in poorly formed publication formats as well 474 as issues that prevent proper review of submitted drafts. 476 Feedback will result in regular iteration of the basic code and XML 477 vocabulary. In order to limit the amount of time the RFC Production 478 Center (RPC) spends on testing and QA, note that their priority is to 479 edit and publish documents, community assistance will be necessary to 480 help move this stage along. A mailing list and experimental source 481 directory on the RFC Editor website will be created for community 482 members willing to assist in the detailed review of the XML and 483 publication formats. Editorial checks of the publication formats by 484 the community are out of scope; the focus will be the QA of each 485 available output, checking for inconsistencies across formats. 487 The purpose of testing phase is to work with the community to 488 identify and fix bugs in the process and the code, before producing 489 canonical, immutable XML, and to collect additional feedback on the 490 usability of the new publication formats. 492 Success will be measured by the closure of all bugs which had been 493 identified by the RPC and the Tools Development team as fatal and 494 consensus on the readiness of the XML vocabulary and final XML files 495 for publication. The actual rendering engine can go through further 496 review and iteration, as the publication formats may be republished 497 as needed. 499 Authors are not required to submit their approved drafts in an XML 500 format, though they are strongly encouraged to do so; plain-text will 501 also remain an option for the foreseeable future. However, documents 502 submitted as plain-text cannot include such features as SVG artwork. 504 A known risk at this point of the transition is the difficulty in 505 quantifying the resources required from the RPC. This phase will 506 require more work on the part of the RPC to support both old and new 507 publication processes for at least six months. There is potential 508 for confusion as consumers of RFCs find some documents published at 509 this time with a full set of outputs, while other documents only have 510 plain text. There may be a delay in publication as new bugs are 511 found that must be fixed before the files can be converted into the 512 canonical format and associated publication formats. 514 Final success of the transition will be measured by the closure of 515 all bugs which had been identified by the RPC and the Tools 516 Development team as major or critical. There must also be rough 517 consensus from the community regarding the utility of the new 518 formats. 520 10.3. Completion 522 Authors may submit XML (preferred) or plain text. The XML drafts 523 submitted for publication will be converted to canonical XML format 524 and published with all available publication formats. All authors 525 will be expected to review the final documents as consistent with the 526 evolving procedures for reviewing drafts. 528 Success for this phase will be measured by a solid understanding by 529 the RSE and the IAOC of the necessary costs and resources required 530 for long-term support of the new format model. 532 11. IANA Considerations 534 This document has no actions for IANA. 536 12. Security Considerations 538 Changing the format for RFCs involves modifying a great number of 539 components to publication. Understanding those changes and the 540 implications for the entire tool chain is critical so as to avoid 541 unintended bugs that would allow unintended changes to text. 542 Unintended changes to text could in turn corrupt a standard, practice 543 or critical piece of information about a protocol. 545 13. Acknowledgements 547 With many thanks to the RFC Format Design Team for their efforts in 548 making this transition successful: Nevil Brownlee (ISE), Tony Hansen, 549 Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, 550 Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler. 552 14. Appendix - Change log 554 To be removed by RFC Editor 556 14.1. draft-iab-rfc-framework-00 to -01 558 Decision Making Process: noted taht other XML schemas and 559 vocabularies were considered by the design team 561 XML for RFCs: "boilerplate at time of publication" 563 HTML: clarified that JavaScript should not impact readability of the 564 document as it looked at time of publication 566 15. References 568 15.1. Normative References 570 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format 571 Requirements and Future Development", RFC 6949, 572 DOI 10.17487/RFC6949, May 2013, 573 . 575 [I-D.iab-xml2rfc] 576 Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft- 577 iab-xml2rfc-02 (work in progress), January 2016. 579 [I-D.iab-xml2rfcv2] 580 Reschke, J., "The 'XML2RFC' version 2 Vocabulary", draft- 581 iab-xml2rfcv2-02 (work in progress), September 2015. 583 [I-D.iab-svg-rfc] 584 Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft- 585 iab-svg-rfc-01 (work in progress), January 2016. 587 [I-D.iab-html-rfc] 588 Hildebrand, J. and P. Hoffman, "HyperText Markup Language 589 Request For Comments Format", draft-iab-html-rfc-01 (work 590 in progress), January 2016. 592 [I-D.iab-rfc-use-of-pdf] 593 Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC 594 Series Output Document Format", draft-iab-rfc-use-of- 595 pdf-01 (work in progress), January 2016. 597 [I-D.iab-rfc-plaintext] 598 Flanagan, H., "Requirements for Plain-Text RFCs", draft- 599 iab-rfc-plaintext-01 (work in progress), January 2016. 601 [I-D.iab-rfc-nonascii] 602 Flanagan, H., "The Use of Non-ASCII Characters in RFCs", 603 draft-iab-rfc-nonascii-00 (work in progress), January 604 2016. 606 [I-D.iab-rfc-css] 607 Flanagan, H., "CSS Requirements for RFCs", draft-iab-rfc- 608 css-00 (work in progress), January 2016. 610 15.2. Informative References 612 [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process 613 for Publication of IAB RFCs", RFC 4845, 614 DOI 10.17487/RFC4845, July 2007, 615 . 617 [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, 618 Headers, and Boilerplates", RFC 5741, 619 DOI 10.17487/RFC5741, December 2009, 620 . 622 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor 623 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 624 2012, . 626 [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, 627 DOI 10.17487/RFC7322, September 2014, 628 . 630 [GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d., 631 . 633 [IASA-RFP] 634 IETF Administrative Support Activity, "RFPs and RFIs", 635 n.d., . 637 [IETF84] Flanagan, H., "IETF 84 Proceedings: RFC Format (rfcform)", 638 n.d., . 640 [IETF85] Flanagan, H., "IETF 85 Proceedings: RFC Format (rfcform)", 641 n.d., . 643 [IETF88] Flanagan, H., "IETF 88 Proceedings: RFC Format (rfcform)", 644 n.d., . 646 [IETF89] Flanagan, H., "IETF 89 Proceedings: RFC Format (rfcform)", 647 n.d., . 649 [IETF90] Flanagan, H., "IETF 90 Proceedings: RFC Format (rfcform)", 650 n.d., . 652 [ISTATS] "Internet Live Stats", n.d., 653 . 655 [NDN2014] "28th NORDUnet Conference 2014", 2014, 656 . 659 [RFC-INTEREST] 660 RFC Editor, "rfc-interest -- A list for discussion of the 661 RFC series and RFC Editor functions.", n.d., 662 . 665 [RSOC] IAB, "RFC Editor Program: The RSOC", n.d., 666 . 669 [TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 670 n.d., . 672 [TYPOGRAPHY] 673 Butterick, M., "Butterick's Practical Typography", n.d., 674 . 677 [XML-ANNOUNCE] 678 "Subject: [rfc-i] Direction of the RFC Format Development 679 effort", n.d., . 682 Author's Address 684 Heather Flanagan 685 RFC Editor 687 Email: rse@rfc-editor.org 688 URI: http://orcid.org/0000-0002-2647-2220