SECTION 6

INPUT AND OUTPUT

Security mechanisms, and data consistency mechanisms shall apply to all PCIS facilities required by this section.

Input and output are defined in terms of logical devices. Logical and physical devices are regarded as logical and physical resources respectively, and the requirements in Sections 2.9 and 2.10 apply.

The paragraph above categorizes logical and physical devices as logical and physical resources respectively, allowing the more general requirements of Section 2.9 and Section 2.10 to be invoked. In particular the IRAC requires a process to be able to use a logical device. The mapping of that logical device onto a particular physical device is achieved by Requirement 2.10A and Requirement 6.4C.

The requirements in this section are stated in terms of concepts expressed in the following Entity Relationship diagram which is intended as clarification of some of the terms used.

                          +---------+
                          | Logical |
                          | Device  |
                          | Type    |
                          +----+----+
                               |
                               ^ defines properties of
                               |                       +-----------------+
                               |                       |                 |
                               v                       | +-------------+ |
                               v instance of           | |+-----------+| |
                               |                       | || Process   || |
                          +----+----+                  | || Connector || |
  +---------+             |         |                  | |+-----------+| |
  |         | uses        |         | maps to          | |             | |
  | Process |-<<------->>-| Logical |-<<------------->-| |             | |
  |         |     used by |         |     mapped to by | |+-----------+| |
  +---------+             |         |                  | || Physical  || |
                          +---------+                  | || Device    || |
                                                       | |+-----------+| |
                                                       |                 |
                                                       +-----------------+


	Key:	Double-headed arrows show "to-many" relationships.
		Single-headed arrows show "to-one" relationships.

	Note:   This diagram is intended solely for clarification of
		the language in which the requirements are stated and
		not as a model that is to be directly provided by the
		PCIS.

It is seen as undesirable that a tool should be able to connect itself to a particular physical device. Rather, tools should operate only on logical devices, otherwise tool portability is seriously impaired. How can a tool be portable if it asks to be connected to a printer at a particular physical location? What happens when that particular device is not serviceable? A tool must expect a logical device to be of a particular logical device type. It is a function of the administration of resources that allows a given logical device to be mapped to a particular physical device. This mapping can be delayed and occur at run-time to answer to the general requirements of flexibility and the ability of PCIS to evolve (see Requirement 6.4C).

6.1 Logical Device Types

A logical device type defines the properties of a set of logical devices. One or more instances of a logical device type may be available for input or output.

The properties of a logical device type are the abstractions of the properties of a set of physical devices so that these properties have a defined effect on each physical device that the logical device type represents. The list of types of logical devices that the PCIS should support is indicated in the rest of this section. A process may use several instances of a single logical device type, for example, a tool may wish to output results to one line printer and a summary to another.

6.1A Introducing Device Types. PCIS shall support the introduction (and possibly the cancellation) of logical device types.

The set of logical device types should evolve with the introduction of novel physical devices (for example, data gloves, 3D-mice, display helmet, softpen, etc.). PCIS implementations are not required to support all the device types specified in all the requirements of Section 6.1 to be conformant. A device can become obsolete, for example, a card reader. On the other hand, it could be acceptable not to provide a line printer. This complements Requirement 6.4B.

6.1B Serial Device Types. The PCIS shall support at least the following serial logical device types:

Magnetic tape unit
Alphanumeric terminal
Line printer
Scanners

Serial logical device types are those that handle a stream of data units in a purely serial fashion, in particular, these devices do not allow selective overwriting of information.

Magnetic tape units not only read and write data serially but also support rewinding.
Serial terminals are the basic form. They may emulate teletypes or similar hard copy devices.
Line printers are similar to serial terminals, except they only provide for output. Additionally they support pagination and wider pages.
Scanners can read serially (or not!) alphanumeric or non alphanumeric data (for instance, bar code which also can be read with wands).

6.1C Positional and Interactive Device Types. PCIS shall support at least the following positional and interactive logical device types:

Plotter
Page addressable printer
Cursor addressable terminal
Bulk storage
Locator input
Bit-mapped terminal
Graphical terminal
3D devices

Positional device types allow input and output operations to be specified by position.

The pen position of a plotter must be controlled.
Page printers, notably laser printers, allow information to be explicitly positioned on the page. Dot matrix and laser printers also support production of complete pixel-detailed illustrations.
Cursor addressable terminals allow text to be explicitly positioned on the screen and may also support reading back of data from locations of the screen.
On bulk storage devices such as discs it is efficient to provide for indexed access to a file, that is, for input and output to be specified by position.

Interactive device types communicate with the end user and typically require coordination between input and output. They also provide facilities unique to these devices.

