RFC82 日本語訳

0082 Network Meeting Notes. E. Meyer. December 1970. (Format: TXT=38023 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                               Edwin W. Meyer, Jr.
Request for Comments #82                                MIT Project MAC
Network Information Center #5619                        December9, 1970

#82MITプロジェクトMACがインフォメーション・センター#5619 12月9日、1970をネットワークでつなぐというコメントのためにワーキンググループのエドウィン・W.マイヤー、Jr.Requestをネットワークでつないでください。

                         Network Meeting Notes

ネットワークミーティング注意

   The following summary was transcribed from notes I took at three
   network meetings held in Houston during the 1970 Fall Joint Computer
   Conference.  Although I have tried to be objective, unavoidably these
   notes present a biased view of the meetings.  This is due in part to
   my preoccupation with certain topics and possible misunderstanding of
   various discussions.  While I have tried to accurately paraphrase the
   statements of the attendees, the import of some may have been
   twisted.

以下の概要は私が1970年のフォール・ジョイント・コンピュータ協議会の間にヒューストンで行われる3回のネットワーク会合で取ったノートから転写されました。 私は客観的になろうとしましたが、やむを得ず、これらの注意はミーティングの偏見を提示します。 様々な議論のある話題と可能な誤解によってこれは私の先取の一部ためです。 私が正確に出席者の声明について言い換えようとした間、いくつかの輸入はねじられているかもしれません。

                        Attendees of Monday Meeting

月曜日に会う出席者

   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

ディックベンジャミン斜め継ぎジャックBouknight UI-CACアルCocanower MIRUTスティーブ医者UCLAパン生地Engelbart様のリチャードグリーンブラットMIT-MACエリックHarslem底ならし革フランク心臓BBNアレンジョゼフORNL(オークリッジ)ペギー・カープ・MITREウィリアムB; ケールUCLAボブLong SDCジムMadden UI-CACボブメトカルフェMIT-MACエドウィンマイヤーMIT-MACアリOllikainen UCLAトムオサリヴァンレイセオンジョンポステルUCLAクリスReeve MIT-MAC Tjaartシペールユーカル-CCNマイケルS.シェールUI-CACボブSundbergハーバードハルバンZoeren米カーネギーメロン大学アルバートVezza MIT-MACアルフレッドH.Vorhaus MITREクラークワイズマンSDC

Meyer                                                           [Page 1]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[1ページ]RFC82ネットワークミーティングは1970年12月に注意します。

                              Network Meeting
                         8:05 PM Monday, 11/16/70

月曜日、11/16/70にミーティング午後8時5分をネットワークでつないでください。

   Crocker: Not everybody is here, so lets talk until more people get
      here.  is everybody satisfied with the agenda in my announcement ?

クロッカー: より多くの人々がここに到着するまで、みんなは、ここにいるので、話をさせるというわけではありません。私の発表における議題に、満足していますか?

   Meyer: We should talk about logger protocol.  Operational usage of
      the net- work, as opposed to experiments, depends on its
      implementation.

マイヤー: 私たちはきこりのプロトコルに関して話すべきです。 実験と対照的に、ネットの仕事の操作上の用法は実現によります。

   Introductions to all around.

序論、全体に。

   Crocker: I have an agenda, but want suggestions for topics.

クロッカー: 私は、議題を持っていますが、話題のための提案が欲しいと思います。

      1)  I will make introductory remarks.
      2)  I will list topics of concern.
      3)  Englebart will talk about the Network Information Center
      4)  I  will review the status of sites.

1) 私は前置きをするつもりです。 2) 私は関心の話題を記載するつもりです。 3) EnglebartはNetworkインフォメーション・センター4)に関して話すでしょう。 私はサイトの状態について調査するつもりです。

   Introductory remarks

前置き

      1)  ARPA will not pay for the coffee and pastry being served, so
          please chip in to help me pay for it.
      2)  I am going to devote full time to network coordination in an
          official capacity.  My goals are: (a) to build up usability of
          the network.  (b) to establish protocol levels, (c) ?

1) ARPAが出されるコーヒーとペストリーの代金を支払わないので、私がそれの代価を払うのを助けるのを出し合ってください。 2) 私は公式の立場でネットワークコーディネートにフルタイムをささげるつもりです。 私の目標は以下の通りです。 (a) ネットワークのユーザビリティを確立するために。 (b) プロトコルレベル、(c)を設立するために ?

   Areas of importance

重要な領域

      1)  Some site of coalition of sites should prepare a method by
          which a site's NCP could be checked out.
      2)  Reworking of NCP protocol.  Some issues could be solved
          better:  (a) error control, (b) flow control, (c) overloading
          - loosing network states, (d) simplification and relayering of
          protocol.
      3)  Telnet system  console interaction, or logger protocol.  How
          to get into the system and how to get help when in trouble.
      4)  Documentation of individual hosts.  Network Info Center
          involved.  Perhaps each site could be provided with a
          facsimile device.
      5)  More sophisticated consoles, particularly graphics consoles,
          to be attached through network.  There should be a working
          group to formulate and workout a format for handling
          sophisticated consoles.  There will be a graphics meeting in
          January in Colorado or Utah.  The price of admission is to
          write a proposal.  I expect up to 30 people.  I will pick a
          small subset to develop specifications.

1) サイトの連合のいくつかの場所がサイトのNCPを調べることができるだろう方法を準備するべきです。 2) NCPを作りなおすのは議定書を作ります。 より一層いくつかの問題を解決できました: (a) 誤り制御、(b)フロー制御、(c)積みすぎ--プロトコルのネットワーク州、(d)簡素化、および「再-レイヤ」を発射します。 3) telnetシステム操作卓相互作用、またはきこりのプロトコル。 どうシステムに入るか、そして、どう得るかは、困ったことになるのを助けます。 4) 個々のホストのドキュメンテーション。 かかわるInfoセンターをネットワークでつないでください。 恐らく各サイトにファクシミリ装置を提供できました。 5) より精巧なコンソール、特にネットワークを通して付けられるべきグラフィックスコンソール。 そこでは定式化するワーキンググループと練習が精巧なコンソールを扱うための形式であるなら。 グラフィックス会議は1月にコロラドかユタで開催されるでしょう。 入場料は提案を書くことです。 私は最大30人の人を予想します。 私は、仕様を開発するために小さい部分集合を選ぶつもりです。

Meyer                                                           [Page 2]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[2ページ]RFC82ネットワークミーティングは1970年12月に注意します。

      6)  Accounting - In the 2nd half of 1971 more sites will come on
          where accounting is important. (They want to send bills.)
          Larry Roberts says that there will be a kind of banking system
          with bills passed around.  Two types of sites: billing sites,
          and free but limited access research sites.  I see no
          fundamental problems.  What happens when a research site talks
          to a billing site? I think it is do-able.
      7)  Measurements - the network is a tool, but it is also a model
          that is better than a simulation package.  Various people want
          to make measurements.  This could be supported by keeping
          statistics in NCP's What about increasing the NCP's to include
          these?

6) 会計--半分の2番目の1971年に、より多くのサイトが会計が重要であるところで来るでしょう。 (彼らは請求書を送りたがっています。) ラリー・ロバーツは、請求書が回されている一種のバンキングシステムがあると言います。 2つのタイプのサイト: 支払いサイト、および自由な、しかし、限られたアクセス研究サイト。 私はどんな基本的な問題も認めません。研究サイトが支払いサイトと話すとき、何が起こりますか? 私は、それがするできると思います。 7) 測定値--ネットワークはツールですが、また、それはシミュレーションパッケージより良いモデルです。 様々な人々は測定をしたがっています。 これらを含むようにNCPのものを増加させながらNCPのWhatでの統計を置くことによって、これを支持できますか?

   Long: Putting accounting and measuring into NCP's costs space.  Keep
      additions to a minimum.

長い: 会計と測定をNCPに入れるのはスペースかかります。 追加を最小に抑えてください。

   Weissman: What about scheduled availability of various systems?

ワイズマン: 様々なシステムの予定されている有用性はどうですか?

   Crocker: This has to be coordinated with each individual system

