Request for Comments

IETFによる技術仕様の保存、公開形式 ウィキペディアから

Request for Comments(リクエスト フォー コメンツ、略称:RFC)はIETF(インターネット技術特別調査委員会、: Internet Engineering Task Force)による技術仕様保存、公開形式である。内容には特に制限はないが、通信プロトコルファイルフォーマットが主に扱われる。

RFCとは「コメント募集」を意味する英語の略語であり、もともとは技術仕様を公開し、それについての意見を広く募集してより良いものにしていく観点から始められたようである。今日では、IETFIAB (インターネットアーキテクチャ委員会、: Internet Architecture Board)、およびコンピュータネットワーク研究者の世界的なコミュニティの公式発表の場となっている。

RFCは基本的に英語で書かれており、公式の翻訳版は存在しない。

なお、IETF以外の組織・コミュニティにおいても、同様の目的の文書群をRFCと呼称する事例が存在する。

歴史

要約
視点

RFCというコンセプトは、1969年にARPANETプロジェクトにおいて生まれた[1]

初期のRFCはタイプライターで執筆され、高等研究計画局(略称ARPA、後にDARPAへ改名)の研究者にそれをコピーした紙が配布された。現在のRFCとは異なり、初期のRFCの多くは文字通り実際にコメントを求めるものであり、宣言のような響きを避け、議論を促すために"Request for comments"という名前が付けられた[2][3]。初期のRFCは、あまり形式ばらないスタイルで書かれていた。

RFC 1 は、カリフォルニア大学ロサンゼルス校(UCLA)のスティーブ・クロッカーが執筆し、1969年4月7日に発行された「ホスト・ソフトウェア」である[4]。このRFCは、執筆したのはクロッカーであるが、クロッカーとスティーブ・カー、ジェフ・ルリフソンによる初期のワーキンググループでの議論により生まれたものである。

クロッカーが執筆した RFC 3 で「RFCとは何であるか」を初めて定義し、RFCはARPAのネットワーク・ワーキンググループに帰属するものとされた。ただし、これは正式な委員会ではなく、ARPANETプロジェクトに関心のある研究者のゆるやかな集まりであり、誰でも参加できた。

ARPANETが1969年12月に稼働し始めると、RFCの配布はARPANET上で行われるようになった。最初にネットワークで配布されたRFCはRFC 114であった[5]UCLAにはARPANETの最初のIMP(Interface Message Processor)の一つが置かれていたため、1970年代のRFCの多くもUCLAから発信された。ダグラス・エンゲルバートが所長を務めたスタンフォード研究所オーグメンテイション研究センター(ARC)は、ARPANETの最初の4つのノードのうちの1つであり、初期のRFCもここから発信された。ARCには最初のNIC(のちのInterNIC)が置かれ、エリザベス・J・フェインラーが管理し、他のネットワーク情報とともにRFCを配布した[6]

1974年に発行されたRFC 675inter-networkingの略語としてはじめて「Internet」の語がつかわれた。

1977年頃、ARPANETプロジェクトとは別にInternetプロジェクトが発足した際に、ARPANETプロジェクトのRFCというコンセプトを模倣して、インターネット実験ノート: Internet Experiment Note、IEN)という類似の文書シリーズを発行することにした。またRFCのコンセプトを模倣した文書シリーズは IEN だけではなく、INWG Note[注釈 1]や、PRNET Notes、ARPA Satellite System Notes など多くプロジェクトでRFCを模倣した類似の文書シリーズが存在した[7]

これらのシリーズは完全に独立したものではなく、複数のプロジェクトに関係する文書は複数のシリーズでナンバリングをされているものも存在する。例えば前述のRFC 675は INWG 72 でもあり、またRFC 761は IEN 129 でもある。

1983年にARPANETはそれまでのNetwork Control Program(NCP)プロトコルを、Internetプロジェクトの成果物であるTCP/IPに移行した。それを機に、あるいはそれと前後して、これらの類似の文書シリーズはRFCに統合されていった[7]

