From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc282.txt | 451 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc282.txt (limited to 'doc/rfc/rfc282.txt') diff --git a/doc/rfc/rfc282.txt b/doc/rfc/rfc282.txt new file mode 100644 index 0000000..67fd47e --- /dev/null +++ b/doc/rfc/rfc282.txt @@ -0,0 +1,451 @@ + + + + + + +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] + +RFC 282 Graphics Meeting Report December 1971 + + + 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.) + + 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 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). + +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. + + + + + + + + + +Padlipsky [Page 5] + +RFC 282 Graphics Meeting Report December 1971 + + +ASSUMPTIONS + + The following assumptions were agreed upon: + + 1. There shall be a "virtual screen" and a Standard Graphics + Stream. + + 2. The origin is in the center. + + 3. Coordinates are signed, 2's complement fractions (-.5 to + +.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.) + + 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. + + 6. Where appropriate, operators shall have "absolute," + "relative," and "local" (to a subpicture) modes. + + 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. + + 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. + + 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: + + 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. + + 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. + + + +Padlipsky [Page 6] + +RFC 282 Graphics Meeting Report December 1971 + + + 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. + + 4. Point. Display a point at the specified position. Modes are + as with move. + + 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. + + 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. + + 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.) + + 8. Escape. If the console is of specified type, pass a specified + number of bytes directly to it. + + 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. + +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) + + + +Padlipsky [Page 7] + +RFC 282 Graphics Meeting Report December 1971 + + +APPENDIX - LIST OF ATTENDEES + + Marshall Abrams, Ntl. Bureau of Stds. + + Jack Bouknight, U. of Ill. + + Jackson T. Cole, Rome Air Development Ctr. + + Ira Cotton, MITRE + + Daniel Debrosse, UTAH + + Eric Harslem, RAND + + Karl Kelly, U. of Ill. + + David Liddle, Owens Illinois + + John Melvin, SRI + + Ed Meyer, MAC + + James Michener, MAC + + James Moorer, SAIL + + Hamid Naficy, UCLA + + Mike Padlipsky, MAC + + Ken Pogran, MAC + + Jon Postel, UCLA + + Jerry Powell, MITRE + + Jean Saylor, SDC + + Ron Stoughton, UCSB + + Elaine Thomas, BBN + + Howard Wactlar, Carnegie-Mellon + + Bill White, SUHP + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Kelly Tardif, Viagénie 10/99] + + + +Padlipsky [Page 8] + -- cgit v1.2.3