コメントを求める

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

Request for CommentsRFC )は、インターネットの主要な技術開発および標準化団体、最も有名なのはインターネット技術特別調査委員会(IETF)からの一連の出版物です。RFCは、インターネットおよびインターネットに接続されたシステムの動作に適用可能な方法、動作、研究、または革新を説明する覚書の形で、エンジニアおよびコンピューター科学者の個人またはグループによって作成されます。査読のため、または新しい概念、情報、場合によってはエンジニアリングのユーモアを伝えるために提出されます。[1]

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

インターネットコミュニティの外では、コメントの要求とも呼ばれる他の文書が、米国運輸省道路交通安全局などの米国連邦政府の活動で公開されています。[5]

歴史

RFC形式の開始は、1969年に独創的なARPANETプロジェクトの一部として発生しました。[4]今日、これはインターネット技術特別調査委員会(IETF)、インターネットアーキテクチャ委員会(IAB)、そしてある程度はコンピュータネットワーク研究者のグローバルコミュニティの公式出版チャネルです。

最初のRFCの作成者は、自分たちの作業をタイプライトし、ARPA研究者の間でハードコピーを配布まし最新のRFCとは異なり、初期のRFCの多くは実際のコメント要求であり、宣言的すぎるように聞こえないようにし、議論を促すためにそのようにタイトルが付けられていました。[6] [7] RFCは質問を開いたままにし、あまり正式ではないスタイルで書かれています。このあまり正式ではないスタイルは、RFCとして承認される前の前段階である、 インターネットドラフトドキュメントの典型的なものです。

1969年12月、研究者は新しく運用されたARPANETを介して新しいRFCの配布を開始しました。 「ホストソフトウェア」というタイトルのRFC1は、カリフォルニア大学ロサンゼルス校(UCLA)のSteve Crockerによって作成され、1969年4月7日に公開されました。[8] Steve Crockerによって作成されましたが、RFCは初期から登場していました。Steve Crocker、Steve Carr、およびJeffRulifsonの間のワーキンググループディスカッション。

RFCシリーズを最初に定義したRFC3では、CrockerはRFCシリーズをネットワークワーキンググループに帰属させ始めました。正式な委員会ではなく、ARPANETプロジェクトに関心のある研究者のゆるやかな協会でした。事実上、プロジェクトに関する会議や議論に参加したい人は誰でも含まれていました。

1970年代のその後のRFCの多くもUCLAからのものでした。これは、UCLAがARPANETのインターフェイスメッセージプロセッサ(IMP)の最初のものの1つであるためです。DouglasEngelbartが監督するStanfordResearchInstituteAugmentationResearch Center(ARC)は、ARPANETノードの最初の4つのうちの別のものであり、初期のRFCのソースです。ARCは、他のネットワーク情報とともにRFCを配布するためにエリザベスJ.ファインラーによって管理された最初のネットワーク情報センター(InterNIC )になりました。[9] 1969年から1998年まで、JonPostelはRFCエディターを務めていました。1998年に亡くなったとき、彼の死亡記事はRFC2468として公開されました。

米国連邦政府との最初のARPANET契約の満了後、インターネットソサエティはIETFに代わって行動し、南カリフォルニア大学(USC)情報科学研究所(ISI)のネットワーク部門と契約して編集を引き受けました。 IABの指示の下で責任を公開します。SandyGinozaは1999年にUSC / ISIに参加してRFC編集に取り組み、2005年にAliceHagensに参加しました。[10] Bob BradenがRFCプロジェクトリーダーの役割を引き継ぎ、Joyce K.Reynoldsは10月13日までチームの一員でした。 2006年。