1988年、IABインターネットドラフト: Internet Draft)シリーズの作成が承認された[5]。これにより最初期の「コメント募集」という位置づけと形式ばらないスタイルが、RFCとして承認される前段階であるインターネットドラフトに引き継がれた。

RFCの歴史については以下のRFCにまとめられている。

  • RFC 1000 "The Request for Comments Reference Guide"(1987年8月)
  • RFC 2555 "30 Years of RFCs"(1999年4月)
  • RFC 5540 "40 Years of RFCs"(2009年4月)
  • RFC 8700 "Fifty Years of RFCs"(2019年12月)

RFC編集者の役割

1969年から1998年までは、ジョン・ポステルがRFC編集者(: RFC editor)を務めた。1998年にポステルが亡くなると、彼の訃報が RFC 2468 として発表された。

アメリカ連邦政府とのARPANETの契約が切れた後、IETFを代表してインターネットソサエティ南カリフォルニア大学(USC)情報科学研究所(ISI)のネットワーク部門と契約し、IABの指示の下でRFCの編集および発行を行うことになった[8]

2007年7月にRFC発行の流れ(: RFC stream)が定義され、編集作業を分担できるようになった[9]

2010年1月、RFC編集者の役割は Association Management Solutions に移管され、Glenn Kowack が暫定のシリーズ編集者を務めた[10]。2011年後半、Heather Flanagan が常任のRFCシリーズ編集者(: RFC Series Editor、RSE)として採用された。また、その時にRFCシリーズ監視委員会(: RFC Series Oversight Committee、RSOC)が設立された[11]

2020年、IABは RFC Editor Future Development プログラム開催し、RFC編集者のモデル変更の可能性について議論した。プログラムの結果は、2022年6月に公開されたRFC 9280で定義されているRFC編集者モデル(バージョン3)に含まれている。一般的に、新しいモデルは、RFCシリーズとRFC編集者の役割に関連するポリシーの定義と実装の責任とプロセスを明確にすることを目的としている。新しいモデルの変更には、RFCコンサルティング編集者(: RFC Consulting Editor)、RFCシリーズワーキンググループ(: RFC Series Working Group、RSWG)、およびRFCシリーズ承認委員会(: RFC Series Approval Board、RSAB)の役職の確立が含まれる。また、RFCシリーズの新しい編集の流れを確立し、RSOCを終了した。RSEの役割はRFCシリーズコンサルティング編集者(: RFC Series Consulting Editor、RSCE)に変更され、2022年9月 Alexis Rossiがその役職に任命された[12]

作成

要約
視点

RFCの作成プロセスは、RFC 2026 "The Internet Standards Process, Revision 3" で定義されている(一部が RFC 6410により更新されている)。

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

RFCのスタイルガイドは RFC 7322 で定義されている。また、RFC編集者のサイトでスタイルガイド関連資料が紹介されている[14]。ほとんどのRFCでは一貫性を保ち理解しやすいように「MUST」や「NOT RECOMMENDED」などの共通の用語セット(RFC 2119およびRFC 8174を参照)、メタ言語としての拡張バッカスナウア記法(ABNFRFC 5234を参照)、および単純なテキストベースのフォーマットを使用している[注釈 2]

初期のRFCは固定幅の整形済みテキスト形式で作成されていたが、2019年8月にRFC文書をさまざまな表示サイズのデバイスで最適に表示できるように、リフロー可能な形式に変更された[15]

バージョン管理

RFC編集者はRFCを公開する際に一連の番号を割り当てる[注釈 3]。一度番号が割り当てられ公開されたRFCは、取り消されたり変更されたりすることはない[注釈 4][16]。誤字などの誤りがあった場合には、別途正誤表(: errata)が公開されることがある。

