コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Request for Comments

出典: フリー百科事典『ウィキペディア(Wikipedia)』
RFC 2555から転送)

Request for Comments(リクエスト フォー コメンツ、略称:RFC)はIETF(Internet Engineering Task Force、インターネット技術特別調査委員会)による技術仕様保存、公開形式である。内容には特に制限はないが、プロトコルファイルフォーマットが主に扱われる。RFCとは「コメント募集」を意味する英語の略語であり、もともとは技術仕様を公開し、それについての意見を広く募集してより良いものにしていく観点から始められたようである。

今日では、Internet Engineering Task Force (IETF)やインターネットアーキテクチャ委員会 (IAB)、およびコンピュータネットワーク研究者の世界的なコミュニティの公式発表の場となっている。

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

歴史

[編集]

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

初期のRFCはタイプライターで執筆され、DARPAの研究者にそれをコピーした紙が配布された。現在のRFCとは異なり、初期のRFCの多くは文字通り実際にコメントを求めるものであり、宣言のような響きを避け、議論を促すために"Request for comments"という名前が付けられた[2][3]。初期のRFCは、あまり形式ばらないスタイルで書かれていた。この形式ばらないスタイルは、RFCとして承認される前段階のインターネットドラフトに引き継がれている。

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

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

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

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

当時のARPANETはNetwork Control Program(NCP)というプロトコルで動作していたが、1983年にNCPから(Internetプロジェクトの成果物である)TCP/IPへ移行した。それ機に、あるいはそれと前後して、これらの類似の文書はRFCに統合されていったという。

1988年、IABにインターネットドラフト: Internet Draft)シリーズの作成が承認された(RFC 8700参照)。これにより最初期の Request for Comments の位置づけがインターネットドラフトに引き継がれた。

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

  • 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の編集および発行を行うことになった[6]

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

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

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

作成

[編集]

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

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

RFCのスタイルガイドは RFC 7322 で定義されている。また、RFC編集者のサイトでスタイルガイド関連資料が紹介されている[12]

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

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

バージョン管理

[編集]

RFC編集者はRFCを公開する際に一連の番号を割り当てる。一度番号が割り当てられ公開されたRFCは、取り消されたり変更されたりすることはない。誤字などの誤りがあった場合には、別途正誤表(: 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 がインターネット標準というわけではない[14][15]。各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編集者のサイトで確認ができる[16]。詳しくはインターネット標準を参照。
「情報」
エイプリルフールジョークRFCプロプライエタリなプロトコル、RFC 1591DNSの構造と権限の委任)のように広く不可欠なものと認められた RFC など、ほとんどあらゆるものが含まれる。
「実験的」
インターネットに関して有用と考えられる研究成果や実験結果を広く公開するためのものである。実験的といっても、実際には具体的な手続きをとろうとする者がいないために標準化過程へ昇格していないだけの文書も含まれる。
「現状で最良の慣行」
「情報」には留まらないが実際にネットワークで使われるデータには影響しない、インターネット上の公式なルールと見なされている実務上の文書などである。またインターネット標準を実践するための技術的な推奨事項も含まれる。
「歴史的」
標準化過程で破棄された文書や標準化以前に公開されていた廃れた RFC に適用される。
その他のステータス
非常に古い RFC には「不明 (: unknown)」というステータスのものがある。1989年を最後にその後は発行されたことのないステータスである。また、一部のジョークRFCでは上記のどれでもないステータスのものが存在する(例えば RFC 2551 は「現状で最悪の慣行(: Worst Current Practice)」というステータスになっている)。

サブシリーズ

[編集]

RFCシリーズには、3つのサブシリーズ(BCP、FYI、STD)が含まれている。

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

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 は使用されなくなった。

発行の流れ

[編集]

RFC発行の流れには、IETF、IRTF、IAB、独立提出、および編集の5パターンがある[17]

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

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

著作権

[編集]

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

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

取得方法

[編集]

全ての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 ドメインのものはその作業用リポジトリであるとしている[21][22][23]。ただし、関連するインターネットドラフト等は 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が公開されることがある[注釈 1]

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

RFCの一覧

[編集]

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

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

脚注

[編集]

注釈

[編集]
  1. ^ ジョークRFCは必ず発行されるわけではない。例えば2006年や2016年には発行されていない。

出典

[編集]
  1. ^ “Stephen D. Crocker, How the Internet Got Its Rules, The New York Times, 6 April 2009”. Nytimes.com. (April 7, 2009). https://www.nytimes.com/2009/04/07/opinion/07crocker.html?_r=1&em April 3, 2012閲覧。 
  2. ^ Hafner, Katie; Lyon, Matthew (1996). Where Wizards Stay Up Late: The Origins of the Internet.
  3. ^ Metz, Cade (May 18, 2012). “Meet the man who invented the instructions for the Internet”. Wired. https://www.wired.com/2012/05/steve-crocker/ December 18, 2018閲覧。. 
  4. ^ Host Software (英語). 7 April 1969. doi:10.17487/RFC0001. RFC 1
  5. ^ Elizabeth J. Feinler (July–September 2010). “The Network Information Center and its Archives”. Annals of the History of Computing 32 (3): 83–89. doi:10.1109/MAHC.2010.54. 
  6. ^ Leslie Daigle (March 2010). “RFC Editor in Transition: Past, Present, and Future”. The Internet Protocol Journal (Cisco Systems) 13 (1). http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_13-1/131_rfc.html August 17, 2011閲覧。 
  7. ^ The RFC Series and RFC Editor (英語). July 2007. doi:10.17487/RFC4844. RFC 4844
  8. ^ RFC Editor Transition Announcement at the Wayback Machine (archived 2011-06-29)
  9. ^ The RFC Series Editor and the Series Reorganization at the Wayback Machine (archived 2013-03-13)
  10. ^ Alexis Rossi appointed as RFC Series Consulting Editor” (2022年9月1日). 2024年11月29日閲覧。
  11. ^ IETF Working Group Guidelines and Procedures (英語). September 1998. doi:10.17487/RFC2418. RFC 2418
  12. ^ Style Guide”. RFC Editor. 2024年12月3日閲覧。
  13. ^ RFC Format Change FAQ”. 2024年11月29日閲覧。
  14. ^ Frequently Asked Questions - Are all RFCs Internet standards documents?”. 2024年11月29日閲覧。
  15. ^ Not All RFCs are Standards (英語). April 1995. doi:10.17487/RFC1796. RFC 1796
  16. ^ Official Internet Protocol Standards”. 2024年11月29日閲覧。
  17. ^ RFC Editor Model (Version 3) (英語). June 2022. doi:10.17487/RFC9280. RFC 9280
  18. ^ Frequently Asked Questions - Reproducing RFCs”. 2024年11月29日閲覧。
  19. ^ Rights Contributors Provide to the IETF Trust (英語). November 2008. doi:10.17487/RFC5378. RFC 5378
  20. ^ Frequently Asked Questions - Copyright and IETF Copyright Policies”. 2024年11月29日閲覧。
  21. ^ References in RFCXML”. 2024年11月29日閲覧。
  22. ^ What is the difference between datatracker.ietf.org & www.rfc-editor.org and which is Official URL for RFC ?”. 2024年11月29日閲覧。
  23. ^ Links to HTML versions of RFC's need to move from "tools" to "datatracker"”. 2024年11月29日閲覧。
  24. ^ RFC Index”. RFC Editor. 2024年12月3日閲覧。

関連項目

[編集]

外部リンク

[編集]