2007年7月に、 RFCのストリームが定義され、編集業務を分割できるようになりました。IETFドキュメントは、インターネットエンジニアリングステアリンググループのIETFエリアディレクターが後援するIETFワーキンググループまたは提出物からのものです。IABは独自のドキュメントを公開できます。ドキュメントのリサーチストリームは、インターネットリサーチタスクフォース(IRTF)からのものであり、他の外部ソースからの独立したストリームです。[11]新しいモデルが2008年に提案され、改良され、2009年8月に公開され、タスクがいくつかの役割に分割されました[12]。RFCシリーズアドバイザリーグループ(RSAG)が含まれます。モデルは2012年に更新されました。[13]ストリームも2009年12月に改良され、そのスタイルに標準が定義されました。[14] 2010年1月、RFCエディター機能は請負業者であるAssociation Management Solutionsに移され、GlennKowackが暫定シリーズエディターとして機能しました。[15] 2011年後半、HeatherFlanaganがRFCシリーズの常設編集者として採用されました。また、その時点で、RFCシリーズ監視委員会(RSOC)が作成されました。[16]

コメントのリクエストは、元々リフロー不可能なテキスト形式で作成されていました。2019年8月にフォーマットが変更され、さまざまなディスプレイサイズのデバイスで新しいドキュメントを最適に表示できるようになりました。[17]

制作とバージョン管理

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

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

個人または小規模な作業グループによって達成される実用的で経験主導の事後標準化団体のRFCの伝統は、ISOおよび国内標準化団体に典型的なより正式な委員会主導のプロセスよりも重要な利点を持ちます[明確化が必要] 。[要出典]

ほとんどのRFCは、「MUST」や「NOT RECOMMENDED」(RFC2119およびRFC8174で定義)、拡張バッカスナウア記法(ABNF)(RFC 5234)などの一般的な用語セットをメタ言語として使用し、単純なテキストを使用します。 RFCの一貫性と理解を容易にするために、ベースのフォーマット。[18]

サブシリーズ

RFCシリーズには、 IETF RFCの3つのサブシリーズ(BCP、FYI、およびSTD)が含まれています。Best Current Practice(BCP)は、標準化されていない必須のIETFRFCのサブシリーズです。For Your Information(FYI)は、RFC 1150(FYI 1)で指定されているIETFによって推進される情報RFCのサブシリーズです。2011年、RFC6360はFYI1を廃止し、このサブシリーズを終了しました。標準(STD)は、RFC 2026(BCP 9)で指定されているIETF標準トラックの3番目で最高の成熟度レベルでした。2011年にRFC6410(BCP 9の新しい部分)は標準化過程を2つの成熟度レベルに減らしました。[要出典]

ストリーム

RFCには、 IETFIRTFIAB、および独立した提出の4つのストリームがあります[19] IETFのみが標準化過程でBCPとRFCを作成します。独立した提出物は、 IESGによってIETF作業との競合がないかチェックされます。品質は、独立した提出編集委員会によって評価されます。言い換えると、IRTFと独立した RFCには、IETFの作業と競合しない、インターネット全般に関連する情報や実験が含まれているはずです。RFC 4846、RFC 5742、およびRFC5744を比較してください。[要出典]

RFCの取得

RFC2046メディアタイプ1996年11月


   A.収集された文法.................................... 43

1.はじめに

   このセットの最初のドキュメントであるRFC2045は、いくつかのヘッダーを定義しています。
   Content-Typeを含むフィールド。Content-Typeフィールドは、
   MIMEエンティティの本文のデータの性質を次のように指定します
   メディアタイプとサブタイプの識別子を提供し、補助を提供することによって
   特定のメディアタイプに必要な情報。後に
 text / plainMIMEタイプを定義するRFC2046それ自体がプレーンテキストです。

World Wide Web上のRFCの公式ソースは、RFCエディターです。公開されているほとんどすべてのRFCは、RFC5000で示されているhttp://www.rfc-editor.org/rfc/rfc5000.txtの形式 のURLを介して取得できます。

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

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

RFCシリーズの公式の国際標準シリアル番号(ISSN)は、2070〜1721です。[14]

ステータス

