home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / protocol / kostya-locking-shift.reply < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
  2. To: kvin@ccic.icsti.msk.su (Konstantin Vinogradov)
  3. Cc: cmg@watsun.cc.columbia.edu, jrd@watsun.cc.columbia.edu,
  4.     pepmnt@cfaamp.harvard.edu, keibun@kek.jp, Klensin@INFOODS.MIT.EDU,
  5.     MURAKAMI@NTT-20.NTT.JP, PIRARD@vm1.ulg.ac.be, pplaceway@bbn.com,
  6.     S00100@DBNRHRZ1.BITNET, TERRY@SPCVXA.BITNET
  7. Subject: Re: Kermit Locking Shift Proposal
  8. bcc: fdc
  9. In-Reply-To: Your message of Thu, 16 May 91 20:24:17 +0300 (MSD)
  10.  
  11. > Dear Christine and Frank,
  12. > 
  13. > > The file sender should not set this capability bit if its PARITY variable
  14. > > is not NONE.
  15. > 
  16. > Does it mean that the Sender should set capability bit only if its PARITY
  17. > variable is NONE ? I can't believe this and assume the first "not" (or
  18. > the second one) NOT TRUE.
  19. >
  20. Thank you for noticing the typographical error!
  21.  
  22. > It seems there is no way to initiate Locking Shift by the Receiver in case
  23. > sender's parity is NONE. I guess it's possible to set sender's LS bit if
  24. > parity is NONE, but receiver should not set this bit if its parity is NONE
  25. > and sender's QBIN equal "Y". Does it make sense ?
  26. > 
  27. You're right, Konstantin.  Locking shifts (or combined shifts) should be
  28. negotiated and used in exactly the same way as single shifts.  So the file
  29. receiver should be able to initiate locking shifts just as it can initiate
  30. single shifts.  However, we should not tie locking shift negotiation to
  31. single-shift negotiation because we want them to be independent.
  32.  
  33. So suppose we modify the negotiation phase to be like this:
  34.  
  35. Any Kermit program that implements locking-shift protocol will always set the
  36. locking-shift capability bit.  This indicates that it CAN do locking shifts,
  37. but not that it WILL do them.
  38.  
  39. In addition, a new field is added to the initialization string: PARITY.  It
  40. will be the fourth byte after the capabilities field (CAPAS+4).  The values
  41. can be:
  42.  
  43.     E  Even parity (7 bit data)
  44.     O  Odd parity (7 bit data)
  45.     M  Mark parity (7 bit data)
  46.     S  Space parity (7 bit data)
  47.     P  Any kind of parity other than NONE (7 bit data)
  48.     N  NONE, no parity (8-bit data)
  49.  
  50. So the conditions for locking shifts to be used are that both Kermit programs
  51. set the locking-shift capability bit, AND one or both Kermits specifies a
  52. PARITY value other than N.  The value of the PARITY negotiation field comes
  53. from Kermit's PARITY variable.
  54.  
  55. > LS FORCED mode: I have two remarks here.  Assume any text file will be
  56. > received and recorded with sender's ISO-based (8859/? + 2022)
  57. > transfer_character_set in case receiver does not support LS.  First of all,
  58. > this is unsuitable if receiver has been able to accept this
  59. > transfer_character_set and to translate it accordingly.  This is unwanted
  60. > situation.
  61. >
  62. An excellent point!  But the use of locking shifts should not prevent
  63. character set translation, and the proposal did not say it should.  Let's look
  64. at the possibilities when the sender has LOCKING-SHIFT FORCED and has
  65. announced the transfer character set in the Attribute packet, and the receiver
  66. supports character-set translation, but does not support LS (or LS protocol
  67. has not been negotiated):
  68.  
  69. 1. Receiver translates the transfer character set into an 8-bit file character
  70.    set whose first 128 characters are ASCII, such as an IBM code page, KOI-8,
  71.    the Apple or NeXT character set, etc.  In this case, the desired effect is
  72.    achieved automatically.
  73.  
  74. 2. Receiver translates the transfer character set into a 7-bit file character
  75.    set such as an ISO 646 NRC or Short KOI.  In this case the result is
  76.    garbage.  Locking shifts should not be used here.  For the languages
  77.    covered by ISO 646 NRCs, single shifts are more efficient anyway.
  78.  
  79. > John already mentioned the second problem.  Well, receiver couldn't accept
  80. > the transfer_character_set.  In this case we have got a text file with
  81. > SI/SO included.  Even if it is ISO-based it does not mean that local
  82. > equipment can process it.  Which kind of 8859 arrived?  How should it be
  83. > translated?  If you can't answer you can't use such file.  It's not enough
  84. > to convert it to 8-bit data file or output to display or printer.  You may
  85. > get nothing.
  86. > 
  87. This situation is no worse with locking shifts than without them.  If the file
  88. had been transferred with single shifts only, it would still contain 8-bit
  89. characters whose meanings were unknown.  In either case -- 8-bit values or
  90. SO/SI characters in the file -- a postprocessing program could translate the
  91. character set into the desired one.
  92.  
  93. > As to my experience, the only character set which is used here in the
  94. > Soviet Union in such manner is KOI/7, i.e. old_KOI/8 in 7-bit environment.
  95. > Really a variety of displays, operating systems, online services, etc. was
  96. > designed to use SI/SO technique.  My LAN station, for example, uses it.
  97. > But most of them are obsolete and I never heard that somebody decided to
  98. > apply SI/SO method to store or output currently used codes (including
  99. > new_KOI/8 = ISO8859/5).
  100. > 
  101. Now they can.  Several useful examples have already been listed.  With
  102. imbedded SO/SI in file data, people can read and print international
  103. characters in environments where this could never be done before.
  104.  
  105.  
  106.