draft-iab-rfc-framework-03.txt   draft-iab-rfc-framework-04.txt 
Internet Architecture Board H. Flanagan Internet Architecture Board H. Flanagan
Internet-Draft RFC Editor Internet-Draft RFC Editor
Intended status: Informational February 2, 2016 Intended status: Informational February 5, 2016
Expires: August 5, 2016 Expires: August 8, 2016
RFC Format Framework RFC Format Framework
draft-iab-rfc-framework-03 draft-iab-rfc-framework-04
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 using the XML2RFC version 3 vocabulary. Different canonical format using the XML2RFC version 3 vocabulary. Different
publication formats will be rendered from that base document. These publication formats will be rendered from that base document. These
changes are intended to increase the usability of the RFC Series by changes are intended to increase the usability of the RFC Series by
offering documents that match the needs of a wider variety of offering documents that match the needs of a wider variety of
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 August 5, 2016. This Internet-Draft will expire on August 8, 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 14.1. draft-iab-rfc-framework-03 to -04 . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 14.2. draft-iab-rfc-framework-02 to -03 . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 12 14.3. draft-iab-rfc-framework-01 to -02 . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 13 14.4. draft-iab-rfc-framework-00 to -01 . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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
[XML-ANNOUNCE]. This document serves as the framework that describes [XML-ANNOUNCE]. This document serves as the framework that describes
the problems being solved and summarizes the documents created to- the problems being solved and summarizes the documents created to-
date that capture the specific requirements for each aspect of the date that capture the specific requirements for each aspect of the
change in format. change in format.
Key changes to the publication of RFCs are highlighted, and a Key changes to the publication of RFCs are highlighted, and a
transition plan that will take the Series from a plain-text, ASCII- transition plan that will take the Series from a plain-text, ASCII-
only format to the new formats is described [RFC-INTEREST]. only format to the new formats is described on the rfc-interest
mailing list [RFC-INTEREST].
This document is concerned with the production of RFCs, focusing on This document is concerned with the production of RFCs, focusing on
the published formats. It does not address any changes to the the published formats. It does not address any changes to the
processes each stream uses to develop and review their submissions processes each stream uses to develop and review their submissions
(specifically, how Internet-Drafts will be developed). While I-Ds (specifically, how Internet-Drafts will be developed). While I-Ds
have a similar set of issues and concerns, directly addressing those have a similar set of issues and concerns, directly addressing those
issues for I-Ds will be discussed within each document stream. issues for I-Ds will be discussed within each document stream.
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
skipping to change at page 7, line 20 skipping to change at page 7, line 23
o The XML file will not contain any xml2rfc v3 vocabulary elements o The XML file will not contain any xml2rfc v3 vocabulary elements
or 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 as applicable at time of publication specified by RFC boilerplate as applicable at time of publication specified by RFC
5741 or its successors [RFC5741]. 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 with all the information
that reference externally-defined input will be expanded. This known at publication time. For instance, all features 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 The 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.
skipping to change at page 8, line 7 skipping to change at page 8, line 14
7. Publication Format Documents 7. Publication Format Documents
7.1. HTML 7.1. HTML
[I-D.iab-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 be rendered from the XML file; it will not be
format. derived from the plain-text publication 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 on a limited basis. It will not be o JavaScript will be supported on a limited basis. It will not be
skipping to change at page 8, line 34 skipping to change at page 8, line 41
7.2. PDF 7.2. PDF
[I-D.iab-rfc-use-of-pdf] - Describes the tags and profiles that will [I-D.iab-rfc-use-of-pdf] - Describes the tags and profiles that will
be used to create the new PDF format, including both the internal be used to create the new PDF format, including both the internal
structure and the visible layout of the file. A review of the structure and the visible layout of the file. A review of the
different versions of PDF is offered, with a recommendation of what different versions of PDF is offered, with a recommendation of what
PDF standard should apply to RFCs. PDF standard should apply to RFCs.
Key points regarding the PDF output: Key points regarding the PDF output:
o The PDF file will not be derived from the plain-text publication o The PDF file will be rendered from the XML file; it will not be
format. derived from the plain-text publication format.
o The PDF publication format will conform to the PDF/A-3 standard o The PDF publication format will conform to the PDF/A-3 standard
and will embed the canonical XML source. and will embed the canonical XML source.
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
skipping to change at page 11, line 26 skipping to change at page 11, line 36
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, though they are strongly encouraged to do so; plain-text will format, though they are strongly encouraged to do so; plain-text will
also remain an option for the foreseeable future. However, documents also remain an option for the foreseeable future. However, documents
submitted as plain-text cannot include such features as SVG artwork. submitted as plain-text cannot include such features as SVG artwork.
The RPC will generate an XML file if necessary for basic processing
and subsequent rendering into the approved output formats.
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 12, line 33 skipping to change at page 12, line 43
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
14.1. draft-iab-rfc-framework-00 to -01 14.1. draft-iab-rfc-framework-03 to -04
Introduction: editorial changes
Clarified that submitted plain text will be converted to XML by the
RPC; the XML will be used to render all output formats.
14.2. draft-iab-rfc-framework-02 to -03
HTML output: clarified expectations around use of JavaScript.
14.3. draft-iab-rfc-framework-01 to -02
Introduction: Removed some unnecessary history.
14.4. draft-iab-rfc-framework-00 to -01
Decision Making Process: noted taht other XML schemas and Decision Making Process: noted taht other XML schemas and
vocabularies were considered by the design team vocabularies were considered by the design team
XML for RFCs: "boilerplate at time of publication" XML for RFCs: "boilerplate at time of publication"
HTML: clarified that JavaScript should not impact readability of the HTML: clarified that JavaScript should not impact readability of the
document as it looked at time of publication document as it looked at time of publication
15. References 15. References
 End of changes. 15 change blocks. 
22 lines changed or deleted 44 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/