RFC 493

Document Type RFC - Unknown (April 1973; No errata)
Obsoletes RFC 292
Last updated 2020-11-14
Stream Legacy stream
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 493 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        J. Michener
Request for Comments: 493                                            MAC
NIC: 15358                                                     I. Cotton
References: 282, 258                                               MITRE
Obsoletes: 292                                                 K. Kelley
                                                              U. of Ill.
                                                               D. Liddle
                                                              Ownes Ill.
                                                                E. Meyer

                           GRAPHICS PROTOCOL


   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.

   This document is intended to serve as a basis for discussion and for
   experimentation over 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 Group).

   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 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 integrated with the graphics input byte stream,
   since it involves most of the problems related to synchrony of
   independent hosts.

Michener, et. al.                                               [Page 1]
RFC 493                    GRAPHICS PROTOCOL               26 April 1973


   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

Levels and Ground Rules Pertaining Thereto

   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
   inclemently.  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 long as
   the commands and data take advantage only of strictly 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
Show full document text