From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc553.txt | 1067 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1067 insertions(+) create mode 100644 doc/rfc/rfc553.txt (limited to 'doc/rfc/rfc553.txt') 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] + -- cgit v1.2.3