公開済のRFCに大きな修正が必要な場合は、新しいRFCとして改訂版を発行する。そのため、一部のRFCは他のRFCを置き換えることがある。他のRFCを置き換えたRFCは「置き換え先のRFCを廃止した(: obsolete)」と言い、置き換えられたRFCは「置き換え元のRFCによって廃止された(: obsoleted by)」と言う。例えばRFC 5000RFC 7100によって破棄されたため、RFCインデックスなどにはRFC 5000には Obsoleted-By RFC7100 と記載があり、RFC 7100には、Obsoletes RFC5000 という記載がある。

またRFC文書の全体を廃止するのではなく、一部を上書きするケースもある。この場合には他のRFCを上書きしたRFCは「上書き先のRFCを更新した(: update)」と言い、上書きされたRFCは「上書き元のRFCによって更新された(: updated by)」と言う。

ステータス

すべての RFC がインターネット標準というわけではない[17][18]。各RFCには標準化プロセスにおけるステータス(: status)が定められている。ステータスは「標準化過程 (: Standards Track)」、「情報 (: Informational)」、「実験的 (: Experimental)」、「現状で最良の慣行 (: Best Current Practice)」、「歴史的 (: Historic)」のいずれかである。

「標準化過程」
「標準化過程」は成熟度によってさらに「標準への提唱 (: Proposed Standard, PS)」、「インターネット標準 (: Internet Standard, STD)」に分けられる。以前のRFC 2026では「標準への提唱」、「標準への草稿 (: Draft Standard, DS)」、「インターネット標準」の3段階だったが、RFC 6410によって2段階に変更された。ただし、それ以前に「標準への草稿」となったものが引き続き存在するため、標準化過程のRFCのすべてが2段階のどちらかになっているわけではない。最新の状態はRFC編集者のサイトで確認ができる[参考 1]
「情報」
エイプリルフールジョークRFCプロプライエタリなプロトコル、RFC 1591DNSの構造と権限の委任)のように広く不可欠なものと認められた RFC など、ほとんどあらゆるものが含まれる。
「実験的」
インターネットに関して有用と考えられる研究成果や実験結果を広く公開するためのものである。実験的といっても、実際には具体的な手続きをとろうとする者がいないために標準化過程へ昇格していないだけの文書も含まれる。
「現状で最良の慣行」
「情報」には留まらないが実際にネットワークで使われるデータには影響しない、インターネット上の公式なルールと見なされている実務上の文書などである。またインターネット標準を実践するための技術的な推奨事項も含まれる。
「歴史的」
標準化過程で破棄された文書や標準化以前に公開されていた廃れた RFC に適用される。
「不明」
ステータスが導入される以前に公開されたRFC(RFC 1128以前)は、そのほとんどのステータスを「不明 (: Unknown)」とみなしている。ただし一部のRFCについて遡及的に「不明」以外のステータスを適用しているものもある[16]

サブシリーズ

RFCシリーズには、2つのサブシリーズ(BCP、STD)が含まれており、また廃止された1つのサブシリーズ(FYI)がある。

  • BCPサブシリーズ(: Best Current Practice)は標準化過程ではないが、実務上のルールなどの必須情報をまとめたサブシリーズである。ステータスが「現状で最良の慣行」のRFCがこのサブシリーズを構成する。RFC 1818参照。
  • STDサブシリーズ(: Standard)は、標準化過程の最終段階である「インターネット標準」のRFCが構成する。RFC 1311参照。
  • FYIサブシリーズ(: For Your Information)は、RFC 1150 (FYI 1) で規定されているようにIETFによって推進されている情報RFCのサブシリーズであった。ステータスが「情報」の一部がこのサブシリーズを構成していた。2011年、RFC 6360によって FYI 1 が廃止され、このサブシリーズは終了した。

RFCが各サブシリーズに割り当てられると、サブシリーズの番号が割り当てられる(例えば、STD 1 など)。サブシリーズの番号が割り当てられてもRFC番号は保持される。

