Editorial Stream P. Hoffman
Request for Comments: 9720 ICANN
Obsoletes: 7990 H. Flanagan
Updates: 9280 Spherical Cow Consulting
Category: Informational January 2025
ISSN: 2070-1721
In order to improve the readability of RFCs while supporting their archivability, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. This document describes how RFCs are published.
RFCの読みやすさをサポートしながら改善するために、RFCシリーズの決定的なバージョンは、RFCXML語彙を使用してプレーンテキストASCIIからXMLに遷移しました。そのベースドキュメントから異なる出版バージョンがレンダリングされています。このドキュメントでは、RFCの公開方法について説明します。
This document obsoletes RFC 7990. This document also updates the stability policy in RFC 9280.
このドキュメントはRFC 7990を廃止します。このドキュメントは、RFC 9280の安定性ポリシーも更新します。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the RFC Series Policy Definition Process. It represents the consensus of the RFC Series Working Group approved by the RFC Series Approval Board. Such documents are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、RFCシリーズポリシー定義プロセスの製品です。これは、RFCシリーズ承認委員会によって承認されたRFCシリーズワーキンググループのコンセンサスを表しています。このような文書は、インターネット標準のレベルの候補ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9720.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9720で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
1.1. Changes to RFC 7990
1.2. Changes to RFC 9280
1.3. Key Changes from the Earlier RFC Process
2. Definitive Version of an RFC
2.1. Updating the Definitive Version of an RFC
2.2. Expected Updates to RFCXML
3. Publication Versions
4. Archived Documents
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
"RFC Series Format Requirements and Future Development" [RFC6949] discussed 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 discussions with communities of interest, such as the IETF, the RFC Series Editor decided to explore a change to the format of the Series. [RFC7990] was the culmination of that exploration.
「RFCシリーズ形式の要件と将来の開発」[RFC6949]は、RFCの著者名やアートワークなどのアイテムの表示を改善する必要性と、RFCがさまざまなデバイスで適切に表示される能力を向上させる必要性について議論しました。IETFなどの関心のあるコミュニティとの議論に基づいて、RFCシリーズエディターは、シリーズの形式の変更を探ることを決定しました。[RFC7990]はその探査の集大成でした。
This document is concerned with the production of RFCs, focusing on the published documents. It does not address any changes to the processes each stream uses to develop and review their submissions (specifically, how Internet-Drafts are developed). While I-Ds have a similar set of issues and concerns, directly addressing those issues for I-Ds should be discussed within each document stream.
このドキュメントは、公開されたドキュメントに焦点を当てたRFCの生産に関係しています。各ストリームが使用するプロセスの変更には、提出物（特にインターネットドラフトの開発方法）を開発およびレビューするために使用しません。I-DSには同様の問題と懸念がありますが、I-DSの問題に直接対処することは、各ドキュメントストリーム内で議論する必要があります。
The details described in this document are expected to continue to change over time as the community and the RFC Production Center (RPC) gain further experience implementing the policies described here.
このドキュメントに記載されている詳細は、コミュニティとRFC生産センター（RPC）がここで説明されているポリシーの実装経験がさらに得られるにつれて、時間の経過とともに変化し続けると予想されます。
Implementors of these components are advised to avoid assuming that all such changes will be backwards compatible.
これらのコンポーネントの実装者は、そのようなすべての変更が逆方向に互換性があると仮定することを避けることをお勧めします。
[RFC7990] defined a framework for how RFCs would be published, including new "publication formats" and a new "canonical format". It talked about "the XML file" as if there would only be one XML file for an RFC because that was the expectation at the time [RFC7990] was published. It also talked about "publication formats" as the versions of HTML, plain text, and PDF derived from the "canonical format".
[RFC7990]は、新しい「出版形式」や新しい「標準形式」など、RFCがどのように公開されるかについてのフレームワークを定義しました。「XMLファイル」について話しました。まるでRFCには1つのXMLファイルしか存在しないかのように、それは[RFC7990]が公開された時点であったためです。また、「標準形式」から派生したHTML、プレーンテキスト、およびPDFのバージョンとして「出版形式」についても説明しました。
After extensive experience with publishing RFCs in the RFCXML format [RFC7991], it has been decided that an RFC's XML file can be updated for narrowly limited purposes. This document changes [RFC7990] in significant ways:
RFCXML形式[RFC7991]でRFCを公開した豊富な経験の後、RFCのXMLファイルを狭く限られた目的で更新できることが決定されました。このドキュメントは、[RFC7990]を重要な方法で変更します。
* It defines four terms that replace the use of the term "canonical" and clarifies "format":
* 「Canonical」という用語の使用を置き換え、「形式」を明確にする4つの用語を定義します。
- The "definitive format", which is RFCXML
- RFCXMLである「決定的な形式」
- The "definitive version", which is a published RFC in the definitive format
- 決定的な形式で公開されているRFCである「Definitiveバージョン」
- A "publication format", which is currently one of HTML, plain text, and PDF
- 現在HTML、プレーンテキスト、PDFの1つである「出版形式」
- A "publication version", which is a published RFC in one of the publication formats
- 出版形式の1つで公開されているRFCである「出版バージョン」
* It defines a policy governing how the RFCXML format changes.
* RFCXML形式の変更方法を管理するポリシーを定義します。
* It defines a policy for when the definitive version of an RFC can be updated and older definitive versions archived.
* RFCの決定的なバージョンを更新し、アーカイブされた古い決定的なバージョンをいつ更新できるかについてのポリシーを定義します。
* It defines a policy for when the publication versions of an RFC can be updated and older publication versions archived.
* RFCの出版バージョンを更新し、アーカイブされた古い出版物バージョンをいつ更新できるかについてのポリシーを定義します。
When using the new terminology, it is important to note that [RFC7990] used the term "canonical format" to mean two very different things. Quoting from RFC 7990:
新しい用語を使用する場合、[RFC7990]は「標準形式」という用語を使用して2つの非常に異なるものを意味することに注意することが重要です。RFC 7990からの引用：
Canonical format: the authorized, recognized, accepted, and archived version of the document
標準形式：ドキュメントの承認、認識、受け入れ、アーカイブされたバージョン
and
そして
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.
最高レベルでは、RFC形式に加えられている変更には、ASCIIプレーンテキストのみから脱却し、ドキュメントをさまざまな出版形式にするために必要なすべての情報を含む標準形式に移動することが含まれます。
This document uses two terms, "definitive version" and "definitive format", for the earlier term "canonical format".
このドキュメントでは、以前の用語「Canonical Format」に「Definitiveバージョン」と「Definitive Format」という2つの用語を使用します。
This document also makes the following terminology changes:
また、このドキュメントは次の用語の変更を行います。
* It changes the phrase "xml2rfc version 3" to "RFCXML".
* 「XML2RFCバージョン3」というフレーズを「RFCXML」に変更します。
* It changes the name of the body that publishes RFCs from "RFC Editor" to "RFC Production Center" (RPC).
* RFCを「RFCエディター」から「RFC生産センター」（RPC）に公開する本体の名前を変更します。
Historical text from [RFC7990], such as Section 2 ("Problem Statement"), Section 4 ("Overview of the Decision-Making Process"), and Section 10 ("Transition Plan"), was purposely omitted from this document. Text from [RFC7990] that repeated what was in other RFCs, particularly Section 8 ("Figures and Artwork") and Section 9 ("Content and Page Layout"), was also removed.
[RFC7990]の履歴テキスト、セクション2（「問題声明」）、セクション4（「意思決定プロセスの概要」）、セクション10（「移行計画」）は、このドキュメントから意図的に省略されました。他のRFC、特にセクション8（「図とアートワーク」）とセクション9（「コンテンツとページレイアウト」）にあるものを繰り返した[RFC7990]のテキストも削除されました。
Section 7.6 of [RFC9280] says:
[RFC9280]のセクション7.6は次のように述べています。
Once published, RFC Series documents are not changed.
公開されると、RFCシリーズドキュメントは変更されません。
This document replaces that sentence with:
このドキュメントは、その文を次のように置き換えます。
Once published, RFCs may be reissued, but the semantic content of publication versions shall be preserved to the greatest extent possible.
公開されると、RFCは再発行される場合がありますが、出版バージョンのセマンティックコンテンツは可能な限り保存されます。
This document also adds a new policy to Section 7 of [RFC9280]:
このドキュメントは、[RFC9280]のセクション7に新しいポリシーを追加します。
7.8. Consistency
7.8. 一貫性
RFCs are copyedited, formatted, and then published. They may be reissued to maintain a consistent presentation.
RFCはコピー編集、フォーマット、および公開されます。一貫したプレゼンテーションを維持するために再発行される場合があります。
Sections 2.1 and 3 in this document are based on this policy in [RFC9280].
このドキュメントのセクション2.1および3は、[RFC9280]のこのポリシーに基づいています。
The first RFC to be published following the guidance of the group of RFCs described in [RFC7990] was [RFC8651], published in October 2019. In the time since then, all published RFCs have followed the general plan from [RFC7990].
[RFC7990]に記載されているRFCのグループのガイダンスに従って公開された最初のRFCは[RFC8651]である[RFC8651]でした。それ以来、公開されたすべてのRFCは[RFC7990]から一般計画に従っています。
At the highest level, the changes that [RFC7990] made to the RFC format involved breaking away from solely ASCII [RFC20] plain text and moving to a definitive format that includes all the information required for rendering a document into a wide variety of publication formats. The RPC became responsible for more than just the plain-text file and a PDF rendering that was created from the plain text at the time of publication; the RPC now creates the definitive version and three publication versions of the RFC in order to meet the diverse requirements of the community.
最高レベルでは、[RFC7990]がRFC形式に対して行った変更は、ASCII [RFC20]プレーンテキストのみから離れることと、ドキュメントをさまざまな出版形式にするために必要なすべての情報を含む決定的な形式に移行することを含みました。。RPCは、公開時にプレーンテキストから作成されたプレーンテキストファイルとPDFレンダリング以上のものを担当しました。RPCは、コミュニティの多様な要件を満たすために、RFCの決定的なバージョンと3つの出版バージョンを作成するようになりました。
The final RFCXML file produced by the RPC is the definitive version for RFCs; it holds all the information intended for an RFC. Additional publication versions (HTML, plain text, and PDF) are also published by the RPC. The publication formats are fully specified in other RFCs.
RPCによって作成された最終的なRFCXMLファイルは、RFCSの決定的なバージョンです。RFC向けのすべての情報を保持します。追加の出版バージョン（HTML、プレーンテキスト、およびPDF）もRPCによって公開されています。出版形式は、他のRFCで完全に指定されています。
The definitive version produced by the RPC holds all the information intended for an RFC. The RPC may change the definitive version of an RFC over time (that is, change the XML file), as described in Section 2.1. See [RFC7991] for the original complete description of RFCXML.
RPCによって作成された決定的なバージョンは、RFC向けのすべての情報を保持します。RPCは、セクション2.1で説明されているように、時間の経過とともにRFCの決定的なバージョン（つまり、XMLファイルを変更）を変更する場合があります。RFCXMLの元の完全な説明については、[RFC7991]を参照してください。
The XML may contain SVG line art, as originally described in [RFC7996]. That SVG will also appear in the HTML publication version. The XML may contain non-ASCII characters, as originally described in [RFC7997]. These characters will appear in all the publication versions.
XMLには、元々[RFC7996]で説明されているように、SVGラインアートが含まれている場合があります。そのSVGは、HTML Publicationバージョンにも表示されます。XMLには、[RFC7997]で最初に説明されているように、非ASCII文字が含まれている場合があります。これらの文字は、すべての出版物バージョンに表示されます。
The definitive version must contain all information necessary to render the specified publication versions; any question about what was intended in the publication will be answered from this file. It is self-contained with all the semantic content known at publication time. For instance, all features that reference externally defined input are expanded. It does not contain src attributes for <artwork> or <sourcecode> elements. It does not contain comments or processing instructions.
決定的なバージョンには、指定された出版物バージョンをレンダリングするために必要なすべての情報を含める必要があります。出版物で何が意図されていたかについての質問は、このファイルから回答されます。これは、出版時に知られているすべてのセマンティックコンテンツと自己完結型です。たとえば、外部から定義された入力を参照するすべての機能が展開されます。<Artwork>または<Sourcode>要素のSRC属性は含まれていません。コメントや処理手順は含まれていません。
RFCs may be reissued, as described in Section 1.2. Such changes must preserve the semantics expressed in the original RFC. Reasons to make such changes include updates to the RFCXML schema, errors discovered in the XML, and changes to the tooling used to generate the publication versions of the definitive version of the RFC. The RPC will keep a public record of when it reissues any RFC and give a short description of its reasoning for each change.
セクション1.2で説明されているように、RFCは再発行される場合があります。このような変更は、元のRFCで表現されたセマンティクスを保存する必要があります。このような変更を加える理由には、RFCXMLスキーマの更新、XMLで発見されたエラー、RFCの決定的なバージョンの出版バージョンを生成するために使用されるツールの変更が含まれます。RPCは、RFCを再発行するときの公開記録を保持し、各変更に対するその推論の簡単な説明を提供します。
It is anticipated that [RFC7991] will be updated. Updates to the RFCXML specification that are applied to existing RFCs should preserve the semantics expressed in the original RFC to the greatest extent possible. The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the published document.
[RFC7991]が更新されると予想されます。既存のRFCに適用されるRFCXML仕様の更新は、元のRFCで表現されたセマンティクスを可能な限り最大限に保持する必要があります。変更を構文のみに制限するという目標は、公開されたドキュメントにエンコードされた意味的な意味を保存することです。
This policy does not require that updates to RFCXML avoid all risk of introducing semantic changes to existing RFCs. Instead, considering the potential for semantic changes, taking steps to understand the risk of a semantic change (either deliberate or inadvertent), and limiting associated risks are the only requirements.
このポリシーでは、RFCXMLの更新が既存のRFCにセマンティック変更を導入するリスクをすべて回避することを要求していません。代わりに、セマンティックの変化の可能性を考慮し、セマンティックの変化のリスクを理解するための措置を講じ（意図的または不注意で）、関連するリスクを制限することが唯一の要件です。
The RPC is permitted but not required to reissue publication versions of an RFC, as described in Section 1.2. In deciding whether to update the publication versions of an RFC, the RPC will take into account both the risk of semantic changes and consistency of the Series.
セクション1.2で説明されているように、RPCは許可されていますが、RFCの出版バージョンを再発行する必要はありません。RFCの出版バージョンを更新するかどうかを決定する際に、RPCはセマンティックの変更のリスクとシリーズの一貫性の両方を考慮します。
XML format errors and better design choices have been discovered by the community since the first RFCs were published using the RFCXML format. When the XML in a definitive version changes, the publication versions may change, even if this might not result in observable differences. Similarly, as production tools change, publication versions may be regenerated to ensure a consistent presentation.
XML形式のエラーとより良い設計の選択肢は、RFCXML形式を使用して最初のRFCが公開されて以来、コミュニティによって発見されました。決定的なバージョンのXMLが変更されると、これが観察可能な違いにつながらない場合でも、出版バージョンが変更される場合があります。同様に、生産ツールが変更されるにつれて、一貫したプレゼンテーションを確保するために出版バージョンを再生することができます。
The RPC will keep an archived set of all definitive versions of RFCs as well as archived sets of the publication versions for an RFC that were previously published. These archived sets must be available using the same access methods as for current definitive and publication versions. Every archived set shall record the date that a definitive and/or publication version was created or reissued.
RPCは、RFCのすべての決定的なバージョンのアーカイブされたセットと、以前に公開されたRFCの出版バージョンのアーカイブセットを保持します。これらのアーカイブセットは、現在の決定的および出版バージョンと同じアクセス方法を使用して使用できる必要があります。すべてのアーカイブセットは、決定的および/または公開バージョンが作成または再発行された日付を記録するものとします。
When the RPC archives definitive and publication versions, it does so in a manner that allows them to be found by people who want the historical (as compared to current) files.
RPCアーカイブの決定的なバージョンと出版バージョンの場合、歴史的な（現在と比較して）ファイルを望む人々がそれらを見つけることができるようにします。
This document does not specify how archives are maintained or how archived documents might be located or identified. The methods for storage and access will be determined by the RPC in consultation with the technical community.
このドキュメントでは、アーカイブの維持方法、またはアーカイブされたドキュメントがどのように配置または識別されるかを指定していません。ストレージとアクセスの方法は、技術コミュニティと協議してRPCによって決定されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
Allowing changes to the definitive version and publication versions of RFCs introduces risks. A significant risk is that unintended changes could occur in either the definitive version or publication versions of an RFC as a result of an editing error. In addition, unintended changes may be introduced into a publication version when it is regenerated from the definitive version. This may result in the corruption of a standard, practice, or critical piece of information about a protocol, which may harm the reputation of the RFC Series.
RFCSの決定的なバージョンと出版バージョンの変更を許可すると、リスクが導入されます。重大なリスクは、編集エラーの結果としてRFCの決定的なバージョンまたは出版バージョンのいずれかで意図しない変更が発生する可能性があることです。さらに、決定的なバージョンから再生されると、意図しない変更が出版バージョンに導入される場合があります。これにより、RFCシリーズの評判を損なう可能性のあるプロトコルに関する標準、実践、または重要な情報の腐敗が生じる可能性があります。
The RPC is expected to identify, track, and actively mitigate risks introduced by this new policy.
RPCは、この新しいポリシーによって導入されたリスクを特定、追跡、および積極的に軽減することが期待されています。
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
RFC 7991, DOI 10.17487/RFC7991, December 2016,
<https://www.rfc-editor.org/info/rfc7991>.
[RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
RFC 7996, DOI 10.17487/RFC7996, December 2016,
<https://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,
<https://www.rfc-editor.org/info/rfc7997>.
[RFC9280] Saint-Andre, P., Ed., "RFC Editor Model (Version 3)",
RFC 9280, DOI 10.17487/RFC9280, June 2022,
<https://www.rfc-editor.org/info/rfc9280>.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
Requirements and Future Development", RFC 6949,
DOI 10.17487/RFC6949, May 2013,
<https://www.rfc-editor.org/info/rfc6949>.
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990,
DOI 10.17487/RFC7990, December 2016,
<https://www.rfc-editor.org/info/rfc7990>.
[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link
Exchange Protocol (DLEP) Control-Plane-Based Pause
Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019,
<https://www.rfc-editor.org/info/rfc8651>.
Martin Thomson wrote a great deal of the significant text here as part of draft-thomson-rswg-syntax-change-01.
マーティン・トムソンは、ドラフト・トムソン-RSWG-syntax-change-01の一部として、ここで重要なテキストの多くを書いた。
This document has greatly benefited from the input of the RSWG. In particular, Alexis Rossi, Brian Carpenter, Eliot Lear, Jay Daley, Jean Mahoney, John Levine, and Pete Resnick provided significant input on the early draft versions of this document.
このドキュメントは、RSWGの入力から大きな恩恵を受けています。特に、Alexis Rossi、Brian Carpenter、Eliot Lear、Jay Daley、Jean Mahoney、John Levine、およびPete Resnickは、このドキュメントの初期ドラフトバージョンに重要な情報を提供しました。
Paul Hoffman
ICANN
Email: paul.hoffman@icann.org
Heather Flanagan
Spherical Cow Consulting
Email: hlf@sphericalcowconsulting.com