[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#61792: marked as done (telnet: Can't type non-ascii chars.)



On Tue, Apr 11, 2000 at 02:14:31PM +0200, Richard Braakman wrote:
> 
> That's in section 3.2.7 of RFC 1123 :-)

And I stand corrected again :)

>          When the Binary option has been successfully negotiated,
>          arbitrary 8-bit characters are allowed.  However, the data
>          stream MUST still be scanned for IAC characters, any embedded
>          Telnet commands MUST be obeyed, and data bytes equal to IAC
>          MUST be doubled.  Other character processing (e.g., replacing
>          CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
>          there is no end-of-line convention (see Section 3.3.1) in
>          binary mode.
> 
> I'm guessing that one or both sides is attempting to abuse the BINARY
> mode as an "8-bit terminal" mode.  Section 3.2.5 discusses that.  
> In particular, it sort-of blesses the use of 8-bit characters in
> the normal terminal mode.

Well our side seems to be correct, i.e., it's sending a lone \r when the
user presses enter and expects the remote side to send back \r\n if they
want a new line + carriage return.

This is backed up by the fact that in the problematic case of RH and Solaris,
the remote side seems to be sending back just \n, or that it doesn't respond
to \r but does to \n.

> Is our side well-behaved, though?

Seems to be, but if anyone can prove otherwise, I'd love to hear from you.
-- 
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Reply to: