RFC282 日本語訳

Network Working Group                                    M. A. Padlipsky
Request for Comments: 282                                    Project MAC
NIC: 8164                                               December 8, 1971

A.Padlipskyがコメントのために要求するワーキンググループM.をネットワークでつないでください: 282 MAC NICを映し出してください: 8164 1971年12月8日

                        GRAPHICS MEETING REPORT

グラフィックスミーティングレポート

   The second Network Graphics Group Meeting was convened at the
   Stanford Artificial Intelligence Lab at 6:00p.m. Sunday, November
   21st.  (Attendees are listed in the Appendix.)  Jim Michener served
   as chairman, and I either volunteered or was volunteered to serve as
   recording secretary, with Karl Kelly's assistance in keeping notes.

第2Network Graphics Group Meetingは11月21日日曜日の午後6時にスタンフォードArtificial Intelligence Labで召集されました。 (出席者はAppendixに記載されています。) ジム・ミッチェナーが議長を務めて、私は、買って出たか、または記録係として勤めるために買って出られました、注意を保つことにおけるカール・ケリーの支援で。

   An agenda was agreed upon for the meeting, covering three major
   topics: 1) reports on the experiments which had been set up at the
   July meeting,  2) prepared talks by attendees who had general points
   to raise about Network Graphics, and  3) specification of a "first-
   pass" graphics protocol.  Before the reports were given, some general
   discussion was held on two important topics: the "context" problem
   (just how, in the Network sense, are graphics connections
   established, and who is supposed to do what for whom), and what might
   be called the "console types" problem (should there be a separate
   protocol for inherently static storage tube type devices and one for
   inherently interactive refresh type devices which have their own
   processors, or can we come up with some sort of continuous -- or
   layered -- single protocol which covers both).  Both points were
   noted as being necessary to keep in mind for the protocol
   specification phase of the meeting, an apparent consensus emerged
   that a single protocol would be preferable, and the reports on
   experiments were turned to.

3つの主要な話題をカバーしていて、議題はミーティングのために同意されました: 1) 7月のミーティングでセットアップされていた実験に関するレポート、Network Graphics、および3時頃に上げる一般的なポイント) 「最初のパス」グラフィックスの仕様を持っていた出席者による2つの)準備された会談が議定書を作ります。 レポートを与える前に、2つの重要な話題に関して何らかの一般的な議論が行いました: 「文脈」問題(ちょうどどのように、Networkが感じるコネは接続が確立したグラフィックスであるか、そして、だれがいるかがだれのために何をするかと思った)、および「コンソールタイプ」問題(本来スタティックストレージチューブタイプ装置のための別々のプロトコルと私たちが両方を覆うある種の連続したか層にされたただ一つのプロトコルと共に来させるそれら自身のプロセッサ、または缶を持っている本来対話的なリフレッシュ・タイプ装置のための1つがそうあるべきである)と呼ばれるかもしれないもの。 両方のポイントはミーティングのプロトコル仕様フェーズのために覚えておくために必要に応じて注意されました、そして、ただ一つのプロトコルが望ましいだろうという見かけのコンセンサスは現れました、そして、実験に関するレポートは変わられました。

REPORTS ON EXPERIMENTS

実験に関するレポート

   RAND - UCSB

底ならし革--UCSB

   Eric Harslem of RAND and Ron Stoughton of UCSB reported on their
   experiment, which entailed use of the UCSB On-Line System (OLS) from
   RAND Videographics terminals.  As demonstrated by a videotape which
   was shown, the experiment was successful.  An RFC describing the
   simple protocol they used is forthcoming.  As noted in their
   discussion and in the RFC, the experimental protocol is not being
   proposed as a Network standard.  In addition to using OLS from RAND,
   a subsidiary experiment tested the sensitivity of the hook-up to
   variations in the size of the allocations (in the Host-to-Host
   Protocol sense) given at the RAND end.  It seemed clear from the
   videotape of the same pictures being drawn at various allocation
   levels that larger allocations allow for noticeably smoother

