Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!auspex!guy From: guy@auspex.UUCP (Guy Harris) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet v.s. rlogin Message-ID: <358@auspex.UUCP> Date: 29 Oct 88 06:40:59 GMT Article-I.D.: auspex.358 References: <8810252013.AA07602@radc-lonex.arpa> <1351@unisoft.UUCP> Reply-To: guy@auspex.UUCP (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 36 >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....