はじめに
以下の要約は、1970 年秋季 Fall Joint Computer Conference の期間中に Houston で開かれた三次のネットワーク会議で私が取ったメモから起こしたものである。客観的であろうと努めたが、このメモが会議について偏った見方を示すのは避けられない。これは一部には、私が特定の話題に気を取られていたことと、さまざまな議論を誤解した可能性による。出席者の発言を正確に言い換えようと努めたが、いくつかの趣旨はねじ曲げられているかもしれない。
月曜会議の出席者
Dick Benjamin MITRE
Jack Bouknight UI-CAC
Al Cocanower MIRUT
Steve Crocker UCLA
Dough Engelbart SRI
Richard Greenblatt MIT-MAC
Eric Harslem RAND
Frank Heart BBN
Allen Joseph ORNL (Oak Ridge)
Peggy Karp MITRE
William B. Kehl UCLA
Bob Long SDC
Jim Madden UI-CAC
Bob Metcalfe MIT-MAC
Edwin Meyer MIT-MAC
Ari Ollikainen UCLA
Tom O'Sullivan Raytheon
Jon Postel UCLA
Chris Reeve MIT-MAC
Tjaart Schipper UCAL-CCN
Michael S. Sher UI-CAC
Bob Sundberg Harvard
Hal van Zoeren CMU
Albert Vezza MIT-MAC
Alfred H. Vorhaus MITRE
Clark Weissman SDC
ネットワーク会議
1970年11月16日 月曜日 午後8:05
Crocker: 全員はまだ来ていないので、もっと人が来るまで話を進めよう。私の告知にあった議題で皆満足しているか?
Meyer: logger protocol について話すべきである。実験とは対照的に、ネットワークの運用上の使用はその実装にかかっている。
周囲の全員に紹介が行われた。
Crocker: 議題は用意してあるが、話題について提案がほしい。
- 私が冒頭の発言を行う。
- 私が関心のある話題を列挙する。
- Englebart が Network Information Center について話す
- 私が各サイトの状況を概観する。
冒頭の発言
- ARPA は出されているコーヒーと菓子代を払ってくれないので、私が支払えるよう皆で少しずつ出してください。
- 私は公式の立場でネットワーク調整に専念することになる。私の目標は、(a) ネットワークの使い勝手を高めること、(b) プロトコルの水準を確立すること、(c) ?
重要な領域
- いずれかのサイト、またはサイトの連合が、あるサイトの NCP を検査する方法を用意すべきである。
- NCP プロトコルの作り直し。いくつかの問題はよりよく解決できる: (a) エラー制御、(b) フロー制御、(c) 過負荷 - ネットワーク状態の喪失、(d) プロトコルの単純化と再階層化。
- Telnet system のコンソール対話、すなわち logger protocol。システムにどう入るか、困ったときにどう助けを得るか。
- 個々のホストの文書。Network Info Center が関与する。おそらく各サイトにファクシミリ装置を提供できるだろう。
- より高度なコンソール、特にグラフィックスコンソールをネットワーク経由で接続する。高度なコンソールを扱う形式を策定し練り上げる作業グループが必要である。1 月に Colorado か Utah でグラフィックスの会議がある。参加の条件は提案書を書くことである。30 人程度を見込んでいる。仕様を開発するため少数の者を選ぶ。
- 課金 - 1971 年の後半には、課金が重要となるより多くのサイトが参加する。(彼らは請求書を送りたがっている。) Larry Roberts は、請求書が回される一種の銀行システムができると言っている。サイトは二種類ある: 課金サイトと、無料だがアクセスが制限される研究サイトである。根本的な問題は見当たらない。研究サイトが課金サイトと通信すると何が起こるか? 実行可能だと思う。
- 計測 - ネットワークは道具であるが、シミュレーションパッケージより優れたモデルでもある。さまざまな人々が計測を行いたがっている。これは NCP に統計を保持させることで支えられる。これらを含めるよう NCP を増強してはどうか?
Long: 課金と計測を NCP に入れると容量を食う。追加は最小限に抑えるべきだ。
Weissman: 各種システムの利用可能時間の予定はどうなっているのか?
Crocker: それは個々のシステムごとに調整しなければならない
? : システムがダウンしたとき、接続はどうなるのか?
Crocker: グラフィックスの提案はどうか? 私は自分の論文を提案として書く。それは DEC 340 をモデルとして使う。Modes は scope system にメモリを仮定する。出力と入力の両方が標準策定に含まれる。作業グループから有能なプロトコルが開発されることを望む。
Crocker: 文書はどうか?
Meyer: 他のシステムの使い方に関する文書は必須である。これだけがネットワークの運用上の使用を促すことができる。
--: 各サイトで文書をオンラインにするのはどうか、少なくとも概要だけでも。
Crocker: どのサイトが文書をオンラインにしているか? (MIT と Harvard) 文書をよそのシステムに置くことについて各サイトはどう感じているか?
Crocker: プロトコルを作り直すのはどうか?
Harslem: 我々は UCSB のシステムにログインしており、共同でデバッグしている。
Harslem: マーキングとパディングの廃止 (RFC 67 による) には感銘を受けている。
Crocker: これについては各サイトと話し合った。大半は受け入れたようだが、多少の留保もある。基本プロトコルの変更はどうか。I'm Meyer が何か言いたいそうだ。
Meyer: Project MAC の立場は、現時点では重大な修正以外の変更に反対である。変更に費やす時間は、他の必要な、そして興味深いプロトコルやシステムの開発に費やされない時間である。しかも我々 Multics では、変更の作成と導入に長いリードタイムがかかる。
Weissman: 私は変更を小刻みに入れるより、たとえば 6 か月間隔で一まとめに入れる方を好む。
O'Sullivan: 現行のシステムと新しいシステムは同時に動かせないのか?
Crocker: 変更が IMP に関わるなら無理だ。すべての IMP は同じシステムで動作する必要があるからである。
Meyer: M.I.T. の感触では、成功するためにはネットワークが運用上使われることが切実に必要である。もう一年、有意義な運用上の使用がなければ、おじゃんになるかもしれない。
--: そして文書は、運用上の使用を促すうえで決定的に重要である。
Engelbart: タイプライタを遅らせないよう、グラフィックスを数か月延期すべきかもしれない。タイプライタは重要である。
--: しかしそれで DOD の人々に十分に強い印象を与えられるだろうか?
Engelbart: しかし二年後に厄介な問題の山になっているとしたら...
--: しかし二つの (タイプライタとグラフィックスの) 開発グループは交流しているのか?
Vezza と Engelbart: はい。
Crocker: これについてもっと聞こう。
Harslem: 我々はファイルにアクセスできるようにしたい。
Crocker: ならばグラフィックスの取り組みはタイプライタの開発を薄めるかもしれない。グラフィックスの会議を開くべきでないというのがこのグループの総意か?
Vezza: グラフィックスは新参者が取り組むべきで、既存の人々ではない。現在の人々がこの会議に行くことを禁じるべきだ。
Meyer: それは非常にいら立たしいだろう。
Benjamin: ポジションペーパーを募集してはどうか (ただし会議は開かない)。
Weissman: 文字の伝送はグラフィックの伝送より容易である。グラフィックスにはもっと実験が必要である。グラフィックプロトコルの開発にかかるリードタイムはタイプライタよりずっと長い。
Vezza: 賛成だ。
Crocker: これから数日のうちに、ネットワーク経由で有用な仕事をこなす問題に取り組むため、さらに会議が開かれる。
休憩
午後9:15
Crocker: Engelbart が Network Information Center について話す。
Engelbart: NIC は ARPA からの具体的な指示もなく、その場しのぎで育ってきた。どのようなものが想定されていたか? (1) 高度な問い合わせシステム、(2) 各サイトのシステムに関する基本情報である。誰もが自分のサイトの文書の状態に非常に弱みを感じている。全員が同意している: より良い文書が必要である。我々は次のサービスを提供するものと考えている: 1) ハードコピー資料の収集、2) それらのカタログと索引のオンライン問い合わせ、3) この資料へのアクセス提供。我々はオンラインではなくハードコピーで進めることにした。おそらくマイクロフィッシュで。
Engelbart: 940 は文書システムに使われる予定で、使用の増加に応じて拡張可能であった。我々はサービス能力をよりよく拡張するため、940 から 10X に切り替えつつある。容量はかなり増える。これが他の面での作業を遅らせてきた。意識的な賭けである。我々は立ち上げに不安を抱いている。二次記憶を増やす資金が足りず、三次記憶に他のホストを使うことに関心がある。940 でプロトコルを実装する費用は、得られる利益に対して高すぎたので断念した。我々の 940 を送り出す頃の 1 月までに立ち上がるサイトはほとんどなかっただろう。
Engelbart: 我々は Network Dialogue System を作った。これは人間のエージェントのネットワークである。各サイトには a) 技術通信エージェント (秘書) と b) 技術連絡担当者がいる。我々はエージェントが我々と話すよう促しており、無料で通話できるよう「Enterprise」電話番号を作った。
Engelbart: 我々はまず各エージェントに小さなキット、つまり成長しつつあるネットワーク参照情報の集合を送っている。各サイトの一人 (エージェント) が、その文書一式を扱い、情報を取り出し、他サイトの技術連絡担当者に連絡するよう訓練される。これは公の対話であり、行き来する文書の記録を保持することを伴う。これは一種の「人間 IMP」ネットワークであり、次のように構成される:
________________________________
| |
| ________________ |
| | local | | one
| | reference | | <== site ____________
| | material | | ( )
| -----------------| | ( )
| | => (____________)
| | || \\
| | || Other sites
| | || \\
| ________ | || ____________
| local =====> | |================ ( )
| users | agent |=====|===============( )
| =====> |________| | (____________)
| |
|________________________________|
- マスタコレクションがすべての資料を持つ。
- 各ローカルコレクションは最も有用と見なされる部分集合を持つ。
--: 文書へのアクセスを制限するのはどうか?
Engelbart: このシステムではすべてのファイルは公開ファイルである。
Vezza: NIC のサービスを使う代わりに私的なメモを送ればよい。
Engelbart: マスタコレクションには書籍やその他の文書が含まれる。オンラインでカタログ化される。ハードコピーのものは複製できる。価値の基準を満たす情報については、このサービスは文書を保存し、カタログ化し、索引を付け、アクセスを提供する。我々はいくつもの異なる端末をサポートする。ハードコピーの項目で長くやっていく覚悟はあるが、有料でハードコピーからオンラインへの転記サービスも設けられる。
Weissman: 各サイトに OCR Selectric ボールを配布するのはどうか?
--: NIC は送られてきたものを受け取るのか、それとも積極的に探し出すのか?
Engelbart: 多かれ少なかれ、こちらに来たものを受け取る。1971 年春には、エージェントがカタログに項目を挿入できるシステムが存在する。行われる対話が、データベースがどちらへ成長するかを決める。我々は、一次サイトにいない多くの潜在的利用者が限られた資源を求めるため、最終的に SRI が課金せざるを得なくなるとかなり確信している。
--: あなたの 10X 用の NCP はどうか。
Engelbart: 1971 年 2 月までに BBN の NCP ができれば、それを使う。
Crocker: 人々はどうやってアクセスするのか?
Engelbart: 各サイトは登録される。サイトのアカウントで入った者は誰でもそのアクセス権を持つ。飽和状態になるまでは課金を気にしない。各サイトの資源の調査を作成し利用するためにエージェントシステムを使うことを促したい。何らかの分科会がこれについて話すべきである。
Crocker: これについて話し合うために人々はいつ集まれるか? (明朝)
Engelbart: 我々にはメーリングリスト、私的な文献目録、人員プロフィールを作成するための立派な設備があるが、それはネットワーク関係者の関心次第である。
Engelbart: MIT、UCLA、RAND、UI、Utah などとエージェントが設けられた。かなりの割合のサイト
Vezza: 多くのサイトが三等・四等郵便で物を送っている。時間がかかりすぎる。
Crocker: サイト状況報告。ILLIAC IV は 1971 年半ばまで運用されず、ネットワークにはさらに後 (72 年?) に載る。他の候補サイト: RADC、AWS、NCAR。現在稼働中: UCSB、RAND。間もなく (1971 年 1 月): MIT BBN、Harvard、UCLA、Utah、LL、SDC。年末までに一部の割合、残りは 1 月に。
Heart: 全く新しい IMP システム (大幅な変更) が明日導入される。さらにいくつかのサイトが参加を検討している。ネットワークは現在搭載されているものをはるかに超えて成長するだろう。我々もサイト資源情報に関心がある。長期的な関心ではないが、ARPA の助けになるよう情報を紙にまとめる。
Crocker: 多くの人があくびをしている。会議の日程はどうか? FJCC の期間中に? 1 日か 2 日の会議か? 東海岸と西海岸の二重開催はどうか?
会議の終了
ネットワーク会議
1970年11月17日 火曜日 午前9:15
Crocker: Engelbart がより詳しく話す。後で logger protocol とファイル転送を議論するかもしれない。
Engelbart: 基本となるのは、それを記述するカタログを伴う文書のコレクションである。項目には、どこにあるかを含め多くのデータ要素がある。項目を追加し更新する技法。我々は今それを行っているが、どこに価値があるか判断できないこともあり、他の側にも能力を与えたい。 (3 種類の印刷出力を示した。) 1) コレクション内の順序索引と NIC 索引によるカタログ一覧。在庫管理のため、何があるかを見つけるため。 2) 一行に圧縮した形式。 3) 著者別に並べ替え、項目ごとに一行。 我々は、訓練を受けていない利用者でもコレクションを管理できる手順を用意する。
Meyer: これらのシステムはどう実装されているのか?
Engelbart: 940 上に compiler-compiler がある。我々のサブシステムは特殊な高水準言語で書かれている。これを 10X へ移している。
Heart: 大まかに言って 10X は何人をサポートできるのか?
Engelbart: おそらく 100-1000 のコレクション。
--: 追加記憶として、人々が自分の DEC テープを持ち寄ることもできるかもしれない。
Engelbart: できなくはないが、オンサイトのオペレータが必要である。アクセスは遅い。我々には記憶を増やす金はないが、ファイルを UCSB に送ることを検討している。我々はオンラインデータのオンライン問い合わせを提供する。保存するかどうかにかかわらず、データ管理を引き受ける用意がある。
Crocker: 各種サブシステムについて説明してほしい。 (以下、Engelbart による説明。)
Heart: 誰かネットワーク経由でそれを使おうとしたか?
Engelbart: いいや。940 には NCP がない。なくなる予定のシステムには入れないことに決めた。最大の障害は 10X が NCP を手に入れるときである。Bobrow が開発しているが、遅れている。
Heart: 誰が早くそれ (SRI) に取りかかるのか?
UI: Illinois は最初は SRI にしかアクセスできない。
Postel, UCLA: 我々は使う予定である。
Heart: 誰かが Engelbart のシステムに入ることを目標にすれば、重要な仕事になるだろう。
MITRE: 我々は BBN の 10X から他のシステムを使うつもりである。
Engelbart: 我々は人々が容易に使えるよう、本質的なサブシステムを切り出そうとしている。ファイルは階層的に編成され、年を経るにつれて充実していく。文書はパス名で参照される。 (以下、システムについての議論。)
Crocker: どうやってシステムに入るのか? (Engelbart が TOdas への入り方の手順を説明する。)
Crocker: システムにどうやって登録するのか?
Engelbart: 最終的には個人単位の登録だが、現在はサイトごとに一つの user id がある。
Meyer: 我々はタイプライタのインターフェースにおける未解決の問題を無視していると思う。たとえば TOdas への入り方では、利用者が一、二文字をタイプするとシステムがキーワードの残りの文字を打ち出すが、これは Multics のような half duplex システムから使うと苛立たしいだろう。我々のシステムは、改行が入力されるまで入力行を認識しない。
Various: 1/2 duplex 通信についての議論。a) システムが入力をエコーする full duplex システムと、入力がローカルで打鍵される 1/2 duplex、および b) 入力されるたびに各文字が認識されるシステムと、EOL 文字の後に初めて行全体が認識されるシステム、の区別が明らかになった。
Crocker: ネットワーク上で half-duplex かつ行指向のシステムはMultics だけではないか?
Meyer: 信じられない。IBM のシステムもそう動くのではないか?
Engelbart: 我々のシステム (SRI) には 1/2 duplex インターフェースを設けられる。この制約を課しているのは Multics のハードウェアか?
Meyer: そうだ、入出力コントローラだ。*
* Multics IO コントローラのタイプライタアダプタは 1/2 duplex だが、「改行」文字以外の break 文字も受け付けられる。
Engelbart: 各システムは他のシステムと話すためのプリプロセッサを持つべきである。我々はネットワークにグラフィックスインターフェースを載せるつもりである。
Meyer: これらのインターフェースをどう見ているのか? それらは何らかのネットワーク標準に従うのか、それとも各システムがあなた方へのインターフェースを構築するのか?
Engelbart: 標準のネットワークプロトコルである。
Crocker: 他のことに移ろう。
O'Sullivan: あなた方 (CMU) の 10X システム上の 2741 はどうか。深刻なインターフェース問題はあるか? (CMU の 2741 はそれらを TTY 37 に変換するソフトウェアパッケージを通る。深刻な困難はない。)
Various: Multics がどのように入力を扱うかについての簡単な議論。
Sundberg, HARVARD: 我々の 10X は char-oriented の入力を受け取れるが、上位のサブシステムは line-oriented の入力を好む。
--: ネットワークを通して一度に一文字ずつメッセージを伝送する効率はどうか?
Crocker: 入力より出力の方が多く、出力はまとめて送られるので、入力の非効率は無視できる。
Engelbart: 我々は自システムへのいくつかの異なるポートを用意する予定である。各システムが NIC モジュールを持てば、ログインすることなく我々と通信できる。我々は、サイトが spool された編集要求のバッチを送り、物を受け取り、ポートを解放するというバッチ型のシステムを好む。タイプライタを行単位で伝送する問題は、spool された要求と同様に扱える。我々は spooling を促すが、対話型の利用者もサポートする。我々は対話型の人々より多くのバッチをサポートできる。
* Multics IO コントローラのタイプライタアダプタは 1/2 duplex だが、「改行」文字以外の break 文字も受け付けられる。
Vezza: full duplex と 1/2 duplex の問題を問題だと人々は感じているか? 皆が戻ってこれについて調べるように。20 feet 離れた full duplex と 1/2 duplex のシステムを持つ M.I.T. がここでは助けになる。
O'Sullivan: 2 つの問題があるようだ: (1) エコー (full duplex) 対 1/2 duplex。 (2) 単一文字の伝送 対 行全体の伝送。
Crocker: 二つの定義: Serving host - 計算を提供する。using host - 寄生型で、利用者の端末を管理する。これはネットワークの使用を、ローカルの利用者と外部のサーバーとの間のリンクと見なす。
Vezza: 一部の full duplex システムが入力以外のものをエコーする場合の、1/2 duplex と full duplex の相互接続はどうか。
Crocker: 二つの独立した可能性がある。図を描こう:
| "2741" | "33, 35, 37" |
| hard wire | 2 separate |
| local echo | lines all |
| computer does | printed |
| not echo | |
____________|_________________|___________________|
Process | hard | X |
each | | |
character | | |
____________|_________________|___________________|
Process | X | easy |
only after | | |
EOL | | |
____________|_________________|___________________|
Crocker: 実際には二つの可能性しかないと主張する (X で印を付けた)。
Postel: エコーが削除できないほど低い水準で行われるシステムはどうか。
Crocker: そうなら、エコーしないのと同じである。
Van Zoeren: 我々のシステムは full duplex の TTY を持っていると考えているが、我々の 2741 はソフトウェア変換ボックス経由で接続されている。
Meyer: エコーしないシステムがネットワーク経由でエコーするシステムに接続されると何が起こるか? 私が入力行をタイプすると、エコーするシステムが私の入力を返し、次に何らかの出力を返す。私のシステムはエコーと出力を区別する方法がないため、これをフィルタできない。
Crocker: これは必ずしも悪いことではない。私が SRI にコマンドの省略形をタイプすると、次の出力行は入力コマンドを展開した形である。
Meyer: 我々の目標は、特定のホストの組の間の通信を実装するための一群の場当たり的な仕組みではなく、一つの共通のプロトコルであるべきだ。
Long, SDC: 我々はネットワークを通して送られてくる行全体を受け取る方を好む。
Crocker: 研究センターとサービスセンターを区別しよう。half-duplex インターフェースに関わるのはサービスセンターだけである。 (図の左下の X)。これらには SRI、BBN、Multics が含まれる。
O'Sullivan: 研究センターはどうか?
Crocker: 彼らはサービスセンターを呼び出せるが、彼ら自身は使いにくいかもしれない。
Illinois: ならば ILLIAC IV は half-duplex でなければならなくなる。
Postel: half-duplex で行指向のものは (full-duplex で文字指向のプロトコルより) 弱いと思う。
Sundberg: Harvard はどちらでもよいが、行指向のシステムを好む。
Engelbart: グラフィックス端末は、非標準の入力のためネットワークに載せるのがより難しい。
Harslem: あなたはキーを入力キーではなくファンクションキーと考えている。
Engelbart: グラフィックスを使いたい人々のことが心配である。
O'Sullivan: どのようなプロトコルを確立すべきかという問題には触れていない。
Crocker: それは難しい技術的なことではない。後でそこに触れ、決定を下す。
Meyer: 私はいかなる決定を下す権限もない。MAC グループに報告することになっている。
Crocker: よし。では、通常の仕組みを通して受け入れられるべき提案を。 休憩
Crocker: X 印の付いた箱の扱い方を提案する。hard と ease の箱は無視する:
行指向入力 - End of Line 文字を含む 8 bit ascii:
n, C1,...,Cn;
Cn=EOL
120>n>>_1 n is the character count in an 8-bit field.
文字数が行の前に付き、ソフトウェアシステムにハードウェアシステムと同じ効率を与える。コンピュータは EOL を走査する必要がない。
Vezza: IMP メッセージで長さの情報が得られるのではないか?
Crocker: 私の哲学は、IMP メッセージ境界は完全に見えなくすべきだというものである。
Long: タイプライタメッセージを二つの別々の塊に分割することに反対である。
Crocker: 反対の理由は何か、1) 行がメッセージ境界から始まることか、それとも 2) メッセージが行境界から始まらないことか?
Long: 両方だ。
Engelbart: 各ホストは最も一般的な端末の種類を扱うインターフェースを書くべきである。
Crocker: 公式のプロトコルは、IMP メッセージ境界に何らかの意味があることを認めていない。
Engelbart: IMP メッセージ境界を気にしたくない。ネットワークは (この水準では) 見えないべきである。
Vezza, Long: 譲歩する、従おう。
Meyer: 私は制約を変えたい。行パケットの最後の文字は EOL である必要はない (出力が新しい行に進まない場合のように) が、EOL はパケットの途中に現れてはならない。
Van Zoeren: この制約は好まない。
Meyer: カウントが、EOL は末尾にあると教えてくれるので、走査する必要はない。
Crocker: EOL は、システムに動作を起こすよう告げる文字である。
Harslem: 我々のシステムには 46 個のファンクションキーがあり、EOL だけではない。
Crocker: C, E {breakset}; i=n としたらどうか。これはより複雑である。breakset を伝送しなければならないからである。これについてはすぐ後で提案する。次のようなのはどうか: メッセージ指向 (1/2 duplex) の接続
コンソール対話のための、User ホストと Server ホストの間の接続。ローカルエコーで、サーバーエコーはなし。これは行指向のサービスシステム向けである。これらは Multics の取り決めをわずかに一般化したものである。
Meyer: Multics 以外の他のシステムもそれを使っているはずである。あなたが思うほど悪くはない。
Engelbart: 上層の管理者はそれが悪いと知るべきである。
Meyer: それは明確ではない。効率の問題がある。
Van Zoeren: この方法でファイルを伝送しなければならないのは嫌だ。
Crocker: これはコンソール用であり、ファイル伝送用ではない。
Engelbart: データ伝送のための統一された仕組みが必要である。
O'Sullivan: (コンソールについて) 我々は、システムに割り込みをどこでシミュレートすべきかを告げる方法を考案すべきである。
Crocker: テープとファイルのデータ伝送には一般的な問題がある。
O'Sullivan: しかし我々にはタイプライタ通信を実装するという具体的な問題がある。
Engelbart: しかし我々に必要なのは、ネットワークを通して (見えないように) 物を送り、ホストがそれを望むままに解釈する、一般的な方法である。
Meyer: ネットワークには一つのコンソールインターフェースがあるべきで、各サイトにいくつもあるべきではない。
Crocker: この問題はおそらく誇張されている。
Engelbart, Meyer, O'Sullivan: 特定の端末の種類をサポートすることについての議論。
Engelbart: システム対端末の種類のグラフを描こう。あるシステムと、そのシステムに受け入れられる端末との交点は点で示す。ネットワーク通信の問題は、ローカルホストにあって対象ホストでもサポートされる端末を見つけるという問題である。
_____|_____|_____|_____|_____
| | | |
systems_____|_____|_____._____|_____
| | | |
_____|_____._____|_____|_____
| | | |
_____|_____|_____|_____|_____
| | | |
terminals
Crocker: サブシステムが入力に反応するという一般的な問題がある。入力は完全なメッセージとして、または 8-bits の倍数で送るべきだと提案しよう。
Vezza: 我々は制約しすぎているのではないか?
Meyer: なぜ 8-bit の倍数にする必要があるのか?
Crocker, Engelbart: よし、それは捨てよう。
第二回会議の終了
ネットワーク会議
1970年11月18日 水曜日 午後8:20
(以下のメモは大幅に要約したもので、この会議で議論された主要なテーマのみを示そうとするものである。)
Crocker: もっと事前に準備して SJCC で会おう。2-3 か月間隔で数日間の会議を開こう。次のレベルのプロトコルについて多くの良い議論ができた。分科会に詰めさせよう。
(Harslem が RFC 66 で提案された logger protocol を書き直すことを志願する。Meyer が RFC 46 の提案を改訂する。)
Meyer: 戻って、これらの問題を議論し、提案を書こう。後で正式な提案を決めるための公開会議を持つ。
Crocker: 小さなグループの方がよい。おそらく私が一部を選ぶ。
Vezza: ここで物事が決着していないのは確かである。主要な提案は会議に先立って紙になっているべきである。我々は小さなグループのすることを法制化できない。それは個人以上の権限を持たない。
(MITRE の Karp が、おそらく 1 月までにネットワーク文書の文献目録を作成することを志願する。)
(誰が logger protocol を実装したか? UCSB と UCLA mod 91 は実装済みか計画中である。SDC は 21/1 までに持つかもしれず、ぎこちないと感じており、変更する用意がある。)
(ファイル伝送についての議論。Crocker は、将来のプロトコル変更で、8、32、36 bits のような byte サイズを接続に付けるかもしれないと提案する。)
(制御リンクについて、ECO、ERP、ERR コマンドを除きすべてが 8-bit の byte で伝送される。それらも 8-bit の byte の倍数でなければならないようプロトコルを変えることに異議は唱えられなかった。)
(ファイルの終端をどう指定するかについての議論。事前にビット数を伝送するか、末尾に EOR 文字を送るか? 単なるファイル伝送ではなく、任意の長さのメッセージを送るという一般的な問題に対する全体的な解決を望むという提案。)
(「transaction units」すなわちレコードサイズについての議論。最適な transaction unit サイズは何か? IMP メッセージ境界は (プロトコルのお達しにより) 見えず、この議論とは関係がない。Multics のブロックサイズが持ち出された。最も近いものはページサイズ、1024 words である。)
(ファイルの終端をどう指定するか。Engelbart は、データパケットを送り、次に EOF パケットを送ると言う。Crocker は、接続を CLS することが EOF として働けると提案する。Vezza は、IMP メッセージ境界を終端の判定に使うことを提案する。完全な IMP メッセージより少なければ、それがファイルの最後の部分である。Meyer は、データチャネルと制御チャネルの二つの接続を使い、ファイル名、ビット長などのすべての制御メッセージをその上で渡すことを提案する。)
(ファイル全体、ファイルの一部、または任意の塊でのファイル全体が求められるさまざまな状況についての議論。)
Meyer: これを延期して、最も重大なタイプライタ通信について話してはどうか。
Vezza: Engelbart はすっきりした一般的な解決を望んでいる。
Crocker: 今その場しのぎの解決を得ると、後で一般的な解決を実装するのを妨げるかもしれない。
(Crocker は、8-26 bits の固定サイズの byte からなる任意の長さのレコードのファイルを伝送する形式を提案する。レコードは 10^5 bytes 未満である。各レコードは先頭にカウント byte を持つ。)
1 2 n 1 2 m
|----------------------------------------------------|
| n | | | | | m | | | | |
|----------------------------------------------------|
<------- record -----------> <-------- record ------->
O'Sullivan: このモデルは、文字モードとグラフィックモードを持つ端末に適合するか?
(キーボードとファイル伝送の違いについての議論。全体的な解決が両方に適合するかどうかは不確かである。)
(誰がネットワークを通してファイルを送りたいのか? Multics と 6-10、RAND から UCLA へ、MITRE は BBN を使う。)
Crocker: これを持ち帰って考え、後で解決策を提案しよう。
(Harslem は、operation code を伴うデータを伝送する形式を提案する。各レコードは次からなる: <opcode> <length> <data>。多くの種類の状態情報を送る機会を与える。)
(データと制御情報を混在させて送るか、別々の接続で送るかについての議論。データの汚染 対 同期と競合の問題。同期の問題は容易に克服されると主張された。)
(この領域について我々は実際にはあまり知らないという提案。我々は持ち帰って書くべきである。)
休憩
Crocker: 他のシステムにログオンできるようにする前に、何をしなければならないか?
Meyer: 3 つの問題: 1) どうやって接続を確立するか、2) 文字集合は何か、3) 伝送のモードは何か (full duplex と 1/2 duplex の問題に関連する)。
(一般に行指向で 1/2 duplex であるサービスシステムに向けて標準プロトコルを方向付けることについての議論。サービスを提供するシステムはすべて 1/2 duplex インターフェースを持つべきである。)
(logger protocol が IMP メッセージ内で部分的な行の伝送を許すことが可能か、望ましいかについての議論。部分的な行を受け取るのは効率が悪く、行全体を送るのが妥当である。NCP プロトコルは IMP メッセージ境界に何の意味も認めていないので、システムは IMP メッセージ境界をまたぐ行を受け入れる用意がなければならないと指摘された。ただし、完全な行を送るのが最善である。)
(行指向のプロトコルが、full duplex システムからの単一文字伝送を受け入れるよう曲げられるべきかについての議論。どのシステムも行指向のシステムを使えるようにするプロトコルを我々は考え出しているようである。他のシステムから文字指向のシステムを使うのはより難しく、別のプロトコルを要する。)
Heart: 私は即時の解決に賛成である。
Postel: いったん何かが入ると、それを変えるのは難しくなる。
Crocker: これらの会議は、我々が望んだ以上に重要になるだろうと思う。私は開始日よりも長期的な影響の方を気にしている。
Van Zoeren: 我々が決めなければ、誰か他の者が悪い形で決めてしまうだろう。
注: この RFC は、Gottfried Janik により 2/98 にオンライン RFC アーカイブへ収録するため機械可読形式に変換された。