From: Frank da Cruz To: kvin@ccic.icsti.msk.su (Konstantin Vinogradov) Cc: cmg@watsun.cc.columbia.edu, jrd@watsun.cc.columbia.edu, pepmnt@cfaamp.harvard.edu, keibun@kek.jp, Klensin@INFOODS.MIT.EDU, MURAKAMI@NTT-20.NTT.JP, PIRARD@vm1.ulg.ac.be, pplaceway@bbn.com, S00100@DBNRHRZ1.BITNET, TERRY@SPCVXA.BITNET Subject: Re: Kermit Locking Shift Proposal bcc: fdc In-Reply-To: Your message of Thu, 16 May 91 20:24:17 +0300 (MSD) > Dear Christine and Frank, > > > The file sender should not set this capability bit if its PARITY variable > > is not NONE. > > Does it mean that the Sender should set capability bit only if its PARITY > variable is NONE ? I can't believe this and assume the first "not" (or > the second one) NOT TRUE. > Thank you for noticing the typographical error! > It seems there is no way to initiate Locking Shift by the Receiver in case > sender's parity is NONE. I guess it's possible to set sender's LS bit if > parity is NONE, but receiver should not set this bit if its parity is NONE > and sender's QBIN equal "Y". Does it make sense ? > You're right, Konstantin. Locking shifts (or combined shifts) should be negotiated and used in exactly the same way as single shifts. So the file receiver should be able to initiate locking shifts just as it can initiate single shifts. However, we should not tie locking shift negotiation to single-shift negotiation because we want them to be independent. So suppose we modify the negotiation phase to be like this: Any Kermit program that implements locking-shift protocol will always set the locking-shift capability bit. This indicates that it CAN do locking shifts, but not that it WILL do them. In addition, a new field is added to the initialization string: PARITY. It will be the fourth byte after the capabilities field (CAPAS+4). The values can be: E Even parity (7 bit data) O Odd parity (7 bit data) M Mark parity (7 bit data) S Space parity (7 bit data) P Any kind of parity other than NONE (7 bit data) N NONE, no parity (8-bit data) So the conditions for locking shifts to be used are that both Kermit programs set the locking-shift capability bit, AND one or both Kermits specifies a PARITY value other than N. The value of the PARITY negotiation field comes from Kermit's PARITY variable. > LS FORCED mode: I have two remarks here. Assume any text file will be > received and recorded with sender's ISO-based (8859/? + 2022) > transfer_character_set in case receiver does not support LS. First of all, > this is unsuitable if receiver has been able to accept this > transfer_character_set and to translate it accordingly. This is unwanted > situation. > An excellent point! But the use of locking shifts should not prevent character set translation, and the proposal did not say it should. Let's look at the possibilities when the sender has LOCKING-SHIFT FORCED and has announced the transfer character set in the Attribute packet, and the receiver supports character-set translation, but does not support LS (or LS protocol has not been negotiated): 1. Receiver translates the transfer character set into an 8-bit file character set whose first 128 characters are ASCII, such as an IBM code page, KOI-8, the Apple or NeXT character set, etc. In this case, the desired effect is achieved automatically. 2. Receiver translates the transfer character set into a 7-bit file character set such as an ISO 646 NRC or Short KOI. In this case the result is garbage. Locking shifts should not be used here. For the languages covered by ISO 646 NRCs, single shifts are more efficient anyway. > John already mentioned the second problem. Well, receiver couldn't accept > the transfer_character_set. In this case we have got a text file with > SI/SO included. Even if it is ISO-based it does not mean that local > equipment can process it. Which kind of 8859 arrived? How should it be > translated? If you can't answer you can't use such file. It's not enough > to convert it to 8-bit data file or output to display or printer. You may > get nothing. > This situation is no worse with locking shifts than without them. If the file had been transferred with single shifts only, it would still contain 8-bit characters whose meanings were unknown. In either case -- 8-bit values or SO/SI characters in the file -- a postprocessing program could translate the character set into the desired one. > As to my experience, the only character set which is used here in the > Soviet Union in such manner is KOI/7, i.e. old_KOI/8 in 7-bit environment. > Really a variety of displays, operating systems, online services, etc. was > designed to use SI/SO technique. My LAN station, for example, uses it. > But most of them are obsolete and I never heard that somebody decided to > apply SI/SO method to store or output currently used codes (including > new_KOI/8 = ISO8859/5). > Now they can. Several useful examples have already been listed. With imbedded SO/SI in file data, people can read and print international characters in environments where this could never be done before.