Re: telnet v.s. rlogin


Guy Harris (auspex!guy@uunet.uu.net)
29 Oct 88 06:40:59 GMT


>One of the disturbing features of 4.3 telnet daemon implementation is that
>it assumes that the remote telnet client knows about TTYPE negotiation
>at the beginning of the session establishment.

Another problem with TTYPE, although less serious, is that, while RFC930
says

   The terminal type information is an NVT ASCII string. Within this
   string, upper and lower case are considered equivalent. The complete
   list of valid terminal type names can be found in the latest
   "Assigned Numbers" RFC.

and RFC1010, "Assigned Numbers", lists (for example), under Terminal
Type Names, "DEC-VT100". However, all that the 4.3BSD "telnet" program
does is take the UNIX environment variable TERM, upper-casify it, and
use the result. Unfortunately, UNIX doesn't tend to use the RFC1010
names; for example, the names it uses for VT100s are "vt100",
"vt100-am", and "vt100am", but not "dec-vt100" or its upper-case equivalent.

This works fine and dandy when one UNIX system talks to another, but if
somebody else out there implements precisely the recommendations of
RFC930 and RFC1010 their implementation may not recognize "vt100" as a
VT-100.

I don't know if this is a serious problem (as I said, it works fine and
dandy for UNIX), or if it is what the correct fix is (the list of
terminals that UNIX, in some sense, knows about - e.g., the ones in the
"termcap" or "terminfo" data base - is much larger thatn the list of
terminals in RFC1010; for instance, I don't see an entry in that section
for "sun", but I'd be pretty cheesed off if, when I TELNETted to another
UNIX system from a window on my machine, it didn't understand that it
should set the TERM environment variable to "sun"). Perhaps it should
map to the "canonical" name if one exists, pass the non-canonical name
across the net otherwise (unless it conflicts with a canonical name for
some other terminal, in which case you have to do something else), and
hope for the best....



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:57 GMT