summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc553.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc553.txt')
-rw-r--r--doc/rfc/rfc553.txt1067
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]
+