クロッカー: これは各個人能率給制で調整されなければなりません。

   ?   : What happens to connections when a system goes down?

? : 何がシステムが落ちるときの接続に起こりますか?

   Crocker: What about graphics proposals? I will write my own paper as
      a proposal.  It uses the DEC 340 as a model.  Modes assumes scope
      system a memory.  Both output-input are included in standards
      making.  I want a competent protocol to be developed out of the
      working group.

クロッカー: グラフィックス提案はどうですか? 私は提案として私自身の論文を書くつもりです。 それはモデルとして12月の340を使用します。 モードは、範囲システムがメモリであると仮定します。 ともに、出力入力は規格作成に含まれています。 私は、ワーキンググループから十分なプロトコルを開発して欲しいと思います。

   Crocker: What about documentation?

クロッカー: ドキュメンテーションはどうですか?

   Meyer: Documentation on how to use other systems are a must.  Only
      this can motivate operational use of the network.

マイヤー: どう他のシステムを使用するかに関するドキュメンテーションは絶対に必要なものです。 これだけがネットワークの操作上の使用を動機づけることができます。

   --: What about putting documents on-line at each site, or at least
      abstracts.

--: 各サイト、または少なくとも要約におけるオンラインのドキュメントを置くのはどうです。

   Crocker: What sites have documents on-line? (MIT and Harvard) How do
      the sites feel about keeping documents on some foreign system?

クロッカー: どんなサイトに、ドキュメントがオンラインでありますか? (MITとハーバード) サイトは、何らかの外国システムの上のドキュメントを保管しながら、どのように探られますか?

   Crocker: What about reworking the protocol?

クロッカー: プロトコルを作りなおすのはどうですか?

   Harslem: We have logged into the UCSB system and are debugging
      cooperatively.

Harslem: 私たちは、UCSBシステムにログインして、協力してデバッグしています。

   Harslem: We are impressed with eliminating marking and padding (per
      RFC 67).

Harslem: 私たちはマークと詰め物(RFC67あたりの)を排除するのに感動しています。

Meyer                                                           [Page 3]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[3ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Crocker: We discussed this with the sites.  Most seemed to accept it,
      but some reservations.  What about changes to the basic protocol.
      I'm Meyer has something to say.

クロッカー: 私たちはサイトとこれについて議論しました。 大部分はそれ、しかし、いくつかの予約を受け入れるように思えました。 基本プロトコルに変化するのはどうです。 私はマイヤーが言いたいことがあるということです。

   Meyer: The position at Project MAC is that at this point we are
      opposed to changes other than critical fixes.  Time spent on
      changes is time that won't be spent on developing other necessary
      and interesting protocols and systems.  And we at Multics have a
      long lead time for creation and installation of changes.

マイヤー: Project MACの位置によるここに私たちが批判的なフィックス以外の変化に反対するということです。 変化に費やされた時間は他の展開している必要でおもしろいプロトコルとシステムに費やされない時間です。そして、Multicsの私たちは変化の創造とインストールのための長い先行時間を過します。

   Weissman: I prefer to put in changes in one chunk, say at 6 month
      intervals.  rather than in bits pieces.

ワイズマン: 6カ月の間隔を置いて、私は、1つの塊における変化を入れるのを好んで、言います。. ビットがつなぎあわせるコネよりむしろ。

   O'Sullivan: Can't current and new systems work simultaneously?

オサリヴァン: 現在の、そして、新しいシステムは同時に、動作できませんか?

   Crocker: If the changes involve the IMP, no, because all IMPs want to
      operate the same system.

クロッカー: 変化がIMPにかかわるなら、すべてのIMPsが同じシステムを操作したがっているので、いいえ。

   Meyer: The feeling at M.I.T. is that to be a success, the network
      needs desperately to be used operationally.  If another year
      passes without significant operational use, it might go down the
      drain.

マイヤー: マサチューセッツ工科大学の感じはネットワークが、成功に、なるのに絶望的に操作上使用される必要があるということです。 もう1年が重要な操作上の使用なしで経過するなら、それは無駄になるかもしれません。

   --: And documentation is critical towards motivating operational
      usage.

--: そして、操作上の用法を動機づけることに向かってドキュメンテーションは重要です。

   Engelbart: Perhaps we should put off graphics several months so as
      not to delay typewriters.  Typewriters are important.

Engelbart: 恐らく、私たちは、タイプライタを遅らせないように数カ月のグラフィックスを延期するべきです。 タイプライタは重要です。

   --: But would that be sufficiently impressive for DOD people?

--: しかし、DODの人々にとって、それは十分印象的でしょうか?

   Engelbart: But if it turns out to be a can of worms in two years...

Engelbart: しかし、ターンするなら、2年間で出かけるのは、複雑な問題です…

   --: But do the two (typewriters and graphics) development groups
      interact?

--: しかし、2つ(タイプライタとグラフィックス)の開発グループが相互作用しますか?

   Vezza and Engelbart: Yes.

VezzaとEngelbart: はい。

   Crocker: Let's hear more about this.

クロッカー: これについて、より多く聞きましょう。

   Harslem: We want to be able to access files.

Harslem: 私たちはファイルにアクセスできるようになりたいです。

   Crocker: Then perhaps the graphics effort would dilute typewriter
      development.  Is it the consensus of this group that we shouldn't
      have a graphics meeting?

クロッカー: 恐らくそして、グラフィックスの努力はタイプライタ開発を希釈するでしょう。 それは私たちにはグラフィックスミーティングがあるべきでないというこのグループのコンセンサスですか?

   Vezza: Newcomers should work on graphics, not established people.
      Prohibit current people form going to this meeting.

Vezza: 新来者は人々を設立するのではなく、グラフィックスに取り組むべきです。 このミーティングに続く現在の人々フォームを禁止してください。

Meyer                                                           [Page 4]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[4ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Meyer: That would be very frustrating.

マイヤー: それは非常にいらだたしいでしょう。

   Benjamin: Why not solicit position papers (but have no meeting).

ベンジャミン: なぜ方針書に請求しませんか?(会うことを持たないでください)

   Weissman: Character transmission is easier than graphic transmission
      More experiments needed for graphics.  The lead time for
      developing a graphic protocol is much longer than for typewriters.

ワイズマン: キャラクター送信はグラフィックスに必要であるグラフィックトランスミッションMore実験より簡単です。 グラフィックプロトコルを開発するための先行時間はタイプライタよりはるかに長いです。

   Vezza: I agree.

Vezza: 私は同意します。

   Crocker: There will be more meetings in the next few days to work on
      problems of getting useful work over the network.

クロッカー: ネットワークの上に実質的な仕事を得るという問題を扱うこの数日には、より多くのミーティングがあるでしょう。

   Intermission

幕間

   9:15 PM

午後9時15分

   Crocker: Engelbart will speak on Network Information Center.

クロッカー: EngelbartはNetworkインフォメーション・センターについて演説するでしょう。

   Engelbart: NIC grew as an ad hoc thing, with no specific directives
      from ARPA.  What kinds of things were envisioned? (1)
      Sophisticated query systems, (2) Basic information about systems
      at each site.  Everyone feels very vulnerable about the state of
      documentation at his own site.  Everyone agrees: better documents
      necessary.  We see ourselves as providing the following services:
      1) collecting hard-copy material; 2) on-line querying of catalogs
      and indices of these; 3) giving access to this material.  We
      decided to go hard copy rather than on-line, perhaps on
      microfiche.

Engelbart: NICは臨時のものとしてARPAから特定の指示なしで成長しました。 どんな種類のものは思い描かれましたか? (1) 精巧な質問システム、各サイトのシステムに関する(2)基本情報。 皆は彼自身のサイトでドキュメンテーションの状態に関して非常に傷つきやすく感じます。 皆は同意します: 必要な状態でドキュメントを改善してください。 私たちは、以下のサービスを提供するのを自分達を見ます: 1) 集まっているハードコピーの材料。 2) これらのカタログとインデックスリストのオンライン質問。 3) この材料へのアクセスを与えます。 私たちは恐らくマイクロフィッシュのオンラインであるよりむしろ碁のハードコピーに決めました。

   Engelbart: As 940 was to be used for the documentation system,
      expandable as usage increase.  We are switching form a 940 to a
      10X to better expand service capacity.  Amount of capacity goes up
      considerably.  This has held up work on other facets.  A conscious
      gamble.  We are worried about getting of the ground.  We are short
      on funds for more secondary storage and are interested in using
      other hosts for tertiary storage.  The cost of implementing the
      protocol on the 940 was too high for potential gains, so it was
      given up.  Few sites would be up by January when our 940 was to be
      shipped out.

