1 files changed, 115 insertions, 0 deletions
diff --git a/doc/rfc/rfc472.txt b/doc/rfc/rfc472.txt
new file mode 100644
index 0000000..4b99aa6
--- /dev/null
+++ b/doc/rfc/rfc472.txt
@@ -0,0 +1,115 @@
+
+
+
+
+
+
+Network Working Group                                        Steve Bunch
+RFC # 472                                                    ILL-ANTS
+NIC # 14801                                                  March, 1973
+
+
+    Illinois' reply to Maxwell's Request for Graphics Information,
+                          NIC Document 14925.
+
+
+This is a reply to Craig Maxwell's (UCLA-NMC) "Request for graphics
+information" of 3/7/73.  Further details can be obtained by contacting
+me directly.
+
+To date, our work in graphics has been primarily centered about support
+for several applications groups.  To make the generation of beam-
+oriented graphics as painless as possible for these groups, our policy
+for supporting this type of graphics has been to emulate as closely as
+possible the CALCOMP plotter support package on the host machine, but
+with NGP0 output.  (Presently, before the resulting NGP can be sent to
+some of our peripherals, e.g., Gould 4800, it must be converted to
+device specifics.  With the advent of ANTS MARK II and a PDP-11/45, all
+conversions will be handled locally, so all graphics flowing into our
+system will be NGP).  We find this approach very labor-saving, even at
+the present slightly kludgey level.
+
+We also have some grey-scale work taking place on our GOULD and IMLAC.
+One group is processing satellite pictures on Illiac and will soon need
+grey-scale output, another is producing natural-resource maps, and a
+third is generating holograms.  No standardization plans have been made
+for grey scale work, but if an acceptable standard is established, we
+will most likely use it.
+
+A small group, including myself, is currently planning an interactive
+graphics system.  The system will use multiple hosts, possibly using a
+remote E&S machine for rotation, scaling, etc.  We have a number of
+large hurdles that have to be jumped before we can do anything, though.
+Several of these are not graphics-specific, such as process-controlled
+FTP, inter-process coordination among hosts, and others.  We had
+intended to let efficiency dictate the format of intermediate results
+shipped via the Net, with standardization being applied where it is
+helpful for minimizing effort.  Since the system will be highly
+interactive and will also manipulate grey-scale data, we will need a
+higher level of graphics protocol to handle the user interface.  A
+"proto-prototype" system is being used now to do some simple
+manipulations of meteorological data (e.g., contouring, 3-D plotting)
+
+
+
+
+
+
+Bunch                                                           [Page 1]
+
+RFC 472        Reply to Request for Graphics Information      March 1973
+
+
+with an IMLAC passively displaying the NGP0 pictures created.  Soon, I
+hope to finish an IMLAC program that will handle some interaction with
+the mouse/keyset.  I have decided to implement the following (outgoing)
+commands.
+
+    MOVE  beam to mouse position
+
+    DRAW  from last to present beam position.
+
+    TEXT  at present beam position.
+
+    UNDO  the last command (to facilitate freehand drawing and
+          backspacing in TEXT).
+
+Other commands may be implemented as needed to do what people want to
+do, at least until an adequate interaction standard comes along.
+
+Note that there is implicit in the UNDO command the assumption that
+the other end of the line possesses a certain amount of memory and
+intelligence.  Two possible philosophies for standardizing interaction
+are that (1) all "nodes" ("generators" or "users" of data) understand
+some set of commands and possess at least a certain amount of
+intelligence, and (2) a distinction is made between "displays" and
+"computers" (quotes because the line is fuzzy).  I favor the first for
+its generality, but I suggest that the lowest level of interactive
+graphics might want to use the second for ease of implementation with
+unintelligent devices, e.g., COMPUTEK 400's.  (I do not mean to
+imply in (1) that the actual "computer" would not have a larger
+vocabulary than the actual "display" --this is inevitable with higher
+level capabilities in the protocol).
+
+Since we have almost no local computing power for applications work,
+all our graphics computation is done remotely (our work has been
+primarily at UCSD (B6700), USC-ISI (TENEX), and UCLA-CCN (360)).
+Because we do our work at scattered sites and are basically economic
+of labor (pronounced "lazy"), we have a lot to gain by standards and
+will be glad to cooperate as much as possible with standardization
+efforts.
+
+Steve Bunch
+
+
+
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by Alex McKenzie with    ]
+       [ support from GTE, formerly BBN Corp.             9/99 ]
+
+
+
+
+Bunch                                                           [Page 2]
+