rfc282.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

                        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.

   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.

REPORTS ON EXPERIMENTS

   RAND - 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





Padlipsky                                                       [Page 1]

RFC 282                 Graphics Meeting Report            December 1971


   "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.

   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.

   ILLINOIS 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.

   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.

   SEX - 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.







Padlipsky                                                       [Page 2]

RFC 282                 Graphics Meeting Report            December 1971


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

   "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."

    LANGUAGES FOR GRAPHICS ATTENTION HANDLING - Ira 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."

   "INTERACTIVE" GRAPHICS ISSUES - Ken 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."

   "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."







Padlipsky                                                       [Page 3]

RFC 282                 Graphics Meeting Report            December 1971


   PROTOCOL FOR THE OLS EXPERIMENT - Ron Stoughton, Eric 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."

   CONNECTION CONSIDERATIONS - Andy Moorer [Abstracted by 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.

   CONNECTION TYPES - Jim Michener [Abstracted by 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.

   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").





Padlipsky                                                       [Page 4]