Engelbart: ドキュメンテーション・システムに中古であって、用法として拡張可能であるように、940がことであった増加してください。 私たちは切り換えがサービス容量をよりよく広げるために940対1 10Xを形成するということです。 容量の量はかなり上がります。 これは他の一面に対する作業を遅れさせました。 意識しているギャンブル。 私たちは地面を得ることが心配です。 基金で、より多くの補助記憶装置に短く、第三の格納に他のホストを使用したいと思います。 940でプロトコルを実行する費用が潜在的利益のために高過ぎたので、それはあきらめられました。 わずかなサイトが外国へ送られる私たちの940がことであった1月までに上がっているでしょう。

   Engelbart: We have created a Network Dialogue System.  This is a
      network of human agents.  At each site there is: a) technical
      communications agent (secretary) and b) a technical liaison
      person.  We are encouraging agents to talk to us and have created
      "Enterprise" phone numbers so they can talk toll free.

Engelbart: 私たちはNetwork Dialogue Systemを作成しました。 これは人間のエージェントのネットワークです。 ある各サイトで: a) 技術コミュニケーションエージェント(秘書)とb) 技術連絡の人。 私たちは、エージェントが私たちに話すよう奨励していて、彼らがフリーダイヤルで話すことができるように、「エンタープライズ」電話番号を作成しました。

Meyer                                                           [Page 5]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[5ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Engelbart: We are at first sending out a tiny kit to each agent, a
      growing collection of network reference information.  One person
      (agent) at each site is to be trained to handle the set of
      documents and retrieve information of contact another site's
      technical liaison.  This involves a public dialogue, keeping a
      record of the documents passing back and forth.  This is a sort of
      "human IMP" network, structured as follows:

Engelbart: 小さいキットからの最初の発信には各エージェント、ネットワーク参考情報の増加している収集には私たちがいます。 ドキュメントのセットを扱って、各サイトの(エージェント)が情報を検索する訓練されることになっている1人の人が別のサイトの技術連絡に連絡します。 ドキュメントに関する記録を前後に終わらせ続けて、これは公共の対話にかかわります。 これは以下の通り構造化された一種の「人間のIMP」ネットワークです:

     ________________________________
    |                                |
    |              ________________  |
    |             |   local        | |     one
    |             |   reference    | | <== site    ____________
    |             |    material    | |            (            )
    |             -----------------| |            (            )
    |                                |         => (____________)
    |                                |        ||       \\
    |                                |        ||     Other sites
    |                                |        ||         \\
    |                  ________      |        ||      ____________
    | local =====>    |        |================     (            )
    | users           |  agent |=====|===============(            )
    |       =====>    |________|     |               (____________)
    |                                |
    |________________________________|

________________________________ | | | ________________ | | | ローカル| | 1つ| | 参照| | <= サイト____________ | | 材料| | ( ) | -----------------| | ( ) | | =>(____________)| | || \\ | | || 他のサイト| | || \\ | ________ | || ____________ | ローカル=====>||================ ( ) | ユーザ| エージェント|=====|===============( ) | =====>|________| | (____________) | | |________________________________|

          1) Master collection has all material.
          2) Each local collection has a subset considered most useful.

1) マスター収集には、すべての材料があります。 2) それぞれのローカルの収集で、最も役に立つと部分集合を考えます。

   --: What about restricting access to documents?

--: アクセスをドキュメントに制限するのはどうですか?

   Engelbart: All files are public files in this system.

Engelbart: すべてのファイルがこのシステムの公共のファイルです。

   Vezza: You can send a private memo rather than use the NIC service.

Vezza: あなたは使用よりむしろ個人的なメモにNICサービスを送ることができます。

   Engelbart: The master collection contains books and other documents.
      Cataloged on-line.  Hard copy stuff can be duplicated.  For
      information that passes the value test, the service is to store,
      catalog, index, and provide access to documents.  We will support
      a number of different terminal.  We are prepared to go a long time
      with hard copy items, but can establish a hard copy to on-line
      transcription service for a price.

Engelbart: マスター収集は本と他のドキュメントを含んでいます。 オンラインでカタログに載せられます。 ハードコピーものをコピーできます。 サービスは、価値テストに合格する情報のためにドキュメントへのアクセスに格納して、カタログに載せて、索引をつけて、提供することです。 私たちは多くの異なった端末を支えるつもりです。 私たちは、長い間ハードコピー商品を伴うように準備されますが、価格のためのオンライン転写サービスにハードコピーを確立できます。

   Weissman: What about distributing OCR Selectric balls to sites?

ワイズマン: OCR Selectricボールをサイトに分配するのはどうですか?

   --: Will NIC take what is sent or actively search it out?

--: NICは送られるものを取りますか、活発にそれを捜し出すでしょうか?

Meyer                                                           [Page 6]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[6ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Engelbart: More or less what comes our way.  A system will exist in
      Spring 1971, to allow an agent to insert items into a catalog.
      The dialogue that goes on will determine which way the data base
      grows.  We are pretty sure that eventually SRI will have to charge
      because of many potential users not at primary sites seeking limit
      resources.

Engelbart: だいたい私たちのやり方に来ること。 システムは、エージェントが商品をカタログに挿入するのを許容するためにSpring1971に存在するでしょう。 先へ進む対話はデータベースが発展するどの方法を決定するだろうか。 結局、SRIは、私たちが、多くのために潜在的ユーザが原発部位探知がリソースを制限しないとかなり確実に宣言しなければならないでしょう。

   --: What about an NCP for your 10X.

--: あなたの10XのためのNCPはどうですか?

   Engelbart: If BBN's NCP is ready by February 1971, we'll use it.

Engelbart: BBNのNCPが1971年2月までに準備ができているなら、私たちはそれを使用するつもりです。

   Crocker: How do people get access?

クロッカー: 人々はどのようにアクセスを得ますか?

   Engelbart: Each site is registered.  Any person who gets in on a
      site's account has its access.  We won't worry about accounting
      until saturation occurs.  We would like to encourage use of the
      agent system to create and use a survey of resources at each site.
      Some subgroup should talk about this.

Engelbart: それぞれのサイトは登録されています。 サイトのアカウントに参加するどんな人もアクセサリーを持っています。 私たちは飽和が起こるまで会計を心配しないでしょう。 エージェントシステムの使用が各サイトでリソースの調査を創設して、使用するよう奨励したいと思います。 いくらかのサブグループがこれに関して話すべきです。

   Crocker: When can people meet to discuss this? (Tomorrow morning)

クロッカー: 人々はいつこれについて打ち合わせることができますか? (明朝)

   Engelbart: We have nice facilities for developing mailing lists,
      private bibliographies, personnel profiles, but it depends on the
      interest of the network people.

Engelbart: 私たちは展開しているメーリングリストのための良い施設を持っています、個人的な図書目録、人員プロフィールにもかかわらず、場合によりけりですネットワークの人々の関心で。

   Engelbart: Agents have been set up with MIT, UCLA, RAND, UI, Utah,
      etc.  A good percentage of sites

Engelbart: エージェントはMIT、UCLA、RAND、UI、ユタなどでセットアップされました。 良い割合のサイト

   Vezza: Many sites are sending out stuff 3rd and 4th class.  Takes too
      much time.

Vezza: 多くのサイトが、3番目にものを出して、4番目のクラスです。 あまりに多くの時間がかかります。

   Crocker: Site status report.  ILLIAC IV not to be operational until
      mid-71, on network later (72?).  Other possible sites: RADC, AWS,
      NCAR.  Currently up: UCSB, RAND.  Imminent (January 71): MIT BBN,
      Harvard, UCLA, Utah, LL, SDC.  Some percentage by end of year rest
      in January.

クロッカー: サイト現状報告。 中間の71で、オンになるまで操作上でないILLIAC IVは後の(72?)をネットワークでつなぎます。 他の可能なサイト: RADC、AWS、NCAR。 現在、上がる: UCSB、底ならし革。 差し迫る(1月71日): MIT BBN、ハーバードUCLA、ユタLL、SDC。 1月の年の休息の終わりまでに何らかの割合。

   Heart: A brand new IMP system (major change) goes in tomorrow.  Some
      more sites are thinking about coming on.  The network will grow
      consider- ably beyond what's already on board.  We too are
      interested in site resource information.  No long term interest,
      but we will put information on paper to help ARPA.

心臓: 真新しいIMPシステム(大きな変化)は明日、動きます。 それ以上のサイトが、来ると考えています。 意志が育てるネットワークはりっぱに既に車中にあるものを超えて考えます。 私たちもサイトリソース情報に興味を持っています。 しかし、長期関心がない、私たちは、ARPAを助けるために紙上の情報を置くつもりです。

   Crocker: A lot of people are yawning.  What about meeting schedules?
      During FJCC's? 1 day vs. 2 day meetings? What about dual East and
      West coast meetings?

クロッカー: 多くの人々があくびしています。 ミーティングスケジュールはどうですか? FJCCの間? 1日?対2日間のミーティング 二元的な東の、そして、西の海岸ミーティングはどうですか?

                                                          End of Meeting

ミーティングの終わり

Meyer                                                           [Page 7]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[7ページ]RFC82ネットワークミーティングは1970年12月に注意します。

                               Network Meeting
                          9:15 AM Tuesday, 11/17/70

火曜日、11/17/70にミーティング午前9時15分をネットワークでつないでください。

   Crocker: Engelbart will talk in more detail.  Later may discuss
      logger protocol and file transfer.

クロッカー: Engelbartはさらに詳細に話すでしょう。 その後、きこりのプロトコルとファイル転送について議論するかもしれません。

   Engelbart: Basic thing is a collection of documents with a catalog to
      describe it.  Entry has lots of data items, including where to
      find it.  Techniques for adding and updating entries.  We do it
      now, but would want to give capability to other sides, partly
      because we can't determine what's of value. (Displayed 3 types of
      printout.)  1) Catalog listing, by ordinal index in collection and
      NIC index.  for inventory control, finding out what's there. 2)
      Compacted format on one line. 3) Sorted by author-one line per
      entry.  We Will have procedures where an untrained user can manage
      a collection.

