RFC 549

Minutes of Network Graphics Group meeting, 15-17 July 1973

📅 published July 1973, from ietf

RFC 549: Minutes of Network Graphics Group Meeting ✨

Okay bestie, this is RFC 549, and it's literally the meeting notes from the Network Graphics Group 🎀 Nobody gets a spec here, just what got said and who said it. Here's the header info you need:

  • Series: Network Working Group 🌸
  • Author: Anonymous, so no name on it 🙈
  • Affiliation: Center for Advanced Computation, U of Ill 🦋
  • NIC number: 17795 💜
  • Date: 15-17 July 1973 📅
  • Category and status: not stated in the original
  • Obsoletes and updates: none listed

Sunday evening, 15 July

The meeting kicked off around 1930 with Jim Michener running things 💅 After intros, everyone built an agenda for the rest of the meeting ✨

Elaine Thomas handed out copies of an Alternative Network Graphics Protocol so people could read it overnight before the discussion 📖🌙

Some people who had definitely said they'd come on Monday morning were absent, so the meeting adjourned at 2030 and everyone agreed to meet again at 0930 the next morning ⭐

Monday Morning/Afternoon, 16 July

The meeting was called to order at 0930 🌞

Jim Michener passed around an outline for a paper on the features that would be useful for two-dimensional input devices working with a hierarchically structured display program. Very main character energy 💖

Ken Victor shared copies of RFC 553: A Proposed Network Text/Graphics Protocol. The citation was (LJOURNAL,17810,) 📚

Ken Pogran walked everyone through the history of the NGG and how the "levels" approach from RFC 493 came about 🧚 The "level 0" protocol was basically an experiment, but the idea was that you should be able to put "level 0" meaningfully inside any later protocol 🔥

Reports of Network Graphics Experiences

Jon Jervert told everyone about the setup at CAD/CAM (Fort Monmouth) 🖥️ They have a mix of display terminals and tried a bunch of them over a Telnet connection to MIT-DMCG. The problem was that it was painfully slow at 300 Baud bandwidth 💀

Austin Henderson shared an Air Traffic Control experiment 🛫 The simulator takes in codes that describe changes in state, then spits out descriptions of the controlled airspace (region) along with aircraft position and velocity. These descriptions are super encoded, so they aren't pictures in any normal sense. The simulation ran at an adequate speed ✨

Jim Michener described an experiment where the E&S LDS-1 at MIT-DMCG generated stylus inking input for a character recognition program at SDC ✍️ It was a bit of a mess, with bugs in SDC's NCP and trouble scheduling experiment and debugging sessions. When it was finally shut down (because DMCG had big hardware changes planned), the team didn't have a clear understanding yet, but they did see network transmission delays of up to 20 seconds 😭

Dan Cohen described an Aircraft Flight Simulator that talks to a user at the Harvard PDP-1 ✈️ The simulation itself runs on a PDP-10. Network traffic is about 200 bits from the PDP-1 to the PDP-10, and several thousand bits going the other way 📊 They found that at least 5 updates per second are needed to give the "pilot" a decent feeling of control 🎮 They used the Harvard PDP-10 and one at BBN, and the BBN one ran at 6 AM to dodge loading problems 🌅

John Pickens described UCSB's status on output in level 0 Network Graphics Protocol (NGP-0) 🎀

Steve Bunch reported that he has an Imlac monitor that accepts NGP-0 directly 🫶 Programs built at CCN, using subroutine packages modeled on plotter packages, create files full of pictures in NGP-0. Other programs send those pictures either to a Gould plotter or a storage display (in device-specific code), or to an Imlac (in NGP-0 form) 💅

Steve Holmgren gave a quick rundown of a Fancy Arpa Network Graphics System (FANGS) that's being built at UCSD 🌈

Discussion of Graphics Input 💖

Okay so Dan Cohen summarized how input works in his flight simulator 🛩️. It only comes to about 200 bits in toto, so all the switches, knobs, and stylus position get transmitted. That happens about five times per second. Literally so efficient 🔥

Austin Henderson walked us through the input facilities on the LL TX-2 🎀:

  • Attentions are enabled. The info the app wants when a particular attention happens gets described right when that attention is enabled.
  • When an attention occurs, the system stores the wanted info in a queue for the application program.
  • The next time the application program gets scheduled, it checks the queue and responds however it sees fit.

