Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!GYRE.UMD.EDU!chris From: chris@GYRE.UMD.EDU (Chris Torek) Newsgroups: comp.protocols.tcp-ip Subject: Re: telnet CR processing, bridge comm servers and TWG telnet Message-ID: <8708111749.AA05938@gyre.umd.edu> Date: Tue, 11-Aug-87 13:49:42 EDT Article-I.D.: gyre.8708111749.AA05938 Posted: Tue Aug 11 13:49:42 1987 Date-Received: Thu, 13-Aug-87 04:41:41 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 74 Why are things always more complicated than they need to be? Let us see what happens if we break this down carefully. First, telnet seems to assume that there is a User on a Terminal (possibly a Printing Terminal) who is connected, either directly or via modem, to a Host. This Host is connected to another Host via the Internet. Let us name these hosts to avoid confusion: the first will be Tachost, the second Usefulhost. Now as to cases: Usefulhost can try to print a line to User. To do so, it sends characters to Tachost, and then it sends an End Of Line. What is this End Of Line? It seems fairly well agreed that it is a CR plus an LF. To print this, should Usefulhost send or just ? Either should work, but the latter should be preferred. Tachost must arrange for either to produce the appropriate printhead or cursor motion. Usefulhost can also try to do fancy printhead motion (if our User is on a Printing Terminal), namely, `go back to the beginning of the line and get ready to overstrike' or `go down one line'; for these it should send and respectively. It is obvious that will move the printhead to the beginning of a new line, though possibly inefficiently, which is why we say is preferred. Now on the other hand, User may be trying to send a line to Usefulhost. Here the situation is murkier. User pushes keys for characters; upon these we agree: they are just plain ASCII. (Let us not consider binary EBCDIC, please!) But then User pushes a key marked ENTER. Or is it marked RETURN? Maybe LINE FEED? Or perhaps even NEWLINE. Just what key *is* this, anyway? I cannot speak for everyone, but all *my* terminals have a great big key marked RETURN. It sends . They also have an ordinary sized key marked LINE FEED, and it sends . But apparently there is at least one Tachost that has different terminals, with keys marked ENTER that send . The clear, obvious solution is to have Tachost send when a User types RETURN, when a User types LINE FEED, and when a user pushes an ENTER key that sends . Terminals with just one big ENTER key thus cannot send . Well, that is natural since they have no key for it. As long as the terminal has separate keys, though, it should be Tachost's job to send to Usefulhost exactly that key which was typed. Alas, telnet does not use the clear, obvious solution. It imposes on a User the very same protocol used for making a Terminal or Printer work. This is odd, for Users are not at all like Terminals and Printers, but we are stuck with it. At least it is symmetric---or is it? If Tachost can easily tell which key User typed, *I* say it should send that very key to Usefulhost. So (since we have this extra protocol in the way) let us define that Tachost is to send either or (it should not matter which) when User types RETURN, and when User types LINE FEED. If User types ENTER and Tachost cannot tell which was meant, let it again send either or . Note that in the Tachost->Usefulhost path, means RETURN, while on the Usefulhost->Tachost path, means NEW LINE. This is--- alas!---not symmetric, but is clearly necessary since many Tachosts already send when a User hits RETURN. Note also that is useless, since it means the same thing as ; nonetheless, it must be retained for compatibility, since other Tachosts already send when a User hits RETURN. Summary: End host should send for NEW LINE, for cursor-to-beginning-of-line, for cursor-down-without-return. Intermediate host should send or for RETURN, for LINE FEED. Neither host should ever send without immediately sending either or . Chris