ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (03/31/89)
Here is the NEW list of terminal names that I've collected. New names start
with an "x". There are now 270 names vs. the 177 in RFC 1010. If your favorite
still isn't here, let me know! I grabbed many of these from termcap. Some
names may not be accurate.
YES, XTERM and SUN are included! Can anyone think of a better name for these?
Maybe a version number (X11.3) should be included?
Drew
RFC XXX - Assigned Numbers 1989
Terminal Type Names
TERMINAL TYPE NAMES
These are the Official Terminal Type Names. Their use is described
in RFC 1091 [97]. The maximum length of a name is 40 characters.
A terminal names may be up to 40 characters taken from the set of
uppercase letters, digits, and the two punctuation characters hyphen
and slash. It must start with a letter, and end with a letter or
digit.
ADDS-CONSUL-980
ADDS-REGENT-100
ADDS-REGENT-20
ADDS-REGENT-200
ADDS-REGENT-25
ADDS-REGENT-40
ADDS-REGENT-60
x ADDS-VIEWPOINT
x ADDS-VIEWPOINT-60
x AED-512
x AMPEX-DIALOGUE-210
AMPEX-DIALOGUE-80
x AMPEX-210
x AMPEX-230
x ANDERSON-JACOBSON-510
ANDERSON-JACOBSON-630
ANDERSON-JACOBSON-832
ANDERSON-JACOBSON-841
ANN-ARBOR-AMBASSADOR
x ANSI
ARDS
BITGRAPH
BUSSIPLEXER
CALCOMP-565
CDC-456
CDI-1030
CDI-1203
x C-ITOH-101
x C-ITOH-50
x C-ITOH-80
CLNZ
COMPUCOLOR-II
CONCEPT-100
CONCEPT-104
CONCEPT-108
DATA-100
DATA-GENERAL-6053
DATAGRAPHIX-132A
DATAMEDIA-1520
DATAMEDIA-1521
DATAMEDIA-2500
DATAMEDIA-3025
DATAMEDIA-3025A
DATAMEDIA-3045
DATAMEDIA-3045A
DATAMEDIA-DT80/1
DATAPOINT-2200
DATAPOINT-3000
DATAPOINT-3300
DATAPOINT-3360
DEC-DECWRITER-I
DEC-DECWRITER-II
x DEC-GIGI
DEC-GT40
DEC-GT40A
DEC-GT42
DEC-LA120
DEC-LA30
DEC-LA36
DEC-LA38
DEC-VT05
DEC-VT100
x DEC-VT101
x DEC-VT102
x DEC-VT125
x DEC-VT131
DEC-VT132
x DEC-VT200
x DEC-VT220
x DEC-VT240
x DEC-VT241
x DEC-VT300
x DEC-VT320
x DEC-VT340
DEC-VT50
DEC-VT50H
DEC-VT52
x DEC-VT55
x DEC-VT61
x DEC-VT62
DELTA-DATA-5000
x DELTA-DATA-NIH-7000
DELTA-TELTERM-2
DIABLO-1620
DIABLO-1640
DIGILOG-333
DTC-300S
x DTC-382
EDT-1200
EXECUPORT-4000
EXECUPORT-4080
x FACIT-TWIST-4440
x FREEDOM-100
x FREEDOM-110
x FREEDOM-200
GENERAL-TERMINAL-100A
x GENERAL-TERMINAL-101
GSI
x HAZELTINE-1420
HAZELTINE-1500
HAZELTINE-1510
HAZELTINE-1520
x HAZELTINE-1552
HAZELTINE-2000
x HAZELTINE-ESPRIT
x HP-2392
HP-2621
HP-2621A
HP-2621P
x HP-2623
HP-2626
HP-2626A
HP-2626P
x HP-2627
HP-2640
HP-2640A
HP-2640B
HP-2645
HP-2645A
HP-2648
HP-2648A
HP-2649
HP-2649A
x IBM-1050
x IBM-2741
IBM-3101
IBM-3101-10
IBM-3275-2
IBM-3276-2
IBM-3276-3
IBM-3276-4
IBM-3277-2
IBM-3278-2
IBM-3278-3
IBM-3278-4
IBM-3278-5
IBM-3279-2
IBM-3279-3
x IBM-5151
x IBM-5154
x IBM-5081
x IBM-6153
x IBM-6154
x IBM-6155
x IBM-AED
IMLAC
INFOTON-100
x INFOTON-400
INFOTONKAS
ISC-8001
x LSI-ADM-1
x LSI-ADM-11
x LSI-ADM-12
x LSI-ADM-2
x LSI-ADM-20
x LSI-ADM-22
x LSI-ADM-220
LSI-ADM-3
LSI-ADM-31
LSI-ADM-3A
LSI-ADM-42
x LSI-ADM-5
MEMOREX-1240
MICROBEE
MICROTERM-ACT-IV
MICROTERM-ACT-V
x MICROTERM-ERGO-301
MICROTERM-MIME-1
MICROTERM-MIME-2
x MICROTERM-ACT-5A
x MICROTERM-TWIST
x NEC-5520
NETRONICS
NETWORK-VIRTUAL-TERMINAL
OMRON-8025AG
PERKIN-ELMER-1100
PERKIN-ELMER-1200
x PERKIN-ELMER-550
PERQ
PLASMA-PANEL
QUME-SPRINT-5
x QUME-101
x QUME-102
SOROC
SOROC-120
SOUTHWEST-TECHNICAL-PRODUCTS-CT82
x SUN
SUPERBEE
SUPERBEE-III-M
TEC
x TEKTRONIX-4006
TEKTRONIX-4010
TEKTRONIX-4012
TEKTRONIX-4013
TEKTRONIX-4014
TEKTRONIX-4023
TEKTRONIX-4024
TEKTRONIX-4025
TEKTRONIX-4027
x TEKTRONIX-4105
x TEKTRONIX-4107
x TEKTRONIX-4110
x TEKTRONIX-4112
x TEKTRONIX-4113
x TEKTRONIX-4114
x TEKTRONIX-4115
x TEKTRONIX-4125
x TEKTRONIX-4404
TELERAY-1061
TELERAY-3700
TELERAY-3800
TELETEC-DATASCREEN
TELETERM-1030
TELETYPE-33
TELETYPE-35
TELETYPE-37
TELETYPE-38
x TELETYPE-40
TELETYPE-43
x TELEVIDEO-910
TELEVIDEO-912
TELEVIDEO-920
TELEVIDEO-920B
TELEVIDEO-920C
x TELEVIDEO-925
x TELEVIDEO-955
TELEVIDEO-950
x TELEVIDEO-970
x TELEVIDEO-975
TERMINET-1200
TERMINET-300
TI-700
TI-733
TI-735
TI-743
TI-745
x TI-800
TYCOM
UNIVAC-DCT-500
VIDEO-SYSTEMS-1200
VIDEO-SYSTEMS-5000
x VOLKER-CRAIG-303
x VOLKER-CRAIG-303A
x VOLKER-CRAIG-404
VISUAL-200
x VISUAL-55
x WYSE-30
x WYSE-50
x WYSE-60
x WYSE-75
x WYSE-85
XEROX-1720
x XTERM
ZENITH-H19
x ZENITH-Z29
ZENTEC-30patterso@hardees.rutgers.edu (Ross Patterson) (04/04/89)
>x IBM-2741
I love it! The terminal that TELNET GO-AHEAD was designed for isn't on
the Official Terminal Names list!
Ross Patterson
Rutgers University
Center for Computer and Information Servicesbarmar@think.COM (Barry Margolin) (04/06/89)
In article <Apr.4.10.17.26.1989.22017@hardees.rutgers.edu> patterso@hardees.rutgers.edu (Ross Patterson) writes: >>x IBM-2741 >I love it! The terminal that TELNET GO-AHEAD was designed for isn't on >the Official Terminal Names list! Read the Host Requirements draft RFC -- GO-AHEAD is gone, too. Since no one is required to support GO-AHEAD any more, it makes sense to punt the associated terminal type. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
wayne@ultra.UUCP (Wayne Hathaway) (04/06/89)
> >x IBM-2741 > I love it! The terminal that TELNET GO-AHEAD was designed for isn't > on the Official Terminal Names list! As someone who was slightly involved with this issue ( 1/2 :-} ), I'd like to argue that the TELNET GO-AHEAD was "designed" for half-duplex HOST operation, not really for a particular terminal (although admittedly the infamous 2741 was the most common at the time). That is, it was the overall IBM philosophy of half-duplex operation with locked terminals that introduced the need to know when to allow/expect input, which is all the GO-AHEAD was for. It made no difference whether the terminals involved were 2741's, 2740's, 3270's ("modern" boob tubes), or even ASR33's -- they were ALL driven with the idea that there was a time for waiting for output and there was a time for typing input, and the HOST was the one who determined which was which. The GO-AHEAD was introduced to try to give the host at least a hint as to how to make this determination (although most implementations did little actual good). Of course, all this has become a moot point now that IBM has joined the rest of the universe with AIX and such. (Right ... Try selling THAT one to the thousands of TSO users sitting at their 3270's right now with that maddening little "X" shining brightly at the bottom!) Wayne Hathaway Ultra Network Technologies domain: wayne@Ultra.COM 101 Daggett Drive Internet: ultra!wayne@Ames.ARC.NASA.GOV San Jose, CA 95134 uucp: ...!ames!ultra!wayne 408-922-0100
gore@eecs.nwu.edu (Jacob Gore) (04/10/89)
Is there any particular reason why we have to enumerate every piece of
computer hardware in the world?
For instance, the domain application wants host type and OS type for the
hosts on which the domain's nameservers run. What on Earth for?
Jacob Gore Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gorehenry@utzoo.uucp (Henry Spencer) (04/10/89)
In article <8904061537.AA00580@lear.ultra.com> wayne@ultra.UUCP (Wayne Hathaway) writes: >... It made no difference >whether the terminals involved were 2741's, 2740's, 3270's ("modern" >boob tubes), or even ASR33's -- they were ALL driven with the idea >that there was a time for waiting for output and there was a time for >typing input, and the HOST was the one who determined which was which. Um, the ASR33, for all its other flaws, at least was full-duplex. It didn't have IBM Terminal Disease. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
amanda@lts.UUCP (Amanda Walker) (04/11/89)
In article <7080013@eecs.nwu.edu>,ntgore@eecs.nwu.edu (Jacob Gore) writes:
Is there any particular reason why we have to enumerate every piece of
computer hardware in the world?
Well, I think the general principle goes something along the lines of:
Since, the world being as it is, it is often necessary or desirable for
two pieces of hardware to be able to use information about each other
in order to communicate. For terminals this is particularly necessary
if any functinality greater than "glass teletype" is desired. Making this
type of information available automatically (such as through a domain
name server, the telnet TERMINAL-TYPE negotiation, Hesiod, etc.) results
in decreased time and increased accuracy over the alternative of having
users supply this information whenever it is needed. In fact, users
may well not have this information readily available, if at all.
For instance, the domain application wants host type and OS type for the
hosts on which the domain's nameservers run. What on Earth for?
I can think of several reasons off-hand. The most practical one is for
identifying special circumstances. For example, the FTP client in our
Macintosh TCP/IP package uses this information to provide extended
functionality (such as directory browsing and file size estimation)
for hosts it "understands." It can make do without it, but taking
advantage of it allows us to move the burden of system-specific
knowledge from the user to the software. Network diagnostic programs
can use this information to improve the intelligibility of their output.
Programs such as mailers can use the well-known-socket information to
predetermine whether or not a given type of service is available on
a particular host.
We don't, of course, *need* to enumerate all of this stuff, but it is
often quite useful...
--
Amanda Walker <amanda@lts.UUCP>
InterCon Systems Corporation
--
"A keyboard ... how quaint!" -- Scotty, Star Trek IV: The Voyage Homewayne@ultra.UUCP (Wayne Hathaway) (04/11/89)
> In article <8904061537.AA00580@lear.ultra.com> wayne@ultra.UUCP (Wayne Hathaway) writes: > >... It made no difference > >whether the terminals involved were 2741's, 2740's, 3270's ("modern" > >boob tubes), or even ASR33's -- they were ALL driven with the idea > >that there was a time for waiting for output and there was a time for > >typing input, and the HOST was the one who determined which was which. > Um, the ASR33, for all its other flaws, at least was full-duplex. It > didn't have IBM Terminal Disease. > -- > Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology > passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu Well, the point I was trying to make was that it didn't MATTER on IBM operating systems whether the terminal was capable of full duplex operation or not, the system ran it as half-duplex with a "locked" keyboard. Since 2741's and the like could physically lock the keyboard, there was no confusion. One system I remember that supported ASR33's simulated the "locked" mode by just treating anything typed while "locked" as a BREAK character. (I think this was a requirement of the box -- 2703? -- used to connect the ASR33 to the mainframe.) Needless to say this was NOT a very nice user interface! Anyway, the only reason I commented earlier was that this seems to me to be another of those situations where a simplistic "their terminals are broken" explanation hides the REAL problem of a completely different user interface philosophy. Now it's UNIX, but back then it was TENEX, and you wouldn't believe the difficulties trying to get otherwise very bright people to even consider the possibility of alternative approaches. Right or wrong, better or worse, that wasn't the issue -- in general the TENEX crowd couldn't even COMPREHEND any alternatives enough to evaluate them. Blaming it on defective hardware provided a very easy out. If I felt that this problem died completely with the demise of TENEX parochialism then I wouldn't have commented. Unfortunately, the names have changed but the tunnel vision remains the same. Wayne Hathaway Ultra Network Technologies domain: wayne@Ultra.COM 101 Daggett Drive Internet: ultra!wayne@Ames.ARC.NASA.GOV San Jose, CA 95134 uucp: ...!ames!ultra!wayne 408-922-0100 PS: Love your quotes, Henry!
rpw3@amdcad.AMD.COM (Rob Warnock) (04/13/89)
By the way, dropping support for go-ahead may not be a disaster, even if
you have some of those "old" terminals. Back in 19-ought-74 (or so), at
Digital Communications Assoc., we made our network processors capable
of doing the reverse -- supporting 2741's as "full-duplex" terminals
on PDP-10's. [Why? Well, there were these customers who had 2741's...]
It may have been sluggish [and by modern sensibilities *ug-lee!*], but
it worked. You could even run character-at-a-time programs like TECO
and DDT on a 2741. [You know, type "1234/" and the contents of location
"1234" come out on the same line.] Yes, we required the 2741 to have the
"reverse break" option, wherein the host can lock your keyboard even if
you haven't typed "return" yet. Conversely, we unlocked the keyboard
whenever the host user process was in TTY input wait. [There was more
to it than that, of course.]
My point is that in a "full-duplex world" those older terminals can
still be supported to a great extent by providing appropriate filters.
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun}!redwood!rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403gore@eecs.nwu.edu (Jacob Gore) (04/18/89)
/ comp.protocols.tcp-ip / amanda@lts.UUCP (Amanda Walker) / Apr 10, 1989 / > For instance, the domain application wants host type and OS type for the > hosts on which the domain's nameservers run. What on Earth for? > > I can think of several reasons off-hand. The most practical one is for > identifying special circumstances. For example, the FTP client in our > Macintosh TCP/IP package uses this information to provide extended > functionality (such as directory browsing and file size estimation) > for hosts it "understands." If you are doing an FTP to foo.bar.edu, how does it help to know that the two name servers for bar.edu are a Timex/Sinclair and an IBM Selectric? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore
amanda@lts.UUCP (Amanda Walker) (05/03/89)
In article <7080014@eecs.nwu.edu>, gore@eecs.nwu.edu (Jacob Gore) writes: >If you are doing an FTP to foo.bar.edu, how does it help to know that the >two name servers for bar.edu are a Timex/Sinclair and an IBM Selectric? > >Jacob Gore Gore@EECS.NWU.Edu >Northwestern Univ., EECS Dept. {oddjob,chinet,att}!nucsrl!gore Sigh. It doesn't. However, it helps a lot to know that foo.bar.edu is running UNIX (for example), so that the FTP client can ask for a long format directory listing, parse it, and find out useful things like file size, whether or not a given file is really a directory, and so on. Since this sort of information is not provided by the FTP spec, it must be determined in a OS-dependent fashion. Since the OS involved cannot usually be determined from the host itself (since most FTP servers do not conform to the RFC by responding to the SYST command...), it's very nice to be able to glean this information from the nameserver. To take another example, it's quite useful for a mail transport program to be able to find out where to send mail destined for zot.bar.edu, even (or especially) if there is no direct path between said mail transport program and zot.bar.edu. Domain servers provide information about the domain and the hosts therein. Addresses are part of this information. Host OS and type information is part it, too. So is mail-handling information. This discussion seems to be approaching ridiculousness... -- Amanda Walker InterCon Systems Corporation amanda@lts.UUCP / lts!amanda@uunet.uu.net