サブシリーズを構成するRFCが置き換えられた場合でも、サブシリーズの番号は変わらずに新しいRFCを参照するようになる(参照先のRFCは1つの場合もあれば、複数のこともある)。例えば、2007年時点ではRFC 3700がインターネット標準 STD 1 であったが、その後RFC 5000に置き換えられたため、2008年5月時点の STD 1 はRFC 5000となった。さら2013年12月にRFC 7100で置き換えられ、STD 1 [注釈 5]は使用されなくなった。

発行の流れ

RFC発行の流れには、IETF、IRTF、IAB、独立提出(: independent submission)、および声明(: Editorial)の5パターンがある[19]

  • IETFだけが「現状で最良の慣行」と「標準化過程」のRFCを作成できる。
  • IABは、ポリシーやアーキテクチャに関する「情報」文書を公開する。
  • IRTFは、「情報」または「実験的」として研究結果を公開する。
  • 「独立提出」は、独立提出編集者(: Independent Submissions Editor)の裁量で公開される(RFC 4846RFC 5742RFC 5744参照)。
  • 「声明」は、RFCシリーズ全体の編集ポリシーの変更に使用される(RFC 9280参照)。

IETFと声明以外の文書は、IETFの作業と競合するかどうかについてIESGによってレビューされる。IRTFおよび独立提出RFCには通常、IETFの作業と競合しない、インターネット全体に関連する情報または実験的内容が含まれている。

著作権

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

独立機関であるIETFトラストが一部のRFCの著作権を保有しており、その他すべてのRFCについては著者からRFCの複製を許可するライセンスを付与されている[21]インターネットソサエティRFC 4714以前の多くのRFCで著作権所有者として言及されているが、その権利をIETFトラストに譲渡した[22]

取得方法

全てのRFCはインターネット上で公開されており、誰でも閲覧、取得することができる。

インターネット上では以下の2つのURIからRFCを取得できる(以下はRFC 1149の例)。

  • https://www.rfc-editor.org/info/rfc1149
  • https://datatracker.ietf.org/doc/html/rfc1149

IETFは、RFCの公式提供URIは www.rfc-editor.org ドメインのもので、datatracker.ietf.org ドメインのものはその作業用リポジトリであるとしている[23][24][25]。ただし、関連するインターネットドラフト等は datatracker.ietf.org にしかないため注意が必要である(Wikipediaでは、datatracker.ietf.orgドメインのURIを使用している)。

RFCシリーズのISSN(国際標準逐次刊行物番号)は 2070-1721 である(RFC 5741参照)。

RFCシリーズのDOI(デジタルオブジェクト識別子)のディレクトリ識別子は 10.17487 である(RFC 7669参照)。例えばRFC 1149のDOIは10.17487/RFC1149であり、DOIディレクトリ経由でアクセスするURIは以下のようになる(%2F/URLエンコードである)。

  • https://doi.org/10.17487%2FRFC1149

一風変わったRFC

毎年、エイプリルフールにはユーモラスな内容のRFC、通称ジョークRFCが公開されることがある[注釈 6]

また、インターネットに多大な貢献があった人への追悼のRFCが公開されたこともある。

  • RFC 2468 "I Remember IANA"(1998年10月)
  • RFC 2441 "Working with Jon"(1998年11月)

RFCの一覧

要約
視点

最新のRFC一覧はRFC編集者のページに公開されているRFCインデックスで確認ができる[参考 2]。以下の一覧は一部の抜粋である。

