[要約] RFC 7322は、RFC文書のスタイルとフォーマットに関するガイドラインです。その目的は、一貫性のある形式でRFC文書を作成し、読みやすく理解しやすいものにすることです。
Internet Architecture Board (IAB) H. Flanagan
Request for Comments: 7322 S. Ginoza
Obsoletes: 2223 RFC Editor
Category: Informational September 2014
ISSN: 2070-1721
RFC Style Guide
RFCスタイルガイド
Abstract
概要
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".
このドキュメントでは、RFCシリーズで現在使用されている基本的でユニークなスタイルの規則と編集ポリシーについて説明します。これは、RFCエディターの基本要件を取り込み、RFCのスタイルと構造に関するガイダンスを提供します。追加のガイダンスは、そのガイダンスの実験的な性質を反映し、RFCスタイルガイドに将来含めるために準備するWebサイトでキャプチャされます。このドキュメントはRFC 2223「Instructions to RFC Authors」を廃止します。
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/rfc7322.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7322で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. RFC Editor's Philosophy .........................................4
3. RFC Style Conventions ...........................................5
3.1. Language ...................................................5
3.2. Punctuation ................................................5
3.3. DNS Names and URIs .........................................6
3.4. Capitalization .............................................6
3.5. Citations ..................................................6
3.6. Abbreviation Rules .........................................7
4. Structure of an RFC .............................................8
4.1. First-Page Header ..........................................9
4.1.1. Author/Editor .......................................9
4.1.2. Organization ........................................9
4.1.3. "ISSN: 2070-1721" ..................................10
4.1.4. Updates and Obsoletes ..............................10
4.2. Full Title ................................................10
4.3. Abstract Section ..........................................11
4.4. RFC Editor or Stream Notes Section ........................11
4.5. Status of This Memo Section ...............................11
4.6. Copyright, Licenses, and IPR Boilerplate Section ..........11
4.7. Table of Contents Section .................................11
4.8. Body of the Memo .........................................12
4.8.1. Introduction Section ...............................12
4.8.2. Requirement Language Section .......................12
4.8.3. IANA Considerations Section ........................13
4.8.4. Internationalization Considerations Section ........13
4.8.5. Security Considerations Section ....................13
4.8.6. References Section .................................14
4.8.6.1. URIs in RFCs ..............................15
4.8.6.2. Referencing RFCs ..........................15
4.8.6.3. Referencing STDs and BCPs .................16
4.8.6.4. Referencing Internet-Drafts ...............17
4.8.6.5. Referencing Errata ........................18
4.8.6.6. Referencing Other Standards Development
Organizations (SDOs) ......................18
4.9. Appendices Section ........................................19
4.10. Acknowledgements Section .................................19
4.11. Contributors Section .....................................19
4.12. "Author's Address" or "Authors' Addresses" Section .......20
5. Security Considerations ........................................20
6. References .....................................................20
6.1. Normative References ......................................20
6.2. Informative References ....................................20
Appendix A. Related Procedures ....................................23
A.1. Dispute Resolution .........................................23
A.2. Returning an I-D to the Document Stream ....................23
A.3. Revising This Document and Associated Web Pages ............23
IAB Members at the Time of Approval ...............................24
Acknowledgements ..................................................24
Contributors ......................................................24
Authors' Addresses ................................................24
The ultimate goal of the RFC publication process is to produce documents that are readable, clear, consistent, and reasonably uniform. The basic formatting conventions for RFCs were established in the 1970s by the original RFC Editor, Jon Postel. This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series [RFC4844]. It is intended as a stable, infrequently updated reference for authors, editors, and reviewers.
RFC公開プロセスの最終的な目標は、読みやすく、明確で、一貫性があり、適度に均一なドキュメントを作成することです。 RFCの基本的なフォーマット規則は、元のRFCエディターであるJon Postelによって1970年代に確立されました。このドキュメントでは、RFCシリーズ[RFC4844]で現在使用されている基本的で独自のスタイル規則と編集ポリシーについて説明します。これは、作者、編集者、およびレビュー担当者向けの、安定した、まれに更新されるリファレンスとして意図されています。
The RFC Editor also maintains a web portion of the Style Guide (see Appendix A.3) that describes issues as they are raised and indicates how the RFC Editor intends to address them. As new style issues arise, the RFC Editor will first address them on the web portion of the Style Guide [STYLE-WEB]. These topics may become part of the RFC Style Guide when it is revised.
RFCエディターは、スタイルガイド（付録A.3を参照）のWeb部分も保持しており、発生した問題を説明し、RFCエディターがどのように対処するかを示しています。新しいスタイルの問題が発生すると、RFCエディターは最初にスタイルガイド[STYLE-WEB]のWeb部分でそれらに対処します。これらのトピックは改訂時にRFCスタイルガイドの一部になる可能性があります。
The world of technical publishing has generally accepted rules for grammar, punctuation, capitalization, sentence length and complexity, parallelism, etc. The RFC Editor generally follows these accepted rules as defined by the Chicago Manual of Style (CMOS) [CMOS], with a few important exceptions to avoid ambiguity in complex technical prose and to handle mixtures of text and computer languages, or to preserve historical formatting rules. This document presents these exceptions as applied or recommended by the RFC Editor.
テクニカルパブリッシングの世界では、文法、句読点、大文字、文の長さ、複雑さ、並列性などの規則が一般に受け入れられています。RFCエディターは、シカゴスタイルマニュアル（CMOS）[CMOS]で定義されているこれらの受け入れられた規則に従います。複雑な技術的文章のあいまいさを回避し、テキストとコンピューター言語の混合を処理するため、または過去のフォーマットルールを保持するためのいくつかの重要な例外。このドキュメントでは、RFCエディタによって適用または推奨されるこれらの例外を示します。
All RFCs begin as Internet-Drafts (also referred to as I-Ds), and a well-written and properly constructed Internet-Draft [ID-GUIDE] provides a strong basis for a good RFC. The RFC Editor accepts Internet-Drafts from specified streams for publication [RFC4844] and applies the rules and guidelines for the RFC Series during the editorial process.
すべてのRFCはインターネットドラフト（I-Dとも呼ばれる）で始まり、適切に作成され、適切に構築されたインターネットドラフト[ID-GUIDE]は、優れたRFCの強力な基盤を提供します。 RFCエディターは、公開[RFC4844]のために指定されたストリームからインターネットドラフトを受け入れ、編集プロセス中にRFCシリーズのルールとガイドラインを適用します。
Authors may find it helpful to understand the RFC Editor's goals during the publication process, namely to:
著者は、公開プロセス中にRFCエディタの目標を理解すること、つまり次のことを理解すると役立つ場合があります。
- Prepare the document according to RFC style and format.
- RFCのスタイルと形式に従ってドキュメントを準備します。
- Make the document as clear, consistent, and readable as possible.
- ドキュメントをできるだけ明確、一貫性があり、読みやすいものにします。
- Correct larger content/clarity issues; flag any unclear passages for author review.
- より大きなコンテンツ/明瞭さの問題を修正します。著者のレビューのために不明確な箇所にフラグを付けます。
- Fix inconsistencies (e.g., terms that appear in various forms, text that appears multiple times, or inconsistent capitalization).
- 不一致を修正します（例：さまざまな形式で表示される用語、複数回表示されるテキスト、一貫性のない大文字表記）。
We strive for consistency within:
私たちは以下の範囲内で一貫性を保つよう努めています。
a. the document,
a. ドキュメント、
b. a cluster of documents [CLUSTER], and
b. ドキュメントのクラスター[CLUSTER]、および
c. the series of RFCs on the subject matter.
c. 主題に関する一連のRFC。
The editorial process of the RFC Editor is not an additional technical review of the document. Where the RFC Editor may suggest changes in wording for clarity and readability, it is up to the author, working group, or stream-approving body to determine whether the changes have an impact on the technical meaning of the document [RFC4844]. If the original wording is a more accurate representation of the technical content being described in the document, it takes precedence over editorial conventions.
RFC Editorの編集プロセスは、ドキュメントの追加の技術レビューではありません。 RFCエディターが明快さと読みやすさのために文言の変更を提案する場合、変更が文書の技術的意味に影響を与えるかどうかを判断するのは、作成者、ワーキンググループ、またはストリーム承認機関次第です[RFC4844]。元の表現がドキュメントで説明されている技術的な内容をより正確に表現している場合は、編集上の規則よりも優先されます。
The activity of editing sometimes creates a tension between author and editor. The RFC Editor attempts to minimize this conflict for RFC publication while continually striving to produce a uniformly excellent document series. The RFC Editor refers to this fundamental tension as "editorial balance," and maintaining this balance is a continuing concern for the RFC Editor. There is a prime directive that must rule over grammatical conventions: do not change the intended meaning of the text.
編集の活動は、作者と編集者の間に緊張を引き起こすことがあります。 RFCエディターは、一貫して優れたドキュメントシリーズを作成するために継続的に努力しながら、RFC公開のこの競合を最小限に抑えようとします。 RFCエディターはこの基本的な緊張を「編集上のバランス」と呼び、このバランスを維持することはRFCエディターにとって継続的な関心事です。文法の規則を支配しなければならない主要な指示があります。テキストの意図された意味を変更しないでください。
If the RFC Editor cannot edit a document without serious risk of altering the meaning, it may be returned to the stream-approving body for review. See Appendix A.2 for more information.
RFCエディタが意味を変更する重大なリスクなしにドキュメントを編集できない場合、レビューのためにストリーム承認機関に返される場合があります。詳細については、付録A.2を参照してください。
This Style Guide does not use terminology as defined in RFC 2119 [BCP14]. In this document, lowercase use of "must" and "should" indicates changes the RFC Editor will make automatically to conform with this Style Guide versus those that may be questioned if not applied. The lowercase "must" indicates those changes that will be applied automatically and are not at the discretion of the authors. The lowercase "should" indicates the RFC Editor's recommended use, but conformance with the recommendations is not required; the RFC Editor may question whether the guidance may be applied.
このスタイルガイドでは、RFC 2119 [BCP14]で定義されている用語を使用していません。このドキュメントでは、「必須」および「する必要がある」の小文字の使用は、RFCエディタがこのスタイルガイドに準拠するために自動的に行う変更と、適用しない場合に疑わしい変更を示します。小文字の「必須」は、自動的に適用され、作成者の裁量ではない変更を示します。小文字の「すべき」はRFCエディタの推奨される使用法を示しますが、推奨事項への適合は必須ではありません。 RFCエディターは、ガイダンスが適用されるかどうかを質問する場合があります。
The RFC publication language is English. Spelling may be either American or British, as long as an individual document is internally consistent. Where both American and British English spelling are used within a document or cluster of documents, the text will be modified to be consistent with American English spelling.
RFC公開言語は英語です。スペリングは、個々のドキュメントが内部的に一貫している限り、アメリカでもイギリスでもかまいません。ドキュメントまたはドキュメントのクラスター内でアメリカ英語とイギリス英語の両方のスペルが使用されている場合、テキストはアメリカ英語のスペルと一致するように変更されます。
* No overstriking (or underlining) is allowed.
* 重ね打ち（または下線）は許可されていません。
* When a sentence ended by a period is immediately followed by another sentence, there must be two blank spaces after the period.
* ピリオドで終了する文の直後に別の文が続く場合、ピリオドの後に2つの空白スペースが必要です。
* A comma is used before the last item of a series, e.g.,
* シリーズの最後の項目の前にカンマが使用されています。たとえば、
"TCP service is reliable, ordered, and full duplex"
「TCPサービスは信頼性があり、注文され、全二重です」
* When quoting literal text, punctuation is placed outside quotation marks, e.g.,
* リテラルテキストを引用する場合、句読点は引用符の外に配置されます。たとえば、
Search for the string "Error Found".
文字列「エラーが見つかりました」を検索します。
When quoting general text, such as general text from another RFC, punctuation may be included within the quotation marks, e.g.,
別のRFCの一般的なテキストなどの一般的なテキストを引用する場合、引用符内に句読点を含めることができます。たとえば、
RFC 4844 indicates that "RFCs are available free of charge to anyone via the Internet."
RFC 4844は、「RFCはインターネットを介して誰でも無料で利用できる」ことを示しています。
Quotation marks are not necessary when text is formatted as a block quotation.
テキストがブロック引用としてフォーマットされている場合、引用符は必要ありません。
DNS names, whether or not in URIs, that are used as generic examples in RFCs should use the particular examples defined in "Reserved Top Level DNS Names" [BCP32], to avoid accidental conflicts.
URIであるかどうかに関係なく、RFCで一般的な例として使用されているDNS名は、「予約済みトップレベルDNS名」[BCP32]で定義されている特定の例を使用して、偶発的な競合を回避する必要があります。
Angle brackets are strongly recommended around URIs [STD66], e.g.,
角括弧は、URI [STD66]の周囲に強く推奨されます。たとえば、
<http://example.com/>
* Capitalization must be consistent within the document and ideally should be consistent with related RFCs. Refer to the online table of decisions on consistent usage of terms in RFCs [TERMS].
* 大文字と小文字はドキュメント内で一貫している必要があり、理想的には関連するRFCと一貫している必要があります。 RFC [TERMS]の用語の一貫した使用に関する決定のオンライン表を参照してください。
* Per CMOS guidelines, the major words in RFC titles and section titles should be capitalized (this is sometimes called "title case"). Typically, all words in a title will be capitalized, except for internal articles, prepositions, and conjunctions.
* CMOSガイドラインに従って、RFCタイトルおよびセクションタイトルの主要な単語は大文字にする必要があります（これは「タイトルケース」と呼ばれることもあります）。通常、タイトルのすべての単語は、内部の記事、前置詞、および接続詞を除いて大文字で表記されます。
* Section titles that are in sentence form will follow typical sentence capitalization.
* 文形式のセクションタイトルは、一般的な文の大文字表記に従います。
* Titles of figures may be in sentence form or use title case.
* 図のタイトルは、文の形式またはタイトルケースを使用できます。
* References and citations must match. That is, there must be a reference for each citation used, and vice versa.
* 参照と引用は一致する必要があります。つまり、使用される引用ごとに参照が必要であり、その逆も同様です。
* Citations must be enclosed in square brackets (e.g., "[CITE1]").
* 引用は角括弧で囲む必要があります（例： "[CITE1]"）。
* A citation/reference tag must not contain spaces.
* 引用/参照タグにスペースを含めることはできません。
Example: "[RFC2119]" rather than "[RFC 2119]"
例：「[RFC 2119]」ではなく「[RFC2119]」
However, the proper textual naming of an RFC contains a space.
ただし、RFCの適切なテキストによる命名にはスペースが含まれます。
Example: "See RFC 2119 [BCP14] for more information."
例：「詳細については、RFC 2119 [BCP14]を参照してください。」
* Cross-references within the body of the memo and to other RFCs must use section numbers rather than page numbers, as pagination may change per format and device.
* メモの本文内および他のRFCへの相互参照には、ページ番号ではなくセクション番号を使用する必要があります。ページ付けは、フォーマットやデバイスごとに変わる可能性があるためです。
Abbreviations should be expanded in document titles and upon first use in the document. The full expansion of the text should be followed by the abbreviation itself in parentheses. The exception is an abbreviation that is so common that the readership of RFCs can be expected to recognize it immediately; examples include (but are not limited to) TCP, IP, SNMP, and HTTP. The online list of abbreviations [ABBR] provides guidance. Some cases are marginal, and the RFC Editor will make the final judgment, weighing obscurity against complexity.
省略形は、ドキュメントのタイトルとドキュメントでの最初の使用時に展開する必要があります。テキストの完全な展開の後には、括弧内の略語自体が続く必要があります。例外は、RFCの読者がすぐにそれを認識することが期待できるほど一般的な略語です。例には、TCP、IP、SNMP、およびHTTPが含まれます（これらに限定されません）。略語のオンラインリスト[ABBR]はガイダンスを提供します。一部のケースは限界的であり、RFCエディタが最終的な判断を下し、あいまいさを複雑さと比較検討します。
Note: The online list of abbreviations is not exhaustive or definitive. It is a list of abbreviations appearing in RFCs and sometimes reflects discussions with authors, Working Group Chairs, and/or Area Directors (ADs). Note that some abbreviations have multiple expansions. Additionally, this list includes some terms that look like abbreviations but that are actually fixed names for things and hence cannot and should not be expanded. These are noted as "No Expansion".
注：略語のオンラインリストは、網羅的または完全なものではありません。これは、RFCに現れる略語のリストであり、著者、ワーキンググループチェア、および/またはエリアディレクター（AD）との議論を反映している場合があります。一部の略語には複数の展開があることに注意してください。さらに、このリストには、略語のように見えるが実際には固定された名前であるため、展開できない、または展開すべきでないいくつかの用語が含まれています。これらは「拡張なし」として示されます。
A published RFC will largely contain the elements in the following list. Some of these sections are required, as noted. Those sections marked with "*" will be supplied by the RFC Editor during the editorial process when necessary. Sections are allowed to contain nothing but subsections. The rules for each of these elements are described in more detail below.
公開されたRFCには、主に次のリストの要素が含まれます。記載されているように、これらのセクションのいくつかは必須です。 「*」が付いているセクションは、編集プロセス中に必要に応じてRFCエディターによって提供されます。セクションには、サブセクションのみを含めることができます。これらの各要素のルールについては、以下で詳しく説明します。
First-page header * [Required]
Title [Required]
Abstract [Required]
RFC Editor or Stream Note * [Upon request]
Status of This Memo * [Required]
Copyright Notice * [Required]
Table of Contents * [Required]
Body of the Memo [Required]
1. Introduction [Required]
2. Requirements Language (RFC 2119)
3. ...
MAIN BODY OF THE TEXT
6. ...
7. IANA Considerations [Required in I-D]
8. Internationalization Considerations
9. Security Considerations [Required]
10. References
10.1. Normative References
10.2. Informative References
Appendix A.
Appendix B.
Acknowledgements
Contributors
Author's Address [Required]
Within the body of the memo, the order shown above is strongly recommended. Exceptions may be questioned. Outside the body of the memo, the order above is required. The section numbers above are for illustrative purposes; they are not intended to correspond to required numbering in an RFC.
メモの本文では、上記の順序を強くお勧めします。例外が疑われる場合があります。メモの本文以外では、上記の注文が必要です。上記のセクション番号は説明のためのものです。 RFCで必要な番号付けに対応することは意図されていません。
The elements preceding the body of the memo should not be numbered. Typically, the body of the memo will have numbered sections and the appendices will be labeled with letters. Any sections that appear after the appendices should not be numbered or labeled (e.g., see "Contributors" above).
メモの本文の前にある要素には番号を付けないでください。通常、メモの本文には番号が付けられたセクションがあり、付録には文字でラベルが付けられます。付録の後に表示されるセクションには、番号やラベルを付けないでください（たとえば、上記の「寄稿者」を参照）。
Headers will follow the format described in "RFC Streams, Headers, and Boilerplates" [RFC5741] and its successors. In addition, the following conventions will apply.
ヘッダーは、「RFCストリーム、ヘッダー、およびボイラープレート」[RFC5741]およびその後継で説明されているフォーマットに従います。さらに、次の規則が適用されます。
The determination of who should be listed as an author or editor on an RFC is made by the stream.
RFCの作成者または編集者として誰をリストするかは、ストリームによって決定されます。
The author's name (initial followed by family name) appears on the first line of the heading. Some variation, such as additional initials or capitalization of family name, is acceptable. Once the author has selected how their name should appear, they should use that display consistently in all of their documents.
著者の名前（最初に姓が続く）が見出しの最初の行に表示されます。追加のイニシャルや姓の大文字化など、一部のバリエーションは許容されます。著者が名前の表示方法を選択したら、すべてのドキュメントで一貫してその表示を使用する必要があります。
The total number of authors or editors on the first page is generally limited to five individuals and their affiliations. If there is a request for more than five authors, the stream-approving body needs to consider if one or two editors should have primary responsibility for this document, with the other individuals listed in the Contributors or Acknowledgements section. There must be a direct correlation of authors and editors in the document header and the Authors' Addresses section. These are the individuals that must sign off on the document during the AUTH48 process and respond to inquiries, such as errata.
最初のページの著者または編集者の総数は、通常、5人の個人とその所属に制限されています。 5人を超える著者からのリクエストがある場合、ストリーム承認機関は、1人または2人の編集者がこのドキュメントに対して主な責任を持つべきかどうかを検討する必要があります。他の個人は、「貢献者」または「謝辞」セクションにリストされています。ドキュメントヘッダーと[作成者のアドレス]セクションで、作成者と編集者が直接関連付けられている必要があります。これらは、AUTH48プロセス中にドキュメントにサインオフし、正誤表などの問い合わせに応答する必要がある個人です。
The author's organization is indicated on the line following the author's name.
著者の組織は、著者の名前に続く行に示されています。
For multiple authors, each author name appears on its own line, followed by that author's organization. When more than one author is affiliated with the same organization, the organization can be "factored out," appearing only once following the corresponding Author lines. However, such factoring is inappropriate when it would force an unacceptable reordering of author names.
複数の作成者の場合、各作成者名は独自の行に表示され、その後にその作成者の組織が表示されます。複数の著者が同じ組織に所属している場合、組織は「除外」され、対応する著者行の後に一度だけ表示されます。ただし、このような因数分解は、著者名の許容できない並べ替えを強制する場合には不適切です。
If an author cannot or will not provide an affiliation for any reason, "Independent", "Individual Contributor", "Retired", or some other term that appropriately describes the author's affiliation may be used. Alternatively, a blank line may be included in the document header when no affiliation is provided.
著者が何らかの理由で所属を提供できない、または提供しない場合、「独立」、「個人の貢献者」、「退職」、または著者の所属を適切に説明するその他の用語が使用される場合があります。または、所属が指定されていない場合、ドキュメントヘッダーに空白行を含めることができます。
The RFC Series has been assigned an International Standard Serial Number of 2070-1721 [ISO3297]. It will be included by the RFC Editor.
RFCシリーズには、2070-1721 [ISO3297]という国際標準シリアル番号が割り当てられています。 RFC Editorに含まれます。
When an RFC obsoletes or updates a previously published RFC or RFCs, this information is included in the document header. For example:
RFCが以前に発行されたRFCを廃止または更新する場合、この情報はドキュメントヘッダーに含まれます。例えば：
"Updates: nnnn" or "Updates: nnnn, ..., nnnn"
「更新：nnnn」または「更新：nnnn、...、nnnn」
"Obsoletes: nnnn" or "Obsoletes: nnnn, ... , nnnn"
「廃止：nnnn」または「廃止：nnnn、...、nnnn」
If the document updates or obsoletes more than one document, numbers will be listed in ascending order.
ドキュメントが複数のドキュメントを更新または廃止する場合、番号は昇順でリストされます。
The title must be centered below the rest of the heading, preceded by two blank lines and followed by one blank line.
タイトルは、残りの見出しの下の中央に配置する必要があります。先頭に2つの空白行が続き、その後に1つの空白行が続きます。
Choosing a good title for an RFC can be a challenge. A good title should fairly represent the scope and purpose of the document without being either too general or too specific and lengthy.
RFCの適切なタイトルを選択することは、困難な場合があります。適切なタイトルは、一般的すぎたり、具体的すぎたり長すぎたりすることなく、ドキュメントの範囲と目的を公平に表す必要があります。
Abbreviations in a title must generally be expanded when first encountered (see Section 3.6 for additional guidance on abbreviations).
タイトルの略語は通常、最初に出現したときに展開する必要があります（略語の詳細については、セクション3.6を参照してください）。
It is often helpful to follow the expansion with the parenthesized abbreviation, as in the following example:
次の例のように、展開の後に括弧で囲まれた省略形を付けると役立つことがよくあります。
Encoding Rules for the Common Routing Encapsulation Extension Protocol (CREEP)
Common Routing Encapsulation Extension Protocol（CREEP）のエンコーディングルール
The RFC Editor recommends that documents describing a particular company's private protocol should bear a title of the form "Foo's ... Protocol" (where Foo is a company name), to clearly differentiate it from a protocol of more general applicability.
RFC Editorは、特定の会社のプライベートプロトコルを説明するドキュメントに、「Foo's ... Protocol」（Fooは会社名）という形式のタイトルを付けて、より一般的な適用性のプロトコルと明確に区別することを推奨しています。
Every RFC must have an Abstract that provides a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document.
すべてのRFCには、技術的な知識のある読者にドキュメントの機能の概要を提供するために、ドキュメント全体の目的と内容の簡潔で包括的な概要を提供する要約が必要です。
Composing a useful Abstract generally requires thought and care. Usually, an Abstract should begin with a phrase like "This memo ..." or "This document ..." A satisfactory Abstract can often be constructed in part from material within the Introduction section, but an effective Abstract may be shorter, less detailed, and perhaps broader in scope than the Introduction. Simply copying and pasting the first few paragraphs of the Introduction is allowed, but it may result in an Abstract that is both incomplete and redundant. Note also that an Abstract is not a substitute for an Introduction; the RFC should be self-contained as if there were no Abstract.
有用なアブストラクトを作成するには、一般に思考と注意が必要です。通常、アブストラクトは「このメモ...」または「このドキュメント...」のような語句で始める必要があります。満足できるアブストラクトは、多くの場合、導入セクション内の素材から部分的に構築できますが、効果的なアブストラクトは短く、少なくなります詳細、そしておそらく導入よりも広い範囲。序文の最初の数段落を単純にコピーして貼り付けることは許可されていますが、不完全で冗長な要約になる可能性があります。また、アブストラクトはイントロダクションの代わりにはなりません。 RFCは、あたかも抄録がないかのように自己完結型である必要があります。
Similarly, the Abstract should be complete in itself. It will appear in isolation in publication announcements and in the online index of RFCs. Therefore, the Abstract must not contain citations.
同様に、要約はそれ自体で完全でなければなりません。これは、出版物の発表とRFCのオンラインインデックスに単独で表示されます。したがって、要約には引用を含めないでください。
A stream-approving body may approve the inclusion of an editorial note to explain anything unusual about the process that led to the document's publication or to note a correction. In this case, a stream note section will contain such a note.
ストリーム承認機関は、ドキュメントの発行につながったプロセスについて異常なことを説明したり、修正を記したりするための編集ノートの追加を承認する場合があります。この場合、ストリームノートセクションにはそのようなノートが含まれます。
Additionally, an RFC Editor Note section may contain a note inserted by the RFC Editor to highlight special circumstances surrounding an RFC.
さらに、RFCエディタのノートセクションには、RFCを取り巻く特別な状況を強調するためにRFCエディタによって挿入されたノートが含まれる場合があります。
The RFC Editor will supply an appropriate "Status of This Memo" as defined in RFC 5741 [RFC5741] and "Format for RFCs in the IAB Stream" [IAB-FORM].
RFCエディターは、RFC 5741 [RFC5741]および「IABストリームのRFCの形式」[IAB-FORM]で定義されている適切な「このメモのステータス」を提供します。
The full copyright and license notices are available on the IETF Trust Legal Provisions documents website [IETF-TRUST].
著作権とライセンスの完全な通知は、IETF Trust Legal ProvisionsドキュメントWebサイト[IETF-TRUST]で入手できます。
A Table of Contents (TOC) is required in all RFCs. It must be positioned after the Copyright Notice and before the Introduction.
すべてのRFCで目次（TOC）が必要です。これは、著作権情報の後で、紹介の前に配置する必要があります。
Following the TOC is the body of the memo.
TOCの後にはメモの本文があります。
Each RFC must include an Introduction section that (among other things) explains the motivation for the RFC and (if appropriate) describes the applicability of the document, e.g., whether it specifies a protocol, provides a discussion of some problem, is simply of interest to the Internet community, or provides a status report on some activity. The body of the memo and the Abstract must be self-contained and separable. This may result in some duplication of text between the Abstract and the Introduction; this is acceptable.
各RFCには、（特に）RFCの動機を説明し、（該当する場合）ドキュメントの適用可能性を説明する導入セクションを含める必要があります。たとえば、プロトコルを指定しているか、問題の説明を提供しているか、インターネットコミュニティに、またはいくつかの活動のステータスレポートを提供します。メモの本文と要約は、自己完結型で分離可能でなければなりません。これにより、アブストラクトとイントロダクションの間でテキストが重複する可能性があります。これは許容範囲です。
The Introduction section should always be the first section following the TOC (except in the case of MIB module documents). While "Introduction" is recommended, authors may choose alternate titles such as "Overview" or "Background". These alternates are acceptable.
はじめにセクションは、TOCに続く最初のセクションである必要があります（MIBモジュールドキュメントの場合を除く）。 「はじめに」をお勧めしますが、著者は「概要」や「背景」などの代替タイトルを選択できます。これらの代替案は受け入れられます。
For MIB module documents, common practice has been for "The Internet-Standard Management Framework" [MIB-BOILER] text to appear as Section 1.
MIBモジュールのドキュメントでは、「インターネット標準管理フレームワーク」[MIB-BOILER]テキストがセクション1として表示されるのが一般的です。
Some documents use certain capitalized words ("MUST", "SHOULD", etc.) to specify precise requirement levels for technical features. RFC 2119 [BCP14] defines a default interpretation of these capitalized words in IETF documents. If this interpretation is used, RFC 2119 must be cited (as specified in RFC 2119) and included as a normative reference. Otherwise, the correct interpretation must be specified in the document.
一部のドキュメントでは、特定の大文字の単語（「MUST」、「SHOULD」など）を使用して、技術機能の正確な要件レベルを指定しています。 RFC 2119 [BCP14]は、IETF文書内のこれらの大文字の単語のデフォルトの解釈を定義しています。この解釈を使用する場合は、RFC 2119を（RFC 2119で指定されているように）引用し、規範的な参照として含める必要があります。それ以外の場合は、正しい解釈をドキュメントに指定する必要があります。
This section must appear as part of the body of the memo (as defined by this document). It must appear as part of, or subsequent to, the Introduction section.
このセクションは、メモの本文の一部として表示される必要があります（このドキュメントで定義されています）。紹介セクションの一部として、またはその後に表示される必要があります。
These words are considered part of the technical content of the document and are intended to provide guidance to implementers about specific technical features, generally governed by considerations of interoperability. RFC 2119 says:
これらの単語は、ドキュメントの技術的な内容の一部と見なされ、特定の技術的な機能について実装者にガイダンスを提供することを目的としており、一般に相互運用性の考慮事項によって管理されます。 RFC 2119は言う：
Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability.
このメモで定義されているタイプの命令は、慎重かつ慎重に使用する必要があります。特に、相互運用に実際に必要な場合、または害を及ぼす可能性のある動作を制限する場合（たとえば、再送信の制限）にのみ使用する必要があります。たとえば、特定のメソッドを実装者に課そうとするために使用してはなりません。相互運用性のためにメソッドは必要ありません。
For guidance on how to register IANA-related values or create new registries to be managed by IANA, see "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANA関連の値を登録する方法、またはIANAで管理する新しいレジストリを作成する方法のガイダンスについては、「RFCでIANAに関する考慮事項セクションを記述するためのガイドライン」[BCP26]を参照してください。
The RFC Editor will update text accordingly after the IANA assignments have been made. It is helpful for authors to clearly identify where text should be updated to reflect the newly assigned values. For example, the use of "TBD1", "TBD2", etc., is recommended in the IANA Considerations section and in the body of the memo.
IANAの割り当てが行われた後、RFCエディターはそれに応じてテキストを更新します。新しく割り当てられた値を反映するためにテキストを更新する必要がある場所を作成者が明確に識別するのに役立ちます。たとえば、「TBD1」、「TBD2」などの使用は、IANAの考慮事項セクションとメモの本文で推奨されています。
If the authors have provided values to be assigned by IANA, the RFC Editor will verify that the values inserted by the authors match those that have actually been registered on the IANA site. When writing a given value, consistent use of decimal or hexadecimal is recommended.
著者がIANAによって割り当てられる値を提供した場合、RFCエディターは、著者が挿入した値がIANAサイトに実際に登録されている値と一致することを確認します。特定の値を書き込む場合、10進数または16進数の一貫した使用をお勧めします。
If any of the IANA-related information is not clear, the RFC Editor will work with IANA to send queries to the authors to ensure that assignments and values are properly inserted.
IANA関連の情報のいずれかが明確でない場合、RFCエディターはIANAと協力して作成者にクエリを送信し、割り当てと値が適切に挿入されるようにします。
The RFC Editor will remove an IANA Considerations section that says there are no IANA considerations (although such a section is required in the Internet-Draft preceding the RFC).
RFCエディターは、IANAの考慮事項がないことを示すIANAの考慮事項セクションを削除します（そのようなセクションは、RFCの前のインターネットドラフトで必要です）。
All RFCs that deal with internationalization issues should have a section describing those issues; see "IETF Policy on Character Sets and Languages" [BCP18], Section 6, for more information.
国際化の問題を扱うすべてのRFCには、それらの問題を説明するセクションが必要です。詳細については、「文字セットと言語に関するIETFポリシー」[BCP18]のセクション6をご覧ください。
All RFCs must contain a section that discusses the security considerations relevant to the specification; see "Guidelines for Writing RFC Text on Security Considerations" [BCP72] for more information.
すべてのRFCには、仕様に関連するセキュリティの考慮事項を説明するセクションが含まれている必要があります。詳細については、「セキュリティ上の考慮事項に関するRFCテキストの作成ガイドライン」[BCP72]を参照してください。
Note that additional boilerplate material for RFCs containing MIB and YANG modules also exists. See "Security Guidelines for IETF MIB Modules" [MIB-SEC] and "yang module security considerations" [YANG-SEC] for details.
MIBおよびYANGモジュールを含むRFCの追加のボイラープレート資料も存在することに注意してください。詳細については、「IETF MIBモジュールのセキュリティガイドライン」[MIB-SEC]および「yangモジュールのセキュリティに関する考慮事項」[YANG-SEC]を参照してください。
The reference list is solely for recording reference entries. Introductory text is not allowed.
参照リストは、参照エントリを記録するためだけのものです。紹介文は許可されていません。
The RFC style allows the use of any of a variety of reference styles, as long as they are used consistently within a document. However, where necessary, some reference styles have been described for use within the Series. See the examples in this document.
RFCスタイルでは、ドキュメント内で一貫して使用されている限り、さまざまな参照スタイルを使用できます。ただし、必要に応じて、シリーズ内で使用するためにいくつかの参照スタイルが説明されています。このドキュメントの例を参照してください。
The RFC Editor ensures that references to other RFCs refer to the most current RFC available on that topic (unless provided with a reason not to do so). When referring to an obsoleted document, it is common practice to also refer to the most recent version.
RFCエディターは、他のRFCへの参照がそのトピックで利用可能な最新のRFCを参照することを保証します（そうしない理由が提供されている場合を除く）。廃止されたドキュメントを参照する場合、最新バージョンも参照するのが一般的です。
A reference to an RFC that has been assigned an STD [RFC1311], BCP [RFC1818], or FYI [FYI90] sub-series number must include the sub-series number of the document. Note that the FYI series was ended by RFC 6360. RFCs that were published with an FYI sub-series number and still maintain the FYI number must include the sub-series number in the reference.
STD [RFC1311]、BCP [RFC1818]、またはFYI [FYI90]サブシリーズ番号が割り当てられているRFCへの参照には、ドキュメントのサブシリーズ番号を含める必要があります。 FYIシリーズはRFC 6360によって終了したことに注意してください。FYIサブシリーズ番号で公開され、FYI番号を維持しているRFCは、サブシリーズ番号を参照に含める必要があります。
Reference lists must indicate whether each reference is normative or informative, where normative references are essential to implementing or understanding the content of the RFC and informative references provide additional information. More information about normative and informative references may be found in the IESG's statement "Normative and Informative References" [REFS]. When both normative and informative references exist, the references section should be split into two subsections:
参照リストは、各参照が規範的であるか情報提供であるかを示さなければなりません。規範的参照は、RFCのコンテンツの実装または理解に不可欠であり、情報提供参照は追加情報を提供します。規範的および有益な参照に関する詳細情報は、IESGのステートメント「規範的および情報的参照」[REFS]にあります。規範と参考の両方の参照が存在する場合、参照セクションは2つのサブセクションに分割する必要があります。
s. References
s. 参考文献
s.1. Normative References
s.1。規範的な参考文献
xxx ... xxx
xxx ... xxx
s.2. Informative References
s.2。参考情報
xxx ... xxx
xxx ... xxx
References will generally appear in alphanumeric order by citation tag. Where there are only normative or informative references, no subsection is required; the top-level section should say "Normative References" or "Informative References".
参照は通常、引用タグのアルファベット順に表示されます。規範的または有益な参照のみがある場合、サブセクションは必要ありません。最上位のセクションには、「規範的な参照」または「有益な参照」と記載する必要があります。
Normative references to Internet-Drafts will cause publication of the RFC to be suspended until the referenced draft is also ready for publication; the RFC Editor will then update the entry to refer to the RFC and publish both documents simultaneously.
インターネットドラフトへの規範的な参照は、参照されたドラフトも公開の準備ができるまでRFCの公開を中断させます。 RFCエディターは、RFCを参照するようにエントリを更新し、両方のドキュメントを同時に公開します。
The use of URIs in references is acceptable, as long as the URI is the most stable (i.e., unlikely to change and expected to be continuously available) and direct reference possible. The URI will be verified as valid during the RFC editorial process.
参照でのURIの使用は、URIが最も安定しており（つまり、変更される可能性が低く、継続的に利用できることが期待される）、可能な限り直接参照である限り許容されます。 URIは、RFC編集プロセス中に有効であることが検証されます。
If a dated URI (one that includes a timestamp for the page) is available for a referenced web page, its use is required.
参照されたWebページで日付付きURI（ページのタイムスタンプを含むもの）が使用可能な場合は、その使用が必要です。
Note that URIs may not be the sole information provided for a reference entry.
URIが参照エントリに提供される唯一の情報ではない場合があることに注意してください。
The following format is required for referencing RFCs. Note the ordering for multiple authors: the format of the name of the last author listed is different than that of all previous authors in the list.
RFCを参照するには、次の形式が必要です。複数の著者の順序に注意してください。リストされた最後の著者の名前の形式は、リスト内の以前のすべての著者の形式とは異なります。
For one author or editor:
1人の著者または編集者の場合：
[RFCXXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, Date of publication, <http://www.rfc-editor.org/info/rfc#>.
[RFCXXXX]姓、イニシャル、エド。 （該当する場合）、「RFCタイトル」、サブシリーズ番号（該当する場合）、RFC番号、発行日、<http://www.rfc-editor.org/info/rfc#>。
Example:
例：
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001, <http://www.rfc-editor.org/info/rfc3080>.
[RFC3080] Rose、M。、「The Blocks Extensible Exchange Protocol Core」、RFC 3080、2001年3月、<http://www.rfc-editor.org/info/rfc3080>。
For two authors or editors:
2人の著者または編集者の場合：
[RFCXXXX] Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, Date of publication, <http://www.rfc-editor.org/info/rfc#>.
[RFCXXXX]姓、イニシャル、エド。 （該当する場合）および最初のイニシャル。姓、エド。 （該当する場合）、「RFCタイトル」、サブシリーズ番号（該当する場合）、RFC番号、発行日、<http://www.rfc-editor.org/info/rfc#>。
Example:
例：
[RFC6323] Renker, G. and G. Fairhurst, "Sender RTT Estimate Option for the Datagram Congestion Control Protocol (DCCP)", RFC 6323, July 2011, <http://www.rfc-editor.org/info/rfc6323>.
[RFC6323]レンカー、G。およびG.フェアハースト、「データグラム輻輳制御プロトコル（DCCP）の送信者RTT見積もりオプション」、RFC 6323、2011年7月、<http://www.rfc-editor.org/info/rfc6323 >。
For three or more authors or editors:
3人以上の著者または編集者の場合：
[RFCXXXX] Last name, First initial., Ed. (if applicable), Last name, First initial., Ed. (if applicable), and First initial. Last name, Ed. (if applicable), "RFC Title", Sub-series number (if applicable), RFC number, Date of publication, <http://www.rfc-editor.org/info/rfc#>.
[RFCXXXX]姓、イニシャル、エド。 （該当する場合）、姓、イニシャル、エド。 （該当する場合）、および最初のイニシャル。姓、エド。 （該当する場合）、「RFCタイトル」、サブシリーズ番号（該当する場合）、RFC番号、発行日、<http://www.rfc-editor.org/info/rfc#>。
Example:
例：
[RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender Clarification for Persist Condition", RFC 6429, December 2011, <http://www.rfc-editor.org/info/rfc6429>.
[RFC6429] Bashyam、M.、Jethanandani、M。、およびA. Ramaiah、「永続的な状態のためのTCP送信者の明確化」、RFC 6429、2011年12月、<http://www.rfc-editor.org/info/rfc6429> 。
Internet Standards (STDs) and Best Current Practices (BCPs) may consist of a single RFC or multiple RFCs. When an STD or BCP that contains multiple RFCs is referenced, the reference entry should include ALL of the RFCs comprising that sub-series. The authors should refer to specific RFC numbers as part of the text (not as citations) and cite the sub-series number. Inclusion of the URI to the STD or BCP info page (see Section 3.2.3 of [RFC5741]) is recommended. The text should appear as follows:
インターネット標準（STD）およびベストカレントプラクティス（BCP）は、単一のRFCまたは複数のRFCで構成されている場合があります。複数のRFCを含むSTDまたはBCPが参照される場合、参照エントリには、そのサブシリーズを構成するすべてのRFCを含める必要があります。著者は、特定のRFC番号をテキストの一部として（引用ではなく）参照し、サブシリーズ番号を引用する必要があります。 STDまたはBCP情報ページへのURIを含めることをお勧めします（[RFC5741]のセクション3.2.3を参照）。テキストは次のように表示されます。
See RFC 1034 [STD13].
RFC 1034 [STD13]を参照してください。
For an STD or BCP that contains one RFC:
1つのRFCを含むSTDまたはBCPの場合：
[STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number, RFC number, Date of publication, <http://www.rfc-editor.org/info/std#>.
[STDXXX]姓、イニシャル、エド。 （該当する場合）、「RFCタイトル」、サブシリーズ番号、RFC番号、公開日、<http://www.rfc-editor.org/info/std#>。
Example:
例：
[STD72] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011, <http://www.rfc-editor.org/info/std72>.
[STD72] Gellens、R。およびJ. Klensin、「Mail for Submission for Mail」、STD 72、RFC 6409、2011年11月、<http://www.rfc-editor.org/info/std72>。
For an STD or BCP that contains two or more RFCs:
2つ以上のRFCを含むSTDまたはBCPの場合：
[STDXXX] Last name, First initial., Ed. (if applicable), "RFC Title", Sub-series number, RFC number, Date of publication.
[STDXXX]姓、イニシャル、エド。 （該当する場合）、「RFCタイトル」、サブシリーズ番号、RFC番号、発行日。
Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "RFC Title", Sub-series number, RFC number, Date of publication.
姓、イニシャル、エド。 （該当する場合）および最初のイニシャル。姓、エド。 （該当する場合）、「RFCタイトル」、サブシリーズ番号、RFC番号、発行日。
<http://www.rfc-editor.org/info/std#>
Example:
例：
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
<http://www.rfc-editor.org/info/std13>
References to Internet-Drafts may only appear as informative references. Given that several revisions of an I-D may be produced in a short time frame, references must include the posting date (month and year), the full Internet-Draft file name (including the version number), and the phrase "Work in Progress". Authors may reference multiple versions of an I-D. If the referenced I-D was also later published as an RFC, then that RFC must also be listed.
インターネットドラフトへの参照は、参考情報としてのみ表示される場合があります。 IDのいくつかのリビジョンが短期間で作成される場合があるため、参照には、投稿日（月と年）、完全なInternet-Draftファイル名（バージョン番号を含む）、および「Work in Progress」というフレーズを含める必要があります。 。著者は、I-Dの複数のバージョンを参照できます。参照されたI-Dも後にRFCとして公開された場合は、そのRFCもリストする必要があります。
[SYMBOLIC-TAG] Last name, First initial., Ed. (if applicable) and First initial. Last name, Ed. (if applicable), "I-D Title", Work in Progress, draft-string-NN, Month Year.
[SYMBOLIC-TAG]姓、イニシャル、エド。 （該当する場合）および最初のイニシャル。姓、エド。 （該当する場合）、「I-Dタイトル」、作業中、draft-string-NN、月年。
Example:
例：
[RFC-STYLE] Flanagan, H. and S. Ginoza, "RFC Style Guide", Work in Progress, draft-flanagan-style-01, June 2013.
[RFC-STYLE] Flanagan、H. and S. Ginoza、「RFC Style Guide」、Work in Progress、draft-flanagan-style-01、2013年6月。
The following format is required when a reference to an erratum report is necessary:
エラータレポートへの参照が必要な場合は、次の形式が必要です。
[ErrNumber] RFC Errata, Erratum ID number, RFC number.
[ErrNumber] RFC Errata、Erratum ID番号、RFC番号。
[Err1912] RFC Errata, Erratum ID 1912, RFC 2978.
[Err1912] RFC Errata、Erratum ID 1912、RFC 2978。
The following format is suggested when referencing a document or standard from another SDO in which authors are listed:
著者がリストされている別のSDOからドキュメントまたは標準を参照する場合は、次の形式が推奨されます。
[SYMBOLIC-TAG] Last name, First initial. and First initial. Last name, "Document Title", Document reference number, Date of publication, <URI if available>.
[SYMBOLIC-TAG]姓、イニシャル。そして最初のイニシャル。姓、「ドキュメントのタイトル」、ドキュメントの参照番号、公開日、<利用可能な場合はURI>。
[W3C.REC-xml11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-xml11] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E.、Yergeau、F.、J。Cowan、「Extensible Markup Language（XML）1.1（Second Edition） ） "、W3C勧告REC-xml11-20060816、2006年8月、<http://www.w3.org/TR/2006/REC-xml11-20060816>。
Note that the order of authors in the list is the same as the order shown on the actual document and that the common, abbreviated form of the SDO is used.
リスト内の作成者の順序は実際のドキュメントに示されている順序と同じであり、SDOの共通の省略形が使用されていることに注意してください。
Alternatively, when no list of authors is available, the following format is recommended:
または、作成者のリストがない場合は、次の形式をお勧めします。
[SYMBOLIC-TAG] Organization, "Document Title", Document reference number, Date of publication, <URI if available>.
[SYMBOLIC-TAG]組織、「ドキュメントタイトル」、ドキュメント参照番号、発行日、<利用可能な場合はURI>。
Example:
例：
[IEEE802.1Q] IEEE, "Local and Metropolitan Area Networks -- Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", IEEE Std 802.1Q-2011, August 2011, <http://standards.ieee.org/findstds/standard/ 802.1Q-2011.html>.
[IEEE802.1Q] IEEE、「ローカルおよびメトロポリタンエリアネットワーク-メディアアクセスコントロール（MAC）ブリッジおよび仮想ブリッジローカルエリアネットワーク」、IEEE Std 802.1Q-2011、2011年8月、<http://standards.ieee.org /findstds/standard/802.1Q-2011.html>。
The RFC Editor recommends placing references before the Appendices. Appendices should be labeled as "Appendix A. Title", "A.1. Title", "Appendix B. Title", etc.
RFCエディタでは、付録の前に参照を配置することをお勧めします。付録には「付録A.タイトル」、「A.1。タイトル」、「付録B.タイトル」などのラベルを付ける必要があります。
This optional section may be used instead of, or in addition to, a Contributors section. It is often used by authors to publicly thank those who have provided feedback regarding a document and to note any documents from which text was borrowed.
このオプションのセクションは、コントリビューターセクションの代わりに、またはそれに加えて使用できます。文書に関してフィードバックを提供してくれた人々に感謝の意を表し、テキストが借用されたすべての文書を書き留めるために、作者がよく使用します。
This optional section acknowledges those who have made significant contributions to the document.
このオプションのセクションでは、ドキュメントに多大な貢献をした人を認めています。
In a similar fashion to the Author's Address section, the RFC Editor does not make the determination as to who should be listed as a contributor to an RFC. The determination of who should be listed as a contributor is made by the stream.
著者のアドレスセクションと同様の方法で、RFCエディターは、RFCへの貢献者として誰をリストする必要があるかを決定しません。誰が貢献者としてリストされるべきかの決定は、ストリームによって行われます。
The Contributors section may include brief statements about the nature of particular contributions ("Sam contributed Section 3"), and it may also include affiliations of listed contributors. At the discretion of the author(s), contact addresses may also be included in the Contributors section, for those contributors whose knowledge makes them useful future contacts for information about the RFC. The format of any contact information should be similar to the format of information in the Author's Address section.
寄稿者セクションには、特定の寄稿の性質に関する簡単な説明が含まれる場合があり（「サム寄稿セクション3」）、リストされた寄稿者の所属も含まれる場合があります。著者の裁量で、RFCについての情報のために将来の連絡先として役立つ連絡先の場合、連絡先アドレスも[貢献者]セクションに含めることができます。連絡先情報の形式は、作成者のアドレスセクションの情報の形式と同様である必要があります。
This required section gives contact information for the author(s) listed in the first-page header.
この必須セクションには、最初のページのヘッダーにリストされている著者の連絡先情報が記載されています。
Contact information must include a long-lived email address and optionally may include a postal address and/or telephone number. If the postal address is included, it should include the country name, using the English short name listed by the ISO 3166 Maintenance Agency [ISO_OBP]. The purpose of this section is to (1) unambiguously define author identity (e.g., the John Smith who works for FooBar Systems) and (2) provide contact information for future readers who have questions or comments.
連絡先情報には、長期間有効な電子メールアドレスを含める必要があり、必要に応じて、住所や電話番号を含めることもできます。住所が含まれている場合は、ISO 3166 Maintenance Agency [ISO_OBP]によってリストされている英語の短縮名を使用して、国名を含める必要があります。このセクションの目的は、（1）作成者のアイデンティティ（FooBar Systemsで働くJohn Smithなど）を明確に定義し、（2）質問やコメントがある将来の読者に連絡先情報を提供することです。
The practice of munged email addresses (i.e., altering an email address to make it less readable to bots and web crawlers to avoid spam) is not appropriate in an archival document series. Author contact information is provided so that readers can easily contact the author with questions and/or comments. Address munging is not allowed in RFCs.
電子メールアドレスを変更する（つまり、ボットやWebクローラーがスパムを回避できるように電子メールアドレスを読みにくくする）ことは、一連のアーカイブドキュメントでは適切ではありません。著者の連絡先情報は、読者が質問やコメントで著者に簡単に連絡できるように提供されています。 RFCではアドレスの変更は許可されていません。
This document has no security considerations.
このドキュメントにはセキュリティに関する考慮事項はありません。
[STYLE-WEB] RFC Editor, "Web Portion of the Style Guide", <http://www.rfc-editor.org/rfc-style-guide/part2.html>.
[STYLE-WEB] RFC Editor、 "Web Portion of the Style Guide"、<http://www.rfc-editor.org/rfc-style-guide/part2.html>。
[ABBR] RFC Editor Abbreviations List, <http://www.rfc-editor.org/rfc-style-guide/ abbrev.expansion.txt>.
[ABBR] RFC Editor Abbreviations List、<http://www.rfc-editor.org/rfc-style-guide/ abbrev.expansion.txt>。
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/bcp14>.
[BCP14] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/bcp14>。
[BCP18] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998, <http://www.rfc-editor.org/info/bcp18>.
[BCP18] Alvestrand、H。、「文字セットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月、<http://www.rfc-editor.org/info/bcp18>。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/bcp26>.
[BCP26] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/bcp26> 。
[BCP32] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999, <http://www.rfc-editor.org/info/bcp32>.
[BCP32] Eastlake 3rd、D。およびA. Panitz、「Reserved Top Level DNS Names」、BCP 32、RFC 2606、1999年6月、<http://www.rfc-editor.org/info/bcp32>。
[BCP72] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/bcp72>.
[BCP72] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストの作成ガイドライン」、BCP 72、RFC 3552、2003年7月、<http://www.rfc-editor.org/info/bcp72>。
[CLUSTER] RFC Editor, "Clusters in the RFC Editor Queue", <http://www.rfc-editor.org/cluster_def.html>.
[CLUSTER] RFC Editor、「Clusters in the RFC Editor Queue」、<http://www.rfc-editor.org/cluster_def.html>。
[CMOS] Chicago Manual of Style, 16th ed. Chicago: University of Chicago Press, 2010.
[CMOS]シカゴマニュアルオブスタイル、第16版。シカゴ：シカゴ大学出版局、2010年。
[FYI90] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to the FYI Notes", FYI Notes, RFC 1150, March 1990.
[FYI90] Malkin、G。およびJ. Reynolds、「FYI on FYI：Introduction to the FYI Notes」、FYI Notes、RFC 1150、March 1990。
Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, August 2011.
Housley、R。、「FYI RFCサブシリーズの結論」、RFC 6360、2011年8月。
[IAB-FORM] IAB, "Format for RFCs in the IAB Stream", <http://www.rfc-editor.org/rfc-style-guide/ iab-format.txt>.
[IAB-FORM] IAB、「IABストリームのRFCの形式」、<http://www.rfc-editor.org/rfc-style-guide/ iab-format.txt>。
[ID-GUIDE] IETF, "Guidelines to Authors of Internet Drafts", <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[ID-GUIDE] IETF、「インターネットドラフトの作成者へのガイドライン」、<http://www.ietf.org/ietf-ftp/1id-guidelines.txt>。
[IETF-TRUST] IETF Trust, "Trust Legal Provisions (TLP)", <http://trustee.ietf.org/license-info/>.
[IETF-TRUST] IETF Trust、「Trust Legal Provisions（TLP）」、<http://trustee.ietf.org/license-info/>。
[ISO_OBP] ISO, "Online Browsing Platform (OBP)", <https://www.iso.org/obp/ui/>.
[ISO_OBP] ISO、「オンラインブラウジングプラットフォーム（OBP）」、<https://www.iso.org/obp/ui/>。
[ISO3297] Technical Committee ISO/TC 46, Information and documentation, Subcommittee SC 9, Identification and description, "Information and documentation - International standard serial number (ISSN)", September 2007.
[ISO3297]技術委員会ISO / TC 46、情報と文書、小委員会SC 9、識別と説明、「情報と文書-国際標準シリアル番号（ISSN）」、2007年9月。
[MIB-BOILER] IETF OPS Area, "Boilerplate for IETF MIB Documents", <http://www.ops.ietf.org/mib-boilerplate.html>.
[MIB-BOILER] IETF OPSエリア、「IETF MIBドキュメントのボイラープレート」、<http://www.ops.ietf.org/mib-boilerplate.html>。
[MIB-SEC] IETF OPS Area, "Security Guidelines for IETF MIB Modules", <http://trac.tools.ietf.org/area/ops/trac/wiki/ mib-security>.
[MIB-SEC] IETF OPSエリア、「IETF MIBモジュールのセキュリティガイドライン」、<http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security>。
[REFS] IESG, "IESG Statement: Normative and Informative References", <http://www.ietf.org/iesg/statement/ normative-informative.html>.
[参考文献] IESG、「IESG Statement：Normative and Informative References」、<http://www.ietf.org/iesg/statement/ normative-informative.html>。
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992, <http://www.rfc-editor.org/info/rfc1311>.
[RFC1311] Postel、J。、「Introduction to the STD Notes」、RFC 1311、1992年3月、<http://www.rfc-editor.org/info/rfc1311>。
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", RFC 1818, August 1995, <http://www.rfc-editor.org/info/rfc1818>.
[RFC1818] Postel、J.、Li、T。、およびY. Rekhter、「Best Current Practices」、RFC 1818、1995年8月、<http://www.rfc-editor.org/info/rfc1818>。
[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997, <http://www.rfc-editor.org/ info/rfc2223>.
[RFC2223] Postel、J。およびJ. Reynolds、「Instructions to RFC Authors」、RFC 2223、1997年10月、<http://www.rfc-editor.org/ info / rfc2223>。
[RFC2223bis] Reynolds, J., Ed. and B. Braden, Ed. "Instructions to Request for Comments (RFC) Authors", Work in Progress, draft-rfc-editor-rfc2223bis-08, August 2004.
[RFC2223bis]レイノルズ、J。、エド。とB.ブレーデン、エド。 「Request for Comments（RFC）Authors for Comments（RFC）Authors for Comment for（RFC）Authors）」、「進行中の作業」、draft-rfc-editor-rfc2223bis-08、2004年8月。
[RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC4844] Daigle、L.、Ed。、and Internet Architecture Board、 "The RFC Series and RFC Editor"、RFC 4844、July 2007、<http://www.rfc-editor.org/info/rfc4844>
[RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009, <http://www.rfc-editor.org/info/rfc5741>.
[RFC5741] Daigle、L.、Ed。、Kolkman、O.、Ed。、and IAB、 "RFC Streams、Headers、and Boilerplates"、RFC 5741、December 2009、<http://www.rfc-editor.org / info / rfc5741>。
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, June 2012, <http://www.rfc-editor.org/info/rfc6635>.
[RFC6635] Kolkman、O.、Ed。、Halpern、J.、Ed。、and IAB、 "RFC Editor Model（Version 2）"、RFC 6635、June 2012、<http://www.rfc-editor.org / info / rfc6635>。
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/ info/std66>.
[STD66] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/ info / std66>。
[TERMS] RFC Editor, "Terms List", <http://www.rfc-editor.org/styleguide.html>.
[用語] RFCエディター、「用語リスト」、<http://www.rfc-editor.org/styleguide.html>。
[YANG-SEC] IETF OPS Area, "yang module security considerations", <http://trac.tools.ietf.org/area/ops/trac/wiki/ yang-security-guidelines>.
[YANG-SEC] IETF OPSエリア、「モジュールのセキュリティに関する考慮事項」、<http://trac.tools.ietf.org/area/ops/trac/wiki/ yang-security-guidelines>。
The following procedures are related to the application and updating of the RFC Style Guide.
以下の手順は、RFCスタイルガイドの適用と更新に関連しています。
There are competing rationales for some of the rules described in this Guide, and the RFC Editor has selected the ones that work best for the Series. However, at times, an author may have a disagreement with the RFC Production Center (RPC) over the application of Style Guide conventions. In such cases, the authors should discuss their concerns with the RPC. If no agreement can be reached between the RPC and the authors, the RFC Series Editor will, with input from the appropriate stream-approving body, make a final determination. If further resolution is required, the dispute resolution process as described in the RFC Editor Model [RFC6635] will be followed.
このガイドで説明されているルールのいくつかには競合する理論的根拠があり、RFCエディターはシリーズに最適なものを選択しています。ただし、場合によっては、スタイルガイドの規則の適用について、RFC Production Center（RPC）と意見が異なることがあります。このような場合、著者はRPCとの懸念について話し合う必要があります。 RPCと作成者の間で合意に達することができない場合、RFCシリーズ編集者は、適切なストリーム承認機関からの入力に基づいて、最終的な決定を行います。さらに解決が必要な場合は、RFCエディターモデル[RFC6635]で説明されている紛争解決プロセスに従います。
For a given document, if the RFC Editor determines that it cannot be edited without serious risk of altering the meaning of the technical content or if the RFC Editor does not have the resources to provide the level of editing it needs, it may be sent back to the stream-approving body with a request to improve the clarity, consistency, and/or readability of the document. This is not to be considered a dispute with the author.
特定のドキュメントについて、技術コンテンツの意味を変更する重大なリスクがないと編集できないとRFCエディターが判断した場合、またはRFCエディターに必要な編集レベルを提供するリソースがない場合は、RFCエディターが送り返されることがあります。ドキュメントの明確性、一貫性、読みやすさを向上させるために、ストリーム承認機関にリクエストを送信します。これは著者との論争とは見なされません。
The RFC Series is continually evolving as a document series. This document focuses on the fundamental and stable requirements that must be met by an RFC. From time to time, the RFC Editor may offer less formal recommendations that authors may apply at their discretion; these recommendations may be found on the RFC Editor website "Guidelines for RFC Style" [STYLE-WEB].
RFCシリーズは、ドキュメントシリーズとして継続的に進化しています。このドキュメントでは、RFCが満たす必要のある基本的で安定した要件に焦点を当てています。 RFCエディターは、執筆者が独自の裁量で適用する可能性のある正式でない推奨事項を提供する場合があります。これらの推奨事項は、RFCエディタのWebサイト「RFCスタイルのガイドライン」[STYLE-WEB]にあります。
When a new recommendation is made regarding the overall structure and formatting of RFCs, it will be published on that page and accepted for a period of time before the RFC Editor determines whether it should become part of the fundamental requirements in the RFC Style Guide or remain as a less formal recommendation. That period of time will vary, in part depending on the frequency with which authors encounter and apply the guidance.
RFCの全体的な構造とフォーマットに関して新しい推奨事項が作成されると、そのページに公開され、RFCエディターがRFCスタイルガイドの基本的な要件の一部になるべきか、それとも残り続けるべきかを決定する前に一定期間受け入れられます。あまり正式ではない推奨事項として。その期間は、一部には著者が出会い、ガイダンスを適用する頻度によって異なります。
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko (IETF Chair) Mary Barnes Marc Blanchet Joel Halpern Ted Hardie Joe Hildebrand Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Brian Trammell
Jari Arkko（IETF議長）メアリーバーンズマークブランシェジョエルハルパーンテッドハーディジョーヒルデブランドラスヒュースリーエリオットリアシンリーエリックノードマークアンドリューサリバンデイブターラーブライアントランメル
Acknowledgements
謝辞
This document refers heavily to RFC 2223 [RFC2223] and [RFC2223bis]; as such, we are grateful to the authors of those documents for putting their time and effort into the RFC Series.
このドキュメントでは、RFC 2223 [RFC2223]および[RFC2223bis]に大きく言及しています。そのため、これらのドキュメントの作成者がRFCシリーズに時間と労力を費やしてくれたことに感謝します。
Robert T. Braden USC Information Sciences Institute
ロバートT.ブレーデンUSC情報科学研究所
Joyce Reynolds
ジョイス・レイノルズ
Jon Postel
ジョン郵便
Contributors
貢献者
Alice Russo RFC Production Center
アリスルッソRFCプロダクションセンター
Authors' Addresses
著者のアドレス
Heather Flanagan RFC Series Editor
ヘザーフラナガンRFCシリーズエディター
EMail: rse@rfc-editor.org
Sandy Ginoza RFC Production Center
さんｄｙ ぎのざ ＲＦＣ Ｐろづｃちおん せんてｒ
EMail: rfc-editor@rfc-editor.org