Everyone was pretty much like "yesss, TX-2 strategy" and agreed to adopt it 🙌 Input devices won't be enabled unless the server enables them, so no sneaky stuff ✨

No restriction is placed on any "lies" the using host wants to tell about disguising one device as another. 🙈

Network connections for input follow the same rules as output 📡. Which input attentions get implemented at the using host can be figured out by the serving host by asking it 💅

Inking is provided by the using host, but only one inking input can be specified at a time, and the using host is not allowed to buffer ahead (no buffering ahead shall be done by the using host) 🖊️

Tracking means feeding the current two dimensional input device position back to the user 👀 It gets switched on automatically by Inking, Positioning, and Targeting (hitting) attentions. Main character energy, honestly 🦋

What data gets reported when an attention happens is specified by the application at the server when the attention is enabled 🧚 The types of attentions got listed, along with what extra optional info could be specified with each one 📝

Deactivating Inputs was discussed too 🫶 The application can explicitly deactivate an attention. When an attention is enabled, it shall be possible to specify when it should be deactivated. Three modes came up: never turned off (until the application explicitly does so), turned off when it occurs (self-destruct 💀), and turned off when any attention occurs. Everyone agreed a synchronization message was needed 🌸

It was agreed that the serving host and using host relationship would be master and slave 👑 Among other things, the using host would never volunteer input information the serving host (application) hadn't asked for. Boundaries, bestie 😌

It was decided to meet the next morning at 0830, and the meeting adjourned about 1830 🌙

Monday Evening, 16 July

About 2030, seven of us met in Ken Victor's room 🍓

Bob Sproul led the meeting and kept track of the various aspects of the protocol 📋 Protocol topics from the day's meeting got covered again. Most aspects got firmed up based on what we talked about during the day. A few topics got flagged for discussion in the morning ⏰

Operations on and attributes of segments were defined 🧩

The server should be able to ask the using host for various info 🔍:

  • Whether the using host has all the features implemented (which the application needs).
  • What input devices the human has at their disposal.
  • What sort of terminal is being used. Not to send device specific code to it, but so the application doesn't try some graphics programming technique on a terminal that can't handle it (e.g., some sort of dynamics on a storage tube) 📺

The server may request that the using host report what segments have been defined, their status, and what is contained in them. This is good for debugging, and it also gives a limited way to build a picture and then dump it to some storage medium other than a graphics device 💾

It was pointed out that the effect of multiple changes in the display (replacing, inserting and deleting segments) should occur "all at once" when an "end batch of updates" command is received by the using host ✨

  • For a refreshed display, this means keeping old and new copies of segments until the "batch" command is received.
  • This rule may be waived if storage limitations dictate.

There was considerable discussion on input. It was felt to be the least firm of any aspect of the protocol 🥺

The meeting broke up around 0030? 😭

Tuesday Morning/Afternoon, 17 July

Bob Sproul presented the results of the previous evening's discussion to the whole meeting 🎀

The features required of a graphics user program under the proposed protocol got divided into three classes:

  • Required features included segment manipulation, primitive graphics output operations, and responding to queries from the server about what is implemented at the using host, what input devices the human has available, etc. These are the non-negotiables 💅
  • Optional features included TTY units, and reporting the contents of a segment back to the server at its request.
  • Experimental features included Input.

It was assumed that after some experience, experimental features would become either required or optional 🔮

A full list of required, optional, and experimental features will be issued as a supplement to the description of the protocol 📄

A graphics server program only needs to implement the features that applications at that site make use of 🫶

There was some discussion about how and when the graphics protocol should be published 🤔

  • The protocol is still regarded as experimental, and we wouldn't want any site to assume otherwise, to their later dismay 😬
  • Some worry was expressed about finally presenting this protocol to the Network Community in a form that wouldn't frighten too many people 😳
  • Ira Cotton advised us to include a glossary 📚

Bob Sproul will put an initial version (skeleton) of a description of the graphics protocol for the transformed-segmented scheme into NLS, and will invite everybody in the group to edit it (in normal NLS fashion) 💻

When you edit normally, your ident, the date and the time are associated with each statement you touch. That info can be seen via the viewspec (capital) K 🕵️‍♀️

There was some discussion of whether Level 0 NGP could be imbedded in the Transformed-segmented graphics protocol 🧁

One unfortunate part of NGP-0 was that an End-Picture is not explicitly required in order to see something. If it were required, then it could act like an end-batch-of-updates command. 🙃

