[要約] RFC 7990は、RFCのフォーマットとフレームワークに関するガイドラインです。その目的は、RFCの一貫性と可読性を向上させることです。
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.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
"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-ANNOUNCE]の形式の変更を検討することを決定しました。このドキュメントは、解決される問題を説明するフレームワークとして機能し、フォーマットの変更の各側面の特定の要件を取り込む、これまでに作成されたドキュメントを要約します。
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の発行に対する主要な変更が強調表示され、SeriesをプレーンテキストのASCIIのみの形式から新しい形式に移行する移行計画がrfc-interestメーリングリスト[RFC-INTEREST]で説明されています。
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-Dにも同様の一連の問題と懸念事項がありますが、I-Dのこれらの問題への直接の対処については、各ドキュメントストリーム内で説明します。
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]、少なくとも5か国からの個人が過去5年間に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 Editorに提出されるフォーマット
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 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].
要件、使用例、懸念事項、および提案は、RFC形式を更新するために、プロジェクトのすべての段階で関心のあるコミュニティから収集されました。入力は、rfc-interestメーリングリスト、およびIETFミーティングでの複数の対面セッションを通じて受信されました。 IETF、IRTF、IAB、IAOCの議長、および独立ストリームエディターと定期的に会話を行い、高レベルのストリーム要件について話し合いました。 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 Next General（RELAX NG）の標準言語モデルを支持して、XML文書型定義（DTD）の使用をやめる決定が含まれていました。このチームの隔週の呼び出しは設計チームのメンバーに限定されていましたが、このチームによって作成されたドキュメントに記載されている決定のレビューは、rfc-interestメーリングリストへのフィードバックのリクエストを通じて公に行われました。 xml2rfc v2 [RFC7749]とv3 [RFC7991]のドキュメントやSVGプロファイル[RFC7996]を含む、設計チームによって作成されたドキュメントのいくつかは、承認されるプロセスを開始する前に初期GenARTレビュー[GEN-ART]を通じて送信されましたIABストリームによって。
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]での参加者との非公式な議論、およびTERENAネットワーキング会議2014 [TNC2014]やNORDUnet 2014 [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.
召喚状への応答に関する懸念に対応し、法的要件を理解するために、RFCに対する召喚状の要求に応答する際にどの形式が合理的であると見なされるかについて、IETFトラストの法務チームにアドバイスを求めました。
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 regarding their experience with supporting one or more non-plain-text formats for their standards.
他のいくつかの標準開発組織（SDO）がプレーンテキストドキュメントを提供せず、実際にそれらの標準に複数のフォーマットを提供する可能性があることを考慮して、1つ以上の非プレーンテキストをサポートした経験について非公式の意見を求めました標準のフォーマット。
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 Series Oversight Committee [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 Editorは、公開時に作成されたプレーンテキストファイルとPDF-from-textフォーマット以外にも責任があります。 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は、エラッタやその他のメタデータへのポインタを提供するJavaScriptを含む、RFCの最も柔軟な機能セットを提供することに重点を置いています。可能な場合は既存のツールチェーン、およびこの形式で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の公開前には正式に文書化されていませんでした。よりシンプルなエクスペリエンスと著者向けの追加機能を可能にするためにボキャブラリーを変更する必要があるものを理解するために、現在の語彙は完全に説明する必要がありました。 RFC 7749は[RFC7991]によって廃止されます。
[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 プレーンテキストのパブリケーションフォーマットのウィドウとオーファンコントロール[TYPOGRAPHY]は、レンダリングコードを作成する開発者には優先権がありません。
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の文法、構造、および内容に焦点を合わせて、可能な限り多くのページフォーマット情報を削除しました。ただし、推奨される変更の一部は、XML v3の語彙に基づいています。
[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]は、「HyperText Markup Language Request for Comments Format」で言及されている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 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.
I-Dレビューおよび承認プロセス中に、作成者およびストリーム承認機関は、提案された新しい公開プロセスを実行するドラフトを選択します。 RFCエディターは、xml2rfc v2を使用して公開が承認された後、これらのドキュメントを処理し、同時にxml2rfc v3プロセスとツールを使用して選択されたI-Dをテストします。この間に公開された最終的な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 Production Center（RPC）がテストと品質保証（QA）に費やす時間を制限するために、それらの優先事項はドキュメントの編集と公開です。したがって、このステージを進めるためには、コミュニティの支援が必要です。 RFCエディターのWebサイトにあるメーリングリストと実験的なソースディレクトリは、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.
成功は、RPCとツール開発チームが致命的であると特定したすべてのバグのクローズと、XML語彙と公開用の最終出力ファイルの準備についてコミュニティとの大まかなコンセンサスに達することによって評価されます。パブリケーション形式は必要に応じて再パブリッシュされる可能性があるため、実際のレンダリングエンジンはさらにレビューと反復を行うことができます。
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アートワークなどの機能を含めることはできません。 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 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.
移行のこの時点での既知のリスクは、RPCから必要なリソースを定量化することが難しいことです。このフェーズでは、少なくとも6か月間、新旧両方の発行プロセスをサポートするために、RPCの側でさらに作業が必要になります。 RFCの利用者は、現時点で完全な出力セットを備えて公開されているドキュメントを見つける一方で、古いドキュメントはプレーンテキストしかないため、混乱の可能性があります。ファイルを正規形式および関連する公開形式に変換する前に修正する必要がある新しいバグが見つかったため、公開が遅れる可能性があります。
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。、「The "xml2rfc" Version 2 Vocabulary」、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。、「The "xml2rfc" Version 3 Vocabulary」、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]ヒルデブランド、J。、エド。および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。、「Requires for Plain-Text RFCs」、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.、and M. Hardy、 "PDF Format for RFCs"、RFC 7995、DOI 10.17487 / RFC7995、December 2016、<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。、「The Use of Non-ASCII Characters in RFCs」、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。インターネットアーキテクチャボード、「Process for Publication of IAB RFCs」、RFC 4845、DOI 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。、編、Halpern、J。、編、およびIAB、「RFC Editor Model（Version 2）」、RFC 6635、DOI 10.17487 / RFC6635、2012年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。、and O. Kolkman、Ed。、 "RFC Streams、Headers、and Boilerplates"、RFC 7841、DOI 10.17487 / RFC7841、May 2016、<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] American National Standards Institute、「Coded Character Set-7-bit American Standard Code for Information Interchange」、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、「General Area Review Team（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。、「IETF 84 Proceedings：RFC Format（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 Proceedings：RFC Format（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 Proceedings：RFC Format（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 Proceedings：RFC Format（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 Proceedings：RFC Format（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]「28th NORDUnet Conference 2014」、2014、<https://events.nordu.net/display/NORDU2014/ BoF％27s + and + side + meetings>。
[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-interest> 。
[RNC] Clark, J., "RELAX NG Compact Syntax", OASIS , November 2002, <http://www.oasis-open.org/committees/relax-ng/ compact-20021121.html>.
[RNC] Clark、J。、「RELAX NG Compact Syntax」、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 Editor Program：The RSOC」、<http://www.iab.org/activities/programs/ rfc-editor-program />。
[TNC2014] Flanagan, H., "IETF Update - 'What's Hot?' - RFC Update", 2014, <https://tnc2014.terena.org/core/presentation/84>.
[TNC2014] Flanagan、H。、「IETF Update-'What's Hot？' -RFC Update "、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>.
[TYPOGRAPHY] Butterick、M。、「Butterick's Practical Typography」、<http://practicaltypography.com/ widow-and-orphan-control.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-interestメーリングリストへのメッセージ、2013年5月、<http：//www.rfc-editor。 org / pipermail / rfc-interest / 2013-May / 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