Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7990 RFC Editor
Category: Informational December 2016
ISSN: 2070-1721
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7990 RFC Editor
Category: Informational December 2016
ISSN: 2070-1721
RFC Format Framework
RFC格式框架
Abstract
摘要
In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication formats will be rendered from that base document. With these changes comes an increase in complexity for authors, consumers, and the publisher of RFCs. This document serves as the framework that provides the problem statement, lays out a road map of the documents that capture the specific requirements, and describes the transition plan.
为了提高RFC的可读性，同时支持其可归档性，RFC系列的规范格式将使用xml2rfc版本3词汇表从纯文本ASCII转换为XML；将从该基础文档呈现不同的发布格式。随着这些变化，RFC的作者、消费者和发布者的复杂性增加。本文档作为一个框架，提供了问题陈述，列出了捕获特定需求的文档路线图，并描述了过渡计划。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7990.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7990.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the Decision-Making Process . . . . . . . . . . . 4
5. Key Changes . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Canonical Format Documents . . . . . . . . . . . . . . . . . 6
6.1. XML for RFCs . . . . . . . . . . . . . . . . . . . . . . 6
7. Publication Format Documents . . . . . . . . . . . . . . . . 8
7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. Potential Future Publication Formats . . . . . . . . . . 9
7.4.1. EPUB . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 9
8.1. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Content and Page Layout . . . . . . . . . . . . . . . . . . . 10
9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 10
9.2. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 10
9.3. CSS Requirements . . . . . . . . . . . . . . . . . . . . 10
10. Transition Plan . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Statement of Work and RFP for Tool Development . . . . . 10
10.2. Testing and Transition . . . . . . . . . . . . . . . . . 10
10.3. Completion . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of the Decision-Making Process . . . . . . . . . . . 4
5. Key Changes . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Canonical Format Documents . . . . . . . . . . . . . . . . . 6
6.1. XML for RFCs . . . . . . . . . . . . . . . . . . . . . . 6
7. Publication Format Documents . . . . . . . . . . . . . . . . 8
7.1. HTML . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.3. Plain Text . . . . . . . . . . . . . . . . . . . . . . . 9
7.4. Potential Future Publication Formats . . . . . . . . . . 9
7.4.1. EPUB . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Figures and Artwork . . . . . . . . . . . . . . . . . . . . . 9
8.1. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Content and Page Layout . . . . . . . . . . . . . . . . . . . 10
9.1. Non-ASCII Characters . . . . . . . . . . . . . . . . . . 10
9.2. Style Guide . . . . . . . . . . . . . . . . . . . . . . . 10
9.3. CSS Requirements . . . . . . . . . . . . . . . . . . . . 10
10. Transition Plan . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Statement of Work and RFP for Tool Development . . . . . 10
10.2. Testing and Transition . . . . . . . . . . . . . . . . . 10
10.3. Completion . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 13
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
"RFC Series Format Requirements and Future Development" [RFC6949] discusses the need to improve the display of items such as author names and artwork in RFCs as well as the need to improve the ability of RFCs to be displayed properly on various devices. Based on the discussions with communities of interest, such as the IETF, the RFC Series Editor decided to explore a change to the format of the Series [XML-ANNOUNCE]. This document serves as the framework that describes the problems being solved and summarizes the documents created to-date that capture the specific requirements for each aspect of the change in format.
“RFC系列格式要求和未来发展”[RFC6949]讨论了改进RFC中作者姓名和艺术品等项目显示的必要性，以及改进RFC在各种设备上正确显示的能力的必要性。基于与感兴趣的社区（如IETF）的讨论，RFC系列编辑决定探索对系列[XML-RENENCE]格式的更改。本文档作为一个框架，描述了正在解决的问题，并总结了迄今为止创建的文档，这些文档捕获了格式更改各个方面的特定需求。
Key changes to the publication of RFCs are highlighted, and a transition plan that will take the Series from a plain text, ASCII-only format to the new formats is described on the rfc-interest mailing list [RFC-INTEREST].
突出显示了rfc出版物的关键变化，rfc兴趣邮件列表[rfc-interest]中描述了将本系列从纯文本、ASCII格式转换为新格式的过渡计划。
This document is concerned with the production of RFCs, focusing on the published formats. It does not address any changes to the processes each stream uses to develop and review their submissions (specifically, how Internet-Drafts will be developed). While I-Ds have a similar set of issues and concerns, directly addressing those issues for I-Ds will be discussed within each document stream.
本文件涉及RFC的制作，重点关注已发布的格式。它不涉及每个流用于开发和审查其提交内容的流程的任何更改（特别是如何开发互联网草稿）。虽然I-Ds有一组类似的问题和顾虑，但直接解决I-Ds的这些问题将在每个文档流中讨论。
The details described in this document are expected to change based on experience gained in implementing the new publication toolsets. Revised documents will be published capturing those changes as the toolsets are completed. Other implementers must not expect those changes to remain backwards compatible with the details described in this document.
本文档中描述的详细信息预计将根据在实施新发布工具集过程中获得的经验进行更改。修订后的文档将在工具集完成后发布，以捕获这些更改。其他实施者不得期望这些更改与本文档中描述的细节保持向后兼容。
There are nearly three billion people connected to the Internet [ISTATS] and individuals from at least 45 countries have regularly attended IETF meetings over the last five years. The Internet is now global, and while the world has changed from when the first RFCs were published, the Series remains critical to defining protocols, standards, best practices, and more for this global network that continues to grow. In order to make RFCs easily viewable to the largest number of people possible, across a wide array of devices, and to respect the diversity of authors and reference materials while still recognizing the archival aspects of the Series, it is time to update the tightly prescribed format of the RFC Series.
近30亿人连接到互联网[ISTATS]，在过去五年中，至少45个国家的个人定期参加IETF会议。互联网现在是全球化的，虽然世界从第一个RFC发布时起已经发生了变化，但该系列对于定义协议、标准、最佳实践以及这个持续增长的全球网络的更多方面仍然至关重要。为了使尽可能多的人能够在各种设备上轻松查看RFC，并尊重作者和参考资料的多样性，同时仍然认识到该系列的档案方面，现在是更新严格规定的RFC系列格式的时候了。
All changes to the format of the RFC Series must be made with consideration to the requirements of a wide set of communities over an extended length of time. Examples of the preferences and specific needs are those of existing authors and implementers, lawyers that argue Intellectual Property Rights (IPR), educators, managers, and policymakers that need to know what to list in potential Request for Proposals (RFPs) for their organizations. The immediate needs of today's communities must be balanced with the needs for long-term archival storage.
对RFC系列格式的所有更改必须考虑到一系列社区在较长时间内的要求。偏好和具体需求的例子包括现有作者和实施者、主张知识产权（IPR）的律师、教育工作者、管理者和决策者，他们需要知道在其组织的潜在征求建议书（RFP）中列出哪些内容。当今社区的迫切需要必须与长期存档存储的需要相平衡。
This document uses terminology from RFC 6949, repeated below for convenience.
本文件使用RFC 6949中的术语，为方便起见，重复如下。
ASCII: Coded Character Set - 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986 [ASCII]
ASCII：编码字符集.信息交换用7位美国标准代码，ANSI X3.4-1986[ASCII]
Canonical format: the authorized, recognized, accepted, and archived version of the document
规范格式：文档的授权、认可、接受和存档版本
Metadata: information associated with a document so as to provide, for example, definitions of its structure, or of elements within the document such as its topic or author
元数据：与文档相关联的信息，例如提供文档结构或文档中元素（如主题或作者）的定义
Publication format: display and distribution format as it may be read or printed after the publication process has completed
出版物格式：出版过程完成后可阅读或打印的显示和分发格式
Reflowable text: text that automatically wraps to the next line in a document as the user moves the margins of the text, either by resizing the window or changing the font size
可回流文本：当用户移动文本边距时，通过调整窗口大小或更改字体大小，自动换行到文档中的下一行的文本
Revisable format: the format that will provide the information for conversion into a Publication format; it is used or created by the RFC Editor
可修改格式：提供信息以转换为出版物格式的格式；它由RFC编辑器使用或创建
Submission format: the format submitted to the RFC Editor for editorial revision and publication
提交格式：提交给RFC编辑进行编辑修订和出版的格式
Requirements, use cases, concerns, and suggestions were collected from the communities of interest at every stage of the project to update the RFC format. Input was received through the rfc-interest mailing list, as well as in several face-to-face sessions at IETF meetings. Regular conversations were held with the Chairs of the IETF, IRTF, IAB, and IAOC as well as the Independent Stream Editor to discuss high-level stream requirements. Updates regarding the status
在项目的每个阶段，从感兴趣的社区收集需求、用例、关注点和建议，以更新RFC格式。通过rfc兴趣邮件列表以及IETF会议上的几次面对面会议收到了输入。定期与IETF、IRTF、IAB和IAOC的主席以及独立的流编辑器进行对话，讨论高层流需求。关于状态的更新
of the project were provided to the IETF community during the IETF Technical Plenary as well as Format BoFs or IAB sessions at several IETF meetings [IETF84] [IETF85] [IETF88] [IETF89] [IETF90].
在IETF技术全体会议期间以及在几个IETF会议[IETF84][IETF85][IETF88][IETF89][IETF90]上的格式BOF或IAB会议期间，向IETF社区提供了该项目的信息。
The output from the first year of discussion on the topic of RFC format was published as RFC 6949, which provided the first solid documentation on the requirements for the Series. RFC 6949 is a product of the IAB stream (following the process described in "Process for Publication of IAB RFCs" [RFC4845]). This is also the case with all of the RFCs that informed the format update work.
关于RFC格式主题的第一年讨论的结果发布为RFC 6949，它提供了关于该系列要求的第一份可靠文档。RFC 6949是IAB流的产物（遵循“IAB RFC发布流程”[RFC4845]中描述的流程）。所有通知格式更新工作的RFC也是如此。
After the high-level requirements were published, the RFC Series Editor (RSE) brought together an RFC Format Design Team to start working out the necessary details to develop the code needed to create new and changed formats. The Design Team discussed moving away from the existing xml2rfc vocabulary, but with such a strong existing support base within the community and no clear value with other XML vocabularies or schemas, the decision was made to work with the xml2rfc version 2 (xml2rfc v2) [RFC7749] model and use it as the base for the new format environment. Part of this discussion included a decision to stop using an XML document type definition (DTD) in favor of a Regular Language for XML Next General (RELAX NG) model using a defined vocabulary. While the biweekly calls for this team were limited to Design Team members, review of the decisions as documented in the documents produced by this team was done publicly through requests for feedback on the rfc-interest mailing list. Several of the documents produced by the Design Team, including those on xml2rfc v2 [RFC7749] and v3 [RFC7991] and the SVG profile [RFC7996], were sent through an early GenART review [GEN-ART] before starting the process to be accepted by the IAB stream.
高级需求发布后，RFC系列编辑器（RSE）召集了一个RFC格式设计团队，开始制定必要的细节，以开发创建新格式和更改格式所需的代码。设计团队讨论了离开现有的xml2rfc词汇表的问题，但由于社区中现有的支持基础非常强大，而且对其他XML词汇表或模式没有明确的价值，因此决定使用xml2rfc版本2（xml2rfc v2）[RFC7749]模型，并将其用作新格式环境的基础。讨论的一部分包括决定停止使用XML文档类型定义（DTD），转而使用定义词汇表的XML下一个通用（RELAXNG）模型的常规语言。虽然每两周对该团队的电话仅限于设计团队成员，但通过请求rfc兴趣邮件列表上的反馈，对该团队编制的文件中记录的决策进行了公开审查。设计团队制作的一些文件，包括xml2rfc v2[RFC7749]和v3[RFC7991]以及SVG配置文件[RFC7996]上的文件，在开始IAB流接受的流程之前，通过早期GenART审查[GEN-ART]发送。
While the IETF community provided the majority of input on the process, additional outreach opportunities were sought to gain input from an even broader audience. Informal discussions were held with participants at several International Association of Scientific, Technical, and Medical Publisher events [STM], and presentations made at technical conferences such as the TERENA Networking Conference 2014 [TNC2014] and NORDUnet 2014 [NDN2014].
虽然IETF社区提供了该过程的大部分投入，但寻求更多的外联机会，以获得更广泛受众的投入。与多个国际科学、技术和医学出版商协会活动[STM]的参与者进行了非正式讨论，并在技术会议上进行了演讲，如2014年TERENA网络会议[TNC2014]和2014年NORDUnet[NDN2014]。
In order to respond to concerns regarding responses to subpoenas and to understand the legal requirements, advice was requested from the IETF Trust legal team regarding what format or formats would be considered reasonable when responding to a subpoena request for an RFC.
为了回应有关传票回复的问题并理解法律要求，请IETF信托法律团队提供建议，说明在回应RFC传票请求时，哪些格式是合理的。
Given that several other standards development organizations (SDOs) do not offer plain-text documents, and in fact may offer more than one format for their standards, informal input was sought from them
鉴于其他几个标准开发组织（SDO）不提供纯文本文档，事实上可能为其标准提供多种格式，因此需要从他们那里获得非正式的输入
regarding their experience with supporting one or more non-plain-text formats for their standards.
关于他们的标准支持一种或多种非纯文本格式的经验。
Finally, the entire process was reviewed regularly with the RFC Series Oversight Committee [RSOC] and regular updates provided to the IAB and IESG. They have offered support and input throughout the process.
最后，RFC系列监督委员会[RSOC]定期审查整个流程，并定期向IAB和IESG提供更新。他们在整个过程中提供了支持和投入。
Where consensus was not reached during the process, the RSE made any necessary final decisions, as per the guidance in "RFC Editor Model (Version 2)" [RFC6635].
如果在此过程中未达成一致意见，则RSE根据“RFC编辑器模型（版本2）”中的指南[RFC6635]做出任何必要的最终决定。
At the highest level, the changes being made to the RFC format involve breaking away from solely ASCII plain text and moving to a canonical format that includes all the information required for rendering a document into a wide variety of publication formats. The RFC Editor will become responsible for more than just the plain-text file and the PDF-from-text format created at time of publication; the RFC Editor will be creating several different formats in order to meet the diverse requirements of the community.
在最高级别上，对RFC格式所做的更改包括从单纯的ASCII纯文本转换为规范格式，该格式包含将文档转换为各种发布格式所需的所有信息。RFC编辑器将不仅仅负责发布时创建的纯文本文件和PDF格式的文本文件；RFC编辑器将创建几种不同的格式，以满足社区的不同需求。
The final XML file produced by the RFC Editor will be considered the canonical format for RFCs; it is the lowest common denominator that holds all the information intended for an RFC. PDF/A-3 will be the publication format offered in response to subpoenas for RFCs published through this new process and will be developed with an eye towards long-term archival storage. HTML will be the focus of providing the most flexible set of features for an RFC, including JavaScript to provide pointers to errata and other metadata. Plain text will continue to be offered in order to support existing tool chains, where practicable, and the individuals who prefer to read RFCs in this format.
RFC编辑器生成的最终XML文件将被视为RFC的标准格式；它是保存RFC所有信息的最低公分母。PDF/A-3将是响应通过这一新流程发布的RFC传票而提供的发布格式，并将着眼于长期档案存储而开发。HTML将是为RFC提供最灵活的特性集的重点，包括JavaScript，以提供指向勘误表和其他元数据的指针。在可行的情况下，将继续提供纯文本，以支持现有的工具链，以及喜欢阅读这种格式的RFC的个人。
Key points regarding the XML format:
关于XML格式的要点：
o The canonical format for RFCs is XML using the xml2rfc version 3 (xml2rfc v3) vocabulary. The XML file must contain all information necessary to render a variety of formats; any question about what was intended in the publication will be answered from this format.
o RFC的标准格式是使用xml2rfc版本3（xml2rfc v3）词汇表的XML。XML文件必须包含呈现各种格式所需的所有信息；任何关于出版物内容的问题都将以这种格式回答。
o Authors may submit documents using the xml2rfc v2 vocabulary, but the final publication will be converted to use the xml2rfc v3 vocabulary.
o 作者可以使用xml2rfc v2词汇表提交文档，但最终出版物将转换为使用xml2rfc v3词汇表。
o SVG is supported and will be embedded in the final XML file.
o 支持SVG，并将嵌入最终的XML文件中。
o There will be automatically generated identifiers for sections, paragraphs, figures, and tables in the final XML file.
o 在最终的XML文件中，将自动生成节、段落、图和表的标识符。
o The XML file will not contain any xml2rfc v3 vocabulary elements or attributes that have been marked deprecated.
o XML文件将不包含任何标记为已弃用的xml2rfc v3词汇表元素或属性。
o A DTD will no longer be used. The grammar will be defined using RELAX NG [RNC].
o DTD将不再使用。语法将使用RELAX NG[RNC]定义。
o The final XML file will contain, verbatim, the appropriate boilerplate as applicable at time of publication specified by RFC 7841 [RFC7841] or its successors.
o 最终XML文件将逐字包含RFC 7841[RFC7841]或其后续文件规定的发布时适用的适当样板文件。
o The final XML will be self-contained with all the information 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 <artwork> or <sourcecode> elements), include-like processing instructions, and externally defined entities.
o 最终的XML将是自包含的，包含发布时已知的所有信息。例如，所有引用外部定义输入的功能都将展开。这包括xinclude、src属性（例如在<artwork>或<sourcecode>元素中）的所有使用，包括类似的处理指令和外部定义的实体。
o The final XML will not contain comments or processing instructions.
o 最终的XML将不包含注释或处理说明。
o The final XML will not contain src attributes for <artwork> or <sourcecode> elements.
o 最终的XML将不包含<artwork>或<sourcecode>元素的src属性。
[RFC7749] describes the xml2rfc v2 vocabulary. While in wide use at the time of writing, this vocabulary had not been formally documented prior to the publication of RFC 7749. In order to understand what needed to change in the vocabulary to allow for a more simple experience and additional features for authors, the current vocabulary needed to be fully described. RFC 7749 will be obsoleted by [RFC7991].
[RFC7749]描述了xml2rfc v2词汇表。尽管在撰写本文时广泛使用，但在RFC 7749出版之前，该词汇表尚未正式记录。为了理解词汇表中需要更改哪些内容，以便为作者提供更简单的体验和附加功能，需要全面描述当前词汇表。[RFC7991]将淘汰RFC 7749。
[RFC7991] describes the xml2rfc v3 vocabulary. The design goals were to make the vocabulary more intuitive for authors and to expand the features to support the changes being made in the publication process. It obsoletes RFC 7749.
[RFC7991]描述了xml2rfc v3词汇表。设计目标是使词汇表对作者更直观，并扩展功能以支持发布过程中所做的更改。它淘汰了RFC 7749。
[RFC7992] describes the semantic HTML that will be produced by the RFC Editor from the xml2rfc v3 files.
[RFC7992]描述了RFC编辑器将从xml2rfc v3文件生成的语义HTML。
Key points regarding the HTML output:
有关HTML输出的关键点：
o The HTML will be rendered from the XML file; it will not be derived from the plain-text publication format.
o HTML将从XML文件中呈现；它不会从纯文本发布格式派生。
o The body of the document will use a subset of HTML. The documents will include Cascading Style Sheets (CSS) for default visual presentation; it can be overwritten by a local CSS file.
o 文档主体将使用HTML的子集。文档将包括用于默认视觉呈现的级联样式表（CSS）；它可以被本地CSS文件覆盖。
o SVG is supported and will be included in the HTML file.
o 支持SVG，并将包含在HTML文件中。
o Text will be reflowable.
o 文本将可回流。
o JavaScript will be supported on a limited basis. It will not be permitted to overwrite or change any text present in the rendered HTML. It may, on a limited basis, add text that provides post-publication metadata or pointers, if warranted. All such text will be clearly marked as additional.
o JavaScript将在有限的基础上得到支持。不允许覆盖或更改呈现HTML中的任何文本。它可以在有限的基础上添加提供发布后元数据或指针的文本（如果需要）。所有此类文本将明确标记为附加文本。
[RFC7995] describes the tags and profiles that will be used to create the new PDF format, including both the internal structure and the visible layout of the file. A review of the different versions of PDF is offered, with a recommendation of what PDF standard should apply to RFCs.
[RFC7995]描述了用于创建新PDF格式的标记和配置文件，包括文件的内部结构和可见布局。对PDF的不同版本进行了审查，并对RFC应采用何种PDF标准提出了建议。
Key points regarding the PDF output:
有关PDF输出的关键点：
o The PDF file will be rendered from the XML file; it will not be derived from the plain-text publication format.
o PDF文件将从XML文件中呈现；它不会从纯文本发布格式派生。
o The PDF publication format will conform to the PDF/A-3 standard and will embed the canonical XML source.
o PDF发布格式将符合PDF/A-3标准，并将嵌入规范的XML源。
o The PDF will look more like the HTML publication format than the plain-text publication format.
o PDF看起来更像HTML发布格式，而不是纯文本发布格式。
o The PDF will include a rich set of tags and metadata within the document.
o PDF将在文档中包含一组丰富的标记和元数据。
o SVG is supported and will be included in the PDF file.
o 支持SVG，并将包含在PDF文件中。
[RFC7994] describes the details of the plain-text format; in particular, it focuses on what is changing from the existing plain-text output.
[RFC7994]描述了纯文本格式的详细信息；特别是，它关注现有纯文本输出的变化。
Key points regarding the plain-text output:
关于纯文本输出的要点：
o The plain-text document will no longer be the canonical version of an RFC.
o 纯文本文档将不再是RFC的规范版本。
o The plain-text format will be UTF-8 encoded; non-ASCII characters will be allowed.
o 纯文本格式将采用UTF-8编码；将允许使用非ASCII字符。
o A Byte Order Mark (BOM) will be added at the start of each file.
o 将在每个文件的开头添加一个字节顺序标记（BOM）。
o Widow and orphan control [TYPOGRAPHY] for the plain-text publication format will not have priority for the developers creating the rendering code.
o 纯文本发布格式的寡妇和孤儿控件[排版]对于创建呈现代码的开发人员没有优先级。
o Authors may choose to have pointers to line art in other publication formats in place of ASCII art in the .txt file.
o 作者可以选择使用指向其他出版物格式的线条艺术的指针来代替.txt文件中的ASCII艺术。
o An unpaginated plain-text file will be created.
o 将创建一个未搅拌的纯文本文件。
o Running headers and footers will not be used.
o 将不使用正在运行的页眉和页脚。
This format is intended for use by ebook readers and will be available for RFCs after the requirements have been defined. No document on this topic is currently available.
此格式供电子书阅读器使用，并在定义要求后可用于RFC。目前没有关于此主题的文档。
[RFC7996] describes the profile for SVG line art. SVG is an XML-based vocabulary for creating line drawings; SVG information will be embedded within the canonical XML at the time of publication.
[RFC7996]介绍了SVG线条艺术的配置文件。SVG是用于创建线条图的基于XML的词汇表；SVG信息将在发布时嵌入到规范XML中。
There are security and readability implications to moving outside the ASCII range of characters. [RFC7997] focuses on exactly where and how non-ASCII characters may be used in an RFC, with an eye towards keeping the documents as secure and readable as possible, given the information that needs to be expressed.
超出ASCII字符范围会带来安全性和可读性方面的影响。[RFC7997]关注在RFC中使用非ASCII字符的确切位置和方式，着眼于在需要表达信息的情况下尽可能保持文档的安全性和可读性。
The RFC Style Guide [RFC7322] was revised to remove as much page formatting information as possible, focusing instead on grammar, structure, and content of RFCs. Some of the changes recommended, however, informed the XML v3 vocabulary.
对RFC样式指南[RFC7322]进行了修订，删除了尽可能多的页面格式信息，重点放在RFC的语法、结构和内容上。但是，建议的一些更改通知了XMLV3词汇表。
[RFC7993] describes how the CSS classes mentioned in "HyperText Markup Language Request for Comments Format" should be used to create an accessible and responsive design for the HTML format.
[RFC7993]描述了如何使用“超文本标记语言注释请求格式”中提到的CSS类为HTML格式创建可访问和响应的设计。
Existing tools for the creation of RFCs will need to be updated, and new tools created, to implement the updated format. As the requirements-gathering effort, described in the various documents described earlier in this document, finishes the bulk of the work, the Tools Development Team of the IETF will work with the RSE to develop Statements of Work (SoWs). Those SoWs will first be reviewed within the Tools Development Team and the Tools Management Committee, and it will then go out for a public comment period. After public review, the SoWs will be attached to an RFP and posted as per the IETF Administrative Support Activity (IASA) bid process [IASA-RFP].
需要更新用于创建RFC的现有工具，并创建新工具，以实现更新的格式。随着本文件前面所述的各种文件中所述的需求收集工作完成了大部分工作，IETF的工具开发团队将与RSE合作制定工作说明书（SOW）。这些SOW将首先在工具开发团队和工具管理委员会内部进行审查，然后将公开发表评论。公开审查后，SOW将附在RFP中，并按照IETF行政支持活动（IASA）投标流程[IASA-RFP]发布。
Once bids have been received, reviewed, and awarded, coding will begin.
一旦收到、审查和授予标书，将开始编码。
During the I-D review and approval process, authors and stream-approving bodies will select drafts to run through the proposed new publication process. The RFC Editor will process these documents after they have been approved for publication using xml2rfc v2 and will simultaneously test the selected I-Ds with the xml2rfc v3
在I-D审查和批准过程中，作者和流式审批机构将选择草稿，以在拟定的新出版过程中运行。RFC编辑器将在批准使用xml2rfc v2发布这些文档后对其进行处理，并同时使用xml2rfc v3测试选定的I-D
process and tools. While the final RFCs published during this time will continue as plain text and immutable once published, the feedback process is necessary to bootstrap initial testing. These early tests will target finding issues with the proposed xml2rfc v3 vocabulary that result in poorly formed publication formats as well as issues that prevent proper review of submitted documents.
过程和工具。虽然在这段时间内发布的最终RFC将继续以纯文本形式发布，并且一旦发布就不可更改，但反馈过程对于引导初始测试是必要的。这些早期测试的目标是发现建议的xml2rfc v3词汇表中的问题，这些问题会导致格式不良的发布格式，以及阻止对提交的文档进行适当审查的问题。
Feedback will result in regular iteration of the basic code and XML vocabulary. In order to limit the amount of time the RFC Production Center (RPC) spends on testing and quality assurance (QA), their priority will be to edit and publish documents; therefore, community assistance will be necessary to help move this stage along. A mailing list and experimental source directory on the RFC Editor website will be created for community members willing to assist in the detailed review of the XML and publication formats. Editorial checks of the publication formats by the community are out of scope; the focus will be the QA of each available output, checking for inconsistencies across formats.
反馈将导致基本代码和XML词汇表的定期迭代。为了限制RFC生产中心（RPC）花费在测试和质量保证（QA）上的时间，他们的首要任务是编辑和发布文档；因此，社区援助将有助于推动这一阶段。将在RFC编辑器网站上为愿意协助详细审查XML和出版物格式的社区成员创建邮件列表和实验源目录。社区对出版物格式的编辑检查超出范围；重点将是每个可用输出的QA，检查格式之间的不一致性。
The purpose of the testing phase is to work with the community to identify and fix bugs in the process and the code before producing canonical, immutable XML, and to collect additional feedback on the usability of the new publication formats.
测试阶段的目的是与社区合作，在生成规范的、不可变的XML之前识别并修复流程和代码中的错误，并收集关于新发布格式可用性的其他反馈。
Any modifications to the document review process, up to and including AUTH48, will happen with the community and the stream-approving bodies as we learn more about the features and outputs of the new publication tools. Defining those processes is out of scope for this document.
随着我们对新发布工具的特性和输出的更多了解，社区和流审批机构将对文档审查流程（包括AUTH48）进行任何修改。定义这些过程超出了本文档的范围。
Success will be measured by the closure of all bugs identified by the RPC and the Tools Development Team as fatal in addition to reaching rough consensus with the community on the readiness of the XML vocabulary and final output files for publication. The actual rendering engine can go through further review and iteration, as the publication formats may be republished as needed.
除了与社区就XML词汇表和最终输出文件的发布准备情况达成大致共识外，RPC和工具开发团队确定为致命的所有bug的关闭将衡量成功与否。实际的渲染引擎可以进行进一步的检查和迭代，因为发布格式可能会根据需要重新发布。
Authors are not required to submit their approved drafts to the RFC Editor in an XML format, though they are strongly encouraged to do so; plain text will also remain an option for the foreseeable future. However, documents 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.
作者不需要以XML格式向RFC编辑器提交其批准的草稿，尽管强烈鼓励他们这样做；在可预见的未来，纯文本仍然是一种选择。但是，以纯文本形式提交的文档不能包含SVG artwork等功能。如有必要，RPC将生成一个XML文件，以进行基本处理并随后呈现为批准的输出格式。
A known risk at this point of the transition is the difficulty in 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
在转换的这一点上，一个已知的风险是难以量化RPC所需的资源。这个阶段将需要RPC的更多工作来支持旧的和新的
publication processes for at least six months. There is potential for confusion as consumers of RFCs find some documents published at this time with a full set of outputs, while older documents only have 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 canonical format and associated publication formats.
至少六个月的出版过程。由于RFC的使用者发现此时发布的某些文档具有全套输出，而旧文档只有纯文本，因此可能会产生混淆。由于发现新的bug，在将文件转换为规范格式和相关发布格式之前，必须修复这些bug，因此发布可能会延迟。
Authors may submit XML (preferred) or plain-text files. The XML files submitted for publication will be converted to canonical XML format and published with all available publication formats. All authors will be expected to review the final documents as consistent with the evolving procedures for reviewing documents.
作者可以提交XML（首选）或纯文本文件。提交发布的XML文件将转换为规范XML格式，并以所有可用的发布格式发布。所有作者都将按照不断发展的文件审查程序审查最终文件。
Success for this phase will be measured by a solid understanding by the RSE and the IAOC of the necessary costs and resources required for long-term support of the new format model.
这一阶段的成功将通过RSE和IAOC对长期支持新格式模型所需的必要成本和资源的充分理解来衡量。
Changing the format for RFCs involves modifying a great number of components to publication. Understanding those changes and the implications for the entire tool chain is critical so as to avoid unintended bugs that would allow unintended changes to text. Unintended changes to text could in turn corrupt a standard, practice, or critical piece of information about a protocol.
更改RFC的格式需要修改大量组件以供发布。理解这些更改以及对整个工具链的影响是至关重要的，这样可以避免出现允许对文本进行意外更改的意外错误。对文本的意外更改可能反过来破坏协议的标准、实践或关键信息。
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <http://www.rfc-editor.org/info/rfc6949>.
[RFC6949]Flanagan，H.和N.Brownlee，“RFC系列格式要求和未来发展”，RFC 6949，DOI 10.17487/RFC6949，2013年5月<http://www.rfc-editor.org/info/rfc6949>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary", RFC 7749, DOI 10.17487/RFC7749, February 2016, <http://www.rfc-editor.org/info/rfc7749>.
[RFC7749]Reschke，J.“xml2rfc”版本2词汇表”，RFC 7749，DOI 10.17487/RFC7749，2016年2月<http://www.rfc-editor.org/info/rfc7749>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", RFC 7991, DOI 10.17487/RFC7991, December 2016, <http://www.rfc-editor.org/info/rfc7991>.
[RFC7991]Hoffman，P.“xml2rfc”版本3词汇表”，RFC 7991，DOI 10.17487/RFC7991，2016年12月<http://www.rfc-editor.org/info/rfc7991>.
[RFC7992] Hildebrand, J., Ed. and P. Hoffman, "HTML Format for RFCs", RFC 7992, DOI 10.17487/RFC7992, December 2016, <http://www.rfc-editor.org/info/rfc792>.
[RFC7992]Hildebrand，J.，Ed.和P.Hoffman，“RFC的HTML格式”，RFC 7992，DOI 10.17487/RFC7992，2016年12月<http://www.rfc-editor.org/info/rfc792>.
[RFC7993] Flanagan, H., "Cascading Style Sheets (CSS) Requirements for RFCs", RFC 7993, DOI 10.17487/RFC7993, December 2016, <http://www.rfc-editor.org/info/rfc7993>.
[RFC7993]Flanagan，H.，“RFC的级联样式表（CSS）要求”，RFC 7993，DOI 10.17487/RFC7993，2016年12月<http://www.rfc-editor.org/info/rfc7993>.
[RFC7994] Flanagan, H., "Requirements for Plain-Text RFCs", RFC 7994, DOI 10.17487/RFC7994, December 2016, <http://www.rfc-editor.org/info/rfc7994>.
[RFC7994]Flanagan，H.，“纯文本RFC的要求”，RFC 7994，DOI 10.17487/RFC7994，2016年12月<http://www.rfc-editor.org/info/rfc7994>.
[RFC7995] Hansen, T., Ed., Masinter, L., and M. Hardy, "PDF Format for RFCs", RFC 7995, DOI 10.17487/RFC7995, December 2016, <http://www.rfc-editor.org/info/rfc7995>.
[RFC7995]Hansen，T.，Ed.，Masinter，L.，和M.Hardy，“RFC的PDF格式”，RFC 7995，DOI 10.17487/RFC7995，2016年12月<http://www.rfc-editor.org/info/rfc7995>.
[RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", RFC 7996, DOI 10.17487/RFC7996, December 2016, <http://www.rfc-editor.org/info/rfc7996>.
[RFC7996]Brownlee，N.，“RFC的SVG图纸：SVG 1.2 RFC”，RFC 7996，DOI 10.17487/RFC7996，2016年12月<http://www.rfc-editor.org/info/rfc7996>.
[RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, <http://www.rfc-editor.org/info/rfc7997>.
[RFC7997]Flanagan，H.，Ed.，“RFC中非ASCII字符的使用”，RFC 7997，DOI 10.17487/RFC7997，2016年12月<http://www.rfc-editor.org/info/rfc7997>.
[RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process for Publication of IAB RFCs", RFC 4845, DOI 10.17487/RFC4845, July 2007, <http://www.rfc-editor.org/info/rfc4845>.
[RFC4845]Daigle，L.，Ed.和互联网架构委员会，“IAB RFC的发布流程”，RFC 4845DOI 10.17487/RFC4845，2007年7月<http://www.rfc-editor.org/info/rfc4845>.
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 2012, <http://www.rfc-editor.org/info/rfc6635>.
[RFC6635]Kolkman，O.，Ed.，Halpern，J.，Ed.，和IAB，“RFC编辑器模型（版本2）”，RFC 6635，DOI 10.17487/RFC66352012年6月<http://www.rfc-editor.org/info/rfc6635>.
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322, DOI 10.17487/RFC7322, September 2014, <http://www.rfc-editor.org/info/rfc7322>.
[RFC7322]Flanagan，H.和S.Ginoza，“RFC风格指南”，RFC 7322，DOI 10.17487/RFC7322，2014年9月<http://www.rfc-editor.org/info/rfc7322>.
[RFC7841] Halpern, J., Ed., Daigle, L., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, <http://www.rfc-editor.org/info/rfc7841>.
[RFC7841]Halpern，J.，Ed.，Daigle，L.，Ed.，和O.Kolkman，Ed.，“RFC流，标题和样板”，RFC 7841，DOI 10.17487/RFC78412016年5月<http://www.rfc-editor.org/info/rfc7841>.
[ASCII] American National Standards Institute, "Coded Character Set - 7-bit American Standard Code for Information Interchange", ANSI X3.4-1986, 1986.
[ASCII]美国国家标准协会，“编码字符集-信息交换用7位美国标准代码”，ANSI X3.4-1986，1986年。
[GEN-ART] IETF, "General Area Review Team (Gen-ART)", <http://www.ietf.org/iesg/directorate/gen-art.html>.
[GEN-ART]IETF，“一般区域审查小组（GEN-ART）”<http://www.ietf.org/iesg/directorate/gen-art.html>.
[IASA-RFP] IETF Administrative Support Activity, "RFPs and RFIs", <http://iaoc.ietf.org/rfps-rfis.html>.
[IASA-RFP]IETF行政支持活动，“RFP和RFI”<http://iaoc.ietf.org/rfps-rfis.html>.
[IETF84] Flanagan, H., "IETF 84 Proceedings: RFC Format (rfcform)", July 2012, <http://www.ietf.org/proceedings/84/rfcform.html>.
[IETF84]Flanagan，H.，“IETF84会议记录：RFC格式（rfcform）”，2012年7月<http://www.ietf.org/proceedings/84/rfcform.html>.
[IETF85] Flanagan, H., "IETF 85 Proceedings: RFC Format (rfcform)", November 2012, <http://www.ietf.org/proceedings/85/rfcform.html>.
[IETF85]Flanagan，H.，“IETF 85会议记录：RFC格式（rfcform）”，2012年11月<http://www.ietf.org/proceedings/85/rfcform.html>.
[IETF88] Flanagan, H., "IETF 88 Proceedings: RFC Format (rfcform)", November 2013, <http://www.ietf.org/proceedings/88/rfcform.html>.
[IETF88]Flanagan，H.，“IETF 88会议记录：RFC格式（rfcform）”，2013年11月<http://www.ietf.org/proceedings/88/rfcform.html>.
[IETF89] Flanagan, H., "IETF 89 Proceedings: RFC Format (rfcform)", March 2014, <http://www.ietf.org/proceedings/89/rfcform.html>.
[IETF89]Flanagan，H.，“IETF 89会议记录：RFC格式（rfcform）”，2014年3月<http://www.ietf.org/proceedings/89/rfcform.html>.
[IETF90] Flanagan, H., "IETF 90 Proceedings: RFC Format (rfcform)", July 2014, <http://www.ietf.org/proceedings/90/rfcform.html>.
[IETF90]Flanagan，H.，“IETF 90会议记录：RFC格式（rfcform）”，2014年7月<http://www.ietf.org/proceedings/90/rfcform.html>.
[ISTATS] "Internet Live Stats", <http://www.internetlivestats.com/internet-users/>.
[ISTATS]“互联网实时统计数据”<http://www.internetlivestats.com/internet-users/>.
[NDN2014] "28th NORDUnet Conference 2014", 2014, <https://events.nordu.net/display/NORDU2014/ BoF%27s+and+side+meetings>.
[NDN2014]“2014年第28届北欧电信会议”，2014年<https://events.nordu.net/display/NORDU2014/ BoF%27s+和+边+会议>。
[RFC-INTEREST] RFC Editor, "rfc-interest -- A list for discussion of the RFC series and RFC Editor functions.", <https://www.rfc-editor.org/mailman/listinfo/ rfc-interest>.
[RFC-INTEREST]RFC编辑器，“RFC INTEREST——讨论RFC系列和RFC编辑器功能的列表。”<https://www.rfc-editor.org/mailman/listinfo/ rfc兴趣>。
[RNC] Clark, J., "RELAX NG Compact Syntax", OASIS , November 2002, <http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[RNC]Clark，J.，“RELAXNG紧凑语法”，OASIS，2002年11月<http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>。
[RSOC] IAB, "RFC Editor Program: The RSOC", <http://www.iab.org/activities/programs/ rfc-editor-program/>.
[RSOC]IAB，“RFC编辑器程序：RSOC”<http://www.iab.org/activities/programs/ rfc编辑器程序/>。
[TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 2014, <https://tnc2014.terena.org/core/presentation/84>.
[TNC2014]弗拉纳根，H.，“IETF更新-‘什么是热门？’”-RFC更新”，2014年<https://tnc2014.terena.org/core/presentation/84>.
[STM] STM, "The global voice of scholarly publishing", <http://www.stm-assoc.org/>.
[STM]STM，“全球学术出版之声”<http://www.stm-assoc.org/>.
[TYPOGRAPHY] Butterick, M., "Butterick's Practical Typography", <http://practicaltypography.com/ widow-and-orphan-control.html>.
[排版]巴特里克，M.，“巴特里克的实用排版”<http://practicaltypography.com/ 寡妇和孤儿控件.html>。
[XML-ANNOUNCE] Flanagan, H., "Subject: [rfc-i] Direction of the RFC Format Development effort", message to the rfc-interest mailing list, May 2013, <http://www.rfc-editor.org/pipermail/rfc-interest/ 2013-May/005584.html>.
[XML-ANNOUNCE]Flanagan，H.，“主题：[rfc-i]rfc格式开发工作的方向”，发给rfc兴趣邮件列表的信息，2013年5月<http://www.rfc-editor.org/pipermail/rfc-interest/ 2013年5月/005584.html>。
IAB Members at the Time of Approval
批准时的IAB成员
The IAB members at the time this memo was approved were (in alphabetical order):
本备忘录批准时，IAB成员为（按字母顺序排列）：
Jari Arkko Ralph Droms Ted Hardie Joe Hildebrand Russ Housley Lee Howard Erik Nordmark Robert Sparks Andrew Sullivan Dave Thaler Martin Thomson Brian Trammell Suzanne Woolf
贾里·阿克科·拉尔夫·德罗姆斯·泰德·哈迪·乔·希尔德布兰德·罗斯·霍斯利·李·霍华德·埃里克·诺德马克·罗伯特·斯帕克斯·安德鲁·沙利文·戴夫·泰勒·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
With many thanks to the RFC Format Design Team for their efforts in making this transition successful: Nevil Brownlee (ISE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.
非常感谢RFC格式设计团队为成功实现这一转变所做的努力：内维尔·布朗利（ISE）、托尼·汉森、乔·希尔德布兰德、保罗·霍夫曼、特德·莱蒙、朱利安·雷什克、亚当·罗奇、爱丽丝·鲁索、罗伯特·斯帕克斯（工具团队联络员）和戴夫·泰勒。
Author's Address
作者地址
Heather Flanagan RFC Editor
希瑟·弗拉纳根RFC编辑
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220
Email: rse@rfc-editor.org
URI: http://orcid.org/0000-0002-2647-2220