Draft design for a text/graphics protocol
RFC 553

Document Type RFC - Unknown (July 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 553 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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


   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

   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

   Consequently, we are proposing that the graphics protocol be
   implemented within telnet using 8-bit BEGIN-GRAPHICS-COMMAND and
   END-GRAPHICS-COMMAND characters or the 8-bit transparent mode of the
   new telnet.  This means that one will be able to run graphics
   programs with one, two, or more sets of telnet connections.

   We also strongly propose that any site which is interested in
   supporting display terminals for use in network graphics would be
   prudent to implement local control over the display (such as IGNORE-
   GRAPHICS-COMMANDS, RESET-TO-TTY-MODE commands from the user to the
   using host).  Failure to take such precautions may very well lead to
   burned out tubes!

Basic concepts

   The model

      The model we are adopting consists of an application program
      manipulating a (remote) display file.  This file may be
      "segmented" or "structured", in which case it may be manipulated
      independently from the display itself.

         For structured display files an "update display" command causes
         the display file to get mapped onto the display in whatever
         fashion is appropriate for the display.

Irby, et. al.                                                   [Page 2]
RFC 553        Draft design for a text/graphics protocol    14 July 1973

      Part of this protocol deals with commands issued to the (remote)
      display file editor.  This editor creates and changes the display
      file at the user host.

   Structured Display Files

      A structured display file consists of named subpictures, each
      containing any number of named units.  There are two types of
Show full document text