draft-iab-rfc-framework-00.txt   draft-iab-rfc-framework-01.txt 
Internet Architecture Board H. Flanagan Internet Architecture Board H. Flanagan
Internet-Draft RFC Editor Internet-Draft RFC Editor
Intended status: Informational January 4, 2016 Intended status: Informational January 20, 2016
Expires: July 7, 2016 Expires: July 23, 2016
RFC Format Framework RFC Format Framework
draft-iab-rfc-framework-00 draft-iab-rfc-framework-01
Abstract Abstract
The canonical format for the RFC Series has been plain-text, ASCII- The canonical format for the RFC Series has been plain-text, ASCII-
encoded for several decades. After extensive community discussion encoded for several decades. After extensive community discussion
and debate, the RFC Editor will be transitioning to XML as the and debate, the RFC Editor will be transitioning to XML as the
canonical format, with different publication formats rendered from canonical format using the XML2RFC version 3 vocabulary. Different
that base document. These changes are intended to increase the publication formats will be rendered from that base document. These
usability of the RFC Series by offering documents that match the changes are intended to increase the usability of the RFC Series by
needs of a wider variety of stakeholders. With these changes, offering documents that match the needs of a wider variety of
however, comes an increase in complexity for authors, consumers, and stakeholders. With these changes, however, comes an increase in
the publisher of RFCs. This document serves as the framework that complexity for authors, consumers, and the publisher of RFCs. This
describes the problems being solved and summarizes the many documents document serves as the framework that describes the problems being
that capture the specific requirements for each aspect of the change solved and summarizes the many documents that capture the specific
in format. requirements for each aspect of the change in format.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the rfc-interest mailing list Discussion of this draft takes place on the rfc-interest mailing list
(rfc-interest@rfc-editor.org), which has its home page at (rfc-interest@rfc-editor.org), which has its home page at
https://www.rfc-editor.org/mailman/listinfo/rfc-interest. https://www.rfc-editor.org/mailman/listinfo/rfc-interest.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 7, 2016. This Internet-Draft will expire on July 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the Decision Making Process . . . . . . . . . . . 4 4. Overview of the Decision Making Process . . . . . . . . . . . 4
5. Key Changes . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Key Changes . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Canonical Format Documents . . . . . . . . . . . . . . . . . 6 6. Canonical Format Documents . . . . . . . . . . . . . . . . . 6
6.1. XML for RFCs . . . . . . . . . . . . . . . . . . . . . . 6 6.1. XML for RFCs . . . . . . . . . . . . . . . . . . . . . . 6
7. Publication Format Documents . . . . . . . . . . . . . . . . 7 7. Publication Format Documents . . . . . . . . . . . . . . . . 8
7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 8 7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. Potential Future Publication Formats . . . . . . . . . . 9 7.4. Potential Future Publication Formats . . . . . . . . . . 9
7.4.1. EPUB . . . . . . . . . . . . . . . . . . . . . . . . 9 7.4.1. EPUB . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 9 8. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 9
8.1. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Content and Page Layout . . . . . . . . . . . . . . . . . . . 9 9. Content and Page Layout . . . . . . . . . . . . . . . . . . . 10
9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 9 9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 10
9.2. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 10
9.3. CSS Requirements . . . . . . . . . . . . . . . . . . . . 10 9.3. CSS Requirements . . . . . . . . . . . . . . . . . . . . 10
10. Transition Plan . . . . . . . . . . . . . . . . . . . . . . . 10 10. Transition Plan . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Statement of Work and RFP for Tool Development . . . . . 10 10.1. Statement of Work and RFP for Tool Development . . . . . 10
10.2. Testing and Transition . . . . . . . . . . . . . . . . . 10 10.2. Testing and Transition . . . . . . . . . . . . . . . . . 10
10.3. Completion . . . . . . . . . . . . . . . . . . . . . . . 11 10.3. Completion . . . . . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
14. Appendix - Change log . . . . . . . . . . . . . . . . . . . . 12 14. Appendix - Change log . . . . . . . . . . . . . . . . . . . . 12
14.1. draft-iab-rfc-framework-00 to -01 . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 14 15.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
[RFC6949], "RFC Series Format Requirements and Future Development," [RFC6949], "RFC Series Format Requirements and Future Development,"
discussed the need for additional features within RFCs such as non- discussed the need for additional features within RFCs such as non-
ASCII characters to respect author names, more advanced artwork than ASCII characters to respect author names, more advanced artwork than
ASCII art, and documents that could display properly on a wide ASCII art, and documents that could display properly on a wide
variety of devices. Based on the discussions with the IETF community variety of devices. Based on the discussions with the IETF community
as well as other communities of interest, the RFC Series Editor as well as other communities of interest, the RFC Series Editor
decided to explore a change to the format of the Series decided to explore a change to the format of the Series
skipping to change at page 3, line 40 skipping to change at page 3, line 42
The details described in this document are expected to change based The details described in this document are expected to change based
on experience gained in implementing the RFC production center's on experience gained in implementing the RFC production center's
toolset. Revised documents will be published capturing those changes toolset. Revised documents will be published capturing those changes
as the toolset is completed. Other implementers must not expect as the toolset is completed. Other implementers must not expect
those changes to remain backwards-compatible with the details those changes to remain backwards-compatible with the details
described this document. described this document.
2. Problem Statement 2. Problem Statement
When the first RFCs were published 45 years ago, the tools to create When the first RFCs were published 45 years ago, the tools to create
and read RFCs were limited. Distribution was in effect restricted to and read RFCs were limited. Distribution was originally on paper via
individuals who had access to the network that became the Internet. postal mail to people living in the United States.
Today, there are nearly three billion people connected to the Today, there are nearly three billion people connected to the
Internet, and individuals from 45 countries or more regularly Internet, and individuals from 45 countries or more regularly
attending IETF meetings over the last 5 years [ISTATS]. The Internet attending IETF meetings over the last 5 years [ISTATS]. The Internet
is now global, and while the world has changed from when the first is now global, and while the world has changed from when the first
RFCs were published, the Series remains critical to defining RFCs were published, the Series remains critical to defining
protocols, standards, best practices, and more for this global protocols, standards, best practices, and more for this global
network that continues to grow. In order to make RFCs easily network that continues to grow. In order to make RFCs easily
viewable to the largest number of people possible, across a wide viewable to the largest number of people possible, across a wide
array of devices, and to respect the diversity of authors and array of devices, and to respect the diversity of authors and
skipping to change at page 5, line 20 skipping to change at page 5, line 21
documentation on what the requirements were for the Series and in documentation on what the requirements were for the Series and in
effect was the output from the first year of discussion on the topic effect was the output from the first year of discussion on the topic
of RFC format. That RFC, as with all of the RFCs that informed the of RFC format. That RFC, as with all of the RFCs that informed the
format update work, was published as an IAB stream document, thus format update work, was published as an IAB stream document, thus
following the process described in RFC 4845, "Process for Publication following the process described in RFC 4845, "Process for Publication
of IAB RFCs" [RFC4845]. of IAB RFCs" [RFC4845].
After the high-level requirements were published, the RFC Series After the high-level requirements were published, the RFC Series
Editor (RSE) brought together an RFC Format Design Team to start Editor (RSE) brought together an RFC Format Design Team to start
working out the necessary details to develop the code needed to working out the necessary details to develop the code needed to
create new and changed formats. While the bi-weekly calls for this create new and changed formats. The design team discussed moving
team were limited to Design Team members, review of the drafts away from the existing xml2rfc vocabulary, but with such a strong
produced by this team were done publicly through requests for existing support base within the community and no clear value with
feedback on the rfc-interest mailing list. Several of the drafts other XML vocabularies or schemas, the decision was made to work with
produced by the Design Team, including the XML v2 and v3 drafts and the XML2RFC version 2 (xml2rfc v2) model and use it as the base for
the SVG profile drafts, were sent through an early GenART review the new format world [I-D.iab-xml2rfcv2]. Part of this discussion
before starting the process to be accepted as an IAB stream draft included a decision to stop using an XML document type definition
[GEN-ART]. (DTD) in favor of a Regular Language for XML Next General (Relax NG)
model using a defined vocabulary. While the bi-weekly calls for this
team were limited to Design Team members, review of the decisions as
documented in the drafts produced by this team were done publicly
through requests for feedback on the rfc-interest mailing list.
Several of the drafts produced by the Design Team, including the
xml2rfc v2 and v3 drafts and the SVG profile drafts, were sent
through an early GenART review before starting the process to be
accepted as an IAB stream draft [GEN-ART] [I-D.iab-xml2rfc].
While the IETF community provided the majority of input on the While the IETF community provided the majority of input on the
process, additional outreach opportunities were sought to gain input process, additional outreach opportunities were sought to gain input
from an even broader audience. Informal discussions were held with from an even broader audience. Informal discussions were held with
participants at several International Association of Scientific, participants at several International Association of Scientific,
Technical, and Medical Publisher events, and presentations made at Technical, and Medical Publisher events, and presentations made at
technical conferences such as the TERENA Networking Conference 2014 technical conferences such as the TERENA Networking Conference 2014
and NORDUnet 2014 [TNC2014] [NDN2014]. and NORDUnet 2014 [TNC2014] [NDN2014].
In order to respond to concerns regarding responses to subpoenas and In order to respond to concerns regarding responses to subpoenas and
skipping to change at page 5, line 51 skipping to change at page 6, line 13
RFC. RFC.
Given that several other standards development organizations (SDOs) Given that several other standards development organizations (SDOs)
do not offer plain-text documents, and in fact may offer more than do not offer plain-text documents, and in fact may offer more than
one format for their standards, informal input was sought from them one format for their standards, informal input was sought from them
regarding their experience with supporting one or more non-plain-text regarding their experience with supporting one or more non-plain-text
formats for their standards. formats for their standards.
Finally, the entire process was reviewed regularly with the RFC Finally, the entire process was reviewed regularly with the RFC
Series Oversight Committee and regular updates provided to the IAB Series Oversight Committee and regular updates provided to the IAB
and IESG [RSOC]. and IESG [RSOC]. They have offered support and input throughout the
process.
Where consensus was not reached during the process, the RSE made any Where consensus was not reached during the process, the RSE made any
necessary final decisions, as per the guidance in RFC 6635, "RFC necessary final decisions, as per the guidance in RFC 6635, "RFC
Editor Model (Version 2)" [RFC6635]. Editor Model (Version 2)" [RFC6635].
5. Key Changes 5. Key Changes
At the highest level, the changes being made to the RFC Format At the highest level, the changes being made to the RFC Format
involve breaking away from a pure-ASCII plain text and moving to involve breaking away from a pure-ASCII plain text and moving to
canonical format that includes all the information required for canonical format that includes all the information required for
skipping to change at page 6, line 38 skipping to change at page 6, line 49
text will continue to be offered in order to support existing tool text will continue to be offered in order to support existing tool
chains where practicable and the individuals who prefer to read RFCs chains where practicable and the individuals who prefer to read RFCs
in this format. in this format.
6. Canonical Format Documents 6. Canonical Format Documents
6.1. XML for RFCs 6.1. XML for RFCs
Key points regarding the XML format: Key points regarding the XML format:
o The canonical format for RFCs is XML using the XML2RFC v3 o The canonical format for RFCs is XML using the XML2RFC version 3
vocabulary [I-D.hoffman-xml2rfc]. This file must contain all (xml2rfc v3) vocabulary. This file must contain all information
information necessary to render a variety of formats; any question necessary to render a variety of formats; any question about what
about what was intended in the publication will be answered from was intended in the publication will be answered from this format.
this format.
o Authors may submit drafts in XML2RFC v2 vocabulary, but the final o Authors may submit drafts in xml2rfc v2 vocabulary, but the final
publication will convert that to XML2RFC v3 vocabulary. publication will convert that to xml2rfc v3 vocabulary.
o SVG is supported and will be embedded in the final XML file. o SVG is supported and will be embedded in the final XML file.
o There will be automatically generated identifiers for sections, o There will be automatically generated identifiers for sections,
paragraphs, figures, and tables in the final XML file. paragraphs, figures, and tables in the final XML file.
o The XML file will not contain any v3 vocabulary elements or o The XML file will not contain any xml2rfc v3 vocabulary elements
attributes that have been marked deprecated. or attributes that have been marked deprecated.
o A Document Type Definition (DTD) will no longer be used. The o A Document Type Definition (DTD) will no longer be used. The
grammar will be defined using RelaxNG. grammar will be defined using RelaxNG.
o The final XML file will contain, verbatim, the appropriate o The final XML file will contain, verbatim, the appropriate
boilerplate specified by RFC 5741. boilerplate as applicable at time of publication specified by RFC
5741 or its successors [RFC5741].
o The final XML will be self-contained. For instance, all features o The final XML will be self-contained. For instance, all features
that reference externally-defined input will be expanded. This that reference externally-defined input will be expanded. This
includes all uses of xinclude, src attributes (such as in includes all uses of xinclude, src attributes (such as in
<artwork> or <sourcecode> elements), include-like processing <artwork> or <sourcecode> elements), include-like processing
instructions, and externally defined entities. instructions, and externally defined entities.
o The final XML will not contain comments or processing o The final XML will not contain comments or processing
instructions. instructions.
o he final XML will not contain src attributes for <artwork> or o The final XML will not contain src attributes for <artwork> or
<sourcecode> elements. <sourcecode> elements.
[I-D.iab-xml2rfcv2] Describes the xml2rfc v2 vocabulary. While in [I-D.iab-xml2rfcv2] Describes the xml2rfc v2 vocabulary. While in
wide use today, this vocabulary had not been formally documented. In wide use today, this vocabulary had not been formally documented. In
order to understand what needed to change in the vocabulary to allow order to understand what needed to change in the vocabulary to allow
for a more simple experience and additional features for authors, the for a more simple experience and additional features for authors, the
current vocabulary needed to be fully described. This document, when current vocabulary needed to be fully described. This document, when
published, will be obsoleted by the RFC published from draft-hoffman- published, will be obsoleted by the RFC published from draft-iab-
xml2rfc. xml2rfc.
[I-D.hoffman-xml2rfc] Describes the xml2rfc v3 vocabulary. The [I-D.iab-xml2rfc] Describes the xml2rfc v3 vocabulary. The design
design goals in this vocabulary were to make the vocabulary more goals in this vocabulary were to make the vocabulary more intuitive
intuitive for authors, and to expand the features to support the for authors, and to expand the features to support the changes being
changes being made in the publication process. This draft, when made in the publication process. This draft, when published, will
published, will obsolete the RFC published from draft-iab-xml2rfcv2. obsolete the RFC published from draft-iab-xml2rfcv2.
7. Publication Format Documents 7. Publication Format Documents
7.1. HTML 7.1. HTML
[I-D.hildebrand-html-rfc] - Describes the semantic HTML that will be [I-D.iab-html-rfc] - Describes the semantic HTML that will be
produced by the RFC Editor from the xml2rfc v3 files. produced by the RFC Editor from the xml2rfc v3 files.
Key points regarding the HTML output: Key points regarding the HTML output:
o The HTML will not be derived from the plain-text publication o The HTML will not be derived from the plain-text publication
format. format.
o The body of the document will use a subset of HTML. The documents o The body of the document will use a subset of HTML. The documents
will include CSS for default visual presentation; it can be will include CSS for default visual presentation; it can be
overwritten by a local CSS file. overwritten by a local CSS file.
o SVG is supported and will be included in the HTML file. o SVG is supported and will be included in the HTML file.
o Text will be reflowable. o Text will be reflowable.
o JavaScript will be supported only as an additional option for o JavaScript will be supported only as an additional option for
presentation of specific publication formats to provide up-to-date presentation of specific publication formats to provide up-to-date
links to post-publication metadata, such as errata or obsoletion. links to post-publication metadata, such as errata or obsoletion.
Documents will be complete and readable when JavaScript is Documents will be complete and readable as at time of publication,
disabled. when JavaScript is disabled.
7.2. PDF 7.2. PDF
[I-D.hansen-rfc-use-of-pdf] - Describes the tags and profiles that [I-D.hansen-rfc-use-of-pdf] - Describes the tags and profiles that
will be used to create the new PDF format, including both the will be used to create the new PDF format, including both the
internal structure and the visible layout of the file. A review of internal structure and the visible layout of the file. A review of
the different versions of PDF is offered, with a recommendation of the different versions of PDF is offered, with a recommendation of
what PDF standard should apply to RFCs. what PDF standard should apply to RFCs.
Key points regarding the PDF output: Key points regarding the PDF output:
skipping to change at page 8, line 45 skipping to change at page 9, line 9
o The PDF will look more like the HTML publication format than the o The PDF will look more like the HTML publication format than the
plain-text publication format. plain-text publication format.
o The PDF will include a rich set of tags and metadata within the o The PDF will include a rich set of tags and metadata within the
document document
o SVG is supported and will be included in the PDF file. o SVG is supported and will be included in the PDF file.
7.3. Plain Text 7.3. Plain Text
[I-D.flanagan-plaintext] - Describes the details of the plain text [I-D.iab-rfc-plaintext] - Describes the details of the plain text
format, focusing in particular on what is changing from the existing format, focusing in particular on what is changing from the existing
plain-text output. plain-text output.
Key points regarding the plain-text output: Key points regarding the plain-text output:
o The plain-text document will no longer be the canonical version of o The plain-text document will no longer be the canonical version of
an RFC. an RFC.
o The plain-text format will be UTF-8 encoded; non-ASCII characters o The plain-text format will be UTF-8 encoded; non-ASCII characters
will be allowed. will be allowed.
skipping to change at page 9, line 34 skipping to change at page 9, line 47
7.4.1. EPUB 7.4.1. EPUB
This format is intended for use by ebook readers and will be This format is intended for use by ebook readers and will be
available for RFCs after the requirements have been defined. No available for RFCs after the requirements have been defined. No
draft is currently available. draft is currently available.
8. Figures and Artwork 8. Figures and Artwork
8.1. SVG 8.1. SVG
[I-D.brownlee-svg-rfc] Describes the profile for SVG line art. SVG [I-D.iab-svg-rfc] Describes the profile for SVG line art. SVG is an
is an XML-based vocabulary for creating line drawings; SVG XML-based vocabulary for creating line drawings; SVG information will
information will be embedded within the canonical XML at time of be embedded within the canonical XML at time of publication.
publication.
9. Content and Page Layout 9. Content and Page Layout
9.1. Non-ASCII Characters 9.1. Non-ASCII Characters
There are security and readability implications to moving outside the There are security and readability implications to moving outside the
ASCII range of characters. [I-D.flanagan-nonascii] focuses on ASCII range of characters. [I-D.iab-rfc-nonascii] focuses on exactly
exactly where and how non-ASCII characters may be used in an RFC, where and how non-ASCII characters may be used in an RFC, with an eye
with an eye towards keeping the documents as secure and readable as towards keeping the documents as secure and readable as possible
possible given the information that needs to be expressed. given the information that needs to be expressed.
9.2. Style Guide 9.2. Style Guide
The RFC Style Guide [RFC7322] was revised to remove as much page The RFC Style Guide [RFC7322] was revised to remove as much page
formatting information as possible, focusing instead on grammar, formatting information as possible, focusing instead on grammar,
structure, and content of RFCs. Some of the changes recommended, structure, and content of RFCs. Some of the changes recommended,
however, informed the XML v3 vocabulary. however, informed the XML v3 vocabulary.
9.3. CSS Requirements 9.3. CSS Requirements
Requirements under development; a draft will be posted and described [I-D.iab-rfc-css] describe how the CSS classes mentioned in the HTML
here in a later revision of this framework. format draft, "HyperText Markup Language Request for Comments
Format", should be used to create an accessible and responsive design
for the HTML format.
10. Transition Plan 10. Transition Plan
10.1. Statement of Work and RFP for Tool Development 10.1. Statement of Work and RFP for Tool Development
Existing tools for the creation of RFCs will need to be updated, and Existing tools for the creation of RFCs will need to be updated, and
new tools created, to implement the updated format. As the new tools created, to implement the updated format. As the
requirements gathering effort, described in the various documents requirements gathering effort, described in the various documents
described earlier int this draft, finishes the bulk of the work, the described earlier int this draft, finishes the bulk of the work, the
Tools Development Team of the IETF will work with the RSE to develop Tools Development Team of the IETF will work with the RSE to develop
skipping to change at page 11, line 21 skipping to change at page 11, line 33
usability of the new publication formats. usability of the new publication formats.
Success will be measured by the closure of all bugs which had been Success will be measured by the closure of all bugs which had been
identified by the RPC and the Tools Development team as fatal and identified by the RPC and the Tools Development team as fatal and
consensus on the readiness of the XML vocabulary and final XML files consensus on the readiness of the XML vocabulary and final XML files
for publication. The actual rendering engine can go through further for publication. The actual rendering engine can go through further
review and iteration, as the publication formats may be republished review and iteration, as the publication formats may be republished
as needed. as needed.
Authors are not required to submit their approved drafts in an XML Authors are not required to submit their approved drafts in an XML
format; plain-text will also remain an option for the foreseeable format, though they are strongly encouraged to do so; plain-text will
future. However, documents submitted as plain-text cannot include also remain an option for the foreseeable future. However, documents
such features as SVG artwork. submitted as plain-text cannot include such features as SVG artwork.
A known risk at this point of the transition is the difficulty in A known risk at this point of the transition is the difficulty in
quantifying the resources required from the RPC. This phase will quantifying the resources required from the RPC. This phase will
require more work on the part of the RPC to support both old and new require more work on the part of the RPC to support both old and new
publication processes for at least six months. There is potential publication processes for at least six months. There is potential
for confusion as consumers of RFCs find some documents published at for confusion as consumers of RFCs find some documents published at
this time with a full set of outputs, while other documents only have this time with a full set of outputs, while other documents only have
plain text. There may be a delay in publication as new bugs are plain text. There may be a delay in publication as new bugs are
found that must be fixed before the files can be converted into the found that must be fixed before the files can be converted into the
canonical format and associated publication formats. canonical format and associated publication formats.
skipping to change at page 11, line 46 skipping to change at page 12, line 10
all bugs which had been identified by the RPC and the Tools all bugs which had been identified by the RPC and the Tools
Development team as major or critical. There must also be rough Development team as major or critical. There must also be rough
consensus from the community regarding the utility of the new consensus from the community regarding the utility of the new
formats. formats.
10.3. Completion 10.3. Completion
Authors may submit XML (preferred) or plain text. The XML drafts Authors may submit XML (preferred) or plain text. The XML drafts
submitted for publication will be converted to canonical XML format submitted for publication will be converted to canonical XML format
and published with all available publication formats. All authors and published with all available publication formats. All authors
will be expected to review the XML and the publication formats prior will be expected to review the final documents as consistent with the
to publication. Further process detail still under discussion. evolving procedures for reviewing drafts.
Success for this phase will be measured by a solid understanding by Success for this phase will be measured by a solid understanding by
the RSE and the IAOC of the necessary costs and resources required the RSE and the IAOC of the necessary costs and resources required
for long-term support of the new format model. for long-term support of the new format model.
11. IANA Considerations 11. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
12. Security Considerations 12. Security Considerations
skipping to change at page 12, line 29 skipping to change at page 12, line 41
With many thanks to the RFC Format Design Team for their efforts in With many thanks to the RFC Format Design Team for their efforts in
making this transition successful: Nevil Brownlee (ISE), Tony Hansen, making this transition successful: Nevil Brownlee (ISE), Tony Hansen,
Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach,
Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler. Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.
14. Appendix - Change log 14. Appendix - Change log
To be removed by RFC Editor To be removed by RFC Editor
draft-flanagan-rfc-framework-04 14.1. draft-iab-rfc-framework-00 to -01
Minor wording cleanup
draft-flanagan-rfc-framework-03
o XML for RFCs: additional details on changes added
o Fixed references
draft-flanagan-rfc-framework-02
o HTML: Fixed the statement on semantic HTML to capture intended
balance between CSS and HTML.
o Transition: Major changes to overall plan, emphasizing a more
iterative process for tool development; also removed statement
that I-Ds submitted as plain-text would only be published as
plain-text. The final process for publication and review has been
marked as under discussion.
draft-flanagan-rfc-framework-01
o Problem Statement: Added educators and managers to the list of
communities impacted by the format of the RFC Series.
o Terminology: Removed comment about RFC 2119.
o Overview of the Decision Making Process: Added a point about
conversation with the IETF, IRTF, IAB, and IAOC chairs, and the
ISE. Indicated that the RSE brought together the RFC Format
Design Team. Added a proper citation tag for the NORDUnet 2014
conference.
o Key Changes: Removed "canonical" from description of the plain-
text file.
o Document Summary: Removed "Section 6. Document Summary" and moved
key points for the different formats in the "Canonical Format
Documents" and "Publication Format Documents" sections.
o XML for RFCs: Reworded bullet points to offer complete sentences.
Added a statement regarding the DTD. Changed mention of "v2
vocabulary" and "v3 vocabulary: to XML2RFC v2/v3 vocabulary.
o HTML: Reworded bullet points to offer complete sentences. Added
"complete" to statement about JavaScript.
o PDF: Reworded bullet points to offer complete sentences.
o Plain Text: Reworded bullet points to offer complete sentences.
Added reference for "widow and orphan control."
o Transition Plan: Added a "Tool Development Phase" to the Decision Making Process: noted taht other XML schemas and
Transition Plan. vocabularies were considered by the design team
o Transition Phase: Emphasized the possibility of dropping back to XML for RFCs: "boilerplate at time of publication"
publishing plain text documents if bugs are found that prevent
timely creation of RFCs.
o Completion: Revised the expectation to indicate the RPC may HTML: clarified that JavaScript should not impact readability of the
perform the text to XML conversion for the authors. Added the document as it looked at time of publication
statement that all drafts submitted with an XML file will be
published as a canonical XML and all available publication
formats.
15. References 15. References
15.1. Normative References 15.1. Normative References
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
Requirements and Future Development", RFC 6949, Requirements and Future Development", RFC 6949,
DOI 10.17487/RFC6949, May 2013, DOI 10.17487/RFC6949, May 2013,
<http://www.rfc-editor.org/info/rfc6949>. <http://www.rfc-editor.org/info/rfc6949>.
[I-D.hoffman-xml2rfc] [I-D.iab-xml2rfc]
Hoffman, P., "The 'XML2RFC' version 3 Vocabulary", draft- Hoffman, P., "The "xml2rfc" version 3 Vocabulary", draft-
hoffman-xml2rfc-23 (work in progress), September 2015. iab-xml2rfc-02 (work in progress), January 2016.
[I-D.iab-xml2rfcv2] [I-D.iab-xml2rfcv2]
Reschke, J., "The 'XML2RFC' version 2 Vocabulary", draft- Reschke, J., "The 'XML2RFC' version 2 Vocabulary", draft-
iab-xml2rfcv2-02 (work in progress), September 2015. iab-xml2rfcv2-02 (work in progress), September 2015.
[I-D.brownlee-svg-rfc] [I-D.iab-svg-rfc]
Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft- Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", draft-
brownlee-svg-rfc-13 (work in progress), October 2015. iab-svg-rfc-00 (work in progress), January 2016.
[I-D.hildebrand-html-rfc] [I-D.iab-html-rfc]
Hildebrand, J. and P. Hoffman, "HyperText Markup Language Hildebrand, J. and P. Hoffman, "HyperText Markup Language
Request For Comments Format", draft-hildebrand-html-rfc-10 Request For Comments Format", draft-iab-html-rfc-01 (work
(work in progress), August 2015. in progress), January 2016.
[I-D.hansen-rfc-use-of-pdf] [I-D.hansen-rfc-use-of-pdf]
Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC Hansen, T., Masinter, L., and M. Hardy, "PDF for an RFC
Series Output Document Format", draft-hansen-rfc-use-of- Series Output Document Format", draft-hansen-rfc-use-of-
pdf-08 (work in progress), October 2015. pdf-08 (work in progress), October 2015.
[I-D.flanagan-plaintext] [I-D.iab-rfc-plaintext]
Flanagan, H., "Requirements for Plain-Text RFCs", draft- Flanagan, H., "Requirements for Plain-Text RFCs", draft-
flanagan-plaintext-09 (work in progress), November 2015. iab-rfc-plaintext-01 (work in progress), January 2016.
[I-D.flanagan-nonascii] [I-D.iab-rfc-nonascii]
Flanagan, H., "The Use of Non-ASCII Characters in RFCs", Flanagan, H., "The Use of Non-ASCII Characters in RFCs",
draft-flanagan-nonascii-06 (work in progress), November draft-iab-rfc-nonascii-00 (work in progress), January
2015. 2016.
[I-D.iab-rfc-css]
Flanagan, H., "CSS Requirements for RFCs", draft-iab-rfc-
css-00 (work in progress), January 2016.
15.2. Informative References 15.2. Informative References
[RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process [RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process
for Publication of IAB RFCs", RFC 4845, for Publication of IAB RFCs", RFC 4845,
DOI 10.17487/RFC4845, July 2007, DOI 10.17487/RFC4845, July 2007,
<http://www.rfc-editor.org/info/rfc4845>. <http://www.rfc-editor.org/info/rfc4845>.
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
Headers, and Boilerplates", RFC 5741,
DOI 10.17487/RFC5741, December 2009,
<http://www.rfc-editor.org/info/rfc5741>.
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
2012, <http://www.rfc-editor.org/info/rfc6635>. 2012, <http://www.rfc-editor.org/info/rfc6635>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, [RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014, DOI 10.17487/RFC7322, September 2014,
<http://www.rfc-editor.org/info/rfc7322>. <http://www.rfc-editor.org/info/rfc7322>.
[GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d., [GEN-ART] IETF, "General Area Review Team (Gen-ART)", n.d.,
<http://www.ietf.org/iesg/directorate/gen-art.html>. <http://www.ietf.org/iesg/directorate/gen-art.html>.
 End of changes. 44 change blocks. 
142 lines changed or deleted 109 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/