コメントのリクエスト

RFC ( Request for Comments ) は、インターネットの主要な技術開発および標準設定団体、最も有名なのはインターネット技術タスクフォース(IETF) が発行する一連の出版物です。^{[1] [2]} RFC は、インターネットおよびインターネット接続システムの動作に適用される方法、動作、研究、または革新を記述した覚書の形式で、エンジニアやコンピュータ科学者の個人またはグループによって作成されます。RFC は、ピアレビューのため、または新しい概念、情報、または時にはエンジニアリングのユーモアを伝えるために提出されます。 ^[3]

IETF は、RFC として公開された提案の一部をインターネット標準として採用しています。ただし、多くの RFC は情報提供や実験的な性質のものであり、標準ではありません。^{[4] RFC システムは、1969 年に}Steve Crockerによって発明され、ARPANETの開発に関する非公式のメモを記録するために使用されました。RFC はその後、インターネットの仕様、通信プロトコル、手順、イベントの公式文書になりました。 ^[5] Crocker によると、これらの文書は「インターネットの内部動作を形作り、その成功に重要な役割を果たしてきた」が、コミュニティの外部では広く知られていません。^[6]

インターネットコミュニティの外では、米国連邦政府の文書、例えば国家道路交通安全局などでも、意見要請と呼ばれる文書が公開されている。^[7]

RFCフォーマットは、1969年にARPANETプロジェクトの一環として始まりました。^[6]現在、RFCはインターネット技術タスクフォース（IETF）、インターネットアーキテクチャ委員会（IAB）、そしてある程度はコンピュータネットワーク研究者の世界的なコミュニティの公式出版チャネルとなっています。

最初のRFCの著者は、その内容をタイプライターで書き、 ARPAの研究者の間でハードコピーを回覧しました。現代のRFCとは異なり、初期のRFCの多くは、実際にはRequest for Commentsであり、宣言的になりすぎないようにし、議論を促すためにそのようなタイトルが付けられました。^{[8] [9]} RFCは質問を未解決のままにし、あまり形式ばらないスタイルで書かれています。この形式ばらないスタイルは、RFCとして承認される前の前段階であるインターネットドラフト文書の典型的なスタイルです。

1969年12月、研究者たちは新たに運用を開始したARPANET経由で新しいRFCの配布を開始した。RFC 1「ホストソフトウェア」はカリフォルニア大学ロサンゼルス校（UCLA）のスティーブ・クロッカーによって書かれ、1969年4月7日に公開された。 ^[10]スティーブ・クロッカーによって書かれたが、RFCはスティーブ・クロッカー、スティーブ・カー、ジェフ・ルリフソンによる初期のワーキンググループの議論から生まれたものであった。

でRFC シリーズを初めて定義した RFC 3 以降、クロッカーは RFC シリーズをネットワーク ワーキング グループに帰属させ始めました。このグループは正式な委員会ではなく、ARPANET プロジェクトに関心を持つ研究者の緩やかな団体でした。実質的に、このグループには、プロジェクトに関する会議や議論に参加したい人なら誰でも参加できました。

1970年代のその後のRFCの多くもUCLAから発信された。UCLAはARPANETのインターフェイスメッセージプロセッサ（IMP）の最初の1つだったからだ。ダグラス・エンゲルバートが率いるスタンフォード研究所のAugmentation Research Center（ARC）は、ARPANETノードの最初の4つのうちの1つであり、初期のRFCの発信源であった。ARCは最初のネットワーク情報センター（InterNIC ）となり、エリザベス・J・ファインラーが管理し、RFCやその他のネットワーク情報を配布した。^[11]

1969 年から 1998 年まで、Jon Postel がRFC編集者を務めました。1998 年に彼が亡くなったとき、彼の死亡記事がRFC 2468 として出版されました。

