RFC 282

GRAPHICS MEETING REPORT ✨

okay bestie, this is RFC 282 🎀 It's a meeting report from the Network Working Group, written by M. A. Padlipsky of Project MAC (NIC 8164), dated December 8, 1971. The title block doesn't list a category, and it doesn't say what this obsoletes or updates, so there's nothing to report on that front 🌸 It's a report, not a spec, but the people in it were building the Network's graphics stuff from scratch, so it's giving pioneer era 💅

---

The second Network Graphics Group Meeting 🦋 was held at the Stanford Artificial Intelligence Lab at 6:00 p.m. on Sunday, November 21st. The attendees are listed in the Appendix. Jim Michener was chairman, and I (M.A.P.) either volunteered or got volunteered to be recording secretary, with Karl Kelly helping keep notes 📝 iykyk, it's always the secretary 🙈

The agenda had three big topics: 1) reports on the experiments that were set up at the July meeting, 2) prepared talks from attendees who had general points to raise about Network Graphics, and 3) working out a "first-pass" graphics protocol 🧚 Before the reports, people talked about two important questions. The first was the "context" problem: in Network terms, how are graphics connections set up, and who is supposed to do what for whom? The second was the "console types" problem. Should there be one protocol for static storage tube devices and a separate one for interactive refresh devices that have their own processors? Or can we come up with a continuous (or layered) single protocol that covers both? 🤔 Both points got noted as things to keep in mind during the protocol phase, an apparent consensus showed up that a single protocol would be preferable, and then they moved on to the experiment reports 💜

REPORTS ON EXPERIMENTS 🌈

RAND - UCSB

Eric Harslem of RAND and Ron Stoughton of UCSB reported on their experiment, which used the UCSB On-Line System (OLS) from RAND Videographics terminals 🖥️ A videotape was shown, and it proved the experiment worked ✨ They said an RFC describing their simple protocol is coming. As they noted in their discussion and in that RFC, the experimental protocol is not being proposed as a Network standard, so don't go treating it like one 🙅‍♀️

There was also a side experiment testing how sensitive the hookup was to changes in the size of the allocations at the RAND end (in the Host-to-Host Protocol sense) 🍓 The videotape showed the same pictures being drawn at different allocation levels, and it was very clear that bigger allocations let the drawing be noticeably smoother. At maximum allocation the picture basically appeared all at once 😭 At minimum allocation, the NCP-NCP overhead was big enough that the picture came in one portion at a time. Main character energy for the allocation size, honestly 👑

SDC - DMCG

This experiment tried to input tablet data collected on MIT Project MAC's Dynamic Modeling/Computer Graphics Group's PDP-10 into a character recognizer package at SDC. Jean Saylor of SDC and Jim Michener of DMCG reported on it 💀 It was rough. There were hardware and software problems at both ends and in the middle, plus time zone conflicts with system availability slowed everything down. Some data did get transmitted though, so it wasn't a total flop 🫶

ILLINOIS MULTICS

This one was also plagued with problems 😩 The team tried to drive a console at U. of Ill. from the Multics Graphics System. Jack Bouknight (Illinois) and Ed Meyer (Multics) reported on it. An NCP bug at the Multics end and a machine switch at the Illinois end together kept the experiment from happening at all 💔

DIGRESSION

During his report, Bouknight said he was worried about whether the Network as a whole is reliable enough yet to support graphics work 🫣 The discussion that followed centered on how often a host other than Multics was unavailable, and I feel it's within my job to draw a curtain of anonymity over that part without prejudice 🙈 But I think mentioning the discussion itself shouldn't be hidden, since most attendees shared Jack's concern. After a lot of conversation, the apparent consensus was that the current reliability level of the Network server hosts isn't crippling to graphics work, but it can be quite hampering 🍵 Not a dealbreaker, but definitely a vibe killer 😤

SEX - NIC

Jon Postel (UCLA) and John Melvin (SRI) gave the last experiment report 🧚‍♀️ The goal was to make an IMLAC on the SEX system look like a local NLS console at the Network Information Center. The experiment hasn't been performed yet, but UCLA has ordered the equipment needed to modify their IMLAC 🛒 Future is being built, bestie ✨

ASSUMPTIONS 🎀

okay so the group agreed on a few assumptions that everything else builds on 💅

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 Standard Graphics Stream will consist of 8-bit bytes initially, and 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. 👀 so the output side is the main event, input can wait its turn 💖

OPERATORS 🛠️

As the Protocol Committee's draft is not immediately available, the following list of low-level operators may be of interest here. The syntax and semantics of these were discussed at length during the meeting, so they're the juicy bits 🍓

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. 🚶‍♀️
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), and 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, and 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 the 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 a 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 that 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). 📅🌈 bestie, that's a whole plan!

APPENDIX - LIST OF ATTENDEES 💜

here's everyone who showed up, iykyk 🧚

• 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] 🫶💖