Engelbart: 基本的なものはそれについて説明するカタログがあるドキュメントの収集です。 エントリーには、どこでそれを見つけるかを含む多くのデータ項目があります。 エントリーを加えて、アップデートするためのテクニック。 現在それをしますが、能力を向こう側に与えたいと思うでしょう、一部私たちが、何が価値のそうであるかを決心できないので。 (3つのタイプのプリントアウトを表示します。) 1) 収集で序数のインデックスでリストをカタログに載せてください。そうすれば、NICは索引をつけます。在庫管理のために、何を見つけるかはそこにあります。 2) 1つの線に形式を圧縮しました。 3) 1エントリーあたり作者-1つの線で、分類されます。 私たち、ウィルには、未熟なユーザがa収集に対処できる手順があります。

   Meyer: How are these systems implemented?

マイヤー: これらのシステムはどのように導入されますか?

   Engelbart: We have a compiler-compiler on the 940.  Our subsystems
      are written in specialized high level language.  We are moving
      this over to the 10X.

Engelbart: 私たちは940にコンパイラコンパイラを持っています。 私たちのサブシステムは専門化している高級言語で書かれています。 私たちは10Xにこれを譲っています。

   Heart: How many people can the 10X support in rough figures?

心臓: 10Xは概算で何人の人々を支持できますか?

   Engelbart: Perhaps 100-1000 collections.

Engelbart: 恐らく100-1000の収集。

   --: Perhaps people could supply own DEC tapes for additional storage.

--: 恐らく、人々は追加格納のための自身の12月のテープを供給できました。

   Engelbart: Could, but requires on-site operator.  Slow access.  We
      don't have money for more storage, but are considering shipping
      files down to UCSB.  We provide on-line querying of on-line data.
      Willing to worry about data management, whether or not we store
      it.

Engelbart: 現場のオペレータを必要とすることができました。 遅いアクセサリー 私たちは、より多くの格納のためのお金を持っていませんが、ファイルをUCSBまで出荷すると考えています。 私たちはオンラインデータのオンライン質問を提供します。 私たちがそれを格納するか否かに関係なく、データ管理を心配することを望んでいます。

   Crocker: Please describe the various subsystems. (Description by
      Engelbart follows.)

クロッカー: 様々なサブシステムを説明してください。(Engelbartによる記述は続きます。)

   Heart: Have people tried to use it over the network?

心臓: 人々はネットワークの上でそれを使用しようとしましたか?

   Engelbart: No.  Don't have an NCP on the 940.  Decided against
      putting it in a system that is going away.  The biggest hang up is
      when 10X gets an NCP.  Bobrow developing it, but it is slipping.

Engelbart: いいえ 940に関するNCPを持たないでください。 遠ざかっているシステムにそれを入れながら、不利な判決を下されます。 10XがNCPを得る最も大きいハングが上にあります。 それを開発するBobrow、それだけが滑る予定です。

   Heart: Who is going to get at it (SRI) early?

心臓: だれが早くそれ(SRI)に達するでしょうか?

   UI: Illinois can access only SRI to begin with.

ウイ: イリノイは初めに、SRIしかアクセスできません。

Meyer                                                           [Page 8]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[8ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Postel, UCLA: We plan to use it.

ポステル、UCLA: 私たちは、それを使用するのを計画しています。

   Heart: Would be a significant task if someone would take it as a goal
      to get into Engelbart's system.

心臓: だれかがEngelbartのシステムに入るために目標としてそれをみなすなら、重要なタスクでしょう。

   MITRE: We're going to use other systems form BBN's 10X.

斜め継ぎ: 私たちは他のシステムフォームBBNの10Xを使用するつもりです。

   Engelbart: We are trying to isolate essential subsystems for people
      to use easily.  Files are organized hierarchically and will fill
      out as years go by.  Documents are referenced by pathnames.
      (Discussion of systems follows.)

Engelbart: 私たちは人々が容易に使用する不可欠のサブシステムを隔離しようとしています。 ファイルは階層的で組織化されます、そして、何年もの中詰めは過ぎるでしょうか? ドキュメントはパス名によって参照をつけられます。 (システムの議論は続きます。)

   Crocker: Row does one get into the system? (Engelbart describes entry
      sequence to TOdas.)

クロッカー: 通りは入ります。1つはシステムに入りますか? (Engelbartはエントリー系列についてTOdasに説明します。)

   Crocker: How does one get registered on the system?

クロッカー: 1つはシステムの上にどのように登録されますか?

   Engelbart: Ultimately by personal entry, but currently there is one
      user id per site.

Engelbart: 結局、個人的なエントリー、現在、1サイトあたり1つのユーザイドがあります。

   Meyer: I think we're ignoring unsolved problems in the typewriter
      interfacing.  For example, the entry sequence to TOdas, where the
      user type one or two characters and the system types out the
      remaining chars of a key word, will be frustrating to use form
      half-duplex system like Multics.  Our system will not recognize an
      input line until a new line is typed.

マイヤー: 私たちがタイプライタ連結における未解決の問題を無視していると思います。 例えば、TOdasへのエントリー系列は、Multicsのようにフォーム半二重システムを使用するためにユーザが1か2文字をタイプして、システムがキーワードの残っている雑用をタイプで打つところでいらだたしくなるでしょう。 復帰改行がタイプされるまで、私たちのシステムは入力行を認識しないでしょう。

   Various: Discussion of 1/2 duplex communication.  Brings out
      distinction between a) Full duplex systems where system echoes
      input vs. 1/2 duplex where input typed locally, and b) systems
      where each character is recognized as it is typed in vs. systems
      where entire line is recognized only after EOL char.