すべてのRFCが標準であるわけではありません。[20] [21]各RFCには、インターネット標準化プロセス内のステータスに関する指定が割り当てられています。このステータスは、情報実験Best Current Practice標準化過程、または履歴のいずれかです。

各RFCは静的です。ドキュメントが変更された場合は、再度送信され、新しいRFC番号が割り当てられます。[要出典]

標準トラック

標準化過程の文書はさらに提案された標準文書とインターネット標準文書に分けられます。[22]

標準追跡RFC を承認できるのは、 Internet Engineering Steering Group (IESG)に代表されるIETFだけです。

RFCがインターネット標準(STD)になると、STD番号が割り当てられますが、RFC番号は保持されます。インターネット標準の最も信頼のおけるリストは、公式のインターネットプロトコル標準です。以前は、リストのスナップショットを維持するためにSTD1が使用されていました。[23]

インターネット標準が更新されても、そのSTD番号は同じままで、新しいRFCまたはRFCのセットを参照するようになります。特定のインターネット標準であるSTDnは、特定の時点でRFC xおよびyである可能性がありますが、後で同じ標準が代わりにRFCzに更新される可能性があります。たとえば、2007年にRFC3700はインターネット標準(STD 1)でしたが、2008年5月にRFC 5000に置き換えられたため、RFC 3700はHistoricに変更され、RFC 5000はインターネット標準になり、2008年5月の時点でSTD1はRFC5000になりました。 。2013年12月の時点で、RFC5000はRFC7100に置き換えられ、RFC2026が更新されてSTD1が使用されなくなりました。

(現在のベストプラクティスも同様に機能します。BCPn特定のRFCまたはRFCのセットを指しますが、RFCまたはRFCは時間の経過とともに変更される可能性があります)。

情報

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

実験的

実験的なRFCは、IETFドキュメントまたはRFCエディタへの個別の提出である可能性があります。ドラフトは、提案が意図したとおりに機能するかどうかが不明な場合、または提案が広く採用されるかどうかが不明な場合は、実験的なものとして指定されます。実験的なRFCは、普及してうまく機能すれば、標準化過程に昇格する可能性があります。[24]

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

ベストカレントプラクティスサブシリーズは、公式ルールと見なされ、情報提供だけでなく、ネットワークデータに影響を与えない管理ドキュメントやその他のテキストを収集します標準トラックとBCPの境界はしばしば不明確です。ドキュメントがBCP9 [25]やIETF管理などのインターネット標準化プロセスにのみ影響する場合、それは明らかにBCPです。Internet Assigned Numbers Authority (IANA)レジストリの規則と規制のみを定義している場合は、あまり明確ではありません。これらのドキュメントのほとんどはBCPですが、一部は標準化されています。

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

歴史的

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

不明

ステータス不明は、一部の非常に古いRFCで使用されます。この場合、ドキュメントが今日公開された場合にどのステータスになるかは不明です。これらのRFCのいくつかは、今日はまったく公開されません。初期のRFCは、多くの場合、それだけでした。プロトコル、管理手順、またはRFCシリーズが現在使用されているその他のものを指定することを意図していない単純なRequest forCommentsです。[要出典]

著作権

原則として、元の作者(または雇用条件で規定されている場合は雇用主)は、明示的に権利を譲渡しない限り、著作権を保持します。[27]

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

も参照してください