A locator input device may be a mouse, track-ball or joystick. These provide positional information as well as the state of a number of buttons. A touch sensitive screen may also act as a locator input device.
Bit-mapped terminals support pixel addressing and raster operations.
Graphical terminals are vector driven and are typically used for line drawing.
Three-dimensional interactive devices include three-dimensional locator input devices such as flying mice as well as three-dimensional sound devices.

The latter device types are currently evolving with the introduction of multi-media devices such as video, speakers, voice recognizers, etc.

We should distinguish between input and output device types, then between alphanumeric and non alphanumeric with the sense they address (eye, ear, both). A lot of devices can be both positional and interactive.

6.1D Communications Device Types. PCIS shall support end-to-end communications from a PCIS implementation to an external system, including a connected target machine and another PCIS implementation.

The use of communication devices in this requirement is not concerned with the support of a distributed PCIS, but provides the underlying mechanism by which a tool on a PCIS implementation may communicate with an external system. Communications may be supported by permanent connections, circuit switched networks or packet switched networks. By supporting end-to-end communication it is anticipated that communication standards, such as the Open Systems Interconnection (OSI) 7-layer model, may be supported. In a secure PCIS, Requirements 7.2I and 7.2J will need to be satisfied in such communication.

6.2 Operations on Logical Devices

This section describes the general characteristics of the input, output and control operations which may be used on logical devices.

6.2A General. The PCIS shall provide facilities for input from, output to and control of logical devices.

6.2B Common Subsets. The PCIS shall provide a subset of the input and a subset of the output facilities which operate on instances of several logical device types. These subsets shall provide for at least serial character input and output.

While a logical device abstracts physical devices with similar properties, the purpose of subset facilities is that they should apply to a wider range of physical devices than those encapsulated in a single logical device type. For instance serial device facilities should work on positional devices. This requirement calls for similar functions on different logical device types to use the same facilities. This is a necessary prerequisite for device independence to have any real benefit and allows tools to be written without being constrained to particular physical device types. This should allow for redirection of input and output and supports the process connector mechanism (see Requirement 6.4A).

6.2C Device Status. The PCIS shall support the interrogation of the status of a logical device including the availability of data on input devices. The PCIS shall support a mechanism to allow a process to be notified of a change of status on a set of one or more logical devices.

This requirement embraces such status returns as "printer out of paper" or "modem hung-up". The ability to check for availability of input data are frequently useful, especially for interactive tools, where the tool may be able to proceed with another task in the absence of a new user command.

The intent of the second sentence is to provide a facility, like select(2) of BSD4.2 UNIX, which allows a tool to wait for something to happen to a set of devices without consuming resources (CPU time).

6.2D Timeout. The PCIS shall provide mechanisms to permit timeout on input and output operations.

This mechanism permits tools to wait for some maximum period for the availability or operation of a device.

A more elaborate time management scheme may be required for PCIS implementations executing over a wide area network.

6.2E Buffering. The PCIS shall support the control of buffered and unbuffered input and output of data items on logical devices. The PCIS shall support the clearing of input buffers without requiring processing of their contents. The PCIS shall support the clearing of output buffers with and without onward transmission of their contents.

The use of unbuffered input and output to a device can have significant performance consequences. In the absence of a buffer, output must happen when the command is executed.

The requirements to support buffering and clearing of input buffers include what is generally implemented as type-ahead and flushing. Forced output is often essential on device closing, across data links, when debugging, or in maintaining external data bases. The total absence of buffering delays is necessary in screen oriented debuggers and editors.

In a reset after an exception, pending data often becomes irrelevant. A user of a tool may request the suppression of the output he is seeing (for example, with control-O), and it becomes necessary to prevent the output of what may be an immense buffer. A consumer may refuse to consume, and the buffer must be eliminated to permit the process to terminate. The disposition of the data in the buffer is of no consequence.

Note the difference between flushing with and without forced processing. The word flushing can be used in two senses. One sense is the concept used here: to force the processing of pending data units gathered in a buffer. The second sense is to discard the contents of such a buffer.

The data may need to be sent despite the buffer not being full. This facility is often useful in debugging, when a paused process has generated output which cannot yet be examined. It can also be used when it becomes clear that the buffer will not be soon filled. This may also be used when a datastream is redirected.

Screen oriented editors and debuggers make use of single keystrokes to govern their interface with the user. This requirement ensures that tools be able to use such interfaces if they are able to control input buffering. If this is not provided, it becomes impossible to implement a large class of tools in a portable manner on a PSE. Screen oriented editors have shown themselves to be useful. It is unfortunate that interfaces using this feature tend to overuse system resources. They should thus be used with restraint in systems where the process using them shares a processor with other programs. In the future, most editors will probably run on intelligent remote nodes where the interface is provided through a single-user processor and no meaningful penalty is incurred.

6.3 Specific Common Subsets

