1969 年 4 月 7 日付、Steve Crocker による「ホスト ソフトウェア」というタイトルの文書。これは、ネットワーク ワーキング グループからの最初の RFC (Request for Comments) です。
1969 年 4 月 7 日に公開された RFC 1 が最初の RFC です。

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

IETFは、RFCとして公開された提案の一部をインターネット標準として採用しています。しかし、多くのRFCは情報提供や実験的な性質を持ち、標準ではありません。[4] RFCシステムは、 1969年にスティーブ・クロッカーによって、 ARPANETの開発に関する非公式な記録を支援するために発明されました。RFCはその後、インターネットの仕様、通信プロトコル、手順、イベントに関する公式文書となりました。[5]クロッカーによると、これらの文書は「インターネットの内部的な仕組みを形作り、その成功に重要な役割を果たしてきた」ものの、コミュニティの外部では広く知られていません。[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）の一つであったからです。ダグラス・エンゲルバートが率いるスタンフォード研究所のAugmentation Research Center（ARC）は、ARPANETノードの最初の4つのうちの1つであり、初期のRFCの発信源でもありました。ARCは最初のネットワーク情報センター（InterNIC ）となり、エリザベス・J・ファインラーが運営し、RFCやその他のネットワーク情報を配布しました。[11]

1978年のエイプリルフールには、TCP/IPの文書化スタイルをパロディ化したRFC 748が公開されました。これは1989年にRFC 1097が公開されたことで再び注目を集め、 Telnetクライアントがサブリミナルメッセージを表示するオプションが規定されました。その後もエイプリルフール関連のRFCは毎年公開されており、中でも注目すべきは、ハイパーテキストコーヒーポット制御プロトコルを規定し、HTTP 418「私はティーポットです」ステータスを定義したRFC 2324です。ユーモラスなRFCの起源は、1973年1月に公開されたRFC 439に遡ります。

RFCエディター機能

ジョン・ポステルは1969年から1998年までRFC編集者を務めました。1998年に亡くなった際には、彼の死亡記事がRFC 2468として出版されました。[12]

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

2007年7月、 RFCのストリームが定義されたため、編集業務を分割できるようになりました。IETFドキュメントは、IETFワーキンググループまたはインターネットエンジニアリングステアリンググループのIETFエリアディレクターがスポンサーとなった提出物から提供されました。IABは独自のドキュメントを公開できます。ドキュメントの研究ストリームは、インターネット調査タスクフォース（IRTF）から提供され、独立したストリームは他の外部ソースから提供されます。[14]新しいモデルは2008年に提案され、改良され、2009年8月に公開され、タスクがRFCシリーズアドバイザリグループ（RSAG）を含むいくつかの役割に分割されました。[15]このモデルは2012年、 [16]、2020年に更新されました。 [17] ストリームも2009年12月に改良され、スタイルの標準が定義されました。[18] 2010年1月、RFCエディター機能は請負業者であるAssociation Management Solutionsに移管され、Glenn Kowackが暫定シリーズエディターを務めました。[19] 2011年後半、ヘザー・フラナガンがRFCシリーズ編集者（RSE）に就任しました。また、同時期にRFCシリーズ監督委員会（RSOC）も設立されました。[20]

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月、アレクシス・ロッシ氏がその役職に任命されました。[21]

新しい出版フォーマット

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

制作とバージョン管理

RFCエディターは各RFCにシリアル番号を割り当てます。一度番号が割り当てられ公開されたRFCは、撤回または変更されることはありません。文書に修正が必要な場合は、作成者は改訂版を公開します。そのため、一部のRFCは他のRFCに取って代わります。置き換えられたRFCは、非推奨、廃止、または置き換え元のRFCによって廃止されたとみなされます。シリアル化されたRFCは、インターネット標準と実践の進化の継続的な履歴記録を構成します。RFCプロセスは、RFC 2026（インターネット標準化プロセス、改訂3）に文書化されています。[23]

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

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

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

サブシリーズ

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

RFCの入手

ワールドワイドウェブ上のRFCの公式ソースはRFC Datatrackerです。公開されているRFCのほぼすべては、 https: //datatracker.ietf.org/doc/html/rfc5000 （RFC 5000 の場合）という形式のURLで取得できます。

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

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

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

状態

すべてのRFCが標準というわけではありません。[29] 各RFCには、インターネット標準化プロセスにおけるステータスに応じて指定が与えられます。このステータスは、Informational（情報提供） 、Experimental（実験的） 、Best Current Practice（現在のベストプラクティス）、Standards Track（標準化過程）、Historic（歴史的）のいずれかです。[30]

一度提出され、受理され、公開されたRFCは変更できません。エラッタを提出することは可能ですが、エラッタは別途公開されます。より重要な変更には、新たな提出が必要となり、新たなシリアル番号が付与されます。[31]

標準化トラック

標準化トラック文書はさらに提案標準文書とインターネット標準文書に分かれています。[32]

標準化過程のRFC を承認できるのは、インターネット エンジニアリング ステアリング グループ(IESG)が代表する IETF のみです。

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

インターネット標準が更新されると、その 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は、広く受け入れられ、うまく機能する場合、標準化トラックに昇格される可能性があります。[34]

現在のベストプラクティス

Best Current Practiceサブシリーズは、公式ルールとみなされ、情報提供のみでなく、ネットワーク上のデータに影響を与えない管理文書やその他のテキストを収集しています。標準化過程とBCPの境界はしばしば曖昧です。BCP 9 [35]やIETF管理のように、インターネット標準化プロセスにのみ影響を与える文書は明らかにBCPです。一方、 IANA（ Internet Assigned Numbers Authority）レジストリの規則と規制のみを定義する文書は、境界が明確ではありません。これらの文書のほとんどはBCPですが、標準化過程にあるものもあります。

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

歴史的

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

未知

ステータス「不明」は、非常に古いRFCの一部に使用されます。これらのRFCは、今日公開された場合、どのようなステータスになるか不明です。これらのRFCの中には、今日では全く公開されないものもあります。初期のRFCは、プロトコル、管理手順、あるいは今日のRFCシリーズで使用されているその他の事項を規定することを意図していない、単なるコメント要請（Request for Comments）に過ぎないことがよくありました。[37]

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

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

参照

参考文献

  1. ^ abc P. Saint-Andre編 (2022年6月). RFCエディタモデル（バージョン3）.インターネットアーキテクチャ委員会. doi : 10.17487/RFC9280 . ISSN  2070-1721. RFC 9280. 情報提供。RFC 8728 を廃止。RFC 7841、8729、8730 を更新。
  2. ^ "RFC". IETF . 2023年11月5日閲覧。
  3. ^ Waitzman, David (1990年4月1日). 鳥類キャリアにおけるIPデータグラムの伝送に関する標準. IETF . doi : 10.17487/RFC1149 . RFC 1149. 2017年3月29日閲覧.
  4. ^ ab Huitema, Christian ; Postel, Jon ; Crocker, Steve (1995年4月). Not All RFCs are Standards. IETF . doi : 10.17487/RFC1796 . RFC 1796. 2018年5月15日閲覧。
  5. ^ 「RFC、インターネットのコメント要求（Request For Comments）」Livinginternet.com . 2012年4月3日閲覧。
  6. ^ ab 「スティーブン・D・クロッカー『インターネットのルールはいかにして生まれたのか』ニューヨーク・タイムズ、2009年4月6日」ニューヨーク・タイムズ、2009年4月7日。 2012年4月3日閲覧。
  7. ^ 「通知とコメント要請」連邦官報2018年1月16日
  8. ^ ハフナー、ケイティ、リヨン、マシュー (1996). 『魔法使いたちが夜更かしする場所：インターネットの起源』タッチストーンブック. サイモン＆シュスター. ISBN 978-0-684-81201-4。
  9. ^ Metz, Cade (2012年5月18日). 「インターネットの命令を発明した男に会う」. Wired . 2018年12月18日閲覧。
  10. ^ S. Crocker編（1969年4月7日）. ホストソフトウェア. ネットワークワーキンググループ. doi : 10.17487/RFC0001 . RFC 1. ステータスは不明です。
  11. ^ Elizabeth J. Feinler (2010年7月～9月). 「ネットワーク情報センターとそのアーカイブ」Annals of the History of Computing . 32 (3): 83– 89. doi : 10.1109/MAHC.2010.54 . S2CID 206443021 . 
  12. ^ V. Cerf (1998年10月17日). I Remember IANA. Network Working Group. doi : 10.17487/RFC2468 . RFC 2468. 情報提供。
  13. ^ Leslie Daigle (2010年3月). 「RFCエディターの変遷：過去、現在、そして未来」. The Internet Protocol Journal . 第13巻第1号. Cisco Systems. 2010年9月20日時点のオリジナルよりアーカイブ。 2011年8月17日閲覧。
  14. ^ L. Daigle編（2007年4月）. RFCシリーズおよびRFCエディタ. ネットワークワーキンググループ. doi : 10.17487/RFC4844 . RFC 4844. 廃止。RFC 8729 により廃止。RFC 5741 により更新。
  15. ^ O.コルクマン編。 (2009 年 8 月)。 RFC エディター モデル (バージョン 1)。インターネットアーキテクチャ委員会。土井: 10.17487/RFC5620。 RFC 5620。 廃止。RFC 6635 および 6548 によって廃止されました。
  16. ^ O. Kolkman、J. Halpern編（2012年6月）。RFCエディタモデル（バージョン2）。インターネットアーキテクチャ委員会。doi : 10.17487/RFC6635。RFC 6635 。 廃止。RFC 8728 により廃止。RFC 5620 より廃止。
  17. ^ O. Kolkman、J. Halpern、R. Hinden編（2020年2月）。RFCエディターモデル（バージョン2）。インターネットアーキテクチャ委員会。doi : 10.17487/RFC8728。RFC 8728。 情報提供。RFC 9280 により廃止。RFC 6635 を廃止。
  18. ^ ab A. Falk (2009年12月). RFC ストリーム、ヘッダー、および定型句. Internet Research Task Force . doi : 10.17487/RFC5741 . ISSN  2070-1721. RFC 5741. 廃止。RFC 7841 により廃止。RFC 2223、4844 を更新。
  19. ^ Glenn Kowack (2010年1月7日). “RFC Editor Transition Announcement”. 2011年6月29日時点のオリジナルよりアーカイブ。
  20. ^ 「RFCシリーズ編集者とシリーズの再編成」。2013年4月5日時点のオリジナルよりアーカイブ。2013年4月5日閲覧。
  21. ^ 「アレクシス・ロッシがRFCシリーズのコンサルティングエディターに任命」。2023年8月19日閲覧。
  22. ^ 「RFC フォーマット変更に関する FAQ」。
  23. ^ ab "RFC Index". RFC Editor. 2008年5月25日. 2008年5月26日閲覧。
  24. ^ IETFワーキンググループのガイドラインと手順. doi : 10.17487/RFC2418 . RFC 2418.
  25. ^ この記事は、 2008 年 11 月 1 日より前のFree On-line Dictionary of Computingの Request+for+Comments から取得した資料に基づいており、 GFDLバージョン 1.3 以降 の「再ライセンス」条項に基づいて組み込まれています。
  26. ^ 「Independent Submissions」RFCエディター. 2018年1月5日閲覧。
  27. ^ Klensin, John; Thaler, David (2007年7月). RFC編集者への独立した投稿. IAB . doi : 10.17487/RFC4846 . RFC 4846.>
  28. ^ Alvestrand, Harald; Housley, Russ (2009年12月). IESGによる独立ストリームおよびIRTFストリーム送信の取り扱い手順. IETF . doi : 10.17487/RFC5742 . RFC 5742.
  29. ^ 「RFCはすべてインターネット標準文書か？」RFCエディター. 2018年3月16日閲覧。
  30. ^ C. Huitema ; J. Postel ; S. Crocker (1995年4月). 「すべてのRFCが標準ではない」. ネットワークワーキンググループ. doi : 10.17487/RFC1796 . RFC 1796. 情報提供。
  31. ^ Nottingham, Mark (2018年7月31日). 「RFCの読み方」 . 2023年9月18日閲覧。RFCはアーカイブ文書であり、変更することはできません。
  32. ^ Housley, Russell; Crocker, Dave; Burger, Eric (2011年10月). 標準化過程の成熟度レベルを2段階に削減. IETF . doi : 10.17487/RFC6410 . RFC 6410.
  33. ^ 「インターネット 公式プロトコル標準」概要文書の廃止。doi : 10.17487/RFC7100。RFC 7100。
  34. ^ 「7.5. 情報RFCと実験RFC」。IETFの道。 2017年11月26日閲覧。
  35. ^ Bradner, Scott O. (1996年10月). インターネット標準化プロセス – 改訂3. IETF . BCP 9. 2017年10月25日閲覧。
  36. ^ 「IESGによるRFCの歴史的指定に関する声明」IETF、2014年7月20日。 2016年4月14日閲覧。
  37. ^ 「ISC貢献者によるIETF標準」. Internet Systems Consortium . 2021年9月10日. 2022年4月5日時点のオリジナルよりアーカイブ。2022年4月11日閲覧。初期のRFC文書の多くは「不明」ステータスとなっている。これは、RFCが実際には単なるコメントの要請であった遠い昔の時代のものであるためである。
  38. ^ 「RFCの複製」IETF Trust . 2021年8月12日閲覧。
  39. ^ Bradner, Scott; Contreras, Jorge (2008年11月). IETF Trustに貢献者が付与する権利. IETF . doi : 10.17487/RFC5378 . RFC 5378.
  40. ^ 「RFCの複製」IETF Trust . 2021年8月13日閲覧。
Wikidata には次のプロパティがあります:
  • RfC ID (P892) (用途を参照)
  • RFCエディター
  • RFCデータベース
  • RFCエラッタ
  • RFC よくある質問
  • RFC インデックス (テキスト)
  • 公式インターネットプロトコル標準
  • IETFのRFCページ
  • RFC インデックス (HTML) 各 RFC のテキストとともに、この RFC が他のどの RFC を「更新」するか、または「この RFC によって更新される」かについても説明します。