様々: 1/2の重複のコミュニケーションの議論。 a)の区別を持ち出します。 全二重方式入力されるところで1/2デュプレックスに対して入力されたシステムエコーがどこで局所的にタイプされたか、そして、b) 全体の線がEOLの後にだけ認識されるところでそれがシステムに対してタイプされるように各キャラクタが見分けられるシステムは焦げます。

   Crocker: Isn't Multics the only half-duplex line-oriented system on
      the net- work?

クロッカー: Multicsはネットの仕事での唯一の半二重回線指向のシステムではありませんか?

   Meyer: I can't believe this.  Don't the IBM systems operate like
      that?

マイヤー: 私はこれを信じることができません。 IBMシステムはそのように作動しませんか?

   Engelbart: We could have a 1/2 duplex interface on our system (SRI).
      Is it the Multics hardware that enforces this restriction?

Engelbart: 私たちは私たちのシステム(SRI)の上に1/2の重複のインタフェースを持つことができました。 この制限を実施するのは、Multicsハードウェアですか?

   Meyer: Yes, the input-output controller.*

マイヤー: はい、入出力制御装置、*

   ______________________________________________
   *  The Multics IO controller's typewriter adaptor is 1/2 duplex, but
   can accept break characters other than the "new line" character.

______________________________________________ * Multics IOコントローラのタイプライタアダプターは、1/2デュプレックスですが、「復帰改行」キャラクタ以外の区切り文字を受け入れることができます。

Meyer                                                           [Page 9]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[9ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Engelbart: Each system should have a preprocessor to talk with other
      systems.  We're going to put a graphics interface onto the
      network.

Engelbart: 各システムには他のシステムと話すプリプロセッサがあるはずです。私たちはネットワークに図形インターフェースを置くつもりです。

   Meyer: How do you view these interfaces? Do these adhere to some
      network standard, or ill each system construct an interface to
      you?

マイヤー: あなたはどのようにこれらのインタフェースを見ますか? これらは何らかのネットワーク規格を固く守りますか、ほとんど各システムがあなたにインタフェースを組み立てますか?

   Engelbart: Standard network protocol.

Engelbart: 標準のネットワーク・プロトコル。

   Crocker: Let's move on to other things.

クロッカー: 他のものに動きましょう。

   O'Sullivan: What about 2741's on your (CMU) 10X system.  Do you have
      serious interfacing problems? (CMU's 2741's go through a software
      package that transforms them into TTY 37's.  No serious
      difficulty.)

オサリヴァン: あなたの(米カーネギーメロン大学)10Xシステムの上の2741年代はどうですか? あなたには、重大な連結問題がありますか? (米カーネギーメロン大学の2741はそれらをTTYのもの37に変えるソフトウェアパッケージを通ります。 重大な困難がありません。)

   Various: Brief discussion on how Multics handles input.

様々: Multicsがどう入力を扱うかについての議論に事情を知らせてください。

   Sundberg, HARVARD: Out 10X can take char-oriented input, but our
      higher level subsystems prefer line-oriented input.

Sundberg、ハーバード: 出ている10Xは炭指向の入力を取ることができますが、私たちの、より高い平らなサブシステムは線指向の入力を好みます。

   --: What about the efficiency of transmitting messages through the
      network one character at a time?

--: ネットワークを通して一度に1つのキャラクタにメッセージを送る効率はどうですか?

   Crocker: There is more output, which goes packed, than input, so the
      input inefficiency is negligible.

クロッカー: より多くの出力があります、どれが行くかは入力されるより荷造りしました、したがって、入力非能率が取るにたらないです。

   Engelbart: We plan to have several different ports into our system.
      If each system had an NIC module; it could communicate with us
      without the necessity of a login.  We prefer a batch-type system,
      where a site sends spooled batch of edit requests, gets stuff
      back, and frees ports.  The typewriter transmission by line
      problem could be handled similar to spooled-up requests.  We
      encourage spooling, but will support interactive users.  We can
      support more batch than inter- active people.

Engelbart: 私たちは、いくつかの異なったポートを私たちのシステムに持っているのを計画しています。 各システムにNICモジュールがあったなら。 それはログインの必要性なしで私たちにコミュニケートするかもしれません。 私たちはバッチ型システムを好みます。そこでは、サイトは、編集要求のスプールさせられたバッチを送って、ものの後部を得て、ポートを解放します。 スプールさせられた要求と同様の状態で線問題によるタイプライタトランスミッションを扱うことができました。 私たちは、スプールするよう奨励しますが、対話的なユーザを支持するつもりです。 私たちは相互活発な人々より多くのバッチを支持できます。

   *  The Multics IO controller's typewriter adaptor is 1/2 duplex, but
   can accept break characters other than the "new line" character.

* Multics IOコントローラのタイプライタアダプターは、1/2デュプレックスですが、「復帰改行」キャラクタ以外の区切り文字を受け入れることができます。

   Vezza: Do people feel that the full and 1/2 duplex issue is a
      problem? Let all the people go back and find out about this.
      M.I.T. with a full and 1/2 duplex system 20 feet apart can help
      here.

Vezza: 人々は、完全、そして、1/2重複の号が問題であると感じますか? すべての人々に戻って、これを見つけさせてください。 完全、そして、1/2二重化システムが20フィート離れてあるマサチューセッツ工科大学はここで助けることができます。

   O'Sullivan: There seem to be 2 issues: (1) echoing (full duplex) vs.
      1/2 duplex. (2) single character vs. full line transmission.

オサリヴァン: 2冊はあるように思えます: (1) 1/2に対して反響している(全二重)デュプレックス。 (2) 実線トランスミッションに対してキャラクタを選抜してください。

Meyer                                                          [Page 10]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[10ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Crocker: Two definitions: Serving host - provides computation; using
      host - parasitic, manages user's terminal.  This view network
      usage as a link between local user and foreign server.

クロッカー: 2つの定義: ホストに役立ちます--計算を提供します。 ホストを使用します--寄生的である、ユーザの端末を管理します。 地元のユーザと外国サーバとのリンクとしてのこの視点ネットワーク用法。

   Vezza: What about 1/2 duplex - full duplex interconnection if some
      full duplex systems echo other than what was input.

Vezza: 1/2デュプレックス。--どうであり、何を除いて、いくつかの全二重方式が反響するかなら、全二重インタコネクトは入力であったか。

   Crocker: Two independent possibilities.  Let's diagram:

クロッカー: 2つの独立している可能性。 以下を図解しましょう。

                        |     "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         |                 |                   |
            ____________|_________________|___________________|

| "2741" | "33, 35, 37" | | 配線してください。| 2は分離します。| | ローカルエコー| すべてを裏打ちします。| | コンピュータはそうします。| 印刷されます。| | エコーでない| | ____________|_________________|___________________| 過程| 困難| X| それぞれ| | | キャラクタ| | | ____________|_________________|___________________| 過程| X| 簡単| 唯一| | | EOL| | | ____________|_________________|___________________|

   Crocker: I claim there are really only two possibilities (marked by
      X's).

クロッカー: 私は、2つの可能性(Xのもので、マークされる)しか本当にないと主張します。

   Postel: Why about a system where echoing is done at such a low level
      that it can't be deleted.

ポステル: 反響するところでそれを削除できないくらいの低レベルでシステムに関する理由をします。

   Crocker: If so, it's like non-echoing.

クロッカー: そうだとすれば、それは非反響に似ています。

   Van Zoeren: Out system thinks we have full duplex TTY's, but our
      2741's are attached via a software transformation box.

Zoerenをバンに積んでください: 出ているシステムは、私たちには全二重TTYのものがあると思いますが、私たちの2741はソフトウェア変化箱を通して付けられています。

   Meyer: What happens when non-echoing systems are attached to echoing
      systems via the network? I type my input line, then the echoing
      system responds with my input, then some output.  My system can't
      filter this because there is no way of differentiating echo from
      output.

マイヤー: 非反響システムがネットワークを通して反響システムに取り付けられるとき、何が起こりますか? 私は入力行をタイプします、次に、反響システムが私の入力で反応して、次に、何かが出力です。 出力とエコーを区別する方法が全くないので、私のシステムはこれをフィルターにかけることができません。

   Crocker: This isn't necessarily a bad thing.  I type command
      abbreviation to SRI; then next output line is an expanded form of
      the input command.

クロッカー: これは必ず悪いものであるというわけではありません。 私はコマンド略語をSRIにタイプします。 そして、次の出力線は入力コマンドの拡充形です。

   Meyer: Our goal should be one common protocol rather than a bunch of
      kludgy schemes to implement communication between specific pairs
      of hosts.

マイヤー: 私たちの目標はホストの特定の組のコミュニケーションを実行する多くのkludgy計画よりむしろ1つの一般的なプロトコルであるべきです。

Meyer                                                          [Page 11]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[11ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Long, SDC: We prefer to receive a full line fed through the network.

SDC、切望してください: 私たちは、ネットワークを通して与えられた実線を受け取るのを好みます。

   Crocker: Let's differentiate between research centers and service
      centers.  Only the service centers are concerned with a half-
      duplex interface.  (lower left hand X on chart).  These include
      SRI, BBN, Multics.

クロッカー: リサーチセンターとサービスセンターを区別しましょう。 サービスセンターだけが半分デュプレックスインタフェースに関係があります。 (図の左下の手X。) これらはSRI、BBN、Multicsを含んでいます。

   O'Sullivan: What about research center?

オサリヴァン: リサーチセンターはどうですか?

   Crocker: They can call up service centers, but may themselves be hard
      to use.

クロッカー: それら、しかし、上がセンターにサービスを提供するという缶の要求がそうするかもしれない、自分たち、使用しにくくなってください。

   Illinois: Then the ILLIAC IV will have to be half-duplex.

イリノイ: そして、ILLIAC IVは半二重にならなければならないでしょう。

   Postel: I think half-duplex, line-oriented is weaker (than full-
      duplex, character-oriented protocol).

ポステル: 私は半二重を考えて、線指向であることは、柔弱(完全な重複の、そして、キャラクタ指向のプロトコルより)以上です。

   Sundberg: Harvard can go either way, but prefer line-oriented system.

Sundberg: ハーバードはいずれにせよ行くことができますが、線指向のシステムを好んでください。

   Engelbart: Graphics terminals harder to put on network because of
      non-standard input.

Engelbart: より置きにくいグラフィックス端末は標準的でないので入力をネットワークでつなぎます。

   Harslem: You're thinking of the keys as function keys rather than
      input keys.

Harslem: あなたは入力キーよりむしろファンクションキーとしてキーを考えています。

   Engelbart: I'm worried about people who want to use graphics.

Engelbart: 私はグラフィックスを使用したがっている人々が心配です。

   O'Sullivan: We haven't spoken to the problem of what kind of protocol
      should be established.

オサリヴァン: 私たちはどういうプロトコルが確立されるべきであるかに関する問題に話していません。

   Crocker: That's not a difficult technical thing.  We'll get to that
      later and make a decision.

クロッカー: それは難しい技術的なものではありません。 私たちは、後でそれを始めて、決定するつもりです。

   Meyer: I'm not authorized to make any decision.  I'm to report back
      to the MAC group.

マイヤー: 私がどんな決定もするのに権限を与えられません。 私はMACグループに報告を持ちかえることになっています。

   Crocker: Okay.  Then, a proposal, to be accepted through the normal
      mechanism.  Intermission

クロッカー: オーケー。 次に、提案、正常なメカニズムを通して受け入れるために。 幕間

   Crocker: I will propose how to handle X'ed boxes, ignoring hard and
      ease boxes:

クロッカー: 私は困難、そして、容易さ箱を無視して、どうX'ed箱を扱うかを提案するつもりです:

      Line-Oriented Input - 8 bit ascii including End of Line character:

線で指向のInput--8は線キャラクタのEndを含むASCIIに噛み付きました:

              n, C1,...,Cn;

n、C1…Cn。

                 Cn=EOL

Cn=EOL

Meyer                                                          [Page 12]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[12ページ]RFC82ネットワークミーティングは1970年12月に注意します。

                 120>n>>_1 n is the character count in an 8-bit field.
      The character count precedes the line so as to give the software
      system the same efficiency as the hardware system, the computer
      doesn't have to scan for the EOL.

120>n>>_、1、n、中のキャラクタカウントは8ビットの分野ですか? キャラクタカウントはハードウェアシステムと同じ効率のソフトウェア・システムを与えるために線に先行します、とコンピュータがEOLのためにスキャンする必要はありません。

   Vezza: Don't you get the length information with the IMP message?

Vezza: あなたはIMPメッセージがある長さの情報を得ませんか?

   Crocker: My philosophy is that IMP message boundaries should be
      completely invisible.

クロッカー: 私の哲学はIMPメッセージ限界が完全に目に見えないはずであるということです。

   Long: I object to splitting typewriter messages into two separate
      chunks.

長い: 私はタイプライタメッセージを2つの別々の塊に分けるのに反対します。

   Crocker: What is your objection, 1) Lines beginning on message
      boundaries or 2) message not beginning on a line boundary?

クロッカー: あなたの異論、1は)何ですか? メッセージ限界か2で始まる線) 線限界で始まらないメッセージ?

   Long: Both.