RANDのエリックHarslemとUCSBのロンストートンは彼らの実験に関して報告しました。(それは、RAND Videographics端末からUCSB On-線System(OLS)の使用を伴いました)。 見せられたビデオテープによって示されるように、実験はうまくいきました。 彼らが使用した簡単なプロトコルについて説明するRFCは用意されています。 彼らの議論とRFCに述べられるように、実験プロトコルはNetwork規格として提案されていません。 RANDからOLSを使用することに加えて、補助の実験はRANDエンドのときに与えられた配分(Hostからホストへのプロトコル意味における)のサイズの変化に接続の感度をテストしました。 それは、より大きい配分が顕著に滑らかに考慮する様々な配分レベルで描かれる同じ絵のビデオテープから明確に見えました。

Padlipsky                                                       [Page 1]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[1ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

   "drawing" at maximum allocation, the picture essentially appeared all
   at once, whereas at minimum allocation, NCP-NCP overhead was
   sufficiently large that the picture appeared a portion at a time.

最大の配分における「図面」、最小の配分では、NCP NCPオーバーヘッドは十分大きかったのですが、絵は本質的には一気に現れました。絵は一度に、部分に現れました。

   SDC - DMCG

SDC--DMCG

   An experiment intended to input tablet data collected at MIT Project
   MAC's Dynamic Modeling/Computer Graphics Group's PDP-10 to a
   character recognizer package at SDC was reported on by Jean Saylor of
   SDC and Jim Michener of DMCG.  Problems ranging from
   hardware/software difficulties at both ends (and in the middle) to
   time zone-induced system availability conflicts retarded the
   experiment's progress, although some transmission of data has been
   achieved.

MIT Project MACのDynamic Modeling/コンピュータGraphics GroupのPDP-10に集められたタブレットデータをSDCでのキャラクタ認識器パッケージに入力することを意図する実験はオンであるとSDCのジーンSaylorとDMCGのジム・ミッチェナーによって報告されました。 両端(そして中央で)におけるハードウェア/ソフトウェア困難から時間帯で誘発されたシステム稼働率闘争まで及ぶことにおける問題は実験の進歩を遅らせました、データの何らかの伝達が達成されましたが。

   ILLINOIS MULTICS

イリノイMULTICS

   Also plagued with problems was the attempt to drive a console at U.
   of Ill. from the Multics Graphics System.  This experiment was
   reported on by Jack Bouknight (Illinois) and Ed Meyer (Multics).  An
   NCP bug at the Multics end and a machine switch at the Illinois end
   combined to prevent the carrying out of the experiment.

また、問題で悩むのは、Multics Graphics Systemからのイリノイ州のU.でコンソールを動かす試みでした。 この実験はオンであるとジャックBouknight(イリノイ)とエド・マイヤー(Multics)によって報告されました。 MulticsエンドのNCPバグとイリノイ終わりのマシンスイッチは結合して、実験の搬出を防ぎました。

   DIGRESSION

脱線

   During his report, Bouknight expressed concern as to whether the
   Network as a whole is as yet sufficiently reliable to support
   graphics work.  As the ensuing discussion focused on the frequent
   unavailability of a host other than Multics, I feel that it is within
   my province to draw the curtain of anonymity over it without
   prejudice.  However, I feel that mention of the discussion need not
   be suppressed as well, in view of the fact that most of the attendees
   shared Jack's concern.  The apparent consensus, reached after
   considerable conversation, is that the present reliability level of
   the Network server hosts is not crippling to graphics work, but can
   be quite hampering.

彼のレポートの間、全体でNetworkがグラフィックス仕事を支持するのにおいて十分まだ信頼できているかどうかに関してBouknightは懸念を示しました。 続く議論がMultics以外のホストの頻繁な使用不能に焦点を合わせたので、私は、偏見なしでそれの上の匿名のカーテンを引くために私の州の中にそれがあると感じます。 しかしながら、私は、また、議論の必要性のその言及が抑圧されないと感じます、出席者の大部分がジャックの関心を共有したという事実から見て。 Networkサーバー・ホストの現在の信頼性レベルがグラフィックスに仕事を無力にしていないということですが、かなりの会話の後に達した見かけのコンセンサスは、全く束縛であることができます。

   SEX - NIC

セックス--NIC

   Jon Postel (UCLA) and John Melvin (SRI) gave the last experiment
   report, on an attempt to make an IMLAC on the SEX system look like a
   local NLS console at the Network Information Center.  The experiment
   has not yet been performed, but UCLA has ordered the necessary
   equipment to modify their IMLAC.

ジョン・ポステル(UCLA)とジョン・メルビン(SRI)は最後の実験レポートを与えました、SEXシステムの上のIMLACをNetworkインフォメーション・センターで地方のNLSコンソールに似させる試みに関して。 実験がまだ行われていませんが、UCLAは、それらのIMLACを変更するよう必要な設備に命令しました。

Padlipsky                                                       [Page 2]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[2ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

PRESENTATIONS

プレゼンテーション

   Most of the speakers who gave prepared talks responded favorably to
   my plea for abstracts, probably out of kindness, but perhaps out of
   fear of (threatened) garbling.  Authors' abstracts are in quotation
   marks in the following section.

準備された会談に与えたスピーカーの大部分はたぶん親切であるのからの要約にもかかわらず、恐らく(脅かされます)誤り伝えることへの恐怖から私の請願に好意的に応じました。 以下のセクションの引用符には作者の要約があります。

   PLASMA PANEL DISPLAY - Dave Liddle

ガスパネル表示--デーヴLiddle

   "The Owens - Illinois DS-1 terminal will be available to Network
   users who request them through ARPA.  The display module is the OI
   512X512 line plasma panel; the processor is a 16 bit, 4K machine with
   modem; ASCII keyboard, and optional tape cassette.  Simple software
   (character and vector generators, etc.) will be provided.  If orders
   can be assembled by 1 January, deliveries will begin this summer."

「オーエンス--イリノイDS-1端末はARPAを通して彼らを要求するNetworkユーザにとって利用可能になるでしょう。」 ディスプレイ・モジュールはOI512X512線ガスパネルです。 プロセッサは16ビット、モデムがある4Kマシンです。 アスキーキーボード、および任意のテープカセット。 簡単なソフトウェア(キャラクタとベクトル発生器など)を提供するでしょう。 「1月1日までに命令を組み立てることができると、配送は今年の夏を始めるでしょう。」

    LANGUAGES FOR GRAPHICS ATTENTION HANDLING - Ira Cotton

グラフィックス注意取り扱いのための言語--イラCotton

   "Available languages for programming the processing of operator
   inputs to a computer graphic system were organized into functional
   classes and briefly surveyed.  Some of the problems associated with
   providing this facility in a multi-computer graphics system (such as
   the Network) were discussed, and a new approach was presented.  This
   system, implemented by Univac for one of its systems, employs an
   interpretively executed command language to direct attention-handling
   in the remote graphics controller.  The commands of the language were
   outlined, and some program fragments illustrated."

「オペレータ入力の処理をコンピュータグラフィック・システムにプログラムするための利用可能な言語は、機能クラスに組織化されて、簡潔に調査されました。」 マルチコンピュータグラフィックスシステム(Networkなどの)にこの施設を供給すると関連している問題のいくつかについて議論しました、そして、新しいアプローチは提示されました。 システムの1つのためにユニバックによって導入されたこのシステムは、リモートグラフィックスコントローラで注意取り扱いを指示するのに解釈的な実行されたコマンド言語を使います。 「言語のコマンドは概説されました、そして、いくつかのプログラム断片が例証しました。」

   "INTERACTIVE" GRAPHICS ISSUES - Ken Pogran

「対話的な」グラフィックス問題--ケンPogran

   "The purpose of this talk was to raise a number of significant issues
   we must face in the development of a Network protocol for
   _interactive_ graphics.  While the bulk of the work at this second
   graphics meeting dealt with a protocol for "static" or "storage-tube"
   graphics, it is appropriate that we begin to think about the problems
   we will encounter in the development of an interactive graphics
   protocol."

「この話の目的は私たちが_インタラクティブ_グラフィックスのためにNetworkプロトコルの開発で直面しなければならない多くの重要な問題を提起することでした。」 「この2番目のグラフィックスミーティングにおける仕事の大半が「静電気」か「蓄積管」グラフィックスのためのプロトコルに対処しましたが、私たちがインタラクティブグラフィックスプロトコルの開発で行きあたるつもりである問題について考え始めるのは適切です。」

   "The issues raised included: 1) the nature of graphical interaction,
   2) various possible hardware/software configurations which might be
   employed, 3) computational capabilities required at the serve and
   user host sites, 4) the nature of a graphical data structure suited
   to a wide range of applications, and 5) the nature and treatment of
   graphic inputs for a generalized interactive graphics system."