さらに見る RFC, タイトル ...
RFCの一覧
RFCタイトル
RFC 3望ましいコメントについての文書。RFCが文字通りの「コメント募集」だった頃の様子が分かる。
RFC 748Telnet ランダム喪失オプション(エイプリルフールに発行されたはじめてのジョークRFC。1978年)
RFC 768UDP
RFC 783TFTP
RFC 791IP
RFC 792ICMP
RFC 793TCP
RFC 826ARP
RFC 854Telnet
RFC 894IP over Ethernet
RFC 903RARP
RFC 959FTP
RFC 1034
RFC 1035
DNS
RFC 1149鳥類キャリアによるIPデータグラムの標準規格(1990年のジョークRFC)
RFC 1157SNMP
RFC 1179LPR Line PRinter daemon protocol
RFC 1189CMIP
RFC 1242ネットワーク相互接続機器のためのベンチマーク用語
RFC 1305NTP
RFC 1459IRC
RFC 1468インターネットメッセージのための日本語文字符号化ISO-2022-JP
RFC 1808相対URLRFC 3986により破棄)
RFC 1855ネチケットガイドライン
RFC 1866HTML 2.0RFC 2854により破棄)
RFC 1867HTMLにおけるフォームからのファイルアップロード(RFC 2854により破棄)
RFC 1928SOCKS v5
RFC 1939POP Version 3
RFC 1942HTMLにおけるテーブル(RFC 2854により破棄)
RFC 1951Deflate圧縮フォーマット仕様 Version 1.3
RFC 1980HTMLにおけるクライアントサイドイメージマップ(RFC 2854により破棄)
RFC 2058Remote Authentication Dial In User Service (RADIUS)
RFC 2070HTMLの国際化(ISO-8859-1以外の文字セットをHTMLで使えるようにしたもの。「HTML2.x」もしくは「HTML i18n」ともいわれる。RFC 2854により破棄)
RFC 2080RIPng for IPv6
RFC 2083PNG
RFC 2119Key words for use in RFCs to Indicate Requirement Levels
RFC 2131DHCP
RFC 2205RSVP
RFC 2247LDAP/X.500 識別名におけるドメイン名の使用
RFC 2251LDAP v3
RFC 2252LDAP v3: 属性文法の定義
RFC 2253LDAP v3: UTF-8 識別名のストリングリプレゼンテーション
RFC 2254LDAP v3: LDAP 検索フィルタの定義
RFC 2255LDAP URL形式
RFC 2256LDAP v3 で利用される X.500(96) ユーザスキーマの要約
RFC 2318Remote Authentication Dial In User Service (RADIUS)
RFC 2322Management of IP numbers by peg-dhcp(洗濯ばさみ-DHCPによるIPアドレス管理)(1998年のジョークRFC。実装例は#外部リンク参照)
RFC 2324Hyper Text Coffee Pot Control Protocol(1998年のジョークRFC)
RFC 2328OSPF Version 2
RFC 2396URIの一般的書式(RFC 3986により破棄)
RFC 2401IPSec : Security Architecture for the Internet Protocol
RFC 2453RIP Version 2
RFC 2459Internet X.509 Public Key Infrastructure Certificate and CRL Profile
RFC 2460IPv6
RFC 2468IANAを偲ぶ」(IANAの発起者であるジョン・ポステルを悼んで。ヴィントン・サーフ作)
RFC 2527Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework(RFC 3647により破棄)
RFC 2549鳥類キャリアによるIPのサービス品質(1999年のジョークRFC)
RFC 2550Y10K and Beyond(1999年のジョークRFC。2000年問題(Y2K)ではなく10000年問題について)
RFC 2555RFCの30年
RFC 2616HTTP/1.1
RFC 2732URLへのIPv6アドレスによるリテラルを含む書式(RFC 3986により破棄)
RFC 2740OSPF for IPv6
RFC 2795The Infinite Monkey Protocol Suite (IMPS)(1999年のジョークRFC。無限の猿定理の実証で用いることのできるプロトコル)
RFC 2845Secret Key Transaction Authentication for DNS (TSIG)
RFC 2854text/htmlメディアタイプ(IETFにより標準化されたHTMLを破棄し、メディアタイプがtext/htmlである文書の仕様についてはW3Cの仕様書を参照するように定めた)
RFC 2865RADIUS認証プロトコル Remote Authentication Dial In User Service (RADIUS)
RFC 2866RADIUS Accounting
RFC 2930Secret Key Establishment for DNS (TKEY RR)
RFC 3261SIP
RFC 3280Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile(RFC 5280により破棄)
RFC 3305Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations(URIURLURNという概念についての考え方)
RFC 3377LDAP v3: 技術仕様
RFC 3411
RFC 3412
RFC 3413
RFC 3414
RFC 3415
RFC 3416
RFC 3417
RFC 3418
SNMP
RFC 3490Internationalizing Domain Names in Applications (IDNA)
RFC 3501IMAP Version 4rev1
RFC 3514The Security Flag in the IPv4 Header(2003年のジョークRFC。悪意ビット。このRFCは発行されたその日にFreeBSD上で実装され、翌日にキャンセルされた)
RFC 3550RTP
RFC 3645Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)
RFC 3647Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework
RFC 3751Omniscience Protocol Requirements(2004年のジョークRFC)
RFC 3920
RFC 3921
RFC 3922
RFC 3923
XMPP(Jabberを参照)
RFC 3977NNTP
RFC 3986URIの一般的書式
RFC 3987Internationalized Resource Identifiers(Unicodeの文字を使えるようにしたリソース識別子であるIRIの仕様定義)
RFC 4041Requirements for Morality Sections in Routing Area Drafts(2005年のジョークRFC)
RFC 4042UTF-9 and UTF-18 Efficient Transformation Formats of Unicode(2005年のジョークRFC)
RFC 4158Internet X.509 Public Key Infrastructure:Certification Path Building
RFC 4250
RFC 4251
RFC 4252
RFC 4253
RFC 4254
RFC 4255
RFC 4256
SSH
RFC 4271BGP
RFC 4325Internet X.509 Public Key Infrastructure Authority Information Access Certificate Revocation List (CRL) Extension(RFC 5280により破棄)
RFC 4346TLS
RFC 4627The application/json Media Type for JavaScript Object Notation (JSON)(RFC 7159により破棄)
RFC 4630Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile(RFC 3280を更新)
RFC 4635HMAC SHA TSIG Algorithm Identifiers
RFC 4824手旗信号システムによるIP伝送(2007年のジョークRFC)
RFC 4844The RFC Series and RFC Editor
RFC 4960SCTP
RFC 5280Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
RFC 5321SMTP
RFC 5322Internet Message Format
RFC 5652暗号メッセージ構文 (CMS)
RFC 5741RFC Streams, Headers, and Boilerplates
RFC 5914Trust Anchor Format
RFC 5937Using Trust Anchor Constraints during Certification Path Processing
RFC 6818Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile(RFC 5280を更新)
RFC 6844DNS Certification Authority Authorization (CAA) Resource Record
RFC 6895Domain Name System (DNS) IANA Considerations
RFC 7158The JavaScript Object Notation (JSON) Data Interchange Format(RFC 7159により破棄)
RFC 7159The JavaScript Object Notation (JSON) Data Interchange Format
RFC 7168Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
RFC 7230Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
RFC 7231Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
RFC 7232Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
RFC 7233Hypertext Transfer Protocol (HTTP/1.1): Range Requests
RFC 7234Hypertext Transfer Protocol (HTTP/1.1): Caching
RFC 7235Hypertext Transfer Protocol (HTTP/1.1): Authentication
RFC 7382Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)
RFC 7519JSON Web Token (JWT)
RFC 7540Hypertext Transfer Protocol Version 2 (HTTP/2)
RFC 7541HPACK: Header Compression for HTTP/2
RFC 8058Signaling One-Click Functionality for List Email Headers - メールマガジンメーリングリスト等において、受信者(購読者)がワンクリックのみで登録を解除(配信を停止)できるデータを、メールヘッダーに記載する方法
閉じる

脚注

関連項目

外部リンク

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.