[要約] RFC 6949は、RFCシリーズの形式要件と将来の開発に関するガイドラインです。その目的は、RFCの一貫性と品質を確保し、将来の改善と進化を促進することです。
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 6949 RFC Series Editor
Updates: 2223 N. Brownlee
Category: Informational Independent Submissions Editor
ISSN: 2070-1721 May 2013
RFC Series Format Requirements and Future Development
RFCシリーズ形式の要件と将来の開発
Abstract
概要
This document describes the current requirements and requests for enhancements for the format of the canonical version of RFCs. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes. The requirements described in this document will determine what changes will be made to RFC format. This document updates RFC 2223.
このドキュメントでは、RFCの正規バージョンの形式の拡張に関する現在の要件と要求について説明します。用語は、フォーマット変更のために議論されているドキュメント作成のどの段階を明確にするのに役立つように定義されています。このドキュメントで説明されている要件によって、RFC形式にどのような変更が加えられるかが決まります。このドキュメントはRFC 2223を更新します。
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 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション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/rfc6949.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6949で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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 ....................................................2
1.1. Terminology ................................................3
2. History and Goals ...............................................4
2.1. Issues Driving Change ......................................5
2.1.1. ASCII Art ...........................................5
2.1.2. Character Encoding ..................................6
2.1.3. Pagination ..........................................7
2.1.4. Reflowable Text .....................................8
2.1.5. Metadata and Tagging ................................8
2.2. Further Considerations .....................................9
2.2.1. Creation and Use of RFC-Specific Tools ..............9
2.2.2. Markup Language ....................................10
2.3. RFC Editor Goals ..........................................10
3. Format Requirements ............................................10
3.1. Original Requirements to Be Retained ......................10
3.2. Requirements to Be Added ..................................11
3.3. Requirements to Be Retired ................................12
4. Security Considerations ........................................13
5. Informative References .........................................13
6. Acknowledgements ...............................................13
1 Introduction
1はじめに
Over 40 years ago, the RFC Series began as a collection of memos in an environment that included handwritten RFCs, typewritten RFCs, RFCs produced on mainframes with complicated layout tools, and more. As the tools changed and some of the source formats became unreadable, the core individuals behind the Series realized that a common format that could be read, revised, and archived long in the future was required. US-ASCII was chosen for the encoding of characters, and after a period of variability, a well-defined presentation format was settled upon. That format has proved to be persistent and reliable across a large variety of devices, operating systems, and editing tools. That stability has been a continuing strength of the Series. However, as new technology, such as small devices and advances in display technology, comes into common usage, there is a growing desire to see the format of the RFC Series adapt to take advantage of these different ways to communicate information.
40年以上前、RFCシリーズは手書きのRFC、タイプライターのRFC、複雑なレイアウトツールを備えたメインフレームで作成されたRFCなどを含む環境でメモのコレクションとして始まりました。ツールが変更され、一部のソース形式が読めなくなったとき、シリーズの背後にいる中心的な個人は、将来的に読み取り、改訂、およびアーカイブできる共通の形式が必要であることを認識しました。文字のエンコーディングにはUS-ASCIIが選択され、一定期間変動した後、明確に定義された表示形式が決定されました。このフォーマットは、さまざまなデバイス、オペレーティングシステム、編集ツールにわたって永続的で信頼できることが証明されています。その安定性はシリーズの継続的な強みです。ただし、小型デバイスやディスプレイテクノロジーの進歩などの新しいテクノロジーが一般的に使用されるようになると、RFCシリーズの形式がこれらのさまざまな方法で情報を伝達するために適応することを望む要望が高まっています。
Since the format stabilized, authors and readers have suggested enhancements to the format. However, no suggestion developed clear consensus in the Internet technical community. As always, some individuals see no need for change, while others press strongly for specific enhancements.
フォーマットが安定して以来、著者と読者はフォーマットの拡張を提案してきました。ただし、インターネット技術コミュニティで明確なコンセンサスを形成した提案はありません。いつものように、変更の必要がないと考える人もいれば、特定の機能強化を強く求める人もいます。
This document takes a look at the current requirements for RFCs as described in RFC 2223 [RFC2223] and more recently in 2223bis [2223bis]. Section 2 reviews recent requests for enhancements as understood from community discussion and various proposals for new formats including HTML, XML, PDF, and EPUB. The actual requirements are then captured in Section 3. The focus of this document is on the Canonical format of RFCs, but some mention of other phases in the RFC publication process and the document formats associated with these phases is also included. Terms are defined to help clarify exactly which stages of document production are under discussion for format changes.
このドキュメントでは、RFC 2223 [RFC2223]と、最近では2223bis [2223bis]で説明されているように、RFCの現在の要件について説明します。セクション2では、コミュニティのディスカッションや、HTML、XML、PDF、EPUBを含む新しいフォーマットのさまざまな提案から理解されるように、最近の機能強化のリクエストをレビューします。実際の要件は、セクション3に記載されています。このドキュメントでは、RFCの正規形式に焦点を当てていますが、RFC公開プロセスの他のフェーズと、これらのフェーズに関連するドキュメント形式についても触れています。用語は、フォーマット変更のために議論されているドキュメント作成のどの段階を明確にするのに役立つように定義されています。
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 * Currently: formatted plain text
正規形式：ドキュメントの承認、認識、承認、およびアーカイブされたバージョン*現在：書式設定されたプレーンテキスト
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 * Currently published by the RFC Editor: formatted plain text, PDF of the formatted plain text, PDF that contains figures (rare) * Currently made available by other sites: HTML, PDF, others
公開形式：公開プロセスの完了後に読み取ったり印刷したりできる表示および配布形式*現在RFCエディターによって公開されています：書式付きプレーンテキスト、書式付きプレーンテキストのPDF、図を含むPDF（まれ）*現在利用可能他のサイト：HTML、PDF、その他
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 (see Section 2.3 for an explanation of current practice) * Currently: XML (optional), nroff (required)
改訂可能な形式：出版物形式に変換するための情報を提供する形式。これは、RFCエディターによって使用または作成されます（現在の慣行の説明についてはセクション2.3を参照）*現在：XML（オプション）、nroff（必須）
Submission format: the format submitted to the RFC Editor for editorial revision and publication * Currently: formatted plain text (required), XML (optional), nroff (optional)
提出形式：編集および改訂のためにRFC Editorに提出された形式*現在：書式設定されたプレーンテキスト（必須）、XML（オプション）、nroff（オプション）
Below are the current RFC format rules as defined in [RFC2223] and clarified in 2223bis.
以下は、[RFC2223]で定義され、2223bisで明確にされた現在のRFC形式の規則です。
* The character codes are ASCII.
* 文字コードはASCIIです。
* Each page must be limited to 58 lines followed by a form feed on a line by itself.
* 各ページは58行に制限する必要があり、その後に1行だけのフォームフィードが続きます。
* Each line must be limited to 72 characters followed by carriage return and line feed.
* 各行は72文字に制限され、その後に改行と改行が続きます。
* No overstriking (or underlining) is allowed.
* 重ね打ち（または下線）は許可されていません。
* These "height" and "width" constraints include any headers, footers, page numbers, or left-side indenting.
* これらの「高さ」および「幅」の制約には、ヘッダー、フッター、ページ番号、または左側のインデントが含まれます。
* Do not fill the text with extra spaces to provide a straight right margin.
* 直線の右マージンを提供するために、テキストに余分なスペースを入れないでください。
* Do not do hyphenation of words at the right margin.
* 右マージンで単語のハイフネーションを行わないでください。
* Do not use footnotes. If such notes are necessary, put them at the end of a section, or at the end of the document.
* 脚注は使用しないでください。そのような注記が必要な場合は、セクションの最後または文書の最後に付けてください。
* Use single spaced text within a paragraph, and one blank line between paragraphs.
* 段落内ではスペースを空けたテキストを使用し、段落の間には空白行を1つ入れます。
* Note that the number of pages in a document and the page numbers on which various sections fall will likely change with reformatting. Thus, cross-references in the text by section number usually are easier to keep consistent than cross-references by page number.
* 文書のページ数と、さまざまなセクションが配置されるページ番号は、再フォーマットによって変わる可能性があることに注意してください。したがって、セクション番号によるテキスト内の相互参照は、通常、ページ番号による相互参照よりも一貫性を保つ方が簡単です。
* RFCs in plain ASCII text may be submitted to the RFC Editor in e-mail messages (or as online files) in either the finished Publication format or in nroff. If you plan to submit a document in nroff please consult the RFC Editor first.
* プレーンASCIIテキストのRFCは、完成したPublication形式またはnroffのいずれかで、電子メールメッセージで（またはオンラインファイルとして）RFCエディターに送信できます。 nroffでドキュメントを送信する場合は、最初にRFCエディタを参照してください。
The precedent for additional formats, specifically PostScript, is described in RFC 2223 and has been used for a small number of RFCs:
追加のフォーマット、特にPostScriptの前例はRFC 2223で説明されており、少数のRFCで使用されています。
Note that since the ASCII text version of the RFC is the primary version, the PostScript version must match the text version. The RFC Editor must decide if the PostScript version is "the same as" the ASCII version before the PostScript version can be published.
RFCのASCIIテキストバージョンがプライマリバージョンであるため、PostScriptバージョンはテキストバージョンと一致する必要があります。 RFCエディタは、PostScriptバージョンを公開する前に、PostScriptバージョンがASCIIバージョンと「同じ」かどうかを判断する必要があります。
Neither RFC 2223 nor 2223bis uses the term 'metadata', though the RFC Editor currently refers to components of the text such as the Stream, Status (e.g., Updates, Obsoletes), Category, and ISSN as 'metadata'.
RFC 2223も2223bisも「メタデータ」という用語を使用していませんが、RFCエディターは現在、ストリーム、ステータス（更新、廃止など）、カテゴリ、ISSNなどのテキストのコンポーネントを「メタデータ」と呼んでいます。
While some authors and readers of RFCs report that they find the strict limits of character encoding, line limits, and so on to be acceptable, others claim to find those limitations a significant obstacle to their desire to communicate and read the information via an RFC. With a broader community of authors currently producing RFCs and a wider range of presentation devices in use, the issues being reported by the community indicate limitations of the current Canonical format that must be reviewed and potentially addressed in the Canonical RFC format.
RFCの作成者や読者の中には、文字エンコーディングや行制限などの厳しい制限は許容できると考えていると報告していますが、RFCを介して情報をやり取りしたり読んだりするには、これらの制限が重大な障害だと主張する人もいます。現在RFCを作成し、使用しているプレゼンテーションデバイスの範囲が広い著者コミュニティにより、コミュニティから報告されている問題は、現在のCanonical形式の制限を示しており、Canonical RFC形式で検討および対処する必要がある可能性があります。
While the specific points of concern vary, the main issues discussed are:
懸念事項はさまざまですが、主な問題は次のとおりです。
* ASCII art
* アスキーアート
* Character encoding
* 文字コード
* Pagination
* ページネーション
* Reflowable text
* リフロー可能なテキスト
* Metadata
* メタデータ
Each area of concern has people in favor of change and people opposed to it, all with reasonable concerns and requirements. Below is a summary of the arguments for and against each major issue. These points are not part of the list of requirements; they are the inputs that informed the requirements discussed in Section 3 of this document.
関心のある各領域には、変化を支持する人々とそれに反対する人々がおり、すべて合理的な懸念と要件を持っています。以下は、それぞれの主要な問題に対する賛成論と反対論の要約です。これらのポイントは、要件のリストの一部ではありません。これらは、このドキュメントのセクション3で説明されている要件を通知した入力です。
Arguments in favor of limiting all diagrams, equations, tables, and charts to ASCII art depictions only include:
すべての図、方程式、表、およびチャートをASCIIアート描写に限定することを支持する議論には、次のものだけが含まれます。
* Dependence on advanced diagrams (or any diagrams) causes accessibility issues.
* 高度な図（または任意の図）に依存すると、アクセシビリティの問題が発生します。
* Requiring ASCII art results in people often relying more on clear written descriptions rather than just the diagram itself.
* ASCIIアートを要求すると、人々はしばしば、ダイアグラム自体だけでなく、明確に書かれた説明に頼ることになります。
* Use of the ASCII character set forces design of diagrams that are simple and concise.
* ASCII文字セットを使用すると、シンプルで簡潔な図を強制的に設計できます。
Arguments in favor of allowing the use of more complex diagrams in place of the current use of ASCII art include:
ASCIIアートの現在の使用の代わりに、より複雑な図の使用を許可することを支持する議論には、以下が含まれます。
* State diagrams with multiple arrows in different directions and labels on the lines will be more understandable.
* さまざまな方向に複数の矢印があり、線にラベルが付いた状態図がよりわかりやすくなります。
* Protocol flow diagrams in which each step needs multiple lines of description will be clearer.
* 各ステップで複数行の説明が必要なプロトコルフロー図が明確になります。
* Scenario descriptions that involve three or more parties with communication flows between them will be clearer.
* 3人以上の関係者が関与するシナリオの説明では、両者間にコミュニケーションフローがあります。
* Given the difficulties in expressing complex equations with common mathematical notation, allowing graphic art would allow equations to be displayed properly.
* 一般的な数学的表記で複雑な方程式を表現することの難しさを考えると、グラフィックアートを許可すると、方程式を適切に表示できます。
* Complex art could allow for grayscale or color to be introduced into the diagrams.
* 複雑なアートでは、グレースケールまたは色を図に導入することができます。
Two suggestions have been proposed regarding how graphics should be included: one that would have graphic art referenced as a separate document to the Publication format, and one that would allow embedded graphics in the Publication format.
グラフィックをどのように含めるかについて、2つの提案が提案されています。1つは、グラフィックアートをパブリケーションフォーマットとは別のドキュメントとして参照する方法、もう1つは、パブリケーションフォーマットにグラフィックを埋め込む方法です。
For most of the history of the RFC Series, the character encoding for RFCs has been ASCII. Below are arguments for keeping ASCII as well as arguments for expanding to UTF-8.
RFCシリーズの歴史のほとんどについて、RFCの文字エンコードはASCIIでした。以下は、ASCIIを維持するための引数と、UTF-8に拡張するための引数です。
Arguments for retaining the ASCII-only requirement:
ASCIIのみの要件を維持するための引数：
* It is the most easy to search and display across a variety of platforms.
* さまざまなプラットフォームで最も簡単に検索および表示できます。
* In extreme cases of having to retype or scan hard copies of documents (it has been required in the past), ASCII is significantly easier to work with for rescanning and retaining all of the original information. There can be no loss of descriptive metadata such as keywords or content tags.
* ドキュメントのハードコピーを再入力またはスキャンする必要がある極端な場合（これまでは必要でした）、ASCIIを使用すると、元の情報をすべて再スキャンして保持することが非常に簡単になります。キーワードやコンテンツタグなどの説明的なメタデータが失われることはありません。
* If we expand beyond ASCII, it will be difficult to know where to draw the line on which characters are and are not allowed. There will be issues with dependencies on local file systems and processors being configured to recognize any other character set.
* ASCIIを超えて拡張すると、文字がどこにあり、どの文字が許可されていないのか、どこに線を引くかを知るのが難しくなります。他の文字セットを認識するように構成されているローカルファイルシステムとプロセッサへの依存関係に問題があります。
* The IETF works in ASCII (and English). The Internet research, design, and development communities function almost entirely in English. That strongly suggests that an ASCII document can be properly rendered and read by everyone in the communities and audiences of interest.
* IETFはASCII（および英語）で動作します。インターネットの研究、設計、および開発コミュニティは、ほぼすべて英語で機能します。これは、コミュニティのすべての人と関心のある聴衆がASCIIドキュメントを適切にレンダリングして読み取ることができることを強く示唆しています。
Arguments for expanding to allow UTF-8:
UTF-8を許可するように拡張するための引数：
* In discussions of internationalization, actually being able to illustrate the issue is rather helpful, and you can't illustrate a Unicode code point with "U+nnnn".
* 国際化の議論では、実際に問題を説明できることはかなり役に立ち、 "U + nnnn"でUnicodeコードポイントを説明することはできません。
* It will provide the ability to denote protocol examples using the character sets those examples support.
* これらの例がサポートする文字セットを使用して、プロトコルの例を示す機能を提供します。
* It will allow better support for international character sets, in particular, allowing authors to spell their names in their native character sets.
* これにより、国際文字セットのサポートが改善され、特に、作成者はネイティブ文字セットで名前を綴ることができます。
* Certain special characters in equations or quoted from other texts could be allowed.
* 方程式の特定の特殊文字、または他のテキストから引用された特定の文字は許可されます。
* Citations of web pages using more international characters are possible.
* より多くの国際的な文字を使用したウェブページの引用が可能です。
Arguments for strictly prescribed UTF-8 use:
厳密に規定されたUTF-8使用の引数：
* In order to keep documents as searchable as possible, ASCII-only should be required for the main text of the document, and some broader UTF-8 character set allowed under clearly prescribed circumstances (e.g., author names and references).
* ドキュメントを可能な限り検索可能に保つために、ドキュメントのメインテキストにはASCIIのみが必要であり、明確に規定された状況（作成者の名前や参照など）で許可されるより広範なUTF-8文字セットが必要です。
Arguments for continuing the use of discrete pages within RFCs:
RFC内の個別のページの使用を継続するための引数：
* Ease of reference and printing; referring to section numbers is too coarse a method.
* 参照と印刷のしやすさ。セクション番号を参照するのは、方法が粗すぎる。
Arguments for removing the pagination requirement:
ページネーション要件を削除するための引数：
* Removing pagination will allow for a smoother reading experience on a wider variety of devices, platforms, and browsers.
* ページネーションを削除すると、さまざまなデバイス、プラットフォーム、ブラウザでスムーズな読書体験が可能になります。
* Removing pagination results in people often using subsections rather than page number for reference purposes, forcing what would otherwise be long sections to be broken into subsections. This would encourage documents that are better organized and simpler.
* ページネーションを削除すると、参照目的でページ番号ではなくサブセクションを使用することが多くなり、長いセクションはサブセクションに分割されます。これにより、ドキュメントがより整理され、よりシンプルになります。
Arguments against requiring text to be reflowable:
テキストをリフロー可能にすることを要求することに反対する議論：
* Reflowable text may impact the usability of graphics and tables within a document.
* リフロー可能なテキストは、ドキュメント内のグラフィックと表の使いやすさに影響を与える可能性があります。
Arguments for requiring text to be reflowable:
テキストをリフロー可能にすることを要求する引数：
* RFCs are more readable on a wider variety of devices and platforms, including mobile devices and assorted screen layouts.
* RFCは、モバイルデバイスや各種画面レイアウトなど、さまざまなデバイスやプラットフォームで読みやすくなっています。
While metadata requirements are not part of RFC 2223, there is a request that descriptive metadata tags be added as part of a revision of the Canonical RFC format. These tags would allow for enhanced content by embedding information such as links, tags, or quick translations and could help control the look and feel of the Publication format. While the lack of metadata in the current RFCs does not impact an RFC's accessibility or readability, several individuals have indicated that allowing metadata within the RFCs would make their reading of the documents more efficient.
メタデータ要件はRFC 2223の一部ではありませんが、Canonical RFC形式の改訂の一部として説明的なメタデータタグを追加するように要求されます。これらのタグを使用すると、リンク、タグ、クイック翻訳などの情報を埋め込むことでコンテンツを拡張でき、パブリケーション形式のルックアンドフィールの制御に役立ちます。現在のRFCにメタデータがなくても、RFCのアクセシビリティや可読性に影響はありませんが、RFC内のメタデータを許可すると、ドキュメントの読み取りがより効率的になると指摘する人もいます。
Arguments for allowing metadata in the Canonical and Publication formats:
CanonicalおよびPublication形式のメタデータを許可するための引数：
* Metadata potentially allows readers to get more detail out of a document. For example, if non-ASCII characters are allowed in the Author's Address and Reference sections, metadata must include translations of that information.
* メタデータにより、読者はドキュメントからより詳細な情報を得ることができます。たとえば、AuthorのAddressセクションとReferenceセクションで非ASCII文字が許可されている場合、メタデータにはその情報の翻訳を含める必要があります。
Arguments against metadata in the final Canonical and Publication formats:
最終的なCanonicalおよびPublication形式のメタデータに対する議論：
* Metadata adds additional overhead to the overall process of creating RFCs and may complicate future usability as a result of requiring backward compatibility for metadata tags.
* メタデータは、RFCを作成するプロセス全体に追加のオーバーヘッドを追加し、メタデータタグの下位互換性を必要とする結果として、将来のユーザビリティを複雑にする可能性があります。
Some of the discussion beyond the issues described above went into a review of potential solutions. Those solutions and the debate around them added a few more points to the list of potential requirements for a change in RFC Format. In particular, the discussion of tools introduced the idea of whether a change in format should also include the creation and ongoing support of specific RFC authoring and/or rendering tools and whether the Canonical format should be a format that must go through a rendering agent to be readable.
上記の問題を超えた議論のいくつかは、可能性のある解決策のレビューに入りました。これらのソリューションとそれらをめぐる議論により、RFC形式の変更に関する潜在的な要件のリストにさらにいくつかのポイントが追加されました。特に、ツールの説明では、フォーマットの変更に特定のRFCオーサリングツールやレンダリングツールの作成と継続的なサポートも含める必要があるかどうか、および正規フォーマットがレンダリングエージェントを介して読みやすい。
Arguments in support of community-supported RFC-specific tools:
コミュニティでサポートされているRFC固有のツールをサポートするための引数：
* Given the community that would be creating and supporting these tools, there would be greater control and flexibility over the tools and how they implement the RFC format requirements.
* これらのツールを作成およびサポートするコミュニティが与えられれば、ツールの制御と柔軟性が向上し、RFC形式の要件をどのように実装するかが決まります。
* Community-supported tools currently exist and are in extensive use within the community, so it would be most efficient to build on that base.
* コミュニティでサポートされているツールが現在存在し、コミュニティ内で広く使用されているため、そのベースで構築するのが最も効率的です。
Arguments against community-supported RFC-specific tools:
コミュニティでサポートされているRFC固有のツールに対する反対意見：
* We cannot be so unique in our needs that we can't use commercial tools.
* 私たちは、商用ツールを使用できないほど、ニーズがユニークであることはありません。
* Ongoing support for these tools adds a greater level of instability to the ongoing availability of the RFC Series through the decades.
* これらのツールに対する継続的なサポートは、RFCシリーズの数十年にわたる継続的な可用性に、より高いレベルの不安定性を追加します。
* The community that would support these tools cannot be relied on to be as stable and persistent as the Series itself.
* これらのツールをサポートするコミュニティは、シリーズ自体のように安定していて永続的であるとは限りません。
Arguments in support of a markup language as the Revisable format:
改訂可能な形式としてのマークアップ言語をサポートする引数：
* Having a markup language such as XML or HTML allows for greater flexibility in creating a variety of Publication formats, with a greater likelihood of similarity between them.
* XMLやHTMLなどのマークアップ言語を使用すると、さまざまなパブリケーションフォーマットをより柔軟に作成でき、それらが類似している可能性が高くなります。
Arguments against a markup language as the Revisable format:
改訂可能な形式としてのマークアップ言語に対する議論：
* Having the Revisable format be in a markup language instead of in a simple text-formatting structure ties us in to specific tools and/or tool support going forward.
* 改訂可能な形式を単純なテキスト形式の構造ではなくマークアップ言語にすることで、今後の特定のツールやツールサポートにつながります。
Currently, each RFC has an nroff file created prior to publication. For RFCs revised using an XML file, the nroff file is created by converting XML to nroff at the final step. As more documents are submitted with an XML file (of the RFCs published in 2012, approximately 65% were submitted with an XML file), this conversion is problematic in terms of time spent and data lost from XML. Making the publication process for the RFC Editor more efficient is strongly desired.
現在、各RFCには、公開前に作成されたnroffファイルがあります。 XMLファイルを使用して改訂されたRFCの場合、nroffファイルは、最終ステップでXMLをnroffに変換することによって作成されます。 （2012年に公開されたRFCのうち、約65％がXMLファイルで提出された）XMLファイルでより多くのドキュメントが送信されるため、この変換は、費やされた時間とXMLから失われたデータの点で問題があります。 RFC Editorの公開プロセスをより効率的にすることが強く望まれています。
Understanding the major pain points and balancing them with the expectation of long-term viability of the documents brings us to a review of what must be kept of the original requirements, what new requirements may be added, and what requirements may be retired. Detailed rules regarding how these changes will be implemented will be documented in a future RFC.
主要な問題点を理解し、それらをドキュメントの長期的な実行可能性の期待とバランスさせることで、元の要件から何を維持する必要があるか、どの新しい要件を追加できるか、どの要件を廃止するかを検討できます。これらの変更の実装方法に関する詳細なルールは、将来のRFCで文書化されます。
Several components of the original format requirements must be retained to ensure the ongoing continuity, reliability, and readability of the Series:
シリーズの継続的な継続性、信頼性、読みやすさを保証するために、元のフォーマット要件のいくつかのコンポーネントを保持する必要があります。
1. The content of an RFC must not change, regardless of format, once published.
1. RFCの内容は、一度公開された形式に関係なく、変更してはなりません。
2. The Canonical format must be persistent and reliable across a large variety of devices, operating systems, and editing tools for the indefinite future. This means the format must be both readable and editable across commonly used devices, operating systems, and platforms for the foreseeable future.
2. Canonical形式は、多種多様なデバイス、オペレーティングシステム、および編集ツールにわたって永続的で信頼性があり、無期限に使用できる必要があります。つまり、このフォーマットは、近い将来に一般的に使用されるデバイス、オペレーティングシステム、およびプラットフォーム全体で読み取り可能かつ編集可能である必要があります。
3. While several Publication formats must be allowed, in order to continue support for the most basic reading and search tools and to provide continuity for the Series, at least one Publication format must be plain text.
3. いくつかの出版物フォーマットを許可する必要がありますが、最も基本的な読み取りおよび検索ツールのサポートを継続し、シリーズに継続性を提供するために、少なくとも1つの出版物フォーマットはプレーンテキストである必要があります。
4. The boilerplate and overall structure of the RFC must be in accordance with current RFC and Style Guide requirements (see [RFC5741]).
4. RFCの定型文および全体的な構造は、現在のRFCおよびスタイルガイドの要件に準拠している必要があります（[RFC5741]を参照）。
Issues such as overstriking, page justification, hyphenation, and spacing will be defined in the RFC Style Guide [Style].
重ね打ち、ページの位置揃え、ハイフネーション、スペースなどの問題は、RFCスタイルガイド[スタイル]で定義されます。
In addition to those continuing requirements, discussions with various members of the wider Internet community have yielded the following general requirements for the RFC Series.
これらの継続的な要件に加えて、より広範なインターネットコミュニティのさまざまなメンバーとの議論により、RFCシリーズに関する次の一般的な要件が生じました。
5. The documents must be made accessible to people with visual disabilities through such means as including alternative text for images and limiting the use of color. See the W3C's accessibility documents [WCAG20] and the United Nations "Convention on the Rights of Persons with Disabilities" [UN2006] for guidance. Appropriate authoring tools are highly desirable but focus on the creation of Internet-Drafts, a topic outside the scope of the RFC Editor.
5. 画像の代替テキストを含めたり、色の使用を制限したりするなどの手段によって、視覚障害を持つ人々がドキュメントにアクセスできるようにする必要があります。ガイダンスについては、W3Cのアクセシビリティドキュメント[WCAG20]および国連「障害者の権利に関する条約」[UN2006]を参照してください。適切なオーサリングツールは非常に望ましいですが、RFCエディターの範囲外のトピックであるインターネットドラフトの作成に重点を置いています。
6. The official language of the RFC Series is English. ASCII is required for all text that must be read to understand or implement the technology described in the RFC. Use of non-ASCII characters, expressed in a standard Unicode Encoding Form (such as UTF-8), must receive explicit approval from the document stream manager and will be allowed after the rules for the common use cases are defined in the Style Guide.
6. RFCシリーズの公式言語は英語です。 RFCに記載されているテクノロジーを理解または実装するために読み取る必要があるすべてのテキストには、ASCIIが必要です。標準のUnicodeエンコーディングフォーム（UTF-8など）で表される非ASCII文字の使用は、ドキュメントストリームマネージャーから明示的な承認を受ける必要があり、一般的な使用例のルールがスタイルガイドで定義された後に許可されます。
7. The Submission and Publication formats need to permit extending the set of metadata tags, for the addition of labeled metadata. A predefined set of metadata tags must be created to make use of metadata tags consistent for the life of the Series.
7. ラベル付きメタデータを追加するために、Submission and Publicationフォーマットは、メタデータタグのセットの拡張を許可する必要があります。シリーズの存続期間中一貫したメタデータタグを使用するには、事前定義されたメタデータタグのセットを作成する必要があります。
8. Graphics may include ASCII art and a more complex form to be defined, such as SVG line art [SVG]. Color and grayscale will not be accepted. RFCs must correctly display in monochromatic black-and-white to allow for monochrome displays, black-and-white printing, and support for visual disabilities.
8. グラフィックには、ASCIIアートと、SVGラインアート[SVG]などのより複雑なフォームを含めることができます。カラーとグレースケールは受け入れられません。 RFCは、モノクロディスプレイ、白黒印刷、および視覚障害のサポートを可能にするために、モノクロ白黒で正しく表示する必要があります。
9. The Canonical format must be renderable into self-contained Publication formats in order to be easily downloaded and read offline.
9. Canonical形式は、簡単にダウンロードしてオフラインで読み取るために、自己完結型のPublication形式にレンダリングできる必要があります。
10. Fixed-width fonts and non-reflowable text are required for ASCII-art sections, source code examples, and other places where strict alignment is required.
10. ASCIIアートセクション、ソースコードの例、および厳密な配置が必要なその他の場所には、固定幅フォントとリフローできないテキストが必要です。
11. At least one Publication format must support readable print to standard paper sizes.
11. 少なくとも1つの出版物フォーマットは、標準の用紙サイズへの読み取り可能な印刷をサポートする必要があります。
12. The Canonical format should be structured to enable easy program identification and parsing of code or specifications, such as MIB modules and ABNF.
12. Canonical形式は、MIBモジュールやABNFなど、プログラムの識別とコードまたは仕様の解析を簡単に行えるように構成する必要があります。
The requirements of the RFC Editor regarding RFC format and the publication process include:
RFC形式と公開プロセスに関するRFCエディターの要件は次のとおりです。
13. The final conversion of all submitted documents to nroff should be replaced by using an accepted Revisable format throughout the process.
13. 提出されたすべてのドキュメントの最終的なnroffへの変換は、プロセス全体で、承認された改訂可能な形式を使用して置き換える必要があります。
14. In order to maintain an efficient publication process, the RFC Editor must work with the minimal number of files required for each submission (not a tar ball of several discrete components).
14. 効率的な公開プロセスを維持するために、RFCエディターは、各送信に必要な最小限の数のファイル（複数の個別のコンポーネントのtarボールではない）を使用する必要があります。
15. In order to maintain the focus of the RFC Editor on editing for clarity and consistency rather than document layout details, the number of Publication formats produced by the RFC editor must be limited.
15. ドキュメントレイアウトの詳細ではなく、明確さと一貫性を保つために編集にRFCエディターの焦点を維持するために、RFCエディターによって生成されるパブリケーションフォーマットの数を制限する必要があります。
16. Tools must support error checking against document layout issues as well as other format details (diagrams, line breaks, variable- and fixed-width fonts).
16. ツールは、ドキュメントレイアウトの問題やその他の形式の詳細（図、改行、可変幅および固定幅フォント）に対するエラーチェックをサポートする必要があります。
Some of the original requirements will be removed from consideration, but detailed rules regarding how these changes will be implemented will be documented in a future RFC.
元の要件の一部は考慮から外されますが、これらの変更の実装方法に関する詳細なルールは、将来のRFCに文書化される予定です。
* Pagination ("Each page must be limited to 58 lines followed by a form feed on a line by itself.")
* ページネーション（「各ページは58行に制限され、その後に改行が続くだけである必要があります。」）
* Maximum line length ("Each line must be limited to 72 characters followed by carriage return and line feed.")
* 最大行長（「各行は72文字に制限され、その後に復帰と改行が続く必要があります。」）
* Limitation to 100% ASCII text ("The character codes are ASCII.")
* 100％ASCIIテキストへの制限（「文字コードはASCIIです。」）
This document sets out requirements for RFCs in their various formats; it does not concern interactions between Internet hosts. Therefore, it does not have any specific security considerations.
このドキュメントでは、RFCの要件をさまざまな形式で説明しています。インターネットホスト間の相互作用には関係しません。したがって、セキュリティに関する特別な考慮事項はありません。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2223] Postel、J。およびJ. Reynolds、「RFC Authorsへの指示」、RFC 2223、1997年10月。
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009.
[RFC5741] Daigle、L.、Ed。、Kolkman、O.、Ed。、and IAB、 "RFC Streams、Headers、and Boilerplates"、RFC 5741、December 2009。
[ASCII] American National Standard for Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII), ANSI X3.4-1986, American National Standards Institute, Inc., March 26, 1986.
[ASCII] American National Standard for Information Systems-コード化文字セット-7ビットAmerican National Standard Code for Information Interchange（7-Bit ASCII）、ANSI X3.4-1986、American National Standards Institute、Inc.、1986年3月26日。
[2223bis] Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", Work in Progress, August 2004.
[2223bis]レイノルズ、J。およびR.ブレーデン、「コメント（RFC）の作成者に依頼するための指示」、作業中、2004年8月。
[Style] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in Progress, October 2012.
[スタイル]フラナガン、H.、S。ギノザ、「RFCスタイルガイド」、作業中、2012年10月。
[SVG] Dahlstrom, E., Dengler, P., Grasso, A., Lilley, C., McCormack, C., Schepers, D., and J. Watt, "Scalable Vector Graphics (SVG) 1.1 (Second Edition)", W3C Recommendation, 16 August 2011, <http://www.w3.org/TR/SVG11/>.
[SVG] Dahlstrom、E.、Dengler、P.、Grasso、A.、Lilley、C.、McCormack、C.、Schepers、D。、およびJ. Watt、「Scalable Vector Graphics（SVG）1.1（Second Edition） "、W3C勧告、2011年8月16日、<http://www.w3.org/TR/SVG11/>。
[WCAG20] Caldwell, B., Cooper, M., Reid, L., and G. Vanderheiden, "Web Content Accessibility Guidelines (WCAG) 2.0", 11 December 2008, <http://www.w3.org/TR/WCAG20/>.
[WCAG20] Caldwell、B.、Cooper、M.、Reid、L。、およびG. Vanderheiden、「Web Content Accessibility Guidelines（WCAG）2.0」、2008年12月11日、<http://www.w3.org/TR / WCAG20 />。
[UN2006] United Nations, "Convention on the Rights of Persons with Disabilities", December 2006.
[UN2006]国連、「障害者の権利に関する条約」、2006年12月。
The authors received a great deal of helpful input from the community in pulling together these requirements and wish to particularly acknowledge the help of Joe Hildebrand, Paul Hoffman, and John Klensin, who each published an Internet-Draft on the topic of potential format options before the IETF 84 BOF.
著者は、これらの要件をまとめる上でコミュニティから多くの有益な意見を受け取り、特にそれぞれが潜在的なフォーマットオプションのトピックに関するインターネットドラフトを公開したJoe Hildebrand、Paul Hoffman、およびJohn Klensinの助けを認めたいと思います。 IETF 84 BOF。
Authors' Addresses
著者のアドレス
Heather Flanagan RFC Series Editor
ヘザーフラナガンRFCシリーズエディター
EMail: rse@rfc-editor.org
Nevil Brownlee Independent Submissions Editor
Nevil Brownlee Independent Submissions Editor
EMail rfc-ise@rfc-editor.org
メールrfc-ise@rfc-editor.org