「提起された問題はである:」 「1) グラフィカルな相互作用の自然、使われるかもしれない2つの)様々な可能なハードウェア/ソフトウェア構成、3つの)コンピュータの能力がサーブ、ユーザー・ホストサイト、グラフィカルなデータ構造の本質がさまざまなアプリケーションに合った4、)および5で)一般化されたインタラクティブグラフィックスシステムのためのグラフィック入力の自然と処理を必要としました。」

Padlipsky                                                       [Page 3]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[3ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

   PROTOCOL FOR THE OLS EXPERIMENT - Ron Stoughton, Eric Harslem

OLS実験のためのプロトコル--ロンストートン、エリックHarslem

   "A short presentation was given describing a graphics protocol used
   to interface the RAND Videographics System to the USCB On-Line
   System.  A video tape of alive demonstration of the experiment [had
   also been] presented.  An RFC describing the experiment and protocol
   in detail will be issued in the near future."

「USCB On-線SystemにRAND Videographics Systemを連結するのに使用されるグラフィックスプロトコルについて説明しながら、短いプレゼンテーションをしました。」 ビデオは生きるのをテープに録音します。提示された[また、ありました]実験のデモンストレーション。 「詳細に実験とプロトコルについて説明するRFCは近い将来、発行されるでしょう。」

   CONNECTION CONSIDERATIONS - Andy Moorer [Abstracted by M.A.P.]

接続問題--アンディ・ムーラー[M.A.P.で、抜き取られています]

   The topic was started succinctly as "how this thing should work."  It
   was proposed to use the Telnet Protocol for simple graphics (i.e.,
   when device dependent codes are being transmitted), with the addition
   of Telnet control codes for Enter graphics Mode, Leave Graphics Mode,
   and Console Type being necessary.  For complex graphics (i.e., when
   an intermediate form is being transmitted) it was proposed that an
   additional socket pair be employed.

「このものはどう働いているはずである」として、話題が簡潔に始められました。 それは、簡単なグラフィックスにテルネット・プロトコルを使用するために必要なEnterグラフィックスのMode、Leave Graphics Mode、およびConsole TypeのためのTelnet制御コードの添加で提案されました(すなわち、装置に依存するコードはいつ伝えられていますか)。 複雑なグラフィックス(すなわち、中間的書式が伝えられているとき)において、追加ソケット組が雇われるよう提案されました。

   CONNECTION TYPES - Jim Michener [Abstracted by M.A.P]

接続はタイプします--ジム・ミッチェナー[M.A.Pで、抜き取られています]

   There are at least three types of graphics devices which may be
   connected over the Network: "simple" (ARDS-like), "smart" (IMLAC-
   like), and "powerful" (E&S-like).  There are three kinds of
   processing involved: applications packages (A), graphics packages
   (G), and conversion to device-specific codes (C), potentially from an
   intermediate form such as the "Network Standard Graphics Stream"
   discussed in earlier RFC's.  There are also three places where each
   kind of processing may be performed: at the graphics device itself,
   at the local host (which may not be able to help if it's a TIP), and
   at a remote host (OR HOST).  This should lead neatly to some sort of
   3X3X3 matrix which depicts the sorts of connections we want to
   support, but I don't know how to draw it.

Networkの上に接続されるかもしれない少なくとも3つのタイプのグラフィックス装置があります: 「簡単(ARDSのような)」、「賢さ」(IMLACは好きである)、および「強力(E&Sのような)」。 かかわった3種類の処理があります: applications packages (A), graphics packages (G), and conversion to device-specific codes (C), potentially from an intermediate form such as the "Network Standard Graphics Stream" discussed in earlier RFC's. また、3つの場所が各種類の処理が実行されるかもしれないところにあります: グラフィックス装置自体においてローカル・ホスト(それがTIPであるなら助けることができないかもしれない)においてリモートホスト(OR HOST)で。 これは支持したいと思う接続の種類について表現するある種の3X3X3マトリクスにきちんと通じるべきですが、私はそれを描く方法を知りません。

   The talk leaned heavily on blackboard pictures of specific
   connections, but for purposes of this report, I'll try to summarize
   the situation in words.  For all simple devices, C must be performed
   "elsewhere"; if the simple device is on the Net via a TIP, C
   apparently must be performed either at the remote host (RH1) where A
   and G are, or at some other remote host (RH2) (which offers, say, the
   Data Reconfiguration Service).  Further, negotiations for C may have
   to be performed by RH1 on the TIP's behalf.  Still more complications
   result from the possible desirability of including an additional
   application (A') and/or an additional graphics package (G') on RH2.
   If the simple device is on the Net via a full-fledged local host
   (LH), then A, G, and C can each potentially be performed at LH or RH1
   -- or RH2 for that matter ("ship it to an E&S for clipping").

話は大いに特定の接続の黒板の絵にもたれましたが、このレポートの目的のために、私は単語による状況をまとめようとするでしょう。 すべての簡単な装置に関しては、「ほかの場所で」Cを実行しなければなりません。 TIPを通して簡単な装置がネットにあるなら、AとGがそうであるリモートホスト(RH1)において、または、ある他のリモートホスト(RH2)(たとえばData Reconfiguration Serviceを提供する)で明らかにCを実行しなければなりません。 さらに、Cのための交渉はRH1によってTIPの利益に実行されなければならないかもしれません。 'まだより多くの複雑さが追加アプリケーション(A')、そして/または、RH2の上の追加グラフィックスパッケージ(G')を含む可能な願わしさから生じます。 一人前のローカル・ホスト(LH)を通して簡単な装置がネットにあるなら、さらに言えば、LHかRH1or RH2でそれぞれ潜在的にA、G、およびCを実行できます(「切り取りのためのE&Sにそれを送ってください」)。

Padlipsky                                                       [Page 4]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[4ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

   In the case of smart devices, C can potentially be performed at the
   device itself - - although the TIP may not be able to furnish the
   extra socket pair which one would want in order to handle such cases
   cleanly.  Finally, powerful devices can do G internally but we may
   well wish to do A and G over the Net.  (Again, how the TIP would
   handle such cases was not clear.)

賢い装置の場合では、装置自体で潜在的にCを実行できます。----TIPは余分なソケット組を提供できないかもしれませんが、どれがそうしたがっているだろうかが清潔にそのような場合を扱います。 最終的に、強力な装置は内部的にGができますが、たぶんネットの上にAとGをしたいと思うでしょう。 (一方、TIPがどうそのような場合を扱うかは、明確ではありませんでした。)

   Jim had presented this discussion for the expressed purpose of
   getting attention focused on the "ends" of the protocol pipeline
   before the meeting became totally concerned with the contents of that
   pipeline.  We responded in the only possible manner:

ミーティングがそのパイプラインのコンテンツに完全に関係があるようになる前にジムはプロトコルパイプラインの「終わり」で集中している注意を引く言い表された目的のためのこの議論を提示しました。 私たちは唯一の可能な方法で応じました:

CONNECTION PROTOCOL COMMITTEE

接続プロトコル委員会

   A committee was designated to formulate a Graphics Connection
   Protocol, the protocol to play an analogous role to that of the
   Initial Connection Protocol with respect to the Telnet Protocol.
   There was a clearcut consensus that only device-specific codes should
   be transmitted over Telnet connections unless the committee uncovered
   overwhelmingly convincing arguments to the contrary.  The committee
   consists of Michener, Bouknight, Harslem, and me.  Will Crowther of
   BBN will be invited to join the committee to furnish TIP
   representation and expertise.

委員会は、Graphics Connectionプロトコル(テルネット・プロトコルに関してInitial Connectionプロトコルのものに類似の役割を果たすプロトコル)を定式化するために任命されました。 委員会がそれと反対に圧倒的に説得力がある議論の覆いを取らない場合装置特有のコードだけがTelnet接続の上に伝えられるという明確なコンセンサスがありました。 委員会はミッチェナー、Bouknight、Harslem、および私から成ります。 BBNのウィル・クラウザーがTIP表現と専門的技術を提供するために委員会に加わるよう誘われるでしょう。

GRAPHICS RESOURCE DOCUMENTATION

グラフィックスリソースドキュメンテーション

   Before turning to the protocol specification, it should be pointed
   out that most attendees felt that Resource Notebook-like
   documentation on Graphics should be prepared.  Postel volunteered to
   coordinate this effort.  Hosts should have drafts submitted to him,
   and he will see to getting them published as new portion of the
   Resource Notebook.  Format considerations were not discussed, but
   assumedly the format should imitate that of the main Resource
   Notebook sections.  Call Jon if you have questions (213-825-2368).

プロトコル仕様に変わる前に、ほとんどの出席者が、Graphicsに関するResource Notebookのようなドキュメンテーションが準備されるべきであると感じたと指摘されるべきです。 ポステルは、この努力を調整するのを買って出ました。 ホストには、彼に提出された草稿があるべきです、そして、彼はResource Notebookの新しい部分としてそれらを発行させるのに見るでしょう。 形式問題について議論しませんでしたが、当然のことのように形式は主なResource Notebook部のものを模倣するべきです。 質問(213-825-2368)がありましたらジョンに電話をしてください。

THE PROTOCOL

プロトコル

   At the outset of the main protocol discussion, it was agreed that a
   committee would be established to resolve those issues on which a
   consensus could not be reached at the meeting, and to prepare a draft
   of the protocol for distribution to the NGG by year's end.  Members
   of the committee are Michener, Meyer, Kelly, Cotton, and Liddle.

最初に、主なプロトコル議論では、委員会がコンセンサスにミーティングで達することができなかったそれらの問題を解決して、年末までに分配のためにプロトコルの草稿をNGGに準備するために設立されるのに同意されました。 委員会のメンバーは、ミッチェナーと、マイヤーと、ケリーと、Cottonと、Liddleです。

Padlipsky                                                       [Page 5]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[5ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

ASSUMPTIONS

仮定

   The following assumptions were agreed upon:

以下の仮定は同意されました:

      1.  There shall be a "virtual screen" and a Standard Graphics
      Stream.

1. 「仮想のスクリーン」とStandard Graphics Streamがあるでしょう。

      2.  The origin is in the center.

2. 起源がセンターにあります。

      3.  Coordinates are signed, 2's complement fractions (-.5 to
      +.499).

3. 座標は調印されて、2は断片(.5対-+.499)の補足となります。

      4.  The Standrd Graphics Stream will consist of 8-bit bytes
      initially, coordinates are two bytes. ( A "set coordinate size"
      operator will be introduced if and when needed.)

4. Standrd Graphics Streamは初めは8ビットのバイトから成って、座標は2バイトです。 (必要であるなら、「コーディネートしているサイズを設定してください」というオペレータは紹介されるでしょう。)

      5.  Network ASCII will be used for text output, with default to
      upper case where necessary.  Control characters are, for the time
      being, site specific.

5. ネットワークASCIIはテキスト出力に必要であるところでデフォルトで大文字に使用されるでしょう。 制御文字は当分の間サイト特有です。

      6.  Where appropriate, operators shall have "absolute,"
      "relative," and "local" (to a subpicture) modes.

6. 適切であるところでは、オペレータが「絶対」の、そして、「相対的で」、「地方(「副-絵」への)」のモードを持っているものとします。

      7.  The protocol will be organized on a "levels of complexity"
      basis, with level 0 comprising operators for simple picture
      drawing, level 1 comprising operators for one level of subpicture
      definition ("macros", or loosely, "subroutines") and level 2
      comprising "viewport" and "window" type operators.

7. プロトコルは「複雑さのレベル」ベースで組織化されるでしょう、レベル0が簡単な絵の図面のためにオペレータを包括していて、レベル1が1つのレベルの「副-絵」の定義のためにオペレータを包括して(「マクロ、」 ゆるみ、「サブルーチン」) レベル2 そして、「ビューポート」と「窓」タイプオペレータを包括すること。

   Note that the discussion dealt specifically with graphics OUTPUT.
   The Protocol Committee was also empowered to prepare recommendations
   for an input-side protocol, but first priority is to be attached to
   the formulation of an acceptable output-side protocol.

議論が特にグラフィックスOUTPUTに対処したことに注意してください。 また、インプット側プロトコルのために推薦を準備するのにプロトコルCommitteeに権限を与えましたが、最優先は許容できるアウトプット側プロトコルの定式化に付けることです。

   OPERATORS

オペレータ

   As the Protocol Committee's draft is not immediately available, the
   following list of low-level operators (the syntax and semantics of
   which were discussed at length during the meeting) may be of interest
   here:

プロトコルCommitteeの草稿がすぐに利用可能でないので、下級オペレータ(十分ミーティングの間、それの構文と意味論について議論しました)の以下のリストはここで興味があるかもしれません:

      1. Erase and reset to origin.  This operator causes the screen to
      be erased and the beam to be positioned at the 0,0 (virtual screen
      center) point.  A new picture is started.

1. 起源に消して、リセットします。 このオペレータは、スクリーンが消されるのを置いて、0時にビームを置かせます、0(仮想のスクリーンのセンター)ポイント。 新しい絵は始められます。

      2. Move.  No line is drawn the beam is positioned to the specified
      x, y position.  There are specific operators for "move relative",
      "move absolute" and "move local" modes.

2. 動いてください。 どんな線も描かれて、ビームが指定に置かれるということではありません。x、y位置。 「親類を動かしてください」と「絶対で、動いてください」と「地方で、動いてください」というモードのための特定のオペレータがいます。

Padlipsky                                                       [Page 6]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[6ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

      3. Draw.  A line (of the current "linetype" -- see 5, below) is
      drawn from the present beam position to the specified x, y
      position.  Modes are as with move.  Treatment of the "off-screen"
      condition is at the displaying host's option.

3. 描いてください。 線(現在の"linetype"について--以下で5を見る)はプレゼントから得られたビームがx(y位置)を指定に置くということです。 モードはそうです。移動のように。 表示しているホストの選択には「オフスクリーン」状態の処理があります。

      4. Point.  Display a point at the specified position.  Modes are
      as with move.

4. 指してください。 指定された位置にポイントを表示してください。 モードはそうです。移動のように。

      5. Line type.  Draw lines of the specified type until further
      notice.  Currently defined types are solid (0), dashed (1), dotted
      (2).  If a requested type is not implemented, default to the
      next-lower-valued type.  After an "erase", type is solid until
      changed.

5. タイプを裏打ちしてください。 追って通知があるまで指定されたタイプの線を描いてください。 現在定義されたタイプは、固体(0)であり、(1)を投げつけて、(2)に点を打たせました。 要求されたタイプが実行されないなら、次に評価されていた状態で下ろしているタイプをデフォルトとしてください。 「抹消」の後に、タイプは変えるまでしっかりしたです。

      6. Line intensity.  Requests line intensity to be as follows: 0 =
      off, 128 = normal, 255 = brightest, intermediate values = map
      appropriately.  After an "erase", intensity is normal until
      changed.

6. 強度を裏打ちしてください。 要求は以下の通りために強度を裏打ちします: 0 = 最も明るくて、中間的なオフ128=標準、255=値は適切に地図と等しいです。 「抹消」の後に、強度は変えるまで正常です。

      7. Text.  Cause display of a specified number of specified (Net
      ASCII) characters.  There are specific operators for "return beam"
      after last character (to position before text display) and "leave
      beam" (wherever it ends up).  Size is to be whatever the
      displaying host considers "normal".  Treatment of "right-hand
      margin" and ASCII controls is host-specified at present.  (A
      character size operator may be specified later.)

7. テキスト。 指定された数の指定された(ネットのASCII)キャラクタの表示を引き起こしてください。 最後のキャラクタ(テキスト表示の前に置く)の後に、「リターンビーム」への特定のオペレータがいます、そして、「休暇は発する」(どこで終わっても)。 サイズはホストが表示が何であってもであるなるように「標準」を考えるということです。 「右手のマージン」とASCIIコントロールの処理は現在のところ、ホストによって指定されています。 (キャラクタサイズオペレータは後で指定されるかもしれません。)

      8. Escape.  If the console is  of specified type, pass a specified
      number of bytes directly to it.

8. 逃げてください。 指定されたタイプにコンソールがあるなら、指定されたバイト数を直接それに通過してください。

   Operators for viewports and subpictures were also discussed.
   Bouknight and Kelly prepared an BNF treatment of all points
   discussed, which will appear in the Protocol Committee's draft.

また、ビューポートと「副-絵」のオペレータについて議論しました。 Bouknightとケリーは議論したすべてのポイントのBNF処理を準備しました。(ポイントはプロトコルCommitteeの草稿に現れるでしょう)。

OTHER BUSINESS

他のビジネス

   The remaining technical discussion dealt with graphic input, on a
   rather general level.

残っている技術面の協議はかなり一般的なレベルに関するグラフィック入力に対処しました。

   Michener extended the attendees' thanks to Andy Moorer for having
   hosted the meeting.

ミッチェナーはミーティングを主催したためのアンディ・ムーラーのおかげで出席者のものを広げました。

   Cotton volunteered to host the next meeting at Mitre, Washington, in
   mid-April, at which time we hope to have had enough experience with
   the connection protocol and first-pass output protocol to agree on a
   "final" statement of them, and to have done enough thinking about the
   input side to specify a first-pass protocol for it (unless the
   Protocol Committee manages to do so first)

4月中旬のMitre、ワシントンで次のミーティングを主催するために買って出られた綿。(その時、私たちは最初に、パスプロトコルをそれに指定するためにインプット側について考えながらそれらの「最終的な」声明で同意して、十分した接続プロトコルと最初に、パス出力プロトコルで十分な経験があったことを望んでいます)。(プロトコルCommitteeが最初に何とかそうしない場合)

Padlipsky                                                       [Page 7]

RFC 282                 Graphics Meeting Report            December 1971

Padlipsky[7ページ]RFC282グラフィックスミーティングは1971年12月に報告します。

APPENDIX - LIST OF ATTENDEES

付録--出席者のリスト

    Marshall Abrams, Ntl. Bureau of Stds.

マーシャル・エーブラムズ、Ntl。 Stdsの事務局。

    Jack Bouknight, U. of Ill.

ジャックBouknight、イリノイ州のU.

    Jackson T. Cole, Rome Air Development Ctr.

ジャクソン・T.コール、ローマ空気開発Ctr。

    Ira Cotton, MITRE

イラCotton、斜め継ぎ

    Daniel Debrosse, UTAH

ダニエルDebrosse、ユタ

    Eric Harslem, RAND

エリックHarslem、底ならし革

    Karl Kelly, U. of Ill.

カール・ケリー、イリノイ州のU.

    David Liddle, Owens Illinois

デヴィッドLiddle、オーエンスイリノイ

    John Melvin, SRI

ジョン・メルビン、様

    Ed Meyer, MAC

エド・マイヤー、MAC

    James Michener, MAC

ジェームス・ミッチェナー、MAC

    James Moorer, SAIL

ジェームス・ムーラー、帆

    Hamid Naficy, UCLA

ハミドNaficy、UCLA

    Mike Padlipsky, MAC

マイクPadlipsky、MAC

    Ken Pogran, MAC

ケンPogran、MAC

    Jon Postel, UCLA

ジョン・ポステル、UCLA

    Jerry Powell, MITRE

ジェリー・パウエル、斜め継ぎ

    Jean Saylor, SDC

ジーンSaylor、SDC

    Ron Stoughton, UCSB

ロンストートン、UCSB

    Elaine Thomas, BBN

エレイン・トーマス、BBN

    Howard Wactlar, Carnegie-Mellon

ハワードWactlar、カーネギー-メロン

    Bill White, SUHP

ビル・ホワイト、SUHP

         [This RFC was put into machine readable form for entry]
     [into the online RFC archives by Kelly Tardif, Viag駭ie 10/99]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ケリーTardifによるオンラインRFCアーカイブへのViag駭ie10/99]

Padlipsky                                                       [Page 8]

Padlipsky[8ページ]