6.3A Textual Subset. The PCIS shall support at least the following presentational characteristics of text: margins, page width, page length, boldness, fonts, slant, justification, underlying, overlying, subscript, superscript, type size, color, inverse video, blinking and line spacing.

Color includes intensity, which can be the same as brightness on monochrome terminals. It is undesirable to try to include everything, and future interfaces can take up the slack for such things as extra dimensions, olfactory output, and the still unimagined. Note that color can be specified in several ways: by wavelength and intensity (chrominance and luminance), by component strength (amount of each process color), by intensity/value/hue, or by an enumerated list of colors. The choice of one or more color representations is left to the PCIS designer. Not all text characteristics may be supported on all textual devices, for instance, blinking is difficult on a hard copy device.

6.3B Graphical Subset. PCIS shall support a bit-map editor. At least, a process to build icons is expected.

There is no existing standard that has universal acceptance as the definition of graphic capabilities. Consequently, the requirement for a specific interface is an issue requiring the sort of investigation and consideration expected of the PCIS designer. The imminent ISO/ANSI Graphics Standards for Graphical Kernel System (GKS), Computer Graphics - Video Display Interface (CG-VDI) and The Programmer's Hierarchical Interactive Graphics Standard (PHIGS) should be considered as candidates.

Facilities to erase geometrical figures are intended for use on interactive, bit-map and graphic terminals where dynamic updating of diagrams is necessary for graphical editors.

Graphics in a windowing environment may require a different set of facilities because of the added functionality of such a system. However, it is desirable that the facilities called for by this requirement are supported by a windowing environment in order to enhance the device independence of tools which only require the lesser functionality.

The decision as to whether bit-mapped or line graphics are to be supported is left to the PCIS designer. Although bit-mapped graphics are important, efficient use of more limited forms is essential. Some devices will not support all of this, but such shortcomings are characteristics of all input/output interfaces. In general, vector and raster devices will achieve the same effect by different means. The limitations of the geometric interfaces are to be determined by the PCIS designer, but at least segments and circles are expected.

6.3C Interactive Subset. PCIS shall:

a) Support facilities for the use and management of windows

b) Support mechanisms for the management of user interfaces

Window managers simply manage the screen real estate, tracking locator input, and focusing keyboard input. They include the management of overlapping windows. They may include the notion of rooms. It would still be possible for the PCIS to map a logical device, that emulated a single physical device, onto a window so that the use of the window was transparent to tools. However, if tools can participate in the use of windows then more supportive user interfaces can be constructed, such as those found in interactive graphical editors. X-Windows for UNIX and Microsoft Windows for MSDOS are the two widely accepted standards today. Top of X-Windows, OSF Motif, Sun OpenLook could be considered as candidates for a PCIS windowing facility. A PCIS style guide could also be required.

Basic facilities to operate several windows are analogous to primitive file handling and leave each tool with a lot of additional support to provide. There is also the danger that these windowing primitives will constrain a tool to particular physical devices. It is therefore desirable to support a user interface management system which gives a higher level abstract interface, relieving each tool of replicating such functionality. A user interface management system will also ensure consistency of style and utility of the user interface, thereby providing for tool integration at the user interface.

Facilities to manage the user's preferences of tailorable aspects under control of the window manager of the User Interface allow choices such as found on Windowing control panels, such as color, mouse sensitivity, locator choices (mouse versus keyboard, left versus right hand operation), pen, overlapping window focus models, etc.

Some questions that may be asked concerning the User Interface:

Should the user interface be specific to tools or should it be standard?
What level of user interface should PCIS provide?

In response to these questions, the following three solutions are possible:

PCIS does not provide a user interface.
PCIS provides a user interface at the level of Motif or higher.
PCIS chooses an existing standard.

The rationale for the first solution is: if PCIS chooses a standard user interface and if the rest of the world chooses another one, should the tools suppliers have to support two user interfaces? No.

The rationale for a combination of the first and third solutions is: PCIS should not be involved in user interface standardization, as a lot of people can do that better than the PCIS definers. In addition, these solutions enable the tools of the PCIS environment to accept general cut and paste.

The rationale for a combination of the second and third solutions is: if there is no user interface provided by PCIS, how can integration of presentation be done?

The rationale for the second solution by itself is: this solution can perhaps assure security at the level of the user interface.

c) Provide facilities to control echoing

Passwords should not generally be echoed. Commands should. When keystrokes have screen-oriented semantics, their echoing is useless and confusing. If typing C moves the cursor forward one character on the screen, the echo of C would overwrite the current character. This control is also essential for windowing, so that the appropriate window may be addressed before echoing is simulated.

It is normal for an operating system to provide echoing of characters and locator position (cursor) to an interactive device, since this is a general requirement and can be achieved much more efficiently than by requiring each tool to perform its own.

Note that any echoing is output and thus subject to the requirement about sequencing. Echo suppression is essential in screen-oriented programs and for passwords.

