PIRARD%vm1.ulg.ac.be@CUNYVM.CUNY.EDU (Andr'e PIRARD) (12/11/90)
On Wed, 19 Sep 90 11:29:05 -0500 James B. Van Bokkelen said: >If it has to replace ours, he needs an IBM PC DOS VT220 emulator with >7-bit and 8-bit support, the ISO Latin character set, keyboard and >display re-mapping and print screen support, built into a Telnet with >a built-in FTP server and multi-session capability. Novell (Excelan) >offers VT220 in their product for the EXOS205, but I don't know its >capabilities. Sun, IBM and 3Com had VT100 last I knew, I don't know >what Beame & Whiteside offers. One could also get a VT220 emulator >from one of the Ascii emulator specialists and use it with an INT 14 >Telnet redirector. I don't recall any INT 14 redirector or VT220 >emulator Telnets that are free... Fine to us, those "foreign" language speakers, James. Now we have the terminal, how can we have the host. Let me explain. To us, computers codes are just as different as EBCDIC is from ASCII. This is because we do have to use an 8-bit code and the "ASCII extension" of the PC and the Macintosh, for example, are not compatible. It needs little reasoning to come to the conclusion that a standard code has to be defined to be used on the communication line, just as ASCII is, that is of course an extension of ASCII. Telnet binary mode, for one, is not enough because it does not enforce computers to use the same exchange code. The same problem occurs for several other application protocols and the rule should be that either a system simply uses that standard code or has to translate its own to standard when exchanging data on communication lines. A 8-bit invertible translation has to be defined for each proprietary code, even if the character set does not match the standard set exactly. The programming key is to use the standard code in memory and provide a translation at the device level (keyboard, screen, file), optional by possibly being null. It needs very little indeed to fit the 4th wheel to the great TCP/IP car. Unhappily, most of the TCP/IP protocols do not define that 8-bit code (X is the counter example, however) worse have a tendency to restrict to 7-bit. Everyone, including X, seems to agree that this code is ISO 8859/1 (for Latin group 1 languages, others would use other versions untranslatable to each other, except for the common ASCII lower half). But I find this agreement too silent. Which 8-bit code to use seems to be left to anybody's whim. Unix moves to 8-bit, but which mainly depends on the character code of the devices (terminals and printers mainly). I have heard of installations using Unix with PC code page 850 (exactly the same character set as ISO 8859/1, but with different code points), even IBM saying that it's the code of AIX. Thus, VT220 and Macintoshes cannot be used. I've heard that SunOS 4.1 starts using ISO 8859/1 (is that correct?). The higher VT models emulation does just that: translate ISO 8859 to local. The specific question is: how does this integrate with Telnet and how does a Unix host have to be setup to use 8859? Should a 7-bit path be used with SO/SI shifting for both screen and keyboard (seems a pain, especially to recover from entering the wrong mode), or will the emulator request binary mode and Unix understand? Unix applications (of those being able to process 8 bits) should work unaware of terminal setup requirements. How will the VT terminal enter ISO 8859/1 mode (or shouldn't the emulator best be locally configurable to use ISO 8859/1 without any system or application action?). In a word, how use ISO 8859/1 as simply as ASCII? Sorry I am not a Unix man. Please excuse my difficulties to use this standard language on communication lines, and believe I'd really like to be able to use my own to send correct mail to French talking people, including those in so far away Quebec :-) Andr'e PIRARD SEGI, Univ. de Li`ege B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) pirard@vm1.ulg.ac.be or PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU
jbvb@FTP.COM (James B. Van Bokkelen) (12/13/90)
The specific question is: how does this integrate with Telnet and how does
a Unix host have to be setup to use 8859?
We've been doing this for a while now, and not nearly enough people have
picked up on it. Maybe this will help the process...
What we did was designed to interoperate with DEC VMS systems, since they
were the first widely-available Ascii-based hosts to support both useful
8-bit data streams and ISO-Latin. PC/TCP's VT220 Telnet does the following:
a. Offers a "DEC-VT220" terminal type option value (per RFC 1091)
b. Accept VT220 escape sequences to switch between "VT220 7-bit" and "VT220
8-bit" modes. When entering 8-bit, we initiate negotiations for the Telnet
"Binary" option (we also initiate it on user request).
c. If "Binary" is accepted, we switch to sending 8-bit CSI sequences instead
of the 7-bit versions. If "Binary" is refused, we continue to send the
two character 7-bit CSI, since the single-character 8-bit version would
probably get destroyed by a masking operation at the server.
d. Accept standard 7-bit or 8-bit CSI values regardless, including the
sequences which display the VT220's "ISO Latin" characters.
It's complicated, there are pitfalls (some applications won't accept 7-bit
CSIs if they have sent the "switch to 8-bit VT220 mode" command, but we
can't send 8-bit because the "Binary" option was refused - solution is to
fix the host's Telnet server), but in general it works for those who can
be satisfied by ISO Latin. It is interoperable to the extent that the
8859 alphabets can be (as long as the community uses the same subset of
it). It is a general solution because it is based on the terminal type,
and hosts/applications understanding that VT220s can switch to 8-bit mode.
Unix doesn't understand 8-bit terminals in general, and normally runs the
VT220 in 7-bit mode, so it needs quite a bit of work on the host side to
get off the ground.
A possible first major improvement is to propagate 8-bit-awareness (most
conveniently in the guise of a VT220) to the Unix of your choice. If an
application works with a direct-attached VT220 in 8-bit mode (set via the
'init-string' in termcap or whatever), it would only need a cooperative
Telnet server to work over the net - this requires careful consideration of
which of the available terminal modes would most usefully map to "Binary"
('raw' doesn't cut it).
A more far-reaching solution is to switch to 16-bit or 32-bit characters.
Of course, the theory is that this will make the whole world happy (I may
not be able to pronounce some of the characters I see displayed, but I can
forward the message intact to someone who does), but it isn't anywhere
near general availability yet. If this is done as DBCS or ISO-646
successor terminals become available, it can just continue to use the
Telnet Terminal Type and Binary options, and will remain backwards
compatible. I would discourage anyone setting out to write a "Telnet DBCS
(or whatever) data stream option" RFC, because it bypasses the Terminal
Type and loses backwards compatibility.
Getting anywhere with any of the available Unices will probably require
either source code or vendor cooperation. If your Unix vendor is interested,
they can talk to/test against us, but so far I haven't been approached
by any willing to admit that there was anything to learn from VMS, or who
felt that improving support for a DEC terminal was in their interest...
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901