最初のRFC（Request for Comments）のRFC 1 -100
最初のRFC（Request for Comments）を 1 から１００まで調べてみました。だいぶ長いです。（ソフトウェア歴史の読み物として捉えていただけたらと思いますｗ）
RFC 1: Host Software
概要
タイトル: Host Software
著者: Steve Crocker
発行日: 1969年4月7日
内容: ARPANETのホストコンピュータ上で動作するソフトウェアについての初期のアイデアと提案を記述しています。この文書は、ネットワークの設計と実装に関する最初の考えを示しています。
背景
1969年、アメリカ国防総省の高等研究計画局（DARPA）が資金を提供し、ARPANET（Advanced Research Projects Agency Network）の開発が始まりました。ARPANETは、パケット交換技術を使用した初期のネットワークで、インターネットの前身とされています。このプロジェクトの一環として、ネットワークの設計、プロトコル、運用方法について議論し、標準化するための文書が必要とされました。その結果、RFCシリーズが誕生しました。
RFC 1の内容
RFC 1は、ホストコンピュータ上で動作するソフトウェアに関するアイデアを共有するために作成されました。以下は、RFC 1に記載されている主要な内容です：
ホスト間の通信:
ホストコンピュータ間でデータを交換するための基本的なプロトコルやメカニズムについて議論しています。
データ転送の信頼性を確保するための方法として、確認応答（ACK）や再送（リトランスミッション）などの概念が紹介されています。
ソフトウェア構造:
ホストコンピュータ上のソフトウェアがどのように構成され、相互に通信するかについての初期の考え方が示されています。
ネットワークソフトウェアのモジュール化とそのインターフェースについても言及されています。
実験的アプローチ:
RFCシリーズの初期の文書として、具体的な実装の詳細よりも、概念的な議論や提案に重点を置いています。
実験とフィードバックを重視し、コミュニティ全体での議論と改善を促進するアプローチが取られています。
将来の議論の基盤:
この文書は、後のRFC文書やネットワーク技術の開発における基盤として機能しました。
RFCシリーズ全体の始まりとして、コミュニティによる協力と継続的な改善の文化を確立しました。
影響
RFC 1は、ARPANETの開発初期における重要な一歩でした。この文書を皮切りに、多くの技術者や研究者がネットワーク技術の標準化と改善に貢献するようになりました。RFCシリーズは、現在も続くインターネット技術の標準化と発展のための重要なプラットフォームとして機能しています。
関連情報
RFCエディタ: RFCシリーズ全体を管理し、文書を公開している機関です。
RFC 1は、ネットワーク技術の発展における歴史的な文書であり、その影響は現在のインターネットにまで及んでいます。この文書が示す協力と標準化の精神は、インターネット技術の継続的な進化を支えています。
RFC 2: Host Software
概要
タイトル: Host Software
著者: Bill Duvall
発行日: 1969年4月
内容: RFC 2は、ARPANET上のホストコンピュータ間の通信プロトコルに関する初期の仕様と提案を記述しています。この文書は、ネットワーク内のホスト間でリンクを確立するための手順や、通信中のエラー処理について説明しています。
主要な内容
リンク確立プロトコル:
ホストAからホストBへのリンクを確立するための具体的な手順が記載されています。これには、リンクの選択、リンク接続メッセージの送信、確認応答の処理などが含まれます。
ネットワークIDの比較に基づき、リンク確立の優先順位が決定される方法についても説明しています。
補助リンク:
補助リンクの確立方法について説明しています。補助リンクはユーザープログラムによってリクエストされ、モニタープログラムがリンクの設定を行います。
ホスト間の補助リンクの確立手順や、特定の条件下での待機時間の設定についても詳述されています。
エラー処理:
ネットワーク内の通信メッセージに対するエラー検出と処理方法について説明しています。各メッセージにはチェックサムが関連付けられ、エラー検出アルゴリズムが適用されます。
エラーメッセージの送信やパニックルーチンの呼び出しなど、エラーが発生した場合の具体的な処理手順が記載されています。
モニター機能:
ネットワークI/Oドライバの入力メッセージの処理手順について説明しています。これには、エラーチェック、文字コードの変換、確認応答の送信などが含まれます。
影響
RFC 2は、ARPANETの初期設計における重要な技術仕様を提供し、ネットワーク内のホスト間通信の基礎を築きました。この文書は、後のRFC文書やネットワークプロトコルの開発における基本的なリファレンスとなりました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 2 - Host Software【64†source】【65†source】
RFC 3: Documentation Conventions
概要
タイトル: Documentation Conventions
著者: Steve Crocker
発行日: 1969年4月
内容: RFC 3は、ネットワークワーキンググループ（NWG）のドキュメント作成および管理に関するガイドラインを提供しています。具体的には、NWGノートの内容、形式、および配布方法に関する基準を示しています。
主要な内容
ネットワークワーキンググループ（NWG）の役割:
NWGは、ホストソフトウェア、ネットワークの利用戦略、および初期のネットワーク実験に関する研究を行っています。
NWGノートは、ネットワークの設計、実装、運用に関する考えや提案を記録するためのものです。
NWGノートの内容:
NWGノートには、ホストソフトウェアやネットワークに関連する任意の考えや提案を含めることができます。
ノートは、洗練されたものである必要はなく、迅速に情報を共有することが奨励されています。
哲学的な立場の表明や具体例のない提案、質問のみの記述なども許容されます。
形式:
すべてのNWGノートには以下の情報が含まれるべきです：
「Network Working Group」
「Request for Comments: x」（xは連番）
著者とその所属
日付
タイトル（タイトルは一意である必要はありません）
配布方法:
各NWGノートは、著者のサイトから特定の関係者（例：Bob Kahn, Larry Roberts, Steve Carrなど）に1部ずつ送られます。
必要に応じてローカルで複製することができます。
その他のノート:
現在までに2つのノートが作成されており、両方とも「HOST Software」というタイトルで、Steve CrockerとBill Duvallがそれぞれ作成しています。
予定されている他のノートには、「Network Timetable」、「The Philosophy of NIL」、「Specifications for NIL」、「Deeper Documentation of HOST Software」などがあります。
影響
RFC 3は、ARPANETの初期設計におけるドキュメント作成と情報共有のための基準を確立しました。このガイドラインにより、ネットワークの開発と運用に関する情報を効率的に共有する文化が確立されました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 3 - Documentation Conventions【71†source】【72†source】
RFC 3: Documentation Conventions
概要
タイトル: Documentation Conventions
著者: Steve Crocker
発行日: 1969年4月
内容: RFC 3は、ネットワークワーキンググループ（NWG）のドキュメント作成および管理に関するガイドラインを提供しています。このRFCは、NWGノートの内容、形式、配布方法についての基準を示しており、初期のインターネットの設計と運用に関する情報共有の方法を規定しています。
主要な内容
ネットワークワーキンググループ（NWG）の役割:
NWGは、ホストソフトウェア、ネットワークの利用戦略、初期のネットワーク実験に関する研究を行っています。
NWGノートは、ネットワークの設計、実装、運用に関する考えや提案を記録するためのものです。
NWGノートの内容:
NWGノートには、ホストソフトウェアやネットワークに関連する任意の考えや提案を含めることができます。
ノートは、洗練されたものである必要はなく、迅速に情報を共有することが奨励されています。
哲学的な立場の表明や具体例のない提案、質問のみの記述なども許容されます。
形式:
すべてのNWGノートには以下の情報が含まれるべきです：
「Network Working Group」
「Request for Comments: x」（xは連番）
著者とその所属
日付
タイトル（タイトルは一意である必要はありません）
配布方法:
各NWGノートは、著者のサイトから特定の関係者（例：Bob Kahn, Larry Roberts, Steve Carrなど）に1部ずつ送られます。
必要に応じてローカルで複製することができます。
その他のノート:
現在までに2つのノートが作成されており、両方とも「HOST Software」というタイトルで、Steve CrockerとBill Duvallがそれぞれ作成しています。
予定されている他のノートには、「Network Timetable」、「The Philosophy of NIL」、「Specifications for NIL」、「Deeper Documentation of HOST Software」などがあります。
影響
RFC 3は、ARPANETの初期設計におけるドキュメント作成と情報共有のための基準を確立しました。このガイドラインにより、ネットワークの開発と運用に関する情報を効率的に共有する文化が確立されました。
参照
RFC 3は、初期のインターネット技術の発展における重要な文書であり、ネットワークの設計と運用に関する情報の記録と共有の基礎を築きました。この文書により、技術者間のコミュニケーションが促進され、インターネットの進化を支えました。
RFC 4: Network Timetable
概要
タイトル: Network Timetable
著者: Elmer B. Shapiro
発行日: 1969年3月24日
内容: RFC 4は、ARPANETのネットワークチェックアウト、通信機器の設置、ホスト-IMP（Interface Message Processor）インターフェースの設計およびテスト、メッセージテストのスケジュールと手順を含む、初期のネットワークタイムテーブルを提供しています。この文書は、ネットワークの各ステージにおける具体的なタスクと期限を示しています。
主要な内容
ネットワークチェックアウト:
ネットワークの初期チェックアウトに関するタスクが含まれます。
通信機器の設置（1969年8月1日）:
AT&TおよびBBNからの寸法、電力、配線仕様の取得
最大テレコケーブル長を決定するための代替位置の確立
音声調整回路の配置と情報の確立
AC電力の注文と設置（関連タスクと調整）
ホスト-IMPインターフェースの設計と構築（1969年9月1日）:
BBNからの仕様取得
試行設計の開発
システムプログラマとのレビュー
最終設計の確立
ハードウェアの設計と構築
ハードウェアループテストでの試行ソフトウェアのデバッグ
IMPの設置（1969年9月15日）:
BBNからの寸法、電力、配線仕様の取得
SRIによるAC電力の注文と設置
ホスト-IMPインターフェースのデバッグ（1969年10月1日）:
BBNからデバッグ仕様と手順を取得
テストメッセージの転送、クラッシュと回復手順、メッセージの充填およびストリッピング手順の確認
自身の転送テストを実施
UCLA-SRI間のメッセージテスト（1969年10月15日）:
ネットワーク構成
テストメッセージの形式、シーケンス、チェック、手順、障害報告の合意
メッセージの整合性、配信シーケンスのテスト、遅延の測定
異常条件へのシステム応答、施設の喪失と復旧
UCSB-SRI間のメッセージテスト（1969年11月15日）:
ネットワーク構成とテスト手順の拡張
UTAH-SRI間のメッセージテスト（1969年12月15日）:
以前のテストの選択グループ
音声調整スキームの拡張
単純なTTYシステムの運用:
シングルユーザーおよびマルチユーザーアクセスの手順
ログイン、ログアウト、サブシステムの入退出
エラーメッセージ、クラッシュ、回復の処理
メッセージ形式とプロトコルの確立
ファイルの保存と取得
参照
詳細な内容については、以下のリンクから全文を参照できます：
RFC 4は、ARPANETの初期開発における重要な計画文書であり、ネットワーク構築の具体的なスケジュールと手順を提供しています。この文書により、ネットワーク開発の各ステージにおけるタスクと期限が明確にされ、効果的なプロジェクト管理が可能となりました。
RFC 5: Decode-Encode Language (DEL)
概要
タイトル: Decode-Encode Language (DEL)
著者: Jeff Rulifson
発行日: 1969年6月
内容: RFC 5は、Decode-Encode Language (DEL)と呼ばれる機械独立型の言語について説明しています。この言語は、特定のネットワークタスク、特にインタラクティブコンソールからの入力コードの受け取りと即時応答、およびデータのエンコードとデコードを効率的に処理するために設計されています。
主要な内容
DELの目的:
DELは、インタラクティブなコンソールから入力されたコードを受け取り、即時に応答するために設計されています。
また、データのエンコードとデコードを効率的に処理するための言語としても機能します。
言語の特徴:
機械独立: DELは特定のハードウェアやソフトウェアに依存せず、汎用的に使用できるように設計されています。
インタラクティブ処理: ユーザーの入力に即座に反応し、適切な応答を生成する能力を持っています。
具体的な使用例:
DELは、ネットワーク上の様々なタスクに適用可能です。特に、リアルタイムでのデータ処理や、ユーザーインターフェースの開発に役立ちます。
技術的詳細:
文書には、DELの構文やセマンティクスに関する詳細な説明が含まれています。また、具体的なコード例も提示されており、実際の使用方法を示しています。
影響
RFC 5は、ネットワークの初期設計と実装における重要な役割を果たしました。この言語は、当時のネットワーク技術者にとって、リアルタイムのデータ処理とインタラクティブシステムの開発に必要なツールを提供しました。
参照
詳細な内容については、以下のリンクから全文を参照できます：
この文書は、ネットワーク技術の進化において重要なステップとなり、後のプロトコルや技術の基礎を築きました。
RFC 6: Conversation with Bob Kahn
概要
タイトル: Conversation with Bob Kahn
著者: Steve Crocker
発行日: 1969年4月10日
内容: RFC 6は、Steve CrockerとBob Kahnとの会話内容を記録した文書です。この会話では、IMP（Interface Message Processor）におけるコード変換、IMPとホスト間の通信、およびホストソフトウェアについて議論されています。
主要な内容
コード変換:
BB&N（Bolt, Beranek and Newman）は、6ビット、7ビット、8ビット、9ビットの文字コードを8ビットASCIIに変換し、受信側のIMPで再変換する準備が整っていることが述べられています。
特定のホストに固有の変換テーブルを使用して、一対一の変換スキームが計画されています。
6ビットコードを使用する場所では、大文字・小文字のシフトが必要になる可能性があり、過度のシフトがオーバーフローを引き起こすことについても議論されています。
IMPとホスト間の通信:
5ビットのリンクフィールドと変換を示すビットを含む新しい通信プロトコルが検討されています。
メッセージ送信前と送信後の変換を示す2ビットの変換インジケーターを導入することが提案されました。
メッセージ機能:
ホストはIMPに対して以下の情報を送信できます：
トレーシング
変換
メッセージが宛先のIMPかホスト向けか
RFNMの送信
ホストの状態（アップまたはダウン）
同期
フォーマットエラーメッセージ
マスターリンククリア
ステータス要求
IMPはホストに対して以下の情報を送信できます：
変換
REFNMの到着
IMPの状態（アップまたはダウン）
同期
呼び出されたホストが応答しない
フォーマットエラー
IMPのステータス
参照
詳細な内容については、以下のリンクから全文を参照できます：
この文書は、ARPANETの初期設計と実装における重要なコミュニケーションと技術的な議論を記録したものであり、ネットワークプロトコルの発展に寄与しました。
RFC 7: Host-IMP Interface
概要
タイトル: Host-IMP Interface
著者: G. Deloche
発行日: 1969年5月
内容: RFC 7は、ホストコンピュータとインターフェースメッセージプロセッサ（IMP）間の通信インターフェースに関する初期設計と仕様を記述しています。この文書は、ホスト-IMP間のデータ交換と通信プロトコルに焦点を当てています。
主要な内容
システム構成:
システムは主に2つのプログラムで構成されています：
ハンドラープログラム: チャネルハードウェアユニットを駆動し、ネットワークプログラムからのデータ送信リクエストを処理します。
ネットワークプログラム: ユーザーの送信リクエストを実行し、入力データと出力データを管理します。
データの交換:
ハンドラープログラムとネットワークプログラムは、バッファプールとインターフェーステーブルを介してデータを交換します。
ネットワークプログラムの機能:
多重化機能: 送信メッセージを多重化し、受信メッセージを分配します。リンク識別番号に基づいてメッセージをスタックし、バッファプールを埋めることでハンドラーを常に稼働させます。
出力メッセージ処理: ユーザーのプログラムがテキストを送信する場合、テキストの位置、バイト単位の長さ、宛先を指定します。ネットワークプログラムはこれらのデータを使用して16ビットのホストヘッダを準備し、テキストを処理します。
ハンドラープログラムの機能:
チャネルハードウェアの制御: データの送信を開始し、バッファ間のデータチェーンを提供し、割り込みを受信したときにデバイスのステータスをテストします。
バッファの管理: ネットワークプログラムが埋めたバッファを空にし、インターフェーステーブルの内容を更新します。
バッファとインターフェーステーブル:
バッファは、ホストメッセージの最大テキスト長（1006バイト）を収容するのに十分な大きさである必要があります。バッファサイズは256ワード（1024バイト）とすることが推奨されています。
インターフェーステーブルは、ネットワークプログラムがハンドラーにデータの位置と長さを通知するために使用されます。このテーブルはリングテーブルであり、ネットワークプログラムとハンドラープログラムによってそれぞれ更新されます。
質問
文書の最後には、いくつかの技術的な質問が含まれています：
ホストとIMP間の簡単な制御手順がない理由
特別なチャネルハードウェアユニットの接続方法
ユーザーネットワークプログラムインターフェースの設計に関する情報の入手時期
参照
詳細な内容については、以下のリンクから全文を参照できます：
RFC 7は、ARPANETの初期設計におけるホスト-IMP間の通信の基本を定義した重要な文書です。これにより、ネットワークプロトコルの発展と標準化の基礎が築かれました。
RFC 8: ARPA Network Functional Specifications
概要
タイトル: ARPA Network Functional Specifications
著者: G. Deloche
発行日: 1969年5月
内容: RFC 8は、ARPANETのネットワーク機能に関する仕様を提供しています。この文書は、インターフェースメッセージプロセッサ（IMP）とホストコンピュータ間のインターフェースに関する技術的な詳細を記述しています。
主要な内容
システム機能:
IMPとホスト間の通信を確立し、管理するための基本的な機能と手順を規定しています。
ネットワークの初期設計と動作に関するガイドラインを提供し、信頼性の高いデータ通信を実現するための基礎を築いています。
データ通信プロトコル:
メッセージのフォーマットや、データの送受信方法について詳細に説明しています。
エラー処理、データ転送の確認、再送信のメカニズムなど、信頼性を確保するためのプロトコルが含まれています。
IMPの機能と役割:
IMPの役割とその機能についての詳細が記載されています。IMPは、ホストコンピュータ間のデータ通信を仲介し、ネットワーク全体の通信を管理します。
ホストソフトウェアの要件:
ホストコンピュータがIMPと効果的に通信するために必要なソフトウェア要件を明示しています。
ホストソフトウェアが満たすべき機能とインターフェースについて具体的な指針を提供しています。
影響
RFC 8は、ARPANETの初期設計と実装における重要な技術仕様を提供し、ネットワークプロトコルの標準化に寄与しました。この文書は、後のインターネットプロトコルの開発における基盤となり、ネットワーク技術の進化を支えました。
参照
詳細な内容については、以下のリンクから全文を参照できます：
この文書は、インターネットの進化とその技術的基盤を理解するための重要なリソースです。
RFC 9: Host Software
概要
タイトル: Host Software
著者: G. Deloche
発行日: 1969年5月
内容: RFC 9は、ホストソフトウェアの仕様に関するドキュメントであり、ARPANETのホストコンピュータで使用されるソフトウェアの基本設計と機能について説明しています。この文書は、ネットワークに接続されたホストがどのようにIMP（Interface Message Processor）と連携するかに焦点を当てています。
主要な内容
ホスト-IMPインターフェース:
IMPとホスト間の通信方法やデータ転送のプロトコルについて記述されています。ホストはIMPを通じて他のホストとデータを交換し、IMPはその通信を管理します。
ソフトウェア設計:
ホストソフトウェアの基本的な設計原則や機能要件が示されています。これには、データの送受信、エラーチェック、再送信メカニズムなどが含まれます。
エラー処理:
通信中のエラーを検出し、修正するための手順が詳細に説明されています。これにより、データ転送の信頼性が確保されます。
データフォーマット:
IMPとホスト間でやり取りされるデータのフォーマットや、メッセージ構造について具体的な例を挙げて説明しています。
影響
RFC 9は、ARPANETの初期設計と実装における重要な技術仕様を提供し、ネットワークプロトコルの標準化に寄与しました。この文書は、後のインターネットプロトコルの開発における基盤となり、ネットワーク技術の進化を支えました。
参照
詳細な内容については、以下のリンクから全文を参照できます：
RFC 10: Documentation Conventions
概要
タイトル: Documentation Conventions
著者: Steve Crocker
発行日: 1969年7月29日
内容: RFC 10は、ネットワークワーキンググループ（NWG）のドキュメント作成および管理に関するガイドラインを提供しています。この文書は、NWGノートの内容、形式、配布方法についての基準を示しており、初期のインターネットの設計と運用に関する情報共有の方法を規定しています。
主要な内容
ネットワークワーキンググループ（NWG）の役割:
NWGは、ホストソフトウェア、ネットワーク利用の戦略、ネットワークに関する初期の経験について研究を行っています。
NWGノートは、ネットワークの設計、実装、運用に関する考えや提案を記録するためのものです。
NWGノートの内容:
NWGノートには、ホストソフトウェアやネットワークに関連する任意の考えや提案を含めることができます。
ノートは、洗練されたものである必要はなく、迅速に情報を共有することが奨励されています。
哲学的な立場の表明や具体例のない提案、質問のみの記述なども許容されます。
形式:
すべてのNWGノートには以下の情報が含まれるべきです：
「Network Working Group」
「Request for Comments: x」（xは連番）
著者とその所属
日付
タイトル（タイトルは一意である必要はありません）
配布方法:
各NWGノートは、著者のサイトから特定の関係者に1部ずつ送られます。これには、Steve Crocker（UCLA）、Ron Stoughton（UCSB）、Elmer Shapiro（SRI）、Steve Carr（Utah）、John Haefner（RAND）、Paul Rovner（Lincoln Labs）、Bob Kahn（BB&N）、Larry Roberts（ARPA）、Jerry Cole（SDC）などが含まれます。
必要に応じてローカルで複製することができます。
影響
RFC 10は、ARPANETの初期設計におけるドキュメント作成と情報共有のための基準を確立しました。このガイドラインにより、ネットワークの開発と運用に関する情報を効率的に共有する文化が確立されました。これにより、技術者間のコミュニケーションが促進され、インターネットの進化を支えました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 11: Implementation of the Host-Host Software Procedures in GORDO
概要
タイトル: Implementation of the Host-Host Software Procedures in GORDO
著者: G. Deloche
発行日: 1969年8月
内容: RFC 11は、GORDOというシステムにおけるホスト間のソフトウェア手続きを実装するための仕様を提供しています。この文書は、ホストとIMP（Interface Message Processor）間の通信プロトコルやデータ交換の方法に焦点を当てています。
主要な内容
ホスト間の接続手順:
主接続の確立（OPENPRIM）: ホスト間の主接続を確立する手順が示されています。ホストAのネットワークプログラムがホストBのネットワークプログラムと対話し、接続を確立します。具体的なメッセージフォーマットや確認応答の方法が詳細に説明されています。
補助接続の確立（OPENAUXI）: 主接続と同様に、補助接続を確立する手順も示されています。これにより、複数のデータリンクを同時に使用できます。
データの送受信（TRANSM）:
主接続を介したデータ送信: ユーザーがホストAからホストBのオペレーティングシステムにサインインし、リモートプログラム（URSAなど）を呼び出す手順が示されています。
補助接続を介したデータ送信: 主接続とは別に、補助接続を介してデータを交換する方法が説明されています。
接続の終了（CLOSE）:
接続の終了手順が詳細に説明されています。ユーザーがCLOSEサブルーチンを呼び出し、ネットワークプログラムが制御メッセージを交換して接続を終了します。
GORDOシステムの概要:
GORDOファイルシステム: ページ指向のファイルシステムで、ファイルとディレクトリで構成されています。ファイルは見出しと本文からなり、ディレクトリは他のファイルやディレクトリへのエントリを含みます。
GORDOプロセス: プロセスはプログラムとその論理環境から成り、システムコール（FORK）を通じて作成されます。プロセスは仮想空間を参照し、サービスコールを通じてファイルスペースからページを取り込むことができます。
データ構造とソフトウェアの組織:
割り当てテーブル: ホスト、接続、入力リンクに関するテーブルが記述され、リンクの確立、識別、終了のために使用されます。
ネットワークプログラム: 主にユーザーの要求に応じて接続の開閉やデータの送受信を行います。
参照
詳細な内容については、以下のリンクから全文を参照できます：
RFC 12: IMP-Host Interface Flow Diagrams
概要
タイトル: IMP-Host Interface Flow Diagrams
著者: M. Wingfield
発行日: 1969年8月26日
内容: RFC 12は、BBN Report No. 1822の付録Bから抽出されたフローダイアグラムを提供しています。これらのダイアグラムは、IMP（Interface Message Processor）とホスト間のインターフェースにおけるハードウェア操作の論理的なシーケンスを示しています。
主要な内容
IMPからホストへのメッセージ処理:
フローダイアグラムは、IMPからホストにメッセージを送信する際の一連の操作を視覚的に表現しています。
各ステップには、初期化、エラーチェック、データパディング、カウンターの操作、シフトレジスタのパルス処理などが含まれます。
ホストからIMPへのメッセージ処理:
逆に、ホストからIMPにメッセージを送信する際のプロセスも詳細に記述されています。
カウンターの設定、出力リクエストのクリア、データストローブ操作、シフトレジスタのロードなどが含まれます。
エラーチェックとデータパディング:
メッセージ送信中に発生する可能性のあるエラーをチェックし、必要に応じてデータをパディングする手順が示されています。
エラーチェックには、IMPエラーの検出、パディングビットの確認などが含まれます。
カウンターとシフトレジスタの操作:
メッセージ処理において重要な役割を果たすカウンターとシフトレジスタの操作手順が詳細に説明されています。
各操作はフローダイアグラム内のブロックで視覚的に示され、プロセスの理解を助けます。
影響
RFC 12は、IMPとホスト間の通信の詳細を理解するための重要な技術文書であり、ネットワークの信頼性と効率性を確保するための基本的なプロトコルの一部を形成しています。この文書により、ネットワークの設計者とエンジニアは、IMPとホスト間のインターフェースの動作を正確に理解し、適切なシステムを構築するための基礎を得ることができます。
参照
詳細な内容については、以下のリンクから全文を参照できます：
RFC 13: Zero Text Length EOF Message
概要
タイトル: Zero Text Length EOF Message
著者: Vint Cerf
発行日: 1969年8月20日
内容: RFC 13は、補助接続を介したファイル伝送において「ファイルの終わり」を指定するためのメカニズムについて説明しています。この文書は、EOF（End-Of-File）メッセージとして長さ0のメッセージを使用することを提案しています。
主要な内容
背景と目的:
RFC 11に関連して、ファイル伝送の補助接続ではEOFを明示的に指定するメカニズムが必要であることが述べられています。
ファイルの終わりを指定するために長さ0のメッセージを使用することが提案されています。
EOFメッセージのフォーマット:
このフォーマットはリーダー、マーキング、チェックサム、パディングで構成されています。
実装の意図:
このEOFメッセージを使用することで、補助接続を介したファイル伝送が完了したことを明示的に示すことができます。
長さ0のメッセージを使うことで、追加のデータを送信することなくファイルの終わりを指定できるため、効率的な通信が可能になります。
影響
RFC 13は、補助接続を介したファイル伝送におけるEOFの明示的な指定方法を提供することで、通信プロトコルの効率性と信頼性を向上させました。この仕様により、ファイル伝送が終了したことを正確に伝えることが可能になり、通信の管理がより簡単になりました。
参照
詳細な内容については、以下のリンクから全文を参照できます：
この文書は、初期のインターネット技術の発展において重要な役割を果たし、後のプロトコル設計に影響を与えました。
RFC 14: Flow Control – More Efficient and Easily Implemented
概要
タイトル: Flow Control – More Efficient and Easily Implemented
著者: Steve Crocker
発行日: 1969年10月
内容: RFC 14は、データ通信におけるフロー制御の効率化と簡便な実装方法について説明しています。この文書は、通信ネットワークにおけるデータフローを最適化するための方法を提案し、エラー処理や再送メカニズムの改善を目指しています。
主要な内容
フロー制御の必要性:
データ通信において、送信者と受信者の間でデータの流れを適切に管理する必要があります。これにより、ネットワークの過負荷を防ぎ、通信の信頼性を向上させます。
効率的なフロー制御の提案:
フロー制御を効率化するための新しい方法を提案しています。これには、送信者がデータを一定の間隔で送り、受信者がデータを受け取るペースを調整するメカニズムが含まれます。
エラー処理の改善:
データの誤りを検出し、必要に応じて再送を行うための手順が詳述されています。これにより、データ通信の信頼性がさらに向上します。
実装の簡便化:
提案されたフロー制御メカニズムは、既存のシステムに容易に実装できるように設計されています。これにより、開発者は効果的なフロー制御を簡単に導入できます。
影響
RFC 14は、ネットワーク通信の効率性と信頼性を向上させるための重要な提案を行っています。この文書は、フロー制御の分野における基礎を築き、後のプロトコル開発においても参考となる重要なリソースです。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 15: Network Subsystem for Time Sharing Hosts
概要
タイトル: Network Subsystem for Time Sharing Hosts
著者: C. Stephen Carr
発行日: 1969年9月25日
内容: RFC 15は、タイムシェアリングホスト用のネットワークサブシステムについて説明しています。この文書は、ホストコンピュータ間でデータをやり取りするための基本的なシステムコールと、それを利用した簡便なネットワークアクセス手段を提供するための提案です。
主要な内容
システムプリミティブ:
オープン接続: 主接続および補助接続を開くためのシステムコール。
データ送信: 接続を介してデータを送信するための手順。
接続の閉鎖: データ通信が終了した後、接続を閉じるための手順。
これらのプリミティブは、ホストのオペレーティングシステムに組み込まれ、プログラマーが利用できるように設計されています。
基本的なターミナルアクセス:
ユーザーが特別なプログラミングを必要とせずに、リモートホストに直接アクセスできるサブシステムプログラムを提供することが望まれています。
提案されたサブシステム「Telnet」は、ネットワークシステムプリミティブをラップするシェルプログラムであり、リモートホストのターミナルとして機能します。
Telnetサブシステム:
ユーザーがリモートホストにログインし、リモートホストのターミナルとして操作するためのコマンドを提供します。
ESCAPE CHARACTER IS: Telnetが監視するエスケープ文字を宣言します。
CONNECT TO: 接続を確立したいホストの公式サイト名を入力します。
LOGOUT: サービスホストへのログアウトコマンドを発行します。
COPY FILE: ユーザーホストのファイルシステムからサービスホストへデータを移動するためのファイルコピーコマンドです。
影響
RFC 15は、ARPANETの初期設計における重要な技術文書であり、タイムシェアリングホスト間のデータ通信を効率化し、ユーザーがリモートホストに容易にアクセスできるようにするための基本的な仕組みを提供しました。この文書により、ネットワークの利用がより便利になり、インターネットの発展に寄与しました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 16: M.I.T.
概要
タイトル: M.I.T.
著者: Steve Crocker
発行日: 1969年8月27日
内容: RFC 16は、ネットワークワーキンググループ（NWG）のメモの受信者をM.I.T.に変更することを発表しています。この文書は、メモの送付先として指定されたM.I.T.の担当者と連絡先情報を提供しています。
主要な内容
新しいメモの送付先:
宛先: Abhai Bhushan
所在地: Room 807 - Project MAC, 545 Technology Square, Cambridge, Mass. 02139
電話番号: (617) 864-6900, X 5857
目的:
NWGのメモの受信をM.I.T.が担当することになったことを通知するための文書です。
これにより、NWGの活動がより効率的に管理され、ドキュメントの流通が改善されます。
文書の背景:
これは初期のインターネット開発における重要な手続きを示すものであり、ドキュメントの管理と共有の方法を改善することを目的としています。
影響
RFC 16は、ARPANETの初期開発におけるドキュメント管理の改善に寄与しました。この変更により、ネットワークの設計と実装に関する情報の共有がより効果的になり、開発プロセスが円滑に進行するようになりました。
詳細な内容については、以下のリンクから全文を参照できます：
この文書は、インターネットの発展における初期の重要なステップを示しています。
RFC 17: Some Questions Re: Host-IMP Protocol
概要
タイトル: Some Questions Re: Host-IMP Protocol
著者: John Kreznar
発行日: 1969年8月
内容: RFC 17は、ホスト-IMPプロトコルに関するいくつかの質問と、それに対する回答を記載した文書です。John Kreznarが提起した質問に対し、Bob Kahnが回答しています。
主要な内容
自動リンク削除の問題:
BBN 1822のページ11に記載されている自動リンク削除のメカニズムに対する疑問が提起されています。
特に、リンクの使用がタイムシェアリング端末の人間の使用に依存している場合や、プログラムが遅延する場合の影響について述べられています。
RFNMの制御:
Steve Crockerが提起した、ホストがRFNM（Ready For Next Message）を制御できるかどうかについての質問が再提起されています。
IMPがRFNMを生成し、ホストにタイムリーにメッセージを届けられない場合の影響についても議論されています。
メッセージの再送要求:
BBN 1822のページ17に記載されているように、ホストがネットワークにメッセージを再送する準備が必要であることについて疑問が提起されています。
任意の遅延:
BBN 1822のページ23に記載されている「任意の遅延」が自動リンク削除手順と矛盾しているかどうかについての質問です。
高優先度の非ネットワークホストの責任により、次のビットが長時間遅れる可能性がある場合の影響について述べられています。
影響
RFC 17は、ホスト-IMPプロトコルの仕様に関する重要な議論を含んでおり、ネットワーク設計の改善とプロトコルの信頼性向上に貢献しました。これらの議論は、ネットワークの効率的な運用とエラー処理のための基礎を築く上で重要な役割を果たしました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 18: IMP-IMP and HOST-HOST Control Links
概要
タイトル: IMP-IMP and HOST-HOST Control Links
著者: Vint Cerf
発行日: 1969年9月
内容: RFC 18は、ARPANETにおけるIMP（Interface Message Processor）とホスト間の通信リンクの管理について説明しています。この文書は、ホスト間の制御リンクとIMP間の制御リンクを明確に分離することを提案しています。
主要な内容
ホスト-ホスト間の制御リンク:
リンク1をホスト間の制御リンクとして使用することが提案されています。これにより、ホスト間の通信が効率的に管理され、データ転送の遅延が最小限に抑えられます。
IMP-IMP間の制御リンク:
リンク0をIMP間の制御リンクとして使用することが提案されています。この設定により、IMP間の通信がホスト間の通信に干渉することを避け、ネットワーク全体の通信効率が向上します。
目的:
提案されたリンクの分離は、ホストとIMP間の通信の干渉を減らし、両者の通信が円滑に行われるようにすることを目的としています。この方法により、通信の遅延やエラーが減少し、ネットワークのパフォーマンスが向上します。
影響
RFC 18は、ARPANETの初期設計における重要な技術文書であり、ホスト間およびIMP間の通信を効果的に管理するための基盤を提供しました。この文書は、ネットワークの設計と運用において重要な役割を果たし、インターネットの発展に寄与しました。
参照
詳細な内容については、以下のリンクから全文を参照できます：
この文書は、初期のインターネット技術の発展における重要なステップを示しています。
RFC 19: Two Protocol Suggestions to Reduce Congestion at Swap-Bound Nodes
概要
タイトル: Two Protocol Suggestions to Reduce Congestion at Swap-Bound Nodes
著者: John E. Kreznar
発行日: 1969年10月7日
内容: RFC 19では、スワップ境界ノードでの輻輳を緩和するための2つのプロトコル提案が紹介されています。特に、コアストアと補助ストア間のスワップ速度に大きな差があるホストシステムに関する問題に対処しています。
主要な内容
IMPからホストへのトラフィック順序制御:
現在のIMP-HOSTプロトコルでは、IMPが受信した順序でメッセージをホストに配信することが求められています。この順序が原因で、不要なスワッピングが発生することがあります。
提案: ホストがIMPの待機メッセージキューを読み取り、最も効果的な順序でメッセージを受け入れることができるようにする。この変更により、ネットワーク効率が向上します。
ホスト間のコア間転送:
ホスト-IMPプロトコルやIMPソフトウェアの変更を伴わない、ホスト-ホストプロトコルを提案します。これにより、協力するホストがマルチメッセージファイル転送の間、適切なプログラムをコアにロックすることができます。
この方法は、特にスワップ境界ホストとのファイル転送時間を大幅に短縮する可能性がありますが、タイムシェアリング環境で単一プログラムを長時間コアにロックすることは現実的ではない場合があります。
影響
RFC 19は、ネットワークの輻輳を減らし、通信の効率を向上させるための重要な提案を行っています。特に、スワップ境界ノードのパフォーマンスを改善し、全体的なネットワークのユーティリティを向上させるための基盤を提供しました。
参照
詳細な内容については、以下のリンクから全文を参照できます：
RFC 20: ASCII format for Network Interchange
概要
タイトル: ASCII format for Network Interchange
著者: V.G. Cerf
発行日: 1969年10月
内容: RFC 20は、ネットワーク上で使用するためのASCII形式について詳細に記述しています。この文書は、文字の表現方法とコードの識別について標準化された7ビットの文字表現を説明しています。
主要な内容
文字の表現とコードの識別:
標準的な7ビット文字表現について説明しており、各ビットの位置とその役割を示しています。たとえば、文字"K"のビット表現は「b7 b6 b5 b4 b3 b2 b1」となり、具体的なビットパターンが示されています。
コードテーブルの位置は、「列/行」の形式でも表現されます。例として、文字"K"は「4/11」として表されます。
制御文字:
制御文字のリストとその役割について記述されています。たとえば、「NUL」はNullを意味し、タイムフィルやメディアフィルとして使用されます。「BEL」はベル音を出して人間の注意を引くために使用されます。
他にも「STX（テキストの開始）」、「ETX（テキストの終了）」、「EOT（伝送終了）」などの制御文字が含まれます。
グラフィック文字:
スペース、感嘆符、引用符、ドル記号などのグラフィック文字のリストとそのコード位置が示されています。各文字の名前とその用途についても説明されています。
定義:
制御文字（CC）、フォーマット効果文字（FE）、情報セパレータ（IS）などの一般的な定義が提供されています。これらの文字は通信ネットワーク上で情報の送信を制御するために使用されます。
影響
RFC 20は、ネットワーク上でデータを標準化して交換するための重要な文書であり、初期のインターネット通信における文字データの統一的な扱い方を確立しました。この文書は、ASCIIコードの標準化に大きく貢献し、後のプロトコル開発においても基礎となるリファレンスとなりました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 21: Network Meeting
概要
タイトル: Network Meeting
著者: V. Cerf
発行日: 1969年10月17日
内容: RFC 21は、1969年10月10日にUCLAで行われたネットワーク会議の内容を記録したものです。この会議には、複数の機関からの参加者が出席し、ARPANETの設計と運用に関する重要なトピックが議論されました。
参加者
SDC: John Kreznar, Dick Linde
UCLA: Vint Cerf, Steve Crocker, Marty Bleier, Jon Postel, Bob Long, Michel Elie
UCSB: Ron Stoughton, Nancy O'Hara, George Gregg
議題
BBN Memo 1822の修正
メモ1822のページ11には、IMPプログラムが同時に扱える送信リンクと受信リンクがそれぞれ63までであることが記載されています。新しいリンクを送信しようとすると「Link Table Full」のメッセージがホストに送信され、メッセージは破棄されます。
リンクが26秒以上使用されない場合、自動的に削除されることが記載されています。この削除のタイミングについての議論が行われましたが、リンクテーブルが満杯になる前に削除するべきかどうかについては意見が分かれました。
NWG/RFC 11の修正
RFC 11は、UCLAでの開発と他のノードとの議論により、廃止されることが決定されました。新しいバージョンがRFC 22として発行される予定です。
複数の制御メッセージの伝送
UCSBのGeorge Greggが、制御リンクを介した複数の制御メッセージの伝送に関するRFC 23を発行する予定であることが発表されました。
影響
この会議は、ARPANETの設計と運用における重要な変更と改善をもたらし、初期のインターネットプロトコルの発展に寄与しました。特に、リンク管理やメッセージ伝送の効率化に関する議論は、ネットワークの信頼性とパフォーマンスの向上に貢献しました。
詳細な内容については、以下のリンクから全文を参照できます：
RFC 22: Host-Host Control Message Formats
概要: RFC 22は、ホスト間の制御メッセージフォーマットについて詳細に記述しています。特に、7ビットASCIIモードを使用しない新しい8ビットバイト形式のメッセージを提案しています。
主な内容:
メッセージは8ビットバイトのシーケンスで構成され、複数の制御メッセージを1つのパケットで送信できます。
9種類の制御メッセージが定義され、それぞれの制御バイトとパラメータバイトの解釈が提供されています。
影響: このRFCは、ホスト間通信の効率化と柔軟性向上を目指し、ネットワークのパフォーマンスを改善しました。
参照: 詳細はRFC 22を参照してください。
RFC 23: Transmission of Multiple Control Messages
概要: RFC 23は、制御リンクを介して複数の制御メッセージを伝送する方法について説明しています。
主な内容:
サイトのネットワークプログラムは、1つの制御通信で複数の制御メッセージを送受信できるように準備する必要があります。
制御リンクがRFNM（Ready for Next Message）を待っている間に、複数の制御メッセージが蓄積されることがあり、それらはリンクが解除されたときに一度に送信されます。
影響: これにより、通信の効率が向上し、ネットワークパフォーマンスが最適化されました。
参照: 詳細はRFC 23を参照してください。
RFC 24: Documentation Conventions
概要: RFC 24は、RFCシリーズのドキュメントの書式とスタイルに関するガイドラインを提供しています。
主な内容: ドキュメントの統一性と可読性を確保するための基本的なガイドラインが含まれています。
影響: 標準化された技術文書の作成を促進し、文書の一貫性と可読性を向上させました。
参照: 詳細はRFC 24を参照してください。
RFC 25: No High Link Numbers
概要: RFC 25は、リンク番号が高すぎる場合に発生する問題について述べています。
主な内容: 高いリンク番号の使用を避けるための提案が含まれています。
影響: ネットワークのリンク管理が改善され、エラーの発生が減少しました。
参照: 詳細はRFC 25を参照してください。
RFC 26: IMP-Host Interface Commands
概要: RFC 26は、IMP（Interface Message Processor）とホスト間のインターフェースコマンドについて記述しています。
主な内容: IMPとホスト間で使用されるコマンドの詳細が含まれています。
影響: IMPとホスト間の通信が効率化されました。
参照: 詳細はRFC 26を参照してください。
RFC 27: A Proposed Experiment
概要: RFC 27は、ネットワークにおける実験提案について記述しています。
主な内容: 提案された実験の目的と方法が詳述されています。
影響: ネットワーク技術の開発とテストに寄与しました。
参照: 詳細はRFC 27を参照してください。
RFC 28: Time Line
概要: RFC 28は、ネットワークイベントのタイムラインについて記述しています。
主な内容: 重要なネットワークイベントとその時系列が提供されています。
影響: イベント管理とスケジューリングが改善されました。
参照: 詳細はRFC 28を参照してください。
RFC 29: Note in Response to Bill English's Request for Comments
概要: RFC 29は、Bill Englishのコメントに対する応答です。
主な内容: 提案へのフィードバックと追加のコメントが含まれています。
影響: 意見交換を通じて技術開発が促進されました。
参照: 詳細はRFC 29を参照してください。
RFC 30: Documentation Conventions
概要: RFC 30は、RFCシリーズのドキュメントの書式とスタイルに関する追加ガイドラインを提供しています。
主な内容: ドキュメントの形式と構造に関する詳細な指針が含まれています。
影響: ドキュメントの一貫性と可読性がさらに向上しました。
参照: 詳細はRFC 30を参照してください。
RFC 31: Binary Message Forms in Computer Networks
概要: RFC 31は、コンピュータネットワークにおけるバイナリメッセージ形式について説明しています。
主な内容: メッセージのフォーマット、ビットコーディング、シンボリック名の使用などが詳細に説明されています。
影響: バイナリメッセージの標準化に寄与し、ネットワーク間の互換性を向上させました。
参照: RFC 31 - Binary Message Forms in Computer Networks (RFC Editor)
RFC 32: Some Thoughts on SRI's Proposed Real Time Clock
概要: RFC 32は、ネットワークホストにリアルタイムクロックを追加する提案について述べています。これは、ユーザー指向のメッセージ遅延測定を可能にするためのものです。
主な内容:
内部ホスト遅延を含む遅延測定の重要性を強調。
1ミリ秒の解像度と1日（24時間）の範囲を持つクリスタル制御クロックの仕様提案。
クロックの読み取りメカニズムについての考察。
影響: このRFCは、ホスト間のメッセージ遅延を詳細に測定するための基盤を提供し、ネットワークのパフォーマンス解析と最適化に寄与しました。
参照: 詳細はRFC 32を参照してください。
RFC 33: New Host-Host Protocol
概要
タイトル: New Host-Host Protocol
著者: Steve Crocker
発行日: 1970年2月12日
内容: RFC 33は、新しいホスト間プロトコルの仕様を提供しています。このプロトコルは、ホスト間の通信を効率的かつ効果的に行うための基盤を提供します。
主な内容
メッセージのリーダー:
フィールド: ホスト、メッセージタイプ、フラグ、リンク番号
役割: メッセージの送信元と宛先ホストを特定し、通信の制御を行う。
リンクとRFNM（Request-for-Next-Message）メカニズム:
リンク番号: 送信元ホストと受信ホスト間の256個の論理パスの1つを特定。
RFNM: ホスト間のメッセージ送信を制御し、個々のリンクでの過負荷を防止する。
設計概念:
分散管理: 各ホストが独立して運用されるため、管理の分散化が重要。
タイムシェアリングシステム: 基本的なインタラクティブメカニズムの促進。
柔軟な利用: 経験豊富なプログラマーがネットワークを利用できるように、制限を最小限に抑える。
ソケットと接続:
ソケット: 接続の一端を形成し、ホスト間の通信を管理。
バーチャルネット: 各ユーザーが作成するプロセス群を一元的に管理。
システムコールと制御コマンド:
コール: Init、Listen、Accept、Closeなどのシステムコールを定義し、ホスト間の通信を管理。
影響
このRFCは、初期のインターネット技術の発展における重要なステップを示し、ホスト間の効率的な通信を確立するための基盤を提供しました。
参照
詳細はRFC 33を参照してください。
このように、RFC 33は新しいホスト間プロトコルを提案し、ネットワークの通信効率と管理を大幅に改善しました。
RFC 34: Some Brief Preliminary Notes on the Augmentation Research Center Clock
概要: RFC 34は、スタンフォード研究所のAugmentation Research Center（ARC）で使用される時計システムに関する予備的なメモです。時計システムは、XDS 940コンピュータのコアメモリに時間情報を記録するためのものです。
主な内容:
絶対時間: 月、日、年、時間、分、秒を含む2つの連続したワードに記録されます。
相対時間: 24ビットのバイナリ累積器の内容として記録され、更新頻度は100マイクロ秒または1ミリ秒ごとに選択できます。
精度: 初期設定の精度はWWV参照で1秒、オシレータのドリフト率は250日で1秒の誤差が見込まれます。
影響: このRFCは、ネットワークの時間管理と同期精度を向上させるための基盤を提供し、システムの信頼性とパフォーマンスを高めました。
参照: 詳細はRFC 34を参照してください。
RFC 35: Network Meeting
概要: RFC 35は、1969年10月31日にUCLAで行われたネットワーク会議の内容を記録しています。
主な内容:
IMPソフトウェア: IMPソフトウェアの改良とバグ修正に関する議論。
ホスト間通信: 効率的なホスト間通信のための提案と検討。
影響: このRFCは、ネットワークの設計と運用における重要なディスカッションを記録し、技術的な方向性を示しました。
参照: 詳細はRFC 35を参照してください。
RFC 36: Protocol Notes
概要: RFC 36は、ホスト間プロトコルに関する追加のノートを提供しています。
主な内容:
メッセージフォーマット: メッセージの構造と内容に関する詳細な仕様。
エラー処理: 通信中のエラー処理方法についての考察。
影響: このRFCは、ホスト間プロトコルの改良と標準化に寄与しました。
参照: 詳細はRFC 36を参照してください。
RFC 37: Network Meeting Epilogue
概要: RFC 37は、前述のネットワーク会議（RFC 35）に続く議論の結果を記録しています。
主な内容:
議論の要約: 主要なトピックと決定事項の要約。
次のステップ: 将来のアクションプランとフォローアップの手順。
影響: このRFCは、会議の成果を明確にし、次のステップを計画するための基盤を提供しました。
参照: 詳細はRFC 37を参照してください。
RFC 38: Comments on Network Protocol from NWG/RFC 36
概要: RFC 38は、RFC 36で提案されたプロトコルに関するコメントとフィードバックを提供しています。
主な内容:
提案の評価: 提案されたプロトコルの強みと弱点に関する評価。
改善提案: プロトコルの改善方法についての提案。
影響: このRFCは、プロトコルの評価と改良を促進し、ネットワークの信頼性と効率を向上させました。
参照: 詳細はRFC 38を参照してください。
詳細については、各RFCの公式リンクを参照してください。他のRFCも同様の方法で調査し、内容を確認できます。
RFC 39: Comments on Protocol Re: NWG/RFC #36
概要
タイトル: Comments on Protocol Re: NWG/RFC #36
著者: E. Harslem, J. Heafner
発行日: 1970年3月25日
内容: RFC 39は、NWG（Network Working Group）によって発行されたRFC 36のプロトコルに関するコメントと改善提案をまとめたものです。これには、エラーメッセージ、クエリ、プログラム終了通知、ホスト状態、送信とブロードキャストのコマンドに関する詳細な説明が含まれています。
主な内容
エラーメッセージ:
形式: `<ERR> <Code> <Command in error>`
種類: 内容エラー、ステータスエラー、リソースエラーの3種類があり、それぞれのエラーに対する具体的な例が提供されています。
クエリ:
形式: `<QRY> <My Socket>` または `<QRY> <Your Socket> <Text>`
機能: リモートNCPに接続状態を問い合わせるためのコマンド。
プログラム終了通知:
形式: `<TER> <My Socket>`
機能: プログラム間のすべての通信を終了するコマンドで、複数の`<CLS>`コマンドを実行する代わりに使用されます。
ホスト状態:
メッセージ: `<HCU>` (ホスト起動)、 `<HGD>` (ホスト停止)
特徴: 非同期で割り込み駆動型のプログラムと互換性があります。
送信とブロードキャスト:
形式: `<TRN> <Body>`（単一プロセスへのメッセージ送信）、 `<BDC> <Body>`（全受信接続へのブロードキャスト）
機能: ユーザープログラムに割り当てられたリンクを通じてメッセージを送信。
影響
このRFCは、ネットワークプロトコルの複雑さと応答時間の問題に対する改善提案を提供し、ネットワーク制御プログラムのデバッグやエラー処理をより効率的に行うための基盤を提供しました。
詳細は、RFC 39を参照してください。
RFC 40: More Comments on the Forthcoming Protocol
概要
タイトル: More Comments on the Forthcoming Protocol
著者: E. Harslem, J. Heafner
発行日: 1970年3月
内容: RFC 40は、以前に発行されたRFC 36およびRFC 39に対する追加のコメントと改善提案をまとめたものです。主に、エラーメッセージ、クエリ、およびホストステータスに関する詳細な説明が含まれています。
主な内容
エラーメッセージ:
形式: `<ERR> <Code> <Command length> <Command in error>`
コードフィールド: 8ビットフィールドで、エラータイプを指定します。
例:
`00`: 未指定のエラー
`01`: 無効なリソースの要求
`02`: リソースが枯渇しているため、後で再試行
`20`: 不明なコマンドコード
`21`: 接続されていないリンクでメッセージを受信
クエリ:
形式: `<QRY> <My Socket>` または `<RPY> <Your Socket> <Text>`
機能: リモートNCP（Network Control Program）に接続状態を問い合わせるためのコマンド。
ホストステータス:
メッセージ: `<NOP>`
機能: NCPが起動状態、停止状態、または保留中であることを示します。NCPが起動状態に変更された場合、各リモートNCPに`<NOP>`メッセージを送信し、NCPの利用可能性を通知します。
影響
このRFCは、ネットワークプロトコルのエラー処理、クエリ、およびホストステータスの管理を改善するための基盤を提供し、ネットワークの信頼性と効率を向上させました。
詳細については、RFC 40を参照してください。
RFC 41: IMP-IMP Teletype Communication
概要
タイトル: IMP-IMP Teletype Communication
著者: John Melvin
発行日: 1970年3月30日
内容: RFC 41は、IMP（Interface Message Processor）同士のテレタイプ通信に関する提案をまとめたものです。特に、送信されたメッセージのタイムスタンプとタイムゾーンの情報を付加することを提案しています。
主な内容
メッセージのタイムスタンプ:
送信されたメッセージには、送信時間とタイムゾーンの情報を含めることが推奨されています。これにより、受信者はメッセージの送信時刻を正確に把握でき、迅速な対応が求められるかどうかを判断できます。
タイムゾーンの考慮:
アメリカ全土に広がるサイト間での通信を考慮し、各メッセージにタイムゾーン情報を付加することが重要であると述べられています。これにより、異なるタイムゾーン間でのコミュニケーションが円滑に行われます。
改善提案:
すべてのIMPサイトが、応答を必要としないメッセージにもタイムスタンプを付けるように推奨しています。
影響
このRFCは、ネットワークのメッセージ通信における時間管理の重要性を強調し、メッセージのタイムスタンプとタイムゾーン情報を標準化することによって、通信の効率と信頼性を向上させました。
詳細については、以下のリンクから全文を参照してください：
RFC 42: Message Data Types
概要
RFC 42は、ネットワーク上で交換されるメッセージのデータタイプについて提案しています。この提案は、メッセージの先頭8ビットをデータタイプとして予約することを目的としています。この規約により、送信者と受信者がメッセージの内容を解釈するための共通の基盤を提供します。
主な内容
標準タイプとローカルタイプの区別:
標準タイプ: ネットワーク全体で共通に使用されるメッセージタイプ。例えば、U.S. ASCIIやEBCDICなど。
ローカルタイプ: 送信ホストまたは受信ホスト固有のメッセージタイプ。例えば、特定のキャラクタセットやグラフィックスメッセージ。
標準タイプの例:
YOURLOCAL
MYLOCAL
U.S. ASCII
EBCDIC
Mod 33 TTY ASCII
ローカルタイプの例:
ローカルキャラクタセット（例：DEC ASCIIなど）
グラフィックスローカルメッセージ（例：TX-2 Apexディスプレイコール）
実装の提案:
標準タイプ0をYOURLOCAL、標準タイプ1をMYLOCALとし、2バイト目にローカルタイプ番号を格納する。
影響
このRFCは、メッセージのデータタイプを標準化することにより、ネットワーク上のデータ交換を効率化し、メッセージの解釈を容易にするための基盤を提供しました。これにより、異なるシステム間での相互運用性が向上しました。
参照
詳細については、以下のリンクから全文を参照してください：
RFC 43: Proposed Meeting
概要
タイトル: Proposed Meeting
著者: A. G. Nemeth
発行日: 1970年4月8日
内容: RFC 43は、1970年5月8日にM.I.T.リンカーン研究所で開催される予定の会議に関する提案を記述しています。この会議では、TSP（Terminal Support Processor）システムのためのLIL（Local Interaction Language）の説明が行われる予定です。
主な内容
会議の日時と場所:
日時: 1970年5月8日 午前9:30
場所: M.I.T.リンカーン研究所
LIL（Local Interaction Language）:
TSPシステムに柔軟なI/O機能を提供するためのユーザープログラマブルなインタープリタブル言語。
インタラクティブグラフィックス用のツリーストラクチャの操作やメッセージ指向のI/Oに適したプリミティブを備えています。
一般的な用途の部分はI/Oハンドラとディスプレイ構造を指定するために使用されます。
議題:
ARPAネットワーク上でインタラクティブプログラムを扱う際の問題についてのディスカッション。
参加方法:
会議に参加したい、または関連文書を受け取りたい人は、M.I.T.リンカーン研究所のA. G. NemethまたはJ. Forgieに連絡するよう指示されています。
影響
RFC 43は、ネットワーク技術者間の交流と情報共有を促進するための重要な会議を提案し、新しいシステムとプロトコルの開発に寄与しました。このような会議は、ネットワーク技術の発展における重要なステップとなりました。
詳細については、以下のリンクを参照してください：
RFC 44: Comments on NWG/RFC 33 and 36
概要
タイトル: Comments on NWG/RFC 33 and 36
著者: A. Shoshani, R. Long, A. Landsberg
発行日: 1970年4月10日
内容: RFC 44は、以前に発行されたRFC 33およびRFC 36に対するコメントと提案をまとめたものです。この文書では、ホスト間プロトコルの改善点について具体的な提案がされています。
主な内容
再接続のケースの分離:
ケース1: ローカルホスト内のソケット間の再接続（例：ログインプロセスが新しいプロセスに接続を切り替える）。
ケース2: ローカルホストからリモートホストへのソケット間の再接続。
提案: ケース1とケース2を分離し、ケース2は初期プロトコルから除外する。
CLOSEコマンドの明確化:
BLOCKコマンドとCLOSEコマンドを分け、BLOCKは接続をブロックし、CLOSEは接続を終了する。
SUSPENDコマンドでこれらの操作を確認する。
外部ソケットの管理:
接続が確立された後、ローカル接続テーブルに外部ソケットを保持する必要はない。リンク番号を使用してコマンドを管理する。
PORTの使用:
PORTは各ホストに固有であり、ソケットとの1対1の対応がある場合、冗長となる。
その他の議論点:
メッセージがワード境界で終了しない場合の「ダブルパディング」の問題。
エコーの有無、オプションエコーの選択。
コード変換の方法。
影響
RFC 44は、ホスト間の通信プロトコルをより効率的かつ明確にするための具体的な提案を提供し、ネットワークの信頼性と操作性を向上させました。この文書は、後のプロトコル開発における重要な指針となりました。
詳細については、以下のリンクから全文を参照してください：
RFC 45: New Protocol is Coming
概要
タイトル: New Protocol is Coming
著者: J. Postel, S. Crocker
発行日: 1970年4月14日
内容: RFC 45は、新しいネットワークプロトコルの準備状況について報告しています。このプロトコルは、即時実装が可能な形での提供を目指しています。
主な内容
新しいプロトコルの準備:
新しいネットワークプロトコルのクリーンバージョンを準備しており、4月28日に仕様を送信する予定です。
会議の開催:
1970年5月7日にアトランティックシティで会議を開催する予定。この会議では、新しいプロトコルの仕様についての詳細説明と意見交換が行われる予定です。
議論の目的:
4月29日に発行されるドキュメントの不明点を明らかにし、提案やスケジュールについて議論します。
SJCCセッション:
会議の1週間後にSJCC（Spring Joint Computer Conference）が予定されており、そこではBBNなどのプレゼンテーションが行われます。
影響
このRFCは、新しいプロトコルの導入とそれに伴う詳細な議論を促進し、ネットワーク技術の発展に重要な役割を果たしました。特に、プロトコルの仕様と実装に関する具体的なステップを提供することで、関係者間の協力と理解を深めました。
詳細については、以下のリンクから全文を参照してください：
RFC 46: ARPA Network Protocol Notes
概要
タイトル: ARPA Network Protocol Notes
著者: Edwin E. Meyer, Jr.
発行日: 1970年4月17日
内容: RFC 46は、ARPAネットワークプロトコルに関するメモであり、特にNWG（Network Working Group）によって提案されたRFC 33、36に基づく改善提案をまとめたものです。
主な内容
複数経路通信:
既存のプロセス間での複数経路通信を提供する必要性について説明されています。
ログインプロセス:
異なるホストでのログインプロセスを標準化する方法が提案されています。これには、ログインプロセスの開始方法やユーザープロセスの作成リクエストの標準化が含まれます。
擬似タイプライター通信:
新しく作成されたプロセスが、通信を開始するための擬似タイプライター通信を提案しています。
プロトコルの主要な違い:
ダイナミック再接続戦略の将来的な実装に関する議論。
ソケット識別子に「インスタンスタグ」を追加する提案。
NCP（Network Control Program）コマンドの追加（ERR、BLK、RSM、INT、ECO）。
プロトコル階層:
プロトコルを階層的に見ることで、独立したソフトウェアとハードウェアの開発が容易になることを提案しています。
NCPの役割:
各ホストには、ネットワーク通信を制御するNCPモジュールが存在し、ソケット間の通信パスの定義と維持を行います。
影響
このRFCは、ARPAネットワークの初期設計における重要なステップであり、プロトコルの効率化と標準化に寄与しました。特に、プロセス間通信の管理とエラー処理の改善において重要な役割を果たしました。
詳細については、以下のリンクから全文を参照してください：
RFC 47: BBN's Comments on NWG/RFC #33
概要
タイトル: BBN's Comments on NWG/RFC #33
著者: J. Postel, S. Crocker
発行日: 1970年4月20日
内容: RFC 47は、BBN（Bolt, Beranek and Newman Inc.）によるRFC 33に対するコメントをまとめたもので、IMP（Interface Message Processor）の通信特性に関する誤解を指摘しています。
主な内容
IMPのバッファリング:
IMPはメッセージをバッファリングするが、その目的はエラー制御と瞬間的なトラフィックの急増に対応するためである。
メッセージは挿入後即座に出力されると考えるべきであり、長時間バッファに留まるわけではない。
複数リンクの使用:
RFC 33で述べられている「複数リンクを使用しない」という前提は誤りである。実際には、複数リンクを使用することで広帯域を実現することが目的である。
ユーザーメッセージのランダム性:
単一メッセージユーザーに対しては、メッセージがランダムであれば問題はない。問題は非ランダムな連続メッセージ送信にあり、これに対する特別な対策が必要である。
ホストのメッセージ受信:
ホストが複数の待機中メッセージから受け入れるメッセージを指定できる設計は、IMPのバッファリング能力を超えている。IMPのバッファは空でなければならない。
影響
このRFCは、ネットワークのバッファリングとメッセージ処理に関する理解を深め、効率的な通信プロトコルの設計に貢献しました。また、複数リンクの使用やバッファ管理に関する重要な洞察を提供しました。
詳細は以下のリンクから確認できます：
RFC 47 - BBN's Comments on NWG/RFC #33 (RFC Editor)
[RFC 47 - BBN's Comments on NWG/RFC #33 (IETF Datatracker)](https://datatracker.ietf.org/doc/rfc47
RFC 48: A Possible Protocol Plateau
概要
タイトル: A Possible Protocol Plateau
著者: J. Postel, S. Crocker
発行日: 1970年4月
内容: RFC 48は、ネットワークプロトコルの進化とそれに伴う課題についての考察を提供しています。特に、動的再接続（dynamic reconnection）やエラーレポート、ステータステストの重要性について詳述しています。
主な内容
動的再接続:
プロトコルに動的再接続のメカニズムを含めることの必要性と、その実装方法についての議論。
ユーザーが同じ接続で他のソケットに切り替えることができる仕組み。
通信開始後のデータフローを失わずに接続を切り替えるためのアルゴリズムを提案。
接続とリンクの分離:
リンクが特定の接続に割り当てられないようにする提案。
メッセージのテキスト部分に宛先ソケットを含めることで、未ブロックのリンクを使用してメッセージを送信する方法。
エラーレポート:
エラー処理の重要性とエラーコマンドの利用に関する議論。
リソースエラーとその他のエラーの区別が推奨されている。
エラーメッセージの生成をオプションにし、すべてのエラーを時系列ファイルにローカルで記録することが推奨されています。
ステータステストとレポート:
デバッグ支援のためのステータスメッセージの重要性。
ステータス要求を受け取った場合に常にステータスメッセージを送信するメカニズムの提案。
影響
RFC 48は、ネットワークプロトコルの改善と信頼性向上に寄与する具体的な提案を提供しました。動的再接続の導入やエラー処理の標準化は、ネットワークの柔軟性と効率を大幅に向上させました。
詳細については、以下のリンクを参照してください：
RFC 49: Conversations with S. Crocker (UCLA)
概要
タイトル: Conversations with S. Crocker (UCLA)
著者: Edwin W. Meyer, Jr.
発行日: 1970年4月25日
内容: RFC 49は、MITプロジェクトMACのEdwin W. Meyer, Jr.がUCLAのSteve Crockerとのネットワークプロトコルに関する電話会談を記録したものです。この文書は、動的再接続、INTコマンド、ソケット識別子のインスタンスタグ、NCPレベルでのデータ構造、ユーザー制御および通信（UCC）プロトコルなどの議論を含んでいます。
主な内容
動的再接続:
Steve Crockerは、将来的にネットワーク参加者が動的再接続の必要性を認識するだろうと述べていますが、コンセンサスの欠如から初期実装には含めないことが決定されました。
INTコマンド:
NWG/RFC 46で提案されたINTネットワークコマンドの実装が支持されました。このコマンドは、ソケット接続を介してプロセスが他のプロセスを中断させることを可能にし、"quit"シグナルを実装するためのものです。シグナルの処理はNCPではなく、上位プロトコルで行われるべきとされています。
ソケット識別子におけるインスタンスタグ:
Crockerは、ソケット識別子にインスタンスタグを含めることに反対しました。彼の主張は、単一ユーザーの複数プロセスは外部プロセスから区別できないべきであり、必要なら後で追加することは困難だが可能であるというものでした。
NCPレベルでのデータ構造:
データ送信においてNCPレベルで特別な構造を強制しないことに合意しました。これにより、プロトコルの合意が遅れず、将来的な変更に柔軟に対応できるようになります。
ユーザー制御および通信 (UCC) プロトコル:
UCCプロトコルの戦略について様々な提案が議論されました。Crockerは、既存のソケットとロガープロセスを使用するユーザープロセス作成の別の方法を提案しました。
影響
RFC 49は、ネットワークプロトコルの設計と実装における重要な議論を記録しており、特に動的再接続やINTコマンドの実装方法、データ構造の設計に関する貴重な洞察を提供しています。
詳細については、RFC 49の全文をこちらでご確認ください
RFC 50 "Comments on the Meyer Proposal"
概要:
RFC 50は "Comments on the Meyer Proposal" というタイトルで、1970年4月30日にSteve Crockerによって書かれました。この文書は、Ed Meyerが提案したARPANETのホスト間通信プロトコルに対するコメントと分析を含んでいます。
主な内容:
Meyerの提案に対する詳細な分析
プロトコルの設計における効率性と信頼性の議論
提案されたプロトコルの利点と欠点の検討
ホスト間通信の改善に関する提案
プロトコル設計における複雑さと単純さのトレードオフに関する考察
影響:
初期のARPANETプロトコル開発に重要な貢献をしました
後のTCP/IPプロトコルスイートの開発に影響を与えました
ネットワークプロトコル設計における重要な考え方を提示しました
オープンな議論と批評の文化を促進し、RFCプロセスの重要性を示しました
参照:
関連するRFC: RFC 33, RFC 36, RFC 39 (Meyerの元の提案)
ARPANET Historical Documentation: SRI International
RFC 51: ネットワーク間交換言語の提案
概要:
"Proposal for a Network Interchange Language" というタイトルで、1970年5月4日にMichael Padlipskyによって発行されました。この文書は、異なるコンピュータシステム間でデータを交換するための共通言語を提案しています。主な内容:
a) ネットワーク間交換言語の必要性の説明
b) 提案された言語の基本構造と設計原則
c) 言語の具体的な構文と使用例
d) この言語が解決しようとする問題点の詳細提案の特徴:
a) 単純性: 容易に理解・実装できる設計
b) 拡張性: 将来の需要に対応できる柔軟性
c) 効率性: ネットワークリソースの効率的な利用影響と意義:
a) 初期のネットワーク標準化の試みとしての重要性
b) 後のデータ交換形式（XML、JSONなど）の概念的先駆け
c) システム間の相互運用性問題に対する早期の認識歴史的コンテキスト:
ARPANETの発展初期段階における重要な提案の一つとして位置づけられます。
RFC 52 "Updated Distribution List"
概要:
RFC 52は "Updated Distribution List" というタイトルで、1970年7月1日にS. Crocker によって発行されました。この文書は、主にRFCの配布リストの更新に関するものです。主な内容:
a) RFCの配布リストの更新情報
b) 新しく追加された連絡先や組織
c) リストから削除された連絡先や組織（もしあれば）
d) 連絡先情報の変更（住所、所属など）目的:
a) RFCの配布システムを最新の状態に保つこと
b) 新しい参加者や関心のある組織にRFCが確実に届くようにすること
c) ネットワーク研究コミュニティ内のコミュニケーションを改善すること重要性:
a) 初期のインターネット開発における情報共有の仕組みを示している
b) ネットワーク研究コミュニティの拡大を反映している
c) オープンな標準化プロセスの一部として機能している歴史的コンテキスト:
この時期は、ARPANETの発展初期段階であり、参加者や関心を持つ組織が徐々に増加していた時期です。RFC 52は、この成長と変化を管理するための重要な文書でした。
このRFCは、技術的な内容というよりも、初期のインターネット開発における管理と組織の側面を示す文書です。当時のネットワーク研究コミュニティの規模や構成を知る上で貴重な資料となっています。
RFC 53: OFFICIAL PROTOCOL MECHANISM AND PROCEDURES
概要:
RFC 53は1970年6月9日にS. Crocker によって発行されました。この文書は、ARPANETにおける公式プロトコルの確立とその手続きに関する提案を含んでいます。主な内容:
a) 公式プロトコルの定義と重要性の説明
b) プロトコル確立のための手続きの提案
c) プロトコル委員会（Protocol Committee）の設立提案
d) プロトコルの文書化と公開プロセスの説明提案されたプロセス:
a) プロトコル案の提出
b) プロトコル委員会による審査
c) 実装とテスト
d) 最終的な承認と公式化プロトコル委員会の役割:
a) 提案されたプロトコルの技術的評価
b) プロトコルの一貫性と互換性の確保
c) 最終的な承認の決定文書化と公開:
a) 承認されたプロトコルの詳細な文書化
b) RFCシステムを通じた公開重要性と影響:
a) ネットワークプロトコルの標準化プロセスの基礎を確立
b) オープンで透明性のある標準化プロセスの促進
c) 後のインターネット標準化プロセスの先駆け
このRFCは、初期のインターネット開発における重要な組織的側面を示しており、現代のインターネット標準化プロセスの起源を理解する上で重要な文書です。
RFC 54 "An Official Protocol Proffering"
概要:
RFC 54は "An Official Protocol Proffering" というタイトルで、1970年6月18日にSteve Crocker によって発行されました。この文書は、ARPANETのホスト間通信のための公式プロトコルを提案しています。主な内容:
a) ホスト-IMPプロトコル（Host-IMP Protocol）の詳細
b) ホスト-ホストプロトコル（Host-Host Protocol）の提案
c) 初期接続プロトコル（Initial Connection Protocol, ICP）の説明
d) TELNETプロトコルの概要プロトコルの特徴:
a) リンクの確立と維持の方法
b) データ転送の仕組み
c) フロー制御とエラー制御のメカニズム
d) 異なるタイプの接続の扱い方提案の目的:
a) ネットワーク上のホスト間の効率的な通信の実現
b) 異なるシステム間の互換性の確保
c) ネットワークリソースの効率的な利用重要性と影響:
a) ARPANETの基本的な通信プロトコルの標準化
b) 後のTCP/IPプロトコルスイートの開発に影響
c) 現代のインターネットプロトコルの基礎となる概念の提示歴史的コンテキスト:
この文書は、ARPANETの初期段階における重要な技術的提案の一つです。ネットワーク通信の基本的な枠組みを定義し、後のインターネット開発に大きな影響を与えました。
RFC 55 "Prototypical Implementation of the NCP"
概要:
RFC 55は "Prototypical Implementation of the NCP" というタイトルで、1970年6月19日にJohn Melvinと Richard Watsonによって発行されました。この文書は、Network Control Program (NCP)の試験的な実装について説明しています。主な内容:
a) NCPの基本構造と機能の説明
b) 実装の詳細とアプローチ
c) ホスト-IMPインターフェースの扱い方
d) 接続の確立と維持の方法
e) データ転送とフロー制御のメカニズム実装の特徴:
a) モジュール構造の採用
b) 割り込み処理の使用
c) バッファ管理の方法
d) エラー処理とリカバリーの仕組み目的:
a) NCPの実用的な実装モデルの提供
b) 他のホストでのNCP実装の促進
c) プロトコルの実装に関する問題点の特定と解決重要性と影響:
a) ARPANETにおけるホスト間通信の標準化への貢献
b) 後のTCP/IP実装への影響
c) ネットワークソフトウェア開発の実践的アプローチの例示技術的詳細:
文書には、データ構造、プログラムフロー、インターフェース仕様などの技術的な詳細が含まれています。これらは、当時のコンピュータシステムとネットワーク技術の状態を反映しています。歴史的コンテキスト:
この文書は、ARPANETの初期段階における重要な技術的成果の一つです。NCPは後のTCP/IPプロトコルスイートの前身となるプロトコルであり、この実装は初期のインターネット開発における重要なステップでした。
RFC 55: Prototypical Implementation of NCP
概要
タイトル: Prototypical Implementation of NCP
著者: J. Newkirk, M. Kraley, J. Postel, S.D. Crocker
発行日: 1970年6月
内容: RFC 55は、ネットワークコントロールプログラム（NCP）の基本的な実装方法について記述しています。具体的には、NCPの構成要素、各プログラムの役割、データの処理方法、エラーハンドリングなどを詳細に説明しています。
主な内容
NCPの基本構造:
NCPは、5つのコンポーネントプログラム、複数のアソシエイティブテーブル、およびいくつかのキューとバッファで構成されます。
コンポーネントプログラム:
入力ハンドラー: 割り込み駆動のルーチンで、IMPからホストへのデータの受信を開始し、完了時に入力インタープリターを起動します。
出力ハンドラー: 割り込み駆動のルーチンで、ホストからIMPへのデータの送信を開始し、完了時に出力スケジューラーを起動します。
入力インタープリター: 受信したメッセージがユーザーメッセージ、ネットワーク制御メッセージ、IMPからのメッセージ、エラーメッセージのどれであるかを判断し、適切なサブルーチンを呼び出します。
出力スケジューラー: メッセージの優先順位を設定し、最も高い優先順位のメッセージを選択して出力ハンドラーに渡します。
システムコールインタープリター: ユーザーからのリクエストを解釈し、各システムコールに対応するルーチンを呼び出します。
アソシエイティブテーブル:
ランデブーテーブル: 接続の属性を保持し、接続が確立された後に使用されるフィールドを含みます。
入力リンクテーブル: 外部ホストおよびリンクの連結をキーとして使用し、ランデブーテーブルへのポインタを提供します。
出力リンクテーブル: 出力リンクの状態を管理し、ランデブーテーブルへのポインタを提供します。
ポートテーブル: プロセスIDとポートIDをキーとして使用し、ランデブーテーブルへのポインタを提供します。
エラーハンドリングと状態管理:
接続の状態をモニタリングするためのメカニズムが提供されており、接続が確立されているか、エラーが発生しているかなどの情報を管理します。
影響
RFC 55は、NCPの実装における基本的な設計と機能を明確にし、ネットワーク通信の標準化と効率化に貢献しました。このドキュメントは、初期のインターネットプロトコルの発展における重要なステップを示しています。
詳細については、RFC 55の全文をこちらでご確認ください。
RFC 56: Third Level Protocol: Logger Protocol
概要
タイトル: Third Level Protocol: Logger Protocol
著者: E. Belove, D. Black, R. Flegal, L.G. Farquar
発行日: 1970年6月
内容: RFC 56は、ネットワーク上の異なるホスト間での通信を管理するための「Logger Protocol」の詳細を説明しています。このプロトコルは、ユーザーのテレタイプが外国のモニタと通信するための手続きを標準化するものです。
主な内容
受信ロガーと送信ロガー:
受信ロガー: 各ホストでユーザー0として動作し、ソケット0で常にリッスンしています。外国のホストから接続要求を受け入れ、リソースが利用可能な場合は接続を確立します。
送信ロガー: 使用されていないソケットペア（2Nと2N+1）をプールから引き出し、外国ホストのユーザー0、ソケット0に接続を試みます。
接続の確立手順:
送信ロガーが接続を試み、受信ロガーが受け入れると、使用可能なソケットペア（2Mと2M+1）を選択して接続を確立します。これにより、両方のロガー間でフルデュプレックス接続が確立され、ユーザーと外国のモニタ間の通信を管理します。
標準文字コード:
ネットワークでの通信を容易にするため、全てのテレタイプ-外国モニタ間の通信は128文字のUSASCIIを使用することが提案されています。これにより、異なる内部文字コードを持つマシン間の通信が簡素化されます。
ブレークキャラクタ:
ブレークキャラクタ（緊急停止ボタン）の標準的な取り扱い方法を定義します。このキャラクタは、プログラムの中断やシステムレベルへの即時の脱出を実行するために使用されます。
影響
RFC 56は、ネットワーク上での標準化された通信プロトコルの設計に貢献し、異なるホスト間の効率的な通信を可能にしました。特に、テレタイプから外国モニタへの通信を標準化し、エラーハンドリングやリソース管理を改善しました。
詳細については、RFC 56の全文をこちらでご確認ください。
RFC 57: Thoughts and Reflections on NWG/RFC 54
概要
タイトル: Thoughts and Reflections on NWG/RFC 54
著者: Mike Kraley (Harvard), John Newkirk (Harvard)
発行日: 1970年6月19日
内容: RFC 57は、RFC 54に関連する考察や追加のアイデアを述べたもので、ネットワークプロトコルの改良についての提案を含んでいます。特にエラーハンドリングとホストのクラッシュ時の処理について議論しています。
主な内容
エラーとオーバーフロー:
エラーには「実際のエラー」と「オーバーフロー条件」の2種類があるとしています。
実際のエラー: ソフトウェアやハードウェアのバグによって引き起こされるエラー。
オーバーフロー条件: システムリソースの不足やネットワークの混雑によって発生する問題。
RFC 54ではオーバーフロー条件が実際のエラーと同様に扱われていましたが、これが誤解を招く可能性があるため、オーバーフロー条件を区別する新しい制御コマンド「OVF」を提案しています。
ホストのクラッシュと再起動:
ホストがクラッシュし再起動する際の問題点を2つのケースに分けて議論しています。
ソフトクラッシュ: 予告があり、適切な事前処理が可能な場合。
ハードクラッシュ: 突然のシステム障害で、再起動後の状態が予測不可能な場合。
クラッシュ後のネットワーク再同期のために、制御コマンド「RESET (RST)」と「RESET REPLY (RSR)」の導入を提案しています。RSTは全ての接続を終了させ、RSRはホストが再起動していることを通知します。
影響
RFC 57は、エラーハンドリングとネットワークの安定性向上に寄与する重要な提案を含んでいます。特に、エラーの区別とホストクラッシュ後の再同期の方法は、ネットワークの信頼性を高めるために重要です。
詳細については、RFC 57の全文をこちらでご確認ください。
RFC 58: Logical Message Synchronization
概要
タイトル: Logical Message Synchronization
著者: T.P. Skinner
発行日: 1970年6月
内容: RFC 58は、論理メッセージと物理メッセージの同期に関する問題を取り上げています。ネットワーク上でのメッセージの同期と、論理メッセージの境界をどう管理するかについての議論を含んでいます。
主な内容
論理メッセージと物理メッセージの区別:
論理メッセージと物理メッセージを一緒にしないという提案がありました。論理メッセージは物理メッセージの境界で開始するべきだとする考えです。
同期の問題:
論理メッセージの終わりを特定するためにビットカウントやデータタイプ指定を使用する方法が議論されました。
ネットワークを無限のビットストリームとして捉え、物理的な区切りがない状態での同期の問題を取り上げています。
エラーの影響:
ビットが落ちるなどのエラーが発生した場合、同期を取るための方法が必要です。提案された解決策の一つは、エラーメッセージを送信して待機し、次のビットが論理メッセージの始まりであることを確認する方法です。
物理的境界での開始:
論理メッセージを物理的なメッセージの境界で開始するという制限を再検討し、より安全で効率的な方法として提案しています。
影響
RFC 58は、ネットワーク上でのメッセージ同期の問題を解決するための基本的な考え方を提供しています。特に、論理メッセージと物理メッセージの区別とその同期の問題を明確にし、効率的な通信を可能にするための基盤を築きました。
RFC 59: Flow Control - Fixed Versus Demand Allocation
概要
タイトル: Flow Control - Fixed Versus Demand Allocation
著者: E. Meyer
発行日: 1970年6月
内容: RFC 59では、ネットワーク上のフロー制御の方法について、「固定割り当て」と「要求ベースの割り当て」の比較を行っています。固定割り当て方式の欠点と、要求ベースの割り当て方式の利点について詳述しています。
主な内容
固定割り当ての欠点:
リソースの慢性的な未利用:
固定割り当てでは、バッファスペースがほとんど使用されず、無駄になりやすいと指摘しています。例えば、低ボリュームの接続に多くのバッファを割り当てると、そのスペースがほとんど利用されないことがあります。帯域幅の制限:
高ボリューム通信では、適切なバッファ割り当てが行われないと通信速度が低下します。データ送信はバッファの割り当て限界まで行われ、受信プロセスがデータを処理するまで新しいデータの送信が停止します。高いオーバーヘッド:
固定割り当て方式では、すべての接続に対して常に新しい割り当てを送信する必要があり、オーバーヘッドが増加します。負荷が増加した場合の柔軟性の欠如:
固定割り当て方式では、ネットワークの負荷が増加した場合に割り当てを柔軟に調整することが難しいとされています。例えば、低ボリュームの接続に対して割り当てられたスペースを再利用することが困難です。
要求ベースの割り当ての利点:
リソースの効率的な利用:
必要に応じて割り当てを行うため、リソースの無駄が減少し、帯域幅の利用が最適化されます。フロー制御の柔軟性:
フロー制御の制限は必要な時だけに適用され、通常のフローには影響を与えません。負荷が増加した場合の対応:
要求ベースの割り当て方式では、ネットワークの負荷が増加した場合にも柔軟に対応できます。NCP（Network Control Program）のバッファが完全に埋まる前にリンク上のフローを停止することで、過負荷状態を回避します。
影響
RFC 59は、ネットワーク上のフロー制御を効率化し、リソースの利用を最適化するための重要な考察を提供しています。特に、要求ベースの割り当て方式が固定割り当て方式に比べて柔軟で効率的であることを強調しています。
詳細については、RFC 59の全文をこちらでご確認ください。
RFC 60: A Simplified NCP Protocol
概要
タイトル: A Simplified NCP Protocol
著者: R. Kalin
発行日: 1970年7月13日
内容: RFC 60は、ネットワークコントロールプログラム（NCP）の簡素化されたプロトコルを提案しています。このプロトコルは、ネットワーク間の通信を効率化し、バッファ管理とメッセージ同期を改善するための手法を説明しています。
主な内容
接続確立とバッファ割り当て:
接続確立: 接続は、ソケット識別子を使用して確立されます。リモートホストは、ソケット識別子を比較し、一致するリスン（listen）が見つかった場合にACKメッセージを送信します。
バッファ割り当て: メッセージバッファは、接続が確立されたときに両端で割り当てられます。各バッファの状態は「空」として初期化されます。
メッセージ処理:
GETMESSAGE: 次のメッセージを取得します。
PUTMESSAGE: メッセージを送信キューに入れます。
メッセージの整列: メッセージの整列はユーザーに任されています。NCPは、メッセージの整列に関する操作を行わず、ユーザーが必要に応じて調整します。
リンクの削除とクローズ:
リンクの削除: 空のクレートを削除し、対応するバッファを解放します。DECメッセージが送信され、バッファ削減が確認されます。
NOMOREOUTPUT: ユーザープロセスがもうメッセージを送信しないことを宣言し、NCPは空のクレートを削除します。
ABEND: リンクを強制的に閉じるためのメッセージです。受信側のNCPはすべてのバッファを解放し、リンクをクローズします。
拡張とエラーハンドリング:
拡張の検出: INQメッセージを使用してリモートホストの拡張を検出します。応答が未定義のエラーメッセージである場合、リモートホストには最小限のNCPしか実装されていないと判断されます。
ユーザーRFNMの置換: 特別なメッセージを使用して、ユーザーRFNMを制御リンク上で送信します。これにより、ネットワークのスループットが向上します。
影響
RFC 60は、NCPプロトコルの簡素化と効率化を目的としており、ネットワーク通信の管理とバッファ管理の方法を改善します。このプロトコルにより、メッセージ同期の問題が解決され、ネットワークのスループットと信頼性が向上します。
詳細については、RFC 60の全文をこちらでご確認ください。
RFC 61: A Note on Interprocess Communication in a Resource Sharing Computer Network
概要
タイトル: A Note on Interprocess Communication in a Resource Sharing Computer Network
著者: Dave Walden
発行日: 1970年7月17日
内容: RFC 61は、リソース共有型コンピュータネットワークにおけるプロセス間通信（IPC）についての考察を提供しています。特に、ネットワーク上でのプログラム呼び出しとデータ転送の標準化を目指しています。
主な内容
モデルタイムシェアリングシステム:
モニタとプロセス:
モニタは、プロセス間の制御の切り替え、コアとスワッピングメディアの管理、プロセスの作成、スリーププロセスの管理などの機能を持っています。
プロセスは、ディスクハンドラやファイルシステムなどのシステムプロセスと、通常のユーザープロセスに分かれています。
IPC操作:
開始・停止:
プロセスはモニタに対して、新しいプロセスの開始や現在のプロセスの停止を要求できます。
メッセージ送受信:
プロセスは、特定のプロセスへのメッセージ送信、任意のプロセスからのメッセージ受信、ユニークな番号の取得などを要求できます。
ネットワーク通信の一般化:
分散プロセス:
各ポイントに自律的なタイムシェアリングシステムが存在し、中央の「ネットワークコントローラ」がそれらを調整する形でプロセス間通信を行います。
ネットワークコントローラは、SEND、RECEIVE、SEND FROM ANY、RECEIVE ANY、UNIQUEなどの操作を実行し、すべてのモニタがこれらの操作をネットワークコントローラに依頼することで、リモートプロセス間の通信問題を解決します。
フォートランコンパイラのデモ:
プロセスのやり取り:
ユーザーがテレタイプで実行中のエグゼクティブプロセスが、フォートランコンパイラを起動し、必要な入出力ファイルの情報をやり取りする例を示しています。
影響
RFC 61は、プロセス間通信の標準化に関する初期の考え方を提示し、その後のネットワークプロトコルの発展に影響を与えました。特に、プロセス間のメッセージ送受信の方法や、ネットワーク全体で一意の番号を割り当てる仕組みが重要です。
詳細については、RFC 61の全文をこちらでご確認ください。
RFC 62: Systems for Interprocess Communication in a Resource Sharing Computer Network
概要
タイトル: Systems for Interprocess Communication in a Resource Sharing Computer Network
著者: D.C. Walden
発行日: 1970年8月3日
内容: RFC 62は、リソース共有型コンピュータネットワークにおけるプロセス間通信（IPC）についての詳細なプロトコルを説明しています。特に、メッセージの送受信の管理方法、ポート番号の利用、タイムアウト機構などについて触れています。
主な内容
プロセス間通信の基本メカニズム:
プロセスAとプロセスBが通信する場合、プロセスAはポートNからポートMへのRECEIVE操作を実行し、プロセスBはポートNからポートMへのSEND操作を実行します。モニタはポート番号を照合し、プロセスBからプロセスAへのメッセージを転送します。
メッセージが完全に転送されると、プロセスBはSEND操作で指定された位置で再開され、プロセスAはRECEIVE操作で指定された位置で再開されます。
タイムアウトとガベージコレクション:
SEND操作が実行されたが対応するRECEIVE操作が長時間実行されない場合、SEND操作はタイムアウトし、送信プロセスに通知されます。逆に、RECEIVE操作が実行されたが対応するSEND操作がない場合も同様にタイムアウトします。
RECEIVE ANY操作はタイムアウトしませんが、スーパーバイザコールを使用して取り消すことができます。
ポート番号の管理:
ポート番号はプロセス間で渡されることがあり、これによりプロセス間の通信が可能になります。ポートの転送とポート番号の転送を区別することが重要です。
プロテクトオブジェクトシステムを使用することで、ポート番号の誤使用を防ぐことができるとされています。
フロー制御:
フロー制御は、プロセスがRECEIVEを実行するまでSEND操作を開始しないシンプルな方法で提供されます。
リモートプロセス間通信:
提案されたシステムは、地理的に異なる場所にあるプロセス間の通信を可能にします。ネットワークコントローラがSEND、RECEIVE、SEND FROM ANY、RECEIVE ANY、UNIQUEの操作を実行し、これによりリモートプロセス間の通信問題を解決します。
詳細については、RFC 62の全文をこちらでご確認ください。
RFC 63: Belated Network Meeting Report
概要
タイトル: Belated Network Meeting Report
著者: Vint Cerf
発行日: 1970年7月31日
内容: RFC 63は、1970年5月8日にLincoln Labsで開催されたNetwork Working Group（NWG）ミーティングの議事録をまとめたものです。このミーティングでは、以下のトピックが議論されました。
主な内容
Lincoln Lab's Local Interaction Language (LIL):
Lincoln Labの「Local Interaction Language（LIL）」についてのプレゼンテーションと議論が行われました。この言語についての詳細は、1970年5月31日に発行されたLincoln Labの技術概要「Graphics」（ESD-TR-70-151）にまとめられています。
Records, Messages, and Format in HOST-HOST Information Exchange:
RFC 42に関連する「レコード、メッセージ、およびフォーマット」についての議論が行われました。具体的には、メッセージの前に8ビットのタイプバイトを付加し、その後に続くメッセージの形式を宣言する提案が検討されました。
以下の決定がなされました：
レコードはメッセージの任意の位置から開始できる。
レコードの最初の8ビットはタイプ情報に予約される。
接続上の最初の送信はレコードを開始する。
タイプ0は任意の長さのビット列が続くことを意味し、追加のタイプバイトは存在しない。
Miscellaneous Gripes:
その他の様々な問題点についての議論が行われました。
影響
この会議では、メッセージのデータ型システムに関する具体的な仕様が確認され、RFC 42で提案された内容の一部が改訂されました。これにより、メッセージ交換の標準化が進み、ネットワーク通信の効率が向上しました。
詳細については、RFC 63の全文をこちらでご確認ください。
RFC 64: Getting Rid of Marking
概要
タイトル: Getting Rid of Marking
著者: M. Elie
発行日: 1970年7月
内容: RFC 64では、IMP-HOSTインターフェースにおける「マーキング」を廃止する提案がなされています。マーキングは、メッセージのテキストをワード境界で開始するために導入されましたが、受信側ホストのワード長が異なる場合に問題を引き起こします。また、メッセージに不要なビットが追加されるため、効率が低下します。
主な内容
マーキングの弊害:
計算の非効率性: 受信ホストが異なるワード長を持つ場合、メッセージを変換するために全体をシフトする必要があり、計算に時間がかかる。
伝送の非効率性: 不要なビットがメッセージに追加されることで、特に1文字のメッセージの場合に効率が大幅に低下する。
提案された修正:
ホストからIMPへ: メッセージの開始時にカウンタを追加し、32ビットに達すると「ワード完了」信号を発することで、不要なビットの伝送を防ぐ。
IMPからホストへ: 32ビットのカウンタを追加し、新しいメッセージの開始時にシフトレジスタが満杯になるまでビットを入力しないようにする。
この修正により、メッセージの効率が向上し、ネットワーク全体のパフォーマンスが改善されると提案されています。
詳細については、RFC 64の全文をこちらでご確認ください。
RFC 65: Comments on Host/Host Protocol Document No. 1
概要
タイトル: Comments on Host/Host Protocol Document No. 1
著者: Dave Walden
発行日: 1970年8月29日
内容: RFC 65は、S. Crockerによる最初のホスト間プロトコル文書に対するコメントをまとめたものです。この文書では、いくつかの提案や修正点が議論されています。
主な内容
マーキングの廃止:
全ての通常メッセージを2つのメッセージに分けることを提案しています。最初のメッセージはリーダーのみを含み、次のメッセージにデータが続くようにします。これにより、データの開始位置を探す必要がなくなります。
制御メッセージの送受信:
制御メッセージは制御リンクではなく、制御ソケットを使用して送受信することを提案しています。これにより、特別なケースを排除し、処理を簡素化します。
ソケットの割り当て:
特定のネットワークリソースにソケットを永久に割り当てることを推奨し、ソケットとリソースの対応関係を示すディレクトリをネットワーク上のどこかに設けることを提案しています。
リンクの管理:
全ての宛先に対してリンクの数を制限することを提案しています。これにより、次に利用可能なリンクを選択する作業が簡素化されます。リンクは特定の宛先に一時的に使用され、受信者が使用するリンクを選択します。
エラー制御:
現在のエラー制御メカニズム（ERR）を複雑かつ不十分とみなし、プロセス間のメッセージごとに確認応答を送信するシンプルなエラー制御メカニズムを提案しています。
RFC 65は、ホスト間プロトコルの効率性と信頼性を向上させるための具体的な提案を提供しています。
詳細については、RFC 65の全文をこちらでご確認ください。
RFC 66: NIC - Third Level Ideas and Other Noise
概要
タイトル: NIC - Third Level Ideas and Other Noise
著者: Steve Crocker
発行日: 1970年8月26日
内容: RFC 66は、1970年8月12日にBBNおよびMITの代表者と行われた会議で議論された第三レベルプロトコルのアイデアとその他の議論をまとめたものです。主に、ダイヤルアッププロトコルと標準コンソールに関する内容が含まれています。
主な内容
ダイヤルアッププロトコル:
目的: あるサイトのプロセス（using site）を別のサイトのロガー（serving site）と接続するためのプロトコルです。
手順:
ユーザープロセスが受信ソケットUSを設定し、サービングホストのソケット1への接続を要求します。
サービングホストが接続を承認する場合、32ビットの偶数を送信し、接続を閉じます。これはサービングホストの受信ソケットの名前です。
その後、各ホストは追加の接続設定メッセージを交換し、ユーザーがサービングサイトのロガーに接続されます。
標準コンソール:
仕様: 初期のネットワーク標準コンソールとして、8ビットフィールド内の7ビットASCIIを使用することが合意されました。これは、BBNのIMPオペレーションマニュアル（レポート#1877）の付録Hにリストされています。
割り込みや中断: 多くのシステムは標準文字の1つを使用しますが、特別な信号が必要な場合、制御リンク経由で送信される`INR r`メッセージが使用されます。
影響
RFC 66は、第三レベルプロトコルの具体的な実装方法を示し、ネットワーク内のプロセス間通信を円滑にするための基本的なガイドラインを提供しました。また、標準コンソールの仕様を定めることで、ネットワーク内の異なるシステム間の相互運用性を向上させました。
詳細については、RFC 66の全文をこちらでご確認ください。
RFC 67: Proposed Change to Host/IMP Spec to Eliminate Marking
概要
タイトル: Proposed Change to Host/IMP Spec to Eliminate Marking
著者: W.R. Crowther
発行日: 1970年1月
内容: RFC 67は、ホスト/IMP仕様における「マーキング」問題を解決するための変更提案を示しています。この提案は、リーダー部分とメッセージ本文を分離し、それぞれを連続したメッセージとして送信することを目的としています。
主な内容
マーキングの問題点:
現行のマーキング方式では、メッセージのリーダーとデータが1つのメッセージにパックされて送信されます。これにより、異なるワード長を持つマシン間でデータの開始位置を特定するのが困難になります。
提案された変更:
リーダーとデータの分離: メッセージのリーダーをデータから分離し、連続したメッセージとして送信します。これにより、データが常にワード境界で開始されるようになります。
両方向の変更: この変更は、IMP-to-HostおよびHost-to-IMPメッセージの両方に適用されます。
変更の利点:
データの整列が簡素化され、異なるワード長を持つマシン間でのデータ転送が効率化されます。
ホストの反応は中立から非常に好意的までさまざまで、この変更に対するデメリットは見当たりません。
実装の計画:
新しいIMPプログラムのバージョンが既に開発中であり、この変更を実装するためにはホストプログラムの変更も必要です。変更を予定していることを1週間前に通知し、修正されたホスト仕様のテキストを提供する予定です。
この提案は、ホスト/IMP通信の効率を向上させるための重要な変更点を示しており、ネットワーク全体のパフォーマンスに大きな影響を与える可能性があります。
詳細については、RFC 67の全文をこちらでご確認ください。
RFC 68: Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM
概要
タイトル: Comments on Memory Allocation Control Commands: CEASE, ALL, GVB, RET, and RFNM
著者: M. Elie
発行日: 1970年8月31日
内容: RFC 68は、メモリ割り当て制御コマンド（CEASE, ALL, GVB, RET, RFNM）に関するコメントを提供し、これらのコマンドの複雑性を指摘しています。また、メッセージの転送および確認手続きの改善についての提案を含んでいます。
主な内容
バッファ割り当ての問題点:
現行のプロトコルでは、メッセージのバッファ割り当てが二重のメカニズムを必要とし、複雑です。このため、現行のRequest for Next Message (RFNM)を改訂することで、よりシンプルな方式に置き換えることを提案しています。
RFNMの改訂提案:
現行のRFNMの問題: 受信IMPからホストに最初のパケットが送信された後にRFNMが送信されますが、これではホストがメッセージ全体を受け取り、正しく受信したことが保証されません。
提案された変更: 受信ホストがメッセージを完全に受信した後にRFNMを送信するようにします。これにより、ホストがデータを正しく受信したことを確認できます。
ACKとNAK: メッセージの正しい受信を確認するために、ACK (CONTINUE) または ACK (CEASE) を使用します。また、エラー検出や再送信要求のために NAK (REPEAT) を使用します。
エラー検出と再送信:
現行のデザインでは、メッセージの一部が損なわれる可能性があり、ユーザーはエラーを検出しても修正する手段がありません。提案された変更では、NCPがエラーを検出し、再送信を要求する機能を持つようにします。
メモリ割り当ての簡素化:
ACK (CONTINUE) は新しいメッセージのためのスペースが利用可能である場合にのみ送信され、ACK (CEASE) はスペースが利用できない場合に送信されます。これにより、メモリ割り当てメカニズムが簡素化されます。
RFC 68は、ネットワーク通信の効率と信頼性を向上させるための具体的な提案を提供しています。詳細については、RFC 68の全文をこちらでご確認ください。
RFC 69: Distribution List Change for MIT
概要
タイトル: Distribution List Change for MIT
著者: A. Bhushan
発行日: 1970年9月22日
内容: RFC 69は、MITの配布リストに関する変更を記載しています。具体的には、配布リストからA. Bhushanの名前を削除し、新たにAlbert Vezzaを追加することを求めています。
主要な情報
配布リストの変更:
削除: A. Bhushan
追加: Albert Vezza
新しい連絡先情報:
名前: Mr. Albert Vezza
住所: MIT, Rm 831 - Project MAC, 545 Technology Square, Cambridge, Mass. 02139
電話番号: (617) 864-6900, 内線5877
この変更は、MITのProject MACでの連絡先情報を最新のものに更新することを目的としています。
詳細については、RFC 69の全文をこちらでご確認ください。
RFC 70: Note on Padding
概要
タイトル: Note on Padding
著者: S.D. Crocker
発行日: 1970年10月15日
内容: RFC 70は、メッセージのパディングに関する技術的な考察を示しています。パディングは、データの送信時にデータの最後に追加されるビット列のことです。この文書では、パディングの形式や効率的な処理方法について詳述しています。
主な内容
パディングの形式:
メッセージのパディングは「10...0」の形式であり、ホストのワード長が16、32、48ビットなどの場合、このパディング列は最後のワードに位置します。ワード長が16の倍数でない場合、パディングの1ビットは最後のワードか次のワードに入ります。
1ビットの位置特定:
1ビットの位置を特定するための簡単な方法として、「W AND -W」を使用して下位ビットを孤立させる手法が紹介されています。これは、1ビットを見つけるために繰り返しビットシフトを行う方法よりも効率的です。
ビット位置の決定:
孤立したビットの位置を特定するために、ビットシフトとテーブルルックアップの組み合わせが提案されています。特定の割り算子（p）を選び、各ビット位置に対応するテーブルを作成する方法です。これにより、ビットの位置を迅速に特定できます。
適切な割り算子の選択:
割り算子pは可能な限り小さい値が望ましく、pが奇数であり、適切な余りを生成するものが選ばれます。例えば、n=8の場合、p=11を使用してビット位置を特定するためのテーブルを生成します。
RFC 70は、メッセージのパディング処理を効率化するための具体的な技術を提供し、データ通信の信頼性と速度を向上させるための重要な指針を示しています。
詳細については、RFC 70の全文をこちらでご確認ください。
RFC 71: Reallocation in Case of Input Error
概要
タイトル: Reallocation in Case of Input Error
著者: Tjaart Schipper
発行日: 1970年9月25日
内容: RFC 71は、IMP（Interface Message Processor）からメッセージを読み取る際に入力エラーが発生した場合の再割り当てプロトコルについて説明しています。このプロトコルは、UCLA-CCNホストでのフロー制御を再同期するための方法を提供します。
主な内容
入力エラーの検出:
メッセージの読み取り中に入力エラーが発生し、NCP（Network Control Program）がメッセージの長さを判定できない場合、このプロトコルが適用されます。
GVBメッセージの送信:
NCPがリンク番号を特定できる場合、送信ホストに対して`frac = 0`のGVBメッセージを送信し、そのリンク上の以降のメッセージを無視します。
RETメッセージの受信:
送信ホストがRFNM（Request for Next Message）を待機していない場合、GVBメッセージを受信した時点でRETメッセージを即座に送信します。
送信ホストがRFNMを待機している場合、エラーメッセージに対応するRFNMを受信した後でRETメッセージを送信します。
新しいALLメッセージの送信:
受信ホストはリンクがクリアになったことを確認した後、新しいALLメッセージを発行します。
このプロトコルにより、入力エラーが発生した場合でもホスト間のフロー制御を再同期し、データの整合性を保つことができます。
詳細については、RFC 71の全文をこちらでご確認ください。
RFC 72: ネットワークプロトコルの変更に関する提案されたモラトリアム
概要
RFC 72は、1970年9月28日にRobert D. Bresslerによって発行されました。この文書は、既存のネットワークプロトコルの安定性を確保するために、一定期間プロトコルの変更を控えることを提案しています。モラトリアムの期間は6ヶ月間を想定しており、この間にシステムの稼働と特性の観察を行うことを目的としています。
内容
安定性の優先:
現行のプロトコルは理想的ではないかもしれませんが、全員が合意しており、実装が進んでいます。そのため、効率や実装の容易さだけを理由にした変更は控えるべきです。
実装の影響:
プロトコルの変更は、ハードウェアおよびソフトウェアの開発に大きな影響を与える可能性があります。特に、Multicsシステムのように、既に完成または高度なデバッグ段階にあるプログラムに影響を及ぼす可能性があります。
システムの早期稼働:
ネットワークの利点はその使用にあるため、早期にシステムを稼働させることが最も重要です。プロトコルの頻繁な変更はこの稼働を遅らせる可能性があります。
変更管理の制御:
大きな設計問題や必要な拡張については検討が続けられますが、詳細な変更は控えるべきです。これにより、プログラム開発の遅延を防ぐことができます。
将来的な考慮:
新しいアイデアや議論は記録され、将来的な実装を視野に入れて検討されるべきです。これにより、システムが安定した後に改良が導入されることを目指しています。
影響
このモラトリアムは、システムの特性を観察し、重大な問題が発生しない限り、少なくとも6ヶ月間継続されることが提案されました。これにより、ネットワークの早期稼働と安定性の確保が図られ、ネットワークの使用と高レベルな開発が進行することが期待されます。
詳細については、RFCの公式文書を参照してください: RFC 72
RFC 73: Response to NWG/RFC 67
概要
RFC 73は、1970年9月25日にS. Crockerによって発行されました。この文書は、NWG/RFC 67に対する応答として書かれています。主な目的は、ネットワークプロトコルの迅速な実装を奨励し、必要でない限りプロトコルの変更を遅らせることです。
内容
プロトコルの迅速な実装:
文書の冒頭で、Billの提案が良いものであると認めつつ、現時点ではドキュメント#1に記載されたプロトコルの迅速な実装を奨励する方針を示しています。Billの提案された変更は、必要に迫られない限り、遅らせるべきだと述べています。
経験から学ぶ重要性:
ネットワークの使用経験を積むことが、プロトコルの変更を行う前に最も重要であると強調しています。既にNCP（Network Control Protocol）の実装が進んでいるサイトはこの方針に賛同している一方、進捗が遅れているサイトはBillの変更を望んでいると述べています。
変更の必要性:
全般的に、プロトコルの変更は効率を改善し、柔軟性を高め、信頼性を保証するために必要であると認めています。ただし、現在は使用経験からより明確なアイデアが出てくることを期待して、変更は後回しにする方針です。
影響
このRFCは、ネットワークプロトコルの迅速な実装を奨励し、現行のプロトコルを使用しながら経験を積むことの重要性を強調しています。このアプローチにより、プロトコルの改善点が明確になり、将来的により効果的な変更が可能になると期待されています。
詳しくは公式文書を参照してください: RFC 73。
RFC 74: Specifications for Network Use of the UCSB On-Line System
概要
RFC 74は、1970年10月16日にJ.E. Whiteによって発行されました。この文書は、UCSB（カリフォルニア大学サンタバーバラ校）のオンラインシステムのネットワーク利用に関する仕様を詳述しています。このRFCは、ネットワークを通じてUCSBのシステムにアクセスするための具体的な手順と要件を示しています。
内容
ユーザー認証と接続:
ユーザーはネットワーク接続を通じてオンラインシステムにログインおよびログアウトすることができ、これらの操作はインターフェースに対して透過的に行われます。ログオフしないままネットワーク接続を終了すると、後のユーザーがすでにログインしている状態でシステムにアクセスする可能性があります。
データの受信と処理:
入力接続を通じて受信される最初のバイトは無視されます。これは、ホスト間プロトコルに従ってメッセージタイプゼロを示すものであるためです。2番目のバイトはインターフェースによって検査され、ユーザーはこのバイトを適切に選択することで、出力クラスの抑制を指定できます。
出力接続の管理:
出力接続を通じて送信されるデータは、可変長のレコードで構成されます。各レコードは出力クラス、クラス依存のフィールド、データフィールド、および全体の長さを含む2バイトのフィールドから構成されます。出力クラスにはアルファベット、曲線、および特殊文字があります。
具体的な出力クラスの仕様:
アルファベット出力クラスには、ギリシャ文字やラテン文字、特殊記号、キャリッジコントロール文字などが含まれます。これらの文字は、システム生成メッセージ、リストモード表示、キーボードアクティビティなどに使用されます。
影響
このRFCは、UCSBオンラインシステムのネットワーク利用におけるデータ処理とユーザーインターフェースの仕様を明確に定義することにより、ネットワーク接続の効率と信頼性を向上させることを目指しています。これにより、ユーザーは不要なネットワークトラフィックを避け、自身の端末で処理できるデータのみを受信することができます。この文書は、後のネットワークプロトコルの設計や実装においても重要な基礎となるものです。
詳細については公式文書を参照してください: RFC 74。
RFC 75: Network Meeting
概要
RFC 75は、1970年10月14日にS. Crockerによって発行されました。この文書は、1970年11月16日にテキサス州ヒューストンで開催されたネットワークワーキンググループ（NWG）の会議についての詳細を記しています。この会議は、FJCC（Fall Joint Computer Conference）の期間中に開催されました。
内容
会議の目的:
会議の主な目的は、ネットワークの実際の利用に関連するいくつかのトピックを議論することでした。具体的な議題は以下の通りです:
アカウンティングメカニズム（計算管理の仕組み）
ドキュメントの配布
人から人へのメッセージ送信とメッセージ保存
外国ユーザーによるシステムへのアクセス
追加トピックの提案:
参加者は他のトピックも提案することができました。この会議は、これらのトピックや関連トピックを追求するための小規模なサブ会議を開催するための基盤となることが想定されていました。
参加者への連絡:
参加予定者は、部屋の大きさを確保するためにS. Crockerの秘書であるBenita Kirstelに通知するよう求められましたが、予期しない参加者も歓迎されました。
影響
このRFCは、ネットワークの実際の利用に関する具体的な議論を促進するために開催された会議の詳細を提供しています。この会議は、NWGのメンバーがネットワーク運用の実際的な側面について意見交換を行い、ネットワークの効率的な運用を推進するための基盤を築く場となりました。これにより、ネットワークの使用方法に関する知識が共有され、改善点が特定されることが期待されました。
詳細については公式文書を参照してください: RFC 75
RFC 76: Connection by Name: User-Oriented Protocol
概要
RFC 76は、1970年10月にJ. Bouknight、J. Madden、G.R. Grossmanによって発行されました。この文書は、PDP-11ネットワーク端末システムのユーザー向けプロトコルに関する仕様を提供します。このプロトコルは、ユーザーがリモートホストコンピュータに接続し、プロセスを開始し、データフローをローカルの周辺機器にルーティングするための基本的な機能を提供することを目的としています。
内容
基本構造:
PDP-11/20に少なくとも8kのメモリ、小型ディスク（512キロバイトのストレージ）、コンソールテレタイプ、およびオプションのカードリーダー、ラインプリンター、DECテープなどの周辺機器が含まれます。
エグゼクティブシステムは、ネットワーク上の接続を管理し、すぐに実行できないタスクのキューイング、リモートホストの属性の保存などを行います。
ユーザー制御言語:
コントロール言語は、ネットワーク経由でリモートホストに接続し、プロセスを開始し、データをローカルの周辺機器にルーティングするための強力な手段を提供します。
ネットワークホストが文字ごとに通信を処理するか、メッセージモードで通信するかに応じて、システムは特定のホストへの接続を処理します。
周辺機器の指定:
周辺機器の指定は、デバイスクラスとデバイス番号を使用して行われます。デバイスクラスには、カードリーダー（CR）、カードパンチ（CP）、ラインプリンター（LP）、DECテープ（DT）、端末（TR）、ストレージスコープ（SS）が含まれます。
ファイルラベル:
ファイルラベルは、テープファイルを記号的に指定する手段を提供します。テープラベルのみが使用される場合、指定されたファイルはテープ全体を占有すると見なされます。
影響
このプロトコルは、ユーザーがリモートホストに接続し、効率的にデータを操作するための標準化された方法を提供することを目指しています。これにより、ネットワーク上での通信が簡素化され、システム間の互換性が向上します。
詳細については公式文書を参照してください: RFC 76。
RFC 77: Network Meeting Epilogue
概要
RFC 77は、1970年10月にS. Crockerによって発行されました。この文書は、以前のネットワークミーティング（RFC 75）の続編として書かれ、会議での議論内容と次のステップについて記載しています。
内容
会議の要約:
前回のネットワークミーティングで議論された主要なトピックが要約されています。これには、アカウンティングメカニズム、ドキュメント配布、メッセージ送信と保存、外国ユーザーによるシステムアクセスが含まれます。
追加のトピックとサブミーティング:
参加者が提案した追加のトピックや、議論を深めるために開催されたサブミーティングについても言及されています。
次のステップ:
会議の結果を基に、ネットワークの運用改善や新たなプロトコルの開発についての計画が示されています。
影響
このRFCは、ネットワーク運用の改善に向けた具体的なステップを示し、コミュニティ内での意見交換を促進する役割を果たしました。
詳細については公式文書を参照してください: RFC 77。
RFC 78: NIC Service
概要
RFC 78は、1970年10月にS. Crockerによって発行されました。この文書は、NIC（Network Information Center）のサービスとその役割について説明しています。
内容
NICの役割:
NICの主な役割は、ネットワーク全体の情報管理と配布、ユーザーサポート、ドキュメントの維持などです。
サービスの提供:
NICは、ネットワーク上の情報検索サービス、ユーザー向けのヘルプデスク、技術サポートなどのサービスを提供します。
ドキュメント管理:
NICは、ネットワークのプロトコルや運用に関するドキュメントを維持し、更新します。
影響
NICの設立により、ネットワーク全体の情報管理が効率化され、ユーザーが必要な情報にアクセスしやすくなりました。
詳細については公式文書を参照してください: RFC 78。
RFC 79: Logger Protocol
概要
RFC 79は、1970年10月にS. Crockerによって発行されました。この文書は、ネットワーク上でのログ管理プロトコルに関する仕様を提供します。
内容
ログの収集と保存:
ログの収集方法、保存形式、アクセス方法について詳述しています。
エラーハンドリング:
ログに記録されるエラーメッセージの形式や、エラーハンドリングの手順について説明しています。
セキュリティ:
ログ情報のセキュリティとアクセス制御についても言及しています。
影響
このプロトコルにより、ネットワーク運用の監視とトラブルシューティングが容易になり、システムの信頼性が向上しました。
詳細については公式文書を参照してください: RFC 79。
RFC 80: Protocol for Message Senders
概要
RFC 80は、1970年10月にS. Crockerによって発行されました。この文書は、メッセージ送信者のためのプロトコルに関する仕様を提供します。
内容
メッセージ形式:
メッセージの形式や、送信方法について詳述しています。
アドレス指定:
メッセージの宛先指定方法や、エラー処理について説明しています。
配信確認:
メッセージの配信確認や、未達メッセージの処理方法についても言及しています。
影響
このプロトコルにより、ネットワーク上でのメッセージ送信が標準化され、信頼性の高いコミュニケーションが可能になりました。
詳細については公式文書を参照してください: RFC 80。
RFC 81: Request for Reference Information
概要
RFC 81は、1970年12月にJ. Bouknightによって発行されました。この文書は、データ通信と通信理論に関する参考文献の提供を求める内容です。
内容
リクエストの内容:
データ通信と通信理論の分野における参考文献を可能な限り多く送ってほしいというリクエスト。
送付先はイリノイ大学の「Center for Advanced Computation」。
影響
このRFCは、データ通信と通信理論に関する文献収集の支援を求めることで、これらの分野の研究と進展を促進する役割を果たしました。
詳細については公式文書を参照してください: RFC 81
RFC 82: Network Meeting Report
概要
RFC 82は、1970年12月にS. Crockerによって発行されました。この文書は、ヒューストンで開催されたネットワークワーキンググループ（NWG）の会議に関する報告書です。
内容
会議の報告:
会議の概要と主要な議論内容を報告。
参加者が提案した追加のトピックや、議論を深めるためのサブミーティングについても言及。
影響
このRFCは、ネットワーク運用の改善に向けた具体的なステップを示し、コミュニティ内での意見交換を促進しました。
詳細については公式文書を参照してください: RFC 82。
RFC 83: Language-Machine for Data Reconfiguration
概要
RFC 83は、1970年12月にR. Merrymanによって発行されました。この文書は、データの再構成のための言語マシンに関する仕様を提供します。
内容
言語マシンの構造:
データの再構成に必要な言語マシンの基本構造とその動作原理について説明。
再構成プロセスの具体的な手順と使用例を示しています。
影響
このRFCは、データ処理と変換の効率を向上させるための標準化された手法を提供し、システム間のデータ互換性を向上させました。
詳細については公式文書を参照してください: RFC 83。
RFC 84: Specification for Network Use of the UCSB On-Line System
概要
RFC 84は、1970年12月にR. Watsonによって発行されました。この文書は、UCSB（カリフォルニア大学サンタバーバラ校）のオンラインシステムのネットワーク利用に関する仕様を提供します。
内容
ユーザーインターフェース:
システムへのアクセス方法、データ送受信のプロトコル、およびシステム管理のための手順を詳細に説明。
影響
このRFCは、UCSBオンラインシステムのネットワーク利用を標準化し、システムの利用効率と信頼性を向上させました。
詳細については公式文書を参照してください: RFC 84。
RFC 85: Net Data Specification
概要
RFC 85は、1970年12月にR. Karpによって発行されました。この文書は、ネットワークデータ仕様に関する技術的な詳細を提供します。
内容
データ形式:
ネットワークを通じて送信されるデータの形式とその処理方法について詳述。
データパケットの構造、ヘッダー情報、およびエラーチェックの手順など。
影響
このRFCは、ネットワークデータの一貫性と互換性を確保し、データ通信の効率と信頼性を向上させました。
詳細については公式文書を参照してください: RFC 85。
RFC 86: Proposal for Network Standard Format for a Data Stream to Control Graphics Display
概要
RFC 86は、1970年12月にA. Vezzaによって発行されました。この文書は、グラフィックスディスプレイを制御するためのデータストリームの標準フォーマットに関する提案です。
内容
グラフィックス制御:
グラフィックスディスプレイの制御に使用されるデータストリームのフォーマットとその解釈方法について説明。
データ構造、コマンドセット、および表示プロトコルの詳細。
影響
このRFCは、グラフィックスディスプレイの標準化を促進し、異なるシステム間での互換性を確保するための基盤を提供しました。
詳細については公式文書を参照してください: RFC 86。
RFC 87: Standard Host Names
概要
RFC 87は、1970年12月にV. Cerfによって発行されました。この文書は、標準ホスト名のリストを提供します。
内容
ホスト名の標準化:
ネットワーク上で使用される標準ホスト名のリストとその使用方法について説明。
ホスト名の一貫性を確保するための命名規則とガイドライン。
影響
このRFCは、ネットワーク上のホスト名の標準化を促進し、システム間の通信と管理を簡素化しました。
詳細については公式文書を参照してください: RFC 87。
RFC 88: NETRJS Protocol
概要
RFC 88は、1970年12月にA. Bhushanによって発行されました。この文書は、NETRJSプロトコルに関する仕様を提供します。
内容
プロトコルの詳細:
NETRJSプロトコルの目的、データ構造、通信手順について詳述。
リモートジョブエントリーシステム（RJS）のネットワーク通信を効率化するためのプロトコル。
影響
このRFCは、RJSのネットワーク通信を効率化し、システム間のジョブ管理とデータ転送を改善しました。
詳細については公式文書を参照してください: RFC 88。
RFC 89: Some Historic Moments in Networking
概要
RFC 89は、1970年12月にS. Crockerによって発行されました。この文書は、ネットワーキングの歴史的な瞬間に関するエッセイです。
内容
歴史的瞬間:
ネットワーキングの重要な歴史的出来事や技術的ブレークスルーについての回顧。
影響
このRFCは、ネットワーク技術の進化を理解し、過去の教訓から学ぶための洞察を提供しました。
詳細については公式文書を参照してください: RFC 89。
RFC 90: CCN and SINK Test Programs
概要
RFC 90は、1970年12月にJ. Postelによって発行されました。この文書は、CCN（Communication Control Network）とSINKテストプログラムに関する技術仕様を提供します。
内容
テストプログラムの詳細:
CCNとSINKのテストプログラムの目的、設計、実装方法について説明。
ネットワーク通信のテストとデバッグに使用される具体的な手順。
影響
このRFCは、ネットワーク通信のテストとデバッグを効率化し、システムの信頼性と性能を向上させました。
詳細については公式文書を参照してください: RFC 90。
RFC 91: Proposed User-User Protocol
概要
RFC 91は、1970年12月にG.H. Mealyによって発行されました。この文書は、ユーザー間通信を目的としたプロトコルを提案しています。このプロトコルは、ユーザー間でのデータ交換とコントロールメッセージの送受信を標準化するためのものです。
内容
データとコントロールメッセージの区別:
データメッセージとコントロールメッセージの区別を明確にし、それぞれのフォーマットを定義。
ASCIIデータブロックや任意のデータブロック（BLOCK）を使用可能。
フラグとメッセージの処理:
各メッセージにフラグを設定し、そのフラグに基づいてメッセージを処理。フラグには、制御（CONTROL）、ステータス（STATUS）、ラベル（LABEL）、キー（KEY）などがある。
エラー検出と処理:
メッセージの終わりを示すEOMフラグを使用して、メッセージの完全性を検証。エスケープ（ESC）フラグも用意されており、特殊な用途に使用可能。
影響
このRFCは、ネットワーク上でのユーザー間の通信を効率化し、エラー検出と処理のメカニズムを提供することで、信頼性の高いデータ交換を実現するための基礎を築きました。
RFC 92: FTP Document Transfer
概要
RFC 92は、1970年12月にA.K. Bhushanによって発行されました。この文書は、ファイル転送プロトコル（FTP）を用いたドキュメント転送の仕様を提供します。
内容
ファイル転送の手順:
FTPを使用して、ネットワーク上でファイルを転送する手順とプロトコルを定義。
コマンドと応答の形式、データ転送の方法について詳述。
エラーハンドリング:
ファイル転送中のエラー検出と処理方法についても説明。
影響
このRFCは、ネットワーク上での効率的かつ信頼性の高いファイル転送を実現するための標準プロトコルを提供しました。
RFC 93: Initial Connection Protocol
概要
RFC 93は、1970年12月にA.K. Bhushanによって発行されました。この文書は、ネットワーク上での初期接続手順に関するプロトコルを定義しています。
内容
接続手順:
ネットワーク上のホスト間で初期接続を確立するための手順を詳述。
接続要求と応答のメカニズム、セッションの開始と終了について説明。
影響
このRFCは、ネットワーク接続の確立を標準化し、ホスト間の通信を円滑に行うための基盤を提供しました。
RFC 94: Some Thoughts on Network Graphics
概要
RFC 94は、1970年12月にA.V. Herzfeldによって発行されました。この文書は、ネットワーク上でのグラフィックス表示に関する考察を述べています。
内容
グラフィックスの標準化:
ネットワーク上でグラフィックスを表示するための標準フォーマットとプロトコルについて議論。
データ形式、表示手順、およびプロトコルの提案。
影響
このRFCは、ネットワークグラフィックスの標準化を推進し、異なるシステム間での互換性を確保するための基礎を築きました。
RFC 95: Distribution List
概要
RFC 95は、1971年1月にV.G. Cerfによって発行されました。この文書は、ネットワーク上の情報配布リストに関する仕様を提供します。
内容
配布リストの管理:
ネットワーク上で情報を配布するためのリストの作成と管理方法を詳述。
メンバーの追加、削除、情報更新の手順について説明。
影響
このRFCは、ネットワーク上での効率的な情報配布を実現するための標準的な方法を提供しました。
RFC 96: An Interactive Network Experiment to Study Modes of Accessing Information
概要
RFC 96は、1971年2月にA.K. Bhushanによって発行されました。この文書は、情報アクセスモードを研究するためのインタラクティブネットワーク実験に関する内容を記載しています。
内容
実験の目的と手順:
ネットワークを使用して情報にアクセスするさまざまなモードを研究するための実験の目的と手順を説明。
実験の設計、参加者の役割、データ収集方法について詳述。
影響
このRFCは、ネットワークを介した情報アクセスの効率性と有効性を評価し、最適なアクセス方法を見つけるための基礎を提供しました。
RFC 97: A First Cut at a Proposed Telnet Protocol
概要
RFC 97は、1971年2月にJ. Postelによって発行されました。この文書は、Telnetプロトコルの初版を提案しています。
内容
Telnetプロトコルの定義:
リモートホストとの対話を可能にするTelnetプロトコルの基本仕様とコマンドセットを定義。
接続手順、データ転送方法、エラー処理について詳述。
影響
このRFCは、遠隔操作のための標準プロトコルとしてTelnetの基礎を築き、ネットワーク管理と運用を簡素化しました。
RFC 98: The Use of Well-Known Ports
概要
RFC 98は、1971年3月にJ. Postelによって発行されました。この文書は、ネットワークサービスのためのウェルノウンポートの使用に関するガイドラインを提供します。
内容
ウェルノウンポートの指定:
特定のネットワークサービスに割り当てられるウェルノウンポートのリストとその使用方法を説明。
ポート番号の範囲と管理方法についても言及。
影響
このRFCは、ネットワークサービスの標準化を促進し、サービス間の衝突を防ぐための基盤を提供しました。
RFC 99: Network Monitoring
概要
RFC 99は、1971年3月にA.K. Bhushanによって発行されました。この文書は、ネットワーク監視のためのプロトコルと手法を提供します。
内容
監視方法:
ネットワークトラフィックの監視とデータ収集の手法について詳述。
エラー検出、トラフィック解析、およびレポート生成の方法を説明。
影響
このRFCは、ネットワーク運用の監視とトラブルシューティングを効率化し、システムの信頼性を向上させました。
RFC 100: Categorization and Guide to the Work in Progress
概要
RFC 100は、1971年3月にJ. Postelによって発行されました。この文書は、進行中の作業に関する分類とガイドを提供します。
内容
作業の分類:
進行中のネットワーク関連プロジェクトの分類と概要を説明。
各プロジェクトの目的、進捗状況、および今後の計画について詳述。
影響
このRFCは、ネットワークコミュニティ内での情報共有と協力を促進し、プロジェクトの効率的な進行を支援しました
以上、１から１００までのRFCでした。残り、、
おもしろきこともなき世を面白く 議論メシ4期生http://gironmeshi.net/ メンタリストDaiGo弟子 強みほがらかさと発散思考 外資系企業でインフラエンジニア