参考文献

  1. ^ Waitzman、David(1990年4月1日)。鳥類キャリアでのIPデータグラムの送信に関する標準IETF土井10.17487 / RFC1149RFC1149 _ 2017年3月29日取得
  2. ^ Huitema、クリスチャン; ポステル、ジョン; クロッカー、スティーブ(1995年4月)。すべてのRFCが標準であるわけではありませんIETF土井10.17487 / RFC1796RFC1796 _ 2018年5月15日取得
  3. ^ 「RFCの、コメントのためのインターネット要求」Livinginternet.com 2012年4月3日取得
  4. ^ a b "スティーブンD.クロッカー、インターネットがそのルールをどのように取得したか、ニューヨークタイムズ、2009年4月6日"Nytimes.com2009年4月7日2012年4月3日取得
  5. ^ 連邦官報(2018年1月16日)通知とコメントの要求。
  6. ^ ハフナー、ケイティ; リヨン、マシュー(1996)。ウィザードが遅くまで起きている場所:インターネットの起源。
  7. ^ メッツ、ケイド(2012年5月18日)。「インターネットの指示を発明した人に会いなさい」有線2018年12月18日取得
  8. ^ クロッカー、スティーブ(1969年4月7日)。「RFC1   {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  9. ^ エリザベスJ.ファインラー(2010年7月〜9月)。「ネットワークインフォメーションセンターとそのアーカイブ」。コンピューティングの歴史の年報32(3):83–89。土井10.1109 /MAHC.2010.54S2CID206443021_ 
  10. ^ レスリーデイグル(2010年3月)。「移行中のRFCエディタ:過去、現在、そして未来」インターネットプロトコルジャーナル13、いいえ。1.シスコシステムズ2011年8月17日取得
  11. ^ デイグル、レスリー(2007年7月)。RFCシリーズとRFCエディタIETF土井10.17487 / RFC4844RFC4844_
  12. ^ コルクマン、オラフ(2009年8月)。RFCエディターモデル(バージョン1)IETF土井10.17487 / RFC5620RFC5620_
  13. ^ コルクマン、オラフ; ハルパーン、ジョエル(2012年6月)。RFCエディタモデル(バージョン2)IETF土井10.17487 / RFC6635RFC6635_
  14. ^ a b デイグル、レスリー; コルクマン、オラフ(2009年12月)。RFCストリーム、ヘッダー、およびボイラープレートIETF土井10.17487 / RFC5741RFC5741_
  15. ^ Glenn Kowack(2010年1月7日)。「RFCエディター移行のお知らせ」2011年6月29日にオリジナルからアーカイブされました。
  16. ^ RFCエディタ。「RFCシリーズエディタとシリーズ再編成」2013年4月5日取得 {{cite web}}|author=一般名があります(ヘルプ
  17. ^ 「RFCフォーマット変更FAQ」
  18. ^ a b " RFCインデックス"RFCエディター。2008年5月25日2008年5月26日取得
  19. ^ 「独立した提出物」RFCエディター2018年1月5日取得
  20. ^ 「すべてのRFCインターネット標準文書ですか?」RFCエディター2018年3月16日取得
  21. ^ Huitema、クリスチャン; ポステル、ジョン; クロッカー、スティーブ(1995年4月)。すべてのRFCが標準であるわけではありませんIETF土井10.17487 / RFC1796RFC1796_ ...各RFCにはステータスがあります…:情報、実験、または標準化過程(提案された標準、ドラフト標準、インターネット標準)、または履歴。
  22. ^ Housley、Russell; クロッカー、デイブ; バーガー、エリック(2011年10月)。標準トラックを2つの成熟度レベルに下げるIETF土井10.17487 / RFC6410RFC6410_
  23. ^ RFC7100「インターネット公式プロトコル標準」要約文書の廃止
  24. ^ 「7.5。情報および実験RFC」IETFのTao 、 2017年11月26日取得
  25. ^ Bradner、Scott O.(1996年10月)。インターネット標準化プロセス–リビジョン3IETFBCP9 2017年10月25日取得
  26. ^ 「RFCを歴史的なものとして指定することに関するIESGステートメント」IETF。2014年7月20日2016年4月14日取得
  27. ^ 「RFCの複製」IETFトラスト2021年8月12日取得
  28. ^ ブラドナー、スコット; コントレラス、ホルヘ(2008年11月)。権利貢献者はIETFトラストに提供しますIETF土井10.17487 / RFC5378RFC5378_
  29. ^ 「RFCの複製」IETFトラスト2021年8月13日取得

外部リンク