diff options
Diffstat (limited to 'doc/rfc/rfc178.txt')
-rw-r--r-- | doc/rfc/rfc178.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc178.txt b/doc/rfc/rfc178.txt new file mode 100644 index 0000000..f9f2c21 --- /dev/null +++ b/doc/rfc/rfc178.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group Ira W. Cotton +Request for Comments: 178 MITRE +NIC: 7118 June 27, 1971 + + + NETWORK GRAPHIC ATTENTION HANDLING + + +1.0 INTRODUCTION + + Discussions of network graphic protocols have thus far primarily + dealt with protocols for the description of graphic data to be + displayed. RFC 86 proposed a Network Standard Graphic Data Stream + (NGDS) which would serve to convey graphic images expressed in the + Network Standard Display List (NGDL). RFC 94 expanded on this + proposal, and pointed out some shortcomings of the original scheme. + RFC 125 also replied to RFC 86 with comments and extensions, but also + recognized that a protocol for graphic display alone is insufficient + to support an interactive graphic system. + +1.1 TOPICS COVERED + + The present paper addresses itself to this requirement. The process + of attention handling is briefly described, various graphic + configurations are discussed, input devices are surveyed to identify + the types of data which they produce, and an attention protocol is + suggested. + +1.2 VIEWPOINT + + It should be made clear at the onset that the discussion which follow + will be from the viewpoint of a graphics user or a graphic + application program serving one or more users. Our concern is with + third-level protocols only. We assume the network is capable of + delivering arbitrary bit streams from terminal to graphic application + program, but don't care how this is accomplished. + +2.0 ATTENTION-HANDLING + + In order to demonstrate the need for an attention protocol, we must + first define what is meant by "attention" and "attention-handling." + We therefore begin by borrowing the definitions given in a recent + survey of this area(1). + + + + + + + + +Cotton [Page 1] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + +2.1 DEFINITION + + Graphic attention handling refers to the processes and techniques + whereby human inputs to a computer graphic system are serviced. An + attention event, or simply "attention," is a stimulus to the graphic + system, such as that resulting from a keystroke or light pen usage, + which presents information to the system. Servicing includes + accepting or detecting the hardware input, processing it to determine + its intended meaning, and either passing this information to a user + routine or taking some _immediate_ action related to the display + and/or its underlying data structure, or both. The emphasis is on + "immediate." Attention-handling is not intended to include any + detailed, application-oriented processing which the attention + information may indicate is to be performed. Thus, attention + handling may be considered separately from any particular + application. + +2.2 INDEPENDENT FROM DISPLAY CONSIDERATIONS + + Not only may attention handling be considered separately from any + application, but attention generating hardware may be considered + separately from display hardware. Oftentimes, it is only + coincidental that they come in the same package. Indeed, in some + configurations an input be processed locally (by the terminal) to + provide the appropriate response. For example, a keystroke may or + may not cause a character to be displayed on a terminal, and the + logic causing the display may or may not be local (within the + terminal). The keystroke might be immediately displayed locally, as + in the case of an alphanumeric display terminal which buffers + keystrokes and transmits messages of many characters or it might be + transmitted to the host computer and "echoed" back for display as in + teletype-like terminals. + + The question is not limited to such simple input devices as + keyboards. So-called "intelligent terminals" with integrated + programmable logic or even complete small computers can process more + sophisticated attentions locally, and even alter a local distillate + of the central (host) data structure without central knowledge. This + raises the problem of insuring that the display and the graphic + application program do not get "out of sync," and requires a more + expressive protocol from terminal to host processor. + + + + + + + + + + +Cotton [Page 2] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + +3.0 SYSTEM CONFIGURATIONS + + We now turn to a consideration of the evolution of system + configurations for computer graphics. Our intent is to demonstrate + that just as display generation has evolved from the output of device + dependent codes to a generalized protocol, so too should attention + generation evolve. + +3.1 STAND-ALONE CONFIGURATION + + Figure 1 illustrates the stand-alone graphic configuration which was + the first and is still the most common. As we have stressed, input + and output are entirely independent, and are shown as separate + devices. In this configuration, display code generation and + interrupt processing are both done within the graphic application + program in the host processor. The graphic application is very + device-dependent. + +3.2 STAND-ALONE CONFIGURATION WITH STANDARDIZED FORMATS + + The significant conceptual change occurs when the input and output + processors are removed from the graphic application program. The + graphic application program then generates output and accepts input + in a generalized form, as illustrated in Figure 2. The important + fact to note is that in order to accommodate additional (different) + input and/or output devices, only these input/output processing + routines must be replaced or altered. Graphic application programs + may be designed without regard to which particular processing routine + will be used. So far as the application program is concerned, + device-independence has been achieved. + + + + + + + + + + + + + + + + + + + + + +Cotton [Page 3] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + +Figure 1 Stand-Alone Graphic Configuration + + +----------------------------+ + | | _______ + | +---------+-----------+ | / \ + | | |OUTPUT | | / \ + | | /-->|PROCESSOR |----|------------>| | + | | / +-----------+ | \ / + | | | | | \_______/ + | | | | | OUTPUT DEVICE + | | | +-----------+ | ______ + | | \ |INPUT | | | \ + | | \---|PROCESSOR |<-- |-------------|_______\ + | +---------+-----------+ | + | Graphic Application | INPUT DEVICE + | Program | + +----------------------------+ + /SERVING\ HOST + \USING / + + +Figure 2 Stand-Alone Configuration with Standardized Input and Output + Formats + ++-------------------------------------+ ______ +| | /---->/ \ +| +-----------+ |DEVICE-DEPENDENT/ ___/___ \ +| +-----------+ |--|---------------/ / \ | +| STANDARD | OUTPUT | | |DISPLAY LIST / \ / +| +-----+DISPLAY LIST|PROCESSOR |-+ | | |__/ +| | ---|----------->| |----|---------------->\ / +| | | | +-----------+ | \_______/ +| | | | | OUTPUT DEVICE(S) +| | | | | +| | | | +-----------+ |DEVICE-DEPENDENT ______ +| | | | STANDARD +-----------+ |<-|----------------------| \ +| | |--|<-----------|INPUT | | |INPUT DATA ___|___ \ +| +-----+ ATTENTION |PROCESSOR |-+ | | \____\ +| | |<---|------------------| \ +| +-----------+ | |_________\ +| Graphic Application Program | INPUT DEVICE(S) +| | ++-------------------------------------+ +/SERVING\ HOST +\USING / + + + + + + +Cotton [Page 4] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + +3.3 NETWORK CONFIGURATION + + When the stand-alone configuration with standardized formats is + implemented on a network, the organization illustrated in Figure 3 + results. In the network configuration, the graphic application + program and the input and output processors may be in different + hosts. The standardized formats become network standards, and now + any using host with input/output processors conforming to the + standard can access the graphic application program in the serving + host. The network is transparent to the graphic configuration. + +3.4 NETWORK CONFIGURATION WITH INTELLIGENT TERMINAL + + The case of an intelligent graphics terminal configured in the + network is illustrated in Figure 4. Here, input and output + processors are located within the terminal itself. The using host + serves only to connect the terminal to the network, and in the case + of a terminal IMP, is dispensed with altogether. Any type of + intelligent terminal may access any graphic application program if + its (the terminals) input and output processing routines conform to + the network standard. As before, the network is transparent to the + graphic configuration. + + Figure 3 Network Configuration (Omitted due to complexity) + + Figure 4 Network Configuration with Intelligent Terminal (Omitted due + to complexity) + + +4.0 INPUT DEVICES + + We now turn to a survey of graphic input devices as suggested in RFC + 87. The survey will concern itself with the characteristics of the + attention information presented when the device is used (rather than, + for example, human factors considerations). + + We wish to stress at the onset that we consider all devices + equivalent in capability. By this we mean that with appropriate + programming, any device can simulate any other device. Throughout + the survey we will illustrate typical data conversions which might be + performed, and at times discuss how various devices may be simulated. + + It is convenient to consider the characteristics of classes of + devices. Information about particular commercial devices may be + found in reference 5 and elsewhere. Table I presents a device class + summary. + + + + + +Cotton [Page 5] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + +4.1 PUSHBUTTONS + + Perhaps the first and most primitive class of input devices is the + pushbutton, which presents some unique code to the system when + depressed. In the simplest case, the code is equivalent to the + knowledge that the button has been pushed, and may be just a flag. + + Beyond the basic pushbutton, more advanced key devices have been + designed in a variety of ways. For example, each key may be + associated with a single bit in a word or with a complex pattern + (character or byte), multiple keys may or may not be able to be + struck simultaneously (if so, their codes being combined in some + defined way). + + The salient feature of the function key is that it presents two + pieces of information to the system: the fact that a keystroke has + occurred (which may be implicit), and some unique code related to it. + + More elaborate keyboards, be they teletypes or solid state devices + with elaborate "overlays", are merely special cases of function keys. + They present the same information, attention source plus a unique + code. The fact that such a code may be associated with a displayable + character is at this stage only incidental. + + Since keyboards permit the entry of arbitrary codes, particular + sequences of codes may easily be defined to simulate other devices. + If local logic permits, codes may be accumulated until a complete + sequence is entered and then be reformatted to exactly the same + format as the device being simulated would have produced. + + Pointing devices such as light pens and tablets may be simulated by + associating particular keys with screen directions (up, down, right, + left) and using them to position a pointer on the screen face. This + facilitated on terminals with a hardware connection between keys and + cursor symbol. + +4.2 ANALOG DEVICES + + The next most basic class of input devices are those which consist of + analog to digital converters. These include simple shaft encoders, + mouse and trackball. These devices all produce a digital output + proportional to an analog input, in this case, the rotation of a + shaft. Several of these inputs may be presented together, as in the + case of the mouse and trackball. + + + + + + + +Cotton [Page 6] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + + These devices all present as input a device identification (which may + be implicit depending on the hardware method of input) together with + a number of digital codes from the same number of analog devices. + The length of the code is arbitrary and may or may not relate to such + measures as the maximum raster count of the display screen. + + Analog devices are often used as pointing devices by using the input + to control the movement of a cursor on the screen face. This method + is superior to the use of a keyboard, since very smooth and rapid + movement may be obtained. + +4.3 TABLETS + + A tablet consists of a flat surface on which (X,Y) position may be + indicated with a stylus. If position changes can be registered + rapidly enough, arbitrary curves may be digitized by tracing them. + + There are a variety of devices utilizing a variety of techniques + comprising this class. Included are such diverse techniques as + variable resistance, variable capacitance, and ultrasonics, to + mention a few of the devices on the market. The surface may be + horizontal or vertical and may even be superimposed on the screen + itself. A variety of styli have been used, including the operator's + finger. A device (the Lincoln Wand) has also been demonstrated which + may be manipulated in space to yield a position in three dimensions + (X,Y,Z). + + These devices all present a device identification (which may be + implicit), and a position value, which is most often a coordinate + pair, but which may be a triple. + +4.4 LIGHT PEN + + Light pens are devices which relate the occurrence of an attention to + the time in the refresh cycle when a particular point is illuminated + on the screen. The display generators are generally stopped when the + attention occurs, to permit either the display list "P" register or + the (X,Y) beam position registers, or both to be presented as + attention data. Often times this is not enough, as what is desired + is some value which serves to identify the image which the pen + detected. In such cases local hardware and/or software is utilized + to obtain this information, which may be as simple as a single + identification code or as elaborate as a genealogical push down list. + + + + + + + + +Cotton [Page 7] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + + Light pens present as input a device identification (which may be + implicit) and at least one of the following: memory address, (X,Y) + position, item identification. + + Light pens may be used to simulate keyboards by displaying "light + buttons" on the screen associated with particular physical buttons. + Detecting on a light button is logically equivalent to pushing the + related key. + +4.5 INTERNAL ATTENTIONS + + Internal attentions are stimuli arising not from operator action, but + from various sources within the terminal such as a screen edge + violation (overflow) or a programmed trap. Such attentions present + information in much the same way as the operator input devices + already discussed. This information consists of an attention source + identification (equivalent to device identification, and which may + again, be implicit) and appropriate data, which, for the two examples + given, will generally be a memory address. + + Programmed traps are often used to permit mode changes (e.g., enable + or disable light pen operation) during the execution of the display + list. Edge violation might occur when an image is being relocated in + response to operator input. We must provide for describing such + attentions, since then cannot always be handled locally in the + terminal. + +4.6 LOGICAL ATTENTIONS + + We may generalize the concept of an attention from a stimulus from a + physical source to a logically generated stimulus resulting from some + program condition which may or may not cause an interrupt. + (Programmed traps were classified as internal attentions because, by + definition, they cause an interrupt or set a hardware flag). Logical + attentions are generally "input" by setting a software flag which + some control program can periodically inspect. For example, logical + attentions may be designed to detect when a software-defined edge + violation occurs (of a region less than full screen) or when a light + button is picked. There is no general form for the information + generated by logical attentions, since they are programmable, rather + than hardware-bound. The best we can do is to say they consist of an + identification and appropriate data. Actually, logical attentions + most often simulate physical attentions, and so each may be placed in + one of the classes already described. + + + + + + + +Cotton [Page 8] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + + TABLE I + + INPUT DEVICE SUMMARY + +DEVICE CLASS DEVICE EXAMPLES TYPICAL OUTPUT + +Button Teletype 1 Character + Function Key with Overlay 1 Character and + overlay code + Buffered Keyboard n Characters + +A/D Converter Shaft Encoder delta a + Mouse (delta a, delta b) +Tablet Rand Tables and (X,Y) + Lincoln Word (X,Y,Z) + +Light Pen Light Pen P (memory address) + Light Pen (X,Y) + Light Pen and Local Software Item Name + Light Pen and Local Software Item name stack + +Internal Program Trap P (memory address) + Screen Overflow P (memory address) + +Logical Attention Any of the above Any of the above + + +5.0 INTELLIGENT TERMINALS + + As has been indicated, the question of what data results from which + inputs is complicated when "intelligent terminals" are considered. + An intelligent terminal has the ability to modify the data presented + by the input device hardware. In a sense then, all of the outputs of + an intelligent terminal may be considered as logical attentions. The + logical complexity of such attentions may be very great indeed. For + example, such a terminal might be programmed to perform sketching + functions, so that the net effect of a keystroke and a light pen hit + might be the deletion of a portion of the picture together with some + coded message to the effect. A technique has even been developed + which permits the light pen operator to simulate the use of a shaft + encoder by twisting his wrist which holding the pen over a tracking + symbol (7). + + Some intelligent terminal systems have been developed which permit + the terminal operator to modify the picture and the local data + structure independently.(2) Thus, the need for a very expressive + protocol from terminal to central computer becomes apparent, so that + notice of such local processing may be communicated to the central + + + +Cotton [Page 9] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + + program. + + +6.0 NETWORK PROTOCOL GUIDELINES + + We now suggest a format for a (third level) network protocol from + terminal to serving host which is sufficiently open-ended to permit + any type of attention to be communicated. It is not the intent here + to formally propose such a protocol down to the level of "this bit + means that." When such details are decided, a Network Standard + Attention will have been defined. + + The attention protocol has three basic elements: device + identification, data identification, and data. + +6.1 DEVICE IDENTIFICATION + + The device identification field must be sufficiently large to permit + the unique identification of any TYPE OF DEVICE in the network. If + two or more identical input devices exist at different nodes in the + network, it is not necessary to distinguish among them in this field. + However, if a keyboard, for example, has keys which are logically + different, such as typewriter keys and function keys, the distinction + should be made in the identification field, rather than requiring an + analysis of the data. Further, if two different devices are + logically equivalent, as a physical keyboard and light buttons, they + may be so treated by NOT having identification codes different from + each other. + + Somewhere in the network (and possibly at each host supporting a + graphic application) a table should be kept of the input device types + and their characteristics. It may be convenient to organize the + device identification field so that a subfield identifies the device + CLASS, as discussed previously + +6.2 DATA IDENTIFICATION + + The device identification field is intended to contain a description + of the data field which follows. Information which might be provided + here includes number of units (bits, words, bytes) of data which + follow, qualitative description of the data (character code, memory + address, cartesian coordinates, item name, etc.), and data format + information. It may be desirable, for the sake of uniformity, to + include this information even when it is somewhat redundant. + + + + + + + +Cotton [Page 10] + +RFC 178 NETWORK GRAPHIC ATTENTION HANDLING June 1971 + + +6.3 DATA + + Lastly comes the data itself (perhaps an anticlimax at this point!) + which, as should be clear by now, may be of arbitrary length and + organization. + + +BIBLIOGRAPHY + + 1. Cotton, I. "Languages for Graphic Attention-Handling." Proc. + Computer Graphics 70 Symposium, Brunel University, 197. + + 2. Cotton, I. and F. Greatorex "Data Structures and Techniques for + Remote Computer Graphics," Proc. FJCC, 1968, pp. 533-544. + + 3. Crocker, S. "Proposal for a Network Standard Format for a Data + Stream to Control Graphics Display." ARPA Network Working Group, + RFC # 86, 1971. + + 4. Harslem, E. and J. Heafner "Some Thoughts on Network Graphics," + ARPA Network Working Group, RFC # 94, 1971. + + 5. Keast, D. "Survey of Graphic Input Devices," MACHINE DESIGN. + August 3, 1967, pp. 114-120. + + 6. McConnell, J. "Response to RFC #86," ARPA Network Working + Group, RFC #125, 1971. + + 7. Newman, W. "A Graphical Technique for Numerical Input," + COMPUTER J., May 1968, pp. 63-64. + + 8. Vezza, A. "Topic for Discussion at the Next Network Working + Group Meeting." ARPA Network Working Group, RFC #87, 1971. + + + + + + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Kelly Tardif,Viagénie 11/99] + + + + + + + + + + +Cotton [Page 11] + |