長い: ともに。

   Engelbart: Each host should write an interface to handle the most
      common terminal types.

Engelbart: 各ホストは、最も一般的な端末のタイプを扱うためにインタフェースを書くべきです。

   Crocker: The official protocol does not allow IMP message boundaries
      to have any significance.

クロッカー: 公式のプロトコルで、IMPメッセージ限界は少しの意味も持つことができません。

   Engelbart: I don't want to worry about IMP message boundaries.  The
      network should be invisible (at this level).

Engelbart: IMPメッセージ限界を心配したいと思いません。 ネットワークは目に見えないはずです(このレベルにおける)。

   Vezza, Long: We'll concede, we'll go along.

Vezzaで、長い: 私たちは譲歩するつもりであり、進むつもりです。

   Meyer: I'd like to change the restriction.  The last character in the
      line packet need not be an EOL (as when an output does not advance
      to a ne line), but an EOL cannot appear in the midst of a packet.

マイヤー: 制限を変えたいと思います。 線パケットにおける最後のキャラクタはEOLである必要はありません(出力がNe線に達しない時としての)が、EOLはパケットの中に現れることができません。

   Van Zoeren: I don't like this restriction.

Zoerenをバンに積んでください: 私はこの制限が好きではありません。

   Meyer: Count tells us that any EOL is at the end, we need not scan.

マイヤー: 私たちは、カウントが、いくらかのEOLが終わりにあると私たちに言うのをスキャンする必要はありません。

   Crocker: The EOL is the character that tells the system to take
      action.

クロッカー: EOLは行動を取るようにシステムに言うキャラクタです。

   Harslem: Our system has 46 function keys, not just one EOL.

Harslem: 私たちのシステムには、ちょうど1EOLではなく、46個のファンクションキーがあります。

   Crocker: How about if C, E {breakset}; i=n.  This s more complex,
      because have to transmit a breakset.  I'll propose this in a
      moment.  How about this: message oriented (1/2 duplex) connection

クロッカー: EがCであるなら、breaksetされるのは、どうです。 i=n。 このs、 より複雑である、breaksetを伝えるために、持っています。 私は見る間にこれを提案するつもりです。 これはどうです: メッセージは接続を適応させました(1/2デュプレックス)。

Meyer                                                          [Page 13]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[13ページ]RFC82ネットワークミーティングは1970年12月に注意します。

      between User and Server hosts for console interaction.  Local
      echo, no server echo.  This is for line oriented service systems.
      These are slight generalizations of Multics conventions.

コンソール相互作用のためのUserとServerホストの間で。 ローカルエコー、サーバエコーがありません。 これは線がサービス・システムを適応させたからです。これらはMulticsコンベンションのわずかな一般化です。

   Meyer: I'm sure other systems other than Multics use it.  It's not as
      bad as you seem to think.

マイヤー: 私はMultics以外の他のシステムがそれを使用するのを確信しています。 思うのはあなたが見えるほど悪くはありません。

   Engelbart: Upper management should know that it is bad.

