Browse Prior Art Database

Draft design for a text/graphics protocol (RFC0553)

IP.com Disclosure Number: IPCOM000005912D
Original Publication Date: 1973-Jul-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 19 page(s) / 23K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C.H. Irby: AUTHOR [+1]

Related Documents

10.17487/RFC0553: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 10% of the total text.

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.

Environment

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...

Processing...
Loading...