Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!FTP.COM!jbvb
From: jbvb@FTP.COM ("James B. Van Bokkelen")
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: NCSA - Telnet with ansi and extended keyboard support ?
Message-ID: <9101161416.AA23369@ftp.com>
Date: 16 Jan 91 14:16:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: jbvb@ftp.com
Organization: The Internet
Lines: 34

Passing 8 bits directly to the PC's display sounded like a bad idea to us,
and we didn't do it.  There are two problems:  First, there are a number of
old Unix implementations out there that cheerfully pass parity to Telnet
during part of the login process.  Second, one must face the issue of just
what do particular values >127 *mean*.

Present usage of Telnet for full-screen applications is founded on the
concept of terminal type, originally developed to allow use of different
kinds of terminal on different direct-connected lines on a single system.
Modern Telnet clients pass terminal types to the host automatically, and
applications can the use host services like termcap, terminfo and SMG to
achieve independence of particular terminal models.  However, these services
don't address the problem of "how do I translate from a hardware-independent
value indicating 'a-umlaut' to a display code for terminal X" (partly because
there is as yet no universal code table that has separate values for all
the glyphs a multi-lingual document might use - two are under development,
but neither is finished).  Thus, all existing extended-ascii applications
are written for specific display devices.

The standard US PC display's code table is somewhat of a bastard, not
conforming to any of the existing standards, and we felt that offering an
incentive to develop applications to a non-standard was wrong.  Instead, we
chose to follow DEC's lead in the VT220, whose most widely-sold model uses
the standard encoding for the ISO 8859-1 Latin alphabet.  We also allow
users requiring other 8859 variants, and equipped with appropriate display
controllers, to configure other mappings, but that's icing on the cake.

Instead of just passing 8 bits, I suggest that NCSA implement a mapping (it
only takes one char[128] array) following 8859-1. This will contribute to the
overall interoperability of a significant fraction of current extended-ascii
applications.

James B. VanBokkelen		26 Princess St., Wakefield, MA  01880
FTP Software Inc.		voice: (617) 246-0900  fax: (617) 246-0901