Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!ucbvax!FTP.COM!jbvb From: jbvb@FTP.COM (James B. Van Bokkelen) Newsgroups: comp.protocols.tcp-ip Subject: Re: needs VT220 host, was emulation Message-ID: <9012131533.AA20329@ftp.com> Date: 13 Dec 90 15:33:52 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: jbvb@ftp.com Organization: The Internet Lines: 64 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