Engelbart: 上側の経営者側は、それが悪いのを知るべきです。

   Meyer: That's not clear.  There are efficiency questions.

マイヤー: それは明確ではありません。 効率質問があります。

   Van Zoeren: I don't want to have to transmit files this way.

Zoerenをバンに積んでください: 私は、この道にファイルを送らなければならなくて欲しいと思いません。

   Crocker: This is for consoles, not file transmission.

クロッカー: これはファイルトランスミッションではなく、コンソールのためのものです。

   Engelbart: We need a unified scheme for data transmission.

Engelbart: 私たちはデータ伝送の統一された計画を必要とします。

   O'Sullivan: (For consoles) we're to devise a way to tell a system
      where its interrupt should be simulated.

オサリヴァン: (コンソールのための) 私たちは中断がどこでシミュレートされるべきであるかをシステムに言う方法を工夫することになっています。

   Crocker: There is a general problem of data transmission for tapes
      and files.

クロッカー: テープとファイルのためのデータ伝送の一般的問題があります。

   O'Sullivan: But we have the specific problem of implementing
      typewriter communications.

オサリヴァン: しかし、私たちには、タイプライタコミュニケーションを実行するという特定の問題があります。

   Engelbart: But what we need is a general way of sending stuff through
      the network (so it is invisible) and have the host interpret it as
      it wants to.

Engelbart: しかし、私たちが必要とするものはネットワークを通してものを送る一般的な方法(したがって、それは目に見えません)です、そして、解釈したがっているとき、ホストにそれを解釈させてください。

   Meyer: There should be one console interface for the network, not
      several at each site.

マイヤー: 数個ではなく、ネットワークのための1つのコンソールインタフェースが各サイトにあるべきです。

   Crocker: This problem is perhaps overblown.

クロッカー: この問題は恐らく大げさです。

   Engelbart, Meyer, O'Sullivan: Discussion about supporting specific
      terminal types.

Engelbart、マイヤー、オサリヴァン: 特定の端末のタイプを支持するのと議論。

   Engelbart: I'll draw a graph of systems vs. terminal type.  The
      intersection of a system and a terminal that is accepted by that
      system is marked by a dot.  Network communication problem is one
      of finding a terminal at local host that is also supported at the
      target host.

Engelbart: 私はシステム対端末のタイプのグラフを描くつもりです。 そのシステムによって受け入れられるシステムと端末の交差点はドットによって示されます。 ネットワーク意思疎通の問題はまた、目標ホストで支持されるローカル・ホストで端末を見つけるものです。

Meyer                                                          [Page 14]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[14ページ]RFC82ネットワークミーティングは1970年12月に注意します。

              _____|_____|_____|_____|_____
                   |     |     |     |
       systems_____|_____|_____._____|_____
                   |     |     |     |
              _____|_____._____|_____|_____
                   |     |     |     |
              _____|_____|_____|_____|_____
                   |     |     |     |
                   terminals

_____|_____|_____|_____|_____ | | | | システム_____|_____|_____._____|_____ | | | | _____|_____._____|_____|_____ | | | | _____|_____|_____|_____|_____ | | | | 端末

   Crocker: There is a general problem of a subsystem reacting to input.
      Let's propose that input should be sent as a full message or in
      multiples of 8-bits.

クロッカー: サブシステムが反応するという入力する一般的問題があります。 入力が8ビットについて完全なメッセージか倍数で送られるべきであるよう提案しましょう。

   Vezza: Are we constraining too much?

Vezza: 私たちはあまりに多くを抑制していますか?

   Meyer: Why is it necessary to have 8-bit multiples?

マイヤー: 8ビットの倍数を持つのがなぜ必要ですか?

   Crocker, Engelbart: Okay throw that away.

クロッカー、Engelbart: そんなに遠くで一投を承認してください。

                                                   End of Second Meeting

第2ミーティングの終わり

                               Network Meeting
                         8:20 PM Wednesday, 11/18/70

水曜日、11/18/70にミーティング午後8時20分をネットワークでつないでください。

   (The following notes are greatly condensed and attempt only to
      present the
   major themes discussed at this meeting.)

(以下の注意は、大いに凝縮されて、単にこのミーティングで議論した主要なテーマを提示するのを試みます。)

   Crocker: Let's meet at the SJCC with more prior organization.  Let's
      have several day meetings at 2-3 month intervals.  We've got a lot
      of good discussion on the next level protocol.  Let a subgroup
      work if out.

クロッカー: SJCCでは、より多くの先の組織と共に会いましょう。 2-3カ月の間隔を置いて、いくつかの日のミーティングを持ちましょう。 私たちは次の平らなプロトコルについての多くの良い議論をします。 出ているなら、サブグループを働かせてください。

   (Harslem volunteers to redraft the logger protocol proposed in RFC
      66.  Meyer will revise proposal in RFC 46.)

Harslemは、RFC66で提案されたきこりのプロトコルを書き直すのを買って出ます。(マイヤーはRFC46での提案を改訂するでしょう。)

   Meyer: Let's go back, discuss these issues, write proposals.  Later
      we have an open meeting to decide on a formal proposal.

マイヤー: 戻ろう、これらの問題について議論してください、そして、提案を書いてください。 その後、私たちには、正式な提案を決める開いているミーティングがあります。

   Crocker: Small group is better, perhaps I'll pick a subset.

クロッカー: 小さいグループが、より良い、恐らく、私は部分集合を選ぶつもりです。

