jam@RADC-LONEX.ARPA (10/26/88)
>henry@zoo.toronto.edu writes: > >One unfortunate problem is that Berkeley rlogin is definitely a better >implementation than Berkeley telnet. If you compare sources, it's fairly >obvious that rlogind is probably derived from telnetd, but various fixes >and improvements in rlogind have not found their way back into telnetd. >At least, not in the Sun sources that we have (VAXen are a vanishing >breed around here and I don't have any convenient way to check out the >current Berkeley sources). The current Berkeley sources aren't that much different, though a fuller implementation of the telnet features had been added with 4.3. HOWEVER, the rlogin and telnet protocols differ in one major aspect (along with a few minor ones...). The design of telnet implies that data is always sent in segments with a line terminator. This is good with hardware like IBM, but not good at all if you want to run software that peeks at exactly what the keyboard is sending. Rlogin is much simpler in nature, and just passes whatever is typed at the keyboard. You press <CR>, the host software gets <CR>. Telnet would translate that to an end-of-line sequence, which is open to interpertation on the other end. Almost a year ago there was discussion of adding a mode to telnet that would handle a terminal like rlogin. Sort of a RAW data mode without the stipulations that telnet places on that mode. This never came about. Perhaps more people just took to using rlogin? Joel A. Mussman jam@radc-lonex.arpa
hedrick@athos.rutgers.edu (Charles Hedrick) (10/27/88)
> The design of telnet implies that data is > always sent in segments with a line terminator. I presume you're talking about go ahead. That is almost never used. When you're talking to a full-duplex host you negotiate it off. Except for Braden's MVS implementation, even software for IBM hosts doesn't do go aheads. This option appears to be defunct.
bae@unisoft.UUCP (Hwa Jin Bae) (10/27/88)
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. I ahd a case where our version of telnet client would talk to all other systems but 4.3 based telnetd. 4.3 telnetd will hang there waiting for the DO TTYPE command. This also makes it harder for UUCP clients that try to use telnet connection to do UUCP over network; unless UUCP client connecting to the 4.3 telnetd WKP sends WONT DO TTYPE message initially, it will hang forever waiting. /hjb -- ----------- "I am no Jack Kennedy." ------------------------------ Hwa Jin Bae bae@tis.llnl.gov (Internet) UniSoft bae@unisoft.UniSoft (smail uucp) Emeryville, CA ...!uunet!unisoft!bae (plain uucp)
jam@radc-lonex.arpa (10/28/88)
>> The design of telnet implies that data is >> always sent in segments with a line terminator. > >I presume you're talking about go ahead. That is almost never used. >When you're talking to a full-duplex host you negotiate it off. >Except for Braden's MVS implementation, even software for IBM hosts >doesn't do go aheads. This option appears to be defunct. > No (Gee, that sounds rather harsh, doesn't it?) I'm not. And this is right, GA (goahead) does seem to be defunct. Telnet still has idea that stuff should be sent on a line by line basis. This is almost never the case, but telnet still pretty much requires a line terminator sequence of <CR><LF> which is usually inserted wherever the user pressed the return key. This is normally translated to whatever the host system requires as a line terminator (on UNIX this becomes <LF>). The ability exists to send a <CR> exists by sending <CR><NUL>. RFC1053 proposes the addition of a negoiation between the host and remote to send <CR><LF> or <CR><NUL> when the user presses the return key. This would allow the host computer to decide what it wanted, line terminators or just whatever the user typed, without going into BINARY mode (which has some other side effects). Merton Crockett, John Ada, and I orignally opened that can of worms a year ago. It was nice to see it added to that RFC. But it was just proposed, and I do not know if it was ever 'offically' adopted. But as far as I know, BSD4.3 UNIX does not support that negoiation. I'm not sure if other systems do. Does anyone know? Joel
guy@auspex.UUCP (Guy Harris) (10/29/88)
>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....
Ata@RADC-MULTICS.ARPA ("John G. Ata") (11/01/88)
From: hedrick at ARAMIS.RUTGERS.EDU (Charles Hedrick)
systems actually make this distinction. (Many systems represent end
of line in files in different ways, but that's not the issue. The
issue is whether what comes from the terminal when the user wants to
generate an end of line is CR.)
going to be treated the same, and it is hard to see why the telnet
Actually, that's a little simplistic since the definition of EOL, while
in the TELNET spec, is actually part of the Network Virtual Terminal
(NVT) definition. Note that NVT is not only used in TELNET but in other
protocols as well such as FTP where the EOL character that is used
inside a file is very important for the correct transfer of files between
heterogeneous file systems.
John G. Ata
slevy@UC.MSC.UMN.EDU ("Stuart Levy") (11/01/88)
As far as I know, no one has implemented RFC 1053 to date, not even me. *If* enough functionality comes to be added to IDEA 16, it may be a moot point. The CR-NUL vs. CR-LF problem is dealt with in the pending Host Requirements RFC by specifying that hosts should be prepared to accept either. That seems adequate, doesn't it? Stuart Levy, slevy@uc.msc.umn.edu