doc: Add RFC documents

1 files changed, 1298 insertions, 0 deletions

diff --git a/doc/rfc/rfc782.txt b/doc/rfc/rfc782.txt
new file mode 100644
index 0000000..ddf1ce7
--- /dev/null
+++ b/doc/rfc/rfc782.txt
@@ -0,0 +1,1298 @@
+
+
+
+
+
+
+
+
+
+        A Virtual Terminal Management Model
+
+
+
+
+
+        RFC 782
+
+
+
+
+
+        prepared for 
+
+        Defense Communications Agency
+        WWMCCS ADP Directorate
+        Command and Control Technical Center
+        11440 Isaac Newton Square
+        Reston, Virginia 22090
+
+
+
+
+
+
+
+
+        by
+        Jose Nabielsky
+        Anita P. Skelton
+
+
+
+
+
+
+        The MITRE Corporation
+        MITRE C(3) Division
+        Washington C(3) Operations
+        1820 Dolley Madison Boulevard
+
+
+
+
+
+
+
+                          TABLE OF CONTENTS
+
+
+
+                                                                Page
+
+
+LIST OF ILLUSTRATIONS                                             vi
+
+1.0  INTRODUCTION                                                  1
+1.1  The Workstation Environment                                   1
+1.2  Virtual Terminal Management                                   2
+1.3  The Scope                                                     3
+1.4  Related Work                                                  4
+
+2.0  THE VTM MODEL                                                 5
+2.1  The VTM Model Components                                      7
+2.2  The Virtual Terminal Model                                   10
+     2.2.1  Virtual Terminal Connectivity                         11
+     2.2.2  Virtual Terminal Organization                         11
+            2.2.2.1  The Virtual Keys                             12
+            2.2.2.2  The Virtual Controller                       12
+            2.2.2.3  The Virtual Display                          12
+     2.2.3  Virtual Terminal Architecture                         13
+            2.2.3.1  Communication Variables                      13
+            2.2.3.2  Virtual Display with File Extension          13
+            2.2.3.3  Virtual Display Windows                      14
+2.3  The Workstation Model                                        17
+     2.3.1  The Adaptation Unit                                   17
+     2.3.2  The Executive                                         18
+
+REFERENCES                                                        19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 iii
+
+                        LIST OF ILLUSTRATIONS
+
+
+
+                                                                Page
+
+Figure Number
+
+     2.1       The Virtual Terminal Model                          7
+     2.2       The Workstation Model                               8
+     2.3       VT 0 (expanded from previous figure)                9
+     2.4       The Domains                                        14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                  v
+
+
+
+
+
+
+
+1.0  INTRODUCTION
+
+     Recent advances in micro-electronics have brought us to the  age
+of the inexpensive, yet powerful, microprocessor.  Closely resembling
+the advances of the 1960's which brought about  the  transition  from
+batch  processing  to time-sharing, this technological trend suggests
+the birth of decentralized architectures where the  processing  power
+is  shifted  closer  to  the user in the form of intelligent personal
+workstations.  The virtual terminal model described in this  document
+caters to this anticipated personal computing environment.
+
+1.1  The Workstation Environment
+
+     A personal workstation is a computing engine which  consists  of
+hardware  and  software dedicated to serve a single user.  As part of
+its architecture, the workstation can invoke the resources of  other,
+physically  separate  components, effectively extending this personal
+environment well beyond the bounds of the single workstation.
+
+     In this personal environment,  processing  resources  previously
+shared  among  multiple  users  now become dedicated to a single one,
+with a large part of these resources summoned to provide an effective
+human-machine  interface.   As a consequence, modalities of input and
+output that were unfeasible under the time-shared regime now become a
+part of a conversational language  between user and workstation.  Due
+to the availability of processing cycles, and the  closeness  of  the
+user devices to these cycles, the workstation can support interactive
+devices, and dialogue modes using these devices, which could  not  be
+afforded before.
+
+     The workstation can provide the  user  with  the  mechanisms  to
+conduct  several  concurrent  conversations  with user-agents located
+elsewhere in the global architecture.   One  such  mechanism  is  the
+partitioning  of  the  workstation  physical  display  into  multiple
+logical  displays,  with  one  or  more  of  these  logical  displays
+providing a dedicated workspace between user and agent.
+
+     The nature of the conversations on these logical  displays  need
+not  be  limited  to  conventional  alphanumeric  input  and  output.
+Conversations using input tools  such  as  positioning  and  pointing
+devices  (e.g.,  mouse,  tablet, and such), and using high-resolution
+graphics objects for output (e.g., line drawings, raster  blocks  and
+images,  possibly  intermixed with text) should be possible on one or
+more of these screens.
+
+     Moreover, as long as the technological trend  continues  in  its
+predicted  path,  one can postulate a workstation which could support
+by the mid 1980's multi-media conversations using  voice  and  video,
+
+                                  1
+
+
+
+
+
+
+synchronized   with  text  and  graphics.   At  present,  multi-media
+information   management   (i.e.,   acquisition,   processing,    and
+dissemination)  is  an  active  research area, but eventually it will
+become an engineering problem which, when  solved,  will  add  a  new
+dimension  to  already feasible modes of interaction between user and
+workstation.
+
+1.2  Virtual Terminal Management
+
+     All virtual terminal protocols  (VTPs)  provide  a  vehicle  for
+device-independent,     bi-directional,     8-bit    byte    oriented
+communications between two VTP users.  Most Vo so by invoking  a
+device abstraction of real terminals, called a virtual terminal.
+
+     As with a real device, a virtual  terminal  has  a  well-defined
+architecture  with  its  own character sets and functions. A VTP uses
+the architectural features of  the  virtual  terminal  to  provide  a
+common  language,  an  intermediate  representation,  between its two
+communicating entities.  However a  VTP  user  does  not  communicate
+directly  with  this  virtual  terminal.   A function of a VTP is the
+local mapping between the site-specific order codes and  the  virtual
+terminal  domain,  thus allowing this adaptation to be transparent to
+the VTP users.
+
+     The model of a personal workstation as a dedicated  device  with
+considerable   resources    affects  the  way  we  conceptualize  the
+architecture of virtual terminals,  both  in  breadth  and  depth  of
+function.   It also affects the way we view the virtual terminal vis-
+a-vis its local correspondents, the personal  workstations,  and  its
+remote correspondents, the other virtual terminals.
+
+     This document presents a radical view of  virtual  terminals  as
+resource  sharing  devices.   The  classical  concept  of  a  virtual
+terminal as a two-way device with a  limited  architecture  has  been
+dismissed.   Instead,  we  view a virtual terminal as an n-way device
+with multiple correspondents sharing access to its virtual "keyboard"
+and  "display."  In  this  model, a virtual terminal has two kinds of
+correspondents:  adaptation units, and other virtual terminals.   The
+adaptation  units  serve  as  interface  agents  between  the virtual
+terminal and its users, providing the step transformation between the
+user-specific   order   codes  and  the  virtual  terminal  interface
+language.  In turn,  the  other  virtual  terminals  are  cooperating
+co-equals  of the  virtual  terminal, interacting with it to maintain
+global control and data store synchrony. Resembling the administrator
+of  a  local  copy  of  a distributed data base, the virtual terminal
+interacts with the other virtual  terminals  (the  remote  data  base
+managers)  and  with  the  local  adaptation  units  (the  data  base
+transformers) to provide read, write, and modify access to its  local
+
+                                  2
+
+
+
+
+
+
+
+
+
+data  store  (the  local  copy  of  the distributed data base), while
+providing concurrency control to maintain a "single user  view"  when
+so desired.
+
+     To communicate with its correspondents, a virtual terminal  uses
+two virtual languages. In the case where the correspondent is another
+virtual terminal, it  uses  the  language  of  the  virtual  terminal
+protocol;  in the case where the correspondent is an adaptation unit,
+it uses an interface language closer to the physical architecture  of
+the end-user, but a virtual language nevertheless.
+
+     In essence, the virtual terminal has become a device in its  own
+right,  free  from  a  single physical realization and also dedicated
+ownership. As a result, a single workstation not only may request any
+number  of  virtual  terminals,  but  a  number  of  workstations may
+share -- and interact with -- a particular virtual terminal.
+
+     The functional breadth of virtual terminals has  been  augmented
+by  the  concept  of  virtual  terminal  classes.   Each  class is an
+abstraction of a particular device architecture.  There  are  stream,
+line,  logical  page,  physical page, and graphics virtual terminals,
+all made up of:  a class-constrained data structure and its attendant
+operations  (the virtual display); a general controlling element (the
+virtual controller); and an input selector (the virtual keys).
+
+     Finally, the functional depth of the virtual terminal  has  been
+extended  by  architectural  features  previously  unavailable.   The
+virtual terminal becomes a  multi-user  device  with  a  non-volatile
+virtual  display available for selective viewing.  These concepts are
+discussed is some detail in the chapter that follows.
+
+1.3  The Scope
+
+     An overview of the virtual terminal model and the management  of
+communicating  virtual  terminals  is  presented.   A detailed design
+description  of  the  data  structures  and  accompanying  addressing
+functions  has been completed.  The operations and control mechanisms
+are less complete.  Before  the  design  is  solidified,  an  initial
+mimimal implementation will be made to validate the model.
+
+     This document represents work in progress; current international
+interest  in  virtual  terminal  protocols has motivated us to submit
+this as an example of  mechanisms  that  a  virtual  terminal  should
+support.   The  model  provides a framework for supporting device and
+processing  capabilities  not  yet  commonly  available.   A  virtual
+terminal  protocol standardization effort may not want to include all
+the mechanisms that are described here, but it is our contention that
+one should not preclude these extensions for the future.
+
+                                  3
+
+
+
+
+
+
+
+1.4  Related Work
+
+     The concepts presented in this document  are  the  offspring  of
+previous  work  in  the  area  of  personal  computing,  and  of user
+interfaces to (distributed) systems.  The bibliography at the end  of
+the  document  collects  this  material.  In  particular,  we want to
+acknowledge the work done at the University of Rochester  on  virtual
+terminals,(6)   work  which  has  influenced to a large degree how we
+view user interfaces through a display.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                  4
+
+
+
+
+
+
+
+2.0  THE VTM MODEL
+
+     This section describes a virtual terminal management (VTM) model
+whose  architecture  not  only  derives  from  a  quest  for  device-
+independent, terminal-oriented communications, but  more  importantly
+from a desire to provide effective human-machine interfaces.
+
+     The VTM architecture  is  a  multi-user  structure  which  spans
+several  building blocks. The underlying foundation to this structure
+is provided by the cooperating  virtual  terminals.   Under  the  VTM
+model,  these  cooperating  virtual  terminals  are  viewed as device
+abstractions, all with  a  common  architecture,  exchanging  virtual
+terminal  protocol  items  to  update each other's view of the world.
+Resting on this foundation lie the adaptation units.  Associated with
+a   single   end-user,   an   adaptation   unit   provides  the  step
+transformation between user and virtual  domains.   In  a  sense  the
+adaptation  unit  is  also  a virtual terminal, although one which is
+much closer to the architecture of the end-user.  Finally, on top  of
+this  supporting  structure  are  the  end-users, the application and
+human processes, all interacting towards a common goal.
+
+     Before embarking on a description of the VTM  model  components,
+we  present  the  set of capabilities the VTM model provides its end-
+users, either human or application.  After all,  the  motivation  for
+the  model  and  its  underlying  concepts  stems  from our desire to
+provide productive user environments.
+
+     HUMAN  <--->  WORKSTATION
+
+     o   Multiplexing the workstation physical display both  in  time
+         and space.
+
+         The workstation assigns to each user conversation a  logical
+         terminal  with  a well-distinguished logical display.  Under
+         the  user  control,  the  workstation  maps  these   logical
+         displays  on  non-overlapping areas of the physical display,
+         providing   a   dedicated   workspace   between   user   and
+         correspondents.   Limited  only  by the area of the display,
+         many logical displays could be  mapped  at  one  time,  each
+         providing  display updates when so required.  Since the area
+         of the  display  is  a  scarce  resource,  not  all  logical
+         displays  need  be  mapped at the same time.  Therefore, the
+         workstation may roll-out and roll-in selected displays under
+         the  user  control,  thereby  also multiplexing the physical
+         display in time.
+
+     o   Multiplexing the workstation input devices in time.
+
+
+                                  5
+
+
+
+
+
+
+
+         The input devices always map to a single  user  conversation
+         (i.e.,  a  single  logical terminal).  However, the user can
+         select  a  new  logical  terminal   by   some   well-defined
+         interaction  (e.g.,  depressing  a  function  key,  using  a
+         pointing  device,  and  such),  effectively  switching   the
+         ownership of the input tools.
+
+     o   Concurrent multi-mode use of the workstation.
+
+         The capabilities of the  workstation  limit  the  scope  and
+         character   of   the   individual   conversations.   If  the
+         workstation  supports   rubout   processing   (i.e.,   erase
+         operations  on  lines  and  characters),  then  the  logical
+         terminals can be independent,  scrolling  "terminals,"  some
+         page-oriented, others line-oriented.  If the architecture of
+         the  workstation  supports  graphics  objects  as  primitive
+         objects  then so can the individual logical terminals.  As a
+         consequence, while some logical  terminal  displays  may  be
+         dedicated  to alphanumeric output, others may include raster
+         graphics and imaging data together with positioned text.
+
+     o   The sharing of  a  single  logical  terminal  among  several
+         users.
+
+         Several end-users may link to  a  single  logical  terminal.
+         All linked parties are viewed by the shared "device" as both
+         input sources and  output  sinks.   As  a  consequence  this
+         device  sharing  need  not be limited only to the sharing of
+         device output. In general, each linked party may  have  full
+         read  and  write  access  to  the logical terminal, if it so
+         desires.
+
+     o   Selective viewing on a logical terminal display.
+
+         In the user's view, a logical terminal display  is  a  user-
+         specified  window  on  a  potentially  larger structure, the
+         "device"  display.   This  window  provides  the  "peephole"
+         through  which the device display is viewed.  The portion of
+         the device display mapped on this window is not  limited  to
+         its   "present   contents."  Under  the  user  control,  the
+         workstation may invoke the viewing of  past  activity  on  a
+         logical  terminal  display  when  the  device display is I/O
+         file-extended.  Since the window mechanism  is  an  integral
+         part  of  the  device  architecture,  it is available on all
+         logical terminal displays.  Furthermore, the viewing of past
+         activity  does  not  affect  others  sharing  access  to the
+         device.
+
+
+                                  6
+
+
+
+
+
+
+
+     o   Discarding, suspending, and resuming the output of a logical
+         terminal always under user control.
+
+         As part of the  user  interface,  the  workstation  provides
+         simple  "keys" through which the user controls the output on
+         a logical terminal display.  These workstation  "keys"  need
+         not  be  physical  keys, but could be other input tools used
+         for this purpose (e.g., analog dials, hit-sensitive areas on
+         the  physical display, and such).  In any event, through the
+         auspices of the workstation,  the  user's  control  requests
+         translate   into   the   proper  commands  to  the  "device"
+         associated with the logical terminal.
+
+     APPLICATION  <--->  ADAPTATION UNIT
+
+     o   A logical view of real devices.
+
+         For  each  real   terminal   architecture,   one   canonical
+         representation:  a logical device.
+
+     o   For  a   particular   logical   device,   several   possible
+         interaction paradigms.
+
+         Some logical devices are intrinsically half-duplex (e.g.,  a
+         page-oriented  logical  device), some are full-duplex (e.g.,
+         communicating  processes  using  a  stream-oriented  logical
+         device), and some may be either half or full-duplex (e.g., a
+         line-oriented logical  device).   Some  full-duplex  logical
+         devices  can  provide  no  echoing, remote echoing, or local
+         echoing.   Those  that  interface  with  applications   that
+         support command completion (e.g., command-line interpreters)
+         can shift the locus of echoing as a function  of  a  dynamic
+         break character set.
+
+     o   One application communicating with several logical devices.
+
+         As  part  of  an  application's  model  of  interaction,  an
+         application may "own" several logical devices.  For example,
+         an editor could use a line-oriented logical device to gather
+         top-level  commands,  and  a page-oriented logical device to
+         provide editing workspace.
+
+2.1  The VTM Model Components
+
+     The virtual terminal management  model  consists  of  two  major
+components:   the  virtual  terminal model, and the workstation model
+(see Figures 2.1, 2.2, and 2.3 respectively).
+
+
+                                  7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              AU1
+                               |
+                         AU0   |    AU2
+                          |    |     |
+                         _______________
+                         |             |
+                         |     VT2     |
+                         |             |
+                         |             |
+                         _______________
+                                |       _______________
+                                |       |             |----AU0
+                                |_______|     VT0     |
+                                |_______|             |
+                                |       |             |----AU1
+                                |       _______________
+                                |
+                         ________________
+                         |              |
+                         |              |
+                         |     VT1      |
+                         |              |
+                         ________________
+                          |     |     |
+                         AU0    |    AU2
+                                |
+                               AU1
+
+
+VT = VIRTUAL TERMINAL
+AU = ADAPTATION UNIT
+
+
+
+               FIGURE 2.1 - THE VIRTUAL TERMINAL MODEL
+
+
+
+
+
+
+
+
+                                  8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                    ___  ___               ___  ___
+                   |VT1||VT2|             |VT1||VT2|
+                   ____ _____             _____ ____
+                    |     |                 |    |
+                  __|_____|_________________|_____|__
+                  | |     | |             | |     |  |
+                  |  REMOTE | -CONTROLLER-|  REMOTE  |
+                  |   KEYS  |             | DISPLAYS |
+                  |         |             |          |
+                  | VIRTUAL |             |   DATA   |
+                  |   KEYS  |             |  STORE   |
+                  |         |<----------->|          |
+                  |  LOCAL  |             |   LOCAL  |
+                  |   KEYS  |             | DISPLAYS |
+                  |         |             |          |
+                  __|_____|__________________|_____|__
+                    |     |                  |     |
+                   ____ ____               _____ ____
+                  |AU0||AU1|               |AU0||AU1|
+                   ____ ____               _____ ____
+
+
+
+          FIGURE 2.2 -- VT0 (expanded from previous figure)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                  9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                              +--------------------+
+                              |                    |
+                            o-|-------------------|
+                              |     EXECUTIVE      |
+                              |--------------------|
+   Screen        +-------+  o-|--------------------|      +-----+
++---------+     /|OUTPUT |    |  ADAPTATION UNIT 0 |<---->| VT0 |
+|EXECUTIVE|    / |       |<---|--------------------|      +-----+
+|---------|   /  |HANDLER|  o-|--------------------|      +-----+
+|   AU0   |  /   |-------|    |  ADAPTATION UNIT 1 |<---->| VT1 |
+|---------| /    | INPUT |    |--------------------|      +-----+
+|   AU1   |/     |       |  o-|--------------------|
+|---------|      |HANDLER|    |         .          |
+|         |      |    /--|o   |         .          |
+~         ~      +-------+   ~         .          ~
+~         ~         /        ~                    ~
+|---------|        /        o-|--------------------|      +-----+
+|   AUK   |       /           |  ADAPTATION UNIT K |<---->| VTK |
++---------+      /            +--------------------+      +-----+
+                /             |                    |
++---------+    /              +--------------------+
+|Keyboard |   /
++---------+  /
+|[] [] [] | /
+|[] [] [] |/
++---------+
+
+
+
+                 FIGURE 2.3 - THE WORKSTATION MODEL
+
+
+
+The first component embodies the canonical device, while  the  second
+component   includes   the   adaptation   unit   and  its  associated
+environment.  Each component will be described in turn below.
+
+2.2  The Virtual Terminal Model
+
+     The objective of virtual terminal protocols is  to  provide  the
+users  of  the service with a common, logical view of terminals.  The
+common user  view  is  attained  through  a  standard,  protocol-wide
+representation  of  a canonical terminal, the virtual terminal.  This
+
+                                 10
+
+
+
+
+
+
+
+permits the exchanges between users of the protocol  to  be  free  of
+device-specific encodings.
+
+     The design postulates an integrated virtual terminal model which
+extends  the  nature  and  scope  of this canonical device in several
+important ways.  The major aspects of the  model,  its  connectivity,
+its organization, and its architecture are described below.
+
+     2.2.1  Virtual Terminal Connectivity
+
+     Most virtual terminal protocols only cater to two-way  dialogues
+in  which  a  single  virtual  terminal  terminates  each  end of the
+communication path.
+
+     We define the virtual terminal as a n-way device  where  one  or
+more  of  the  correspondents  to  this device are local users of the
+service, and the remaining correspondents (if any) are  peer  virtual
+terminals.   Each  correspondent  to the virtual terminal has its own
+bi-directional path to produce virtual input to, and receive  virtual
+output from, the virtual terminal.  This bi-directional path provides
+the vehicle for a virtual terminal session between user  and  virtual
+terminal.   Globally, the cooperating virtual terminals and these bi-
+directional paths span a dendritic (tree-like) topology.
+
+     It is important to note  that  we  have  decoupled  the  virtual
+terminal  from  its  physical  realization,  a  single real terminal.
+Indeed, a virtual terminal does not map necessarily to just one  real
+device, but possibly to many real devices.
+
+     The virtual terminal is viewed ultimately as a well-defined data
+structure  which  provides  its  correspondents  with a non-dedicated
+virtual terminal service.  And these  correspondents  may  have  read
+only, write only, or read/write access rights to this data structure.
+
+     2.2.2  Virtual Terminal Organization
+
+     The virtual terminal is an abstraction;  its  organization,  the
+building  blocks which make up the virtual terminal, is the result of
+a feature extraction of the real terminal  that  it  is  tailored  to
+support.
+
+     We have conceptualized the virtual terminal as  a  meta-terminal
+(i.e.,  the terminal of terminals).  The meta-terminal is composed of
+three well-distinguished building  blocks: virtual  keys,  a  virtual
+controller, and a virtual display.
+
+
+
+
+                                 11
+
+
+
+
+
+
+     2.2.2.1  The Virtual Keys.  The analog of the  virtual  keys  is
+the  physical keyboard of real terminals.  However, while the keys of
+a physical terminal are controlled by a single manual process,  these
+virtual  keys  can be activated by multiple, concurrent entities (the
+virtual terminal correspondents).  Each correspondent of the  virtual
+terminal, be it a user of the service or a peer virtual terminal, has
+its input stream to the meta-terminal terminated at the virtual keys.
+The  virtual  keys  provide the control of access of input streams to
+the meta-terminal.
+
+
+     2.2.2.2    The Virtual Controller.    The   virtual   controller
+provides   virtual  terminal  session  management.   It  manages  the
+establishment and termination of a virtual terminal  session  with  a
+correspondent; supports the possible negotiation and renegotiation of
+the session  attributes;  and  enables  the  deactivation  and  later
+activation  of  the  session.   The  virtual controller also provides
+virtual terminal  signalling  control  by  managing  the  out-of-band
+signals addressed to the virtual terminal.
+
+
+     2.2.2.3   The Virtual Display.   The  virtual  display  is   the
+dynamic  component in the meta-terminal organization.  For each class
+of  real  device  (e.g.  stream,  line,  page,  or  graphics-oriented
+devices)  there  is  a  corresponding  virtual  terminal  class.  The
+organization  of  the  virtual  terminal  data  structure  is  class-
+specific.  A virtual terminal models a particular terminal class when
+it is 'fitted' with the proper  data  structure  manager  or  virtual
+display.   This  binding  need  not  be  static  (e.g.,  a line-class
+specialist, and so forth), but could be result of decisions  made  at
+"run-time" by applying the principle of negotiated options.
+
+     The virtual display manages the data structure  associated  with
+the  meta-terminal  and  performs  operations on the control and data
+elements  of  the  structure.  As  a  direct  consequence  of   these
+operations  on  the meta-terminal data structure, the virtual display
+may  generate  display  updates  to  one,  some,  or   all   of   the
+correspondents.  All virtual terminal output streams originate at the
+virtual display.
+
+     Different virtual terminal  classes  are  spawned  by  different
+"kinds" of virtual displays, and this is realized in one of two ways.
+For character-oriented virtual devices,  it  is  possible  to  use  a
+single,  wide-scoped  virtual  display with a character-oriented data
+structure by constraining it to conform to the model  of  the  device
+class (e.g., line-oriented devices must be constrained to line-access
+rules).  For non character-oriented virtual devices  (e.g.,  graphics
+devices),  an  altogether different virtual display must be used with
+
+                                 12
+
+
+
+
+
+
+properties better suited for the new domain (e.g., a graphics virtual
+display based on a structured display file).
+
+     2.2.3  Virtual Terminal Architecture
+
+     The commands, and associated parameters, which are available  to
+the  users  of  the  virtual terminal constitute the virtual terminal
+architecture.  The commands available to a user  --  to  request  the
+virtual  controller  to  establish,  abort,  or  close a session, and
+discard, suspend, or resume output -- remain invariant to the virtual
+terminal  class.  However, as one would expect, the user interface to
+the virtual display depends on the nature of this data structure.
+
+     Three important architectural features of the meta-terminal are:
+the concept of communication variables, the notion of a file-extended
+virtual display, and the concept of virtual display windows. Each  of
+these  concepts  are a part of the meta-terminal architecture because
+they are apparent to the users of the virtual terminal.
+
+
+     2.2.3.1  Communication Variables.  Each component of  the  meta-
+terminal  (i.e.,  virtual  keys,  controller,  display) is assigned a
+standard, protocol-wide name which we call a communication  variable.
+The communication variable is a part of the header of each command to
+the  virtual  terminal  (i.e.  protocol  item).   It  permits  better
+management  of  the  virtual  terminal  command  name space, and also
+provides the virtual keys  with  an  easy  mechanism  to  select  the
+destination  of  the  request.   It must be noted that nothing in the
+model precludes the addition of more virtual entities  to  the  meta-
+terminal,  such  as auxiliary virtual devices and signalling devices.
+The use of communication variables provides a naming hierarchy  which
+alleviates   the  problems  of  device  selection  and  command  name
+allocation in the case of such extensions.
+
+
+     2.2.3.2    Virtual Display with File Extension.    The   virtual
+display is the immediate manager of the meta-terminal data structure.
+When the virtual display is provided with an I/O file  extension,  it
+is   possible  to  introduce  the  concept  of  a  stable-store  data
+structure, a data structure whose  contents  are  stored  in  backing
+store  (e.g.,  disk).   If  the virtual display is provided with this
+file  extension  capability  (a  local  option  with  no   end-to-end
+significance),  then  the  meta-terminal  data structure inherits the
+spatial and temporal attributes (dimensions and time-to-live) of  the
+associated file.  Such a virtual display, coupled with the concept of
+virtual display windows below, provides the users of the service with
+a very powerful tool.
+
+
+                                 13
+
+
+
+
+
+
+     2.2.3.3  Virtual Display Windows.  To communicate with a virtual
+terminal,  each  real device uses an adaptation unit as its interface
+entity (this adaptation unit is a part of the workstation model,  see
+section  2.3).  What is important to note is that the adaptation unit
+provides the  transition  between  the  device-specific  domain,  the
+device workspace,  and  the virtual domain, the master workspace (see
+Figure 2.4).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 14
+
+
+
+
+
+
+
+ |                                 |                                   |
+ |        VIRTUAL TERMINAL         |         ADAPTATION UNIT           |
+ |<------------------------------->|<--------------------------------->|
+ |             DOMAIN              |              DOMAIN               |
+ |                                 |                                   |
+
+ + - - - - - - - - - +   + - - - - - - - - - +        - - - - - - - - -
+ |  +--->  x(m)      |   |                   |       /                /|
+ |  |                |   |            x(i)   |      /                / |
+ |  v  y(m)          |   | +---------------> |      - - - - - - - - -  |
+ |                   |   | |              |  |     | +------------+ |  |
+ | +--------------+  |   | |              |  |     | | VIEWPORT 1 | |  |
+ | |              |  |   | |              |  |     | |            | |  |
+ | |              |  |   | |              |  |     | |            | |  |
+ | |              |  |   | |              |  |     | |            | |  |
+ | |              |  |   | |              |  |     | |            | |  |
+ | |              |  |   | |   A<---------|--|-----|-|->A         | |  |
+ | |              |  |   | |  / \         |  |     | |            | |  |
+ | |     <--------|--|---|-|->   \        |  |     | |            | |  |
+ | |    /         |  |   | |      \       |  |     | |        <---|-|--|+
+ | |    A         |  |   | |       \      |  |     | +------------+ |  ||
+ | |              |  |   | |        \     |  |     |                |  ||
+ | |     WINDOW   |  |   | |         \    |  |     | +------------+ |  ||
+ | |              |  |   | |          \   |  |     | | VIEWPORT 2 | |  ||
+ | |              |  |   | |-----------\--+  |     | |            | |  ||
+ | |              |  |   | |            \    |     | |            | |  ||
+ | +--------------+  |   | v  y(i)       \   |     | +------------+ |  ||
+ |                   |   |                \  |     |                | / |
+ |                   |   |                 \ |     |                |   |
+ |                   |   |                  \|      - - - - - - - -     |
+ |     /             |   |       /           |            |  |          |
+ + - -/- - - - - - - +   + - - -/- - - - - - +\           |  |          |
+     /                         /               \     - - - - - - - -    |
+    /                         /                 \   |    KEYBOARD   |   |
+  MASTER WORKSPACE         INSTANCE WORKSPACE    \  + - - - - - - - +   |
+                                                  <-/   []  []  [] /|   | 
+                                                   /   []  []  [] / |   |
+                                                  + - - - - - - - - +   |
+                                                                        |
+                                            PHYSICAL DEVICE WORKSPACE --+
+
+
+                           FIGURE 2.4 -- THE DOMAINS
+
+
+
+
+
+
+                                 15
+
+
+
+
+
+
+
+However  a  device  need  not  be  interested  in  the  whole  master
+workspace,  only  in  a  portion  of  it.   As  part  of  its session
+attributes, each adaptation unit has a window, a  rectangular  region
+in  the  virtual  display, which delimits its area of interest in the
+master.  This portion of the master domain will be  referred  as  the
+instance workspace.   Then,  for  each  adaptation  unit, there is an
+instance workspace whose spatial attributes (dimension  and  position
+within the master) are those of its window definition.
+
+     All adaptation  units  communicate  with  the  virtual  terminal
+"relative"  to  their  own instance workspace.  As far as the virtual
+terminal is concerned,  each  instance  workspace  defines  a  "real"
+terminal,  although in fact it is just an intermediate representation
+of the real device.   In  essence,  the  instance  workspace  is  the
+coordinate  space  where  both  virtual  terminal and adaptation unit
+rendezvous. (See section 2.3 for a discussion of  how  this  instance
+workspace is mapped onto the device workspace).
+
+     The window dimensions are the exclusive choice of the adaptation
+unit  that  owns  it.   With  these  dimensions  the  adaptation unit
+specifies to the virtual terminal how much of the  master  is  to  be
+viewed; data  elements  not  contained  within  the boundaries of the
+window are clipped.  Varying the dimension of the window  results  in
+corresponding changes on the amount of the master that is viewed.
+
+     In contrast, the position of the window on the master might  not
+be  under  direct  control of the adaptation unit.  To understand the
+dynamics of a window, we introduce the notion of a master cursor  and
+an instance cursor.  The master cursor is a read/write pointer, which
+is a part of the virtual display architecture.  In turn, the instance
+cursor  is a pointer owned by the adaptation unit, which is a part of
+the state information maintained by the virtual  display.   Normally,
+both master and instance cursors are bound together so that motion of
+one cursor translates into an equivalent motion  of  the  other.   As
+long  as  the adaptation unit does not explicitly unbind its instance
+cursor from the master cursor, the active region of the master (i.e.,
+the position where the master cursor lies) is guaranteed to be always
+within the instance  space,  and  thus  viewable.   This  means  that
+certain  operations  on  the virtual display will implicitly relocate
+the window of an adaptation unit within  the  bounds  of  the  master
+workspace  to  insure the tracking of the master cursor.  (The actual
+algorithm which enforces  this  tracking  rule,  called  the  viewing
+algorithm,  has  not  been included here.)  This window relocation is
+
+
+                                 16
+
+
+
+
+
+
+viewed  at  the  real  terminal  as  either  vertical  or  horizontal
+scrolling.
+
+     However, an adaptation unit has the choice to bypass  this  rule
+by detaching its instance cursor from the master, effectively getting
+complete control of its cursor to view other portions of  the  master
+space.   If  the  virtual display has an I/O file extension, then the
+adaptation unit can pan its window on the  file-extended  space  well
+beyond  the  present  contents of the master space.  Therein lies the
+power of a stable-store data structure when coupled with the  concept
+of windowing.
+
+2.3  The Workstation Model
+
+     The workstation model is composed  of  one  or  more  adaptation
+units,  and  a workstation monitor, which we will call the executive.
+Each will be  described  in  turn  below.   In  addition,  the  model
+includes  input  and output handlers, and an underlying multi-tasking
+operating system of unspecified architecture.
+
+     2.3.1  The Adaptation Unit
+
+     An adaptation unit embodies an instance of a  virtual  terminal,
+and  since  the  workstation model postulates possibly many different
+such  instances  per  physical  workstation,  then  potentially  many
+adaptation units will be co-located at a workstation.
+
+     The adaptation unit can be viewed as the workstation agent which
+provides the mapping between instance workspace and device workspace.
+To define this mapping, we introduce the notion of a  viewport  as  a
+rectangular  area of the physical screen allocated for the viewing of
+a virtual terminal instance.  An adaptation  unit  has  the  task  of
+mapping  the  totality of the instance workspace onto the viewport, a
+mapping which is a device-specific concern totally removed  from  the
+domain  of  discourse  of the virtual terminal.  Thus the position of
+the viewport determines the relocation of the selected data structure
+elements   on  the  viewing  unit,  and  the  viewport  dimensions  a
+(potential) scaling transformation.
+
+     The adaptation unit also produces virtual input to  the  virtual
+terminal   by  translating  the  user  input  into  virtual  terminal
+commands.  It implements the service side of  the  interface  to  the
+virtual terminal.
+
+
+
+
+
+
+                                 17
+
+
+
+
+
+
+     2.3.2  The Executive
+
+     This conceptual entity performs the task and resource management
+required to create and destroy virtual terminal instances, and to map
+these virtual terminal instances to the screen viewports.
+
+     It must provide at least a minimal  user  command  interface  so
+that  its  tools may be accessed (one of them being the management of
+screen real estate).
+
+     Finally, the executive provides the mechanism for  the  end-user
+to  switch  viewport  contexts  through  the use of some input device
+(e.g., function key, pointing or positioning  device).   Following  a
+user  interaction  which indicates a change of context, the executive
+makes the newly selected  virtual  terminal  instance  the  dedicated
+owner of the input devices.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 18
+
+
+
+
+
+
+                             REFERENCES
+
+
+
+1.   R. Bisbey II and D. Hollingworth.   "A  distributable,  display-
+     device-independent  vector  graphics  system  for  the  military
+     command   and   control   environment,"   Information   Sciences
+     Institute, Marina del Rey, California, April 1978.
+
+2.   Alan Branden, et al.  "Lisp Machine Project Report,"  Artificial
+     Intelligence  Laboratory, Massachusetts Institute of Technology,
+     AIM 444, August 1977.
+
+3.   John Day.  "TELNET Data Entry  Terminal  Option,"  ARPA  Network
+     Working   Group   RFC   732,  Network  Information  Center,  SRI
+     International, September 1977.
+
+4.   Douglas Gerhart and D. L. Parnas.  WINDOW  A  formally specified
+     graphics based   text   editor,   Computer  Science  Department,
+     Carnegie-Mellon University, June 1973.
+
+5.   B. W. Lampson and R. F. Sproull, "An Open Operating System for a
+     Single-User  Machine,"  Proc  7th Symposium on Operating Systems
+     Principles 9-17, ACM, December 1979.
+
+6.   Keith Lantz.  Uniform Interfaces for Distributed Systems,  Ph.D.
+     thesis, University of Rochester, Rochester, N.Y., May 1980.
+
+7.   Mathis, J.E., et al, "Terminal Interface Unit Notebook,"  Volume
+     2, ARPA Order No. 2302, SRI Project No. 6933, SRI International,
+     Menlo Park, California, 1979.
+
+8.   Allen Newell, Scott  Fahlman,  Bob  Sproull.   "A  Proposal  for
+     Personal  Scientific Computing," Department of Computer Science,
+     Carnegie-Mellon University, July 1979 (DRAFT).
+
+9.   "PERQ,"  Three  Rivers  Computer  Corp.,  160  N.   Craig   St.,
+     Pittsburgh, Pa. 15213.
+
+10.  Jon  Postel  and  Dave  Crocker.   "TELNET   Remote   Controlled
+     Transmission and Echoing Option," ARPA Network Working Group RFC
+     726, Network Information Center, SRI International, March 1977.
+
+
+
+
+
+
+
+                                 19
+
+
+
+
+
+
+11.  John F. Shoch and Jon A. Hupp.  "Notes on the 'Worm'  programs -
+     - some  early  experience with a distributed computation," Xerox
+     Palo Alto Research Center publication  SSL-80-3.   Presented  at
+     the  Workshop  on  Fundamental  Issues in Distributed Computing,
+     ACM/SIGOPS and ACM/SIGPLAN, December 1980.
+
+12.  R. F. Sproull and E. L. Thomas.  A  network  graphics  protocol,
+     Computer Graphics 8(3), Fall 1974.
+
+13.  C. P. Thacker, E. M. McCreight, B. W. Lampson,  R.  F.  Sproull,
+     and  D. R. Boggs.  "Alto: A Personal Computer." D. Siewiorek, C.
+     G. Bell,  and  A.  Newell,  Computer  Structures   Readings  and
+     Examples, editors, second edition, McGraw-Hill, 1979.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                 20
+
+
+
+
+
+