d) Provide facilities to control proper sequencing of input from and output to interactive logical devices

This is a necessary condition for a usable interactive device.

It seems apparent to a programmer that if he calls two subroutines and the first outputs an A, the second a B, the A should come out first.

There is debate over the level at which such sequencing should be required. Within a single datapath, it is most likely to be compromised when separate tasks use that datapath. Sequencing could also be required between datapaths accessing the same device or different devices or between datapaths used by different processes, even different processors. The appropriate level of control is left to the PCIS designers.

PCIS designers should consider the relationship between sequencing of input from these devices and transactions as provided for by the OMS. The interaction between these devices and transactions should be compatible and consistent between different PCIS implementations.

PCIS designers should consider the effects on window manager actions related to inter-window (and inter-process) focus so that these effects are well specified and consistent between PCIS implementations.

6.4 Physical Devices

6.4A Process Connectors. The PCIS shall support process connectors. A logical device may be mapped to a process connector so that output by one process may be received as input by another process and similarly for control.

A process connector is equivalent to a physical device and provides a mechanism whereby the output of one process to a logical device may be consumed as input from a logical device by another process. This mechanism is similar to pipes in UNIX. Tools which use this mechanism only need to cooperate to the extent that they both use complementary subsets of input and output facilities. This encourages the reuse of tools and tool fragments.

6.4B Unsupported Features. The PCIS shall define the consequences when the physical device does not have all of the features required by the logical device.

If, for example, a device does not support cursor control, it may be desirable to let the cursor control sequences echo on the screen (in some readable form) for debugging purposes (that is, to treat the device as another device), to do nothing, or to raise an exception. The control over this behavior is not required in all interfaces, but an explanation should be offered as to why the selections were made. The exceptions response is technically general in that the calling program can handle the exception with whatever action is desired, but this may raise high costs in complexity and run-time efficiency.

Not all missing features present reasonable alternatives. An attempt to plot on a line-printer should raise an exception and be done with it. PCIS may be implemented on top of an underlying operating system that does not provide full support. For example, when the underlying operating system does not support some control of buffering, which is needed, the tools should have a choice between ignoring the request and raising an exception. The underlying device may be another device driver, such as a specific physical driver or the window manager.

6.4C Device Mapping. The PCIS shall provide mechanisms that permit both static and dynamic mapping between a logical device and a physical device or a process connector.

This requirement should not be confused with the so-called device redirection, which is a Command Language Interpreter function to direct input to, or output from, a tool to a particular device or file. This may be supported by the device mapping facilities described here, but, since the Command Language Interpreter is typically a tool, device redirection is typically implemented within a tool.

In typical situations logical device mapping may be specified:

At compilation or build time, for example in some Fortran systems output to device 6 may be predefined to go to a particular line-printer.
At run-time, by the tool making a PCIS call to open a channel to a particular device or file. The device or file identification may have been passed as a parameter to the tool so that, for example, the Command Language Interpreter can control the device which is used.

In conjunction with the requirements for resource administration, this requirement allows selection of a particular physical device.

A logical device allows the specification of some form of generic device, without directly specifying a particular instance of that device. For example, a program may transfer output to "lp:" or "mt:" or "line-printer (with lowercase)", and the system may choose, in some way, which particular device to use from among the group of similar devices. In these situations there may be only a single device having the appropriate characteristics, or the system manager may have determined which devices particular users should use, or the system may make a random choice among available devices.

The requirement suggests such a generic facility but does not require it.

If a generic facility is provided, the usual situation is that the binding to a particular physical device is determined before the tool is executed and cannot be changed during the tool execution. However, a more powerful facility, for example, to allow output to be switched between the user's terminal and a file, during tool execution, can be very useful. The requirement allows for such a dynamic binding.

6.4D Exclusive Access. The PCIS shall provide facilities to obtain and relinquish exclusive access to a logical device and hence to the physical device to which it is mapped.

A process must be able to obtain total control of a logical device, to prevent data corruption caused by interleaving by other processes. For example a screen editor would normally be designed to utilize the whole screen and to prevent intrusion. Similarly a print spooler would obtain exclusive access to the printer.

A more extensive requirement referring to resources instead of devices was considered but rejected since it was felt undesirable to provide PCIS facilities to obtain or relinquish exclusive access to resources such as a processor. The normal process exclusion necessary to the operation of any multi-tasking system is expected to be implicit in the implementation and does not appear at the PCIS.

PCIS designers should consider the interaction between exclusive access procedures and trees of (nested) transactions. The transaction interaction should be consistent between PCIS implementations.

PCIS designers should specify the interaction between window manager focus models, exclusivity visualization, and modality of dialogue box windows. The model should be consistent between PCIS implementations.

Go forward to Section 7, Protection and Security.