@make[article]
@device[x2700]
@style[spacing 1]
@modify[hd2,facecode=k]
@begin[text,topmargin=+1.3inches,leftmargin=+0.45inches,rightmargin=+0.6inches]
blank
@newpage
@section[The Need for a Virtual Terminal Specification]

Terminals are normally connected to the system  they are used on via a
direct connection, a connection  through  a  device  such as a circuit
switch which behaves as  if  the  terminal  was directly connected, or
through a network, local or wide area. The characteristic behaviour of
a  terminal  will  differ  depending  on  the  access  route  and  the
requirements for driving it will also differ.

The model matched by most computer  manufacturers in the past was that
of a simple, hard copy terminal that printed out a line at a time then
moved one line down the paper.  Although  most terminals are now based
on VDUs, the basic method of handling  them has remained the same, the
output is scrolled up the screen  one  line at a time. The consequence
of this is almost all ascii asynchronous terminals are capable of this
mode of operation. When a process  requires  to  use the terminal in a
more sophisticated manner then each  terminal  manufacturer has used a
different method to drive such operations  as clear the screen or move
to position x,y. The implication of  this  is  the tendency to have to
use a specific terminal type  with a particular computer manufacturer,
eg 3270 type terminals with  IBM  machines,  VT100 type terminals with
DEC VAX/VMS  systems,  or  for  the  operating  system,  or particular
process, to be capable of recognising  a wide range of terminal types,
possibly in excess of 30, such as with Unix systems.

Typically, if an incorrect or unrecognised  terminal type is used on a
particular system this will lead to a  lower quality of service to the
user. One obvious example of this is the  line by line use of an ascii
terminal on an IBM operating system.

The use of a terminal  through  a  network  causes new problems as the
terminal may well be used to  communicate  with a number of different,
incompatible,  hosts  and  inherent   network   delays   can  lead  to
differences in the way that the terminal must be handled.

The use of a Virtual Terminal Protocol removes these problems as it
handles the communication in a device independent manner.

@section(Requirements for a Virtual Terminal)

The requirements for a VT are  twofold,  firstly is the need to handle
output to the screen and secondly the need to control key strokes from
the user.

The handling of  screen  output  in  a  device  independent  manner by
encapsulating screen directives within a data  stream have now been in
use for a long  period  and  the  construction  of  a Virtual Terminal
Protocol to remove the  dependence  on  the  physical  hardware is not
difficult. Of more interest is the handling of 'newer' characteristics
such as emphasis, colour, different fonts and graphics.

Changing emphasis,  colour  and  to  a  certain  extent  fonts  is not
substantially more complex than the  simple requirements. Of much more
intrinsic difficulty is  the  handling  of  non-proportional fonts and
graphics, a challenge which has not been  met by any protocol which is
based on a simple rectangular character matrix.

The problem of handling key  strokes  from  the  user can be separated
into the handling of  echo  and  processing  of  special keys, such as
insert line and delete line. The  handling  of echo is only complex in
the networking environment. With a directly connected terminal, or one
that appears to be directly  connected,  it  is  feasible to allow the
host processor to receive each  keyboard  stroke and take the decision
as to whether, when and where to place any echo characters.

The more conventional way to  handle  echo,  eg  using local echo, can
cause destruction of the screen  image  as  control over keystrokes is
lost and so is not suitable  for  use  in  a screen image type process
such as form filling.

Special keys cause problems  with  all  types  of  connection, as with
output each manufacturer has chosen  a  different method of signalling
that a special key has been pressed.  The most common method is via an
escape sequence, for example the  character  escape followed by one to
three bytes to define the key pressed. There is nothing in common with
the number or function of keys supplied on the keyboard.

@section[Problems with Networked Terminals]

As has been shown above,  handling  terminals  across a network causes
additional problems to  those  associated  with  a  directly connected
terminal.

The most widely used non-manufacturer specific  protocol in use is XXX
(X.3, X.28 and X.29)[1]. These  protocols  describe a parameter driven
service rather than a true virtual  terminal model and was designed to
provide a line orientated display with simple editing facilities.
  Host applications which require  extensive  control of the displayed
