RFC77 日本語訳
0077 Network meeting report. J. Postel. November 1970. (Format: TXT=19196 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Postel Request for Comments: 77 UCLA NIC 5604 20 November 1970
コメントを求めるワーキンググループJ.ポステルの要求をネットワークでつないでください: 77 UCLA NIC5604 1970年11月20日
Network Meeting Report
ネットワークミーティングレポート
This is a report on a series of three Network Working Group meetings at the Fall Joint Computer Conference, November 16, 17 and 18 in Houston, Texas. The meeting will be lumped together and ideas may or may not be identified as to their originator. The meetings were chaired by Steve Crocker.
これはフォール・ジョイント・コンピュータ協議会、11月16日、17日、および18日のヒューストン(テキサス)での一連の3つのNetwork作業部会のミーティングに関するレポートです。 ミーティングは一括されるでしょう、そして、考えは彼らの創始者に関して特定されるかもしれません。 ミーティングはスティーブ・クロッカーによって議長を務められました。
The meetings began with a listing of topics of concern.
話題のリストが重要な状態でミーティングは始まりました。
1) A site or group should be designated as protocol testers. As NCP's are implemented they should be subjected to comprehensive testing by an independent group.
1) サイトかグループがプロトコルテスターとして指定されるべきです。 NCPが実行されたとき、それらは独立しているグループによる包括的なテストにかけられるべきです。
2) The Host-Host protocol needs reworking in several areas: error control, overload conditions, allocation of resources, status information, and system crash problems.
2) Host-ホストプロトコルは、いくつかの領域で作りなおす必要があります: 誤り制御、過負荷条件、リソースの配分、状態情報、およびシステムクラッシュ問題。
3) The immediate need for specification of TELNET, the third level program which allows people to pass through their local hosts and use remote hosts. TELNET must provide facilities to log in at a distant site, run programs, transmit files, and call for help. This call for help is likely to mean getting a systems programmer at the remote site "taking control" of the user console.
3) TELNET(人々が彼らのローカル・ホストを通り抜けて、リモートホストを使用する3番目の平らなプログラム)の仕様の即座の必要性。 TELNETは遠位部位でログインするために便宜を与えて、プログラムを動かして、ファイルを送って、助けを求めなければなりません。 助けのためのこの呼び出しは、ユーザコンソールについて「コントロールを取り」ながら、リモートサイトでシステム・プログラマを得ることを意味しそうです。
4) The documentation of systems on the network must become available to all sites. This is to be done by the NIC with the cooperation of the other sites. Particularly useful will be on-line documentation. It is suggested that each site have an identical hard copy device (e.g. a line printer) suitable for reproducing documents.
4) ネットワークのシステムのドキュメンテーションはすべてのサイトに利用可能にならなければなりません。 NICは他のサイトの協力でこれをすることになっています。 特に役に立つのは、オンラインドキュメンテーションでしょう。 各サイトで同じハードコピー装置(例えば、ラインプリンタ)がドキュメントを複製するのに適当になることが提案されます。
5) The use of graphics consoles on the network will require a graphics protocol. People interested in this problem should write position papers on such a protocol. A meeting may be held between the authors of such papers if sufficient interest develops. The papers should be distributed as NWG/RFC's before 1 January 71.
5) ネットワークにおけるグラフィックスコンソールの使用はグラフィックスプロトコルを必要とするでしょう。 この問題に興味を持っている人々はそのようなプロトコルに関する方針書を書くべきです。 十分な関心が発生するなら、会合がそのような書類の作者で行われるかもしれません。 書類は、1971年1月1日以前NWG/RFCを配布するので、配布されるべきです。
6) Some sites must account for use of their computer resources, thus there must be some network accounting scheme. Sites can be categorized as Research Centers vs. Service Centers. The Service centers tend to have big machines, lots of users, and accounting problems; while the Research Centers tend to have specialized hardware, a small number of users, and no accounting at all.
6) いくつかのサイトがそれらのコンピュータリソースの使用を説明しなければなりません、その結果、何らかのネットワーク会計計画があるに違いありません。 Researchセンターズ対Serviceセンターズとしてサイトを分類できます。 Serviceセンターは、大きいマシン、多くのユーザ、および会計問題を持っている傾向があります。 Researchセンターズである間、完全に少ない数のユーザにもかかわらず、ハードウェア、説明でないのを専門にした傾向があってください。
J. Postel [Page 1] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[1ページ]RFC77ネットワーク
7) Some people are interested in the network as an object of study. In particular UCLA-Computer Science, and BBN wish to perform measurements on the network. Is it appropriate to ask the NCP to keep statistics?
7) 研究の対象としてネットワークに興味を持っている人々もいます。 特にUCLA-コンピュータScience、およびネットワークに測定を実行するというBBN願望。 統計を保つようにNCPに頼むのは適切ですか?
After this opening some discussion followed.
この後何らかの議論を開くということになりました。
It was generally felt that changes to the protocol should be made in bunches and at about six-month intervals rather than a continuous stream of small changes. Also that a lead time of three months was not over optimistic. The proposed change to the IMP-Host protocol to get rid of marking was generally approved but it will not be implemented for some time since casual changes to the protocol are undesirable. Tom O'Sullivan suggested that perhaps new and old protocols could work together, that is the new protocol would support the old one as well as provide better mechanisms where possible. Steve Crocker suggested that a new protocol might be developed as a private experimental protocol between two or three sites.
一般に、プロトコルへの変更が房にばら銭の連続した流れよりむしろおよそ6カ月の間隔で、行われるべきであると感じられました。 また、楽観的な上に3カ月の先行時間がありませんでした。 マークを取り除くIMP-ホストプロトコルへの変更案は一般に承認されましたが、プロトコルへのカジュアルな変化が望ましくないので、それはしばらく実行されないでしょう。 トム・オサリヴァンが恐らく新しい状態でそれを勧めて、古いプロトコルが一緒に働くことができて、すなわち、新しいプロトコルは、古い方を支持して、より良いメカニズムを可能であるところに提供するでしょう。 スティーブ・クロッカーは、新しいプロトコルが2か3つのサイトの間の個人的な実験プロトコルとして開発されるかもしれないことを提案しました。
It was stressed that it is necessary that the network be used to gain experience, and that we should get teletype-like console use of remote systems going before we get too involved in graphics. Perhaps the graphics protocol should be developed by a different set of people. The scheduling of a graphics protocol meeting was thus discouraged, but papers should still be written. Strong feelings were expressed in favour of first developing use of remote subsystems and file transmission instead of worrying about graphics at this stage. It was suggested that development of protocols at the higher levels be driven by applications.
ネットワークが経験を積むのに使用されるのが必要であり、グラフィックスで深みに入る前に私たちがリモートシステムのテレタイプのようなコンソール使用を行かせるべきであると強調されました。 恐らく、グラフィックスプロトコルは異なったセットの人々によって開発されるべきです。 グラフィックスプロトコルミーティングのスケジューリングはこのようにしてがっかりしましたが、論文はまだ書かれているべきです。 最初に現在のところグラフィックスを心配することの代わりにリモートサブシステムとファイルトランスミッションの使用を開発することを支持して強い意見は述べられました。 より高いレベルにおけるプロトコルの開発がアプリケーションで追い立てられることが提案されました。
Documentation will be a major concern for network users. Several people mentioned that users at their sites have already begun to inquire about the network. As Eric Harslem put it "What does the ARPA Network have to offer?" Some sites (Multics, SRI) keep system documentation on-line. It was suggested that the trillion bit store be used to keep on-line documentation of all systems.
ドキュメンテーションはネットワーク利用者に関する主要な関心事になるでしょう。 数人は、彼らのサイトのユーザが既にネットワークについて問い合わせをし始めると言及しました。 エリックHarslemがそれを表現するように「アーパネットは何を提供しなければなりませんか?」 いくつかのサイト(Multics、SRI)がオンラインにシステム文書を保管します。 1兆ビットの店がすべてのシステムのオンラインドキュメンテーションを保管するのに使用されることが提案されました。
At this point Doug Engelbart gave a presentation on the Network Information Center (NIC). The goals or services of NIC have not been well defined by anyone and have been left up to NIC to define. NIC has decided that one urgent task is to make information about the network and the host systems on the network available to users of the network. Doug has found that some people feel threatened by the revelation of their documentation inadequacy. Doug's project at SRI has built up a system that allows the user to create catalogs and indices into a collection of information. The system has a master catalog of all information files. Each user may have a number of private (or shared) catalogs. The system provides a means of examining on-line the catalogs
ここに、ダグEngelbartはNetworkインフォメーション・センター(NIC)で報告しました。 NICの目標かサービスが、だれによってもよく定義されていなくて、定義するのがNICに任せられました。 NICは、1つの緊急の仕事がネットワークのユーザにとって、利用可能なネットワークでネットワークとホストシステムの情報を作ることであると決めました。 ダグは、何人かの人々が、彼らのドキュメンテーション不適当の暴露で脅かされると感じるのがわかりました。 SRIのダグのプロジェクトはユーザがカタログとインデックスリストを情報の収集に作成できるシステムを確立しました。 システムには、すべての調査資料ファイルのマスタカタログがあります。 各ユーザには、多くの個人的で(共有される)のカタログがあるかもしれません。 システムはオンラインでカタログを調べる手段を提供します。
J. Postel [Page 2] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[2ページ]RFC77ネットワーク
and amending them. The system also provides a means to examine any information file which happens to be on-line and for creating new information files on-line.
そして、それらを修正すること。 また、システムはオンラインとオンラインで新情報ファイルを作成するためにたまたまあるどんな調査資料ファイルも調べる手段を提供します。
Several problems will delay the NIC from coming on the network. One of these is the switch from the XDS-940 to the PDP-10 (TENEX). The switch is being made because the 940 system is inadequate to handle the anticipated load. At first it was planned to offer service on the 940 and switch to the 10 when it came up, but too much effort would be required for a very small payoff.
いくつかの問題が、ネットワークをつくので、NICを遅らせるでしょう。 XDS-940からPDP-10(TENEX)までこれらの1つはスイッチです。 940システムが予期された負荷を扱うために不十分であるので、スイッチは作られています。 初めに来たとき、それは940とスイッチの上にサービスを10に提供するために計画されていましたが、あまりに多くの努力が非常にわずかな支払いで必要でしょう。
Doug explained the working of the Network Dialoge System. At each site there is a communication agent and a technical liaison officer. The agents will be trained by NIC to use the facilities of NIC to get information about the Network and other sites. The agents will acquire from NIC documents of interest to users at the local site, be able to contact NIC at a toll free number, and should have an on-line console into the network (and therefore NIC). Thus the Network Dialoge System is a network of people (the agents).
ダグはNetwork Dialoge Systemの働きについて説明しました。 各サイトに、コミュニケーションエージェントと技術渉外係がいます。 エージェントがNetworkと他のサイトの情報を得るのにNICの施設を使用するようNICによって訓練されるでしょう。 エージェントは、NICからローカル・サイトのユーザにとって、興味深いドキュメントを入手して、フリーダイヤル数でNICに連絡できて、ネットワーク(そして、したがって、NIC)にオンラインコンソールを持つべきです。 したがって、Network Dialoge Systemは人々(エージェント)のネットワークです。
Steve Crocker then brought us up to date on the status of the network. He drew a picture of what is connected and what is proposed. He discussed the level of implementation at various sites. Eric Harslem mentioned that RAND and UCSB had conducted tests of their NCP implementations last week (10 Nov 70) and that things worked well.
そして、スティーブ・クロッカーはネットワークの状態で私たちを最新の状態にしました。 彼は何が接続されているか、そして、何が提案されるかに関する絵を描きました。 彼は様々なサイトで実現のレベルについて議論しました。 エリックHarslemはRANDとUCSBが先週(1970年11月10日)のときに彼らのNCP実現のテストを行って、いろいろなことがうまくいったと言及しました。
Frank Heart announced that BBN was planning the development of a "Terminal" IMP. The Terminal IMP would support some large number of a wide range of consoles as well as provide the normal IMP functions.
フランクHeartは、BBNが「端末」のIMPの開発を計画していたと発表しました。 Terminal IMPはいくつかのコンソールを様々多く支持して、正常なIMP機能を提供するでしょう。
At this point we broke and scheduled to reconvene Tuesday morning.
ここに、私たちは中断していました。そして、火曜日の朝再召集するために、予定されています。
The Tuesday meeting started with Doug giving another pass at explaining the SRI system at a more detailed level. The basic thing to deal with is the collection. The user can query over the collection or over sub collections. The user can obtain bibliographic references of three kinds: a) full references, b) first line, c) author indexed. Information files of the collection may be on-line, in tape libraries, or only in hard copy. It is suggested that much data could be kept at other network sites, for example the trillion bit store and before that perhaps on disk at UCSB. If files are kept at other sites then the system must be able to retrieve them automatically when they are requested. The subsystem to be used is called TODAS. TODAS is an evolving program and the documentation of TODAS is inadequate. In TODAS, file are organized hierarchically, each paragraph is numbered, and it is possible to do context analysis on the text.
火曜日のミーティングは、より詳細なレベルでSRIシステムについて説明するのに別のパスを与えるダグから始まりました。 対処する基本的なものは収集です。 ユーザは収集の上、または、潜水艦の上で収集について質問できます。 ユーザは3種類の図書目録の参照を得ることができます: a) 完全な参照、b)最初の線、c) 作者は索引をつけました。 収集の調査資料ファイルはテープ・ライブラリ、またはハードコピーだけでオンラインであるかもしれません。 例えば、他のネットワークサイトにおいて、1兆ビットの店と恐らくUCSBのディスクの上のその前にデータを保つことができたことがそれだけ提案されます。 それらが要求されているとき、ファイルが他のサイトに保たれるなら、システムは自動的にそれらを検索できなければなりません。 使用されるべきサブシステムはTODASと呼ばれます。 TODASは発展プログラムです、そして、TODASのドキュメンテーションは不十分です。 TODASでは、ファイルは階層的で組織化されます、そして、それぞれのパラグラフは番号付です、そして、テキストで文脈処理をするのは可能です。
J. Postel [Page 3] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[3ページ]RFC77ネットワーク
Doug then mentioned some things about the console interaction. This raised a question about half vs. full duplex and line oriented vs. character oriented systems. The remainder of the meeting revolved around this issue.
そして、ダグはコンソール相互作用に関していくつかのことについて言及しました。 これはおよそ半分対全二重とキャラクタに対して指向の線がシステムを適応させたという疑問を引き起こしました。ミーティングの残りはこの問題を中心題目としました。
I shall try to define the terms as I understand them for purpose of clarity in the following. Half duplex is the situation where the console, a peripheral processor or some very low level software, echos the character entered. The console can not be used to input data while output is in progress. Full duplex is the situation where the character typed is echoed by software, and input can be done at the same time as output. In line oriented systems the user enters a complete line terminated by an extra sensitive and of line character (e.g. carriage return). Often the keyboard is then locked until after the next output. In character oriented systems each character the user enters is interpreted by software before it is echoed and the echo may be different from the character entered. In particular after a few character the software may guess what the user wants and complete the line for him. The following chart will be used for clarity.
明快の目的のために以下でそれらを理解しているとき、私は語を定義しようとするでしょう。 半二重はコンソール(周辺プロセッサか何らかの非常に低いレベルソフトウェア)がこだまする状況です。入れられたキャラクタ。 出力が進行している間、データを入力するのにコンソールを使用できません。 全二重はタイプされた文字がソフトウェアによって反映されて、出力と同時に入力をできる状況です。 線の指向のシステムでは、ユーザはエキストラで敏感な状態で終えられて、線キャラクタ(例えば、復帰)についてそうする完全な線に入ります。 そして、しばしば、キーボードは次の出力の後までロックされます。 キャラクタ指向のシステムでは、それが反響されて、エコーが異なるかもしれない前にユーザが入る各キャラクタはソフトウェアによって解釈されます。 特にいくつかのキャラクタの後に、ソフトウェアは、ユーザが何が欲しいかを推測して、彼のために線を完了するかもしれません。 以下の図は明快に使用されるでしょう。
| Half Duplex | Full Duplex
______________|_____________|_____________
| |
Character | |
Oriented | type1 | type2
| |
______________|_____________|_____________
| |
Line | |
Oriented | type3 | type4
| |
______________|_____________|_____________
| 半二重| 全二重______________|_____________|_____________ | | キャラクター| | 適応します。| type1| type2| | ______________|_____________|_____________ | | 線| | 適応します。| type3| type4| | ______________|_____________|_____________
It was discovered that many people don't really know where their own systems fit in this chart and are very vague about what it means to interact with a system in a different than their own. Doug stated that NIC has a system of type 2 but would try to provide service to all types of systems. The following table shows systems with their interaction type and categorization as to Research vs. Service Center.
多くの人々がそれら自身のシステムがそれら自身のと異なったaでどこでそれがシステムで相互作用することを意味することに関してこの図をうまくはめ込んで、非常にあいまいであるかを本当に知らないと発見されました。 ダグは、NICにはタイプ2のシステムがあると述べますが、すべてのタイプのシステムに対するサービスを提供しようとするでしょう。以下のテーブルは彼らの相互作用タイプと分類でResearch対Serviceセンターに関してシステムを示しています。
J. Postel [Page 4] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[4ページ]RFC77ネットワーク
System Interaction Type Categorization
システム相互作用タイプ分類
UCLA - Sigma-7 2 - char, full Research
UCLA--σ-7 2--炭、完全なResearch
UCLA - 360/91 3 - line, half Service
UCLA--360/91 3--線、半分Service
MIT - Multics 3 - line, half Service
MIT--Multics3--線、半分Service
SDC 3 - line, half ?
SDC3--半分立ち並んでいますか?
RAND 3 or 4 - line, ? ?
RAND3か4--立ち並んでください。
SRI 2 - char, full ?
SRI2--いっぱいに炭?
Al Vezza promised to study this problem and to circulate his results as an NWG/RFC. It was pointed out that line oriented systems usually allow line editing of the form "delete last character" (back space) and "delete line", however this feature does not alter their classification as to interaction type. Concern arose over what do line oriented systems expect to receive from the network for a connection acting as console input to a subsystem. Steve Crocker made the suggestion that when using a line oriented system transmission be in lines. More precisely that transmission be in strings of the following form.
アルVezzaはこの問題を研究して、NWG/RFCとして彼の結果を循環させると約束しました。 通常、指向のシステムが形式の線編集を許す線が「最後のキャラクタを削除し」て(後退)、「線を削除する」と指摘されました、この特徴が相互作用タイプに関してどのように彼らの分類を変更しないでも。 何がコンソール入力として務めている接続のために指向のシステムがネットワークから受け取ると予想する台詞をするかの上に関心はサブシステムに起こりました。 スティーブ・クロッカーは、線を使用するときシステムトランスミッションを適応させた提案が整列しているのを作りました。 より正確に、トランスミッションが以下の形式のストリングにあります。
n c1 c2 ...cn
n c1 c2…cn
where 1 <= n <= 120 (n is eight bits)
1<がn<=120と等しいところ(nは8ビットです)
and if ci is an "end of line" character then i = n
そして、ciが「行末」キャラクタであるなら、iはnと等しいです。
This suggestion was not immediately accepted and some discussion took place regarding the significance of Host-Imp-Host message boundaries. Doug brought up file transmission and the problem of finding the end of the file, which provoked more discussion. At this point the meeting broke up with a third session scheduled for 8:00 p.m. Wednesday evening.
この提案はすぐに受け入れられませんでした、そして、何らかの議論がHost悪童ホストメッセージ限界の意味に関して行われました。 ダグはファイルトランスミッションとファイルの端を見つけるという問題を持って来ました。ファイルは、より多くの議論を引き起こしました。 ここに、ミーティングは水曜日の晩の午後8時に予定されていた3番目のセッションと分かれました。
The Wednesday meeting began with the suggestion that at future xJCC's there be an official ARPA Network hotel with a block of rooms on one floor and a nearby meeting room for networkers. This suggestion was favored by all.
水曜日のミーティングは1棟の部屋がオンの公式のアーパネットホテルがネットワーカーのための1階と近くの会議室であったなら未来に、xJCCがそこにあるという提案で始まりました。 この提案はすべてによって支持されました。
Steve Crocker asked how people felt about these meetings. The general feeling was that the meetings were very useful and should occur about 3 months apart. Al Vezza pointed out that meetings this size (15 - 30 people) are good for bringing up problems but not for putting them down. Steve proposed that 3 or 4 people be designated to solve particular problems. Al responded that 3 people can't legislate. That any such
スティーブ・クロッカーは、人々がこれらのミーティングに関してどのように感じたかを尋ねました。 一般的な感じはミーティングが非常に役に立って、およそ3カ月離れて起こるべきであるということでした。 アルVezzaは、もたらすのに、このサイズ(15--30人の人)が良いミーティングがそれらを置くのではなく、問題にダウンすると指摘しました。 スティーブは、3か4人の人が特定の問題を解決するために任命されるよう提案しました。アルは、3人の人が制定できないと応答しました。 どんなそのそのようなもの
J. Postel [Page 5] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[5ページ]RFC77ネットワーク
solution must be considered in the same way as a proposal by an individual.
同様に、個人による提案であると解決策をみなさなければなりません。
Steve persuaded Peggy Karp to act as NWG/RFC editor. This is a job independent of cataloging RFC's or assigning numbers (functions now performed by NIC). The RFC editor will only categorize RFC as "hot issues", current, out of date, or superseded.
スティーブは、NWG/RFCエディタとして務めるようにペギー・カープを説得しました。 RFCのものをカタログに載せるか、または数を割り当てることの如何にかかわらずこれは仕事(機能は今や、NICで働いた)です。 RFCエディタは現在の、または、時代遅れの、または、取って代わられた「注目材料」としてRFCを分類するだけでしょう。
The subject of Logger protocol -- that is, how to get the first connection -- needs to be officially defined. NWG/RFC #66 suggests one way. Eric Harslem will revise this and send it out as proposed official protocol. Ed Myer will also send out a proposal.
Loggerプロトコルの対象(すなわち、どう最初の接続を得る)は、公式に定義される必要があります。 NWG/RFC#66は一方通行で示されます。 エリックHarslemは提案された公式のプロトコルとしてこれを改訂して、それを出すでしょう。 また、エドマイヤーは提案を出すでしょう。
Steve then opened up discussion of the topics of the previous meeting by suggesting we talk about the following: Message boundaries, half duplex vs. ull duplex, line oriented vs. character oriented, file transmission, byte counts in messages, byte sizes and transactional units. It was proposed that transactions on the command link (i.e. between NCP's) be always in multiples of eight bits. This mean that the length field in the ECO, ERP, and ERR commands will always have three low order zeroes. This was approved. Steve then proposed that connections could be established with a declared byte size and a maximum record length in bytes. Transactional units on this type of connection would be of the form
次に、私たちが以下に関して話すのを示すことによって、スティーブは前のミーティングの話題の議論を開けました: メッセージ限界、半二重、対ullデュプレックス、線はキャラクタに対して指向のファイルトランスミッション、メッセージ、バイトサイズ、および取引のユニットにおけるバイト・カウントを適応させました。 コマンドリンク(すなわち、NCPのものの間の)における取引がいつも8ビットの倍数でそうであるよう提案されました。 ECO、ERP、およびERRの長さの分野がいつも下位が合っているゼロ3を持っていると命令するこの平均。 これは承認されました。 そして、スティーブは、宣言しているバイトサイズと最大記録長でバイトで接続を確立できるだろうというよう提案しました。 このタイプの接続での取引のユニットはフォームのものでしょう。
n c1 c2 c3 ... cn
n c1 c2 c3…cn
where 0 <= n <= max record length
0<=n<=がレコード長に最大限にするところ
if n = 0 then the transactional unit acts like a semaphore. Steve suggested that we should look into the theory of information exchange, particularly along the lines of Richard Kaline (NWG/RFC #60). Perhaps for each information unit sent there should be some status response.
n=0であるなら、取引のユニットは腕木信号機のように行動します。 スティーブは、私たちが情報交換の理論を調べるべきであると示唆しました、特にリチャード・ケーライン(NWG/RFC#60)の列に沿って。 恐らく各情報に関しては、そこに送られたユニットは何らかの状態応答であるべきです。
The next question was on file transmission. In particular, how do you find the end? Frank Heart suggested that with each portion there be a flag indicating "this is not the end" until in the last portion the flag is switched to indicate "this is the end". Eric Harslem suggested that each portion should have an "opcode" field, a length field, and the text which is length bits (bytes?) long. This appears to be like the data types proposed at the Lincoln Lab meeting last spring. Ed Myer proposed that two connections be used, one for the file transmission and the other to control it. The file control connection would specify the data connection and indicate that transmission as about to start. After the sender had completed the file transmission he would send on the file control link the total number of bits sent. The receiver would then know how many bits to receive and exactly where the end of the file should be. Bob Metcalfe was concerned that some of the proposals mixed
ファイルトランスミッションには次の質問がありました。 特に、あなたはどのように端を見つけますか? フランクHeartは、各部分がそこにあるそれが旗が「これは終わりです」と示すために語尾で切り換えられるまで「これは終わりではありません」と示す旗であると示唆しました。 エリックHarslemは、各部分には"opcode"分野、長さの分野、およびテキストが長さの長さビットである(バイト?)あるべきであると示唆しました。 これは去年の春にリンカーンのLabミーティングで提案されたデータ型に似ているように見えます。 エドマイヤーは、2つの接続が使用されるよう提案して、ファイルトランスミッションとコントロールへのもう片方のための1つはそれです。 ファイルコントロール接続は、始まろうとしているほどデータ接続を指定して、そのトランスミッションを示すでしょう。 送付者がファイルトランスミッションを終了した後に、彼はビットの総数が送ったファイルのコントロールリンクを転送するでしょう。 そして、受信機はいくつのビットを受け取るか、そして、ファイルの端がちょうどどこにあるべきであるかを知っているでしょう。 ボブメトカルフェは提案のいくつかが混入したことを心配していました。
J. Postel [Page 6] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[6ページ]RFC77ネットワーク
control information with data and felt that perhaps this mixing should be avoided.
恐らく、この混合が避けられるべきであるというデータとフェルトがある情報を制御してください。
Steve asked if anybody could suggest an advisor we might talk about these problems. Bob Metcalfe suggested Anatol Holt. Bob Sundberg suggested George Mealy. Eric Harslem and Peggy Karp suggested that people who worked on the COIN System might be helpful. Frank Heart suggested that no one has solved these problems.
スティーブは、だれかが私たちがこれらの問題に関して話すかもしれないアドバイザーを勧めることができるかどうか尋ねました。ボブメトカルフェはアナトール・ホルトを示しました。 ボブSundbergはジョージMealyを勧めました。 エリックHarslemとペギー・カープは、COIN Systemに勤めた人々が助けになるかもしれないと示唆しました。 フランクHeartは、だれもこれらの問題を解決していないと示唆しました。
Steve proposed that Service Centers offer line oriented interaction with no echoing of the input. Any simple editing (e.g. back space) would be done at the using site. Ed Meyer suggested that there be official protocols for both line oriented and character oriented interaction. Steve promised to write a NWG/RFC clarifying the issues and laying out the arguments on full transactions, byte counts, and accumulating data on the receive side.
スティーブは、Serviceセンターズ申し出線が入力をまねないで相互作用を適応させたよう提案しました。 使用サイトでどんな簡単な編集(例えば、後退)もするでしょう。 両方のための公式のプロトコルが線指向していたなら、エド・マイヤーはそこでそれを勧めました、そして、キャラクタは相互作用を向けました。 スティーブが、問題をはっきりさせて、完全な取引、バイト・カウント、および蓄積しているデータの進行中の議論を広げるNWG/RFCに書くと約束した、側を受け取ってください。
It was felt that these were hard problems that needed more thought. Thus the meeting was adjourned with the request that people circulate any ideas or proposals as NWG/RFC's. Ed Myer took notes and agreed to also prepare a NWG/RFC summarizing these meetings.
これらが以上を考える必要があった難問であると感じられました。 したがって、ミーティングは人々がNWG/RFCのものとしてどんな考えや提案も循環させるという要求で休会されました。 エドマイヤーは、メモを取って、また、これらのミーティングをまとめるNWG/RFCを準備するのに同意しました。
J. Postel [Page 7] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[7ページ]RFC77ネットワーク
Network Meeting Attendance List 16 - 18 Nov. 70 Houston
ネットワークミーティング出席リスト16--18 Nov. 70ヒューストン
Name Site Sessions
名前サイトセッション
1. Dick Benjamin MITRE 1
1. ディックベンジャミンMITRE1
2. Jack Bouknight Illinois - CAC 1,2
2. ジャック・Bouknightイリノイ--CAC1、2
3. Al Cocanower MERIT 1,3
3. アルCocanower MERIT1、3
4. Steve Crocker UCLA - SPADE 1,2,3
4. スティーブ医者UCLA--すき1、2、3
5. Doug Engelbart SRI - ARC 1,2,3
5. ダグEngelbart SRI--アーク1、2、3
6. Wayne Fischer MERIT 3
6. ウェインフィッシャーMERIT3
7. Richard Greenblatt MIT - AI 1
7. リチャードグリーンブラットMIT--AI1
8. Eric Harslem RAND 1,2,3
8. エリックHarslem RAND1、2、3
9. Frank Heart BBN 1,2,3
9. フランク心臓BBN1、2、3
10. Allen Joseph ORNL 1
10. アレンジョゼフORNL1
11. Peggy Karp MITRE 1,2,3
11. ペギーカープMITRE1、2、3
12. William Kehl UCLA - CCN 1
12. ウィリアムケールUCLA--CCN1
13. Bob Long SDC 1,2,3
13. ボブの長いSDC1、2、3
14. Jim Madden Illinois - CAC 1,2
14. ジムはイリノイを怒らせます--CAC1、2
15. Bob Metcalfe MIT - DM 1,3
15. ボブメトカルフェMIT--DM1、3
16. Edwin Myer MIT Multics 1,2,3
16. エドウィンマイヤーMIT Multics1、2、3
17. Ari Ollikainen UCLA - SPADE 1,2,3
17. アリOllikainen UCLA--すき1、2、3
18. Tom O'Sullivan Raytheon 1,2,3
18. トムオサリヴァンレイセオン1、2、3
19. Jon Postel UCLA - SPADE 1,2,3
19. ジョンポステルUCLA--すき1、2、3
20. Chris Reeve MIT - DM 1,3
20. クリス奉行MIT--DM1、3
J. Postel [Page 8] RFC 77 Network Meeting Report 20 November 1970
J。 レポート1970年11月20日に間に合うポステル[8ページ]RFC77ネットワーク
Network Meeting Attendance List 16 - 18 Nov. 70 Houston
ネットワークミーティング出席リスト16--18 Nov. 70ヒューストン
Name Site Sessions
名前サイトセッション
21. Tijaart Schipper UCLA - CCN 1
21. TijaartシペールUCLA--CCN1
22. Michael Sher Illinois - CAC 1
22. マイケル・シェール・イリノイ--CAC1
23. Bob Sundberg Harvard 1,2,3
23. ボブSundbergハーバード1、2、3
24. Hal Van Zoeren CMU 1,2,3
24. ハルバンZoeren米カーネギーメロン大学1、2、3
25. Albert Vezza MIT - DM 1,2,3
25. アルバートVezza MIT--DM1、2、3
26. Alfred Vorhaus MITRE 1
26. アルフレッドVorhaus MITRE1
27. Clark Weissman SDC 1
27. クラークワイズマンSDC1
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gottfried Janik 02/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ゴットフリート・ジャニク02/98によるオンラインRFCアーカイブへの]
J. Postel [Page 9]
J。 ポステル[9ページ]
一覧
スポンサーリンク
