Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!GATEWAY.MITRE.ORG!rick
From: rick@GATEWAY.MITRE.ORG
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Terminal servers and 3270 emulation
Message-ID: <8902271834.AA01285@mars.mitre.org>
Date: 27 Feb 89 18:34:45 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49

This is off the original subject of availability of forms-oriented
terminal servers, but I thought I'd agree with Marty about a
terminal description server...

You are correct about the exchange of curses-type information
not being covered in the ISO VT standard.  It's generally considered
that this is only useful for the mapping of VT updates to a specific
terminal type, and is therefor a "local" rather than a "peer to peer"
protocol matter. The VT standard only defines communications between
2 peer VTs and doesn't have an idea of a terminal description server.

I suppose in the ISO world the proper way to look at this may be to
register the terminal information in the directory. (could a name
domain record type be devised for this?)  This may take
care of the need for a protocol to distribute the info, but it definitely
still requires standards for the format of the information. Maybe there
needs to be more than one format for different terminal classes
(possibly screen-oriented ala curses, forms-oriented, and graphics).

This kind of information might be used by a variety of clients:

1. terminal servers, as you suggested

2. TELNET or ISO VT client programs.  This would be to help them
map either generic VT updates to a physical terminal, or one type
of data stream (ie. 3270) to another (ie. async dumb terminal).

3. applications that want to control terminals directly.
This, of course,contradicts the VT idea that anything being sent across
a network to a terminal should be in a standard (device-independent) format.
On the other hand it is exactly what happens when someone telnets
to a remote unix box and fires up "vi".  A well designed, standard
representation (or set of representations)
for the terminal capability data may just expand this
approach beyond curses/termcap/terminfo.  Wasn't there a project some
years ago at Berkeley to define a termcap-like description for
graphics terminals? Anybody know about it?

By the way, it's not yet clear what method of supporting 
forms-oriented applications will be popular using ISO VTP.  
There is a FORMS VT profile defined by the NIST OSI workshop,
but some favor the idea of sending 3270 data streams through
a "transparent" VT (ala tn3270). Here at MITRE we have a prototype of a 
VT FORMS implementation and are looking for someone to test
interoperability with. This implementation uses curses to map
VT FORMS updates to async. terminals.

-Rick Wilder (rick@gateway.mitre.org)