doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc553.txt b/doc/rfc/rfc553.txt
new file mode 100644
index 0000000..db247ce
--- /dev/null
+++ b/doc/rfc/rfc553.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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 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
+      units, primitive units and call units.  The effect of a unit is
+      independent of its name or creation within the subpicture.
+
+         Primitive units contain drawing instructions and associated
+         coordinates that may generate visible information on the
+         display screen.  Drawing instructions and coordinates can occur
+         only in primitive units.
+
+         Call units give the display structure a subroutine capability.
+         A call unit invokes the display of another subpicture.  In
+         other words, a call unit allows one subpicture to contain
+         instances of other subpictures.  As well as providing for
+         subroutine-style control transfer, call units can be used to
+         establish display parameters and maintain parameter
+         transparency.  For example, a call unit can be used to call a
+         subpicture with a translation and relative intensity setting.
+         On return from the called subpicture, these parameters are
+         restored to their original values.
+
+         A subpicture is an ordered list of units which can be any
+         mixture of primitive and call units.  Each subpicture begins
+         with a header and terminates with the subpicture end unit.  The
+         subpicture end unit is a single unique unit in a display
+         structure linked to the end of each subpicture.
+
+         In order to understand how control passes through a structure,
+         one can think of the display elements as follows: subpictures
+         are subroutines and units are linked blocks of in-line code.
+         When all of the units contained in a subpicture have been
+         executed, the subpicture end unit returns control to wherever
+         the subpicture was called from.  A primitive unit contains
+         display code and transfer to the next unit.  A call unit
+         contains a subroutine call to a subpicture and a transfer to
+         the next unit in line.
+
+
+
+
+
+
+
+
+
+Irby, et. al.                                                   [Page 3]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+   Segmented Display Files
+
+      A segmented display file consists of named segments, each
+      containing any number of primitive units.  The only operations
+      available for segmented display file is to add new, delete old, or
+      replace old segments (updating the actual display happens
+      automatically).  The effect of a unit is independent of its name
+      or creation order within the subpicture.
+
+   Hosts
+
+      Since a given terminal may be under partial control of several
+      different hosts, all further discussion of names, coordinates,
+      display files, etc. should be taken as relative to each individual
+      host.
+
+      That is, each host believes it has a display file, naming, and
+      coordinate space and a set of state parameters entirely under its
+      control; its only evidence of resource sharing is that the
+      terminal may appear to be of different sizes at different times.
+
+      (We feel that in principle it should be processes within hosts,
+      rather than hosts, that enjoy these properties, but it does not
+      seem feasible to construct a process identification scheme that
+      all hosts will find acceptable.)
+
+   Subpictures
+
+      A subpicture has a name and zero or more units.
+
+         Subpicture names are arbitrary, globally unique, fixed-length
+         identifiers (subpicture names are chosen by the host).
+
+         Each unit (displayable component) has a name, which is local to
+         the subpicture.
+
+      A unit may be a "primitive unit", such as a string or a vector, or
+      a "call unit", which implies displaying a (possibly transformed)
+      copy of another subpicture.
+
+         The display data are organized into a re-entrant tree (acyclic
+         graph) by the call units.
+
+      A unit may be "visible" or "invisible".
+
+
+
+
+
+
+
+Irby, et. al.                                                   [Page 4]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+         A particular instance of a subpicture (the result of a call-
+         unit) appears on the screen precisely if it and all subpictures
+         on the logical path to it from the root of the tree are
+         "visible".
+
+   Primitive units
+
+      Strings
+
+         A string is a horizontal line of characters with its own mode
+         and X,Y origin relative to the origin of the subpicture.
+
+            Note: intensity is always relative.
+
+         Font and mode (e.g. blinking) information logically accompanies
+         each character.  This is accomplished by means of embedded mode
+         and font specification characters and a "restore original
+         string mode and font" character.
+
+            Note: Mode modifiers are non-displayable characters and do
+            not take up character positions on the screen.
+
+         Determining the space occupied on the screen by a string
+         requires knowledge of the font(s) being used; this is a
+         separate question which is dealt with later.
+
+   TTY units
+
+      A tty unit is a rectangle that consists of a number of lines.
+      Within this unit the display acts as if it were an alpha-numeric
+      display, e.g.,
+
+         characters which would write beyond the right hand margin of
+         the rectangle cause an automatic line folding to take place
+
+         ascii control characters CarriageReturn, LineFeed, FormFeed,
+         and BackSpaceCharacter, (HorizontalTab and VerticalTab?), are
+         interpreted appropriately
+
+         other control characters are displayed in a terminal specific
+         manner, e.g. ^F, <^F>, etc.
+
+         display of the characters in the range 200-377 is left
+         unspecified at this point (truncated to 7 bits?, alternate
+         fonts?, alternate modes?)
+
+
+
+
+
+
+Irby, et. al.                                                   [Page 5]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+            It is hoped that we can agree on a standardization of some
+            of the characters in this range to allow for such things as
+            greek letters, common mathematical symbols, super-scripting,
+            and sub-scripting.
+
+         linefolding that would cause characters to be written below the
+         rectangle (whether performed automatically or by a LineFeed
+         character, etc.) cause the text within the unit to be scrolled
+         upwards one line (storage tube may adopt a different scheme).
+
+      Characters are displayed in a teletype unit in one of two ways:
+
+         Characters sent to the terminal that are not part of any
+         command (unescorted characters) are appended to appropriate
+         tty-units (see below --- USE-TTY-UNITS, TTY)
+
+         By use of the APPEND-STRING-TO-UNITS command for structured
+         display files
+
+      The first character sent to a tty-unit appears as the first
+      character (at the left margin) of the top line.  This is necessary
+      for a number of reasons, the most convincing of which is the
+      behavior characteristics of storage tubes and most real alpha-
+      numeric displays.
+
+         Successive characters appear as successive characters within
+         the top line until either an explicit (e.g., linefeed) or
+         implicit (line overflow) line break occurs.
+
+         When a line break occurs, the next character appears on the
+         second from the top line of the unit.
+
+         This continues until the bottom line of the tty-unit is
+         reached.
+
+            At this point, a line break causes the lines within the unit
+            to scroll up one line.
+
+               Note: Storage scopes may use a different technique for
+               scrolling.
+
+      Dots
+
+         A dot unit consists of an initial X0,Y0 followed by a series of
+         points X,Y which describe a series of dots.
+
+         Each dot unit logically carries mode information such as
+         blinking, relative intensity, etc.
+
+
+
+Irby, et. al.                                                   [Page 6]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      Lines
+
+         A line unit consists of an origin X0,Y0 followed by a series of
+         points X,Y which describes a series of straight lines connected
+         tail-to-head (i.e. a polygon).
+
+         Each line unit logically carries mode information such as
+         blinking, dotted vs. solid, invisible.
+
+         Other kinds of lines, such as conic sections, may belong in the
+         primitive set.
+
+      Special points
+
+         This primitive unit consists of a series of points, which will
+         be displayed joined by lines in the best available manner.
+
+         The intent is to use Flegal's algorithms to produce a smooth
+         curve.
+
+      Device-specific
+
+         This primitive unit consists of any number of device specific
+         commands.  The device type may be obtained through an
+         interrogation command.
+
+   Call units
+
+      In addition to the name of the referenced subpicture, a call unit
+      may include the following transformations:
+
+         Master/instance rectangle: specifies a rectangle in the
+         caller's space into which a specified rectangle of the callee's
+         space is to be imaged.  This provides independent scaling in
+         each coordinate as well as translation and clipping.
+
+         Rotation.  It may be desirable to combine this with scaling
+         using the familiar idea of homogeneous transformation.
+
+         Intensity and color control.  In principle, a call could
+         specify intensity increments (positive or negative) for each
+         color.
+
+         It is assumed that best effort will be used in scaling and
+         rotation of text.  We recommend replacing it by a line when all
+         else fails.
+
+
+
+
+
+Irby, et. al.                                                   [Page 7]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+   Initial state
+
+      After the initial telnet connection is established, the first
+      graphics command issued by the applications program should be a
+      request for either a structured display file or for a segmented
+      display file.
+
+         The response to this request should be whether or not the
+         requested display file was allocated and other parameters about
+         the virtual display, e.g. screen size, character sizes, whether
+         or not color is available, etc.
+
+      Before the display file is allocated, the terminal should appear
+      as, and simulate to the best of its ability, a Network Virtual
+      Terminal (NVT).
+
+      Any graphic commands issued before the allocation of a display
+      file will be ignored.
+
+      After requesting commands and receiving a structured display file,
+      the following structure will exist:
+
+         There will exist a subpicture, referred to as the ICP
+         SUBPICTURE, whose rectangular extent corresponds to the extent
+         of the virtual display allocated to this host.
+
+         There will exist a tty-unit, referred to as the ICP TTY-UNIT,
+         in the ICP SUBPICTURE, where rectangular extent corresponds to
+         the extent of the virtual display allocated to this host.
+
+            This tty-unit will consist of n lines, where n is terminal
+            dependent and available through a query command.
+
+            This tty-unit will be instituted for the display of
+            unescorted characters.
+
+         There will be in effect an implicit call on the ICP SUBPICTURE.
+
+            This call is not accessible to the applications program.
+
+         The applications program causes the display of information by:
+
+            1) creating primitive units in the ICP SUBPICTURE
+
+            2) creating call units, to created subpictures, in the ICP
+               SUBPICTURE
+
+
+
+
+
+Irby, et. al.                                                   [Page 8]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+            3) using the TTY command to make visible/invisible the ICP
+               TTY-UNIT (or change its location or size)
+
+      After requesting and receiving a segmented display file, the
+      following structure will exist:
+
+         There will exist a segment, referred to as the ICP SEGMENT.
+
+            There will exist a tty-unit, referred to as the ICP TTY-
+            UNIT, in the ICP SEGMENT, whose rectangular extent
+            corresponds to the extent of the virtual display allocated
+            to this host.
+
+            This tty-unit will consist of n lines, where n is terminal
+            dependent and available through a query command.
+
+            This tty-unit will be instituted for the display unescorted
+            characters.
+
+         The applications program causes the display of information by:
+
+            1) creating primitive units in the ICP SEGMENT
+
+            2) creating new segments
+
+            3) using the TTY command to make visible/invisible the ICP
+               TTY-UNIT (or to relocate it or change its size)
+
+Display editing primitives
+
+   General editing primitives
+
+      REQUEST-DISPLAY-FILE (file-type)
+
+         file-type is either structured or segmented.
+
+         This command requires a response.
+
+   Segmented display file editing
+
+      SEGMENT (Segment)
+
+         If the segment Segment already exists, then it is cleared; if
+         it did not exist then it is created.
+
+         Pictures are displayed within segments by the use of the
+         primitive unit command listed below.
+
+
+
+
+Irby, et. al.                                                   [Page 9]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      DELETE-SEGMENT(Segment)
+
+         If the segment exists, then it is deleted.
+
+      Primitive Units
+
+         All unit operations cause immediate display on the screen.
+
+         STRING-UNIT(Segment,Mode,X-Origin,Y-Origin,Text)
+
+         Writes the specified string unit.
+
+         Mode refers to relative intensity, blinking, reverse video,
+         color, etc.
+
+         Errors: Segment does not exist.
+
+      LINE-UNIT(Segment,Type,Mode,X0,Y0,X1,Y1, ..., Xn,Yn)
+
+         Draws the specified line segments.
+
+         Type refers to solid, dashed, dotted, etc.
+
+         Errors: Segment does not exist; illegal mode.
+
+      DOT-UNIT(Segment,Mode,X0,Y0,X1,Y1, ..., Xn,Yn)
+
+         Draws the specified dots.
+
+         Errors: Segment does not exist; illegal mode.
+
+      SPECIAL-POINTS-UNIT(Segment,Mode,X1,Y1, ..., Xn,Yn)
+
+         Draws the special-points curve.
+
+         The terminal should attempt to connect the specified points in
+         the nicest way possible (e.g. Flegal's spline curve algorithm,
+         straight line segments).
+
+         Errors: Segment does not exist; illegal mode.
+
+      TTY-UNIT(Segment,Mode,Rectangle,Lines)
+
+         Creates a unit which will behave as a tty-simulation area with
+         "lines" lines distributed within the specified rectangle.
+
+         Unescorted characters will be echoed in this unit in addition
+         to any other units they are being sent to.
+
+
+
+Irby, et. al.                                                  [Page 10]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+         Errors: Segment does not exist.
+
+      DEVICE-SPECIFIC-UNIT(Segment,device commands)
+
+         Creates a unit of device specific commands.
+
+      TTY(parameters)
+
+         parameters are:
+
+            position rectangle, visible/invisible, number of lines, mode
+            of characters
+
+         This refers to the ICP TTY simulation.
+
+      RESET()
+
+         delete all segments, except ICP SEGMENT, and all units of ICP
+         SEGMENT, except ICP TTY-UNIT
+
+         resets all nodes to their initial state (i.e., the state that
+         existed immediately after a REQUEST-DISPLAY-FILE command)
+
+Structured display file editing
+
+      SUBPICTURE(Subpicture, rectangle)
+
+         Creates a new subpicture with name "Subpicture".  "rectangle"
+         is the coordinates of a diagonal of the subpicture's virtual
+         screen (i.e. its coordinate system.)
+
+         If a subpicture named "Subpicture" already exists, it is
+         cleared and the new coordinate rectangle takes precedence.
+
+      DELETE-SUBPICTURE(Subpicture)
+
+         Deletes the subpicture named "Subpicture".  Call units
+         referring to Subpicture are also deleted.
+
+      CLEAR-SUBPICTURE(Subpicture)
+
+         Deletes all units of the subpicture Subpicture, but does not
+         delete the subpicture.
+
+
+
+
+
+
+
+
+Irby, et. al.                                                  [Page 11]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      Primitive Units
+
+         All the operations for creating units are transparent to the
+         prior existence of the designated unit, i.e. they function as
+         "replace" as well as "create".
+
+            STRING-UNIT(Subpicture,Unit,Target-Key,Mode,X-Origin,Y-
+            origin,Text)
+
+               Replaces the unit by a string unit.
+
+               Mode specifies the mode of the characters (e.g. blinking,
+               underlined, etc).
+
+            Target-Key is used in conjunction with the TARGET-SENSITIVE
+            command and target input.  It may also be sent via the SET-
+            TARGET-KEY COMMAND.
+
+            Errors: Subpicture does not exist; X-Origin or Y-Origin is
+            outside the subpicture's virtual coordinate system.
+
+               We explicitly do not require an error if the string
+               extends beyond the right-hand edge of the subpicture;
+               however, the results are not defined.
+
+         LINE-UNIT(Subpicture,Unit,Target-Key,Type,Mode,X0,Y0,X1,Y1,
+         ..., Xn,Yn)
+
+            Replaces the unit by a line unit.
+
+               Errors: Subpicture does not exist illegal mode; some X or
+               Y is outside the subpicture.
+
+         DOT-UNIT(Subpicture,Unit,Target-Key,Type,Mode,X0,Y0,X1,Y1, ...,
+         Xn,Yn)
+
+            Replaces the unit by a dot unit.
+
+            Errors: Subpicture does not exist; illegal mode; some X or Y
+            is outside the subpicture.
+
+         SPECIAL-POINTS-UNIT(Subpicture,Unit,Target-Key,Type,Mode,X1,Y1,
+         ..., Xn,Yn)
+
+            Replaces the unit by a special-points unit.
+
+            Errors: Subpicture does not exist; illegal mode; some X or Y
+            is outside the subpicture.
+
+
+
+Irby, et. al.                                                  [Page 12]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+         CALL-UNIT(Subpicture,Unit,Target-Key,Called-
+         Subpicture,Parameters)
+
+            Replaces the unit by a call unit.
+
+            Parameters:
+
+               Master-Instance rectangles
+
+               rotation
+
+               mode
+
+            Errors: Subpicture does not exist; Called-Subpicture does
+            not exist; parameter errors.
+
+         TTY-UNIT(Subpicture, unit, mode, rectangle, lines)
+
+            Creates a unit which will behave as a tty-simulation area
+            with "lines" lines distributed within the specified
+            rectangle.
+
+            Errors: Subpicture does not exist.
+
+         DEVICE-SPECIFIC-UNIT(Subpicture, Unit, Target-Key, device,
+         commands)
+
+            Creates a unit of device specific commands.  The action of
+            the commands should leave alone (or at least restore) any
+            global modes, e.g., the standout mode (see below).
+
+      APPEND-STRING-TO-UNIT(Subpicture, Unit, Text)
+
+         Appends the specified text to the specific commands.  This only
+         makes sense if the specified unit is a string or tty unit.
+
+         Errors: Subpicture does not exist, unit does not exist, not a
+         string or tty unit.
+
+      DELETE-UNIT(Subpicture, Unit)
+
+         Deletes a unit.
+
+
+
+
+
+
+
+
+
+Irby, et. al.                                                  [Page 13]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      VISIBLE-UNIT(Subpicture, Unit, Flag)
+
+         Makes the Unit visible or invisible as specified by Flag.  If a
+         unit which is target sensitive is made invisible, it is no
+         longer target sensitive.  However, in the absence of a
+         subsequent modifying target sensitive command, the unit becomes
+         target sensitive again if it should be made visible.
+
+         Errors: Subpicture does not exist, unit does not exist.
+
+      SET-TARGET-KEY(Subpicture, Unit, Target-Key)
+
+         Sets the target key for the specified unit to the specified
+         value.
+
+      SET-STANDOUT-MODE(mode)
+
+         Sets the mode that will be used to make text and/or units stand
+         out to blinking, underlining, etc.
+
+         If the terminal does not support the specified mode, the
+         terminal should make a best effort or use another method to
+         make things stand out.
+
+      STANDOUT-UNIT(Subpicture, unit, yesno)
+
+         makes the specified unit stand out (according to the mode set
+         by SET-STANDOUT-MODE) or not, according to "yesno".  If the
+         unit which is to stand out is a call-unit, the instance of the
+         subpicture which is the result of the call (all the way to the
+         terminal nodes) is made to stand out.
+
+      STANDOUT-TEXT(Subpicture, unit, begin-char-count, end-char-count,
+      yesno)
+
+         Unit must refer to a string unit.
+
+         Makes the specified text stand out (according to the mode set
+         by SET-STANDOUT-MODE) or not, according to "yesno".
+
+      UPDATE-STRUCTURED-DISPLAY()
+
+         This causes any changes that have been made to the display
+         file, since the last update or since ICP, to be reflected on
+         the screen.
+
+
+
+
+
+
+Irby, et. al.                                                  [Page 14]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      TTY(parameters)
+
+         parameters are:
+
+            position rectangle, visible/invisible, number of lines, mode
+            of characters
+
+         This refers to the ICP TTY simulation
+
+      USE-TTY-UNITS(Subpicture1, unit1, ..., Subpicturen, unitn)
+
+         Unescorted characters are to be appended only to the specified
+         tty units.
+
+      Errors: Subpicture, unit does not exist.
+
+      RESET(How)
+
+         Case How Of
+
+            =  Permanent
+
+               Immediately resets the terminal to its initial ICP state
+
+            =  Temporary
+
+               Immediately resets the terminal to its initial ICP state
+               without destroying the previous state.
+
+            =  Restore state saved from last RESET(Temporary).
+
+Direct Feedback
+
+   It seems extremely desirable, given network speeds, to allow the
+   using host to perform direct feedback to the user without
+   intervention from the application program in the serving host.  This
+   is already done in telnet with local echoing.  We propose extending
+   this capability to graphics by allowing "dragging" (attaching a
+   subpicture's origin to the position of the cursor), "tracking"
+   (following the movement of the mouse, stylus, or light pen with a
+   distinctive mark on the screen), "inking" (plotting the trail of the
+   cursor on the screen) and "rubber banding" (a straight line attached
+   to a fixed point on one end the cursor location on the other).
+
+   These should be seen as allowable extensions of the protocol rather
+   than as requirements.  There should, however, be commands available
+   in the protocol for determining their existence and controlling them.
+
+
+
+
+Irby, et. al.                                                  [Page 15]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+Data input primitives
+
+   Input Control
+
+      TARGET-SENSATIVE(key1, ..., keyn)
+
+         Arms the units which have the specified keys for target
+         selection.
+
+      SET-INPUT-MODE(Device, parameters)
+
+         Selects the mode in which a logical device shall produce input
+         and under what conditions.
+
+         the logical devices are specified below as well as their
+         possible input formats and conditions.
+
+         Errors: no such device.
+
+   Keyboard input
+
+      The keyboard has only one input mode, in which it sends a
+      character whenever a key is struck.
+
+   Binary devices
+
+      Unless otherwise specified, binary devices act as an extension of
+      the keyboard and produce 8-bit characters which are not
+      distinguishable from keyboard characters by the serving host.
+
+         The algorithm for translating binary devices into characters is
+         not specified, but something like the NLS accumulation
+         algorithm for mouse-keyset chords is intended.
+
+      Binary devices may also input binary data (according to their
+      up/down states), which is transmitted on state changes.  Examples
+      of this type of device are function keys and overlay cards, mouse
+      and keyset (used independently or together), pen-up/pen/down,
+      light pen buttons, etc.
+
+   Coordinate input
+
+      Coordinates may be sent according to any subset of the following
+      criteria: with every character in some designated set (e.g.
+      control characters, or all characters); with every binary device
+      state change input; after some time interval has elapsed; after a
+      position change P > (y1-y0) ^2+(x1-x0)^2, etc.
+
+
+
+
+Irby, et. al.                                                  [Page 16]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      Coordinates may be sent in either or both of "X-Y" or "target"
+      format.
+
+         X-Y format is just the location of the cursor relative to the
+         screen region assigned to the host.
+
+         Target format is the "call stack" (logical path from the root
+         unit - the ICP SUBPICTURE - to the closest unit) plus the
+         target-key of that unit plus the count of the closest character
+         within the string or the closest line segment or dot or special
+         point if appropriate.
+
+            Target input is unavailable for segmented display files.
+
+            In the event of overlapping target sensitive units, it is
+            not specified which of the units selected will be returned
+            as the hit unit.
+
+   Time input
+
+      Since hosts may wish to consider two events happening sufficiently
+      close together to be simultaneous, or to keep detailed interaction
+      statistics, it must be possible to request time information to be
+      sent with some reasonable subnet of other types of input.
+
+Interrogations
+
+   It must be possible for the serving host to discover its environment
+   (e.g. screen size, available devices) and to read back state
+   information (display file).
+
+      This is very desirable both for debugging and for redirecting a
+      displayed image to another device (e.g. a plotter).
+
+   Environment
+
+      Terminal parameters: screen size and resolution, available input
+      devices, terminal type (for device specific control), number of
+      lines in the ICP TTY-UNIT.
+
+      Character parameters: available character sizes, special (non-
+      ASCII) characters, font characteristics, sub- and super-scripting
+      facilities.
+
+   State
+
+      Display file or display file components.
+
+
+
+
+Irby, et. al.                                                  [Page 17]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      Cursor Position
+
+         It should be possible for the application program to read the
+         cursor position at any time.
+
+      Display File Support
+
+         It should be possible to find out if this user process supports
+         only segmented or structured display files, or both.
+
+      Command support
+
+         It should be possible to get a matrix from the user process
+         which indicates which commands are implemented.  This is a
+         necessity to find out which, if any, of the direct feedback
+         features are supported, and might be nice to allow for, e.g.,
+         the possibility of a text only or graphics only subset of the
+         protocol to be implemented.
+
+Encoding Principles
+
+   Commands will have the format : BGC OPCODE DATA EGC where:
+
+      BGC (Begin Graphics Command) places the telnet connection into a
+      "read graphics command" mode,
+
+      OPCODE DATA is the specific graphics command and data, and
+
+      EGC (End Graphics Command) restores the telnet connection to its
+      normal state.
+
+      Note: This may all have to be bracketed by telnet Begin-8-bit-
+      transparent-mode and End-8-bit-transparent-mode commands.
+
+   Numbers in general will have have 7-bits of significance in each byte
+   -- if the high order of a byte is on, then the significant bits from
+   the next byte should be concatenated onto the low-order end of the
+   bits collected so far, etc..
+
+   Subpicture names - shall be 14-bit numbers, assigned by the serving
+   host.
+
+   Unit names - shall be 14-bit numbers, assigned by the serving host.
+
+   Strings - shall be 8-bit characters, with an escape convention to
+   represent changes of font and mode.
+
+
+
+
+
+Irby, et. al.                                                  [Page 18]
+
+RFC 553        Draft design for a text/graphics protocol    14 July 1973
+
+
+      Since the channel is 8-bits wide, there is room for many more than
+      128 displayable characters.  However, the interpretation of codes
+      200B and above is not standardized!
+
+   Coordinates should be as described in RFC 493.
+
+   Rectangles - shall be specified by the coordinates of the endpoints
+   of one of the diagonal.
+
+Encoding
+
+   The actual encoding of this protocol is forthcoming.  Since we expect
+   some changes to come about because of the upcoming Network Graphics
+   Group Meeting, we have postponed the actual encoding until after this
+   meeting.
+
+          [This RFC was put into machine readable form for entry]
+           [into the online RFC archives by Via Genie, 12/1999]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Irby, et. al.                                                  [Page 19]
+