米国連邦政府との当初のARPANET契約の期限切れ後、IETFに代わってインターネット協会が南カリフォルニア大学（USC）情報科学研究所（ISI）のネットワーク部門と契約し、IABの指示の下で編集と出版の責任を引き継いだ。サンディ・ギノザは1999年にUSC/ISIに加わりRFC編集に携わり、アリス・ハーゲンズは2005年に加わった。^[12] ボブ・ブレイデンがRFCプロジェクトリーダーの役割を引き継ぎ、ジョイス・K・レイノルズは2006年10月13日までチームの一員として活動した。

2007年7月、 RFCのストリームが定義され、編集業務を分割できるようになりました。IETF文書は、IETFワーキンググループまたはインターネットエンジニアリングステアリンググループのIETFエリアディレクターがスポンサーとなった提出物から提供されました。IABは独自の文書を公開できます。文書の研究ストリームは、インターネットリサーチタスクフォース（IRTF）から提供され、独立したストリームは他の外部ソースから提供されます。^{[13] 2008}年に新しいモデルが提案され、改良され、2009年8月に公開され、タスクがRFCシリーズアドバイザリグループ（RSAG）を含むいくつかの役割に分割されました。[14] このモデルは2012年に更新されました。^[15]ストリームも2009年12月に改良され、スタイルの標準が定義されました。^[16]

2010年1月、RFC編集者の機能は請負業者であるAssociation Management Solutionsに移管され、Glenn Kowackが暫定シリーズ編集者を務めました。^[17] 2011年後半、Heather Flanaganが常任RFCシリーズ編集者（RSE）として採用されました。また、その時にRFCシリーズ監視委員会（RSOC）が設立されました。^[18]

2020年、IABはRFCエディター将来開発プログラムを開催し、RFCエディターモデルの潜在的な変更について議論しました。プログラムの結果は、2022年6月に公開されたRFC 9280で定義されているRFCエディターモデル（バージョン3）に含まれていました。 ^[1]一般的に、新しいモデルは、RFCシリーズとRFCエディター機能に関連するポリシーの定義と実装の責任とプロセスを明確にすることを目的としています。新しいモデルの変更には、RFCコンサルティングエディター、RFCシリーズワーキンググループ（RSWG）、およびRFCシリーズ承認委員会（RSAB）の役職の確立が含まれます。また、RFCシリーズの新しい編集ストリームを確立し、RSOCを終了しました。RSEの役割はRFCシリーズコンサルティングエディター（RSCE）に変更されました。2022年9月、アレクシスロッシがその役職に任命されました。^[19]

当初、RFPはリフロー不可能なテキスト形式で作成されていました。2019年8月に、新しい文書がさまざまなディスプレイサイズのデバイスで最適に表示されるように、形式が変更されました。^[20]

RFC エディタは各 RFC にシリアル番号を割り当てます。番号が割り当てられて公開された RFC は、取り消されたり変更されたりすることはありません。文書に修正が必要な場合は、著者が改訂版を発行します。そのため、一部の RFC は他の RFC に取って代わります。置き換えられた RFC は、廃止予定、廃止、または置き換え元の RFCによって廃止されたと言われます。シリアル化された RFC は、インターネット標準と実践の進化の継続的な歴史的記録を構成します。RFC プロセスは、RFC 2026 (インターネット標準化プロセス、リビジョン 3 ) に文書化されています。^[21]

RFCの作成プロセスは、国際標準化機構（ISO）などの正式な標準化組織の標準化プロセスとは異なります。インターネット技術の専門家は、外部機関のサポートなしにインターネットドラフトを提出することができます。標準化トラックRFCはIETFの承認を得て公開され、通常はIETFワーキンググループに参加している専門家によって作成され、最初にインターネットドラフトが公開されます。このアプローチにより、文書がRFCに成熟する前に、最初のピアレビューラウンドが容易になります。^[22]

RFCの伝統は、個人や小規模なワーキンググループによって、実用的で経験に基づいた事後的な標準の執筆が行われており、ISOや国家標準化団体に典型的な、より形式的で委員会主導のプロセスに比べて重要な利点^{（説明が必要）がある可能性がある。 [23]}