image normally need more facilities than  are provided in the terminal
support. There is a tendency  for  hosts  to  use a particular mode of
operation of XXX to avoid the restrictions.

Firstly, local echo  of  user  keystrokes  is  suppressed. This avoids
damage to the screen image from user keystrokes.
 Secondly, the parameter which controls how  long the PAD waits before
forwarding characters in its input buffer  is  set to a very low value
to ensure the PAD will attempt to  send  each character to the host as
it is typed. A particular  problem  arises  with escape sequences. The
final character may well not be one  in  the forwarding set in use; so
if the PAD is not forwarding all  keystrokes then the sequence may not
be correctly interpreted by the host.

Host applications software operating in this  mode has full control of
the screen  image.  The  disadvantages  of  this  use  of  XXX  are as
follows:-

   All characters typed by the  user  which  are  echoed to the screen
must traverse the network twice. This  is necessary to ensure that the
host maintains full control of the contents of the display.

   Provision must be made in  the  host  to support each terminal type
attached to the network. Tables must be built to describe the terminal
characteristics such as erase screen and set cursor.

Across networks with any degree  of  inherent  delay  this leads to an
extremely poor response for the user  which is only tolerated as there
is currently no alternative. The number of packets, and hence the cost
of a call, generated by a  user  working  in this mode is greater than
the number generated by a simple line  by line conversation due to the
single character packets containing user input or the associated echo.

@section[A Simple Screen Management Protocol]

The heavy reliance on supporting terminal sessions across networks has
generated a lot of user  pressure  to  improve services. This has lead
the UK  Academic  Community  to  develop  a  protocol,  modelled  as a
intercept of  the  ISO  Forms  Class  Virtual  Terminal  Service.  The
protocol is called the Simple Screen Management Protocol or SSMP [2].

SSMP is  a  half-duplex  protocol.  The  control  and synchronisation,
handled by the Session Layer in the ISO model is handled within SSMP.
Connection establishment  and  Connection  Release  are  Session Layer
functions which are considered to  be  carried  by lower level network
services presenting an essentially error-free  environment to the SSMP
application.

SSMP operates by enabling the  host  to  define an arbitrary protected
area, or box, on the screen. While  the terminal end is processing the
input characters it echoes them to the screen until the user presses a
key which either moves the cursor outside the box or causes some other
function, for example move a  page,  which  necessitates action by the
host signalled by the transfer of the control token. While the host is
processing the input, potentially redrawing  the screen and redefining
the box, any user keystrokes are queued and processing of them delayed
until the terminal end has been passed the token.

@subsection{Implementation}

The protocol was published in  July 1985  and  work  has continued since to
provide implementations. Newcastle University, who  did the major work
in defining the protocol, have written both a reference implementation
in Pascal to  provide  a  portable  editor  for  a  host  system and a
corresponding implementation for a micro  to emulate the terminal end.
The micro end has now been implemented on a number of micros including
the IBM PC and  BBCs.  A  recent  development  is  a  cheap micro in a
package which is inserted between a  dumb  terminal and a PAD enabling
the terminal to work in  SSMP  mode.  Currently  less than 10 types of
terminal are supported  although  new  types  are  being  added as the
demand becomes apparent.

@subsection(Limitations)

SSMP is described as  a  simple  protocol because various restrictions
were imposed in order to  limit  the  scope  of the problem and ensure
that the protocol was developed inn  a reasonable time scale. The main
limitations are

@itemize[
Characters in use must be in the 128 instances defined in International
Standard 646.

The Display  Screen  model  is  a  rectangular  matrix  of  fixed size
characters.

Control of font and colour is excluded and only one display attribute
can be used on a character position.

The presence of a keyboard is assumed

Local processing capability is assumed.
]

@section[ISO Standards]

