Graphics Protocol: Level 0 only
RFC 292

Document Type RFC - Unknown (January 1972; No errata)
Obsoleted by RFC 493
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 292 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                     12 January 1972
Request for Comment: 292                                Jim Michener, MAC
NIC 8302                                                Ira Cotton, MITRE
References: 282, 285                              Karl Kelley, U. of Ill.
Updates: None                                     Dave Liddle, Owens Ill.
Obsoletes: None                                             Ed Meyer, MAC

                   GRAPHICS PROTOCOL - LEVEL 0 ONLY


   This document reflects opinions expressed and decisions reached at
   the second meeting of the Network Graphics Group, held at the
   Stanford Artificial Intelligence Laboratory in late November 1971.
   It describes part of a proposed Network Standard Graphics Protocol
   for transmitting graphics data within the ARPA network.  The
   particular aspects of the protocol covered in this document relate to
   the form and content of graphics information sent from a source of
   graphical information (an application program, say, in the "Serving
   Host") to a display package for output to a graphics console (at the
   "Using Host").  This will take the form of a sequence of 8-bit bytes,
   and will be called the graphics output byte stream.  In particular,
   only the simplest forms of graphics data will be covered in this, the
   first version of this document.  The next version, already in
   preparation, will be much more complete.  In any case this is not
   intended to describe a finished protocol; rather it should serve as a
   basis for graphics experimentation on the network.

   This document does not include form or content of graphics input
   (data sent from the Using Host to the Serving Host) nor does it cover
   how the connection is established between the hosts.  A proposal for
   the former will be generated eventually by this committee; the latter
   is the job of the Connection Committee (of the Network Graphics

   This RFC describes the commands which are available in the protocol
   in terms of the effect they would have at the receiving (Using Host)
   end.  Clearly, some subroutine package is desirable at the Serving
   Host for use by applications package in transmitting graphics data,
   but on this topic this RFC does not intend to comment.

   It may be observed by the reader that no facility is specified in
   this protocol allowing the Using Host to report logical errors in the
   graphics output byte stream to the Serving Host.  Such a facility
   would have to be intergrated with the graphics _input_ byte stream,
   since it involves most of the problems related to synchrony of
   independent hosts.

Michener                                                        [Page 1]
RFC 292                Graphics Protocol Level 0            January 1972


   The reader should probably peruse RFC 282: "Graphics Meeting Report"
   by Mike Padlipsky to obtain some of the framework surrounding this
   discussion of network graphics.  Also it might be valuable to make
   note of the model described in RFC 285: "Network Graphics" by Donald


   Functions within the graphics protocol will be classified into a
   number of levels depending partly on how difficult it is to implement
   those functions.  It is intended that any host which claims to
   implement the functions of level N must implement all lower levels as
   well.  Thus, it is envisioned that sites will implement levels
   incremently.  Implementations will be improved as a continuing
   process to include more and more functions, and it is intended that
   each implementation will be able to identify its own level to a
   graphics protocol at a remote site which is requesting a graphics
   interchange.  A side result is that each site will be able to
   determine its own priorities in committing programmers to the
   graphics protocol as opposed to other efforts.

   It is also our intention that implementation of level N will require
   no knowledge of level N+1.  Thus a site can implement a level in the
   (reasonably) firm knowledge that no changes at higher levels will
   alter the level implemented.  At some time it may be decided by the
   Network Graphics Group to redefine a level which has previously been
   firmed up.  It is not our intention that this shall happen but one
   must recognize that the proposed Graphics Protocol is experimental
   and may have to be changed.

   One further ground rule:  a stream of commands and data which is
   valid at a given level, K, shall produce "identical" results on any
   interpreter of level K or higher.  By this we mean that as defined
   operations, similar pictures should result.  Aspects of the protocol
   which are not strictly defined (at this time) include character size,
   character position relative to the beam, how control characters in
   text output affect the terminal and what happens when the beam is
Show full document text