Draft design for a text/graphics protocol (RFC0553)
Original Publication Date: 1973-Jul-01
Included in the Prior Art Database: 2019-Feb-12
Internet Society Requests For Comment (RFCs)
C.H. Irby: AUTHOR [+1]
Network Working Group C. Irby Request for Comments: 553 K. Victor NIC: 17810 SRI-ARC 14 July 1973
Draft design for a text/graphics protocol
DRAFT DESIGN FOR A TEXT/GRAPHICS PROTOCOL
This proposal should be seen as a synthesis of existing ideas rather than an attempt to put forth new ones. It is based on work by the NGG, Elaine Thomas, Peter Deutsch, Charles Irby, Ken Victor, Bill Duvall, Bob Sproull, and others at ARC, PARC, and BBN.
We are concerned about the lack of text-handling capabilities of the protocol suggested in RFC 493. Also, we feel that the protocol will have a significant influence on the interface provided to writers of future graphics application programs, and consequently that such things as "beam twiddling" should not be part of the protocol.
Things of this nature address the problem at too low a level for a facility which is intended to service the needs of a wide range of graphics devices.
We feel that, although the breakdown into "levels" as proposed in RFC 493 may be expedient for initial experimentation, it is inappropriate for a Network Standard Protocol. Instead, we propose that the protocol allow for two levels, segmented and structured. This allows the writers of graphics application programs to deal with a very simple display facility (segments consisting of lines, dots, or character strings) or with a powerful structure of display subroutines.
We propose an experimental implementation of such a scheme on the ARC, BBN, and PARC systems to test these ideas using several application programs (including NLS) and at least an IMLAC, ARDS, and an E&S LDS.
We are trying to design a protocol used to communicate with a "virtual display" to operate at the other end of a wire (ARPANET connection) from a "host" which is running some kind of display application program.
Irby, et. al. [Page 1]
RFC 553 Draft design for a text/graphics protocol 14 July 1973
We will adopt the terminology that the human user, sitting at the display, is the "user" and the application program is the "server".
We wish to stress the fact that within a single application, a single terminal should be useable both as an "interactive graphics" terminal AND as an "interactive control" terminal. Thus, the graphics protocol must allow for teletype-like operations.
The need for two sets of connections for running graphics programs over the Net (according to our understanding) is centered about the issue of handling (being able to recover gracefully from) berserk programs (and perhaps achieving greater bandwidth through the net).
We recognize this problem but also think one should be able to run graphics programs using only one set of telnet connections. Also, it seems obvious that even though one is running a graphics program, one must expect to be able to handle "unescorted" characters (not embedded in a command or response message) being sent to his terminal.
Consequently, we are proposing that the graphics protocol be implemented within telnet u...