The work in ISO to produce a  VT  protocol  was split into a number of
distinct parts. Each part describes a class of protocol and the service
needed  to  support  the  protocol.  The   two  classes  that  we  are
particularly interested in here  are  the  Basic  Class  and the Forms
Class. Work in ISO progresses through a number of stages, the standard
is  published  first  as  a   Draft   Protocol   (DP),  then  a  Draft
International Standard (DIS)  and  finally  an  International Standard
(IS). Each stage is subject to a ballot,  and there can be a number of
ballots at any stage if disagreements still exist.

In June 1986, ISO published for  ballot  DIS  9040 and DIS 9041. These
are the service and protocol  standards  for Virtual Terminals - Basic
Class.

This VT  draft  standard  is  a  true  virtual  terminal  protocol and
represents an improvement over the  features  offered  by XXX. As such
the problems of handling  a  screen  image  rather  than a scroll mode
terminal have  been  addressed  and  thus  removes  the  necessity  of
identifying the terminal type

A number of features of  the  VT  represent a significant advance over
current facilities.  The basic display  object  can  be  up to a three
dimensional  array,  as  against  the  typical  2  dimensional  array.
Rendition attributes such as  emphasis,  foreground colour, background
colour and font have been defined.

There are a number of problems with  the DIS and raise questions as to
whether it will become an IS without substantial changes.

@itemise[
The control in the basic  protocol  of  input seems little better than
that offered by XXX.

It would appear to be  difficult  to handle special characters without
extensions although some functions have been implemented. For example,
erase line, erase part of line and  erase screen can be mapped but the
functions which require the movement  of  text  such as insert line do
not appear to be present.

There is no  provision  to  handle  a  'break  in'  from  a  user, and
unsolicited messages from a host,  for  example  a status message from
the operating system.

A large number of features, potentially  enough to handle the problems
listed enough can  be  put  into  'profiles'.  The  problem  with this
approach is that  it  could  lead  to  large  numbers  of incompatible
implementations.
]

   The ISO standard which will  address  more  of  the problems is the
Forms Class Virtual Terminal Service but  work  on this class is still
at an early stage.

@section{The Impact of Personal Computers}

With the first influx of  personal  computers  there was an assumption
that mainframes or even  minicomputers  would  no longer be necessary.
The reality is somewhat  different.  First  of  all the penetration of
PCs into user communities  has  not  been  as  complete as some people
predicted, second, those with  PCs  discovered  that not all functions
can be handled by their own machine  and limitations of store, disc or
compute power means that they are also used as terminals.

The current method of connection of a  PC to a larger machine tends to
be implemented via simple terminal emulation  software in the PC. This
method of course means that  the  functionality  is little better than
the emulated terminal although one would expect to be able to exchange
files with the host machine.

The availability of a user programmable  processor within the PC makes
it ideal for hosting  a  Virtual  Terminal  Protocol and, if anything,
tends to highlight the need for such a protocol.

The use of a Virtual Terminal  emulator  is  not the ideal solution. A
better model is a much closer relationship between the PC and its host
computer, possibly executed with the use  of remote procedure calls to
allow the user  to  call  upon  the  resources  of  the larger machine
without the inconvenience  of  'leaving'  his  known environment.  The
protocols necessary to implement any  general solution to this problem
are potentially more difficult than  VT  protocols  and so will not be
seen for a correspondingly longer period.


@section[Conclusion]

There is a significant  user  demand  for  Virtual Terminal facilities
which are not yet addressed by ISO. To a certain extent the problem is
that the demand is for a moving  target,  whereas a basic VTP may have
been sufficient a  few  years  ago  the  current  demand is orientated
towards documents with their  problems  of  proportional fonts and the
ability to mix text and graphics.

The use of  microcomputers  as  terminals  will  require  a completely
different style of protocol to make  full  use of the potential of the
micro and mainframe combination but it  does not seem to be beneficial
to hold off until a solution appears because of the long timescale.

In the short term it is important to give ISO encouragement to produce
workable protocols as soon as possible.

@section(References)

@enumerate{

CCITT Recommendation X.3, X.28 and X.29 (1980, 1984)

A Simple Screen Management Protocol - The Joint Network Team, C/o
Rutherford Appleton Laboratory, Chilton, Didcot, Oxfordshire
OX11 0QX
}