Re: Telnet, <CR><LF>, etc.

Hugh LaMaster (pioneer!
6 Aug 87 21:49:24 GMT

Stephen Casner writes:

>You are correct, the Telnet spec does NOT make it clear whether the
>client program should send CR-LF or CR-NUL when the user hits the
>"return" key. The discussion is clear for characters flowing in the

>The following sentence is the one that I think causes trouble; you have
>undoubtedly read it before, but I'll quote it here for discussion:

    Therefore, the sequence "CR LF" must be treated as a single "new
    line" character and used whenever their combined action is intended;
    the sequence "CR NUL" must be used where a carriage return alone is
    actually desired; and the CR character must be avoided in other

>show that CR-LF "must be ... used". Those who believe that carriage
>return alone is desired, because on many (most?) terminals the "return"
>key generates a single CR character, might quote the second part of the
>sentence to show that CR-NUL "must be used".

I agree with ALMOST all of this. Now, I have just read the spec carefully
again myself, and it seemed clear to me that CR-NUL was intended originally to
be used on output for NVT printer overstrikes on the same line. It isn't
clear what, if anything, it means on input. However, through long use
(misuse?), CR-NUL should, it seems, ALSO be INTERPRETED as a newline on input.
Does anyone know what a TAC sends when it gets a CR from a keyboard?

>NEITHER group can "prove" its case from the spec, but this is not a
>legal contest. As Mark Crispin says, "we all have a shared interest in
>maximizing interoperability".

EXACTLY. Since interoperability is the PURPOSE, implementors have an
OBLIGATION to follow the robustness principle, even if it inconveniences
Un*x raw mode I/O.

>I believe the Telnet spec should say exactly which of these two choices
>should be used, just to avoid the present confusion of interpretation.
>In any case, by the "robustness principle", EITHER sequence (CR-LF or
>CR-NUL) should be accepted by the Telnet server to mean that the
>"return" / "enter" key was pushed because we know there are some systems
>that send one and some systems that send the other.

Yes, the spec should have defined ONE sequence exactly for what user telnet
should send to mean "newline". However, the spec does state very clearly that
CR-LF MUST (read it again) be INTERPRETED as a newline. Therefore, user
telnet MUST SEND CR-LF unless it has negotiated or otherwise knows that
something else is preferable. Versions of BSD telnet which don't follow this
are not consistent with the standard, pure and simple. In my opinion (let us
not get personal).

>So, for the moment at least, my complaint was and is not that the 4.3BSD
>telnet client sends CR-NUL but only about the 4.3BSD telnetd maps CR-LF
>to '\n' instead of '\r'.

I do not follow this. 4.3BSD telnetd MUST interpret CR-LF as a "newline"
(which means that a user PROCESS must receive \n (or \n\0 depending on how you
look at the \0) - whatever happens in between is the implementors problem) and
MUST SEND CR-LF as a "newline" to a (non-Unix) host. Obviously, there is
disagreement about this, but it seems very clear to me. Read the spec again.
The convention used to handle the raw-mode case must be consistent with this.
Some discussion seems to point to the need for programs in raw mode receiving
a \r or \r\0. I am not sure I follow this, but if the cooked mode case is
clear, then the raw mode case should make more sense.

(discussion about the difference between terminals and what a process receives
internally deleted - the discussion is correct: there is NO necessary
connection between the characters that telnet NVT uses and what Unix uses
internally, although 99% of the time they are the same).

  Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center ames!pioneer!lamaster
  Moffett Field, CA 94035 ARPA
  Phone: (415)694-6117 ARPA

                 "IBM will have it soon"

(Disclaimer: "All opinions solely the author's responsibility")

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