UCSB assumes that NGP-0 works like a storage tube. They append a new function plot to an existing picture, never having sent an End-Picture operation 🖍️

This ability to append in a storage tube fashion struck the processors of refresh tubes as quite a drawback, because of implementation difficulties 🥴

It was decided to allow a using site to have NGP-0 compatibility, but not to require it ✌️

  • At the very least, the NGP-0 opcodes would not be reused.

Except for the End-Picture problem, and possibly also a coordinate system problem (coordsys), NGP-0 can be imbedded in the transformed-segmented protocol, with the entire NGP-0 picture corresponding to a single segment 🧩

The following sites hope to achieve implementations of the experimental segmented protocol 🌈

  • UCSB hopes to have a server running for OLS and Signal Analysis (speech processing).
  • SRI-ARC hopes to have NLS operate in this protocol.
  • MIT-DMCG may have some simple serving programs.
  • Several people plan to implement user programs, at least as far as the required features go.

(coordsys) A discussion came up about what coordinate system should be used when sending graphics output primitives from the server to the user 📐 These problems were addressed:

  • What happens if the display segment terminal screen area to be used by the application is not rectangular?
  • What happens if the basic unit delta X is not the same as the unit delta Y? The application might want a 45 degree line to really be at 45 degrees 📏

Various answers to the first question:

  • Use the largest square within the rectangle (centered?, adjusted to the left, top, right, or bottom?).
  • Use the smallest square surrounding the rectangle. (How is the rectangle positioned in the square?)
  • NGP-0 standard coordinates (-1/2 to +1/2) used and mapped into the whole rectangle.
  • The user reports left, bottom, right, and top physical coordinates, and the server sends coordinates within the range given.
    • This is compatible with the attitude that the transformed (!) segmented graphics data are sent.
    • It also saves the using host (which might be an Imlac) from doing a multiply 🙌

John Pickens observed that if a graphics server for a finicky application transmits characters as strokes, then the application is assured of having the characters positioned in exactly the right place (e.g., for a numeric label on a tic mark on the axis of a graph). If characters are sent as text (not strokes), positioning is not necessarily guaranteed 🎯

Ken Victor and Jim Michener will look into ways of keeping the NGG apprised of progress (in terms of what sites have experimental/operational graphics protocol servers or user programs) using a pointer file in the NIC 📁

The next NGG meeting is tentatively scheduled for the first Sunday in February 73, at 8PM. It will either be at the NIC, or partly there and partly at Xerox PARC 🗓️

The meeting was adjourned at 1500 🦋

Appendix: Meeting Participants/ Affiliation/ Online mailing address/ Attendance (S=Sunday, M=Monday day, E=Monday Evening, T=Tuesday)

   Steve Bunch     ILL-ANTS
      BUNCH@ISI
      SMT

   Dan Cohen     Harvard
      DCOHEN@ISI or COHEN@HARVARD
      SMET

   Ira Cotton     National Bureau of Standards
      NBS-TIP@NIC attention Ira Cotton
      SMET

   John Day     ILL-ANTS
      S

   David Egli     CAD/CAM (Fort Monmouth)
      ECOM@BBN
      SMT

   Jim Hansen     ILL-ANTS
      HANSEN@ISI
      SMT

   Jim Hart      NASA/Ames
      MT

   Austin Henderson     Lincoln Labs
      DAH@TX2 or DAH@BBN
      SMET

   Steve Holmgren     ILL-ANTS
      HOLMGREN@ISI
      MT

   John Jervert     CAD/CAM (Fort Monmouth)
      ECOM@BBN
      SMT

   Alex McKenzie     BBN
      AAM in the journal or MCKENZIE@SRI-ARC
      SMT

   James Michener     MIT-DMCG
      JCM in the journal or JCM@DMCG
      SMET

   John Pickens     UCSB
      JRP in the journal or UCSB@ISI (attn: John Pickens)
      MT

   Ken Progran     MIT-Multics
      Pogran.CompNet at MIT-MULTICS
      SMT

   Bob Sproul XEROX
      SPROUL@MAXC
      MET

   Elaine Thomas     BBN
      THOMAS@BBN
      SMET

   Ken Victor     SRI-ARC
      VICTOR@NIC
      SMET
         [ This RFC was put into machine readable form for entry ]
               [ into the online RFC archives by Via Genie ]
📦 where this page comes from