Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Draft design for a text/graphics protocol (RFC0553)

IP.com Disclosure Number: IPCOM000005912D
Original Publication Date: 1973-Jul-14
Included in the Prior Art Database: 2001-Nov-15
Document File: 20 page(s) / 36K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C.H. Irby: AUTHOR [+2]

Abstract

DRAFT DESIGN FOR A TEXT/GRAPHICS PROTOCOL

This text was extracted from an ASCII text 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...