ほとんどのRFCでは、RFCの一貫性を保ち、理解しやすいように、「MUST」や「NOT RECOMMENDED」（RFC 2119および8174で定義）などの共通の用語セット、メタ言語としての拡張バッカスナウア記法（ABNF）（RFC 5234）、および単純なテキストベースのフォーマットを使用しています。^[21]

RFC シリーズには、 IETF RFCの 3 つのサブシリーズ(BCP、FYI、STD) が含まれています。Best Current Practice (BCP) は、標準化の過程にない必須の IETF RFC のサブシリーズです。For Your Information (FYI) は、RFC 1150 (FYI 1) で指定されているように、IETF によって推進されている情報 RFC のサブシリーズです。2011 年、RFC 6360 によって FYI 1 が廃止され、このサブシリーズは終了しました。Standard (STD) は、RFC 2026 (BCP 9) で指定されている IETF 標準化過程の 3 番目で最も成熟度の高いレベルでした。2011 年、RFC 6410 (BCP 9 の新しい部分) によって、標準化過程の成熟度が 2 つに削減されました。^{[引用が必要]}

RFC には、 IETF、IRTF、IAB、独立提出、^[24]、編集の 5 つのストリームがあります。^[1]標準化トラックで BCP と RFC を作成するのは IETF だけです。IAB は、ポリシーやアーキテクチャに関する情報文書を公開します。IRTF は、情報文書または実験として、研究結果を公開します。独立提出は、独立提出編集者の裁量で公開されます。IETF 以外の文書は、 IETF の作業と競合するかどうかについてIESGによってレビューされます。IRTF および独立 RFC には通常、IETF の作業と競合しない、インターネット全体に関連する情報または実験が含まれています。RFC 4846、5742、5744を比較してください。 ^{[25] [26]}編集ストリームは、RFC シリーズ全体の編集ポリシーの変更に使用されます (RFC 9280 を参照)。^[1]

World Wide Web上の RFC の公式ソースは、RFC Datatracker です。公開されているほぼすべての RFC は、RFC 5000 の場合に表示される https://datatracker.ietf.org/doc/html/rfc5000 形式のURLを介して取得できます。

すべての RFC はプレーンASCIIテキストとして送信され、その形式で公開されますが、他の形式でも利用できる場合があります。

RFC のメタデータ (概要、キーワード、著者、発行日、正誤表、ステータス、特にその後の更新情報など) に簡単にアクセスできるように、RFC エディター サイトでは多くの機能を備えた検索フォームを提供しています。リダイレクトにより、いくつかの効率的なパラメータが設定されます (例: rfc:5000)。^[4]

RFCシリーズの公式国際標準シリアル番号（ISSN）は2070-1721です。 ^[16]

すべてのRFCが標準というわけではありません。^{[27] [28]各RFCには、インターネット標準化プロセスにおけるステータスに応じて指定が割り当てられます。このステータスは、}情報、実験、現在のベストプラクティス、標準化過程、または歴史的のいずれかです。

一度提出され、承認され、公開されたRFCは変更できません。エラッタは提出できますが、別途公開されます。より重要な変更には、新しいシリアル番号が付与される新しい提出が必要です。^[29]

標準化過程の文書はさらに提案標準文書とインターネット標準文書に分かれています。^[30]

標準化過程のRFC を承認できるのは、 Internet Engineering Steering Group (IESG)が代表する IETF のみです。

RFCがインターネット標準（STD）になると、STD番号が割り当てられますが、RFC番号は保持されます。インターネット標準の最終的なリストは、公式インターネットプロトコル標準です。以前は、STD 1がリストのスナップショットを維持していました。^[31]

インターネット標準が更新されると、その STD 番号は変わりませんが、新しい RFC または RFC セットを参照するようになります。特定のインターネット標準 STD n は、特定の時点ではRFC xおよびyであった可能性がありますが、後に同じ標準が RFC zに更新されることがあります。たとえば、2007 年にはRFC 3700 はインターネット標準 (STD 1) でしたが、2008 年 5 月にRFC 5000 に置き換えられたため、 RFC 3700 はHistoricに変更され、RFC 5000 がインターネット標準となり、2008 年 5 月の時点でSTD 1 はRFC 5000 になりました。2013 年 12 月の時点でRFC 5000 は RFC 7100 に置き換えられ、RFC 2026 は STD 1 を使用しなくなるように更新されました。 ^{[アップデート][アップデート]}

