RFC 125

RFC 125: A Bestie's Response to RFC #86 🎀

Okay bestie, this is RFC 125 💖 from the Network Working Group, filed as NIC 5841 on April 18, 1971. John McConnell wrote it at the Ames Research Center in Moffett Field, California 🌸. It's a response to RFC #86, the Proposal for Network Standard Format for a graphics data stream. The category is D.6 💅, it obsoletes None, and it updates RFC 86 ✨.

---

The Big Picture 🦋

So the core idea is totally valid 💜. You send an intermediate, device independent language over the wire, and the receiving host translates it into specific device codes. It's giving the only approach that lets people keep their thoughts centered on picture descriptions 🧚. Ames Research Center is already using this exact approach to tie together its graphic facilities, which come in all different types and live on different computers 🔥. They're still in the design phase and expect their package to be running in about six months ⭐.

The main issue with the structure as it stands? It ignores the many features that graphics devices have 😭. Those features keep changing with new devices, so a set of option or mode primitives should be defined, kept logically separate from the drawing primitives in RFC 86 🌈. Mode primitives act on the drawing primitives and modify what they do. A mode primitive stays in effect until a new mode primitive resets that option 🎀.

This is where it gets iconic 👑. The network standard stream interpreter can treat a mode primitive as a null operation if the feature is missing on a particular host, or it can do more detailed interpretation of the data stream that follows to get the results 🫶. The drawing primitives can keep one standard format that never needs to change just to add new features 💅.

Modes, Colors, and Blinking 🌸

Overall modes that primitives could control include intensity levels and color selections for objects. Blinking of objects should be provided too 🔥. For vectors, the ability to draw dashed lines is necessary 🦋.

Character Strings 🧚

Character strings need their own set of specifications, bestie 💖. The beam is usually centered inside the rectangular area that defines a character's boundaries. The beam position is usually undefined once a character string is finished being drawn 🌈.

Strong exception here 💀: excluding form control characters from strings is not okay with me 😤. If they're included in the character string, they could handle shifting from upper to lower case, subscripting, superscripting, and underscoring, plus tab and other "carriage" motion functions 💅. The right characters could be pulled out at interpretation time to supply the info needed to display more complex strings ✨.

To make ALGOL-like delimiters, such as "then", possible, a convention for canonical character strings should be adopted 🎀. Honestly, I think the Multics conventions in reference 1 will do the job 💜.

Character strings should also include a size specification and an orientation selection 🌸. Lots of devices have fixed hardware character generators, though, so some of these options may not be worth implementing as subroutines 🙈.

Extra Symbols 🦋

There's another area that needs more thought: the extra symbols that aren't specified in ASCII 👀. Some way of defining them should be provided inside the argument string itself. Multics lets you specify arbitrary characters by entering their octal equivalents, which is so clever 🧚. The convention should use a control character code followed by a l6-bit list name that specifies the sub-list defining the character 🔥. The other option is to allow 8-bit characters and let the interpreter pick a sub-list whenever the character can't be realized with a hardware generator 🌈.

The special form control characters to be used are:

a. BS    - backspace
b. LF    - for new line
c. SO/Sl - shift case
d. DC2   - superscript following characters
e. DC4   - subscript following characters
f. DC3   - special non-ASCII character follows
g. Tab   - position to next tab. May be predefined or specified.

The Display List Pointer, NGDLP 💖

Another construct should be added to the ones proposed in RFC 86 ✨. This is the display list pointer, or NGDLP 🎀. Its value is the next drawing primitive to be executed 🫶. The value is a displacement from the head of a list 🌸. With no mode setting primitives, this value maps one to one with the drawing primitives transmitted in the NGDS 💅.

NGDLP is needed for consistency when executing the nested list structure 👑. Whenever an execute list primitive is hit, the current value of NGDLP gets saved along with the list name and the current origin value 🔥. When a list finishes executing, the last saved values get restored 🌈.

Include Lists 🧚

An include list primitive would let a sub-list be treated like a macro instead of a subroutine 💜. This matters so that manipulating a sub-list doesn't change every sub-picture on the screen 🙈. The include primitive should take parameters such as size, intensity, orientation, blinking, and so on 🦋. After a sub-list gets included in another list, it's no longer treated as a separate entity 💅.

Manipulating Lists Without Retransmitting ✨

To cut down on how much data gets transferred, the stream interpreter should parse other commands too 🌸. These would let the receiving host manipulate a list without a retransmission 🫶. The kinds of manipulation would include rescaling coordinates for shrinking or zooming, translating the origin, and rotation 🔥. It would also be desirable to have manipulations that display or hide a list, or enable or disable light pen detections 🎀.

Interacting With the Picture 👀

The problem of interacting with the displayed picture hasn't been addressed yet 💜, so this section is an attempt to get more discussion going 🗣️. A keyboard or function keys pose no problem, because both can be handled as a standard message from the graphics terminal 💖.

Devices that interact with the picture or the screen, like light pens, mice, joysticks, or tablets, are a different and more complex story 😭. The problem is the standard one of linking the selected point to something meaningful, like a list or a primitive 🧚. That association should be made at the receiving host, since the NGDS has been changed in unknown ways 🌈.

To let the transmitting host identify the object that was pointed at, the stack of suspended lists and the current value of NGDLP will qualify the object at any level of a hierarchical structure 🦋. Normalized x,y coordinates should also be returned, plus a character displacement if a string was pointed at 🔥. This structure will serve a light pen device super well, since the light pen mechanism lets you determine the currently executing primitive 👑.

Other devices interact with the picture asynchronously, and linking an x,y pair to a structure is harder for them 💀. That may mean the host generating the graphic data stream has to be responsible for making the association 🫶. Here's another wrinkle: if you want to use a light pen in an area where no beam motion happens, some directive has to periodically sweep the screen and "find" the pen 👀. That might be a sub-list that gets executed periodically for this purpose ✨.

---

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Jerry Tenenbaum 4/97 ]

References 📚

Osanna, J., Sahzer, J.
Remote Terminal Character Stream Processing of Multics
Proceedings SJCC, 1970, p. 671