Meyer                                                          [Page 15]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[15ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Vezza: It's true that things aren't settled here.  Major proposals
      should be on paper preparatory to a meeting.  We can't legislate
      what a small group does.  It has no more authority than an
      individual.

Vezza: ここでことをしないのは本当です。 主要な提案は紙上でそうであるべきです。ミーティングに、準備です。 私たちは小さいグループがすることを制定できません。 それには、個人が権威でないことのようなどんな権威もありません。

   (Karp of MITRE volunteers to produce a bibliography of network
      documents, perhaps by January.)

(MITREのカープは、恐らく1月までにネットワークドキュメントの図書目録を製作するのを買って出ます。)

   (Who has implemented logger protocol? UCSB and UCLA mod 91 have or
      are planning.  SDC may have it by 21/1, found it awkward, willing
      to change.)

(だれがきこりのプロトコルを実行しましたか? モッズ風の91が持っているか、または計画しているUCSBとUCLA。 SDCは変化するのをそれが無器用な状態で見つけられて、21/1望むようにするかもしれません。)

   (Discussion of file transmission.  Crocker proposes that a future
      protocol change might attach a byte size such as 8, 32, 36 bits to
      a connection.)

(ファイルトランスミッションの議論。 クロッカーは、将来のプロトコル変化が8、32、36ビットなどのバイトサイズに接続に愛着するかもしれないよう提案します。)

   (Regarding control links, everything is transmitted in 8-bit bytes
      except ECO, ERP, ERR commands, No objection was voiced to changing
      the protocol so that they also must be multiples of 8-bit bytes.)

(コントロールリンクに関して、ECOを除いて、すべてが8ビットのバイトで伝えられて、また、ERP、ERRコマンド、異論が全くプロトコルを変えるのに声に出されなかったので、それらは8ビットのバイトの倍数であるに違いありません。)

   (Discussion of how to specify the end of a file.  Prior transmission
      of bit count, or send EOR character at end? Suggestion that we
      want global solution to the general problem of sending an
      arbitrary length message, rather than just file transmission.)

(どうファイルの端を指定するかに関する議論。 ビットの先のトランスミッションは、EORキャラクタを終わりに数えますか、または送りますか? 私たちが、ただトランスミッションをファイルするよりむしろ任意の長さのメッセージを送るという一般的問題のグローバルな解決が欲しいと思うという提案。)

   (Discussion of "transaction units" or record sizes.  What is an
      optimum transaction unit size? IMP message boundaries are
      invisible (by protocol fiat) and are not connected with this
      discussion.  Multics block size was brought up.  Nearest thing is
      page size, 1024 words.)

(「取引ユニット」かレコード・サイズの議論。 最適な取引ユニットサイズはどのくらいですか? IMPメッセージ限界は、目に見えなく(プロトコル法令による)、この議論に関連づけられません。 Multicsブロック・サイズは持って来られました。 最も近いものはページ・サイズ、1024の単語です。)

   (How to specify end of file.  Engelbart says send data packets, then
      EOF packet.  Crocker suggests that CLSing connection can act as
      EOF.  Vezza suggests that IMP message boundaries be used to
      determine end.  If less than full IMP message, this is last part
      of file.  Meyer suggests use of two connections, data channel and
      control channel, over which all control messages, such as file
      name, bit length, etc. are passed.)

(ファイルの終りを指定する方法。 Engelbartは送信データパケット、当時のEOFパケットを言います。 クロッカーは、CLSing接続がEOFとして務めることができることを提案します。 Vezzaは、IMPメッセージ限界が終わりを決定するのに使用されるのを示します。 これが完全なIMPメッセージよりそれほどファイルの最後の部分であるなら。 マイヤーは、2つの接続、データ・チャンネル、およびコントロールの使用(ファイル名、噛み付いている長さなどのすべてのコントロールメッセージが通過される)が向けられることを提案します。)

   (Discussion concerning different situations in which whole file, part
      of the file, or the whole file in arbitrary chunks was wanted.)

(全体のファイル、ファイルの一部、または任意の塊における全体のファイルが欲しかった異なった状況に関する議論。)

   Meyer: Why not defer this, and talk about typewriter communications,
      which is most critical.

マイヤー: なぜこれ、およびタイプライタコミュニケーションに関する話を延期しませんか?(それは、最も批判的です)。

   Vezza: Engelbart wants a clean general solution.

Vezza: Engelbartは清潔な一般解が欲しいです。

Meyer                                                          [Page 16]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[16ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   Crocker: If we get an ad hoc solution now, it may interfere with
      implementing a general solution later.

クロッカー: 私たちが現在その場かぎりの解決を得るなら、それは後で一般解を実行するのを妨げるかもしれません。

   (Crocker proposes format for transmitting a file of arbitrary length
      records of fixed sized bytes of 8-26 bits.  A record is less than
      10^5 bytes.  Each record is headed by a count byte.)

(クロッカーは、8-26ビットの固定大きさで分けられたバイトの任意の長さの記録のファイルを送るために形式を提案します。 レコードは5バイト10未満^です。 各記録はカウントバイト率いられます。)

                      1   2               n       1    2          m
               |----------------------------------------------------|
               |  n |   |   |           |   | m |   |   |       |   |
               |----------------------------------------------------|
               <------- record -----------> <-------- record ------->

1 2、n1 2m|----------------------------------------------------| | n| | | | | m| | | | | |----------------------------------------------------| <、-、-、-、-、-、-- 記録-----------><。-------- 記録------->。

   O'Sullivan: Does this model fit a terminal which has character and
      graphic modes?

オサリヴァン: このモデルはキャラクタとグラフィックモードを持っている端末に合いますか?

   (Discussion about differences between keyboard and file transmission.
      Uncertainty as to whether a global solution would fit both.)

(キーボードとファイルトランスミッションの違いについての議論。 グローバルな解決策が両方に合うだろうかどうかに関する不確実性。)

   (Who wants to ship files through the network? Multics and 6-10, RAND
      to UCLA, MITRE using BBN.)

(だれがネットワークを通してファイルを出荷したがっていますか? Multicsと6-10、UCLAへのランド、BBNを使用する斜め継ぎ。)

   Crocker: Let's go away thinking about this and propose solutions
      later.

クロッカー: これについて考えながら遠ざかって、後で解決策を提案しましょう。

   (Harslem proposes format for transmitting data with operation codes.
      Each record consists of: <opcode> <length> <data>.  Gives the
      opportunity to send many type of status info.)

(Harslemは、命令コードでデータを送るために形式を提案します。 各記録は以下から成ります。 <opcode><の長さの><データ>。 状態インフォメーションの多くのタイプを送る機会を与えます。)

   (Discussion regarding sending data and control information intermixed
      or on separate connections.  Issues of pollution of data vs.
      synchronization and race problems.  Claimed that synchrony
      problems are easily overcome.)

(データと制御情報を送るのと議論が混ぜられたか、または接続は分離します。 データの汚染の問題、同期と人種問題同期問題が容易に克服されると主張しました。)

   (Suggestion that we really don't know much about this area.  We
      should go off and write.)

(私たちが本当にこの領域に関して多くを知らないという提案。 私たちは、去って、書くべきです。)

   Intermission

幕間

   Crocker: What has to be done before we can log onto other systems?

クロッカー: 私たちが他のシステムにログオンできる前に何をしなければなりませんか?

   Meyer: 3 issues: 1) ho to establish the connection, 2) what is the
      character set, 3) what is the mode of transmission (relating to
      full and 1/2 duplex problem).

マイヤー: 3冊: 文字の組、3は)何です。1)に、おーい、2歳の接続を)確立する、トランスミッション(完全、そして、1/2の重複の問題に関連する)の方法であること。

   (Discussion of orienting standard protocol towards service systems
      which generally are line-oriented and 1/2 duplex.  Any systems
      offering services to have a 1/2 duplex interface.)

(一般に、線指向であることのサービス・システムと1/2デュプレックスに向かって標準プロトコルを適応させる議論。 1/2の重複のインタフェースを持つためにサービスを提供するどんなシステム。)

Meyer                                                          [Page 17]

RFC 82                   Network Meeting Notes             December 1970

マイヤー[17ページ]RFC82ネットワークミーティングは1970年12月に注意します。

   (Discussion of whether possible or desirable for the logger protocol
      to allow transmission of partial lines in a IMP message.  Less
      efficient to take partial lines, reasonable to send full line.
      Pointed out that NCP protocol disallows any meaning to IMP message
      boundaries, so systems must be prepared to accept lines straddling
      IMP message boundaries.  However, best to send complete line.)

(議論、きこりにとって可能であるか、または望ましいことにかかわらず、議定書を作って、IMPメッセージにおける、部分的な線のトランスミッションを許容してください。 より部分的な線を取るために効率的であって、実線を送るのがそれほど妥当ではありません。 NCPプロトコルがIMPメッセージ限界にどんな意味も禁じるのでIMPメッセージ限界にまたがりながら線を受け入れるようにシステムを準備しなければならないと指摘しました。 しかしながら、完全な線を送るのは最も十分です。)

   (Discussion of whether line-oriented protocol protocol should bend so
      as to accept single character transmission from full duplex
      systems.  Seems that we are coming up with a protocol to allow any
      system to use a line- oriented system.  To use a char-oriented
      system form other systems is more difficult and requires a
      separate protocol.)

(線指向のプロトコルが議定書を作るかどうかに関する議論は、全二重方式からただ一つのキャラクタトランスミッションを受け入れるために曲がるべきです。. 私たちがどんなシステムも線の指向のシステムを使用するのを許容するためにプロトコルを思いついているように思えます。 炭指向のシステムフォーム他のシステムを使用するのは、より難しく、別々のプロトコルを必要とします。)

   Heart: I am in favor of an immediate solution.

心臓: 私は即座の解決策を支持しています。

   Postel: Once something goes in, it will be hard to change it.

ポステル: 何かにいったん入ると、それを変えにくいでしょう。

   Crocker: I think these meetings will turn out to be more important
      than we ever wanted them to be.  I am more concerned with the long
      term effects than the starting date.

クロッカー: 私は、これらのミーティングが私たちが、今までにそれらが欲しいと思ったより重要であると判明すると思います。 私は始めの期日より長期効果に関係があります。

   Van Zoeren: If we don't decide it, somebody else will decide it the
      bad way.

Zoerenをバンに積んでください: 私たちがそれについて決めないと、他の誰かが悪い方法でそれについて決めるでしょう。

          [ This RFC was put into machine readable form for entry ]
           [ into the online RFC archives by Gottfried Janik 2/98 ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ゴットフリート・ジャニク2/98によるオンラインRFCアーカイブへの]

Meyer                                                          [Page 18]

マイヤー[18ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

カラーモードの違い CMYK/RGB

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る