(Best Current Practices も同様に機能します。BCP n は特定の RFC または RFC セットを参照しますが、どの RFC または RFC が時間の経過とともに変更される可能性があります)。

情報 RFC には、4 月 1 日のジョークから、ドメイン ネーム システムの構造と委任 ( RFC 1591)などの広く認識されている重要な RFC まで、ほぼあらゆるものが含まれます。一部の情報 RFC はFYIサブシリーズ を形成しました。

実験的RFCはIETF文書またはRFCエディタへの個別の提出物である。提案が意図したとおりに機能するかどうか不明な場合、または提案が広く採用されるかどうか不明な場合は、ドラフトは実験的と指定される。実験的RFCは、人気が出てうまく機能する場合は、標準化トラックに昇格される可能性がある。^[32]

Best Current Practiceサブシリーズは、情報提供のみでなく、有線データには影響を及ぼさない公式ルールとみなされる管理文書やその他のテキストを収集しています。標準化過程とBCPの境界は、多くの場合不明瞭です。文書がBCP 9 ^{[33]やIETF管理のようにインターネット標準化プロセスにのみ影響する場合、それは明らかにBCPです。}インターネット割り当て番号機関（IANA）レジストリのルールと規制のみを定義する場合、それはそれほど明確ではありません。これらの文書のほとんどはBCPですが、いくつかは標準化過程にあります。

BCP シリーズには、インターネット標準の実践方法に関する技術的な推奨事項も含まれています。たとえば、ソース フィルタリングを使用してDoS 攻撃をより困難にする推奨事項 ( RFC 2827:「ネットワーク イングレス フィルタリング: IP ソース アドレス スプーフィングを使用するサービス拒否攻撃の阻止」) は BCP 38 です。

歴史的RFCとは、RFCで定義された技術がもはや使用が推奨されていないRFCであり、代替RFCの「Obsoletes」ヘッダーとは異なります。たとえば、RFC 821 ( SMTP ) 自体はさまざまな新しいRFCによって廃止されていますが、SMTP自体はまだ「現在の技術」であるため、「歴史的」ステータスではありません。^[34]ただし、BGPバージョン4は以前のBGPバージョンを完全に置き換えたため、RFC 1267などの以前のバージョンを説明するRFCは歴史的に指定されています。

ステータス不明は、非常に古いRFCの一部に使用されます。これらのRFCは、今日公開された場合、その文書がどのようなステータスになるか不明です。これらのRFCの一部は、今日ではまったく公開されません。初期のRFCは、多くの場合、単なるコメント要求であり、プロトコル、管理手順、または今日のRFCシリーズで使用されているその他のものを指定することを意図していませんでした。^[35]

一般的なルールとしては、明示的に権利を譲渡しない限り、原作者（または雇用条件にその旨が定められている場合は雇用主）が著作権を保持するというものです。^[36]

独立機関であるIETFトラストは、一部のRFCの著作権を保有しており、その他すべてのRFCについては、著者からRFCの複製を許可するライセンスを付与されています。^[37]インターネット協会は、RFC4714より前の多くのRFCで著作権所有者として言及されていますが、その権利をIETFトラストに譲渡しました。^[38]

• 現在のベストプラクティス
• インターネット実験ノート
• RFC のリスト

Wikidata には次のプロパティがあります:

• RfC ID (P892) (用途を参照)

• RFC エディター
• RFC データベース
• RFC エラッタ
• RFC よくある質問
• RFC インデックス (テキスト)
• 公式インターネットプロトコル標準
• IETFのRFCページ
• RFC インデックス (HTML) 各 RFC のテキストとともに、この RFC が「更新」する他の RFC や「更新元」の RFC についても説明します。