home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / iso8859.txt < prev    next >
Text File  |  2020-01-01  |  544KB  |  10,335 lines
  1. 14-Mar-88 03:18:32-EST,1904;000000000001
  2. Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
  3. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 14 Mar 88 03:18:18-EST
  4. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 14 Mar 88 03:17:59 EST
  5. Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  6.  7381; Mon, 14 Mar 88 03:17:58 EST
  7. Received: by BLIULG11 (Mailer X1.25) id 7697; Mon, 14 Mar 88 09:15:55 +0100
  8. Date:         Mon, 14 Mar 1988 08:45:21 +0100
  9. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  10. Subject:      ASCII, ISO and which EBCDIC?
  11. To:           Info-IBMPC Digest c/o Gregory Hicks COMFLEACTS
  12.  <HICKS@WALKER-EMH.ARPA>,
  13.               IBM-KERMIT@CU20B.COLUMBIA.EDU,
  14.               Protocol Converter list <IBM7171@DEARN>,
  15.               LINKFAIL@FRULM11,
  16.               Columbia University Center for Computing Activities
  17.  <INFO-KERMIT@CU20B.COLUMBIA.EDU>
  18.  
  19. We, ASCII or EBCDIC network users must pay particular attention to character
  20. codes standards, now extending to international. Even sites not interested in
  21. in international characters will sooner or later hit the problem because,
  22. albeit the situation is straight in the ASCII world with an ISO standard,
  23. it is far from that for EBCDIC users faced to a choice of several codes whose
  24. differences lies on a few codes, strangely enough not international.
  25.  
  26. The subject is discussed on a mailing list set up by Edwin Hart. Joining with:
  27.  
  28.   TELL LISTSERV AT JHUVM SUB ISO8859 user-name
  29.  
  30. Or sending a note on BITNET to: LISTSERV AT JHUVM
  31. Containing:                     SUB ISO8859 user-name
  32.  
  33. can help the community agree on a viable single code or at least help each
  34. site in finding its most appropriate one and save everybody's time and money.
  35.  
  36. I'll soon post a summary of the problem to that list.
  37.  
  38. Please forward this note to anybody interested.
  39. 22-Mar-88 13:31:54-EST,21373;000000000001
  40. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  41. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 22 Mar 88 13:31:43-EST
  42. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 22 Mar 88 13:32:04 EDT
  43. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  44.  0746; Tue, 22 Mar 88 13:32:01 EDT
  45. Received: by BITNIC (Mailer X1.24) id 0743; Tue, 22 Mar 88 13:21:56 EDT
  46. Date:         Tue, 15 Mar 88 11:17:07 EST
  47. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  48.               <ISO8859@JHUVM>
  49. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  50.               <ISO8859@JHUVM>
  51. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  52. Subject:      Some Important Comments from Howard Gilbert at Yale University
  53. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  54.  
  55. Enclosed are some comments Howard Gilbert wrote after the SHARE 69 meeting held
  56. in August, 1987.  It is a good summary.  Unless otherwise stated, "EBCDIC"
  57. means "U.S./Canada English EBCDIC".
  58.  
  59. IBM is very interested in the issues surrounding ASCII, EBCDIC characters sets
  60. --particularly as they relate to National Character Set Issues (See the
  61. SHARE European Association (SEAS) "White Paper on national character,
  62. language and keyboard problems", September, 1985) and the System Application
  63. Architecture.
  64.  
  65. The Michigan Terminal System (MTS) community has implemented an ISO 8859-1 to
  66. EBCDIC Code Page 37, Version 1 conversion already.  (Brian Eliot
  67.  
  68. IBM also is trying to decide between two code pages to use as a single
  69. EBCDIC for ISO Latin Alphabet number 1:  Code Page 37, version 1
  70. (which is data processing oriented) and Code Page 500, version 1 (which is
  71. word processing oriented).
  72.  
  73. Ed Hart
  74.  
  75.  
  76. Date:         Thu, 03 Sep 87 11:45:39 EST
  77. From:         Howard Gilbert <GILBERT@YALEVM>
  78. To:           HART@APLVM
  79.  
  80. I think that what we learned at SHARE is important to a lot of people.
  81. Besides our local users, it should be directed to:
  82.  
  83.     BITNET technical reps (for ASCII BITNET nodes)
  84.     NOTIS groups (library automation)
  85.     7171  protocol converter list
  86.  
  87. Here is a first draft of the kind of thing I am thinking of sending out:
  88.  
  89.  
  90.     I attended the meetings of the ASCII-EBCDIC Translate Table
  91. committee at SHARE 69 (Chicago) Aug. 23-28.  As someone who has
  92. struggled with this question for 15 years, I was stunned by the
  93. amount of progress which has been made almost overnight.  There
  94. is no solution which will be satisfactory to everyone, but a
  95. solution is now visible and requires only the willingness to
  96. adopt it.  Because of the problem, I will discuss all
  97. characters by name or code value and not attempt to
  98. print them.  I will try to make the presentation as short as
  99. possible while making it complete.
  100.  
  101.     HISTORY: ASCII was standardized after EBCDIC.  With no
  102. national standard in place, and requirements for BCD
  103. compatibility, IBM extemded its 6 bit character set
  104. BCD to an 8 bit code by moving bits rather than translating with
  105. a table.  Both standards made, what is in hindsight, some regrettable
  106. mistakes.  The ASCII committee placed too much emphasis on the
  107. TTY 33 which had no lowercase letters and lacked braces and
  108. vertical bar.  The choice of EBCDIC printable characters was
  109. influenced by the number of characters which could be placed on a
  110. Selectric typewriter ball.
  111.  
  112.     The ANS committee (not IBM) recommended that ASCII
  113. exclamation point be regarded as EBCDIC vertical bar and that
  114. ASCII Circumflex be treated as EBCDIC not.  These were "stylistic
  115. differences" in the 1968 standard.  EBCDIC has a cent
  116. sign which ASCII did not match, and ASCII has brackets, braces,
  117. backslash, accent, and tilde which EBCDIC did not originally
  118. position in its tables.  There were some IBM print bands (notably
  119. TN and ALA) which included some other characters, but they do not
  120. constitute a standard nor are they the basis for one.
  121.  
  122.     Both ASCII and EBCDIC have "national use" characters which
  123. can be replaced in other countries by local graphics.  National
  124. standards bodies in most European countries have chosen specific
  125. graphics for the ASCII positions, and IBM has copied these
  126. choices to the EBCDIC positions.  Technically "ASCII" refers to
  127. the USA version, but everyone uses the term to refer to all the
  128. ISO 646 standard character sets which are similar except for national
  129. use positions.  IBM does not change the compiler.  Therefore, a C
  130. program will print rather strangely in Germany where the German
  131. standard replaces backslash with O-umlaut.  Of course, the
  132. programmers in most countries continue to order terminals and
  133. printers with the US character set or to make that set available
  134. as a special printer setup.  It is interesting to note that
  135. PASCAL was, after all, originally developed in Switzerland where
  136. the offical national languages are French, German, and Italian.
  137.  
  138.     At the time that Yale ASCII was shipped, IBM had no strong
  139. definition as to the position of backslash, braces, and brackets
  140. in the EBCDIC set.  Some mistakes were made (in hindsight) which
  141. were then perpetuated in the 7171.  However, the translate tables
  142. are installation configuration options.
  143.  
  144.     One approach to extending the character set is to form
  145. diacritically marked characters using true overstrikes.  In other
  146. words, there is a key marked with an umlaut.  Press the key and
  147. an umlaut appears but the cursor does not advance.  Press "O" and
  148. what displays is O-umlaut and the cursor advances.  This is the
  149. model used by the CCITT for European telex and by MARC and
  150. library systems (such as the ALA character feature on the
  151. IBM 316x). It is also effectively used by the NOTIS and DOBIS
  152. library systems.  It has never been accepted by data processing
  153. equipment manufacturers, who have instead pressed for an entirely
  154. different form of character set extension based on one character
  155. per code position (i.e., each accented character occupies one
  156. code position).
  157.  
  158.     TECHNOLOGY TO THE RESCUE.  There would probably never have
  159. been a solution to this problem without the elimination of some
  160. constraints.  It may be that there are many devices today which
  161. will not be able to use the solution, but this is a long term
  162. problem which will be solved over years as old devices disappear.
  163. The important change is that microprocessor technology in
  164. terminals and non-impact pageprinters both make it possible to
  165. extend the generally available number of characters from the old
  166. 96 to 194.
  167.  
  168.     ISO (the International Standards Organization) has adopted
  169. ISO 8859/1 and ANSI (the US standards organization) is adopting the
  170. same standard under title ANSI X3.134.2.  It provides a specific
  171. standard set of graphics for 8 bit ASCII code points X'A0' to
  172. X'FF'.  Of particular significance is the assignment of cent sign
  173. to X'A2' and EBCDIC-not to X'AC'.  So suddenly ASCII has all of
  174. the true characters typically found on an IBM terminal.  Of
  175. course, IBM always had an 8 bit character set with many unused
  176. positions.  However, there are only so many keys on the keyboard
  177. or positions on the print band.  The PC and 3800 allow all of the
  178. possible positions to be filled in.  Since IBM does pay careful
  179. attention to standards, the ISO development made it possible for
  180. them to create an internal standard for EBCDIC placement of the
  181. same 194 graphic symbols in the range of X'41' to X'FE'.  IBM
  182. started with the 38xx page printer USA DP code assignments (see
  183. "Code Page T1GDP037" in IBM 3800 Printing Subsystem Model 3 Font
  184. Catalog SH35-0053 which I assume everyone has in his library) and
  185. then adjusted it with:
  186.  
  187.     middle dot at X'B4'
  188.     copyright at X'B5'
  189.     times/multiply at X'BF'
  190.     special hyphen at X'CA'
  191.     superscript 1  at X'DA' (replaces Turkish dotless small i)
  192.     divide at X'E1'
  193.  
  194. This will be referred to as the "code page 37" table.  (In addition,
  195. IBM adjusted each country's EBCDIC to include the extra characters
  196. by filling the empty slots in the tables.  (These are the Country
  197. Extended Code Pages, CECPs.)  Note that while all the characters
  198. exist, code positions vary for each country's individual CECP.)
  199.  
  200.     The result is an implied 1-1 correspondence of 194 ASCII and
  201. US EBCDIC printable characters which in turn implies a translate
  202. table.  All of this is possible because the technology has moved
  203. to microprocessors on most terminals and printers and expanded
  204. memory allows extended character sets.
  205.  
  206.     MOST PEOPLE DO NOT UNDERSTAND WHAT THIS REALLY MEANS.  A code
  207. set assigns a graphic representation to a byte value.  The
  208. "graphic representation" is most important when a file is printed
  209. or displayed on a terminal.  The value X'4E' can be stored in
  210. binary in a FORTRAN program and can be copied from one variable
  211. to another without anyone caring what it means.  Only when it is
  212. displayed do we determine if it should be "N" (ASCII) or "+"
  213. (EBCDIC).
  214.  
  215.     Now compilers do care about the difference between "N" and
  216. "+".  Curiously enough, most ANSI language standards do not
  217. specify code points.  FORTRAN, COBOL, PASCAL, PLI, and C all
  218. specify that "+" means addition.  But none of the standards
  219. requires that plus have any particular binary value.  IBM
  220. mainframes use EBCDIC "+" and most other computers use ASCII
  221. "+", but some systems place it at another location.  VSAPL, for
  222. example, has an internal code set called "Z code" which
  223. rearranges characters for easier interpretation.  Even then, the
  224. code which displays as plus still means addition.
  225.  
  226.     The problem is that graphic representation is a matter of
  227. taste.  A certain amount of flexibility has to be left in to
  228. allow for italics, to let zero optionally have a bar through it
  229. or not, and to let the Europeans put a bar through their Z
  230. (pronounced "zed" over there).  The standards allow "stylistic
  231. differences".  In its most extreme case, however, ASCII
  232. exclamation point was regarded as a stylistic representation of
  233. EBCDIC vertical bar! (or should I say |) in ANSI X3.4-1966.
  234.  
  235.     These stylistic differences start to become a problem when
  236. the effect the selection of codes accepted by compilers, command
  237. processors, and other non-printer system components.  They have
  238. then been allowed to gum up the translation between code sets.
  239.  
  240.     The naive user says that the standard EBCDIC code for "A" is
  241. "C1".  A more correct statement is that the standard graphic
  242. reprsentation for X'C1' is "A".  Other graphic representations
  243. exist for the code (look at the 3800 fonts manual for symbol
  244. fonts and consider Japanese and other languages).  The point,
  245. however, is that most of the compilers, editors, and systems
  246. regard X'C1' as a letter.  Actually no compiler cares what the
  247. human thinks that the letter is.  Alright, there is a funny thing
  248. in FORTRAN that I-N are integers by default, but by and large the
  249. 26 letters of the alphabet are interchangable in forming names.
  250. Thus in some other country these letters could be replaced by the
  251. local alphabet as long as letters remain letters and punctuation
  252. remains punctuation.
  253.  
  254.     WARNINGS: So suddenly we have an "official" translate table
  255. between U.S. EBCDIC and ASCII.  To do it, we had to go to a larger
  256. character set on both sides.  In doing so we pick up the most
  257. important foreign language characters (as determined by ISO, not
  258. IBM).  This can be supported on all laser printers, PCs, and
  259. character loadable devices.  It may not work on older printers
  260. and terminals.  DEC, for example, supports a subset of the ISO
  261. standard as its extended character set on its terminals.
  262. However, it is generally possible today to load fonts into all
  263. but the very ancient equipment.
  264.  
  265.     An IBM standard is an internal document.  Its existence will
  266. force subsequent product developers to justify deviation from the
  267. standard, but will not prevent such deviations when a business
  268. case exists.  Put another way, if IBM feels that there is still a
  269. market for band printers, technology will prevent the creation of
  270. a 194 character set for such a device.  Given a smaller character
  271. set, IBM may have to deviate from the larger standard.  However,
  272. when an organization has to make code translations, this new
  273. standard becomes the obvious starting point.
  274.  
  275.     There is no evidence that the compilers and other
  276. applications will be ready to deal with these EBCDIC assignments.
  277. In particular, for C and PASCAL which are defined for ASCII, the
  278. compilers must support:
  279.  
  280.     circumflex at X'B0'
  281.     left bracket at X'BA'
  282.     right bracket at X'BB'
  283.  
  284. The compilers and other applications must recognize dual EBCDIC codes
  285. for some characters.  Specific examples are:
  286.  
  287.    C:      circumflex and not for "negation"
  288.            vertical bar and split bar for "or"
  289.            brackets at BA/BB and AD/BD code points
  290.            braces at 8B/9B and C0/D0 code points
  291.            "*" and new "x" for multiplication
  292.            "/" and new divide for division
  293.  
  294.    PASCAL: circumflex and not and tilde for "negation"
  295.            vertical bar and split bar for "or"
  296.            brackets at BA/BB and AD/BD code points
  297.            braces at 8B/9B and C0/D0 code points
  298.            "*" and new "x" for multiplication
  299.            "/" and new divide for division
  300.  
  301.    PL/I:   circumflex and not and tilde for "negation"
  302.            vertical bar and split bar for "or"
  303.            "*" and new "x" for multiplication
  304.            "/" and new divide for division
  305.  
  306.    REXX:   circumflex and not and tilde for "negation"
  307.            vertical bar and split bar for "or"
  308.  
  309.    Query Languages:  Unknown.
  310.  
  311.    TELNET: (In DoD TCP/IP network) virtual terminal
  312.            protocol must allow the installation to define
  313.            the character to use for the CONTROL shift.
  314.            Ideally, the installation would be able to
  315.            define two code positions (e.g., cent
  316.            for U.S. EBCDIC 3270s and left bracket for
  317.            ASCII-7 character) compatibility.  (You want
  318.            a character that you seldom use.
  319.            ASCII-7 terminals have no cent and EBCDIC-94
  320.            has no brackets).
  321.  
  322.     There is no standard for the translation of control
  323. characters.  There are 65 ASCII control codes (X'00'-X'1F' and
  324. X'7F'-X'9F') and exactly the same number in EBCDIC (X'00-X'3F'
  325. and X'FF').  However, there is no official 1-1 translation.
  326. In the past there was a tendency for duplicated mappings (EBCDIC
  327. LF and NL were both commonly mapped to ASCII LF) so making
  328. changes will not be a trivial decision.
  329.  
  330. ISSUES
  331.  
  332.     It is always difficult to know what the implications of a
  333. translate table change are going to be.  It is necessary to try
  334. it and then see what happens.  There are some old devices, like
  335. the 6670, for which change is extremely complex.  Fortunately,
  336. the desktop publishing revolution and Postscript printers are
  337. making such old devices less important.
  338.  
  339.     At Yale, we have no special insight into the software.  We
  340. will have to determine the impact of this new character mapping
  341. on PASCAL, C, PL/I, WSCRIPT, DCF, and other character sensitive
  342. products.
  343.  
  344.     However, we have unusual control over the communications
  345. area.  Through YTERM 1.4 it is possible to define any PC to be an
  346. ISO 8859 terminal.  It is also possible to load the EGA with a
  347. font that corresponds to ISO 8859 characters (eliminating a
  348. translation into the standard monochrome extended character set).
  349. By changing the translate tables in the Series/1, it is possible
  350. to build a pseudo-3270 display which supports all 194 new EBCDIC
  351. code points and displays them on an ISO 8859 terminal (like
  352. YTERM).
  353.  
  354.     In the near term, there will be some problems.  Older ASCII-7
  355. terminals will not support the ISO standard and will require the
  356. old translate tables to code PL/I.  Some host compilers will not
  357. support the new ASCII positions and uploaded files may require a
  358. translation pass until the compilers are upgraded.  Therefore,
  359. these changes would be installed only for experimental access
  360. until the full impact is determined.
  361.  
  362.     In the long run, however, these tables provide an interesting
  363. recommendation for BITNET file transfer.  If this translation
  364. could be adopted (with specific control code mappings) by ASCII
  365. locations on BITNET then we could address a number of file
  366. interchange problems.  However, even though the ISO 8859 is 95%
  367. identical to the DEC VAX extended character set, there will still
  368. have to be a comparable period of testing on the VMS and UNIX
  369. side to determine if the translation poses a problem on that end.
  370.  
  371.     The ISO 8859 standard has several parts.  I have been talking
  372. about 8859/1 the standard for Roman character sets.  There are
  373. other parts for Eastern European and presumably Russian, Arabic,
  374. Hebrew, and Japanese.  Eventually these issues may also have to
  375. be addressed.
  376.  
  377. IMPACT
  378.  
  379.     There are several areas of Yale activity which could be
  380. effected by this standard:
  381.  
  382.     The Computer Center would be directly effected if the
  383. standard is to be supported for general terminal access.
  384. For communications and terminal support, this
  385. involves creation of YTERM tables, changes to the frontend
  386. processors, and changes to PCTRANS and possibly TPRINT.  At this
  387. time there would be no intention to change line-at-a-time
  388. communications support or the Datasouth printers since these
  389. devices do not support extended character sets.  This is a
  390. subject for discussion and a long range objective.  We also need
  391. to study the impact on the existing IBM compilers, REXX, and
  392. other applications.
  393.  
  394.     Yale will work through BITNET to get these standards adopted
  395. throughout the community.  This will require the agreement of the
  396. rest of the university community.
  397.  
  398.     The university library community and the NOTIS package might
  399. consider the implications of this standard.  The current approach
  400. based on the special ALA support for overstruck characters is
  401. available on a limited set of devices.  This is an area of future
  402. discussion.
  403.  
  404.     The general community of word processing programs and users
  405. at Yale should take these code assignments into consideration
  406. when building fonts.  This is a user activity and does not
  407. explicitly involve Computer Center personnel.
  408.  
  409.     University users who have in the past been interested in
  410. non-Roman character sets should investigate the implications of
  411. the other elements of the ISO 8859 standard.
  412.  
  413.     Unfortunately, Yale has no particular forum in which to
  414. discuss such changes.  I would like to receive comments at
  415. GILBERT@YALEVM and will attempt to call a meeting to discuss the
  416. implications and implementation of table changes if the response
  417. warrants it.
  418.  
  419. HERE IS IS, WITH WARNINGS.
  420.  
  421.     The following tables are presented for the purpose of
  422. discussion.  They have not been checked for accuracy and are
  423. subject to amendment.  It is, for example, rather difficult for
  424. an American to distinguish lowercase from uppercase "Islandic
  425. Thorn" especially in two entirely different type settings.
  426. Still, the only way to document things is to actually provide the
  427. tables.  A curse upon anyone who actually puts them into
  428. production before the community as a whole agrees to them.
  429.  
  430. ASCII TO EBCDIC TABLE (WITHOUT CONTROL CODES)
  431.  
  432. *            0 1 2 3  4 5 6 7  8 9 A B  C D E F
  433.         0    00?????? ???????? ???????? ????????   0
  434.         1    ???????? ???????? ???????? ????????   1
  435.         2    405A7F7B 5B6C507D 4D5D5C4E 6B604B61   2
  436.         3    F0F1F2F3 F4F5F6F7 F8F97A5E 4C7E6E6F   3
  437.         4    7CC1C2C3 C4C5C6C7 C8C9D1D2 D3D4D5D6   4
  438.         5    D7D8D9E2 E3E4E5E6 E7E8E9BA E0BBB06D   5
  439.         6    79818283 84858687 88899192 93949596   6
  440.         7    979899A2 A3A4A5A6 A7A8A9C0 4FD0A1FF   7
  441.         8    ???????? ???????? ???????? ????????   8
  442.         9    ???????? ???????? ???????? ????????   9
  443.         A    41AA4AB1 9FB26AB5 BDB49A8A 5FCAAFBC   A
  444.         B    908FEAFA BEA0B6B3 9DDA9B8B B7B8B9AB   B
  445.         C    64656266 63679E68 74717273 78757677   C
  446.         D    AC69EDEE EBEFECBF 80FDFEFB FCADAE59   D
  447.         E    44454246 43479648 54515253 58555657   E
  448.         F    8C49CDCE CBCFCCE1 70DDDEDB DC8D8EDF   F
  449. *            0 1 2 3  4 5 6 7  8 9 A B  C D E F
  450.  
  451.  
  452. EBCDIC ASCII TABLE
  453.  
  454. *            0 1 2 3  4 5 6 7  8 9 A B  C D E F
  455.         0    00?????? ???????? ???????? ????????   0
  456.         1    ???????? ???????? ???????? ????????   1
  457.         2    ???????? ???????? ???????? ????????   2
  458.         3    ???????? ???????? ???????? ????????   3
  459.         4    20A0E2E4 E0E1E3E5 E7F1A22E 3C282B7C   4
  460.         5    26E9EAEB E8EDEEEF ECDF2124 2A293BAC   5
  461.         6    2D2FC2C4 C0C1C3C5 C7D1A62C 254F3E2F   6
  462.         7    F8C9CACB C8CDCECF CC6D3A23 4D273D22   7
  463.         8    D8616263 64656667 6869ABBB F0FDFEA1   8
  464.         9    B06A6B6C 6D6E6F70 7172AABA E6B8C6A4   9
  465.         A    B57E7374 75767778 797AA1BF D0DDDEAE   A
  466.         B    5EA3A5B7 A9A7B6BC BDBE5B5D AFA8B4D7   B
  467.         C    7B414243 44454647 4849ADF4 F6F2F3F5   C
  468.         D    7D4A4B4C 4D4E4F50 5152B9FB FCF9FAFF   D
  469.         E    5CF75354 55565758 595AB2D4 D6D2D3D5   E
  470.         F    30313233 34353637 3839B3D8 DCD9DA7F   F
  471. *            0 1 2 3  4 5 6 7  8 9 A B  C D E F
  472. 22-Mar-88 20:55:10-EST,6359;000000000001
  473. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  474. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 22 Mar 88 20:55:02-EST
  475. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 22 Mar 88 20:55:15 EDT
  476. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  477.  1512; Tue, 22 Mar 88 20:55:14 EDT
  478. Received: by BITNIC (Mailer X1.24) id 3564; Tue, 22 Mar 88 20:49:19 EDT
  479. Date:         Tue, 22 Mar 88 19:10:18 EST
  480. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  481.               <ISO8859@JHUVM>
  482. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  483.               <ISO8859@JHUVM>
  484. From:         Mike_Alexander@um.cc.umich.edu
  485. Subject:      Re: Some Important Comments from Howard Gilbert at Yale
  486.               University
  487. X-To:         ISO8859%JHUVM.BITNET@CUNYVM.CUNY.EDU
  488. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  489.  
  490. I read with great interest the comments from Howard Gilbert at Yale
  491. regarding ISO8859 to EBCDIC translation.  He captures the essence of
  492. the problem very well.
  493.  
  494. As Edwin Hart indicated in his preface to these comments, the MTS
  495. community has already installed a ISO8859 to EBCDIC translate table
  496. as its standard for network access to the various machines
  497. involved.  I compared the translate table that Howard Gilbert gave
  498. at the end of his message with the one we use (ignoring the control
  499. characters he didn't fill in) and found the following differences.
  500.  
  501.        ISO8859    Name in ISO8859    Gilbert      MTS
  502.  
  503.          7F        DEL                FF           07
  504.          DE        Capital Thorn      AE           8E
  505.          E6        Small ae dipthong  96           9C
  506.          FE        Small Thorn        8E           AE
  507.  
  508. The code for E6 seems to be a typo, since ISO8859 code point 6F also
  509. translates into EBCDIC code point 96.  The reverse table translates
  510. EBCDIC 96 (which is a lower case o) into ISO8859 6F which seems
  511. correct.
  512.  
  513. We chose to translate ISO8859 code 7F into EBCDIC 07 since that has
  514. been defined as the DEL character in various IBM publications for
  515. some time.  I didn't personally have much to do with this decision,
  516. so I'll let others justify it, but it seems to make sense.
  517.  
  518. We seem to disagree about the difference between an upper case and a
  519. lower case Icelandic Thorn.  I hope we're right, since our table is
  520. already installed.
  521.  
  522. In case anyone is interested, here is the rest of our translate
  523. table.  The codes for ISO8859 01 through 1F were chosen to
  524. correspond to existing EBCDIC control characters.  I don't recall
  525. all the discussion behind the choice of the codes for ISO8859 80 to
  526. 9F, but these codes were chosen so that the entire table is one to
  527. one.  I can dig up some of the discussion behind these choices if
  528. anyone cares.
  529.  
  530. In the following, the name on the left gives the ISO8859 code and
  531. the value in quotes is the corresponding EBCDIC code.
  532.  
  533. ITOE#01  DC    X'01'        SOH   start of heading           (Ctrl-A)
  534. ITOE#02  DC    X'02'        STX   start of text              (Ctrl-B)
  535. ITOE#03  DC    X'03'        ETX   end of text                (Ctrl-C)
  536. ITOE#04  DC    X'37'        EOT   end of transmission        (Ctrl-D)
  537. ITOE#05  DC    X'2D'        ENQ   enquiry                    (Ctrl-E)
  538. ITOE#06  DC    X'2E'        ACK   acknowledge                (Ctrl-F)
  539. ITOE#07  DC    X'2F'        BEL   bell                       (Ctrl-G)
  540. ITOE#08  DC    X'16'        BS    backspace                  (Ctrl-H)
  541. ITOE#09  DC    X'05'        HT    horizontal tabulation      (Ctrl-I)
  542. ITOE#0A  DC    X'25'        LF    line feed                  (Ctrl-J)
  543. ITOE#0B  DC    X'0B'        VT    vertical tabulation        (Ctrl-K)
  544. ITOE#0C  DC    X'0C'        FF    form feed                  (Ctrl-L)
  545. ITOE#0D  DC    X'0D'        CR    carriage return            (Ctrl-M)
  546. ITOE#0E  DC    X'0E'        SO    shift-out                  (Ctrl-N)
  547. ITOE#0F  DC    X'0F'        SI    shift-in                   (Ctrl-O)
  548. *
  549. ITOE#10  DC    X'10'        DLE   data link escape           (Ctrl-P)
  550. ITOE#11  DC    X'11'        DC1   device control 1    (X-Off, Ctrl-Q)
  551. ITOE#12  DC    X'12'        DC2   device control 2           (Ctrl-R)
  552. ITOE#13  DC    X'13'        DC3   device control 3     (X-On, Ctrl-S)
  553. ITOE#14  DC    X'3C'        DC4   device control 4           (Ctrl-T)
  554. ITOE#15  DC    X'3D'        NAK   negative acknowledge       (Ctrl-U)
  555. ITOE#16  DC    X'32'        SYN   synchronous idle           (Ctrl-V)
  556. ITOE#17  DC    X'26'        ETB   end of transmission block  (Ctrl-W)
  557. ITOE#18  DC    X'18'        CAN   cancel                     (Ctrl-X)
  558. ITOE#19  DC    X'19'        EM    end of medium              (Ctrl-Y)
  559. ITOE#1A  DC    X'3F'        SUB   substitute character       (Ctrl-Z)
  560. ITOE#1B  DC    X'27'        ESC   escape                     (Escape)
  561. ITOE#1C  DC    X'1C'        FS    file separator
  562. ITOE#1D  DC    X'1D'        GS    group separator
  563. ITOE#1E  DC    X'1E'        RS    record separator
  564. ITOE#1F  DC    X'1F'        US    unit separator
  565.  
  566. ITOE#80  DC    X'20'              ...
  567. ITOE#81  DC    X'21'              ...
  568. ITOE#82  DC    X'22'              ...
  569. ITOE#83  DC    X'23'              ...
  570. ITOE#84  DC    X'24'              ...
  571. ITOE#85  DC    X'15'              ...
  572. ITOE#86  DC    X'06'              ...
  573. ITOE#87  DC    X'17'              ...
  574. ITOE#88  DC    X'28'              ...
  575. ITOE#89  DC    X'29'              ...
  576. ITOE#8A  DC    X'2A'              ...
  577. ITOE#8B  DC    X'2B'              ...
  578. ITOE#8C  DC    X'2C'              ...
  579. ITOE#8D  DC    X'09'              ...
  580. ITOE#8E  DC    X'0A'              ...
  581. ITOE#8F  DC    X'1B'              ...
  582. *
  583. ITOE#90  DC    X'30'              ...
  584. ITOE#91  DC    X'31'              ...
  585. ITOE#92  DC    X'1A'              ...
  586. ITOE#93  DC    X'33'              ...
  587. ITOE#94  DC    X'34'              ...
  588. ITOE#95  DC    X'35'              ...
  589. ITOE#96  DC    X'36'              ...
  590. ITOE#97  DC    X'08'              ...
  591. ITOE#98  DC    X'38'              ...
  592. ITOE#99  DC    X'39'              ...
  593. ITOE#9A  DC    X'3A'              ...
  594. ITOE#9B  DC    X'3B'              ...
  595. ITOE#9C  DC    X'04'              ...
  596. ITOE#9D  DC    X'14'              ...
  597. ITOE#9E  DC    X'3E'              ...
  598. ITOE#9F  DC    X'FF'              ...
  599. 23-Mar-88 05:07:01-EST,9045;000000000001
  600. Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
  601. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 05:06:36-EST
  602. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 05:06:42 EDT
  603. Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  604.  2089; Wed, 23 Mar 88 05:06:40 EDT
  605. Received: by BLIULG11 (Mailer X1.25) id 6083; Wed, 23 Mar 88 11:03:41 +0100
  606. Date:         Wed, 23 Mar 88 11:00:18 +0100
  607. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  608. Subject:      ASCII/ISO/which EBCDIC? summary
  609. To:           ISO8859@JHUVM,
  610.               Protocol Converter list <IBM7171@DEARN>,
  611.               Columbia University Center for Computing Activities
  612.  <INFO-KERMIT@CU20B.COLUMBIA.EDU>,
  613.               IBM-KERMIT@CU20B.COLUMBIA.EDU
  614.  
  615. Some  time  ago,  I raised a discussion on several mailing  lists
  616. about data communication and ASCII/ISO/EBCDIC character codes.  I
  617. now  realize my wording was very loose.  Since then,  I have  had
  618. contacts   with  both  kind  people  on  the  nets  and  a   very
  619. knowledgeable  IBM representative.  I feel responsible to restate
  620. the  problem  correctly  to  avoid  confusion  and  reflect   the
  621. information,  as  I promised to some.  I'll try to be as short as
  622. feasible.  Please join the Edwin Hart's list ISO8859 at JHUVM for
  623. discussing details on codes etc...
  624.  
  625. We,  ASCII or EBCDIC network users must pay particular  attention
  626. to  character  codes standards,  now extending to  international.
  627. Even sites not interested in international characters will sooner
  628. or  later hit the problem because,  albeit the situation is  well
  629. defined  in  the  ASCII  world with  an  (often  overlooked)  ISO
  630. standard,  it is far from that for EBCDIC users faced to a choice
  631. among   several  new  "codes  pages"  whose  differences  lie  on
  632. the  positions  of  a few characters,  strangely enough  not  the
  633. extended  ones.  The era of data communication raises  an  urgent
  634. need for a single character codes standard.
  635.  
  636. BITNET apparently had found one.  It is now silently tossed up by
  637. these  new codes sets.  We had been proposed "table 500"  (below)
  638. without  warning.  And it turns out that our IBM  representatives
  639. ignored the de-facto coherence of BITNET.
  640.  
  641. The  ISO  have  produced  a considerable  work  in  defining  the
  642. graphics necessary for each country and assigned them codes.  For
  643. latin  based  alphabets,  this  yielded  the ISO  8859/1  =  ANSI
  644. X3.134.2 = ECMA 94,  which is wisely a superset of ISO 646 = ANSI
  645. X3.4, the well known ASCII.
  646.  
  647. ISO  8859/1 assigns character graphics to the A0-FF codes  range.
  648. The  range  80-9F  is  unassigned and can  be  used  for  special
  649. purposes  in 8-bit storage and transmission.  But it is kept free
  650. in  order to not interfere with control codes 00-1F during  7-bit
  651. transmission  in  compatibility with the  ISO  2022,  alternating
  652. between the two sets with the SI/SO control codes.
  653.  
  654. Nobody  questions  the value of ISO and everything so  far  looks
  655. ideal to avoid a new Babel for the largest part of the world.
  656.  
  657. IBM,  in conforming EBCDIC to ISO,  at least strongly claims that
  658. any  EBCDIC  extension shall contain exactly the  ISO  characters
  659. set,  in  order to make a revertible translation always possible,
  660. but allows variations in which particular code is assigned to  an
  661. ISO  character.  This idea is also the origin of the IBM PC  code
  662. page  850  ASCII  extension and of the  IBM  mainframes  multiple
  663. CECP's (country extended code pages) EBCDIC extensions.
  664.  
  665. Why multiple? because:
  666. - Compatibility with previous codes rules IBM  evolution,  e.  g.
  667. code page 850 contains the ISO characters, but most of the former
  668. cp 437 stay in place (missing ones expel graphic characters).
  669. - The  eighty-some-characters  restricted former EBCDIC  did  not
  670. contain  all the X3.4 ASCII characters and conversely.  (see  IBM
  671. publication  GX20-1850,  the yellow book,  pp 9-12 second column,
  672. let's call it simply "EBCDIC" and the third column "TN-chain").
  673. - Some  of  those  EBCDIC  codes  not  in  ASCII  are  vital  for
  674. programming  or  using  IBM systems and had to be  produced  from
  675. ASCII terminals.
  676. - ASCII/EBCDIC translation tables were built to accommodate these
  677. needs instead of mapping equivalent characters,  varied over time
  678. and systems, and are different from those used in file transfers.
  679. - Habits, software and data built up to a huge amount.
  680. - ISO now defines the missing EBCDIC characters.
  681. - It  is finally embarrassing to define a single extended  EBCDIC
  682. and  the  proposed extensions tend to match the  terminal  tables
  683. rather than the more stable file transfer ones.
  684.  
  685. Never  mind,  says IBM.  As long as a particular EBCDIC extension
  686. conforms to ISO,  GDDM will take care of that.  And we're off  on
  687. the  grounds  that  any  conforming  extension  will  do.   These
  688. extensions  are called "Code Pages XXXXX" (cpXXX for short).  The
  689. most prominent offerings are cp500 and cp037, more of them below,
  690. but others exist in order to best fit existing installation use.
  691.  
  692. GDDM  is  an IBM product that will interface with  the  operating
  693. system,  the I/O devices and the application programs in order to
  694. (for  our  concern) convert one particular code page to  another.
  695. They  say GDDM will use cp500 internally as the code page to  and
  696. from which conversion will be made.
  697.  
  698. I simply don't believe in (that function of) GDDM because it  can
  699. only  be  effective when everything will have been  converted  to
  700. that interface.  Networking is a crying example.  What could GDDM
  701. do to a file (they're supposed to be code-tagged) received from a
  702. network site that does not use it?  My opinion is that we have to
  703. settle  on a single code  NOW because the sooner the  better,  at
  704. least for networking, but also the recommended one. Which one?
  705.  
  706. Practically,  that  making the most people happy  certainly.  And
  707. BITNET users are numerous. Other reasons favour the present code:
  708. - It must be compatible with former EBCDIC.
  709. - The  compatibility with the former ASCII/EBCDIC translation  is
  710. vital, because it often gets involved in conversions whose result
  711. is  used  as  data critical for  computation  rather  than  "good
  712. looking" humanly readable text.
  713.  
  714. BTW,  I  think that storing ASCII data on BITNET servers is  best
  715. done in "binary" format (ASCII files streams split into "records"
  716. of  arbitrary length,  best 128).  So bad for docs direct EBCDIC-
  717. wise readability.
  718.  
  719. cp500 is simply not compatible with the former EBCDIC: it carries
  720. on a strange habit of using exclamation marks for what a compiler
  721. understands  as a vertical bar and such things.  I am told it  is
  722. recommended to European because GDDM uses it internally (???) and
  723. on  the ground of previous codes compatibility,  but it does  not
  724. preserve their accented letters :-)
  725.  
  726. cp037 is EBCDIC compatible and recommended to US and Canadian.
  727.  
  728. Both  are  not compatible with what I believe  is  the  prominent
  729. ASCII/EBCDIC translation,  that of the 7171,  VM,  Kermit, BITNET
  730. gateways, ASCII tapes conversion etc... and, as I am told by IBM,
  731. the  3708  and 3275.
  732. - cp037  puts brackets at BA and BB and cp500 puts them at 4A and
  733. 5A whereas traditional conversion from ASCII is to the  positions
  734. in the TN chain AD and BD.
  735. - cp500   additionally   deviates,    because   of   its   EBCDIC
  736. discrepancies, for ASCII "exclamation mark" and "vertical bar".
  737. - the  ASCII  "circumflex"  uniformly translated to  EBCDIC  "not
  738. sign"  5F.  There was no circumflex in EBCDIC,  but its new  ISO-
  739. based definition threatens the former conversion.
  740. - whereas  the  ASCII  backslash is often used to give  the  cent
  741. sign in terminal mode, file transfers keep the EBCDIC backslash.
  742.  
  743. cp037 and cp500 differ in only 7 characters.
  744. VM/SP  5 uses two TTY conversions:  TERMINAL ASCIITBL VM1 or VM2.
  745. VM1,  the default,  is "traditional" (037 with TN chain brackets)
  746. and  matches  no code page.  VM2 corresponds to  cp500,  but  the
  747. brochure  GC24-5328 explains that by using the 037  graphics.  To
  748. add  to  the  confusion the explanation refers to ANSI  X3.4  and
  749. X3.26 respectively.
  750.  
  751. My  experience  shows  that  BITNET is working  perfectly  as  it
  752. stands. Are we going to let a chance messing up all that?
  753.  
  754. And it looks like defining another code page would not be hard to
  755. get  from  IBM  and  that  there  is  "nothing  defined  yet   as
  756. communication standard". I think that we should strongly consider
  757. requiring  another  code  page that matches BITNET  and  that  it
  758. become the standard.
  759.  
  760. In summary:
  761. Adopting CP037 with brackets at AD BD is easy.  What I find  more
  762. serious is the "ASCII circumflex" to "EBCDIC not" conversion that
  763. makes no theoretical sense now both characters are defined in the
  764. other  set,  but is is presently used as such in  many  character
  765. encoded stored binary files.
  766.  
  767. I  close  this discussion on these lists,  it now belongs to  the
  768. list ISO8859.
  769. 23-Mar-88 06:36:54-EST,1210;000000000001
  770. Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
  771. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 06:36:37-EST
  772. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 06:36:37 EDT
  773. Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  774.  2224; Wed, 23 Mar 88 06:36:36 EDT
  775. Received: by BLIULG11 (Mailer X1.25) id 7865; Wed, 23 Mar 88 12:35:32 +0100
  776. Date:         Wed, 23 Mar 88 12:21:37 +0100
  777. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  778. Subject:      Re: Non-standard EBCDIC mappings
  779. To:           IBM-KERMIT@CU20B.COLUMBIA.EDU
  780. In-Reply-To:  Message of 1988 Mar 14 23:41 EST from <PEPMNT@CFAAMP>
  781.  
  782. Had the situation been well defined, I would have suggested implementing
  783. the full ISO character set translation in the optional 8-bit table.
  784. But with various EBCDIC versions and pure ISO itself being rarely used, even
  785. on the IBM PC, I think the best is to wait and see.
  786. The present IBM Kermit translation table is probably what everyone silently
  787. wishes as "the" standard EBCDIC. Let us keep from encouraging exotic ones
  788. and leave the door open for compatible extension.
  789. 23-Mar-88 15:05:14-EST,2877;000000000001
  790. Return-Path: <@um.cc.umich.edu:Bruce_Jolliffe@mtsg.ubc.ca>
  791. Received: from umix.cc.umich.edu by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 15:04:53-EST
  792. Received: by umix.cc.umich.edu (5.54/umix-2.0)
  793.     id AA20587; Wed, 23 Mar 88 15:08:57 EST
  794. Received: from MTSG.UBC.CA by um.cc.umich.edu via MTS-Net; Wed, 23 Mar 88 14:54:46 EST
  795. Date: Wed, 23 Mar 88 11:53:14 PST
  796. From: Bruce_Jolliffe@mtsg.ubc.ca
  797. To: IBM-Kermit@cu20b.Columbia.edu, info-kermit@cu20b.Columbia.edu,
  798.         iso8859%jhuvm@umix.cc.umich.edu, ibm7171%dearn@umix.cc.umich.edu
  799. Message-Id: <972890@mtsg.ubc.ca>
  800. Subject: ISO (ASCII) to EBCDIC Standards
  801.  
  802.  
  803. As one of several MTS sites that have recently adopted an ISO 8859 -
  804. Code Page 37 translation table I found your note on the adoption
  805. standard ASCII-EBCDIC tables interesting.  We mapped each ISO graphic
  806. to its corresponding EBCDIC graphic.  Thus we mapped the EBCDIC
  807. logical not (5F) into the ISO logical not (AC).  Similarily we mapped
  808. the ISO circumflex into the EBCDIC circumflex (B0) and the ISO tilde
  809. (7F) into the EBCDIC tilde (A1).
  810.  
  811. As you might guess the two thorniest issues over the IBM Code Page 37
  812. was the square brackets and the logical not.  As previously noted, in
  813. another message, the square brackets in Code Page 37 are moved from
  814. their traditional TN positions of AD and BD to BA and BB respectively.
  815. The second issue concerned the logical not.  At most of the MTS sites
  816. we had traditionally mapped EBCDIC logical nots into tildes.  After
  817. much debate we decided it made no sense to do cross graphics mapping
  818. and decided to go with a graphic to graphic mapping.
  819.  
  820. Many of the MTS sites provide general access to their IBM mainframes
  821. exclusively through ASCII terminals. Thus many applications that
  822. used the logical not as an input character had to be changed to accept
  823. the EBCDIC tilde (we had previously mapped EBCDIC logical nots to
  824. ASCII tildes).
  825.  
  826. Prior to the conversion there was a lot apprehension about changing to
  827. the newer standard and we prepared for the worse. Now the conversion
  828. has been done, and we can look back the conversion was more of a nuisance
  829. rather than a major hassle. Granted it was not free, but with a
  830. reasonable amount of preparation and saturation publicity the conversion
  831. can be relatively painless.
  832.  
  833. The installations that have made this change include the University
  834. of Michigan, Renssellaer Polytechnic Institute, University of
  835. British Columbia, Simon Fraser University, University of Newcastle,
  836. Durham University, and Wayne State University. The University of
  837. Alberta, the other remaining major MTS site, is due to convert this
  838. summer.
  839.  
  840.  
  841.                 Bruce Jolliffe
  842.                 Computing Centre
  843.                 University of British Columbia
  844.  
  845.                 Bruce_Jolliffe@mtsg.ubc.ca
  846.           or
  847.                 USERBDJ@UBCMTSG.BITNET
  848.  
  849.  
  850. 23-Mar-88 16:04:42-EST,1909;000000000001
  851. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  852. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 16:04:37-EST
  853. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 16:04:49 EDT
  854. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  855.  3172; Wed, 23 Mar 88 16:04:45 EDT
  856. Received: by BITNIC (Mailer X1.24) id 2885; Wed, 23 Mar 88 15:58:39 EDT
  857. Date:         Wed, 23 Mar 88 15:38:39 +0100
  858. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  859.               <ISO8859@JHUVM>
  860. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  861.               <ISO8859@JHUVM>
  862. From:         "Alain FONTAINE (Postmaster - NAD)" <FNTA80%BUCLLN11.BITNET@CUVMA.COLUMBIA.EDU>
  863. Subject:      Re: Some Important Comments from Howard Gilbert at Yale
  864.               University
  865. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  866. In-Reply-To:  Message of Tue, 15 Mar 88 11:17:07 EST from <HART@APLVM>
  867.  
  868. Quite important, indeed...  But the tables shown are not  correct: it is
  869. easy to verify  that some values are present twice,  and some others not
  870. at all. This affects six values in the EBCDIC to ASCII table, and one in
  871. the ASCII to EBCDIC table. The  replacement values given here are indeed
  872. consistent, but that does not mean that they are the truth.
  873.  
  874. EBCDIC to ASCII
  875.  
  876.       '6D' should be translated into '5F' instead of '4F'
  877.       '6F' should be translated into '3F' instead of '2F'
  878.       '79' should be translated into '60' instead of '6D'
  879.       '7C' should be translated into '40' instead of '4D'
  880.       '8F' should be translated into 'B1' instead of 'A1'
  881.       'FB' should be translated into 'DB' instead of 'D8'
  882.  
  883. ASCII to EBCDIC
  884.  
  885.       'E6' should be translated into '9C' instead of '96'
  886.  
  887. Does anybody know better ?                                      /AF
  888. 23-Mar-88 16:05:24-EST,2571;000000000001
  889. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  890. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 16:05:20-EST
  891. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 16:05:38 EDT
  892. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  893.  3180; Wed, 23 Mar 88 16:05:34 EDT
  894. Received: by BITNIC (Mailer X1.24) id 2907; Wed, 23 Mar 88 15:59:28 EDT
  895. Date:         Wed, 23 Mar 88 09:56:36 CST
  896. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  897.               <ISO8859@JHUVM>
  898. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  899.               <ISO8859@JHUVM>
  900. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  901. Subject:      Thorn
  902. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  903.  
  904. I have not yet had the chance to look all through Howard Gilbert's
  905. translate table, but can answer the query about thorn:  in the EBCDIC
  906. CECP for the US, uppercase thorn is at AE and lowercase thorn is
  907. at 8E.  Apart from the typography (which I admit is not always real
  908. clear for non-readers of Icelandic or Old English), these contextual
  909. clues should tip you off:  8C-8E (lowercase) correspond to AC-AE
  910. (uppercase), and the IBM identifying code (LT630000 and LT640000)
  911. for uppercase letters (LT640000 in this case) is consistently
  912. 10000 higher than the code for the corresponding lowercase letters.
  913.  
  914. The typographic differences (in case anyone has to design a font
  915. for these!) are:
  916.  
  917.     - the lowercase thorn has a descender and an ascender; its bowl
  918.          rests on the base line.  (so it is sometimes simulated on
  919.          non-Icelandic typewriters by overstriking 'b' and 'p', unless
  920.          they have serifs, or by overstriking right-bracket and 'o')
  921.     - the uppercase thorn is standard upper-case height, has no
  922.          descender, and its bowl is at mid-letter height, like the
  923.          bowl on a 'P' that has slipped down a bit.
  924.  
  925. Speaking of fonts -- I have designed an ISO8859 font for the IBM3163
  926. terminal, using font design software which was unsigned but I
  927. believe came from Penn.  It's utilitarian, not beautiful, more or
  928. less matches the native IBM3163 fonts, and anyone who wants it
  929. can have it if they promise to send me any improvements they make.
  930. (It can also be downloaded and used as a start on a PC font, since
  931. the cell sizes are similar but the base line and line thickness
  932. are different.)
  933.  
  934. Michael Sperberg-McQueen, University of Illinois at Chicago
  935. 23-Mar-88 23:10:21-EST,3250;000000000001
  936. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  937. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 23 Mar 88 23:10:00-EST
  938. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 23 Mar 88 22:41:12 EDT
  939. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  940.  3772; Wed, 23 Mar 88 22:41:10 EDT
  941. Received: by BITNIC (Mailer X1.24) id 5808; Wed, 23 Mar 88 22:35:21 EDT
  942. Date:         Wed, 23 Mar 88 11:53:14 PST
  943. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  944.               <ISO8859@JHUVM>
  945. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  946.               <ISO8859@JHUVM>
  947. From:         Bruce Jolliffe <USERBDJ%UBCMTSG.BITNET@CUVMA.COLUMBIA.EDU>
  948. Subject:      ISO (ASCII) to EBCDIC Standards
  949. X-To:         IBM-Kermit@cu20b.Columbia.edu, info-kermit@cu20b.Columbia.edu,
  950.               iso8859@JHUVM, ibm7171@DEARN
  951. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  952.  
  953.  
  954. As one of several MTS sites that have recently adopted an ISO 8859 -
  955. Code Page 37 translation table I found your note on the adoption
  956. standard ASCII-EBCDIC tables interesting.  We mapped each ISO graphic
  957. to its corresponding EBCDIC graphic.  Thus we mapped the EBCDIC
  958. logical not (5F) into the ISO logical not (AC).  Similarily we mapped
  959. the ISO circumflex into the EBCDIC circumflex (B0) and the ISO tilde
  960. (7F) into the EBCDIC tilde (A1).
  961.  
  962. As you might guess the two thorniest issues over the IBM Code Page 37
  963. was the square brackets and the logical not.  As previously noted, in
  964. another message, the square brackets in Code Page 37 are moved from
  965. their traditional TN positions of AD and BD to BA and BB respectively.
  966. The second issue concerned the logical not.  At most of the MTS sites
  967. we had traditionally mapped EBCDIC logical nots into tildes.  After
  968. much debate we decided it made no sense to do cross graphics mapping
  969. and decided to go with a graphic to graphic mapping.
  970.  
  971. Many of the MTS sites provide general access to their IBM mainframes
  972. exclusively through ASCII terminals. Thus many applications that
  973. used the logical not as an input character had to be changed to accept
  974. the EBCDIC tilde (we had previously mapped EBCDIC logical nots to
  975. ASCII tildes).
  976.  
  977. Prior to the conversion there was a lot apprehension about changing to
  978. the newer standard and we prepared for the worse. Now the conversion
  979. has been done, and we can look back the conversion was more of a nuisance
  980. rather than a major hassle. Granted it was not free, but with a
  981. reasonable amount of preparation and saturation publicity the conversion
  982. can be relatively painless.
  983.  
  984. The installations that have made this change include the University
  985. of Michigan, Renssellaer Polytechnic Institute, University of
  986. British Columbia, Simon Fraser University, University of Newcastle,
  987. Durham University, and Wayne State University. The University of
  988. Alberta, the other remaining major MTS site, is due to convert this
  989. summer.
  990.  
  991.  
  992.                 Bruce Jolliffe
  993.                 Computing Centre
  994.                 University of British Columbia
  995.  
  996.                 Bruce_Jolliffe@mtsg.ubc.ca
  997.           or
  998.                 USERBDJ@UBCMTSG.BITNET
  999.  
  1000.  
  1001. 24-Mar-88 09:23:23-EST,2803;000000000001
  1002. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1003. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 24 Mar 88 09:23:17-EST
  1004. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 24 Mar 88 09:23:41 EDT
  1005. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1006.  4191; Thu, 24 Mar 88 09:23:40 EDT
  1007. Received: by BITNIC (Mailer X1.24) id 0618; Thu, 24 Mar 88 09:18:10 EDT
  1008. Date:         Thu, 24 Mar 88 07:19:59 EST
  1009. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  1010.               <ISO8859@JHUVM>
  1011. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  1012.               <ISO8859@JHUVM>
  1013. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  1014. Subject:      RE:       How to get a copy of ISO8859
  1015. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1016.  
  1017.    The way to obtain any ISO standard is to go to one's own national
  1018. standards body and order it through them.  In various countries,
  1019. national depository libraries have them also and other libraries have at
  1020. least some on standing subscriptions.   The ISO Central Secretariat in
  1021. Geneva tries to stay out of the bookstore business and I gather will not
  1022. sell standards to individuals.
  1023.   The national standards bodies act as ISO's sales agents within their
  1024. own countries.
  1025.   Bo, this means that you have to find ISO8859 in Norway and, for the
  1026. other readers of this list, similarly.
  1027.   For readers in the USA, ISO standards are obtained through ANSI.  It
  1028. is best to call their order department at 212/642-4900 and get price and
  1029. shipping information.  If you must write, they are at 1430 Broadway, New
  1030. York City, NY 10018.  Specifying "order department" in the address will
  1031. save a bit of time.  I don't have the information on enough other
  1032. countries handy to make it worth listing them.  I recommend that people
  1033. outside the USA not try to order through ANSI for two reasons - they
  1034. might refuse to sell them to you, and, since the publications department
  1035. is a major source of funds for ANSI, their prices for ISO standards are
  1036. often significantly higher than the prices of many other national
  1037. bodies (some of which, I gather, give the things away).
  1038.  
  1039.   Specific warning about ISO 8859:  It is not one standard, but a whole
  1040. family of things, starting with what used to be called "eight-bit ASCII"
  1041. and is now known as "Latin alphabet-1" (ISO8859/1), and extending into a
  1042. large variety of things (many still in draft) that cover mixtures of the
  1043. simple characters the Romans used with a large assortment of specialized
  1044. graphics, embellished Roman, and the character sets of other languages.
  1045. Since they are all "part of" 8859, ordering "8859" is likely to get you
  1046. a lot of documents at a proportionately high price.
  1047.  
  1048. 24-Mar-88 13:28:38-EST,6620;000000000001
  1049. Return-Path: <@CUVMA.COLUMBIA.EDU:LISTSERV@BITNIC.BITNET>
  1050. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 24 Mar 88 13:28:32-EST
  1051. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 24 Mar 88 13:28:33 EDT
  1052. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1053.  5734; Thu, 24 Mar 88 13:28:28 EDT
  1054. Received: by BITNIC (Mailer X1.24) id 2911; Thu, 24 Mar 88 13:21:03 EDT
  1055. Date:         Thu, 24 Mar 1988 13:21:01 EDT
  1056. Sender:       "Revised List Processor (1.5m)" <LISTSERV%BITNIC.BITNET@CUVMA.COLUMBIA.EDU>
  1057. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  1058. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1059. Subject:      File "MOSGLA XMIT" being sent to you.
  1060.  
  1061. *--------------------------------- Cut here ----------------------------------*
  1062. )\INMR01a&HLERUL2MOSGLA    JHUVMISO8859 1988032416
  1063. 56\HINMR02INMCOPYo- a&  
  1064.  MOSGLAXMITDATA -ISOLIST\INMR03o- a&
  1065. *{Dear list users
  1066.        *{ECMA standards, which are generally identical with the corresponding
  1067.          *{ones from ISO, can be ordered from: ECMA, 114 Rue du Rhone, CH-1204,
  1068.            *{Geneve, Switzerland.
  1069.              *{The following is a rather comprehensive list of everything availa
  1070. ble.           *{
  1071.                  *{1
  1072.                    *{  INTERNATIONAL STANDARDS FOR CHARACTER CODES AND RELATED S
  1073. UBJECTS              *{
  1074.                        *{  ISO 646-1983  ISO 7-bit coded character set for infor
  1075. mation interchange       *{  ISO 2022-1986 ISO 7-bit and 8-bit coded character s
  1076. ets -                      *{               Code extension techniques
  1077.                              *{  ISO 2047-1975 Graphical representations for the
  1078.  control characters of         *{               the 7-bit coded character set
  1079.                                  *{  ISO 2375-1985 Procedure for the registratio
  1080. n of escape sequences              *{  ISO 4873-1985 8-bit code for information
  1081. interchange -                        *{               Structure and rules for im
  1082. plementation                           *{  ISO 5426-1983 Extension of the Latin
  1083. alphabet coded character set for         *{               bibliographic informat
  1084. ion interchange                            *{  ISO 5428-1984 Greek alphabet code
  1085. d character set for                          *{               bibliographic info
  1086. rmation interchange                            *{  ISO 6429 DIS  ISO 7-bit and 8
  1087. -bit coded character sets -                      *{               additional con
  1088. trol functions for character-imaging devices       *{  ISO 6862 DIS  Mathematica
  1089. l coded character set for                            *{               bibliograp
  1090. hic information interchange                            *{  ISO 6937   Coded char
  1091. acter sets for textcommunication                         *{  ISO 6937/1-1983 Gen
  1092. eral Introduction                                          *{  ISO 6937/2-1987 L
  1093. atin alphabetic and non-alphabetic graphic characters        *{  ISO 6937/3 DIS
  1094.  Control functions for page-image format                       *{  ISO 6937/4 DP
  1095.    Text-processible format                                       *{  ISO 6937/5
  1096. DP   Scientific and technical graphic characters                   *{  ISO 6937/
  1097. 6 DP   Publishing and box drawing graphic characters                 *{  ISO 693
  1098. 7/7 DIS  Greek graphic characters    (to be withdrawn)                 *{  ISO 6
  1099. 937/8 DIS  Cyrillic graphic characters (to be withdrawn)                 *{  ISO
  1100.  7350 DIS  Text communication -                                            *{
  1101.             registration of graphic character subrepertoires                 *{
  1102.  ISO 8859   8-bit single byte coded graphic characters                         *
  1103. {  ISO 8859/1-1987 Latin alphabet no. 1
  1104.  *{  ISO 8859/2-1987 Latin alphabet no. 2
  1105.    *{  ISO 8859/3-DIS  Latin alphabet no. 3
  1106.      *{  ISO 8859/4-DIS  Latin alphabet no. 4
  1107.        *{  ISO 8859/5-DIS  Latin/Cyrillic alphabet
  1108.          *{  ISO 8859/6-1987 Latin/Arabic alphabet
  1109.            *{  ISO 8859/7-1987 Latin/Greek alphabet
  1110.              *{  ISO 8859/8-DIS  Latin/Hebrew alphabet
  1111.                *{  ISO 8884 DIS  Keyboard layout for multiple Latin-alphabet lan
  1112. guages           *{  ISO 9036-1987 Arabic 7-bit coded character set for informat
  1113. ion interchange    *{
  1114.                      *{  (DIS : Draft International Standard; DP : Draft Proposa
  1115. l)                     *{1
  1116.                          *{  Correspondence between ISO and ECMA standards
  1117.                            *{    ISO    ECMA    Registration number of escape se
  1118. quence (ISO 2375)            *{   8859/1    94    100
  1119.                                *{   8859/2    94    101
  1120.                                  *{   8859/3    94    109
  1121.                                    *{   8859/4    94    110
  1122.                                      *{   8859/5   113    111
  1123.                                        *{   8859/6   114    127
  1124.                                          *{   8859/7   118    126
  1125.                                            *{   8859/8   121    138
  1126.                                              *{
  1127.                                                *{  National Standards
  1128.                                                  *{
  1129.                                                    *{  ANSI X3.04-1977 Code for
  1130. Information Interchange                              *{ 1GOST 19767-74--GOST 197
  1131. 69-74, GOST 13052-74                                   *{ 1Main\ v\yislitel'n\e
  1132. , sistem\ obrabotki i apparatura peredayi dann\h         *{  (to be withdrawn, a
  1133. nd replaced by a new version)                              *{  CAS  GB 2312-80 C
  1134. oded Chinese graphic character set for                       *{               in
  1135. formation interchange                                          *{  JIS  C 6226-1
  1136. 983 Japanese graphic character set for                           *{
  1137.   information interchange                                          *{
  1138.                                                                      *{  Some li
  1139. tterature                                                              *{
  1140.                                                                          *{  C.
  1141. E. Mackenzie, Coded Character sets, History and Development, 1980          *{  J
  1142. oan M. Smith, Transmitting Text, Ass. for Lit. and Ling. Computing,          *{
  1143.        Bulletin, Vol. 11, no. 2, 1983                                          
  1144. \INMR06
  1145. 24-Mar-88 13:55:41-EST,4716;000000000001
  1146. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1147. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 24 Mar 88 13:55:35-EST
  1148. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 24 Mar 88 13:50:49 EDT
  1149. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1150.  6006; Thu, 24 Mar 88 13:50:47 EDT
  1151. Received: by BITNIC (Mailer X1.24) id 3461; Thu, 24 Mar 88 13:43:58 EDT
  1152. Date:         Thu, 24 Mar 88 11:36:38 EST
  1153. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  1154.               <ISO8859@JHUVM>
  1155. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  1156.               <ISO8859@JHUVM>
  1157. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  1158. Subject:      List of Character Coding Standards
  1159. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1160.  
  1161. Enclosed is a list of character set standards I received from MOSGLA @ HLERUL2.
  1162. Dear list users
  1163.                               _________
  1164.  
  1165. ECMA standards, which are generally identical with the corresponding
  1166. ones from ISO, can be ordered from: ECMA, 114 Rue du Rhone, CH-1204,
  1167. Geneve, Switzerland.
  1168. The following is a rather comprehensive list of everything available.
  1169.  
  1170.  
  1171.   INTERNATIONAL STANDARDS FOR CHARACTER CODES AND RELATED SUBJECTS
  1172.  
  1173.   ISO 646-1983  ISO 7-bit coded character set for information interchange
  1174.   ISO 2022-1986 ISO 7-bit and 8-bit coded character sets -
  1175.                Code extension techniques
  1176.   ISO 2047-1975 Graphical representations for the control characters of
  1177.                the 7-bit coded character set
  1178.   ISO 2375-1985 Procedure for the registration of escape sequences
  1179.   ISO 4873-1985 8-bit code for information interchange -
  1180.                Structure and rules for implementation
  1181.   ISO 5426-1983 Extension of the Latin alphabet coded character set for
  1182.                bibliographic information interchange
  1183.   ISO 5428-1984 Greek alphabet coded character set for
  1184.                bibliographic information interchange
  1185.   ISO 6429 DIS  ISO 7-bit and 8-bit coded character sets -
  1186.                additional control functions for character-imaging devices
  1187.   ISO 6862 DIS  Mathematical coded character set for
  1188.                bibliographic information interchange
  1189.   ISO 6937   Coded character sets for text communication
  1190.   ISO 6937/1-1983 General Introduction
  1191.   ISO 6937/2-1987 Latin alphabetic and non-alphabetic graphic characters
  1192.   ISO 6937/3 DIS  Control functions for page-image format
  1193.   ISO 6937/4 DP   Text-processible format
  1194.   ISO 6937/5 DP   Scientific and technical graphic characters
  1195.   ISO 6937/6 DP   Publishing and box drawing graphic characters
  1196.   ISO 6937/7 DIS  Greek graphic characters    (to be withdrawn)
  1197.   ISO 6937/8 DIS  Cyrillic graphic characters (to be withdrawn)
  1198.   ISO 7350 DIS  Text communication -
  1199.                registration of graphic character subrepertoires
  1200.   ISO 8859   8-bit single byte coded graphic characters
  1201.   ISO 8859/1-1987 Latin alphabet no. 1
  1202.   ISO 8859/2-1987 Latin alphabet no. 2
  1203.   ISO 8859/3-DIS  Latin alphabet no. 3
  1204.   ISO 8859/4-DIS  Latin alphabet no. 4
  1205.   ISO 8859/5-DIS  Latin/Cyrillic alphabet
  1206.   ISO 8859/6-1987 Latin/Arabic alphabet
  1207.   ISO 8859/7-1987 Latin/Greek alphabet
  1208.   ISO 8859/8-DIS  Latin/Hebrew alphabet
  1209.   ISO 8884 DIS  Keyboard layout for multiple Latin-alphabet languages
  1210.   ISO 9036-1987 Arabic 7-bit coded character set for information interchange
  1211.  
  1212.   (DIS : Draft International Standard; DP : Draft Proposal)
  1213.  
  1214.   Correspondence between ISO and ECMA standards
  1215.     ISO    ECMA    Registration number of escape sequence (ISO 2375)
  1216.    8859/1    94    100
  1217.    8859/2    94    101
  1218.    8859/3    94    109
  1219.    8859/4    94    110
  1220.    8859/5   113    111
  1221.    8859/6   114    127
  1222.    8859/7   118    126
  1223.    8859/8   121    138
  1224.  
  1225.   National Standards
  1226.  
  1227.   ANSI X3.04-1986 7-bit ASCII Code for Information Interchange
  1228.   ANSI X3.26      Punched Card Standard (ref. for IBM ASCII-EBCDIC translation)
  1229.   ANSI X3.41      7-bit ASCII character extensions, corresponds to ISO 2022
  1230.   ANSI X3.134.2   (proposed) 8-bit ASCII, corresponds to ISO 8859-1
  1231.  
  1232.   GOST 19767-74--GOST 19769-74, GOST 13052-74
  1233.   Main\ v\yislitel'n\e, sistem\ obrabotki i apparatura peredayi dann\h
  1234.   (to be withdrawn, and replaced by a new version)
  1235.   CAS  GB 2312-80 Coded Chinese graphic character set for
  1236.                information interchange
  1237.   JIS  C 6226-1983 Japanese graphic character set for
  1238.                information interchange
  1239.  
  1240.   Some literature
  1241.  
  1242.   C. E. Mackenzie, Coded Character sets, History and Development, 1980
  1243.  
  1244.   Joan M. Smith, Transmitting Text, Ass. for Lit. and Ling. Computing,
  1245.         Bulletin, Vol. 11, no. 2, 1983
  1246. 25-Mar-88 02:53:09-EST,2918;000000000001
  1247. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1248. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 25 Mar 88 02:53:01-EST
  1249. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 25 Mar 88 02:53:18 EDT
  1250. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1251.  6884; Fri, 25 Mar 88 02:53:16 EDT
  1252. Received: by BITNIC (Mailer X1.24) id 9708; Fri, 25 Mar 88 02:48:06 EDT
  1253. Date:         Fri, 25 Mar 88 08:37:11 +0100
  1254. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  1255.               <ISO8859@JHUVM>
  1256. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  1257.               <ISO8859@JHUVM>
  1258. From:         "Alain FONTAINE (Postmaster - NAD)" <FNTA80%BUCLLN11.BITNET@CUVMA.COLUMBIA.EDU>
  1259. Subject:      Re: ISO (ASCII) to EBCDIC Standards
  1260. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1261.  
  1262. I've followed the discussion, and tried  to keep up with all remarks and
  1263. corrections...  As a  result, I've  produced the  two following  tables,
  1264. which are at least complete and  coherent. This still does not mean that
  1265. they are completely right. Any help would be appreciated.     /AF
  1266.  
  1267. P.S. they are in REXX syntax because I used REXX to check the consistency..
  1268.  
  1269. /* EBCDIC -> ASCII */
  1270. asc8859 = '000102039C09867F978D8E0B0C0D0E0F'x||,
  1271.           '101112139D8508871819928F1C1D1E1F'x||,
  1272.           '80818283840A171B88898A8B8C050607'x||,
  1273.           '909116939495960498999A9B14159E1A'x||,
  1274.           '20A0E2E4E0E1E3E5E7F1A22E3C282B7C'x||,
  1275.           '26E9EAEBE8EDEEEFECDF21242A293BAC'x||,
  1276.           '2D2FC2C4C0C1C3C5C7D1A62C255F3E3F'x||,
  1277.           'F8C9CACBC8CDCECFCC603A2340273D22'x||,
  1278.           'D8616263646566676869ABBBF0FDFEB1'x||,
  1279.           'B06A6B6C6D6E6F707172AABAE6B8C6A4'x||,
  1280.           'B57E737475767778797AA1BFD0DDDEAE'x||,
  1281.           '5EA3A5B7A9A7B6BCBDBE5B5DAFA8B4D7'x||,
  1282.           '7B414243444546474849ADF4F6F2F3F5'x||,
  1283.           '7D4A4B4C4D4E4F505152B9FBFCF9FAFF'x||,
  1284.           '5CF7535455565758595AB2D4D6D2D3D5'x||,
  1285.           '30313233343536373839B3DBDCD9DA9F'x
  1286. /* ASCII -> EBCDIC */
  1287. ebc8859 = '00010203372D2E2F1605250B0C0D0E0F'x||,
  1288.           '101112133C3D322618193F271C1D1E1F'x||,
  1289.           '405A7F7B5B6C507D4D5D5C4E6B604B61'x||,
  1290.           'F0F1F2F3F4F5F6F7F8F97A5E4C7E6E6F'x||,
  1291.           '7CC1C2C3C4C5C6C7C8C9D1D2D3D4D5D6'x||,
  1292.           'D7D8D9E2E3E4E5E6E7E8E9BAE0BBB06D'x||,
  1293.           '79818283848586878889919293949596'x||,
  1294.           '979899A2A3A4A5A6A7A8A9C04FD0A107'x||,
  1295.           '202122232415061728292A2B2C090A1B'x||,
  1296.           '30311A333435360838393A3B04143EFF'x||,
  1297.           '41AA4AB19FB26AB5BDB49A8A5FCAAFBC'x||,
  1298.           '908FEAFABEA0B6B39DDA9B8BB7B8B9AB'x||,
  1299.           '6465626663679E687471727378757677'x||,
  1300.           'AC69EDEEEBEFECBF80FDFEFBFCADAE59'x||,
  1301.           '4445424643479C485451525358555657'x||,
  1302.           '8C49CDCECBCFCCE170DDDEDBDC8D8EDF'x
  1303. 25-Mar-88 05:16:23-EST,7033;000000000001
  1304. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1305. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 25 Mar 88 05:16:15-EST
  1306. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 25 Mar 88 05:16:30 EDT
  1307. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1308.  6911; Fri, 25 Mar 88 05:16:29 EDT
  1309. Received: by BITNIC (Mailer X1.24) id 0258; Fri, 25 Mar 88 05:10:17 EDT
  1310. Date:         Fri, 25 Mar 88 10:52:20 +0100
  1311. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  1312.               <ISO8859@JHUVM>
  1313. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  1314.               <ISO8859@JHUVM>
  1315. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  1316. Subject:      IBM official translate tables
  1317. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1318.  
  1319. I've obtained from IBM the following translate tables, so-said official.
  1320. They apply to CECP 500 vs IBM PC cp850 or cp437.
  1321. I may ask for CECP 037 and ISO8859 as well if anyone is interested.
  1322. I'll "batch the orders" and post the answer to the list.
  1323. Any comment?
  1324.  
  1325. -------------------------------------------------------------------------
  1326.  
  1327.      FROM: INTERNATL    697/500   TO:   PC           980/850
  1328.  
  1329.      ---------------------------------------------------------------
  1330.      -0  -1  -2  -3  -4  -5  -6  -7  -8  -9  -A  -B  -C  -D  -E  -F
  1331.      ---------------------------------------------------------------
  1332. 0-   00  01  02  03  DC  09  C3  9F  CA  B2  D5  0B  0C  0D  0E  0F
  1333. 1-   10  11  12  13  DB  DA  08  C1  18  19  C8  F2  1C  1D  1E  1F
  1334. 2-   C4  B3  C0  D9  BF  0A  17  1B  B4  C2  C5  B0  B1  05  06  07
  1335. 3-   CD  BA  16  BC  BB  C9  CC  04  B9  CB  CE  DF  14  15  FE  1A
  1336. 4-   20  FF  83  84  85  A0  C6  86  87  A4  5B  2E  3C  28  2B  21
  1337. 5-   26  82  88  89  8A  A1  8C  8B  8D  E1  5D  24  2A  29  3B  5E
  1338. 6-   2D  2F  B6  8E  B7  B5  C7  8F  80  A5  DD  2C  25  5F  3E  3F
  1339. 7-   9B  90  D2  D3  D4  D6  D7  D8  DE  60  3A  23  40  27  3D  22
  1340. 8-   9D  61  62  63  64  65  66  67  68  69  AE  AF  D0  EC  E7  F1
  1341. 9-   F8  6A  6B  6C  6D  6E  6F  70  71  72  A6  A7  91  F7  92  CF
  1342. A-   E6  7E  73  74  75  76  77  78  79  7A  AD  A8  D1  ED  E8  A9
  1343. B-   BD  9C  BE  FA  B8  F5  F4  AC  AB  F3  AA  7C  EE  F9  EF  9E
  1344. C-   7B  41  42  43  44  45  46  47  48  49  F0  93  94  95  A2  E4
  1345. D-   7D  4A  4B  4C  4D  4E  4F  50  51  52  FB  96  81  97  A3  98
  1346. E-   5C  F6  53  54  55  56  57  58  59  5A  FD  E2  99  E3  E0  E5
  1347. F-   30  31  32  33  34  35  36  37  38  39  FC  EA  9A  EB  E9  7F
  1348.  
  1349.      ---------------------------------------------------------------
  1350.  
  1351.  
  1352.      FROM: PC           980/850   TO:   INTERNATL    697/500
  1353.  
  1354.      ---------------------------------------------------------------
  1355.      -0  -1  -2  -3  -4  -5  -6  -7  -8  -9  -A  -B  -C  -D  -E  -F
  1356.      ---------------------------------------------------------------
  1357. 0-   00  01  02  03  37  2D  2E  2F  16  05  25  0B  0C  0D  0E  0F
  1358. 1-   10  11  12  13  3C  3D  32  26  18  19  3F  27  1C  1D  1E  1F
  1359. 2-   40  4F  7F  7B  5B  6C  50  7D  4D  5D  5C  4E  6B  60  4B  61
  1360. 3-   F0  F1  F2  F3  F4  F5  F6  F7  F8  F9  7A  5E  4C  7E  6E  6F
  1361. 4-   7C  C1  C2  C3  C4  C5  C6  C7  C8  C9  D1  D2  D3  D4  D5  D6
  1362. 5-   D7  D8  D9  E2  E3  E4  E5  E6  E7  E8  E9  4A  E0  5A  5F  6D
  1363. 6-   79  81  82  83  84  85  86  87  88  89  91  92  93  94  95  96
  1364. 7-   97  98  99  A2  A3  A4  A5  A6  A7  A8  A9  C0  BB  D0  A1  FF
  1365. 8-   68  DC  51  42  43  44  47  48  52  53  54  57  56  58  63  67
  1366. 9-   71  9C  9E  CB  CC  CD  DB  DD  DF  EC  FC  70  B1  80  BF  07
  1367. A-   45  55  CE  DE  49  69  9A  9B  AB  AF  BA  B8  B7  AA  8A  8B
  1368. B-   2B  2C  09  21  28  65  62  64  B4  38  31  34  33  B0  B2  24
  1369. C-   22  17  29  06  20  2A  46  66  1A  35  08  39  36  30  3A  9F
  1370. D-   8C  AC  72  73  74  0A  75  76  77  23  15  14  04  6A  78  3B
  1371. E-   EE  59  EB  ED  CF  EF  A0  8E  AE  FE  FB  FD  8D  AD  BC  BE
  1372. F-   CA  8F  1B  B9  B6  B5  E1  9D  90  BD  B3  DA  FA  EA  3E  41
  1373.  
  1374.      ---------------------------------------------------------------
  1375.  
  1376.  
  1377.      FROM: INTERNATL    697/500   TO:   PC           919/437
  1378.  
  1379.      ---------------------------------------------------------------
  1380.      -0  -1  -2  -3  -4  -5  -6  -7  -8  -9  -A  -B  -C  -D  -E  -F
  1381.      ---------------------------------------------------------------
  1382. 0-   00  01  02  03  DC  09  C3  9F  CA  B2  D5  0B  0C  0D  0E  0F
  1383. 1-   10  11  12  13  DB  DA  08  C1  18  19  C8  F2  1C  1D  1E  1F
  1384. 2-   C4  B3  C0  D9  BF  0A  17  1B  B4  C2  C5  B0  B1  05  06  07
  1385. 3-   CD  BA  16  BC  BB  C9  CC  04  B9  CB  CE  DF  F4  F5  FE  1A
  1386. 4-   20  FF  83  84  85  A0  C6  86  87  A4  5B  2E  3C  28  2B  21
  1387. 5-   26  82  88  89  8A  A1  8C  8B  8D  E1  5D  24  2A  29  3B  5E
  1388. 6-   2D  2F  B6  8E  B7  B5  C7  8F  80  A5  DD  2C  25  5F  3E  3F
  1389. 7-   BD  90  D2  D3  D4  D6  D7  D8  DE  60  3A  23  40  27  3D  22
  1390. 8-   BE  61  62  63  64  65  66  67  68  69  AE  AF  D0  EC  E7  F1
  1391. 9-   F8  6A  6B  6C  6D  6E  6F  70  71  72  A6  A7  91  F7  92  CF
  1392. A-   E6  7E  73  74  75  76  77  78  79  7A  AD  A8  D1  ED  E8  A9
  1393. B-   9B  9C  9D  FA  B8  15  14  AC  AB  F3  AA  7C  EE  F9  EF  9E
  1394. C-   7B  41  42  43  44  45  46  47  48  49  F0  93  94  95  A2  E4
  1395. D-   7D  4A  4B  4C  4D  4E  4F  50  51  52  FB  96  81  97  A3  98
  1396. E-   5C  F6  53  54  55  56  57  58  59  5A  FD  E2  99  E3  E0  E5
  1397. F-   30  31  32  33  34  35  36  37  38  39  FC  EA  9A  EB  E9  7F
  1398.  
  1399.      ---------------------------------------------------------------
  1400.  
  1401.  
  1402.      FROM: PC           919/437   TO:   INTERNATL    697/500
  1403.  
  1404.      ---------------------------------------------------------------
  1405.      -0  -1  -2  -3  -4  -5  -6  -7  -8  -9  -A  -B  -C  -D  -E  -F
  1406.      ---------------------------------------------------------------
  1407. 0-   00  01  02  03  37  2D  2E  2F  16  05  25  0B  0C  0D  0E  0F
  1408. 1-   10  11  12  13  B6  B5  32  26  18  19  3F  27  1C  1D  1E  1F
  1409. 2-   40  4F  7F  7B  5B  6C  50  7D  4D  5D  5C  4E  6B  60  4B  61
  1410. 3-   F0  F1  F2  F3  F4  F5  F6  F7  F8  F9  7A  5E  4C  7E  6E  6F
  1411. 4-   7C  C1  C2  C3  C4  C5  C6  C7  C8  C9  D1  D2  D3  D4  D5  D6
  1412. 5-   D7  D8  D9  E2  E3  E4  E5  E6  E7  E8  E9  4A  E0  5A  5F  6D
  1413. 6-   79  81  82  83  84  85  86  87  88  89  91  92  93  94  95  96
  1414. 7-   97  98  99  A2  A3  A4  A5  A6  A7  A8  A9  C0  BB  D0  A1  FF
  1415. 8-   68  DC  51  42  43  44  47  48  52  53  54  57  56  58  63  67
  1416. 9-   71  9C  9E  CB  CC  CD  DB  DD  DF  EC  FC  B0  B1  B2  BF  07
  1417. A-   45  55  CE  DE  49  69  9A  9B  AB  AF  BA  B8  B7  AA  8A  8B
  1418. B-   2B  2C  09  21  28  65  62  64  B4  38  31  34  33  70  80  24
  1419. C-   22  17  29  06  20  2A  46  66  1A  35  08  39  36  30  3A  9F
  1420. D-   8C  AC  72  73  74  0A  75  76  77  23  15  14  04  6A  78  3B
  1421. E-   EE  59  EB  ED  CF  EF  A0  8E  AE  FE  FB  FD  8D  AD  BC  BE
  1422. F-   CA  8F  1B  B9  3C  3D  E1  9D  90  BD  B3  DA  FA  EA  3E  41
  1423.  
  1424.      ---------------------------------------------------------------
  1425. 25-Mar-88 06:44:36-EST,5111;000000000001
  1426. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1427. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 25 Mar 88 06:44:26-EST
  1428. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 25 Mar 88 06:44:39 EDT
  1429. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1430.  6929; Fri, 25 Mar 88 06:44:37 EDT
  1431. Received: by BITNIC (Mailer X1.24) id 0723; Fri, 25 Mar 88 06:39:10 EDT
  1432. Date:         Fri, 25 Mar 88 12:27:00 MET
  1433. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  1434.               <ISO8859@JHUVM>
  1435. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  1436.               <ISO8859@JHUVM>
  1437. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  1438. Subject:      cp37/500
  1439. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1440.  
  1441.  
  1442. Dear List Subscribers
  1443. It took me some time to compare Mr. Gilbert's conversion table with
  1444. others in use. It is simply not true that there was no "official"
  1445. translate table before CP37 and CP500 turned up. There is one in VS
  1446. FORTRAN Language and Library Reference, SC26-4119-1, Appendix C, p.
  1447. 365-370. There is even a Government Standard, exactly identical to this,
  1448. but is not a US one, it is found in GOST 19768 of the USSR, issued in
  1449. 1974. This is the thing I use as the most authoritative reference. The
  1450. combination of this table with ISO 8859-1 produces a unique code page,
  1451. which I implemented using IEBIMAGE at our STC/Siemens laser printer
  1452. (working in IBM 3800 compatibility mode), based on DOTR. I did the same
  1453. thing with ISO 8859-2 for Eastern European languages. The only
  1454. concession to present practice was the exchange of "logical not" with
  1455. "circumflex", and a shift between right square bracket, exclamation
  1456. sign, and vertical bar. I see no reason why to invent a new table for
  1457. ISO 80-FF, creating further confusion. It could even involve changing
  1458. the VS FORTRAN compiler. CP37 and CP500 ought to be withdrawn.
  1459. Yours faithfully, Johan van Wingen
  1460.  
  1461. This is the table (in ISO format, IBM mirrors this sometimes):
  1462.  
  1463.   CONVERSION FROM ASCII TO EBCDIC
  1464.  
  1465.      0. 1. 2. 3. 4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  1466.  
  1467.  .0  00 10 40 F0 7C D7 79 97 20 30 41 58 76 9F B8 DC
  1468.  
  1469.  .1  01 11 4F F1 C1 D8 81 98 21 31 42 59 77 A0 B9 DD
  1470.  
  1471.  .2  02 12 7F F2 C2 D9 82 99 22 1A 43 62 78 AA BA DE
  1472.  
  1473.  .3  03 13 7B F3 C3 E2 83 A2 23 33 44 63 80 AB BB DF
  1474.  
  1475.  .4  37 3C 5B F4 C4 E3 84 A3 24 34 45 64 8A AC BC EA
  1476.  
  1477.  .5  2D 3D 6C F5 C5 E4 85 A4 15 35 46 65 8B AD BD EB
  1478.  
  1479.  .6  2E 32 50 F6 C6 E5 86 A5 06 36 47 66 8C AE BE EC
  1480.  
  1481.  .7  2F 26 7D F7 C7 E6 87 A6 17 08 48 67 8D AF BF ED
  1482.  
  1483.  .8  16 18 4D F8 C8 E7 88 A7 28 38 49 68 8E B0 CA EE
  1484.  
  1485.  .9  05 19 5D F9 C9 E8 89 A8 29 39 51 69 8F B1 CB EF
  1486.  
  1487.  .A  25 3F 5C 7A D1 E9 91 A9 2A 3A 52 70 90 B2 CC FA
  1488.  
  1489.  .B  0B 27 4E 5E D2 4A 92 C0 2B 3B 53 71 9A B3 CD FB
  1490.  
  1491.  .C  0C 1C 6B 4C D3 E0 93 6A 2C 04 54 72 9B B4 CE FC
  1492.  
  1493.  .D  0D 1D 60 7E D4 5A 94 D0 09 14 55 73 9C B5 CF FD
  1494.  
  1495.  .E  0E 1E 4B 6E D5 5F 95 A1 0A 3E 56 74 9D B6 DA FE
  1496.  
  1497.  .F  0F 1F 61 6F D6 6D 96 07 1B E1 57 75 9E B7 DB FF
  1498.  
  1499.  
  1500.   CONVERSION FROM EBCDIC TO ASCII
  1501.  
  1502.      0. 1. 2. 3. 4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  1503.  
  1504.  .0  00 10 80 90 20 26 2D BA C3 CA D1 D8 7B 7D 5C 30
  1505.  
  1506.  .1  01 11 81 91 A0 A9 2F BB 61 6A 7E D9 41 4A 9F 31
  1507.  
  1508.  .2  02 12 82 16 A1 AA B2 BC 62 6B 73 DA 42 4B 53 32
  1509.  
  1510.  .3  03 13 83 93 A2 AB B3 BD 63 6C 74 DB 43 4C 54 33
  1511.  
  1512.  .4  9C 9D 84 94 A3 AC B4 BE 64 6D 75 DC 44 4D 55 34
  1513.  
  1514.  .5  09 85 0A 95 A4 AD B5 BF 65 6E 76 DD 45 4E 56 35
  1515.  
  1516.  .6  86 08 17 96 A5 AE B6 C0 66 6F 77 DE 46 4F 57 36
  1517.  
  1518.  .7  7F 87 1B 04 A6 AF B7 C1 67 70 78 DF 47 50 58 37
  1519.  
  1520.  .8  97 18 88 98 A7 B0 B8 C2 68 71 79 E0 48 51 59 38
  1521.  
  1522.  .9  8D 19 89 99 A8 B1 B9 60 69 72 7A E1 49 52 5A 39
  1523.  
  1524.  .A  8E 92 8A 9A 5B 5D 7C 3A C4 CB D2 E2 E8 EE F4 FA
  1525.  
  1526.  .B  0B 8F 8B 9B 2E 24 2C 23 C5 CC D3 E3 E9 EF F5 FB
  1527.  
  1528.  .C  0C 1C 8C 14 3C 2A 25 40 C6 CD D4 E4 EA F0 F6 FC
  1529.  
  1530.  .D  0D 1D 05 15 28 29 5F 27 C7 CE D5 E5 EB F1 F7 FD
  1531.  
  1532.  .E  0E 1E 06 9E 2B 3B 3E 3D C8 CF D6 E6 EC F2 F8 FE
  1533.  
  1534.  .F  0F 1F 07 1A 21 5E 3F 22 C9 D0 D7 E7 ED F3 F9 FF
  1535.  
  1536.  
  1537.   DEVIATIONS: ASCII TO EBCDIC           EBCDIC TO ASCII     UNPRINTABLE
  1538.                                                                       |
  1539.              21 5D 5E 09 0A 1C FF      4F 5A 5F 15 17 22 24 35 E1 FF  |
  1540.   STANDARD   4F 5A 5F 05 25 1C 00      21 5D 5E 85 87 82 84 95 9F FF
  1541.   PDP-HASP   5A 5F 4F 05 25 22 07      5E 21 5D 00 00 1C 00 1E 00 7F 00
  1542.   VAX-SNA    4F 5A 5F 40 25 1C 3F      21 5D 5E 5C 5C 5C 5C 5C 5C 5C 5C
  1543.   VAX SUBR   4F 5A 5F 05 25 1C FF      21 5D 5E 0A 1B 5C 5C 5C 5C FF 5C
  1544.   VTAM       4F 5A 5F 05 15 1C DELETED 21 5D 5E 0A 00 5C 00 5C 00 7F 00
  1545.   TSO-KERMIT 4F 5A 5F 05 25 1C 00      21 5D 5E 0A 1B 00 00 00 00 00 00
  1546.   PC-3278 AD 5A 4F 5F 05 25 1C 00      5D 21 5E 85 87 82 84 95 9F FF
  1547.  
  1548.   EARN/BITNET
  1549.  A  21 5B 5D 7C 85 8A D5 E3 E5 FC   E  15 2A 4A 4F 5A 6A AD BB BD FC
  1550.  E  5A AD BD 4F 2A 15 BB 4A FC 6A   A  8A 85 E3 7C 21 FC 5B D5 5D E5
  1551.  
  1552.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  1553.      Mail to                                :
  1554.  P. O. Box 486,  2300AL Leiden, Netherlands :
  1555.  
  1556. 25-Mar-88 07:31:19-EST,2977;000000000001
  1557. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1558. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 25 Mar 88 07:31:13-EST
  1559. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 25 Mar 88 07:31:28 EDT
  1560. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1561.  6971; Fri, 25 Mar 88 07:31:27 EDT
  1562. Received: by BITNIC (Mailer X1.24) id 0909; Fri, 25 Mar 88 07:26:10 EDT
  1563. Date:         Fri, 25 Mar 88 11:12:03 +0100
  1564. Reply-To:     Discussion list for ASCII/EBCDIC character set related issues
  1565.               <ISO8859@JHUVM>
  1566. Sender:       Discussion list for ASCII/EBCDIC character set related issues
  1567.               <ISO8859@JHUVM>
  1568. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  1569. Subject:      Re: ASCII/ISO/which EBCDIC? summary
  1570. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1571. In-Reply-To:  Message of Wed, 23 Mar 88 20:10:42 EST from <VM0A61@WVNVM>
  1572.  
  1573. >>My  experience  shows  that  BITNET is working  perfectly  as  it
  1574. >>stands. Are we going to let a chance messing up all that?
  1575. >
  1576. >I agree that this discussion be moved to the other list, but before
  1577. >I do I can't help but point out that the above statement that BITNET
  1578. >is "working perfectly" is one of the silliest things I have heard in
  1579. >a long time, and it is a shame because this was an otherwise
  1580. >fairly reasonable note.
  1581.  
  1582. These words ask for a public reply.
  1583.  
  1584. *From context*, the statement applies to ASCII/EBCDIC 7-bit codes translation
  1585. of mail (through gateways or retrieving stored data obtained through them)
  1586. and to receiving the same codes entered at EBCDIC terminals.
  1587.  
  1588. *My experience* shows that, for example, we've never had any problem sending
  1589. or receiving UUENCODEd or BOOed binary data, a good test because it uses every
  1590. possible ASCII code in a message. And that this translation matched everything
  1591. I could get my hands on. This is what threatens extension to 8 bits.
  1592. This experience might be limited to a subset of BITNET or of its use however.
  1593. This is why I have first queried the net to make up my mind. All I could hear
  1594. of was some "sometime somewhere somebody...".
  1595.  
  1596. I would have liked to evaluate that numerically by sending a simple form to
  1597. be filled by a random sample of BITNET sites. But I have no time to do this
  1598. and the questions to ask had to wait for some discussion first. Maybe after
  1599. a while of ISO8859 good thinking, someone could undertake the project...
  1600.  
  1601. That parity, uselessly reducing transmissions to 7 bits, is nonsense, that it
  1602. is a pity we have to use mail to send binary data, and that other things could
  1603. be better are all subjects I agree with but that were not the point of my
  1604. note.
  1605.  
  1606. But that the guy next door is suddenly typing hieroglyphs for brackets because
  1607. CECP 500 has fallen upon him and that multiplying 3 EBCDIC by 3 ASCII codes
  1608. sets gives us 9 translation tables pairs to choose from in the best case,
  1609. *that* is really silly.
  1610. 29-Mar-88 09:40:33-EST,5895;000000000001
  1611. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1612. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 29 Mar 88 09:40:21-EST
  1613. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 29 Mar 88 09:40:57 EDT
  1614. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1615.  4009; Tue, 29 Mar 88 09:40:55 EDT
  1616. Received: by BITNIC (Mailer X1.24) id 4916; Tue, 29 Mar 88 09:38:49 EDT
  1617. Date:         Tue, 29 Mar 88 15:30:00 MET
  1618. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1619. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1620. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  1621. Subject:      Accented Letters
  1622. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1623.  
  1624.  
  1625. Dear List Subscribers
  1626. The discussion of character codes shows that problems can be classified:
  1627. 1. Problems with differing conversion tables EBCDIC/ISO8859.
  1628. 2. Problems with available characters.
  1629.  
  1630. As for 1, there is the traditional table, as found in the FORTRAN
  1631. manual. BITNET table deviates from this at a few places in transferring
  1632. codes in ASCII 00-7F (left part). For details see my previous letter.
  1633. Then there is the table based on CP37/500 with a complete different
  1634. right part (80-FF).
  1635. As for 2, there is the national character problem, which can only be
  1636. solved using the character sets of ISO 8859.
  1637. Both issues should not be confused with each other.
  1638. Distributing the ISO 8859 characters over a code page cannot be done in
  1639. an arbitrary way. As soon as you choose the conversion table the result
  1640. is fixed, and conversely, every code page created fixes its conversion
  1641. table. So it is up to your choice to determine what is convenient.
  1642.  
  1643. From the information I received I tried to reconstruct the CP500 code
  1644. page, SH35-0053 not being available here. Then I compared it with the
  1645. FORTRAN code page, as derived from the FORTRAN conversion table. Which
  1646. do you prefer? Are the differences really worth the confusion?
  1647. Yours faithfully, Johan van Wingen
  1648.  
  1649.  
  1650.   A COMPARISON OF FACILITIES FOR LETTERS WITH DIACRITICS
  1651.  
  1652.   Notation
  1653.   (descriptions taken from ISO 6937-2, additions between parentheses)
  1654.   /  acute accent
  1655.   \  grave accent
  1656.   ^  circumflex accent
  1657.   %  diaeresis (umlaut, trema)
  1658.   ~  tilde
  1659.   *  caron (hachek)
  1660.   #  breve (Rumanian a)
  1661.   #  double acute accent (Hungarian o,u)
  1662.   @  ring (above: a,u)
  1663.   @  dot (above: z)
  1664.   =  macron (upper line)
  1665.   $  cedilla (c,s,t)
  1666.   $  ogonek (Polish a,e)
  1667.   $  (barred: o, eth, thorn)
  1668.   _  (underline, fraction)
  1669.   &  (ligature: ae,oe,sz)
  1670.   ?  (dot under)
  1671.  
  1672.   REPRESENTATION OF LETTERS FROM ISO 8859-1 WITH FORTRANTABLE
  1673.  
  1674.      4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  1675.  
  1676.  .0              ~A ^E ~N $O           0
  1677.  .1               a  j    \U  A  J     1
  1678.  .2               b  k  s /U  B  K  S  2
  1679.  .3               c  l  t ^U  C  L  T  3
  1680.  .4               d  m  u %U  D  M  U  4
  1681.  .5               e  n  v /Y  E  N  V  5
  1682.  .6           \A  f  o  w $P  F  O  W  6
  1683.  .7           /A  g  p  x &s  G  P  X  7
  1684.  .8           ^A  h  q  y \a  H  Q  Y  8
  1685.  .9               i  r  z /a  I  R  Z  9
  1686.  .A              %A %E \O ^a \e ^i ^o /u
  1687.  .B              @A \I /O ~a /e %i ~o ^u
  1688.  .C              &A /I ^O %a ^e $d %o %u
  1689.  .D              $C ^I ~O @a %e ~n    /y
  1690.  .E              /E %I %O &a \i \o $o $p
  1691.  .F              \E $D    $c /i /o \u %y
  1692.  
  1693.  
  1694.  
  1695.   REPRESENTATION OF LETTERS FROM ISO 8859-1 WITH CP500 TABLE
  1696.  
  1697.      4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  1698.  
  1699.  .0              $o $O
  1700.  .1     /e    /E  a  j        A  J     1
  1701.  .2  ^a ^e ^A ^E  b  k  s     B  K  S  2
  1702.  .3  %a %e %A %E  c  l  t     C  L  T  3
  1703.  .4  \a \e \A \E  d  m  u     D  M  U  4
  1704.  .5  /a /i /A /I  e  n  v     E  N  V  5
  1705.  .6  ~a ^i ~A ^I  f  o  w     F  O  W  6
  1706.  .7  @a %i @A %I  g  p  x     G  P  X  7
  1707.  .8  $c \i $C \I  h  q  y     H  Q  Y  8
  1708.  .9  ~n &s ~N     i  r  z     I  R  Z  9
  1709.  .A
  1710.  .B                          ^o ^u ^O ^U
  1711.  .C              $d &a $D    %o %u %O %U
  1712.  .D              /y    /Y    \o \u \O \U
  1713.  .E              $p &A $P    /o /u /O /U
  1714.  .F                          ~o %y ~O
  1715.  
  1716.  
  1717.   REPRESENTATION OF LETTERS FROM ISO 8859-2 WITH FORTRAN TABLE
  1718.  
  1719.      4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  1720.  
  1721.  .0           $s #A $E /N *R           0
  1722.  .1     *S    *t  a  j    @U  A  J     1
  1723.  .2  $A $S    /z  b  k  s /U  B  K  S  2
  1724.  .3     *T $l     c  l  t #U  C  L  T  3
  1725.  .4  $L       *z  d  m  u %U  D  M  U  4
  1726.  .5        *l @z  e  n  v /Y  E  N  V  5
  1727.  .6  *L *Z /s /R  f  o  w $T  F  O  W  6
  1728.  .7  /S @Z    /A  g  p  x &s  G  P  X  7
  1729.  .8        *s ^A  h  q  y /r  H  Q  Y  8
  1730.  .9     $a        i  r  z /a  I  R  Z  9
  1731.  .A              %A %E *N ^a *c ^i ^o /u
  1732.  .B              /L *E /O #a /e *d #o #u
  1733.  .C              /C /I ^O %a $e $d %o %u
  1734.  .D              $C ^I #O /l %e /n    /y
  1735.  .E              /E *D %O /c *e *n *r $t
  1736.  .F     /Z       *C $D    $c /i /o @u
  1737.  
  1738.  
  1739.  
  1740.   REPRESENTATION OF LETTERS FROM ISO 8859-2 WITH CP500 TABLE
  1741.  
  1742.      4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  1743.  
  1744.  .0           *r *R *l
  1745.  .1     /e    /E  a  j    $L  A  J     1
  1746.  .2  ^a $e ^A $E  b  k  s *L  B  K  S  2
  1747.  .3  %a %e %A %E  c  l  t     C  L  T  3
  1748.  .4  /r *c /R *C  d  m  u *S  D  M  U  4
  1749.  .5  /a /i /A /I  e  n  v     E  N  V  5
  1750.  .6  #a ^i #A ^I  f  o  w /s  F  O  W  6
  1751.  .7  /l *d /L *D  g  p  x /z  G  P  X  7
  1752.  .8  $c *e $C *E  h  q  y     H  Q  Y  8
  1753.  .9  /n &s /N     i  r  z *z  I  R  Z  9
  1754.  .A        /S    *T $S $A       *s    $l
  1755.  .B              *t $s @z    ^o #u ^O #U
  1756.  .C              $d /c $D @Z %o %u %O %U
  1757.  .D              /y    /Y    *n @u *N @U
  1758.  .E              $T /C $T    /o /u /O /U
  1759.  .F     /Z       $a    *Z    #o %y #O
  1760.  
  1761.  
  1762.  
  1763.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  1764.      Mail to                                :
  1765.  P. O. Box 486,  2300AL Leiden, Netherlands :
  1766.  
  1767. 29-Mar-88 12:30:03-EST,3713;000000000001
  1768. Mail-From: SY.FDC created at 29-Mar-88 12:29:58
  1769. Date: Tue 29 Mar 88 12:29:58-EST
  1770. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1771. Subject: For the digest...
  1772. To: sy.christine@CU20B.COLUMBIA.EDU
  1773. Message-ID: <12386232998.151.SY.FDC@CU20B.COLUMBIA.EDU>
  1774.  
  1775. Date: Tue, 29 Mar 88 17:54:11 +0200
  1776. From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  1777. Subject: Proposed Kermit Rule for Extended ASCII
  1778. Keywords: ASCII, Extended ASCII, ISO8859, Translation Tables
  1779.  
  1780. In the process of implementing extended (national) characters transfer
  1781. between micros and IBM mainframes, I came to the conclusion that, for the
  1782. sole IBM PC, I had to build at least 9 different tables in order to support 3
  1783. EBCDIC tables (traditional and CECP 500 and 037) x 3 "ASCII" tables (table
  1784. 437, table 850 and ISO 8859/1).  Not considering ISO for the Macintosh, I've
  1785. still got 3 tables to build for the IBM host and, if I endeavoured Mac to IBM
  1786. PC conversion, 3 more tables or so.
  1787.  
  1788. When we add more machine types, it all looks like the wheat grains on a
  1789. chessboard problem. Not counting the added difficulty of knowing which is to
  1790. translate what in what.
  1791.  
  1792. Doesn't it look reasonable that each party deal with its own code problems
  1793. and that the Kermit protocol rule what character code standard travels on the
  1794. line as it already does for restricted ASCII? (That applies for text mode
  1795. only, of course).
  1796.  
  1797. I think ISO8859/1 is there for the purpose, with the added bonus that it
  1798. keeps the 80-9F range free (but available for additionals if needed).  This
  1799. range is indeed the one that adds the largest overhead to 8th bit quoting.
  1800.  
  1801. Similarly, ISO8859/1 should be used for terminal mode communication, at least
  1802. as an option. This just involves byte to byte conversion in 8-bit wide mode
  1803. and an additional SO/SI escaping (ISO 2022) mechanism in 7-bit mode.
  1804.  
  1805. The same applies to non-Latin group users who should use their own 8859/x
  1806. version similarly.
  1807.  
  1808. [Ed. - Kermit was designed (in 1981) on the assumption that 7-bit ASCII was
  1809. the most common representation for text files.  In ISO terms, 7-bit ASCII
  1810. (with control-character prefixing, etc) is the presentation-layer "transfer
  1811. syntax" for text files.  But now we have a proliferation of 8-bit ASCII
  1812. character sets -- in addition to the IBM PC's, Apple's, and DEC's various
  1813. incompatible extended ASCIIs, we have the ISO 8859 variations, and then the
  1814. various translations between them and EBCDIC.
  1815.  
  1816. In Japan, they face a similar problem.  There are numerous character sets --
  1817. Katakana, Hiragana, Romaji, Kanji -- and there are numerous "standards" for
  1818. representing each of these (especially Kanji) in the computer.  Their
  1819. solution was to modify the Kermit programs they use to "SET FILE TYPE TEXT
  1820. <name of standard>", putting the onus on the user to specify not only the
  1821. file type but also the encoding.
  1822.  
  1823. As Andre suggest, it would be best if there were one single transfer syntax
  1824. for text files (at least for languages whose alphabets can be respresented in
  1825. 8-bit characters), and each Kermit program translate between that and its own
  1826. local code set.  Is ISO 8859/1-1987 ("Latin Alphabet 1", = ANSI X3.134.2, =
  1827. ECMA 94) a choice that won't offend anyone?  The lower half (characters 0-127)
  1828. corresponds to US ASCII (ANSI X3.4).
  1829.  
  1830. If this proposal results in controversy, then does anyone have a simple
  1831. alternative proposal?  Meanwhile, it seems wise to build user-defined
  1832. translation tables into Kermit programs, such as we have in MS-Kermit 2.30,
  1833. and IBM mainframe Kermit 4.0.  In MS-Kermit, it might also be desirable to
  1834. extend the translation mechanism to file transfer, in some general,
  1835. user-controllable way.  Opinions?]
  1836. -------
  1837. 30-Mar-88 08:54:30-EST,1543;000000000001
  1838. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1839. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 30 Mar 88 08:54:23-EST
  1840. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 30 Mar 88 08:54:43 EDT
  1841. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1842.  5247; Wed, 30 Mar 88 08:54:41 EDT
  1843. Received: by BITNIC (Mailer X1.24) id 4652; Wed, 30 Mar 88 08:53:46 EDT
  1844. Date:         Tue, 29 Mar 88 20:48:32 EST
  1845. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1846. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1847. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  1848. Subject:      RE:       Turning the Tables:  A Standards Problem
  1849. X-To:         ASCII/EBCDIC character set related issues
  1850.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  1851. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1852.  
  1853. Well, it may or may not be just history from the "old" ASCII
  1854. Standard, but they are ALL that way.  Every one.  The current
  1855. ASCII standard, the ANSI standards corresponding to ISO8859, the
  1856. control code standards, and so on and so forth.  And, yes, ISO
  1857. has done "the same thing".  And so has CCITT, where you will
  1858. find character codes expressed as column/row.
  1859.  
  1860. Perhaps it is really an artifact, not of "old" ASCII, but of
  1861. "old" FORTRAN, which also addressed things in this order.
  1862.  
  1863. In any event, better just get used to it; a "correction" would
  1864. cause chaos.
  1865.  
  1866. 31-Mar-88 10:15:54-EST,3967;000000000001
  1867. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1868. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 31 Mar 88 10:15:51-EST
  1869. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 31 Mar 88 10:16:32 EDT
  1870. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1871.  6913; Thu, 31 Mar 88 10:16:29 EDT
  1872. Received: by BITNIC (Mailer X1.24) id 9858; Thu, 31 Mar 88 10:15:22 EDT
  1873. Date:         Thu, 31 Mar 88 16:58:17 GMT
  1874. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1875. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1876. From:         Matthias Melcher <$28%DHDURZ1.BITNET@CUVMA.COLUMBIA.EDU>
  1877. Subject:      Code Page Nationalities
  1878. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1879.  
  1880. Dear list subscribers,
  1881.  
  1882. the comparison of code pages can be simplified when we just think of
  1883. them having a nationality or a "mother tongue", and some of them
  1884. knowing foreign languages.
  1885.  
  1886. The mother tongue of a code page is determined by one half
  1887. of its character repertoire, a kernel which could be
  1888. - entered on display terminals
  1889. - coded with 7 bits
  1890. - mapped onto the kernels of code pages of other nationalities simply
  1891.   by replacing the 14 "national use characters"
  1892. That is the left half of an ASCII code page, and in EBCDIC the areas
  1893. roundabout 4A-7F, 81-A9 and C1-F9.
  1894.  
  1895. The difference of CP 037 and CP 500 is not "data processing
  1896. oriented" vs. "word processing oriented" (Ed Hart), but:
  1897. - CP 037 has US nationality
  1898. - CP 500 has nationality "International", like 3274 Interface Code 14,
  1899.   and ISO 8859 itself.
  1900.  
  1901. In that sense, "US"-ASCII must be regarded as International rather
  1902. than US, and there is no real US ASCII code page (with e.g.
  1903. Cent-sign in the left half).
  1904.  
  1905.  
  1906. In the times when code pages did not speak foreign languages
  1907. translations had to be done
  1908. - either ignoring the graphic representations
  1909.   (e.g. exclamation point <-> right bracket, circumflex <-> logical-not)
  1910. - or with foul compromizes
  1911.   (e.g. taking brackets AD/BD from TN-chain, but not braces 7B/8B).
  1912.  
  1913. Today, if we want to respect the graphics  we have the choice:
  1914. (a) Map International ASCII (=ISO 8859) to International EBCDIC
  1915.     (= CP 500), i.e. kernel onto kernel (mother tongue) and extension
  1916.     onto extension (foreign languages).
  1917. (b) Map International ASCII to national EBCDICs, e.g. US (= CP 037),
  1918.     thus intermixing kernel and extension.
  1919.  
  1920. We must be aware that choice (b) logically consists of two translations:
  1921. ASCII to EBDCIC and International to US, and this brings a lot of
  1922. conceptual complexity and confusions which, in the long run, make
  1923. communication cumbersome.
  1924.  
  1925. Choice (a), on the other hand, bears many migration problems,
  1926. especially as long as IBM has not completed its CECP support (like
  1927. teaching PL/1 to recognize B0 as logical not, or teaching the 3174 to
  1928. show and accept thorns).
  1929.  
  1930.  
  1931. But I think this all will come. For example, the 3174 CECP RPQ 8Q0566
  1932. has been already shown at CeBIT Hannover fair and will be
  1933. released as soon as some software corequisites are done.
  1934.  
  1935. In the meantime, its not too difficult two deal with Code Page 500.
  1936. Even on a US 3278 you can edit most of the CECP characters:
  1937. just using CMS set output / set input with the old 5A-device codes.
  1938. (We can send you a copy of the EXEC).
  1939.  
  1940. I don't know which IBM representatives still recommend CP 037 to
  1941. US users. The official recommendation explicitly states
  1942. "Standardizing on a single code page for the entire network ..."
  1943. "IBM recommends that if this is going to be done that the customer
  1944. standardize using the International CECP code page." (8Q0566 announcmt)
  1945.  
  1946. EARN/BITNET is an international network. So I think the code page
  1947. has to be international as well, and every site must be able to
  1948. send and accept mail in this code page.
  1949.  
  1950. Mit freundlichen Gruen - Matthias Melcher
  1951.  8-Apr-88 12:09:29-EST,2329;000000000001
  1952. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1953. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 8 Apr 88 12:09:26-EST
  1954. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 08 Apr 88 12:07:40 EDT
  1955. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1956.  6032; Fri, 08 Apr 88 12:07:37 EDT
  1957. Received: by BITNIC (Mailer X1.25) id 6853; Fri, 08 Apr 88 12:06:10 EDT
  1958. Date:         Fri, 8 Apr 88 11:38:12 EDT
  1959. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1960. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1961. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  1962. Subject:      Re: Code Page Nationalities
  1963. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  1964. In-Reply-To:  Your message of Thu, 31 Mar 88 16:58:17 GMT
  1965.  
  1966. The ISO 8859-1 character set is Latin Alphabet number 1 and has most characters
  1967. needed for Western Europe. Eastern Europe uses a different version of ISO 8859.
  1968.  
  1969. In discussing the differences between Code Pages 500 and 37, please
  1970. understand that they contain exactly the same set of characters as ISO 8859-1.
  1971. They were designed that way.  However, the code points for most of the
  1972. characters are different - each is a different code.  Code Page 37 is a 192
  1973. character superset of the US/Canada English Data Processing 96-character
  1974. code except for (square) brackets.  Similarly, the 96 character subset of
  1975. Code Page 500 characters match the ISO 646 / ANSI X3.4 characters.
  1976.  
  1977. When translating characters from ISO 8859-1 codes to Code Page 500, for
  1978. example, I believe that the characters should match.  If the translation
  1979. were from ISO 8859-1 to Code Page 37, the translation would be different.
  1980. However, if we were considering another variation, ISO 8859-2, then I would
  1981. expect IBM to provide another code page with the same character set as ISO
  1982. 8859-2.  I would expect that the IBM Code Page corresponding to ISO 8859-2
  1983. might require a different translation than the one defined by ISO 8859-1 to
  1984. Code Page 500.  If however, IBM would standardize on one code page for Latin
  1985. Alphabet number 1, then the ISO 8859-x translation to IBM code page xxx
  1986. could be held constant.  That would be desirable.
  1987.  
  1988. Ed Hart
  1989.  8-Apr-88 23:15:10-EST,2676;000000000001
  1990. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  1991. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 8 Apr 88 23:15:04-EST
  1992. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 08 Apr 88 23:13:14 EDT
  1993. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  1994.  6853; Fri, 08 Apr 88 23:13:12 EDT
  1995. Received: by BITNIC (Mailer X1.25) id 4371; Fri, 08 Apr 88 23:07:15 EDT
  1996. Date:         Fri, 8 Apr 88 12:10:00 EST
  1997. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1998. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  1999. From:         Barry D Gates <GATES%MAINE.BITNET@CUVMA.COLUMBIA.EDU>
  2000. Subject:      Something I came across out in netnews-land...
  2001. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2002.  
  2003. I thought the ISO8859 list might be interested in what this person has to say.
  2004. I do not necessarily support the persons views, nor do I reject them
  2005. (I'm not an expert on this, just an interested party).  I'm interested in
  2006. any opinions folks may have on this.  I noticed from previous postings here
  2007. that what we are generally referring to as ISO8859 is really ISO8859/1 for
  2008. the Western European Nations.  Does ISO intend to come out with a codepage
  2009. for the languages this poster lists in his mailfile?
  2010. Also are there any other EBCDIC mappings for the other codepages?
  2011.  
  2012. Anyway, here is the person's posting.  It was brought on in response to
  2013. a posting on "interNational Language Support" on the HP computers I believe.
  2014. The NLS has nothing to do with the SP5 IBM oddity, but more with what we are
  2015. talking about here.
  2016.  
  2017. ------ Forwarded MAIL from comp.std.internat: International Standards Newsgroup
  2018.  
  2019. From: bas+@andrew.cmu.edu (Bruce Sherwood)
  2020. Newsgroups: comp.std.internat
  2021. Subject: Re: International Language Support
  2022. Message-ID: <8WKYiky00UgCM600g4@andrew.cmu.edu>
  2023. Date: 6 Apr 88 15:16:00 GMT
  2024. Organization: Carnegie Mellon University
  2025. Lines: 14
  2026. In-Reply-To: <691@kuling.UUCP>
  2027.  
  2028. To repeat a major complaint I have about ISO 8859 (which I'm distressed to see
  2029. is a component of NLS):
  2030.  
  2031. This standard is based on nations rather than languages.  So the West European
  2032. version doesn't handle Welsh or Catalan or Esperanto (which don't have their
  2033. own nations).
  2034.  
  2035. The older standard, ISO 6937, was based on forty Latin-alphabet-using
  2036. languages, not on nations.  So it handled just about everything (except for
  2037. Vietnamese) including Welsh and Catalan and Esperanto.
  2038.  
  2039. ISO 8859 is a MAJOR step backward in terms of linguistic equality.
  2040.  
  2041. Bruce Sherwood
  2042. --------- End of forwarded mail.
  2043.  9-Apr-88 16:19:02-EST,2716;000000000001
  2044. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2045. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Sat 9 Apr 88 16:18:59-EST
  2046. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Sat, 09 Apr 88 16:17:19 EDT
  2047. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2048.  7347; Sat, 09 Apr 88 16:17:18 EDT
  2049. Received: by BITNIC (Mailer X1.25) id 8422; Sat, 09 Apr 88 16:16:23 EDT
  2050. Date:         Sat, 9 Apr 88 16:08:00 EDT
  2051. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2052. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2053. From:         Chris Tanner <01696%AECLCR.BITNET@CUVMA.COLUMBIA.EDU>
  2054. Subject:      ISO 6937 and ISO 8859
  2055. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2056.  
  2057. This is a few remarks about ISO 6937 and ISO 8859 in reply to a recent mailing
  2058. decrying ISO 8859. I am not an expert in this field, but from the little I know,
  2059. here goes.
  2060.  
  2061. ISO 6937 and ISO 8859 were developed by 2 different groups within
  2062. ISO-IEC JTC1/SC2 for different purposes. ISO 6937 is designed for printers.
  2063. It creates accented characters by the providing accented symbols which are
  2064. actually no spaceing characters (these are found in the G2 set). Forinstance,
  2065. e acute is created by the acute sign character plus e. It also includes the
  2066. oe dipthong. This sort of thing is fine for printing but not very good for
  2067. character string comparison and sorting.
  2068.  
  2069. ISO 8859 is designed for use in programs (character string comparison and
  2070. sorting). It provides separate characters for all the accented characters.
  2071. It does not provide the oe dipthong since this is treated in string
  2072. comparisons as O + E. There are 8 parts to ISO 8859. If people are interested,
  2073. I can post to the list the title of each part, and the languages covered.
  2074.  
  2075. SC2 has been asked by its member countires to achieve a harmonization between
  2076. these 2 standards. This has resulted in a project proposal (Document JTC1 N 156)
  2077. (balloting closes June 2, 1988) which is accompanied with a paper entitled
  2078. Co-ordination of the Development of ISO 6937 and ISO 8859. It describes the
  2079. purposes of ISO 6937, ISO 8859 and ISO 4873 (which specifies the rules and
  2080. structure for 8 bit codes), the problems with these standards, and it proposes
  2081. a structure for a family of graphic character sets for 8 bit coding. Hopefully
  2082. this project will achieve its aim.
  2083.  
  2084. By the way, the library/ information services people have a coding standard
  2085. of their own which is similiar to ISO 6937 in some ways.
  2086.  
  2087. Chris Tanner
  2088. Atomic Energy of Canada
  2089.  
  2090. My views are my own and not the views of my employer.
  2091. 11-Apr-88 11:59:23-EST,1872;000000000001
  2092. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2093. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 11 Apr 88 11:59:18-EST
  2094. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 11 Apr 88 11:30:37 EDT
  2095. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2096.  8303; Mon, 11 Apr 88 11:30:35 EDT
  2097. Received: by BITNIC (Mailer X1.25) id 8501; Mon, 11 Apr 88 11:29:52 EDT
  2098. Date:         Mon, 11 Apr 88 17:14:00 MET
  2099. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2100. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2101. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  2102. Subject:      6937/8859
  2103. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2104.  
  2105. Dear list subscribers
  2106. Mr. Sherwood's remarks about ISO 8859 compared with ISO 6937 are unfair
  2107. and untrue. In ISO 8859-3 one finds characters for Catalan, Esperanto,
  2108. Galician, Maltese and Turkish. Lappish is in ISO8859-4. ECMA-94 contains
  2109. all of ISO 8859-1,2,3,4 together. ISO 6937 is NOT a single byte coded
  2110. character set.
  2111. As a sequel to Mr. Tanner's comments, I attended the meeting of SC2/WG3
  2112. responsible for 6937 and 8859, 16-17 March 1988 in Paris. Work on
  2113. 6937-5,6 will be discontinued, and DIS 6937-7,8 withdrawn. There will be
  2114. ISO 8859-9, Latin alphabet no. 5, with Icelandic eth, thorn and /y
  2115. replaced by Turkish g breve, s cedilla and dotless i / dotted capital I.
  2116. The first draft of ISO XYZ (the harmonization) will appear in May.
  2117. ISO 5426, the bibliographic coded character set is not (yet) included in
  2118. the harmonization.
  2119. Yours faithfully, Johan van Wingen
  2120.  
  2121.  
  2122.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  2123.      Mail to                                :
  2124.  P. O. Box 486,  2300AL Leiden, Netherlands :
  2125.  
  2126. 11-Apr-88 13:19:29-EST,1919;000000000001
  2127. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2128. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 11 Apr 88 13:19:27-EST
  2129. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 11 Apr 88 13:17:50 EDT
  2130. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2131.  8608; Mon, 11 Apr 88 13:17:49 EDT
  2132. Received: by BITNIC (Mailer X1.25) id 0917; Mon, 11 Apr 88 13:17:09 EDT
  2133. Date:         Mon, 11 Apr 88 12:46:17 EDT
  2134. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2135. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2136. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  2137. Subject:      Re: Something I came across out in netnews-land...
  2138. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2139. In-Reply-To:  Your message of Fri, 8 Apr 88 12:10:00 EST
  2140.  
  2141. The problem with ISO 6937 is that none of the computer manufacturers support
  2142. it.  ISO 6937 indeed has all of the accents and with it you can form many
  2143. characters.  ISO 6937 comes from CCITT and the standard is concerned with
  2144. teletext transmission.  However, the computer manufacturers found it
  2145. unacceptable because multiple bytes were used to form and store the characters.
  2146. For example, to form an "a" with a circumflex, you did something like:  strike
  2147. the accent, then backspace, then the character.  The manufacturers wanted to
  2148. represent each character with one code - not some with three.
  2149.  
  2150. ISO 8859-1 is also incomplete.  For example, it also lacks the
  2151. French "oe" diphthong.  ISO 8859-1 is a compromise standard.  I understand
  2152. that when the compromise was reached, and the chairman asked if any more
  2153. changes should be made, no one said anything; because if one started, then
  2154. everyone would have "just a little change" and we would still not have a
  2155. standard.
  2156.  
  2157. Ed Hart
  2158. 11-Apr-88 23:57:10-EST,7258;000000000001
  2159. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2160. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 11 Apr 88 23:57:07-EST
  2161. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 11 Apr 88 23:55:32 EDT
  2162. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2163.  9570; Mon, 11 Apr 88 23:55:31 EDT
  2164. Received: by BITNIC (Mailer X1.25) id 7817; Mon, 11 Apr 88 23:52:55 EDT
  2165. Date:         Mon, 11 Apr 88 10:56:34 CDT
  2166. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2167. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2168. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  2169. Subject:      Single or Multiple Tables for Multiple Character Sets?
  2170. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2171.  
  2172. If I understand his messages correctly, Johan van Wingen's main
  2173. objection to the late discussions is that they are working on the
  2174. assumption that equivalent graphics in different character sets
  2175. should be mapped to each other.  He objects that this would lead
  2176. to multiple, incompatible translate tables being required.
  2177.  
  2178. Edwin Hart voices the hope that IBM may be able to do for 8859
  2179. (in all its various parts) what they did for ISO 646 (in all its
  2180. various national manifestations):  set a translation or mapping
  2181. by comparing two character sets (e.g. CP 37 or CP 500 and ISO
  2182. 8859/1), and then define the various related EBCDIC code pages
  2183. by applying that mapping to the other parts of 8859.  (So a
  2184. Greek EBCDIC code page will result from applying the CP500-ISO8859/1
  2185. translation to ISO8859/7, and so on.)  That might not completely
  2186. answer Mr. van Wingen's concerns, but it would be handy.
  2187.  
  2188. I agree that it would be nice to keep the number of translate tables
  2189. down, where feasible.  But I fear that it's not feasible in the way
  2190. Mr. Hart suggests, and I have a number of problems with Mr. van Wingen's
  2191. idea that an arbitrary mapping should be defined, implemented *in
  2192. hardware* (!), and stuck to come hell or high water.
  2193.  
  2194. The fundamental question I have for anyone who will answer is:  If we
  2195. do not translate graphic-for-graphic, what is the point of translating?
  2196. Why not define our mapping as the one-to-one mapping in which each
  2197. hex code maps to itself?  Or, to protect the control-code areas,
  2198. why not just map
  2199.  
  2200.     ISO       EBCDIC
  2201.     0-1F      0-1F
  2202.     80-9F     20-3F
  2203.     20-7E     40-9E
  2204.     7F        FF
  2205.     A0-FE     A0-FE
  2206.     FF        9F
  2207.  
  2208. ?
  2209.  
  2210. Obviously, this is *not* repeat *not* a serious suggestion.  Why?
  2211. because it would do no one any good at all.  Similarly, applying the
  2212. mapping given in the back of the VS Fortran 2.1 manuals to either
  2213. ISO 8859/1 or any extended EBCDIC code page will give you code pages
  2214. that contain all the necessary characters, but in an arrangement that
  2215. no one at all supports.  What good would data like that do anyone?
  2216.  
  2217. The obvious desiderata for translate tables seem to be:
  2218.     - there should be as few as possible, preferably only one
  2219.     - they should translate characters correctly (i.e. graphic for
  2220.          graphic, with substitutions only where required)
  2221.     - they should preserve the collation sequence of the special
  2222.          characters or second alphabet in the code
  2223.  
  2224. Equally obvious, no two of these are compatible.  The US CECP
  2225. does not preserve the collating sequence of ISO 8859/1, the usual
  2226. EBCDIC version of the library character set does not preserve the
  2227. collating sequence of the ASCII version of the same set (why?!
  2228. does anyone know why?), and the mappings from ALA/ASCII to ALA/EBCDIC
  2229. are not compatible.  Similarly:  ISO 8859/7 will define a Greek
  2230. character set, and ISO 8859/8 a Hebrew character set.  Without having
  2231. seen either, I'll give ten to one odds against either set mapping
  2232. to the EBCDIC character sets for Greek and Hebrew with the same
  2233. translations as for 8859/1 and any IBM extended code page.
  2234.  
  2235.     ------------------------------------------------------------
  2236.  
  2237. What can be done?  I don't know the answers, but it seems obvious
  2238. that certain things *will* be done no matter what, and that others
  2239. *can* be done if we here will agree to do them.  I offer the following
  2240. observations as one person's tentative assessment of the facts,
  2241. probabilities, and hopes.
  2242.  
  2243. First:  if IBM can be persuaded to define one single EBCDIC for Western
  2244. Europe without country variations, as proposed (I think) in the SHARE
  2245. paper, they should do so.
  2246.  
  2247. Second:  a good character-to-character translation for one of the
  2248. IBM extended code pages (37, 500, or some CECP) to ISO 8859/1 is
  2249. going to be implemented a lot of places, along the lines of Howard
  2250. Gilbert's posting and the various revisions to it.  There is no point
  2251. in trying to stop this, but we should, as Mr. Gilbert says, all agree
  2252. and implement the same mapping, not different ones.  To implement
  2253. the same mapping, we should decide, even if IBM will not, on one
  2254. EBCDIC code page to take as basic or common.
  2255.  
  2256. Third:  at sites with library automation systems, a translate table for
  2257. the library character sets will also be implemented, or has already
  2258. been.  There is no point in stopping this, either, and it can't be
  2259. stopped anyway.  The hardware for library terminals defines the
  2260. required table very rigidly, and the library automation systems don't
  2261. have the flexibility to adjust to divergent translations.  (Notis, at
  2262. least, does know the difference between terminals with the library
  2263. character set and terminals without -- but it *knows* what the library
  2264. character set is, and cannot readily be told different.)
  2265.  
  2266. Fourth:  although some protocol converters have the memory required for
  2267. multiple translate tables (e.g. Series/1s), others (e.g. 7171s) don't.
  2268. Those running 7171s may be able to fit one or even two alternate
  2269. tables into their 7171s, but not more.  And we can only fit one:  the
  2270. rest of the room is taken up by local terminal types.  So we are going
  2271. to have to choose:  if you can only support ONE extended-character-set
  2272. translate table, which is it going to be?  Obviously, I think it
  2273. should be the one we here agree on, if we here can agree on one.
  2274. But for library machines, it's going to have to be the one defined
  2275. by the library code pages.
  2276.  
  2277. Fifth:  how can we support the other required translations if we cannot
  2278. put them into our protocol converters?  Matthias Melcher has the
  2279. best idea I've seen:  we use the CMS SET INPUT and SET OUTPUT commands
  2280. to simulate the translate tables actually needed by the users.  I have
  2281. only done a little work on this, but my experiments so far seem to
  2282. show that it can work.
  2283.  
  2284. SET INPUT and SET OUTPUT, on the other hand, only work for terminal
  2285. support.  For file transfer, we are going to have to have execs which
  2286. will post-process files uploaded with a given translate table, and
  2287. re-translate them into the proper code page.  That shouldn't be too
  2288. hard with Rexx under VM.  What other operating environments can do,
  2289. I don't know.
  2290.  
  2291. All of which is just one person's private opinion.  Please contradict
  2292. me where I am wrong.
  2293.  
  2294. Michael Sperberg-McQueen, University of Illinois at Chicago
  2295. 12-Apr-88 00:56:38-EST,6367;000000000001
  2296. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2297. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 00:56:33-EST
  2298. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 00:54:57 EDT
  2299. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2300.  9635; Tue, 12 Apr 88 00:54:55 EDT
  2301. Received: by BITNIC (Mailer X1.25) id 8067; Tue, 12 Apr 88 00:51:49 EDT
  2302. Date:         Mon, 11 Apr 88 23:31:39 EDT
  2303. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2304. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2305. From:         "Bryan, Jerry" <VM0A61%WVNVM.BITNET@CUVMA.COLUMBIA.EDU>
  2306. Subject:      Single or Multiple Tables for Multiple Character Sets?
  2307. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2308. In-Reply-To:  Message of 04/11/88 at 10:56:34 from U18189@UICVM
  2309.  
  2310. I have refrained from saying anything to this list so far, mostly
  2311. out of fear of saying something foolish.  It remains to be seen
  2312. how well founded that fear is, but I have finally decided to
  2313. put my two cents worth in anyway.  Speaking of which, I am writing this
  2314. on a PC running a VT100 emulator going into an IBM system
  2315. through a 7171 protocol converter, so I would have a hard time
  2316. putting in a cent sign (ignoring going into XEDIT hex mode), and
  2317. even it I did, many of you would have a hard time seeing the cent sign
  2318. on your terminal anyway, which I suppose is the whole point of this
  2319. list.  (Note to Europeans about American slang, "two cents worth" is
  2320. an opinion that may not be worth very much (or may  -- it is up
  2321. to the listener to decide).  The speaker is specifically disclaiming
  2322. any great profundity by using that phrase.)
  2323.  
  2324. Anyway, I have the feeling that there is too much emphasis on
  2325. EBCDIC-ASCII conversion and not enough emphasis on straightening
  2326. out EBCDIC and straightening out ASCII *as separate problems*.
  2327. The problems of EBCDIC are legion and well documented  --
  2328. the characters needed by C and PASCAL, national characters, etc.
  2329. ASCII has the same problems of missing characters and national
  2330. characters, and is even worse than EBCDIC in some ways because
  2331. it historically has been only a 7-bit code.  I offer the
  2332. following suggestions.
  2333.  
  2334.   1.  7-bit ASCII is a lost cause.  I realize there will be
  2335.       7-bit ASCII well into the next century, but we would
  2336.       do well to concentrate on 8-bit ASCII and getting it
  2337.       right.  One could argue that 8 bits are not enough,
  2338.       either, but 7 bits are hopeless.
  2339.  
  2340.   2.  Proper graphic-to-graphic mappings *within EBCDIC* and
  2341.       *within ASCII* are vital.  To the maximum extent possible,
  2342.       "proper" means "it looks the same, no matter what".  This
  2343.       goal really cannot be achieved in 8 bits, but it should
  2344.       be the goal, nevertheless.  I have had the opportunity which
  2345.       many Americans do not have of living in Europe.  It was
  2346.       irritating to receive messages from America and have characters
  2347.       not look right.  For that matter, even locally written
  2348.       things  --  SAS programs using dollar signs, for example  --
  2349.       looked awful.  I lived in Norway, which to the eye of an
  2350.       American has a curious looking alphabet, but one adapts.
  2351.       However, I once traveled to Germany and received messages from
  2352.       Norway in Norwegian on a German terminal.  My Norwegian
  2353.       is not all that good anyway, but it was doubly hard when
  2354.       many of the Norwegian characters were rendered as
  2355.       German characters.  Now, I have the same problem in America
  2356.       with Norwegian I receive here.  It seems to me that
  2357.       constancy of graphic rendering ought to be one of the highest,
  2358.       if not the highest goals, even though the goal cannot really
  2359.       be achieved in 8 bits if enough languages are considered.
  2360.       (For that matter, wouldn't it be nice to prepare something on
  2361.       a word processor with italics, send it out over BITNET, and
  2362.       have your italics characters appear as italics on the
  2363.       recipient's screen?)  The infamous problem of the square brackets
  2364.       on the TN print train is one of many examples inconstancy
  2365.       graphic rendering in EBCDIC, but as noted on this list and
  2366.       SHARE and SEAS papers, there are many others.
  2367.  
  2368.    3. Having said all that, rather at too much length, then let me
  2369.       further suggest that the same constancy of graphic rendering
  2370.       ought to be a goal of ASCII-EBCDIC conversion.  All the problems
  2371.       I mentioned in item 1 were EBCDIC-EBCDIC problems with
  2372.       communications between IBM VM/CMS systems. I also communicated
  2373.       between IBM and VAX systems in Norway and to the rest of BITNET,
  2374.       and the lack of graphic constancy gets even worse when ASCII
  2375.       is introduced into the equation.
  2376.  
  2377.    4. CLearly, graphic constancy implies that both ASCII and
  2378.       EBCDIC be as rich as possible in characters, and that the
  2379.       national character idea is not a very good idea.  An American
  2380.       dollar sign and a British pound sign, for example, need
  2381.       to be *standard* in ASCII and EBCDIC, but there are numerous
  2382.       other examples such as Western European umlauted, accented, and
  2383.       dipthonged characters.  Last I heard, the backslash was a
  2384.       national character  --  not so nice for the folks writing in C.
  2385.       However, all this still comes back to even 8 bits not being enough
  2386.       (Greek? Hebrew? Russian? Japanese? Arabic? etc.)
  2387.  
  2388.    5. Finally, graphic constancy implies that ASCII-EBCDIC conversions be
  2389.       fully reversible in both directions.  This is a part of my distaste
  2390.       for even dealing with 7-bit ASCII, where full conversion
  2391.       to/from EBCDIC is clearly impossible.
  2392.  
  2393. I will finish by noting that I have tangled with this problem
  2394. for years, and never cease to be amazed by how difficult it is.
  2395. It always *seems* like it ought to be easy, but somehow it
  2396. never is.  Something always gets you.  I have had users
  2397. editing IBM PL/1 code on a VAX, submitting batch to an
  2398. IBM machine, for example.  How do you handle that? Etc. etc.
  2399. etc., as many other people have pointed out.  Be suspicious
  2400. of anybody who doesn't understand why the problem is not
  2401. trivial, and who submits his own set of translate tables to
  2402. prove it.
  2403. 12-Apr-88 01:38:46-EST,1519;000000000001
  2404. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2405. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 01:38:41-EST
  2406. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 01:37:04 EDT
  2407. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2408.  9645; Tue, 12 Apr 88 01:37:03 EDT
  2409. Received: by BITNIC (Mailer X1.25) id 8504; Tue, 12 Apr 88 01:36:10 EDT
  2410. Date:         Mon, 11 Apr 88 22:27:00 PDT
  2411. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2412. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2413. From:         Leonard D Woren <LDW%USCMVSA.BITNET@CUVMA.COLUMBIA.EDU>
  2414. Subject:      Two more cents worth...
  2415. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2416.  
  2417. I'm a hardcore IBM bigot, but (with some help from coworkers), I've
  2418. come to the realization that EBCDIC's design doesn't make sense.  The
  2419. alphabet isn't contiguous, and numerals sort higher than letters.
  2420. ASCII makes certain programming tasks much simpler by not having
  2421. either of these defects, which date back to EBCDIC's ancestry in BCD,
  2422. which was based on punch card codes.
  2423.  
  2424. This isn't intended to start a war of words, so no flames please...
  2425. This is just mentioned as something to think about:  It may be heresy,
  2426. but maybe the answer is to add some characters to 8 bit ASCII and
  2427. throw out EBCDIC.  (Yes, I realize how much work a conversion would
  2428. be.)
  2429. 12-Apr-88 10:09:56-EST,1482;000000000000
  2430. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2431. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 10:09:52-EST
  2432. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 10:08:15 EDT
  2433. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2434.  0194; Tue, 12 Apr 88 10:08:11 EDT
  2435. Received: by BITNIC (Mailer X1.25) id 5511; Tue, 12 Apr 88 10:07:38 EDT
  2436. Date:         Tue, 12 Apr 88 09:11:02 EDT
  2437. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2438. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2439. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  2440. Subject:      Re: Two more cents worth...
  2441. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2442. In-Reply-To:  Your message of Mon, 11 Apr 88 22:27:00 PDT
  2443.  
  2444. Throw out EBCDIC?
  2445.  
  2446. That clearly is one of the options.  However, I believe that this would be
  2447. a larger conversion effort than to IBM Country Extended Code Pages like
  2448. 37 v1 or 500 v1.  Also, ISO 8859 does not have a contiguous alphabet because
  2449. the accented characters are in the upper half of the table so you have not
  2450. fixed one of the problems.  As soon as you have to be concerned with
  2451. accented characters and different collating sequences between countries,
  2452. then sorting becomes much more difficult (because it depends on both language
  2453. and country).
  2454.  
  2455. Ed Hart
  2456. 12-Apr-88 10:32:00-EST,4592;000000000001
  2457. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2458. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 10:31:57-EST
  2459. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 10:30:20 EDT
  2460. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2461.  0262; Tue, 12 Apr 88 10:30:18 EDT
  2462. Received: by BITNIC (Mailer X1.25) id 6198; Tue, 12 Apr 88 10:23:54 EDT
  2463. Date:         Tue, 12 Apr 88 09:08:44 EST
  2464. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2465. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2466. From:         Howard Gilbert <GILBERT%YALEVM.BITNET@CUVMA.COLUMBIA.EDU>
  2467. Subject:      Re: Single or Multiple Tables for Multiple Character Sets?
  2468. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2469. In-Reply-To:  Message of Mon, 11 Apr 88 10:56:34 CDT from <U18189@UICVM>
  2470.  
  2471. It is important in this discussion to realize that characters set issues
  2472. are not separable from the purpose of the data or communications.  Some
  2473. people mix the question of ASCII data and ASCII terminals without proper
  2474. thought.  When an ASCII terminal is connected to a protocol converter to
  2475. emulate a 3270 display, it is doing device emulation and not character
  2476. translation.  You press "A" and get an "A" on the screen and at the
  2477. host.  This is not a case of simple character translation of X'41'
  2478. into X'C1'. If you are in APL mode, sending X'41' will be translated
  2479. into APL alpha and lowercase "a" goes to uppercase.  If "A" is embedded
  2480. in an ESC sequence, it is interpreted and not translated.  What, after
  2481. all, is the "EBCDIC" meaning of PFK 4 (answer: it is an AID and not a
  2482. character).  Thus the objective of the 7171 is to translate the KEY
  2483. marked "A" into EBCDIC and not the code.  Turn on the Dvorak keyboard
  2484. mode and see what happens then.
  2485.  
  2486. This then follows into all of the remaining discussion.  We recently
  2487. were disturbed to note that Notis cannot find the city of Lodz in
  2488. Poland.  The problem is that the L is stroked (overtype L and /).
  2489. Stroke L is an ALA special alphabetic (along with D bar, O /, and
  2490. U hook). It has lowercase and uppercase forms.  The problem is that
  2491. ordinary library users do not have the special alphabetics and type
  2492. in ordinary "L" and Notis does not alias approximately homographic
  2493. alphabetic characters when doing a search of the database.  Note that
  2494. Notis will match on "odz" but not "Lodz".
  2495.  
  2496. Worse, our database is inconsistent in its handling of AE and OE
  2497. dipthongs. In a large number of cases they are typed as two characters
  2498. rather than using the dipthong code.  Again, database searching is
  2499. a problem.
  2500.  
  2501. There are around 500 characters (including all diacritically marked
  2502. forms) enumerated in the ANSI Z39.47-1985 standard for 35 Roman
  2503. languages and 51 other Romanized forms of languages.  Unfortunately,
  2504. this does not include the Hebrew, Cyrillic, and Arabic alphabets let
  2505. alone the Far East.
  2506.  
  2507. In its most general form, the problem cannot be solved.  It can be
  2508. solved FOR PARTICULAR APPLICATIONS.  Not all applications will find
  2509. the same solution optimal.  The purpose of the committee is to find
  2510. if there is one solution which is applicable to a large enough family
  2511. of applications to warrant general acceptance.
  2512.  
  2513. There are some who would argue that we are looking for a single common
  2514. translation.  I would prefer to believe that we are looking for a
  2515. single preferred translation for the bulk of use.  Just as ISO 8859
  2516. itself cannot replace ANSI Z39.47 and stay within the 8 bit limit of
  2517. available graphic code points, so any ASCII to EBCDIC translation which
  2518. is generally suitable for Data and Word Processing will still fail
  2519. to address math-technical, traditional TN (box drawing), APL, and
  2520. other common code problems.
  2521.  
  2522. I have separately held that we need to make an accompanying recommendation
  2523. that ASCII-EBCDIC (and EBCDIC-EBCDIC) be systematically addressed in
  2524. operating systems, data management subsystems, and communications
  2525. subsystems.  This will allow organizations to develop standardized
  2526. approaches to special needs which are not addressed by the common
  2527. translate table.
  2528.  
  2529. In essence, the idea of a single common table is too easy a way out
  2530. for IBM.  They have undertaken to define such a table on at least
  2531. two previous occasions.  Changing 512 bytes of table space is rather
  2532. easy.  Addressing the general question of codes, alphabets, collating
  2533. sequences, and the like is a much larger and expensive project.
  2534. 12-Apr-88 11:20:07-EST,3401;000000000001
  2535. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2536. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 11:20:04-EST
  2537. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 11:18:28 EDT
  2538. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2539.  0393; Tue, 12 Apr 88 11:18:26 EDT
  2540. Received: by BITNIC (Mailer X1.25) id 8035; Tue, 12 Apr 88 11:17:35 EDT
  2541. Date:         Tue, 12 Apr 88 10:14:19 EDT
  2542. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2543. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2544. From:         "Bryan, Jerry" <VM0A61%WVNVM.BITNET@CUVMA.COLUMBIA.EDU>
  2545. Subject:      Two more cents worth...
  2546. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2547. In-Reply-To:  Message of 04/12/88 at 09:11:02 from HART@APLVM
  2548.  
  2549. >Throw out EBCDIC?
  2550.  
  2551. >That clearly is one of the options.  However, I believe that this would be
  2552. >a larger conversion effort than to IBM Country Extended Code Pages like
  2553. >37 v1 or 500 v1.  Also, ISO 8859 does not have a contiguous alphabet because
  2554. >the accented characters are in the upper half of the table so you have not
  2555. >fixed one of the problems.  As soon as you have to be concerned with
  2556. >accented characters and different collating sequences between countries,
  2557. >then sorting becomes much more difficult (because it depends on both language
  2558. >and country).
  2559.  
  2560. Notwithstanding the problems listed above, I think that throwing out
  2561. EBCDIC might ultimately be the way to go, and I, too, am a lifelong
  2562. IBM bigot.  Throwing out EBCDIC right now is clearly unthinkable.
  2563. But consider the following.  Suppose this process of rationalizing
  2564. EBCDIC and ASCII succeeds to the point that there is a well defined
  2565. graphic to graphic mapping and also a well defined and fully reversible
  2566. 256 code point to 256 code point mapping established.  At that point,
  2567. aside from such trivial little problems as old data, old hardware,
  2568. sorting and collating sequences, etc., isn't the mapping between
  2569. code points and graphics somewhat arbitrary?  And if the mapping is
  2570. somewhat arbitrary, why not standardize on ASCII?
  2571.  
  2572. (An irrelevant aside on the sorting problem:  I do not know how the
  2573. accented or umlauted characters are sorted in German or French, for
  2574. example.  But Norwegian has one curious sorting problem which I think
  2575. no coding will solve completely.  The 29-th letter in the Norwegian
  2576. alphabet has two different graphics renderings.  One is as a double
  2577. "A"  -- "aa" in lower case and "AA" in upper case.  This is not a
  2578. dipthong, it is a *single* letter rendered as two characters.
  2579. The other graphics rendering
  2580. is as an "A" with a circle over it.  The "AA" must be sorted as if
  2581. it were a single letter in the 29-th position of the alphabet, even
  2582. though it is represented as two A's in computer memory.  The "A-with-
  2583. circle-over-it" is also sorted as if it were a single letter in the
  2584. 29-th position of the alphabet, and it is represented as a single
  2585. character in computer memory.  But the two distinct graphics renderings
  2586. must be maintained, so people's names will not only be spelled
  2587. correctly (either graphics rendering is a "correct" spelling),
  2588. but also will *look* right.  Are there any other sorting
  2589. problems which anybody knows about which are this severe?)
  2590. 12-Apr-88 12:14:23-EST,3118;000000000001
  2591. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2592. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 12:14:18-EST
  2593. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 12:12:36 EDT
  2594. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2595.  0518; Tue, 12 Apr 88 12:12:35 EDT
  2596. Received: by BITNIC (Mailer X1.25) id 9299; Tue, 12 Apr 88 12:11:50 EDT
  2597. Date:         Tue, 12 Apr 88 10:25:07 CDT
  2598. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2599. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2600. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  2601. Subject:      Code translation, device emulation, Notis, and Sorting
  2602. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2603.  
  2604. Howare Gilbert corrects, quite rightly, my oversimplified discussion
  2605. of the issues -- I will say that *within graphics strings* what is
  2606. happening sure seems like code translation to me, but he is right
  2607. that terminal emulation, data conversion, and so on are enough
  2608. different that we need to keep the differences present in mind as we
  2609. discuss them.
  2610.  
  2611. His example of searching problems is a good one, but lest a false
  2612. idea of Notis's capacities become widespread I should point out that
  2613. at UIC we have no trouble finding Lodz (or &odz, as it appears
  2614. in most of the records) by searching on 'lodz' -- our indexes never
  2615. contain diacritics.  Something other than Notis must be the problem.
  2616.  
  2617.  
  2618. Jerry Bryan inquires about analogues to Norwegian's 'aa' and 'a'
  2619. -- I know only of two.  The 'ij' digraph in Dutch is sorted
  2620. by itself, and the sharp s (esszett, w) of German sorts identically to
  2621. 'ss', without being (in Germany) the same thing at all.  (In
  2622. Switzerland, sharp s is no longer used, and some Swiss refuse to
  2623. believe me when I say it is still used in Germany and Austria.)
  2624. But diacritics and umlauts also cause problems that no diddling with
  2625. collation sequence can solve.  Lists of words in French and German
  2626. have, effectively, two sort keys:  they are sorted first on the
  2627. base characters without regard to the diacritics, and secondarily
  2628. on the diacritics.  (N.B. I am describing the practice taught me
  2629. in class, and the practice I observe in dictionaries.  Perhaps one
  2630. of the European list members can say how diacritics are typically
  2631. handled in data-processing sorts.)  The concordance packages built
  2632. for literary and linguistic study, therefore (e.g. WatCon and the
  2633. Oxford Concordance Package) have special sort facilities to prepare
  2634. sort keys for the sorting.  But N.B. Howard Gilbert is quite right
  2635. that sort sequence depends both on language and on country.  Umlauts
  2636. follow 'z' in Swedish and Modern Icelandic -- so books on Old
  2637. Norse printed there sort them after 'z'.  Books on Old Norse printed
  2638. in England and North America tend to sort them either that way or
  2639. in the German fashion.  Same goes for edh and thorn.
  2640.  
  2641. Michael Sperberg-McQueen, University of Illinois at Chicago
  2642. 12-Apr-88 13:02:15-EST,4248;000000000001
  2643. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2644. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 13:02:11-EST
  2645. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 13:00:32 EDT
  2646. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2647.  0610; Tue, 12 Apr 88 13:00:30 EDT
  2648. Received: by BITNIC (Mailer X1.25) id 0349; Tue, 12 Apr 88 12:58:48 EDT
  2649. Date:         Tue, 12 Apr 88 09:45:56 EST
  2650. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2651. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2652. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  2653. Subject:      Re: Two more cents worth...
  2654. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2655. In-Reply-To:  Message of Mon, 11 Apr 88 22:27:00 PDT from <LDW@USCMVSA>
  2656.  
  2657. I have no doubt you will catch a lot of flames from people who don't
  2658. understand the issues, I for one think you are on the right track.
  2659.  
  2660. As I see it the whole EBCDIC/ASCII/ISO8859 issue is really 4 closely
  2661. related problems:
  2662.  
  2663.     1) providing the means to input/output characters which are meaningful
  2664.        to the underlying host but are not available on the terminal,
  2665.        printer, etc. being used
  2666.  
  2667.     2) inter-site communication (ISO8859 should be adopted as the standard
  2668.        code for all such communication)
  2669.  
  2670.     3) ASCII-ISO8859 migration, while the people on this list may not be
  2671.        too concerned about this particular problem, some of us do have to
  2672.        'push from the other side' as well.  As yet, I don't know of any
  2673.        group which is pushing for UNIX support of ISO8859, for example.
  2674.  
  2675.     4) EBCDIC-ISO8859 migration - I'll discuss this at some length.
  2676.  
  2677. Suppose for a moment that EBCDIC code pages for each of the ISO8859 family
  2678. of codes were adopted, the end result would be that IBM's would be using
  2679. ISO8859 with a different collating sequence.  We would also be saddled with
  2680. the needless waste of 'translating' characters between the two indefinately.
  2681.  
  2682. I realize that there are MANY applications which currently use EBCDIC, and
  2683. I am not proposing to simply scrap them.  What I am proposing is that IBM
  2684. provide a means for users to migrate at their own pace from EBCDIC to
  2685. ISO8859.
  2686.  
  2687. There will no doubt be those who say why should IBM switch to ISO8859 why
  2688. doesn't everyone else switch to EBCDIC.  The answer is three-fold.  ISO8859
  2689. is a better code, it was designed for computers not inherited from TAB
  2690. equipment.  ISO8859 is an internationally accepted standard, it may not be
  2691. perfect but everyone has agreed to use it.  IBM itself is straddling the
  2692. EBCDIC-ASCII divide (PC, PS/2, AIX).  So, if we want a standard, ISO8859 is
  2693. the one to pick.
  2694.  
  2695. Few people are probably aware that when the 360 was first introduced bit 12
  2696. of the psw determined whether the machine was using ASCII or EBCDIC.  I
  2697. remember reading an interview with one of the developers a while ago in which
  2698. he stated that this feature was dropped because 'no-one wanted it'.  What a
  2699. pity, if the business DP centers of 20 years ago had had a bit more foresight
  2700. this whole mess might have been avoided.
  2701. (Actually, I think the reason users didn't want IBM's ASCII support had to do
  2702. with the way IBM defined ASCII - I came across an old copy of Principles of
  2703. Operation which describes it.  The characters themselves were pretty much as
  2704. they are now, but the bits were laid out strangely:  76X54321 where X was 0
  2705. if the character was < @ and 1 if > ?.)
  2706. IBM should introduce an EBCDIC/ISO8859 option.  Eventually EBCDIC would then
  2707. go the way of card readers and 7-track tapes, and future programmers would
  2708. be able to marvel at how quaint this whole situation was.  Even if it took
  2709. 20 years, eventually we would be rid of the problem.
  2710.  
  2711. If IBM does not migrate to ISO8859, how long will it be before there is a
  2712. mailing list to discuss the problems of having 2 collating sequences?
  2713.  
  2714. If IBM is going to migrate to ISO8859 then now is the time to start planning
  2715. for it.
  2716.  
  2717. A final question: is there any real benefit to having 2 distinct code
  2718. families which I have overlooked?
  2719. 12-Apr-88 13:28:02-EST,1883;000000000001
  2720. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2721. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 13:27:55-EST
  2722. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 13:26:10 EDT
  2723. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2724.  0654; Tue, 12 Apr 88 13:26:09 EDT
  2725. Received: by BITNIC (Mailer X1.25) id 0461; Tue, 12 Apr 88 13:06:41 EDT
  2726. Date:         Tue, 12 Apr 88 13:00:07 EDT
  2727. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2728. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2729. From:         "John F. Chandler" <PEPMNT%CFAAMP.BITNET@CUVMA.COLUMBIA.EDU>
  2730. Subject:      Re: Single or Multiple Tables for Multiple Character Sets?
  2731. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2732. In-Reply-To:  U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU message of Mon,
  2733.               11 Apr 88 10:56:34 CDT
  2734.  
  2735. I don't subscribe to this discussion list, but I was sent a copy of
  2736. this one posting.  My perspective is two-fold: file transfer and
  2737. connection of ASCII terminals to IBM mainframes.  In a way, the 2nd
  2738. is just a special case of the first -- there is a tremendous corpus of
  2739. files that have been typed in over the years.  I will restrain my
  2740. skepticism for the moment and assume that a single standard can be
  2741. (A) agreed upon in the present forum and (B) acted upon elsewhere.
  2742. That leads to my main point: having gone through this whole argument
  2743. in the context of CMS Kermit, I have come to the conclusion that, once
  2744. a site settles on a single translation scheme, that scheme should be
  2745. built into any and all file transfer mechanisms used there.  Kermit,
  2746. for example, offers a tailorable A-to-E table (on the mainframe side),
  2747. which can embody any mapping you care to define.
  2748. 12-Apr-88 14:15:11-EST,2194;000000000001
  2749. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2750. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 14:15:06-EST
  2751. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 14:13:28 EDT
  2752. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2753.  0808; Tue, 12 Apr 88 14:13:26 EDT
  2754. Received: by BITNIC (Mailer X1.25) id 1187; Tue, 12 Apr 88 14:12:27 EDT
  2755. Date:         Tue, 12 Apr 88 13:39:46 EDT
  2756. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2757. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2758. From:         "Bryan, Jerry" <VM0A61%WVNVM.BITNET@CUVMA.COLUMBIA.EDU>
  2759. Subject:      Two more cents worth...
  2760. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2761. In-Reply-To:  Message of 04/12/88 at 09:45:56 from KESICH@NYUCIMSA
  2762.  
  2763.  
  2764. >As I see it the whole EBCDIC/ASCII/ISO8859 issue is really 4 closely
  2765. >related problems:
  2766.  
  2767. .... text deleted....
  2768.  
  2769. >    2) inter-site communication (ISO8859 should be adopted as the standard
  2770. >       code for all such communication)
  2771.  
  2772. This is a most interesting suggestion.  It would mean, for example, and
  2773. if I interpret it correctly, that two IBM EBCDIC machines communicating
  2774. with each other would use ISO8859 rather than EBCDIC over the communications
  2775. path.  This sort of suggestion is philosophically in line with standards
  2776. emerging in other areas where there is an interchange standard for
  2777. graphics, for word-processing style text, for CAD/CAM drawings, etc.,
  2778. where the interchange standard does not dictate how the data is
  2779. stored in the computer, so long as the machine can convert from its
  2780. internal representation to the interchange standard and back.
  2781.  
  2782. If this idea were carried far enough, it could possibly become the
  2783. basis for a long term (30 year?) conversion plan to ISO8859 for
  2784. everything.  For example, one could view reading or writing to a tape
  2785. or a disk as an "interchange", so one could read or write an ISO8859
  2786. tape or disk into an EBCDIC machine or vice versa with smart controllers
  2787. performing an "interchange" rather than an I/O.
  2788. 12-Apr-88 17:25:50-EST,1620;000000000001
  2789. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2790. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 12 Apr 88 17:25:45-EST
  2791. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 12 Apr 88 17:23:54 EDT
  2792. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2793.  1089; Tue, 12 Apr 88 17:23:50 EDT
  2794. Received: by BITNIC (Mailer X1.25) id 3729; Tue, 12 Apr 88 17:23:03 EDT
  2795. Date:         Tue, 12 Apr 88 16:07:05 EST
  2796. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2797. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2798. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  2799. Subject:      Re: Two more cents worth...
  2800. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2801. In-Reply-To:  Message of Tue, 12 Apr 88 13:39:46 EDT from <VM0A61@WVNVM>
  2802.  
  2803. >>    2) inter-site communication (ISO8859 should be adopted as the standard
  2804. >>       code for all such communication)
  2805.  
  2806. > This is a most interesting suggestion.  It would mean, for example, and
  2807. > if I interpret it correctly, that two IBM EBCDIC machines communicating
  2808. > with each other would use ISO8859 rather than EBCDIC over the communications
  2809. > path.
  2810.  
  2811. In theory, yes they would use ISO8859.  In practice they could continue to
  2812. use EBCDIC between them so long as all data being passed through the link
  2813. between 3rd parties was correctly mapped from and then back to ISO8859.
  2814. But backbone network nodes could avoid all the translation overhead by
  2815. working strictly in ISO8859.
  2816. 13-Apr-88 17:56:19-EST,1818;000000000001
  2817. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2818. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 13 Apr 88 17:56:18-EST
  2819. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 13 Apr 88 17:54:42 EDT
  2820. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2821.  2584; Wed, 13 Apr 88 17:54:39 EDT
  2822. Received: by BITNIC (Mailer X1.25) id 7127; Wed, 13 Apr 88 17:53:41 EDT
  2823. Date:         Wed, 13 Apr 88 17:23:43 EDT
  2824. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2825. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2826. From:         "User Services, DCS Paul Henderson" <HENDERS%WATDCS.BITNET@CUVMA.COLUMBIA.EDU>
  2827. Subject:      Re: Two more cents worth...
  2828. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2829. In-Reply-To:  MAIL of Wed, 13 Apr 88 10:34:49 +0300
  2830.  
  2831. >To set the record straight, bit 12 of the PSW controlled the generation of the
  2832. >sign in the results of decimal arithmetic computations.  The bit was labelled
  2833. >ANSI (rather than ASCII) because the "standard" plus sign was X'A' and the
  2834. >minus sign X'B' rather than X'C' and X'D' respectively, which were IBM's
  2835.  
  2836. At the risk of sounding like a nit-picker -- I just happen to have a
  2837. Principles of Operation, Form A22-6821-7, dated September 1968.
  2838. On page 71 it discusses the PSW:
  2839.    ASCII(A): When bit 12 of the PSW is one, the codes preferred
  2840.    for the  USASCII-8 code  are generated for  decimal results.
  2841.    When the PSW  is zero, the codes preferred  for the extended
  2842.    binary-coded-decimal interchange code are generated.
  2843. Perhaps the meaning of the bit was changed to ANSI before it was dropped
  2844. but for some of us, it really was the ASCII bit.  We never used it either.
  2845. 14-Apr-88 09:33:27-EST,5133;000000000001
  2846. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2847. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 14 Apr 88 09:33:24-EST
  2848. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 14 Apr 88 09:31:51 EDT
  2849. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2850.  3213; Thu, 14 Apr 88 09:31:49 EDT
  2851. Received: by BITNIC (Mailer X1.25) id 3982; Thu, 14 Apr 88 09:30:24 EDT
  2852. Date:         Thu, 14 Apr 88 14:55:00 MET
  2853. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2854. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2855. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  2856. Subject:      national versions
  2857. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2858.  
  2859.  
  2860. Dear list subscribers
  2861.  
  2862. Let us stop discussing red herrings like "Throw out EBCDIC". If you
  2863. ever have attended a SHARE or SEAS meeting you ought to know what is
  2864. needed for putting a requirement to IBM.
  2865. Let us also stop using imprecise terminology, like ISO8859 without
  2866. further qualification, or ASCII meaning an 8-bit code. Because of this
  2867. Mr. Kesich's letter is incomprehensible to me. There is no single
  2868. ISO8859, and ASCII is not identical with ISO646, both being 7-bit codes.
  2869. 8-bit ASCII does not exist under this name.
  2870.  
  2871. The real problem for both EBCDIC and ISO is that of the unique graphic-
  2872. code correspondence. Risking to bore those who know, some little
  2873. tutorial is appropriate. First "ASCII".
  2874.  
  2875. ISO646 (1st ed. 1973, 2nd ed. 1983) specifies 7-bit codes for
  2876. characters. Of the 128 possible codes 33 are for control characters, one
  2877. for SPACE, and 94 for graphic characters. Of this last group 82 are
  2878. unique, 12 are left open. For completing the set defining a "national
  2879. version" of ISO646 is required. An International Reference Version
  2880. (IRV) is provided where none is preferred. ASCII is simply the US
  2881. National Version of ISO646. It differs only from IRV in having a $
  2882. instead of the currency sign. But German, Swedish, Danish/Norwegian and
  2883. others substitute accented letters at most of the 12 places. What does
  2884. this mean? If you send square brackets to Norway, they arrive as AE and
  2885. A-ring (braces as ae and a-ring). This practice puts a barrier between
  2886. the English and the non-English speaking world, caused by the number of
  2887. characters being limited to 94.
  2888.  
  2889. An 8-bit code could be a solution, by adding 96 codes. But even then,
  2890. not every character can be accomodated in a unique way. ISO 8859-1
  2891. provides 190 unique characters used in Western Europe. This shifts the
  2892. barrier to about the Iron Curtain, leaving Greece and Turkey at the
  2893. wrong side. Now, if you send a Turkish text from Ankara to Washington,
  2894. it arrives with Icelandic eth's and thorns, inserted into the Turkish
  2895. words. If you are not too concerned about excluding a NATO member from
  2896. the Western civilisation, ISO8859-1 is certainly an improvement.
  2897.  
  2898. There is a next step but - at a price. If we take two bytes for every
  2899. character we can accomodate much more, even Chinese. Only a few
  2900. mandarins who happen to know 80000 Chinese characters would be
  2901. disappointed. The design of this is the subject of SC2/WG2, meeting this
  2902. week in Boston. Thus, at some time, there may be an ISO standard for it.
  2903. I am interested to hear opinions on this idea.
  2904.  
  2905. As for EBCDIC the situation at present is comparable, only there are 14
  2906. positions available for national versions. You find the story in "3270
  2907. system - Display and Printer I/O Interface Codes", Figure 10-43. Still
  2908. worse is the collection of horrors in "IBM Displaywriter Host Attach
  2909. Programming Guide". p. 5-3 to 5-33. It also includes the EBCDIC/7-bit
  2910. code correspondence. There is also mentioned a distinction between
  2911. EBCDIC/Multilingual, EBCDIC/DP and EBCDIC/WP.
  2912.  
  2913. So far for the tutorial. If we want the order of things changed, we can
  2914. know what they are. But there is an important difference when attempting
  2915. changes. The ISO standards are produced by international Working Groups,
  2916. and approved by Subcommittees and Technical Committees, National Member
  2917. Bodies voting. But in many countries it is not difficult to get into
  2918. their panels, provided that you know your stuff, and are prepared to do
  2919. a lot of work, and attend the meetings.
  2920.  
  2921. With EBCDIC changes are an IBM management decision that can be only to a
  2922. certain extent be influenced by SHARE, SEAS or other groups' requests,
  2923. and often at a stage that is too late. Even the defining document for
  2924. EBCDIC is hard to obtain (it exists, it is IBM Corporate Standard, CSS
  2925. 3-3220 002, that is to say my copy that dates from 1970, and will have
  2926. been modified certainly since then).
  2927.  
  2928. So, we should not only talk about what to agree, but also about the way
  2929. to achieve it.
  2930.  
  2931. I hope that my contribution to our list has been constructive. Let us
  2932. shed our tears elsewhere.
  2933. Yours faithfully, Johan van Wingen
  2934.  
  2935.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  2936.      Mail to                                :
  2937.  P. O. Box 486,  2300AL Leiden, Netherlands :
  2938.  
  2939. 14-Apr-88 12:17:59-EST,4482;000000000001
  2940. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  2941. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 14 Apr 88 12:17:53-EST
  2942. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 14 Apr 88 12:16:17 EDT
  2943. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  2944.  3540; Thu, 14 Apr 88 12:16:13 EDT
  2945. Received: by BITNIC (Mailer X1.25) id 6936; Thu, 14 Apr 88 12:12:39 EDT
  2946. Date:         Thu, 14 Apr 88 09:27:22 CDT
  2947. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2948. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  2949. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  2950. Subject:      Query about implementation and use of ISO standards
  2951. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  2952.  
  2953. In discussions of character sets, I occasionally encounter people (in
  2954. person or by their writings) who wonder what all the fuss is about,
  2955. since after all ISO 2022 defines a perfectly adequate method of
  2956. switching from one seven-bit character set to another (SO) and
  2957. back (SI) -- and moreover also defines methods for specifying, as
  2958. part of the data stream, which character sets are being used as G0
  2959. and G1 sets.  (By means of escape sequences assigned by ECMA, acting
  2960. for ISO as a registration authority, to all registered sets.)
  2961.  
  2962. The obvious reason for the fuss, of course, is that ISO 2022 defines
  2963. a method, but does not provide the hardware or software to implement
  2964. the method.  And I wonder -- do the hardware and software exist?
  2965.  
  2966. So my questions are these:
  2967.  
  2968. 1 how common (in the experience of this group, either in North America
  2969. or elsewhere) are terminals or terminal emulation programs which accept
  2970. and handle SI/SO character set switching?  I can think of:
  2971.  
  2972.     - Datamedia APL terminals (I have read that most ASCII APL
  2973.          terminals do SI/SO, but I have never encountered any but DM)
  2974.     - IBM 3163, 3164 terminals, with or without the ALA cartridges
  2975.     - Yterm (beginning with version 1.3)
  2976.  
  2977. and that's it for me.  Are there others?
  2978.  
  2979. 2 how many of these terminals can handle G1 graphics other than the
  2980. built in set?  In my limited experience, only two:  the IBM 3163/4
  2981. and PCs -- if they have EGA or Hercules Graphics Plus or Quadvue cards.
  2982. (Or any PS/2 with a VGA.)
  2983.  
  2984. 3 how many devices of any type can choose the character set they use
  2985. on the basis of the registered escape sequence for a set?  I don't
  2986. know of any at all.  Is that supposed to be what happens with ISO
  2987. 2022, or is it intended that software somewhere along the way will
  2988. see the registered escape sequences and translate them into control
  2989. sequences that will set the terminals or printers correctly?  If
  2990. the recognition of registered escape sequences is supposed to happen
  2991. in software, then has anyone ever written, used, seen, or heard of
  2992. software that does this?
  2993.  
  2994. 4 (forgive my ignorance, I have used mostly IBM mainframes) Do the
  2995. file structures and utilities of ASCII operating systems and editors
  2996. always / usually / sometimes / ever allow escape sequences like those
  2997. prescribed by ISO 2022 to be embedded in files?  Or will the
  2998. communications link see the escape sequence when it comes in from
  2999. a terminal, try unsuccessfully to parse it, and discard it?
  3000. For that matter, can ASCII systems embed the SI and SO in the file?
  3001. (Or IBM systems?  Yes, I know about SET HEX ON and ALTER in Xedit,
  3002. but are there simpler ways?)
  3003.  
  3004. In sum -- my own experience is that SI and SO are useful and (now)
  3005. possible, between a mainframe host and a terminal where both know in
  3006. advance what character sets are to be used.  I have now seen this
  3007. convention actually used in terminal-to-host communication, this year
  3008. for the first time (long after first reading about it).
  3009.  
  3010. But -- while it seems equally useful to be able to identify character
  3011. sets by the use of escape sequences embedded in the data stream, I
  3012. have still (fifteen years or more after ISO 2022) never seen in use
  3013. or heard of as ever being used.  Is it used?  Or is it a nice idea
  3014. that no one has implemented, as ISO 6937/2 appears to be?
  3015.  
  3016. Since there seems no point in burdening the list with replies saying
  3017. "Nope, I haven't ever seen it either," replies can be sent to me,
  3018. U18189 at UICVM, and I will post results, if any, to the list.
  3019.  
  3020. Michael Sperberg-McQueen, University of Illinois at Chicago
  3021. 14-Apr-88 12:46:25-EST,4870;000000000001
  3022. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3023. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 14 Apr 88 12:46:19-EST
  3024. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 14 Apr 88 12:44:42 EDT
  3025. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3026.  3584; Thu, 14 Apr 88 12:44:40 EDT
  3027. Received: by BITNIC (Mailer X1.25) id 7306; Thu, 14 Apr 88 12:43:19 EDT
  3028. Date:         Thu, 14 Apr 88 11:24:08 EST
  3029. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3030. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3031. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  3032. Subject:      RE:       national versions
  3033. X-To:         ASCII/EBCDIC character set related issues
  3034.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  3035. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3036.  
  3037. I agree with Johan's comment, but want to add one observation and
  3038. reinforce another.
  3039.  
  3040. 1) Changing EBCDIC:  By and large, the way IBM makes decisions like this
  3041. are dictated by "marketing considerations" much more than by, e.g.,
  3042. requests from the likes of SHARE or SEAS.  Since the COBOL debacle and
  3043. the environment that spawned it ("we have these three zillion lines of
  3044. code that we would have to change, and that would cost us umpity-ump
  3045. kilos of gold and pounds of flesh..."), "marketing considerations" has
  3046. often been an abbreviation for "we are just not going to make
  3047. incompatible changes if they are going to disrupt our installed customer
  3048. base".  That is, I want to stress, a reasonable position, but it makes
  3049. "drop EBCDIC internally" about as realistic (maybe less so) than "it
  3050. would be really nice if the 370 supported a hardware stack
  3051. architecture".
  3052.   The whatever-you-like-internally, Standard character sets in
  3053. interchange, approach is actually realistic, but this is not the right
  3054. place to debate it.  Things are moving in that direction anyway, but, if
  3055. you are going to have that plan, then you are going to need to convert
  3056. the graphics.  Somehow.  Which is where this discussion should probably
  3057. focus.
  3058.  
  3059. That said, the problem is a little worse than Johan's description.
  3060. First of all, the national member body representatives of some of the
  3061. countries with non-alphabetic languages stood up at an ISO/IEC JTC1/SC22
  3062. (programming languages) meeting last fall and indicated, among other
  3063. things, that "multiple byte" might well need to be more than two.
  3064. Second, they want the multiple byte sequences *embedded* in single-byte
  3065. sequences and vice versa, and got an SC22 vote imposing support for
  3066. exactly that requirement on any future programming language
  3067. standardization.  They appear to feel that translation from a data
  3068. stream that has both sets of characters and escapes into an internal
  3069. representation that uses a single (adequately long) length is
  3070. unacceptable, or only marginally acceptable - at least in part because
  3071. of the space requirements.   Consider the programming language
  3072. implications of the usual "how long is that string in 'characters'" and
  3073. "are these two strings equal" operations.
  3074.     Please do not start a discussion on this topic here, just think
  3075. about it as part of the background to any "solutions" you propose.
  3076.  
  3077. Now, the other thing that has slipped past in the flurry of messages is
  3078. that there are ISO standards finished or under development that permit
  3079. switching character sets midstream.  I can, in principle, send out a
  3080. stream of characters in ISO8859/1 (Latin alphabet 1) and insert a
  3081. control sequence somewhere that says "here comes ISO8859/8", and then
  3082. send some characters which I want interpreted according to the latter
  3083. set of graphic mappings.  Then I can switch back, or switch to a third
  3084. registration set.  Now, one can perfectly well design a system that
  3085. responds to those "switch sets" controls with "I can't deal with that
  3086. nonsense", or one can be prepared to handle all of them.  But, if you
  3087. take the first position, you are better off than you were with national
  3088. variants of ISO646 only in that you *know* that you can't interpret the
  3089. characters correctly, rather than thinking that they represent your own
  3090. variant.
  3091.   But, if you decide to cope with a character set switch, then you need
  3092. to worry about the EBCDIC code pages, or other variations, to deal with
  3093. the entire range, and how you are going to switch between them (so much
  3094. for "one network, one conversion standard" or even "one host, one
  3095. conversion standard", at least for simple versions of "conversion
  3096. standard").
  3097.   Again, this is not an attempt to send people off in another irrelevant
  3098. direction -- I would strongly discourage that -- but let's also skip the
  3099. simplistic "solutions".  They either won't work now, or won't work for
  3100. very long.
  3101.  
  3102. 15-Apr-88 14:34:57-EST,3296;000000000001
  3103. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3104. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 15 Apr 88 14:34:54-EST
  3105. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 15 Apr 88 14:33:07 EDT
  3106. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3107.  0759; Fri, 15 Apr 88 14:33:03 EDT
  3108. Received: by BITNIC (Mailer X1.25) id 8865; Fri, 15 Apr 88 14:32:21 EDT
  3109. Date:         Fri, 15 Apr 88 08:54:55 EST
  3110. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3111. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3112. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  3113. Subject:      RE:       Re: national versions
  3114. X-To:         ASCII/EBCDIC character set related issues
  3115.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  3116. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3117.  
  3118. >       <MSTCOM%NEUVM1.BITNET@MITVMA.MIT.EDU>
  3119. >In-Reply-To:   Message of Thu, 14 Apr 88 14:55:00 MET from <MOSGLA@HLERUL2>
  3120. >
  3121. >     I think you are right about the two-byte international char. set.
  3122. >The world isn't as big as it used to be, because of the xxxNETs. So we
  3123. >need to have ONE code, having ALL chars of the world in it. Problems
  3124. >will be solveable by mapping existing producer-dependent charsets into
  3125. >this code when xfering files. Ensuring correct printout is depending on
  3126. >printers/printer software.
  3127.  
  3128. Sigh.  Let's assume that you can make a list of "ALL chars of the
  3129. world".  Let's assume that you can get a list of the "important"
  3130. characters in the non-alphabetic languages (Chinese and Japanese Kanji
  3131. are not the only ones, just the ones you hear about most often) and get
  3132. the people who use those languages to agree to never want to add another
  3133. character (which would require an extensible set, which works against
  3134. "ONE code").
  3135.  
  3136. Those assumptions are pretty unlikely to be true, but, just assume.
  3137.  
  3138. Then your only problem is that the nature of the standardization process
  3139. is that it is likely to be well into the next century before that
  3140. character set can be agreed upon.  There are a number of character sets
  3141. for which, as far as I know, there aren't even coding proposals in the
  3142. international arena (Sanskrit and Thai come to mind -- if those proposals
  3143. exist, they haven't crossed my desk when I was looking).  And, if you
  3144. want "ALL characters of the world", you need to worry about some
  3145. languages that are no longer in common conversational use, since
  3146. scholars in the relevant fields want to communicate with each other -
  3147. anyone for an ISO-standard Phoenician character set?  Etruscan, perhaps?
  3148.  
  3149. I think one's choice is to learn to deal with an extensible system, and
  3150. hence multiple characters sets, today (or soon), or to theorize and
  3151. harmonize for a *very* long time.  I think I prefer the former.
  3152.  
  3153. Also note that CCITT IA5, otherwise known as ISO646 Basic Version, was
  3154. an attempt at a "universal" character set, and works fairly well in
  3155. restricted applications, as does the even-more-restricted Telex
  3156. character set.  But it does not do very well for non-Latin alphabets or
  3157. lots of characters in highly-populated Latin-derived ones, which is what
  3158. this discussion is all about.
  3159.  
  3160.  
  3161. 15-Apr-88 14:43:52-EST,3433;000000000001
  3162. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3163. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 15 Apr 88 14:43:41-EST
  3164. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 15 Apr 88 14:41:31 EDT
  3165. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3166.  0776; Fri, 15 Apr 88 14:41:29 EDT
  3167. Received: by BITNIC (Mailer X1.25) id 8991; Fri, 15 Apr 88 14:40:27 EDT
  3168. Date:         Fri, 15 Apr 88 10:25:00 CDT
  3169. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3170. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3171. From:         Rick Troth <TROTH%TAMCBA.BITNET@CUVMA.COLUMBIA.EDU>
  3172. Subject:      Throw out EBCDIC?
  3173. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3174.  
  3175.         Thank you Jon Klensen for "right on the money" comments.
  3176. Indeed IBM is obliged to keep a large customer base happy. Banks (for example)
  3177. don't really care about what's new or what's happening in China, they just
  3178. want what works. "What we have now is fine ... why change?" IBM will always
  3179. be slow to change because most of their customers are slow to change.
  3180. We should make the change as smooth as possible.
  3181.  
  3182.         I am becoming an IBM biggot myself, but there was a time when I hated
  3183. EBCDIC for incompatibility. Then came 7171's, VAXen on BITNET, and ...
  3184. whoooa ... we're actually making progress here.  Amdahl seems to recognize
  3185. the value of ASCII (ISO) and the whole idea of a more general I/O scheme.
  3186. Their version of UNIX, UTS, is quite an excellent implementation. I was quite
  3187. astonished to discover that it is an ASCII system. But behold: one need not
  3188. give up 3270's, RSCS (even NETDATA), or VM. JNET (for the VAX) and UTS are
  3189. both making inroads for ASCII (and then ISO) into the IBM mainframe world.
  3190. (Actually JNET is making an inroad for EBCDIC into the VAX world   :-)
  3191.  
  3192.         Since I brought up DEC at this time, I will post my "report card"
  3193. on the VT220. Having gone over the white paper from Ed Hart, I compared
  3194. the listing of ISO8859/1 to the "DEC Multinational" character set.
  3195. Multinational diverged from 8859/1 in 15 places, five of those were collisions
  3196. where DEC had defined something different from ISO and ten were left blank
  3197. in the DEC definition. Jon mentioned switching character sets mid-stream.
  3198. The VT200's can do that. They can also handle SI/SO if you modify APL support
  3199. on your 7171. There are almost a dozen different "NRC sets" in the box.
  3200. I am not as enamored of DEC as I was once, but we have a lot of VAXen on
  3201. campus and thus have a lot of VT200's. I'd like one in my office.
  3202.  
  3203.         Since I mentioned UNIX, (somebody on IBM-MAIN just royally flamed
  3204. UNIX) the ideas that "everything is a file" and "all I/O is performed via
  3205. device drivers" are good. MVS does this (to an extent), CMS does not but it
  3206. could. I don't care for the idea of a two-byte character set, but I do like
  3207. the concept of mid-stream (transparent to the user) set switching.
  3208. Device driven I/O can handle that quite well and makes the transition
  3209. (to ISO or whatever) much smoother. This is precisely how UTS as an ASCII
  3210. system can work just fine with EBCDIC 3270 tubes. I am really quite impressed;
  3211. you really should all see it. (mercy! I don't mean to advertise for Amdahl)
  3212.  
  3213.                                                           - Rick
  3214. 15-Apr-88 16:13:01-EST,1116;000000000001
  3215. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3216. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 15 Apr 88 16:12:53-EST
  3217. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 15 Apr 88 16:10:47 EDT
  3218. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3219.  0974; Fri, 15 Apr 88 16:10:46 EDT
  3220. Received: by BITNIC (Mailer X1.25) id 0919; Fri, 15 Apr 88 16:09:56 EDT
  3221. Date:         Fri, 15 Apr 88 15:53:34 EST
  3222. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3223. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3224. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  3225. Subject:      RE:       Throw out EBCDIC?
  3226. X-To:         ASCII/EBCDIC character set related issues
  3227.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  3228. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3229.  
  3230. Small addendum to Rick's note:  The DEC VT300 has support for
  3231. Latin Alphabet 1.  The 200 predates it, and "DEC Multinational"
  3232. was, approximately, a best guess.
  3233.  
  3234. 15-Apr-88 19:20:02-EST,17835;000000000001
  3235. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3236. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 15 Apr 88 19:19:57-EST
  3237. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 15 Apr 88 19:18:24 EDT
  3238. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3239.  1239; Fri, 15 Apr 88 19:18:22 EDT
  3240. Received: by BITNIC (Mailer X1.25) id 3169; Fri, 15 Apr 88 19:11:48 EDT
  3241. Date:         Fri, 15 Apr 88 18:55:26 EDT
  3242. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3243. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3244. Comments:     Code:    CECP 500
  3245. From:         Otto Stolz +49 7531 88 2645 <RZOTTO%DKNKURZ1.BITNET@CUVMA.COLUMBIA.EDU>
  3246. Subject:      Some clarifications
  3247. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3248.  
  3249. Dear list subscribers,
  3250.  
  3251. first, let me tie together a few loose ends of the discussion that
  3252. commenced on 15 Mar 88 by Some Important Comments from Howard Gilbert.
  3253.  
  3254. I hasten to disclaim: I'm not the Network Expert of our site; rather,
  3255. my duties relate to the end-user interface (software & advice).  Hence,
  3256. the opinions and proposals presented below, are my private contribution
  3257. and bear no official character.
  3258.  
  3259. IBM's CECPs
  3260. -----------
  3261. Further to the ISO 8859-1 standard of 1987, IBM changed their Graphic
  3262. Character Set 00697 to conform with the character set of the ISO
  3263. standard.  To do so, they had to replace these 4 (four) characters:
  3264.    SC07  florin (guilder) sign
  3265.    SM10  double underline
  3266.    LI61  small letter dotless i
  3267.    SP31  numeric space
  3268. with those four characters:
  3269.    SM52  copyright sign
  3270.    SA07  multiplication sign
  3271.    ND011 one superscript
  3272.    SA06  division sign
  3273. Please, make sure that the tables you use are dated 1987 or later, and
  3274. contain the new character set.
  3275.  
  3276. Moreover, IBM has defined 9 (nine) Country Extented Code Pages (serving
  3277. 17 languages), which contain the characters of GCS 00697 in various per-
  3278. mutations.  Again, you should make sure that you use the new CECPs.
  3279. Clearly, IBM had two aims in mind:
  3280. 1. provide an unambiguous mapping between any pair of CECPs, and possibly
  3281.    between any CECP and ISO 8859-1;
  3282. 2. avoid data conversion at their customer's sites when they switch over
  3283.    to the new CECPs.
  3284.  
  3285. This latter aim prevented the introduction of a single CECP: we all now
  3286. have to live with the consequences of the mistake IBM (and ISO, by the
  3287. way) have made dekades ago, when they started that "National Characters"
  3288. rubbish in their code pages.  We call this a "Treppenwitz der Welt-
  3289. geschichte", in German.
  3290.  
  3291. Characters convey a meaning
  3292. ---------------------------
  3293. ISO 8859-1 and the CECPs deal with coding of characters into bytes,
  3294. hence the only sensible mapping between them is via matching characters
  3295. (i.e. grafics or character descriptions, eg. "small letter a with grave
  3296. accent" of ISO 8859-1 is mapped on "LA14 a Grave Small" of the CECPs).
  3297. It's a pitty, that IBM and ISO differ even in the wording of their
  3298. respective descriptions, but I guess, everybody can live with that.
  3299. This mapping would allow the transfer of notes, scripts and the like
  3300. between user's in all countries speaking one of these 17 languages.
  3301.  
  3302. As an aside, letters with diacritical marks, and German and Icelandic
  3303. National Letters, are vital for these respective languages.  They are
  3304. not just "fancy characters", but rather letters in their own right.
  3305. Recently, I've seen in a Swiss newspaper an amusing example of the habit
  3306. of using "ss" instead of the Sharp-s "":
  3307. >   Brigitte Bardot mit ihren beachtlichen K>rpermassen
  3308.     (BB, and the considerable masses of her body)
  3309. whilst the writer probably intended to say
  3310.     Brigitte Bardot mit ihren beachtlichen K>rpermaen
  3311.     (BB, and her remarkable anatomical measurements).
  3312. O yes, Michael Sperberg-McQueen, most Germans and Austrians cannot
  3313. imagine how the Swiss can do without Sharp-s.
  3314.  
  3315. With program sources, things are similar, but a bit more complicated.
  3316. Program sources are written by human beings, and they are on this world
  3317. to be read by human beings|  (As a pleasant accompanying phenomenon,
  3318. they can also be obbeyed by computers.)  If it were the other way round,
  3319. we all would enter our programs bitwise, in machine-language.  Hence,
  3320. program sources must look alike in books, on screens, in listings, and
  3321. on the keyboard.  That's the reason, programming languages' standards
  3322. do specify characters, and do not (and should not) specify code points
  3323. (cf. Howard Gilbert's remark).  On the other hand, they should (and
  3324. normally do) specify alternative representations to take account of
  3325. limited character sets (not Code pages|), eg. "(*" for "{" in Pascal.
  3326. And after introducing any ISO 8859 character set, compilers should cease
  3327. using characters for wrong meanings, e.g. tilde, or circumflex accent
  3328. for not-sign.
  3329.  
  3330. IBM falls far short of the goal of using characters sensibly:  without
  3331. being ashamed the least, they sell you equipment for a couple of Mega-
  3332. DMarks (a terminal, a control unit, a computer, an operating system and
  3333. a compiler) which is not capable of translating a Pascal program, even
  3334. as simple as
  3335.        PROGRAM ebcdic (output)
  3336.          (* example of a little Pascal program *)
  3337.        ; BEGIN writeln ( 'hello|' ) END
  3338.        .
  3339. just because you happen to live in Germany, where the word for "of"
  3340. contains a letter(|) that is interpreted by the compiler as an end-of-
  3341. comment-symbol|  :-(
  3342.  
  3343. Clearly, the next step to be required from IBM must be adapting their
  3344. language processors to the CECPs.  Recognizing dual EBCDIC codes for
  3345. some characters, is not enough for the compilers and other applications:
  3346. as long as there are various EBCDICs (call them CECPs or what you want),
  3347. you must be able to customize them for the variant to be used|  Folks,
  3348. please help convincing IBM by sending in as many APARs as you have pro-
  3349. ducts.  The same holds for other software suppliers.
  3350.  
  3351. But now, for the difference between plain text and programs.  In addition
  3352. to using characters, you may also refer to them.  This is no problem in
  3353. plain text (cf. the sharp-s example, above) -- but in programs you
  3354. normally use its code point to refer to a character|  And here the Code
  3355. Page crept in, again:  if you are going to convert a source program from
  3356. one code to another, you are doomed to understand its ends and means
  3357. to a T.  Every number (be it hexa-dekadic or decimal) might well be a
  3358. character code, or a character code offset, or whatever you can imagine.
  3359. Hence, automatic (and reliable) code conversion of program sources is
  3360. virtually impossible.  Example: you read in a Pascal program
  3361.          'a'-'z', '', '>', 'u', '' !
  3362. From your knowledge, that this program comes from a ISO computer in
  3363. Germany, you have to infer the meaning "some small letter", and you have
  3364. to translate it into something like
  3365.          'a'-'z', ''-'' !            (* for ISO 8859-1*)
  3366.  or
  3367.          'a'-' ', ')'-'', 'W', 'a'-'i'
  3368.         , 's'-'.', 'j'-'r', 'N'
  3369.         , 's'-'z', 'J'-'m', '-'-''
  3370.         !                                (* for CECP 500 *)
  3371. and similar (but different) for other CECPs.
  3372. Now, you probably understand IBM's reluctance to a single universal CECP.
  3373.  
  3374. FORMER CODES
  3375. ------------
  3376. The CECPs meet a lore (80 to 300, depending on whom you ask) of more or
  3377. less established codes and practices.
  3378.  
  3379. 1. There is such a thing as The Factual Software Code: though no stan-
  3380.    dard (neither ISO, nor national, nor internal) covers this practice,
  3381.    software designers seem to unanimously take English(U.S.) EBCIDC plus
  3382.    TN-style brackets minus OCR characters for "the" EBCDIC.
  3383.  
  3384.    A couple of months ago, I met an IBM employee who is substantially
  3385.    involved in Codes and Keyboards design.  When I told him that the
  3386.    brackets are normally assumed on code points AD & BD, he exclaimed:
  3387.    "But they never belonged there|"  Then I told him, that even IBM's
  3388.    Pascal/VS compiler accepts only(|) AD and BD for the brackets.  He
  3389.    had never heared of such a thing|  (Boys, I'm not kidding; that really
  3390.    has happened here.)
  3391.  
  3392.    As I guess from the recent discussion in this list, the BITNET-Code
  3393.    (if there is such a thing) probably looks very similar.
  3394.  
  3395.    The character set of this Code is too limited to support any other
  3396.    language than English.  So, any CECP would be an improvement.  I do
  3397.    not believe that IBM might be willing to define a tenth CECP, based
  3398.    on this code (for which not even a standard exists).
  3399.  
  3400. 2. IBM's I/O Interface Codes are selected during control unit customi-
  3401.    zation.  The trouble: chosing some keyboard layout, you implicitly
  3402.    chose an I/O Interface Code.  Example: if you chose German Keyboard,
  3403.    you get the "p" (capital U with diaresis) on the very codepoint, US
  3404.    EBCDIC uses for the exclamation point.  Hence, important sentences in
  3405.    notes from abroad, and in every IBM-supplied help text, are marked
  3406.    for us, inevitably, with U-Umlaut.
  3407.  
  3408.    Note, that every IBM 327x (or similar) screen is capable of displaying
  3409.    all letters required for 16 languages (anything except Icelandic) and
  3410.    a lot of special characters.  It's the control unit, that prevents
  3411.    you from seeing these characters -- or allows you to display them, if
  3412.    you have installed Configuration Support C, D or T.  In fact, every
  3413.    Configuration Support establishes its own EBCDIC variant;  hence,
  3414.    the nine CECPs cannot be truly upwards-compatible.
  3415.  
  3416.    Matthias Melcher's suggestion is based on these Configuration
  3417.    Supports.
  3418.  
  3419. 3. The 7171 Control Unit seems to be based on a similar code as 1.,
  3420.    above.  The trouble here is, that any character which is not in the
  3421.    code translation table of this ingenious device, is translated into a
  3422.    colon ":".  Hence, you can only get about 90 different characters
  3423.    through this bottle-neck, when you need about 190 different ones.
  3424.    The 7171 manual states, that this translation table can be amended.
  3425.    Has anybody done this, so far?  If so, please drop me a note stating
  3426.    your experiences|
  3427.  
  3428. 4. Kermit has it's own ideas on ASCII-EBCDIC translation.  (Very similar
  3429.    to 1., above.)  During Terminal Emulation, it's confined to 7171's
  3430.    limitations (at least in our case, where the PCs are connected via a
  3431.    7171).  For File Transfer, Kermit can be customized by a suitable
  3432.    take file; so at least in this area incompatibilities can be solved.
  3433.  
  3434. 5. IBM PCs and clones have used their own 8bit character set, comprising
  3435.    the national letters of the same 16 languages but different special
  3436.    characters.  All PCs, regardless of their keyboard, use identical
  3437.    codes for this character set (that's the purpose of that keyboard
  3438.    program you get loaded, when yo boot-strap your PC).
  3439.  
  3440.    Pity, not all software designers recognizing this scheme.  Notably,
  3441.    terminal emulation programs tend to bypass the keyboard program and
  3442.    hence are useless outside USA.  The same tends to hold for software
  3443.    designed for multiple computer brands.
  3444.  
  3445.    I guess, IBM has started already delivering PCs with a new character
  3446.    set, a superset of ISO 8859-1 (they kept 16 classical PC characters,
  3447.    most of them semi-graphics).  The code is ISO 8859-1 (i.e every
  3448.    codepoint above A0 is re-assigned) plus the additional characters
  3449.    in codepoints 80 to 9F.
  3450.  
  3451. WHAT CAN BITNET DO?
  3452. -------------------
  3453. BITNET is primarily designed for transferring messages, i.e. plain
  3454. text.  Let's set a comparatively humble goal, for the moment:
  3455.       BITNET should transmit any plain text consisting of characters
  3456.       from the ISO 8859-1 character set (i.e. GCS 00697) sensibly
  3457.       and undisturbed.
  3458. This must be our first goal, leaving out
  3459. * special handling of program sources (cf. remarks above),
  3460. * other latin based alphabets,
  3461. * non-latin left-to-right single-byte coded languages (e.g. Greek),
  3462. * right-to-left languages, and
  3463. * double byte coded languages.
  3464.  
  3465. Program sources require human intervention for a thorough, sensible
  3466. translation (and they must be enabled for that purpose, cf. IBM's
  3467. "National Language Information and Design Guide" series, SE09-8001,
  3468. SE09-8002, ...)
  3469.  
  3470. The other four require special equipment.  Throughout BITNET, English
  3471. seems to take the role of a Lingua Franca; hence even participants
  3472. in non-latin-writing countries will have to use a latin-writing
  3473. terminal for their BITNET correspondence.
  3474.  
  3475. BITNET is still far away from even this moderatest goal;  nor does it
  3476. handle the former codes sensibly.  One more example:  Germany's primary
  3477. BITNET node, DEARN, refused to accept UDS entries or list subscriptions
  3478. containing German Sharp-s or German Umlauts in the participants proper
  3479. name.  The subscribers had to substitute other characters (e.g. "oe" or
  3480. even "-") for such characters in their names. That happened in a country,
  3481. where you are legally entitled (96 BDSG, 96 LDSG) to having your name's
  3482. spelling corrected, if it's mis-spelled in any database|
  3483.  
  3484. As stated earlier, the transgression from some 300 different EBCDIC
  3485. variants to 9 EBCDIC + 1 ISO would be a major improvement.
  3486.  
  3487. HOW COULD IT WORK?
  3488. ------------------
  3489. I suppose, that every site will try to introduce one single CECP (or
  3490. ISO 8859), and do away with the old Codetable mismash.  This will take
  3491. time, as there is new equipment involved (new terminals, 3174 instead of
  3492. 3274, updatet compilers, &c.)  Also, the old data and programs will have
  3493. to be transformed, suitably.  Note, that BITNET is only a small part of
  3494. the whole EDP business|
  3495.  
  3496. During the transition phase, MM's proposal could help smoothing things.
  3497. But behold, SET INPUT and SET OUTPUT cannot be the last word.  These
  3498. commands are only available in CMS;  and they take effect only in CMS
  3499. line-mode and in XEDIT.  CP commands, and CP messages are not translated,
  3500. and most full-screen mode programs do not honour the SET INPUT and SET
  3501. OUTPUT commands.  What a pleasure, when you enter
  3502.        TELL Kurt Gru Gott|
  3503. and CP displays to Kurt the Message
  3504.        Gr,( Gott|
  3505.  
  3506. After having chosen a CECP (or ISO8859-1), the site could send out its
  3507. texts in this local code.  They will have to be code marked: in the tag,
  3508. and preferably also inside the text.  For NOTES, RFC822 could be enhanced
  3509. with a "Code:" field, such as I have used in the header of this very
  3510. note.  I think, there are enough Network Experts listening to this list:
  3511. they should be able to design a suitable amendmend to the network's
  3512. standards.
  3513.  
  3514. The price for sending out the notes in a local code variant (well, that's
  3515. the very procedure, most sites are following right now) will be the
  3516. obligation of translating incoming messages.  So, every site will use at
  3517. most 9 (of the possible 90) translation tables.  Again, this could be
  3518. done via SET INPUT and SET OUTPUT, as MM suggested (that's exacly the
  3519. way, I read notes from USA and elswhere).  Later, the mailer, or RSCS,
  3520. or some similar software piece, would do the translating for all incoming
  3521. files, and the end-user will cease bothering with the details.
  3522.  
  3523. There will be need for a special marking, say "Code: Binary" preventing
  3524. the file from being translated, at all.  (Andr) PIRARD should be able
  3525. to continue sending his files through the net.)
  3526.  
  3527. HOW CAN WE SIMPLIFY CODE TABLE HANDLING?
  3528. ----------------------------------------
  3529. Divide & impera|  Instead of devicing 90 related Code Tables (and pains-
  3530. takingly checking them for consistency), we could write down 10 "Half-
  3531. Tables".  These latter would relate one code page, respectively, to a
  3532. common description of the characters.  From these Half-Tables, a simple
  3533. program could build the translation tables for every desired code-pair.
  3534.  
  3535. The ISO 8859 descriptions of the characters are a bit too long to make
  3536. for a feasable common base of our half-tables.  But, what about IBM's
  3537. character identifiers, accompanying the GCS and CECP tables?  Instead of
  3538. "small letter a", we could use "LA01"; instead of "small letter a with
  3539. grave accent" we say "LA13", and instead of "small diphthong a with e",
  3540. we have "LA51".
  3541.  
  3542. Thus, the upper part of the CECP 500 half-table would be:
  3543.  
  3544.          Y    4    5    6    7    8    9    A    B    C    D    E    F
  3545.     -----+-------------------------------------------------------------
  3546.        0 Y SP01 SM03 SP10 LO61 LO62 SM19 SM17 SC04 SM11 SM14 SM07 ND10
  3547.          Y
  3548.        1 Y SA06 LE11 SP12 LE12 LA01 LJ01 SD19 SC02 LA02 LJ02 SP31 ND01
  3549.  
  3550. Note the new CECP 500, having SA06 (Division Sign) instead of the older
  3551. SP30 (Numeric Space).
  3552.  
  3553. Aside: these identfiers start with the following letter(s):
  3554.        L   for Letter,
  3555.        ND  for Numerical Digit,
  3556.        NF  for Numerical Fraction,
  3557.        SA  for Arithmetical sign,
  3558.        SC  for Currency sign,
  3559.        SD  for Diacritical mark,
  3560.        SP  for Punctuation marks,
  3561.        SM  for Miscellaneous special characters.
  3562.  
  3563. I can also set up a Half-Table for my controll-unit's I/O interface
  3564. code, hence a simple program could generate from these two half-tables
  3565. an EXEC with suitable SET INPUT and SET OUTPUT commands to display
  3566. CECP 500 on my terminal -- simply by matching the SM11 entry in code-
  3567. point C0 (CECP 500) with the SM11 entry in code-point 75 (Austrian/
  3568. German I/O Interface Code) and generating the REXX-line
  3569.     "SET OUTPUT C0 2"; "SET INPUT 2  C0" /* SM11  */
  3570. from this match.  (The "2" byte comes out as opening brace, on my
  3571. terminal.)  Thus, the generating of MM's procedures can be mechanized
  3572. in the same way as the generating of the BITNET translation tables.
  3573.  
  3574. The same holds for Kermit's Take-Files.
  3575.  
  3576. I would appreciate any comments on this proposition.
  3577.  
  3578. Regards
  3579.         Otto.
  3580. 17-Apr-88 12:39:01-EST,4010;000000000001
  3581. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3582. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Sun 17 Apr 88 12:38:59-EST
  3583. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Sun, 17 Apr 88 12:37:21 EDT
  3584. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3585.  2123; Sun, 17 Apr 88 12:37:18 EDT
  3586. Received: by BITNIC (Mailer X1.25) id 0264; Sun, 17 Apr 88 12:36:31 EDT
  3587. Date:         Sun, 17 Apr 88 02:33:42 EST
  3588. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3589. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3590. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  3591. Subject:      RE:       Some clarifications
  3592. X-To:         ASCII/EBCDIC character set related issues
  3593.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  3594. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3595.  
  3596. Otto,
  3597.   Well-presented, clear, and focused on what I think are the right set
  3598. of problems.  One comment/plea:
  3599.   While the local system's controller may be the "right" place to
  3600. establish the default code table binding for various supported devices,
  3601. keep in mind that transformations are not guaranteed to be reversible at
  3602. least in going to the large [historical] collection of existing devices.
  3603. It is possible that I will have a German-capable (i.e., supporting
  3604. German "extended" characters -- those that don't appear in ASCII /
  3605. English by code table switching) or a German-national (i.e., supporting
  3606. those characters *instead* of the ASCII special characters) -- available
  3607. at a site that mostly has only US-national (i.e., ASCII-only) devices.
  3608. If I do, I want the ability to see exactly what you write if you write
  3609. to me in German, not the local interpretation of what German ought to be
  3610. spelled like in IA5/ISO646 Basic version.  I might even want to invent,
  3611. for my own use, a set of two-or-three-character conventions.  For, if
  3612. you send me that word which we translate to English as "or", and I don't
  3613. have lowercase-u-umlaut available, I might prefer that my smart terminal
  3614. show me one of those "programming language" convolutions, such as fu:r
  3615. or fu..r, rather than trying the either fuer or fur, or showing me f|r
  3616. (that is 'f', broken-vertical-bar, 'r' on my device at the moment).
  3617.  
  3618. I would not expect to transmit this sort of notation convention, or
  3619. expect anyone else to read it, but it is important that the exact text
  3620. of what was sent, and the information about how it was encoded, be
  3621. available to the end user's mail-reading program or agent.
  3622.  
  3623. While you excluded the cases, the underlying problem becomes much more
  3624. important for messages that might involve non-Latin alphabets: A
  3625. reasonable site default might be to have them rendered into Latinized
  3626. transliteration (there are even ISO standards for the Latin alphabet
  3627. representation of several non-Latin alphabets).  But a local user with
  3628. the right equipment would, presumably want to see whatever the message
  3629. looked like to the person who typed it.
  3630.  
  3631. And don't hope for changes in RFC822 for several reasons.  The most
  3632. important is that local modifications and extensions made by various
  3633. people that treat the header fields just as slightly-structured free
  3634. text comments already have made it very difficult to build an adequate
  3635. processing agent.  The introduction of "Code:" is useful, beyond a
  3636. warning that I'm not going to be able to read what follows, only if the
  3637. predicate comes from a very restricted vocabulary and is arranged so
  3638. that an agent can process the text as it specifies (as your discussion
  3639. implies).
  3640.    X.400, by contrast, has provision for such a field.  But the "red
  3641. book" version doesn't have eight-bit character sets: unless you want to
  3642. specify, e.g., Teletext encoding, you will find yourself limited to
  3643. IA5-text.  And CCITT IA5 = ISO646 = the restricted character sets from
  3644. which our current problems originated.
  3645.      john
  3646.  
  3647. 18-Apr-88 08:53:24-EST,1241;000000000001
  3648. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3649. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 18 Apr 88 08:53:20-EST
  3650. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 18 Apr 88 08:50:49 EDT
  3651. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3652.  2675; Mon, 18 Apr 88 08:50:40 EDT
  3653. Received: by BITNIC (Mailer X1.25) id 4044; Mon, 18 Apr 88 08:47:28 EDT
  3654. Date:         Mon, 18 Apr 88 08:41:57 EDT
  3655. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3656. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3657. From:         "Thomas D. Denier" <TOM%PENNDRLS.BITNET@CUVMA.COLUMBIA.EDU>
  3658. Subject:      IBM Graphic character identifiers
  3659. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3660.  
  3661. Otto Stolz states that an initial letter 'L' in an IBM character
  3662. identifier stands for 'letter'. It actually stands for 'Latin
  3663. alphabetic'. IBM has assigned other initial letters to other alphabets,
  3664. as follows:
  3665.    A  Arabic
  3666.    G  Greek
  3667.    H  Hebrew
  3668.    J  Katakana
  3669.    K  Cyrillic
  3670. Thus, for example, Latin lower-case 'a' is LA01, and Greek lower-case
  3671. alpha is GA01.
  3672. 18-Apr-88 12:54:50-EST,1720;000000000001
  3673. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3674. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 18 Apr 88 12:54:47-EST
  3675. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 18 Apr 88 12:53:01 EDT
  3676. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3677.  3050; Mon, 18 Apr 88 12:52:59 EDT
  3678. Received: by BITNIC (Mailer X1.25) id 6469; Mon, 18 Apr 88 12:52:13 EDT
  3679. Date:         Mon, 18 Apr 88 12:05:56 EST
  3680. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3681. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3682. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  3683. Subject:      Re: IBM Graphic character identifiers
  3684. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3685. In-Reply-To:  Message of Mon, 18 Apr 88 08:41:57 EDT from <TOM@PENNDRLS>
  3686.  
  3687. How does IBM's designation differ from ISO 6937/2 (Coded character sets
  3688. for text communication - Part 2: Latin alphabetic and non-alphabetic
  3689. graphic characters)?  I know this is wishful thinking but could they
  3690. actually be one and the same (or at least 1 a subset of the other)?
  3691.  
  3692. As for the notion of adding a "code" field to mail headers, I don't
  3693. think it would buy you very much even if it were implemented.  Two
  3694. problems suggest themselves:
  3695.     1) what about non-mail transmissions
  3696.     2) what about shifting to other codes within the text
  3697. (How does IBM provide for shifting from 1 code page to another?)
  3698.  
  3699. There are already ISO standards which allow you to shift from code set
  3700. to code set to your heart's delight - why reinvent the wheel?
  3701. (646, 2022, 4873, 8859)
  3702. 18-Apr-88 15:07:01-EST,2477;000000000001
  3703. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3704. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 18 Apr 88 15:06:56-EST
  3705. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 18 Apr 88 15:04:31 EDT
  3706. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3707.  3273; Mon, 18 Apr 88 15:04:24 EDT
  3708. Received: by BITNIC (Mailer X1.25) id 7894; Mon, 18 Apr 88 15:03:47 EDT
  3709. Date:         Mon, 18 Apr 88 13:11:38 CDT
  3710. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3711. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3712. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  3713. Subject:      Header field for CODE and reinvention of wheel
  3714. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3715.  
  3716. John Kesich asks why a Code: field is necessary, since ISO has already
  3717. standardized methods for shifting between character sets.  Perhaps a
  3718. preliminary report on answers to my earlier query about ISO 2022
  3719. implementations is in order.
  3720.  
  3721. The reason "Code:" would be useful, and might be necessary, is that
  3722. ISO 2022 code-page switching via SI/SO is possible only when the G0
  3723. and G1 (and C0 and C1, for that matter) sets are known in advance to
  3724. all parties.  ISO standards for identifying coded character sets by
  3725. means of registered escape sequences have no known implementation
  3726. in any automatic device.  (Possible exception:  some printers may
  3727. accept the registered escape sequences to specify G1 before SO is
  3728. used.  Certainly some use escape sequences -- whether they are the
  3729. registered sequences or not is another matter.)
  3730.  
  3731. There are a (small) number of devices which accept SI/SO (terminals
  3732. and printers only, so far -- no one has reported on successful or
  3733. regular use of SI/SO in data transmission to distant sites).  But
  3734. so far only three or four people have reported anything at all.  If
  3735. we assume that silence implies that one has not heard of any notable
  3736. use of ISO 2022, then it appears that the vast majority of sites and
  3737. devices do not use it.
  3738.  
  3739. Perhaps someone better informed about Bitnet can say whether the
  3740. Bitnet header can or should or cannot or should not handle a CODEPAGE
  3741. field.  I was always told "Bitnet is EBCDIC" -- maybe we should at
  3742. least be able to specify what flavor of EBCDIC?
  3743.  
  3744. Michael Sperberg-McQueen, University of Illinois at Chicago
  3745. 18-Apr-88 19:51:24-EST,3256;000000000001
  3746. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3747. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 18 Apr 88 19:51:19-EST
  3748. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 18 Apr 88 19:49:16 EDT
  3749. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3750.  3601; Mon, 18 Apr 88 19:49:14 EDT
  3751. Received: by BITNIC (Mailer X1.25) id 0347; Mon, 18 Apr 88 19:48:19 EDT
  3752. Date:         Mon, 18 Apr 88 19:43:17 EST
  3753. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3754. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3755. From:         John Kesich <kesich@acf4.NYU.EDU>
  3756. Subject:      punched cards, anyone?
  3757. X-To:         iso8859%jhuvm.BITNET@cimsa.nyu.edu
  3758. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3759.  
  3760. The following list may cause one to consider the possibility that BITNET
  3761. should convert over to ISO8859:
  3762.  
  3763.  857  JNET         7  RNET           2  POWER         1  NOS
  3764.  729  RSCS         6  HUJI-           2  NONE         1  NJI
  3765.  133  UREP         6  ANL N           2  MUSIC         1  NJE 4
  3766.  124  ALIAS         5  PMDF           2  MTF         1  NJE 1
  3767.  117  JES2         5  OASYS           2  MAILE         1  NAM
  3768.   82  TCP/I         5  JA JN           2  INTER         1  MRJE/
  3769.   52  NJEF         4  IBM R           2  CARLE         1  MEMO
  3770.   42  NJE         3  TIELI           2  BERKH         1  MACH2
  3771.   42  HOMEB         3  RM           1  UNIX         1  JES2/
  3772.   26  ?             3  HUJI           1  TRANS         1  IX/37
  3773.   20  ANJE         3  GATE           1  SNA/N         1  HUMAI
  3774.   19  BERK         3  ANL/N           1  RTP/1         1  HASPM
  3775.   18  BITE         2  TELCO           1  RJEF         1  ETHER
  3776.   13  JES3         2  RSCSV           1  RES         1  ECF
  3777.   12  HASP         2  RJE S           1  RCOM         1  CDC
  3778.    9  MULTI         2  RHF           1  PMDF-         1  ANY
  3779.    8  DECNE         2  PRIME           1  NRV         1  AMF
  3780.  
  3781. This list is just a count of the different entries in the SYSTEM TYPE field
  3782. of BITNET LINKS804.  (What happens if we add in NETNORTH & EARN?)
  3783. Just counting JNET & UREP, pretty close to half the nodes are ASCII machines.
  3784. (a precise definition of my misuse of terms for those who may otherwise
  3785. become confused:
  3786.         EBCDIC - the stuff they use on IBM's
  3787.         ASCII - the stuff they use on most everything else
  3788.         ISO8859 - the family of codes which will make ISO2022 practical
  3789.         ISO8859/1 - ISO8859/1
  3790. admittedly not 100% accurate, but, hey, it works for me.)
  3791.  
  3792. Finally, let's not forget all the networked hosts, workstations and pc's
  3793. (IBM included) which hang off BITNET gateways and send mail through them,
  3794. how many of those do you suppose are EBCDIC?
  3795.  
  3796. Perhaps a survey of BITNET hosts should be made.  The 2 questions I'd like
  3797. answers to are:
  3798.         1) how would you feel about converting all BITNET links to ISO8859?
  3799. and for IBM nodes:
  3800.         2) if IBM were to announce a new code page which was code-point-to-
  3801.            code-point and graphic-to-graphic identical with ISO8859/1 and
  3802.            pledged to keep it that way, would you migrate to it?
  3803. 20-Apr-88 13:37:24-EST,2093;000000000001
  3804. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3805. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 20 Apr 88 13:37:22-EST
  3806. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 20 Apr 88 13:37:28 EDT
  3807. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3808.  6126; Wed, 20 Apr 88 13:37:27 EDT
  3809. Received: by BITNIC (Mailer X1.25) id 5947; Wed, 20 Apr 88 13:36:50 EDT
  3810. Date:         Wed, 20 Apr 88 11:54:00 CDT
  3811. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3812. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3813. From:         Rick Troth <TROTH%TAMCBA.BITNET@CUVMA.COLUMBIA.EDU>
  3814. Subject:      Re: punched cards, anyone?
  3815. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3816. In-Reply-To:  Your message of Mon 18 Apr 88 19:43:17 EST
  3817.  
  3818.         I think the real objective here is to find a (nearly) one-to-one
  3819. mapping between EBCDIC (North American) and ISO8859/1, with similar 1-1
  3820. mappings between other national EBCDIC's and ISO8859/whatever.
  3821.  
  3822.         All those ASCII machines listed in BITNET NAMES are already
  3823. performaing their own translation between ASCII and EBCDIC. To switch the
  3824. whole network at once would cause many people much grief in both the short-
  3825. run and the intermediate-run. In the long-run, we would hope that IBM
  3826. supported products (like RSCS or whatever will someday replace it) will
  3827. be able to speak ISOxxxx, but remember that that is most likely 21st-century-
  3828. long-run.
  3829.  
  3830.         JNET (and I suppose others) have their translate tables in place.
  3831. What we are striving for is a "correct" translate table where I could do a
  3832. TELL <user> AT <vax> Talk  to me   and he would see 3 hex A2's on his VT330
  3833. as per DEC Multinational. "Talk cents to me"   Kermit transfers would work
  3834. correctly in both directions (if we achieve 1-1). Translate tables are really
  3835. not so bad if we can just agree on the translation.
  3836.  
  3837.                 Or have I completely missed something?           - Rick
  3838. 20-Apr-88 15:18:47-EST,5977;000000000001
  3839. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3840. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 20 Apr 88 15:18:44-EST
  3841. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 20 Apr 88 15:18:49 EDT
  3842. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3843.  6234; Wed, 20 Apr 88 15:18:47 EDT
  3844. Received: by BITNIC (Mailer X1.25) id 7154; Wed, 20 Apr 88 15:16:49 EDT
  3845. Date:         Wed, 20 Apr 88 21:05:04 GMT
  3846. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3847. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3848. From:         Matthias Melcher <$28%DHDURZ1.BITNET@CUVMA.COLUMBIA.EDU>
  3849. Subject:      PC ASCII
  3850. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3851.  
  3852. Dear list subscribers,
  3853.  
  3854. the following is a contribution of an IBM code specialist to ECMA
  3855. about the history and backgrounds of Code Page 850 (PC Latin 1).
  3856. The attachments mentioned are not included, since I don't have them
  3857. in machine readable form. Matthias Melcher.
  3858.  
  3859. A new character set for the IBM PC, by W.F.Bohn
  3860.  
  3861. When I was asked recently to make available to TC1 a copy of the new
  3862. IBM PC code page I felt that I could not honour that request without
  3863. a few words of explanation.
  3864.  
  3865. The IBM PC was developed to be a very versatile computing device
  3866. capable also running video games, teaching programs, etc. That
  3867. is why the original code table (identified as 437 and Attachment 1 to
  3868. this contribution) has some unorthodox features:
  3869. - the code is based on ASCII - not on EBCDIC,
  3870. - the code table positions in column 00 and 01 have graphic characters
  3871.   assigned to them in addition to the normal 7-bit control characters,
  3872. - a graphic character was allocated to table position 07/15 in
  3873.   addition to, or as a graphical representation of, the control
  3874.   character DELETE,
  3875. - as controls beyond the normal 32 were not envisaged (actually all
  3876.   256 code table positions could be used for controls or for
  3877.   graphic characters) the right hand half of the code table was
  3878.   divided into
  3879.   . three columns with graphic characters believed to satisfy the
  3880.     requirements of the major West European languages,
  3881.   . three columns with line and box drawing characters plus other
  3882.     characters believed useful for creating diagrams, company logo's,
  3883.     etc.
  3884.   . two columns with mathematical and technical symbols.
  3885.  
  3886. Later, when the PC was connected to other computing equipment it
  3887. turned out that its graphic character set did not match any other
  3888. existing one and that interchange of data between two different IBM
  3889. machines would have to be limited to the small number of characters
  3890. common to both installations.
  3891.  
  3892. The advent of the 8-bit single-byte coded character set of ECMA-94
  3893. made a solution of that dilemma possible. By changing the IBM EBCDIC as
  3894. well as the PC code to the character set of ECMA-94/1 interchange of
  3895. all characters without loss of information could be achieved.
  3896.  
  3897. An important decision had to be made, however. Which of the characters
  3898. of table 437 should be sacrificed and which should be taken over into
  3899. the new code page (identified as 850 and attachment 2 to this
  3900. contribution)? Furthermore, should the structure of the code table
  3901. be changed to that of ECMA-94 or should the existing structure be kept?
  3902.  
  3903. In the interest of compatibility with existing equipment and existing
  3904. implementations it was decided:
  3905. - to include all the graphic characters of ECMA-94/1,
  3906. - to keep the original structure of the code table
  3907. - to leave those graphic characters in table 437 and now also in table
  3908.   850 in their original code table positions (there are two exceptions
  3909.   which need not be explained here),
  3910. - to select for the 32 positions in the right hand half of the code
  3911.   table (not needed for characters from ECMA-94/1) a useful set of the
  3912.   line drawing and other characters of table 437 and keep those
  3913.   characters also in their original positions. These characters selected
  3914.   are
  3915.   . the 11 basic line drawing characters in thin (or single line)
  3916.     rendition,
  3917.   . the same 11 characters in bold (or double line) rendition,
  3918.   . three shading characters (light, medium, heavy),
  3919.   . three block characters (full box, upper half, lower half),
  3920.   . a small solid square for different uses.
  3921.   To the remaining three positions were assigned graphic characters
  3922.   formerly in use in IBM but removed when IBM equipment changed their
  3923.   graphic character sets to that of ECMA-94/1. Backward compatibility
  3924.   with the existing equipment was the reason for this decision.
  3925.  
  3926. For interchange of the common character set between EBCDIC and PC
  3927. oriented equipment new translation correspondences were determined
  3928. which, when the traditional translation correspondence between EBCDIC
  3929. and ISO (or ASCII) code equipment is used, would lead to an orderly
  3930. arrangement of the additional characters in columns 08 and 09 of
  3931. ECMA-94. The arrangement is as similar as possible to the one proposed
  3932. for ISO 6937-6.
  3933. This may be of some importance when one day the code extension
  3934. procedures of ECMA-35 will allow additional G sets of 128 characters
  3935. instead of only 94 or 96.
  3936.  
  3937. Information on the translation correspondence between EBCDIC, PC-ASCII,
  3938. and ECMA (or ISO) oriented coding is appended to this contribution
  3939. as Attachment 3. Also attached is a copy of the international version
  3940. of EBCDIC (identified as 500 and Attachment 4 to this contribution).
  3941. The graphic character set common to ECMA 94/1, the IBM PC and IBM
  3942. EBCDIC (identified as 697-1) is Attachment 5.
  3943.  
  3944. Conclusion:
  3945.  
  3946. The new IBM PC code table (850) is the best possible compromise
  3947. between the desire to implement the graphic character set of ECMA-94/1
  3948. and the need to create a minumum impact on the existing implementations.
  3949. Of course, the IBM PC implementation of ECMA-94/2 followes the
  3950. principles outlined above.
  3951. 20-Apr-88 19:55:59-EST,2743;000000000001
  3952. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  3953. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 20 Apr 88 19:55:55-EST
  3954. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 20 Apr 88 19:55:40 EDT
  3955. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  3956.  6598; Wed, 20 Apr 88 19:55:38 EDT
  3957. Received: by BITNIC (Mailer X1.25) id 0871; Wed, 20 Apr 88 19:54:35 EDT
  3958. Date:         Wed, 20 Apr 88 16:49:09 PDT
  3959. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3960. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  3961. From:         June Genis <GA.JRG%STANFORD.BITNET@CUVMA.COLUMBIA.EDU>
  3962. Subject:      BITNET's current mapping
  3963. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  3964.  
  3965. REPLY TO 04/20/88 16:33 FROM ISO8859@JHUVM.BITNET "ASCII/EBCDIC character set
  3966. related iss: BITNET's current mapping
  3967.  
  3968. >What is BITNET's current ASCII-EBCDIC standard?
  3969. >and where may one obtain a copy?
  3970. >Thanks in advance.
  3971.  
  3972. Sorry, John.  No such thing currently exists which is one reason
  3973. why data sets are trashed along the way.  Since BITNET is defined
  3974. to be an EBCDIC system, in theory any ASCII node should be
  3975. translating to/from EBCDIC for anything originating/terminating at
  3976. that node.  No standard has ever been defined as far as I know for
  3977. what translation should be used.  An even more ambiguous situation
  3978. potentially exists when an ASCII node is an intermediary node.  Can
  3979. an ASCII node be anything other than an end node?  If so, are files
  3980. passing thru it translated twice or not at all?  In the latter case,
  3981. might there be a chance that the translations are not reversible
  3982. such that the EBCDIC file emerging on the other side is different
  3983. than that which entered?
  3984.  
  3985. While it's clear to me that the absence of a standardized translate
  3986. table could result in things being messed up when the communication
  3987. is between an ASCII and an EBCDIC node, it is not clear to me if the
  3988. intervening nodes which just happen to be along the path can have an
  3989. impact as well.  This strikes me as the worst problem since finding
  3990. out which node trashed the file could be a real bear.
  3991.  
  3992. It's not even clear to me if the possibility of implementing a
  3993. standardized translate table even exists as many node have local
  3994. variations in translation that they are committed to for one reason
  3995. or another.  Can we assume that all systems have the ability to
  3996. apply one translation to their network mail and another in other
  3997. situations (say an ascii terminal attached to the host which is used
  3998. to general mail shipped both locally and to the net)?
  3999.  
  4000. /June
  4001.  
  4002. To:  ISO8859@JHUVM.BITNET
  4003. 21-Apr-88 09:35:00-EST,1818;000000000001
  4004. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4005. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 21 Apr 88 09:34:39-EST
  4006. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 21 Apr 88 09:34:13 EDT
  4007. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4008.  7058; Thu, 21 Apr 88 09:34:12 EDT
  4009. Received: by BITNIC (Mailer X1.25) id 4432; Thu, 21 Apr 88 09:33:36 EDT
  4010. Date:         Thu, 21 Apr 88 02:03:36 EDT
  4011. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4012. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4013. From:         Edward_Vielmetti@um.cc.umich.edu
  4014. Subject:      ISO Latin-1 terminals
  4015. X-To:         ISO8859%JHUVM.BITNET@CUNYVM.CUNY.EDU
  4016. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4017.  
  4018. There's an ISO Latin-1 font available for the Apollo workstations,
  4019. which Jim Rees (umix!apollo!rees) pointed out in a recent usenet
  4020. posting.  Conceptually, it's real easy for any bitmapped terminal
  4021. with a replacable character set to make up a font like that; the
  4022. difficulties arise when the data transport paths are not 8-bit
  4023. transparent (in the all-ASCII world) or when goofy EBCDIC machines
  4024. get in the way.
  4025.  
  4026. A Latin-1 font for the Apple Macintosh would be easy to construct,
  4027. but there's the underlying problem that the typical Mac font has its
  4028. own Apple arrangement for the upper set of characters.  I think you
  4029. could still get everything to print out OK with a suitable manipulation
  4030. of Postscript.
  4031.  
  4032. Edward Vielmetti, U of Michigan Computing Center
  4033. USERW02S@UMICHUM   emv@umix.cc.umich.edu
  4034. (If you can think of any reason to send Bitnet mail to the UMICHUM
  4035. address, please do so - it's a new service which might fail.)
  4036. 21-Apr-88 22:14:47-EST,4697;000000000001
  4037. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4038. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 21 Apr 88 22:14:40-EST
  4039. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 21 Apr 88 22:14:19 EDT
  4040. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4041.  8217; Thu, 21 Apr 88 22:14:18 EDT
  4042. Received: by BITNIC (Mailer X1.25) id 5752; Thu, 21 Apr 88 22:12:17 EDT
  4043. Date:         Mon, 18 Apr 88 17:57:00 MET
  4044. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4045. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4046. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  4047. Subject:      IBM4250 etc.
  4048. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4049.  
  4050. Dear list subscribers
  4051. I think I was too optimistic about EBCDIC in my tutorial. Since then I
  4052. have been collecting code pages, and it seems now that there is not only
  4053. a separate code page for every language, but for every piece of printing
  4054. (or imaging) hardware as well. This results in some kind of Cartesian
  4055. product, at least two parameters are required for describing an item.
  4056. Some of these code pages are in ISO/ANSI style, some mirrored. My
  4057. catalogue is not yet complete, please provide me with the missing data
  4058. (IBM numbers in particular).
  4059. "Madamina, il catalogo i questo":
  4060.  
  4061. IBM Corporate System Standard, CSS 3-3220-2 (Latest version, please)
  4062. IBM Technical Reference for Digitized Type G544-3516 (not avlbl. here)
  4063. IBM VS FORTRAN Language and Library Reference SC26-4119-1
  4064. IBM Displaywriter Host Attach Programming Guide
  4065. IBM DCA RFT Reference
  4066. IBM 3270 Information Display System,
  4067.          Character set Reference GA-27-2837-9
  4068. IBM GDDM (which one, the set here is not complete)
  4069. IBM 3800 Printing Subsystem Model 3 Font Catalog SH35-0053 (id.)
  4070. IBM 3800 (another programming guide)
  4071. IBM 4250 Printer
  4072.  
  4073. The code pages of the 4250 are particularly nice. I selected the codes
  4074. for six important characters: left square bracket, backslash, right
  4075. square bracket, left brace, vertical bar, right brace (in that order):
  4076. (the square bracket are here AD and BD, I can type them at my 3278 only
  4077. in hexadecimal.)
  4078.  
  4079. IBM 4250 Code Pages
  4080.               AFTC   [  \  ]  {  |  }
  4081. German        0382  63 EC FC 43 CC DC
  4082. Belgium       0383  4A 48 5A 51 DD 54
  4083. Brazil        0384  71 E0 68 CF 48 51
  4084. Canada F      0385  44 5A 79 51 DD 54
  4085. Denm./Norway  0386  9E E0 5A 9C 70 47
  4086. Sweden/Finl.  0387  B5 71 5A 43 CC 47
  4087. France        0388  90 48 B5 51 DD 54
  4088. Italy         0389  90 48 51 44 CD 54
  4089. Japan         0390  B1 B2 6A C0 4F D0
  4090. Latin Am.(Sp) 0393  4A E0 5A C0 4F D0
  4091. Portugal      0391  4A 68 5A 46 CF D0
  4092. Spain         0392  4A E0 5A C0 4F D0
  4093. UK, Aus. NZ.  0394  B1 E0 6A C0 4F D0
  4094. US, Canada E  0395  B0 E0 6A C0 4F D0
  4095. International 0361  4A E0 5A C0 6A D0
  4096. APL           0293  AD B7 BD    BF
  4097.  
  4098. "Ma in Espagna che glie mille e tre."
  4099.  
  4100. I suppose that the ordinary national code pages are only a little bit
  4101. less confusing. Mr. Stolz's letter arrived here in good order, only his
  4102. German jokes missed their point, because our STC/Siemens laser printer
  4103. closely follows the GT12 convention from the IBM 3800 software, and
  4104. prints mostly spaces for accented letters, and a vertical bar for the
  4105. exclamation sign (the same for Mr. Klensin's broken bar).
  4106.  
  4107. I have not seen IBM's latest invention according to Mr. Stolz as yet,
  4108. but I remain sceptical. I think 9 tables are still too much. One single
  4109. universal code page is what is wanted. Before it is shown that really
  4110. not all characters can be accomodated I remain unconvinced. This code
  4111. page can be used for BITNET interchange of text. Locally it can be
  4112. converted to the historical version.
  4113.  
  4114. There are more things in Mr. Stolz's letter that deserve comment, but
  4115. that will come later. Just now I propose to you a little experiment.
  4116.  
  4117. Suppose someone in Norway is typing a text at a PC. Of course it
  4118. contains many AE, ae, A-ring and a-ring, barred O and o, and so on. Now
  4119. he transfers the text by Kermit to an IBM system, by EARN to a VAX
  4120. system, and by Kermit to the PC again. This involves conversion from
  4121. ASCII to EBCDIC and back. Now he does the same, but first to a VAX, then
  4122. again to an IBM, and again to the PC. The difference between the two he
  4123. cannot explain, but we can. It is sufficient to take the sequence:
  4124. AE O/ A0 ae o/ a0
  4125. (I suppose it is clear what I mean. German users may take A O U a o u
  4126. with umlauts.)
  4127.  
  4128.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  4129.      Mail to                                :
  4130.  P. O. Box 486,  2300AL Leiden, Netherlands :
  4131.  
  4132. 21-Apr-88 22:47:24-EST,6910;000000000001
  4133. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4134. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 21 Apr 88 22:47:17-EST
  4135. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 21 Apr 88 22:47:08 EDT
  4136. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4137.  8245; Thu, 21 Apr 88 22:47:06 EDT
  4138. Received: by BITNIC (Mailer X1.25) id 6021; Thu, 21 Apr 88 22:45:05 EDT
  4139. Date:         Tue, 19 Apr 88 14:43:00 MET
  4140. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4141. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4142. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  4143. Subject:      more comments on O. Stolz
  4144. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4145.  
  4146. Dear list subscribers
  4147.  
  4148. One should never quote texts from memory. The correct version of
  4149. Leporello's aria from Don Giovanni is:
  4150.  
  4151. Madamina!
  4152. Il catalogo [ questo
  4153. delle belle ch'amh il padron mio;
  4154. un catalogo egli [, ch'ho fatto io;
  4155. osservate, leggete con me!
  4156. In Italia sei cento e quaranta;
  4157. in Alemagna cento e trent'una;
  4158. cento in Francia,
  4159. in Turchia novant'una;
  4160. ma in Ispagna son gik mille e tre!
  4161.  
  4162. This text in Italian contains some accented letters. The question is how
  4163. to transmit this by BITNET correctly. I put carefully (with ISPF/PDF
  4164. CHANGE) the corresponding CP500 codes at the right places, hoping that
  4165. you could at least print it. But that may not work everywhere. I also
  4166. could put in the ISO6937-2 designations (also used by IBM), preceded by
  4167. a & for identification. But this is hard to read. The other way out is
  4168. to devise a notation, that only uses the 94 character set, and is
  4169. suitable for conversion by a little program to the extended local
  4170. printer set. This is what we use here. As long there is universal code
  4171. we should agree on temporary solutions. What is your proposal for
  4172. transmitting texts?
  4173.  
  4174. Madamina!
  4175. Il catalogo &LE13 questo
  4176. delle belle ch'am&LO13 il padron mio;
  4177. un catalogo egli &LE13, ch'ho fatto io;
  4178. osservate, leggete con me!
  4179. In Italia sei cento e quaranta;
  4180. in Alemagna cento e trent'una;
  4181. cento in Francia,
  4182. in Turchia novant'una;
  4183. ma in Ispagna son gi&LA13 mille e tre!
  4184.  
  4185. Madamina!
  4186. Il catalogo \e questo
  4187. delle belle ch'am\o il padron mio;
  4188. un catalogo egli \e, ch'ho fatto io;
  4189. osservate, leggete con me!
  4190. In Italia sei cento e quaranta;
  4191. in Alemagna cento e trent'una;
  4192. cento in Francia,
  4193. in Turchia novant'una;
  4194. ma in Ispagna son gi\a mille e tre!
  4195.  
  4196. The following comments pertain to Mr. Otto Stolz's letter:
  4197.  
  4198. >Moreover, IBM has defined 9 (nine) Country Extented Code Pages (serving
  4199. >17 languages), which contain the characters of GCS 00697 in various per-
  4200. >mutations.  Again, you should make sure that you use the new CECPs.
  4201.  
  4202. What is the relation between these and CP500, and what is the source
  4203. document?
  4204.  
  4205. >Clearly, the next step to be required from IBM must be adapting their
  4206. >language processors to the CECPs.  Recognizing dual EBCDIC codes for
  4207. >some characters, is not enough for the compilers and other applications:
  4208. >as long as there are various EBCDICs (call them CECPs or what you want),
  4209. >you must be able to customize them for the variant to be used|  Folks,
  4210. >please help convincing IBM by sending in as many APARs as you have pro-
  4211. >ducts.  The same holds for other software suppliers.
  4212.  
  4213. This a most unfortunate idea. If people want to adapt compilers to their
  4214. own local or national conventions, it is at their own risk.
  4215.  
  4216. >But now, for the difference between plain text and programs.  In addition
  4217. >............................................
  4218. >Now, you probably understand IBM's reluctance to a single universal CECP.
  4219.  
  4220. This passage is completely incomprehensible to me, because nothing is
  4221. printed here as was presumably intended.
  4222.  
  4223. >BITNET is primarily designed for transferring messages, i.e. plain
  4224. >text.  Let's set a comparatively humble goal, for the moment:
  4225. >      BITNET should transmit any plain text consisting of characters
  4226. >      from the ISO 8859-1 character set (i.e. GCS 00697) sensibly
  4227. >      and undisturbed.
  4228.  
  4229. BITNET is not transmitting characters, but bytes. At receiving a text,
  4230. it has to be interpreted, shown on a screen, or printed. This requires
  4231. a key, as with every coded message. For BITNET there is a default,
  4232. 94-character EBCDIC, not ASCII or ISO8859-1. Any deviations are "subject
  4233. to mutual agreement between the interchange parties", as ISO uses to
  4234. formulate it. This does not mean that use of the other bytes is
  4235. forbidden, only there is no fixed interpretation for them.  As there is
  4236. no agreement between Mr. Stolz and me about the meaning of the codes he
  4237. uses for German letters, I cannot read his German texts.
  4238.  
  4239. >The price for sending out the notes in a local code variant (well, that's
  4240. >the very procedure, most sites are following right now) will be the
  4241. >obligation of translating incoming messages.  So, every site will use at
  4242. >most 9 (of the possible 90) translation tables.  Again, this could be
  4243. >done via SET INPUT and SET OUTPUT, as MM suggested (that's exacly the
  4244. >way, I read notes from USA and elswhere).  Later, the mailer, or RSCS,
  4245. >or some similar software piece, would do the translating for all incoming
  4246. >files, and the end-user will cease bothering with the details.
  4247.  
  4248. Again, this is a misconception. We want to extend the default set of 94
  4249. characters, by a common agreed code table. Like people who pass their
  4250. national border have to speak a different language, we should change our
  4251. computer-using habits, when using BITNET. We are used to speak English
  4252. internationally, we should agree upon one single code system, be it
  4253. computer-English or computer-Esperanto. And if a single code page is
  4254. technically not possible, we should tell the recipient beforehand which
  4255. internationally accepted alternative he is going to receive.
  4256. We do not even need IBM for doing this. We only have to provide a local
  4257. facility to produce the right codes from a local text, and a printer
  4258. with all the necessary characters. All the translate tables required we
  4259. can build ourselves. (The 3800 software, even the non-APA, allows you to
  4260. construct your own character tables.)
  4261.  
  4262. >for a feasable common base of our half-tables.  But, what about IBM's
  4263. >character identifiers, accompanying the GCS and CECP tables?  Instead of
  4264. >"small letter a", we could use "LA01"; instead of "small letter a with
  4265. >grave accent" we say "LA13", and instead of "small diphthong a with e",
  4266. >we have "LA51".
  4267.  
  4268. Those identifiers are not IBM's, but those found in ISO6937-2, with a
  4269. few extensions, such as for the Dutch guilder.
  4270.  
  4271. Yours faithfully, Johan van Wingen
  4272.  
  4273.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  4274.      Mail to                                :
  4275.  P. O. Box 486,  2300AL Leiden, Netherlands :
  4276.  
  4277. 22-Apr-88 09:52:59-EST,3037;000000000001
  4278. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4279. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 22 Apr 88 09:52:54-EST
  4280. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 22 Apr 88 09:52:45 EDT
  4281. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4282.  8564; Fri, 22 Apr 88 09:52:44 EDT
  4283. Received: by BITNIC (Mailer X1.25) id 9098; Fri, 22 Apr 88 09:51:57 EDT
  4284. Date:         Fri, 22 Apr 88 13:19:48 +0200
  4285. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4286. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4287. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  4288. Subject:      Re: BITNET's current mapping
  4289. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4290. In-Reply-To:  Message of Wed, 20 Apr 88 19:09:20 EST from <KESICH@NYUCIMSA>
  4291.  
  4292. >What is BITNET's current ASCII-EBCDIC standard?
  4293. >and where may one obtain a copy?
  4294. >Thanks in advance.
  4295.  
  4296. ASCII/EBCDIC translation on BITNET occurs in gateways  connecting
  4297. it  to  ASCII networks.  For long,  WISCVM drained a lot  of  the
  4298. public  traffic  (from which it died).  Successors probably  have
  4299. inherited  the same tables.  ASCII end nodes deal with their  own
  4300. requirements.
  4301. I  have found WISCVM tables matching standard CMS KERMIT  tables,
  4302. dumped below, as well as many other products and consequent ASCII
  4303. data  stored  on servers.  Probably many other gateways  use  the
  4304. same.
  4305. These tables have been tested with UUENCODED data,  involving the
  4306. 95 characters, that's all but control codes and DEL.
  4307. Focus on A->E, E->A has a couple of non-revertible additions.
  4308. Sorry for a straight dump only, this has to be a quick answer.
  4309.  
  4310. Andr)
  4311.  
  4312. TDUMP A (ASCII -> EBCDIC)
  4313. 00010203 372D2E2F 1605250B 0C0D0E0F
  4314. 10111213 3C3D3226 18193F27 1C1D1E1F
  4315. 405A7F7B 5B6C507D 4D5D5C4E 6B604B61
  4316. F0F1F2F3 F4F5F6F7 F8F97A5E 4C7E6E6F
  4317. 7CC1C2C3 C4C5C6C7 C8C9D1D2 D3D4D5D6
  4318. D7D8D9E2 E3E4E5E6 E7E8E9AD E0BD5F6D
  4319. 79818283 84858687 88899192 93949596
  4320. 979899A2 A3A4A5A6 A7A8A9C0 4FD0A107
  4321. 00010203 372D2E2F 1605250B 0C0D0E0F
  4322. 10111213 3C3D3226 18193F27 1C1D1E1F
  4323. 405A7F7B 5B6C507D 4D5D5C4E 6B604B61
  4324. F0F1F2F3 F4F5F6F7 F8F97A5E 4C7E6E6F
  4325. 7CC1C2C3 C4C5C6C7 C8C9D1D2 D3D4D5D6
  4326. D7D8D9E2 E3E4E5E6 E7E8E9AD E0BD5F6D
  4327. 79818283 84858687 88899192 93949596
  4328. 979899A2 A3A4A5A6 A7A8A9C0 4FD0A107
  4329.  
  4330. TDUMP E (EBCDIC -> ASCII)
  4331. 00010203 0009007F 0000000B 0C0D0E0F
  4332. 10111213 00000800 18190000 1C1D1E1F
  4333. 00000000 000A171B 00000000 00050607
  4334. 00001600 00000004 00000000 1415001A
  4335. 20000000 00000000 00005C2E 3C282B7C
  4336. 26000000 00000000 00002124 2A293B5E
  4337. 2D2F0000 00000000 00007C2C 255F3E3F
  4338. 00000000 00000000 00603A23 40273D22
  4339. 00616263 64656667 6869007B 00000000
  4340. 006A6B6C 6D6E6F70 7172007D 00000000
  4341. 007E7374 75767778 797A0000 005B0000
  4342. 00000000 00000000 00000000 005D0000
  4343. 7B414243 44454647 48490000 00000000
  4344. 7D4A4B4C 4D4E4F50 51520000 00000000
  4345. 5C005354 55565758 595A0000 00000000
  4346. 30313233 34353637 38397C00 00000000
  4347. 23-Apr-88 22:37:33-EST,1548;000000000001
  4348. Return-Path: <protocols-request@rutgers.edu>
  4349. Received: from rutgers.edu by CU20B.COLUMBIA.EDU with TCP; Sat 23 Apr 88 22:37:28-EST
  4350. Received: by rutgers.edu (5.54/1.15) 
  4351.     id AA25258; Sat, 23 Apr 88 19:15:30 EDT
  4352. Received: by ucbvax.Berkeley.EDU (5.59/1.28)
  4353.     id AA13912; Fri, 22 Apr 88 22:27:13 PDT
  4354. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  4355.     for protocols@rutgers.edu (protocols@rutgers.edu)
  4356.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  4357. Date: 22 Apr 88 20:08:03 GMT
  4358. From: mnetor!utzoo!utgpu!water!watmath!egisin@uunet.uu.net  (Eric Gisin)
  4359. Organization: U of Waterloo, Ontario
  4360. Subject: Re: UUCP over X25 on Sun 3
  4361. Message-Id: <18471@watmath.waterloo.edu>
  4362. References: <287@tauros.UUCP>, <19772@pyramid.pyramid.com>, <20060@pyramid.pyramid.com>
  4363. Sender: protocols-request@rutgers.edu
  4364. To: protocols@rutgers.edu
  4365.  
  4366. In article <20060@pyramid.pyramid.com>, csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:
  4367. > [...]
  4368. > The 7-bit-printable-ASCII restriction comes from international X.25 gateways,
  4369. > many of which insist on swiping the eigth bit for parity or somesuch. A few
  4370. > also do funny mappings of control characters, like munging tabs. If I set up a
  4371. > raw X.25 virtual circuit between here and West Germany, it will be 7 bits and
  4372. > there is nothing I can do about it.
  4373.  
  4374. It's difficult to believe CCITT is so stupid to allow this in X.25 VCs.
  4375. Maybe I'll have one last look at the red book to verify it.
  4376. What happens if one wants to run IP, DECNET, or OSI across such a gateway?
  4377. I guess you don't.
  4378. 26-Apr-88 12:48:20-EDT,1440;000000000001
  4379. Mail-From: SY.FDC created at 26-Apr-88 12:48:17
  4380. Date: Tue 26 Apr 88 12:48:17-EDT
  4381. From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4382. Subject: MacKermit modifications
  4383. To: placeway@TUT.CIS.OHIO-STATE.EDU
  4384. cc: sy.christine@CU20B.COLUMBIA.EDU
  4385. Message-ID: <12393565441.48.SY.FDC@CU20B.COLUMBIA.EDU>
  4386.  
  4387. Paul, here are more people champing at the bit...  Sounds like they're
  4388. working on a pretty old version, but the ISO8859 stuff is a big plus for
  4389. the Europeans.  Any news?  Haven't heard from you for a while, and we're
  4390. starting to get a little anxious...  - Frank
  4391.                 ---------------
  4392.  
  4393. To: hafro!comp-protocols-kermit@uunet.UU.NET
  4394. Path: krafla!frisk
  4395. From: mcvax!rhi.hi.is!frisk@uunet.UU.NET (Fridrik Skulason)
  4396. Newsgroups: comp.protocols.kermit
  4397. Subject: MacKermit modifications
  4398. Date: 25 Apr 88 17:27:12 GMT
  4399. Organization: University of Iceland (RHI)
  4400.  
  4401. Here at the University we have made a few modifications to MacKermit
  4402.  
  4403.          *  #ifdef..#endif for MPW
  4404.          *  Full 8 bit (ISO 8859/1) Terminal emulation support
  4405.         with automatic character set conversion.
  4406.  
  4407. Is anyone else working on similar changes ? If not, do you think someone
  4408. would be interested in receiving our modifications ?
  4409.  
  4410.          Fridrik Skulason          University of Iceland
  4411.          UUCP  frisk@rhi.uucp      BIX  frisk
  4412. -------
  4413. 29-Apr-88 11:41:39-EDT,2968;000000000001
  4414. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4415. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 29 Apr 88 11:41:38-EDT
  4416. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 29 Apr 88 11:38:13 EDT
  4417. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4418.  6897; Fri, 29 Apr 88 11:37:55 EDT
  4419. Received: by BITNIC (Mailer X1.25) id 5773; Fri, 29 Apr 88 11:37:17 EDT
  4420. Date:         Thu, 28 Apr 88 22:10:00 MET
  4421. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4422. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4423. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  4424. Subject:      corrections
  4425. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4426.  
  4427.  
  4428. Dear list subscribers
  4429.  
  4430. Here are a few corrections and additions to my previous letters.
  4431.  
  4432. >printer set. This is what we use here. As long there is universal code
  4433. >we should agree on temporary solutions. What is your proposal for
  4434. >transmitting texts?
  4435.  printer set. This is what we use here. As long there is NO universal
  4436.  code we should agree on temporary solutions. What is your proposal for
  4437.  transmitting texts?
  4438.  
  4439. The translation of Lepoello's aria is:
  4440. Madamina!                            Dear Miss!
  4441. Il catalogo \e questo                Here is the catalog
  4442. delle belle ch'am\o il padron mio;   of the beauties my master courted;
  4443. un catalogo egli \e, ch'ho fatto io; it is a catalog that I made myself;
  4444. osservate, leggete con me!           look, read with me!
  4445. In Italia sei cento e quaranta;      In Italy 640,
  4446. in Alemagna cento e trent'una;       in Germany 131,
  4447. cento in Francia,                    100 in France,
  4448. in Turchia novant'una;               in Turkey 91,
  4449. ma in Ispagna son gi\a mille e tre!  but in Spain it are 1003!
  4450.  
  4451. I hope that the number of entries in IBM's Code Page Catalog is
  4452. considerably less.
  4453.  
  4454. In the following table $o and $O should be moved one column to the right
  4455.  
  4456.   REPRESENTATION OF LETTERS FROM ISO 8859-1 WITH CP500 TABLE
  4457.  
  4458.      4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  4459.  
  4460.  .0                 $o $O
  4461.  .1     /e    /E  a  j        A  J     1
  4462.  .2  ^a ^e ^A ^E  b  k  s     B  K  S  2
  4463.  .3  %a %e %A %E  c  l  t     C  L  T  3
  4464.  .4  \a \e \A \E  d  m  u     D  M  U  4
  4465.  .5  /a /i /A /I  e  n  v     E  N  V  5
  4466.  .6  ~a ^i ~A ^I  f  o  w     F  O  W  6
  4467.  .7  @a %i @A %I  g  p  x     G  P  X  7
  4468.  .8  $c \i $C \I  h  q  y     H  Q  Y  8
  4469.  .9  ~n &s ~N     i  r  z     I  R  Z  9
  4470.  .A
  4471.  .B                          ^o ^u ^O ^U
  4472.  .C              $d &a $D    %o %u %O %U
  4473.  .D              /y    /Y    \o \u \O \U
  4474.  .E              $p &A $P    /o /u /O /U
  4475.  .F                          ~o %y ~O
  4476.  
  4477. Best regards, Johan van Wingen
  4478.  
  4479.  
  4480.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  4481.      Mail to                                :
  4482.  P. O. Box 486,  2300AL Leiden, Netherlands :
  4483.  
  4484. 10-May-88 08:17:46-EDT,3091;000000000001
  4485. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4486. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 10 May 88 08:17:44-EDT
  4487. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 10 May 88 08:15:05 EDT
  4488. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4489.  7650; Tue, 10 May 88 08:15:04 EDT
  4490. Received: by BITNIC (Mailer X1.25) id 7519; Tue, 10 May 88 08:16:11 EDT
  4491. Date:         Tue, 10 May 88 13:08:00 MET
  4492. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4493. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4494. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  4495. Subject:      EBCDIC-1992
  4496. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4497.  
  4498. Dear list subscribers
  4499.  
  4500. After having read again the whole of the discussion I think a solution
  4501. can be proposed that is realizible without asking IBM or our managements
  4502. for any important changes.
  4503.  
  4504. 1.  We take ISO8859-1 as is, other parts are for later consideration.
  4505. 2.  We agree on a single, universal and international version (code
  4506.     page) of EBCDIC, that contains all the characters from ISO8859-1.
  4507.     This we call EBCDIC-1992.
  4508. 3.  We agree on a single translate table between ISO8859-1 and
  4509.     EBCDIC-1992. (It is clear that the code page determines the
  4510.     translate table, or vice versa. Which is fixed first does not really
  4511.     matter, it depends on what is the more difficult: changing the
  4512.     existing translate tables, or the code pages.)
  4513.  
  4514. These points I call the 1992-convention. (The details are subject to
  4515. further discussion.)  People adhering to this convention will send and
  4516. receive their EARN/BITNET files using EBCDIC-1992. This requires at an
  4517. IBM installation:
  4518.  
  4519. a.  a program that that is able to translate files from EBCDIC-1992 to
  4520.     local EBCDIC (such programs I write in SNOBOL straight away) and
  4521.     back.
  4522. b.  a printing facility providing all the 190 characters from ISO8859-1.
  4523. c.  a typing convention enabling the user to type transliterations of
  4524.     the 190 characters, using only 47 keys on a normal keyboard.
  4525. d.  a program converting the transliterations to local EBCDIC or
  4526.     EBCDIC-1992 (see c.).
  4527.  
  4528. Except for the printer, this scheme does not require any new hardware on
  4529. the IBM side, (I know too little from VAX to tell what has to be done
  4530. there. Anyway, the conversion table must be installed.)
  4531. One advantage of choosing a version of EBCDIC for text interchange is
  4532. that texts appearing on the screen are readable to a large extent,
  4533. because EBCDIC-1992 does not change the simple Latin letters, the digits
  4534. and many specials.
  4535.  
  4536. It may be that after much negotiation with IBM a better solution will
  4537. turn up, but that can last for years. We need something now. I am
  4538. awaiting your reaction.
  4539.  
  4540. Yours faithfully, Johan van Wingen
  4541.  
  4542.  
  4543.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  4544.      Mail to                                :
  4545.  P. O. Box 486,  2300AL Leiden, Netherlands :
  4546.  
  4547. 17-May-88 17:05:13-EDT,4311;000000000001
  4548. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4549. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 17 May 88 17:05:09-EDT
  4550. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 17 May 88 17:02:29 EDT
  4551. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4552.  7118; Tue, 17 May 88 17:02:27 EDT
  4553. Received: by BITNIC (Mailer X1.25) id 0255; Tue, 17 May 88 16:41:08 EDT
  4554. Date:         Tue, 17 May 88 11:31:27 CDT
  4555. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4556. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4557. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  4558. Subject:      Extended character sets, translation table implemented
  4559. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4560.  
  4561. Remembering Howard Gilbert's warning "A curse upon anyone who actually
  4562. puts them into production before the community as a whole agrees to
  4563. them," I have been careful not to put them into production yet, but we
  4564. have now successfully installed for testing the translate tables for ISO
  4565. 8859/1 and the U.S. Country Extended Code Page which were discussed
  4566. here.  The translations for graphics are those proposed by Howard
  4567. Gilbert in the message posted on 15 march 1988 (original date 3
  4568. September 1987) as modified in the subsequent discussion and summarized
  4569. in Alain Fontaine's posting of 25 March 1987.  Control characters,
  4570. including DUP and FM, are handled as in the standard Yale ASCII / IBM
  4571. 7171 tables (except that CR, NL, EM, and FF are *not* given their own
  4572. code points in the protocol converter:  any device that needs the
  4573. special handling provided by Yale ASCII will have to use the vanilla
  4574. tables).
  4575.  
  4576. So far, so good.  I had a little trouble getting the 7171 to use the
  4577. correct (modified) tables, and of course they take a Kb or so of
  4578. precious RAM, but they seem to work correctly.  When I load the upper
  4579. half of ISO 8859/1 into my IBM3163 and display a hex chart, it looks
  4580. like the U.S. Country Extended Code Page distributed last August at
  4581. SHARE.  (Will someone who knows please tell those of us who can't get
  4582. the documents whether the US CECP is Code Page 500 or Code Page 037, or
  4583. what?  If you want, I'll send you a list of code points and their
  4584. graphics, but somebody *please* tell me what code page we've
  4585. implemented!)
  4586.  
  4587. Results:  one problem so far.  Because ISO, against its own rules (ISO
  4588. 2022), put a graphic in position FF, which cannot be mapped into a
  4589. seven-bit data stream, that graphic (y-with-diaeresis, EBCDIC DF in the
  4590. US CECP) does not show up on my screen.
  4591.  
  4592. Questions for the group:
  4593.  
  4594. 1 should EBCDIC DF be returned as an illegal graphic, or what?  (I'm
  4595. letting it be, even though it doesn't display.  So far it doesn't seem
  4596. to be blowing anything up.)
  4597.  
  4598. 2 should any compromises be made with the 94-character ASCII-to-EBCDIC
  4599. translations users have become accustomed to?  That is, should the
  4600. 188-character translate tables allow users to type ASCII carat and get
  4601. EBCDIC logical not, or should they insist on the new ASCII logical not?
  4602. In other words, should the 188-character tables be a superset of the
  4603. 94-character tables, or not?
  4604.  
  4605. (I thought about this, at the last minute, and then decided I didn't
  4606. want to have to explain, ten years from now, that we had a chance for a
  4607. 1-to-1 ASCII-EBCDIC conversion and passed it up because users were used
  4608. to typing '5' and getting '^'.  That's "typing '&carat.' and getting
  4609. '&logicalnot.'," for those who aren't looking at the same kind of screen
  4610. I am.Y  And the brackets I see are BA and BB -- apologies to those with
  4611. TN print trains.Y  So I implemented the table as it was discussed here,
  4612. no compromises with the old compromise solutions.  Before we make this
  4613. public here, I expect to write a couple execs to set and clear various
  4614. input and output mappings for CMS and Xedit, so people can simulate
  4615. the 94-character translate tables in CMS and Xedit, when they don't
  4616. need the whole thing.)
  4617.  
  4618. Anyone interested in copies of the code (host-based Series/1 and
  4619. 7171 macros) can have them if you send me your name and Bitnet address.
  4620.  
  4621. Michael Sperberg-McQueen, University of Illinois at Chicago
  4622. 18-May-88 06:44:16-EDT,4044;000000000001
  4623. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4624. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 18 May 88 06:44:12-EDT
  4625. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 18 May 88 06:41:33 EDT
  4626. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4627.  7674; Wed, 18 May 88 06:41:31 EDT
  4628. Received: by BITNIC (Mailer X1.25) id 6538; Wed, 18 May 88 06:42:30 EDT
  4629. Date:         Wed, 18 May 88 11:15:18 +0200
  4630. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4631. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4632. Comments:     Resent-From: Andre PIRARD <A-PIRARD@BLIULG11>
  4633. Comments:     Originally-From: Andre PIRARD <A-PIRARD@BLIULG11>
  4634. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  4635. Subject:      Re: Extended character sets, translation table implemented
  4636. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4637. In-Reply-To:  Your message of Tue, 17 May 88 11:31:27 CDT
  4638.  
  4639. >precious RAM, but they seem to work correctly.  When I load the upper
  4640. >half of ISO 8859/1 into my IBM3163 and display a hex chart, it looks
  4641. >like the U.S. Country Extended Code Page distributed last August at
  4642. >SHARE.  (Will someone who knows please tell those of us who can't get
  4643. >the documents whether the US CECP is Code Page 500 or Code Page 037, or
  4644. >what?  If you want, I'll send you a list of code points and their
  4645. >graphics, but somebody *please* tell me what code page we've
  4646. >implemented!)
  4647.  
  4648. In theory, your US CECP is code page 037. I may have a quick check if you
  4649. like. But 037 has exclamation mark at 5A. 500 has closed bracket there.
  4650. To my dismay, I am bound to implement cp 500, but I'll make it comment
  4651. switchable between cp 037 and cp 500.
  4652.  
  4653. >Results:  one problem so far.  Because ISO, against its own rules (ISO
  4654. >2022), put a graphic in position FF, which cannot be mapped into a
  4655. >seven-bit data stream, that graphic (y-with-diaeresis, EBCDIC DF in the
  4656. >US CECP) does not show up on my screen.
  4657.  
  4658. You're right! Johan will probably wake up on this one. I'll forward the
  4659. question to someone of our brains not on the list.
  4660.  
  4661. >1 should EBCDIC DF be returned as an illegal graphic, or what?  (I'm
  4662. >letting it be, even though it doesn't display.  So far it doesn't seem
  4663. >to be blowing anything up.)
  4664.  
  4665. I think you relate to DF as being the RATS code to which invalid EBCDIC
  4666. codes are translated. It is finally output to the terminal as whatever
  4667. the terminal table contains at offset DF. So, in my mind, DF can be replaced
  4668. by anything else, unless there is some hard coded test for that value
  4669. somewhere in the code, but I see no reason why.
  4670. In fact, this is really the heart of the problem. Which codes in the RATS
  4671. or terminal table has a hard coded value?
  4672. It seems the two-level translation allows for choosing any value in the RATS,
  4673. which is the 7171 own internal hidden business.
  4674. So, choosing it to be ISO8859 is a matter of convenience.
  4675. A couple of deviations here and there won't hurt if clearly documented.
  4676.  
  4677. >2 should any compromises be made with the 94-character ASCII-to-EBCDIC
  4678. >translations users have become accustomed to?  That is, should the
  4679. >188-character translate tables allow users to type ASCII carat and get
  4680. >EBCDIC logical not, or should they insist on the new ASCII logical not?
  4681. >In other words, should the 188-character tables be a superset of the
  4682. >94-character tables, or not?
  4683.  
  4684. I hate it. You have to switch to APL mode to reach ISO2022 haven't you?
  4685. I prefer to implement two modes:
  4686. 1) non-APL for older terminals, for which installation dependent compromises
  4687. are acceptable for convenience.
  4688. 2) APL mode switched to by intelligent terminals (mostly micros) which have
  4689. their elaborate keyboard redefinition anyway.
  4690. Else, one will one day find true ISO hardware and start the story all over
  4691. again.
  4692. A standard is a standard. And to be a little bit incompatible ...
  4693.  
  4694. Any comment?
  4695.  
  4696. Andr).
  4697. 18-May-88 13:35:57-EDT,4516;000000000001
  4698. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4699. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 18 May 88 13:35:43-EDT
  4700. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 18 May 88 13:33:02 EDT
  4701. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4702.  8234; Wed, 18 May 88 13:33:00 EDT
  4703. Received: by BITNIC (Mailer X1.25) id 2709; Wed, 18 May 88 13:33:52 EDT
  4704. Date:         Wed, 18 May 88 10:46:13 CDT
  4705. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4706. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4707. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  4708. Subject:      Further on CP 037 DF = ISO 8859/5 FF = (SO) 7F.  Also APL mode
  4709. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4710.  
  4711. Many thanks to Andre (Andr)) Pirard for his comments on my last posting.
  4712. He is right that the special treatment of EBCDIC DF (= ISO8859/1 FF)
  4713. could reflect the special treatment of code point DF inside the Series/1
  4714. or 7171, instead of or in addition to complications for the seven-bit
  4715. terminal data stream that now must accept a 7F (in the G1 set) as a
  4716. graphic.
  4717.  
  4718. To test this hypothesis, I altered the translation table on our test
  4719. Series/1, from:
  4720.  
  4721.     EBCDIC         Series/1       Terminal
  4722.     8E (thorn)     DE             (G1) 7E (thorn) = ISO8859/1 FE
  4723.     DF (y-diaer.)  DF             (G1) 7F (y-diaer.) = ISO    FF
  4724.  
  4725. to:
  4726.  
  4727.     EBCDIC         Series/1       Terminal
  4728.     8E (thorn)     DF             (G1) 7E (thorn) = ISO8859/1 FE
  4729.     DF (y-diaer.)  DE             (G1) 7F (y-diaer.) = ISO    FF
  4730.  
  4731. In both cases, lowercase thorn displayed properly; y with diaeresis did
  4732. not display.  So we can infer that the internal code point DF is not a
  4733. magic number that is used by other portions of the code, and that my
  4734. trouble displaying y-diaeresis results from its position in the
  4735. ISO8859/1 table.
  4736.  
  4737. It seems likely that the Series/1 is actually sending out the desired
  4738. shift-out + 7F to the terminal; I don't have a line monitor but putting
  4739. the terminal into transparent mode allows me to see that it is receiving
  4740. something, which it displays the same way as it displays a 7F.
  4741.  
  4742. But the terminal, in normal operation, simply ignores ASCII DEL (7F)
  4743. when it is received, and so I cannot make ISO8859/1 FF display.  When
  4744. equipment built to handle ISO8859 comes out, I assume this will not be a
  4745. problem (unless one's data line refuses to transmit DEL); a PC running
  4746. Yterm, similarly, may have no trouble with the 7F.  It will only be
  4747. devices which rely on the ISO 2022 definition of eight-bit sets which
  4748. will have trouble.
  4749.  
  4750. 2.  APL mode.
  4751.  
  4752. > You have to switch to APL mode to reach ISO2022 haven't you?
  4753.  
  4754. I am not quite sure what is meant.  On the IBM3163 I must hit an ALT-CHR
  4755. key (a control-key combination) to get to the G1 set; not too hard.  In
  4756. the VM host I do *not* need to set the CP APL mode, or SET APL ON in
  4757. Xedit.  When I do issue a SET APL ON in Xedit, I hang the Series/1, for
  4758. reasons I don't understand.  Probably it has to do with the fact that we
  4759. use SI/SO, but not the standard 3278 or 3277 APL conventions.
  4760.  
  4761. The tables we are using do not emulate either the 3277 or the 3278 APL
  4762. support -- that is, they do not insert 1D (IFS) or 08 (Graphic Escape)
  4763. in front of the extended characters when handing characters to the host,
  4764. nor do they expect 1D or 08 in front of the characters when taking a
  4765. write from the host.  That may be a dumb way to do it, and it certainly
  4766. makes the protocol converter look different from a real 3278 or 3277.
  4767. But it is simpler to see what is going on inside the protocol converter,
  4768. and 3277s and 3278s don't support code page 037 anyhow.  So I followed
  4769. the lead of Tom Denier (sp?) at Penn, from whom we got the tables for
  4770. support of the ALA character set.  Seems to work okay, and I don't
  4771. have to issue any special Xedit commands.  (We did have to change
  4772. the Xedit module to treat hex 41 through FE as displayable characters.
  4773. When we made FF displayable, it caused terminal errors and dropped
  4774. us into line-mode Xedit, so we backed out of that.  This risks data
  4775. loss if extended-EBCDIC files are edited on real 3270 devices, and
  4776. I keep expecting data loss if they are edited on terminals which use
  4777. the standard tables.  But so far, we haven't had any data lost at all.
  4778. Knock on wood!)
  4779.  
  4780. Michael Sperberg-McQueen
  4781. 19-May-88 10:01:05-EDT,2066;000000000001
  4782. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4783. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 19 May 88 10:00:44-EDT
  4784. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 19 May 88 09:50:44 EDT
  4785. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4786.  9434; Thu, 19 May 88 09:50:43 EDT
  4787. Received: by BITNIC (Mailer X1.25) id 7390; Thu, 19 May 88 09:51:39 EDT
  4788. Date:         Thu, 19 May 88 13:55:52 +0200
  4789. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4790. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4791. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  4792. Subject:      Re: Further on CP 037 DF = ISO 8859/5 FF = (SO) 7F.  Also APL
  4793.               mode
  4794. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4795. In-Reply-To:  Message of Wed, 18 May 88 10:46:13 CDT from <U18189@UICVM>
  4796.  
  4797. >> You have to switch to APL mode to reach ISO2022 haven't you?
  4798. >
  4799. >I am not quite sure what is meant.  On the IBM3163 I must hit an ALT-CHR
  4800. >key (a control-key combination) to get to the G1 set; not too hard.  In
  4801. >the VM host I do *not* need to set the CP APL mode, or SET APL ON in
  4802. >Xedit.  When I do issue a SET APL ON in Xedit, I hang the Series/1, for
  4803. >reasons I don't understand.  Probably it has to do with the fact that we
  4804. >use SI/SO, but not the standard 3278 or 3277 APL conventions.
  4805.  
  4806. I mean activating APL mode on the 7171 or S/1 only. This, on the 7171,
  4807. uses an alternative set of terminal translate tables. My hope is that
  4808. it would make two translation modes possible. My fear is that it would
  4809. trigger the host input APL escaping too. And I would neither like nor
  4810. dare turning on APL mode on the host.
  4811. The converters switch to and from APL mode with the setup functions
  4812. invoked by <introducer (usually ESC)> "accent" "lower/upper letter A".
  4813. Is that your ALT-CHR or does it mean the way you enter SO, which should
  4814. be ctrl-N too isn't it?
  4815.  
  4816. Andr).
  4817. 19-May-88 12:45:19-EDT,1637;000000000001
  4818. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4819. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 19 May 88 12:45:14-EDT
  4820. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 19 May 88 12:42:36 EDT
  4821. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4822.  0126; Thu, 19 May 88 12:42:35 EDT
  4823. Received: by BITNIC (Mailer X1.25) id 9131; Thu, 19 May 88 12:44:06 EDT
  4824. Date:         Thu, 19 May 88 17:11:00 MET
  4825. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4826. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4827. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  4828. Subject:      iso2022
  4829. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4830.  
  4831. Dear list subscribers
  4832.  
  4833. Just a small comment for the time being.
  4834.  
  4835. >Results:  one problem so far.  Because ISO, against its own rules (ISO
  4836. >2022), put a graphic in position FF, which cannot be mapped into a
  4837. >seven-bit data stream, that graphic (y-with-diaeresis, EBCDIC DF in the
  4838. >US CECP) does not show up on my screen.
  4839.  
  4840. ISO8859 is NOT an 8-bit code extension of a 7-bit code, but an 8-bit
  4841. code in itself. Rules for 8-bit codes have been defined in ISO4873, not
  4842. in ISO 2022. It is allowed to take here a 94 or a 96 character set for
  4843. G1. If the 7171 cannot manage 8-bit codes, the worse for the 7171.
  4844.  
  4845. Yours faithfully, Johan van Wingen
  4846.  
  4847.  
  4848.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  4849.      Mail to                                :
  4850.  P. O. Box 486,  2300AL Leiden, Netherlands :
  4851.  
  4852. 19-May-88 18:25:01-EDT,6767;000000000001
  4853. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4854. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Thu 19 May 88 18:24:58-EDT
  4855. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Thu, 19 May 88 18:22:21 EDT
  4856. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4857.  0575; Thu, 19 May 88 18:22:18 EDT
  4858. Received: by BITNIC (Mailer X1.25) id 4167; Thu, 19 May 88 18:22:12 EDT
  4859. Date:         Thu, 19 May 88 12:49:00 CDT
  4860. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4861. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4862. From:         Rick Troth <TROTH%TAMCBA.BITNET@CUVMA.COLUMBIA.EDU>
  4863. Subject:      Headache
  4864. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4865.  
  4866.         I think it just hit me ...
  4867.  
  4868.         We have at least three "schemes" (code pages) for EBCDIC here
  4869. at Texas A&M.  This does not count various ASCII character sets.
  4870.  
  4871.         1) IBM 3192, 3179G   (newer terminals)
  4872.            the "ISO set",  has all (most of) the ISO8859/1 characters
  4873.  
  4874.         2) IBM 3180, 3279G, 3179   (older terminals)
  4875.            the "3180 set"
  4876.  
  4877.         3) IBM 7171, TN Print Chain, JNET (VAX), Kermit, WISCNET
  4878.            the "7171 set".
  4879.  
  4880.         I here include a "raw EBCDIC" file with illustrations of how it
  4881. displays on these three main groups of terminals.  The big problem is not that
  4882. 7171, WISCNET, et al, deviate from ISO, they were intended for mapping 7-bit
  4883. ASCII to "some points" of EBCDIC (and thus are excused).  But the real
  4884. concern is that this 3180 set deviates everywhere.  It is wierd ... has
  4885. duplications all over the place!  What do we call these sets?  If the ISO set
  4886. is CP037, then what is the 3180 set?
  4887.  
  4888. * note: I used ^ in place of 5 for the sake of 7171 users.
  4889.  
  4890.  Raw EBCDIC    How does this display on your screen?
  4891.  
  4892.        0   1  2   3   4   5   6   7   8   9   A   B   C   D   E   F
  4893.    0                                                      
  4894.    1                                                
  4895.    2                  
  4896.                               
  4897.    3                                                
  4898.    4       &   a      k         b   +          .   <   (   +   |
  4899.    5   &   )   *      [   %      c   (      !   $   *   )   ;   ^
  4900.    6   -   /   _   \      ]   ^         ,   :   ,   %   _   >   ?
  4901.    7   W         0   1   2   |   V   {   `   :   #   @   '   =   "
  4902.    8   x   a   b   c   d   e   f   g   h   i      $   s   /   .   E
  4903.    9       j   k   l   m   n   o   p   q   r         N      q   ~
  4904.    A   H   ~   s   t   u   v   w   x   y   z   o   @   Z   [   r   y
  4905.    B   5   6   }   7   8   9   f   ;   <   =      Y   ?   ]   X   D
  4906.    C   {   A   B   C   D   E   F   G   H   I   K   J   >   h   l   m
  4907.    D   }   J   K   L   M   N   O   P   Q   R   !   -   u   t   #   
  4908.    E   \   g   S   T   U   V   W   X   Y   Z             i   d   Q
  4909.    F   0   1   2   3   4   5   6   7   8   9   3   w   p   z   '   
  4910.  
  4911.  IBM 3179G, 3192
  4912.  
  4913.        0   1   2   3   4   5   6   7   8   9   A   B   C   D   E   F
  4914.    0  --  --  --  --  --  -;  --  --  --  --  --  --  --  --  --  --
  4915.    1  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4916.    2  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4917.    3  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4918.    4          ^a  %a  \a  /a  ~a  @a  $c  ~n  /c   .   <   (   +   |
  4919.    5   &  /e  ^e  %e  \e  /i  ^i  %i  \i  $s   !   $   *   )   ;   ^
  4920.    6   -   /  ^A  %A  \A  /A  ~A  @A  $C  ~N  -|   ,   %   _   >   ?
  4921.    7  $o  /E  ^E  %E  \E  /I  ^I  %I  \I   `   :   #   @   '   =   "
  4922.    8  $O   a   b   c   d   e   f   g   h   i  <<  >>  -d  /y  $P  +-
  4923.    9  ^0   j   k   l   m   n   o   p   q   r  -a  -o  $a  /,  $A  @X
  4924.    A  /u   ~   s   t   u   v   w   x   y   z  !!  ??  -D  /Y  $p  @R
  4925.    B  /\  -L  -Y  ^.  -f  /s  |P  14  12  34  |(  |)  ^_  ..  //  v=
  4926.    C   {   A   B   C   D   E   F   G   H   I   -  ^o  %o  \o  /o  ~o
  4927.    D   }   J   K   L   M   N   O   P   Q   R  ^1  ^u  %u  \u  /u  ~u
  4928.    E   \       S   T   U   V   W   X   Y   Z  ^2  ^O  %O  \O  /O  ~O
  4929.    F   0   1   2   3   4   5   6   7   8   9  ^3  ^U  %U  \U  /U  ~U
  4930.  
  4931.  IBM 3279G, 3179, 3180
  4932.  
  4933.        0   1  2   3   4   5   6   7   8   9   A   B   C   D   E   F
  4934.    0  --  --  --  --  --  -;  --  --  --  --  --  --  --  --  --  --
  4935.    1  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4936.    2  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4937.    3  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4938.    4      |(  |)  -L  -Y  Pt  $X  $s  /s  ^-  /c   .   <   (   +   |
  4939.    5   &  ^0  \/  /\  ..  //  /,  \a  \e  \i   !   $   *   )   ;   ^
  4940.    6   -   /  \o  \u  ~a  ~o  %y  \a  \e  /e  -|   ,   %   _   >   ?
  4941.    7  \i  \o  \u  %u  $c  %a  %e  %i  %o   `   :   #   @   '   =   "
  4942.    8  %u   a   b   c   d   e   f   g   h   i  ^a  ^e  ^i  ^o  ^u  /a
  4943.    9  /e   j   k   l   m   n   o   p   q   r  /i  /o  /u  ~n  \A  \E
  4944.    A  \I   ~   s   t   u   v   w   x   y   z  \O  \U  ~A  ~O   Y   A
  4945.    B   E   E   I   O   U   Y   C  %A  %E  %I  %O  %U  ^A  ^E  ^I  ^O
  4946.    C   {   A   B   C   D   E   F   G   H   I  ^U  /A  /E  /I   l   m
  4947.    D   }   J   K   L   M   N   O   P   Q   R  /O  /U  ~N   t   #   
  4948.    E   \  $a   S   T   U   V   W   X   Y   Z  $o  @a  $c   i   d  -;
  4949.    F   0   1   2   3   4   5   6   7   8   9  $A  $O  @A  $C  -*   
  4950.  
  4951.  IBM 7171, TN Print Chain
  4952.  
  4953.        0   1  2   3   4   5   6   7   8   9   A   B   C   D   E   F
  4954.    0  --  --  --  --  --   ;  --  --  --  --  --  --  --  --  --  --
  4955.    1  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4956.    2  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4957.    3  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
  4958.    4      --  --  --  --  --  --  --  --  --   \   .   <   (   +   |
  4959.    5   &  --  --  --  --  --  --  --  --  --   !   $   *   )   ;  /
  4960.    6   -   /  --  --  --  --  --  --  --  --   |   ,   %   _   >   ?
  4961.    7  --  --  --  --  --  --  --  --  --   `   :   #   @   '   =   "
  4962.    8  --   a   b   c   d   e   f   g   h   i  --  --  --  --  --  --
  4963.    9  --   j   k   l   m   n   o   p   q   r  --  --  --  --  --  --
  4964.    A  --   ~   s   t   u   v   w   x   y   z  --  --  --  |(  --  --
  4965.    B  --  --  --  --  --  --  --  --  --  --  --  --  --  |)  --  --
  4966.    C   {   A   B   C   D   E   F   G   H   I  --  --  --  --  --  --
  4967.    D   }   J   K   L   M   N   O   P   Q   R  --  --  --  --  --  --
  4968.    E   \  --   S   T   U   V   W   X   Y   Z  --  --  --  --  --  --
  4969.    F   0   1   2   3   4   5   6   7   8   9  --  --  --  --  --  --
  4970.  
  4971. 20-May-88 08:04:17-EDT,1628;000000000001
  4972. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  4973. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 08:04:14-EDT
  4974. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 08:01:38 EDT
  4975. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  4976.  0874; Fri, 20 May 88 08:01:37 EDT
  4977. Received: by BITNIC (Mailer X1.25) id 2067; Fri, 20 May 88 08:02:51 EDT
  4978. Date:         Fri, 20 May 88 13:38:18 +0200
  4979. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4980. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  4981. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  4982. Subject:      Re: iso2022
  4983. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  4984. In-Reply-To:  Message of Thu, 19 May 88 17:11:00 MET from <MOSGLA@HLERUL2>
  4985.  
  4986. >ISO8859 is NOT an 8-bit code extension of a 7-bit code, but an 8-bit
  4987. >code in itself. Rules for 8-bit codes have been defined in ISO4873, not
  4988. >in ISO 2022. It is allowed to take here a 94 or a 96 character set for
  4989. >G1. If the 7171 cannot manage 8-bit codes, the worse for the 7171.
  4990.  
  4991. Sorry Johan, but both the way ISO looks (80-9F free) and information from
  4992. an IBM representative make it clear it was designed to be transmitted
  4993. 7-bit wide. Else, it would have been a really lucky coincidence.
  4994. I wonder which poor people this character affects.
  4995.  
  4996. I agree with you 7-bit communication is nonsense. And parity is a hoax.
  4997. But the 7171's are there next room. And they are dreadfully useful.
  4998.  
  4999. Andr).
  5000. 20-May-88 12:14:46-EDT,1571;000000000001
  5001. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5002. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 12:14:40-EDT
  5003. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 12:11:57 EDT
  5004. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5005.  1153; Fri, 20 May 88 12:11:55 EDT
  5006. Received: by BITNIC (Mailer X1.25) id 5193; Fri, 20 May 88 12:13:03 EDT
  5007. Date:         Fri, 20 May 88 11:57:31 EDT
  5008. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5009. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5010. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  5011. Subject:      Re: iso2022
  5012. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5013. In-Reply-To:  Your message of Fri, 20 May 88 13:38:18 +0200
  5014.  
  5015. ISO 8859-1 is an 8-bit code.  I have not seen any standards on how it
  5016. is to be transmitted over a communications wire.  It might be 8 data plus
  5017. parity.  However, the issue you are discussing is implementation using
  5018. existing equipment.  When you try to implement ISO 8859-1 characters using
  5019. the 7171 or Yale ASCII Comm System on an IBM Series/1, then because these
  5020. controllers were programmed for 7 data bits, you must use the ISO 2022
  5021. or ANSI X3.41 protocols to use the characters in columns 10 to 15.  This
  5022. is a different problem than transmitting an 8-bit code.  How does DEC
  5023. (Digital Equipment Corporation) do it with the new VT300 series of terminals?
  5024.  
  5025. Ed Hart
  5026. 20-May-88 13:55:09-EDT,3061;000000000001
  5027. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5028. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 13:55:07-EDT
  5029. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 13:52:31 EDT
  5030. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5031.  1254; Fri, 20 May 88 13:52:27 EDT
  5032. Received: by BITNIC (Mailer X1.25) id 7552; Fri, 20 May 88 13:53:10 EDT
  5033. Date:         Fri, 20 May 88 11:53:56 CDT
  5034. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5035. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5036. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMA.COLUMBIA.EDU>
  5037. Subject:      7-bit and 8-bit sets
  5038. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5039.  
  5040. Many thanks to Johan van Wingen for his note.  I apologize for my error
  5041. in ascribing the rules on 8-bit code structures to ISO 2022.  I once
  5042. worked at a site where we had a fairly good collection of the ISO
  5043. standards, but I don't have copies handy here, so my memory can slip.
  5044. Has ISO 4873 been revised in the last ten years or so?  And does 2022
  5045. really not talk at all about 8-bit sets?  I was very sure that the
  5046. ISO standards I read, when I studied them all a few years back,
  5047. prohibited use of A0 and FF for graphics.
  5048.  
  5049. The American standard which I think is the equivalent of ISO 2022
  5050. (and which I thought was *compatible* with all the relevant ISO
  5051. standards, please correct me if I'm wrong) is ANSI X3.41 - 1974
  5052. ("American National Standard Code Extension Techniques for Use with the
  5053. 7-Bit Coded Character Set of American National Standard Code for
  5054. Information Interchange").  ANSI X3.41- 1974 (which I do have in front
  5055. of me) does define the structure of 8-bit sets (despite its name) and
  5056. provides for a 94-graphic G1 set:  "The 8-bit code table consists of an
  5057. ordered set of controls and graphic characters grouped as follows [...]:
  5058. [...] (5) A set of ninety-four graphic characters allocated to columns
  5059. 10-15, subject to the exception of positions 10/0 and 15/15"  (Section
  5060. 6.2).  So even if ISO 8859/1 conforms with ISO standards, it doesn't
  5061. conform with ANSI X3.41 unless ANSI has revised it very recently.
  5062.  
  5063. I'm not sure I understand Ed Hart's note.  He is right, of course, that
  5064. we have to use ANSI X3.41 to transmit 8-bit codes over 7-bit wire.  But
  5065. how is that "a different problem than transmitting an 8-bit code"?  Part
  5066. of ANSI X3.41 *is* the definition of how to transmit 8-bit codes over
  5067. 7-bit lines, stipulating that SI should be sent to switch from the G0
  5068. graphic set to the G1 graphic set, SO to switch back.  (Switching
  5069. between C0 and C1, the two sets of controls, seems to be handled by
  5070. escape sequences not SI/SO.)  Since A0 and FF are explicitly not part of
  5071. the G1 set, ANSI X3.41 provides (sec. 9.3) that they should be
  5072. represented, if they have to be, by a private escape sequence.
  5073.  
  5074. Michael Sperberg-McQueen, University of Illinois at Chicago
  5075. 20-May-88 14:50:08-EDT,3543;000000000001
  5076. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5077. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 14:50:02-EDT
  5078. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 14:47:22 EDT
  5079. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5080.  1400; Fri, 20 May 88 14:47:19 EDT
  5081. Received: by BITNIC (Mailer X1.25) id 8740; Fri, 20 May 88 14:48:11 EDT
  5082. Date:         Fri, 20 May 88 13:03:29 CDT
  5083. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5084. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5085. From:         Phil Howard KA9WGN <PHIL%UIUCVMD.BITNET@CUVMA.COLUMBIA.EDU>
  5086. Subject:      Re: 7-bit and 8-bit sets
  5087. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5088. In-Reply-To:  Your message of Fri, 20 May 88 11:53:56 CDT
  5089.  
  5090. > From:         Michael Sperberg-McQueen <U18189@UICVM>
  5091. >                                                        .....  I once
  5092. > worked at a site where we had a fairly good collection of the ISO
  5093. > standards, but I don't have copies handy here, so my memory can slip.
  5094.  
  5095. This is an interesting issue.  I have found it to be difficult to get hold
  5096. of ANY ISO documentation at a reasonable price.
  5097.  
  5098. ANSI documents are reasonably priced and ANSI sells them directly within the
  5099. USA.  There was a company I found once in Washington DC that sold ISO
  5100. at exhorbitantly high prices.  I was told that two major factors went into
  5101. this high price:  extremenly slick production of the documents themselves
  5102. and very expensive binders to hold them.  Further the company charged a
  5103. high markup.  Finally, documents were bundled in such a way that nothing
  5104. could be had for under $800 a few years ago.
  5105.  
  5106. Does anyone know a reasonable source for ISO documents without any slick
  5107. covers or excessive bundling or any form of profiteering?  (such practices
  5108. really should have no place in standardizing).
  5109.  
  5110. Many documents about TCP/IP networking are readily available online.  Are
  5111. there any ISO documents online?
  5112.  
  5113. > of ANSI X3.41 *is* the definition of how to transmit 8-bit codes over
  5114. > 7-bit lines, stipulating that SI should be sent to switch from the G0
  5115. > graphic set to the G1 graphic set, SO to switch back.  (Switching
  5116. > between C0 and C1, the two sets of controls, seems to be handled by
  5117. > escape sequences not SI/SO.)  Since A0 and FF are explicitly not part of
  5118. > the G1 set, ANSI X3.41 provides (sec. 9.3) that they should be
  5119. > represented, if they have to be, by a private escape sequence.
  5120.  
  5121. If the C0 and C1 sets were switched by SI and SO, that would make SI
  5122. present in C0 only, and SO present in C1 only, and the opposing codes
  5123. acting as no-op.  I guess it would have worked, but maybe someone
  5124. thought it wasteful to define 2 no-ops.
  5125.  
  5126. +-----------------------------------------------------------------------+
  5127. | Phil Howard, KA9WGN                   bitnet: <phil@uiucvmd.bitnet>   |
  5128. | Research Programmer                 internet: <phil@vmd.cso.uiuc.edu> |
  5129. | Computing Services Office            or unix: <phil@uxg.cso.uiuc.edu> |
  5130. | University of Illinois at U/C            mci: 10222-1-217-BIG-MAIN    |
  5131. | 1304 West Springfield Avenue            at&t: 10288-1-217-BIG-MAIN    |
  5132. | Urbana, IL  61801                     sprint: 10333-1-217-BIG-MAIN    |
  5133. | Phil's corollary: "If I was able to fix it, it must have been broke!" |
  5134. +-----------------------------------------------------------------------+
  5135. 20-May-88 10:23:53-EDT,9407;000000000015
  5136. Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
  5137. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 10:23:47-EDT
  5138. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 10:21:07 EDT
  5139. Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5140.  1007; Fri, 20 May 88 10:21:05 EDT
  5141. Received: by BLIULG11 (Mailer X1.25) id 1202; Fri, 20 May 88 16:15:41 +0200
  5142. Date:         Fri, 20 May 88 15:26:25 +0200
  5143. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  5144. Subject:      Extended ASCII with Kermit
  5145. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5146.  
  5147. Frank,
  5148.  
  5149. Here is a rewrite of the note I asked you to stop.
  5150. My main goal is to reach Kermit developers.
  5151. I leave it for you to judge if Info-Kermit is the right audience.
  5152. Are there other lists like IBM-KERMIT for each implementation?
  5153. If yes, that's of course the good place, but I'd like some
  5154. feedback despite the fact I can't subscribe to all of them.
  5155.  
  5156. I agree it's a big piece for Info-Kermit, and it could raise
  5157. a lot of discussion. But you will understand it's vital for many
  5158. people and it could add Kermit a big plus for them. In fact, some
  5159. are probably secretly half way for terminal mode with SI/SO and G sets.
  5160.  
  5161. I can shorten it to somewhat more than the conclusion for I-K if
  5162. you like.
  5163.  
  5164. Because of our special problems with and treat to the Mac, I am
  5165. sending this note to Matthias Aebi K116430 @ CZHRZU1A and
  5166. Paul Placeway PLACEWAY @ OHIO-STATE.ARPA. I hope these addresses are
  5167. still all-right.
  5168.  
  5169. Thanks in advance.
  5170.  
  5171. Andr).
  5172.  
  5173. ------------------------- For publication:
  5174. Dear Kermit developers,
  5175.  
  5176. Abstract.
  5177.  
  5178. In  the  course of implementing our own national  character  sets
  5179. with Kermit for terminal mode and file transfer, my understanding
  5180. of  the  problem evolved from confusion to (near) simplicity  and
  5181. from  national to international.  I think my findings will be  of
  5182. much interest to those having to deal with the  Spanish,  French,
  5183. German, Italian, well, the American continent, Western Europe and
  5184. many other languages.  That's,  for them,  really interconnecting
  5185. the majority of computers existing to-day.
  5186.  
  5187. On request,  I've tried to be as short as possible at the risk of
  5188. skimming  here and there.  I sure won't blame those getting bored
  5189. with  the subject.  They can skip to the conclusion and see  just
  5190. what  it  takes  in  Kermit  terms.   Conversely,   those  really
  5191. interested  will get more information from the standards and  the
  5192. ISO8859 list of BITNET's LISTSERV @ JHUVM and its archives.
  5193.  
  5194. Finally  I take the occasion to praise all those devoting much of
  5195. their time to straightening things that had run havoc. It's their
  5196. ideas I am conveying.  But I am sure glad to help. I just hope my
  5197. limited English will carry the message precisely.
  5198.  
  5199.  
  5200. Detail.
  5201.  
  5202. In   the   process of implementing extended  characters  transfer
  5203. between  micros  and  IBM mainframes,   I relied on the  extended
  5204. capabilities of Kermit 370 conversion (thanks John!). I  came  to
  5205. the conclusion that,   for the sole IBM PC,  I should set up to 9
  5206. different  tables in order to support 3 EBCDIC tables x 3 "ASCII"
  5207. tables.  For  the  Macintosh,  that's 3 more tables with the  IBM
  5208. host.  I was unable   to have Kermit do Mac to IBM PC conversion,
  5209. unless endeavouring translation on the PC, 3 more tables or so.
  5210.  
  5211. I  hacked  some  limited national characters  support  for  IBMPC
  5212. terminal mode through the 7171,  but our Mac users were left with
  5213. a dumb nice keyboard and a deaf screen.
  5214.  
  5215.  
  5216. Kermit implements two main files transfer modes.
  5217.  
  5218. Binary mode defines how to transport a continuous string of bytes
  5219. containing   values  only  required  to  be  meaningful  to   the
  5220. originating and receiving final systems.  No matter how stored on
  5221. an  intermediate one,  it should forward or return the same  byte
  5222. string  on the communication line.  The  point here is that  each
  5223. node operation is clearly defined, making it the best method when
  5224. appropriate.
  5225.  
  5226. Text  mode,  in  contrast,  defines how  to  transport  *records*
  5227. containing codes for "readable" characters intended to be  usable
  5228. -- and  stored as such -- on any system.  The protocol rules  how
  5229. to,  on  the  line,  stream the records in a  system  independent
  5230. manner. Again, every node should forward the data unaltered, that
  5231. is equivalent communication line encoding.
  5232.  
  5233. The  Kermit  protocol  wisely  says that the  ANSI  X3.4  (ASCII)
  5234. standard is to be used to represent these characters.  It is  the
  5235. code used on most computers and those (IBM,  Commodore) not using
  5236. it have to deal with their own problem of code conversion.
  5237.  
  5238. Most  modern computers now implement an 8-bit extended  character
  5239. set in order to support,  to various extents, languages requiring
  5240. characters  not found in ANSI X3.4 (I intentionally disregard the
  5241. obsolete  7-bit remapping methods).  Almost each does it its  own
  5242. way however,  because there was no standard at the time they were
  5243. devised (IBM even has multiple ones within a single system).
  5244.  
  5245. Clearly,  translation  must occur somewhere to transmit  extended
  5246. text  usefully  between  them.  If it is done say  by  running  a
  5247. program in the receiving system,  one must know and use the right
  5248. table  according to the sender.  The mere at least 7 codes that I
  5249. have  to deal with make for 5040 tables in theory.  In  practice,
  5250. what  was  a crystal clear matter as long as only X3.4  was  used
  5251. becomes  a  real puzzle with extended codes.  As  the  number  of
  5252. tables grows, so does the problem factorially.
  5253.  
  5254. To  a lesser extent,  the same problem holds for  terminal  mode.
  5255. It  occurs  only when a computer supports remote  terminals,  but
  5256. we must fiddle with a 7-bit data path,  an issue solved per se by
  5257. the Kermit protocol in the first case.
  5258.  
  5259. It  is  evident that the problem lies in each  machine's  dealing
  5260. with the others' own business,  and that the solution is to  have
  5261. them  talk a common code on the line,  as it is now with X3.4 and
  5262. for those not using it. Imposing them to use that code internally
  5263. is impractical,  although recommendable.  But having each convert
  5264. the  data  to/from  that common  code  before/after  transmission
  5265. reduces the above example to a mere 6 tables pairs.
  5266.  
  5267. What is striking is the technical simplicity of translating every
  5268. character  data  byte  that flows on a communication  line  to  a
  5269. common code everyone agrees about.  What is sorry is that we have
  5270. to. What is moot is what common code should be used on the line.
  5271.  
  5272. It  is my strong feeling that Kermit itself translating  national
  5273. codes to make up for the lack of its host system using a standard
  5274. will be *extremely* useful for people having to use these  codes.
  5275. This feature must be optional, because incompatible with previous
  5276. use.  It would be a shame to have two Kermit implementations  for
  5277. the  same  system corrupt data because one uses this feature  and
  5278. the other lacks it.
  5279.  
  5280. The  cause  of the problem,  a missing standard,  does no  longer
  5281. exist.  ISO 8859/1 = ANSI X3.134.2 = ECMA 94 has been defined and
  5282. gathers  every  possible  character extension for Latin  group  1
  5283. users,  by far the largest,  plus other common symbols satisfying
  5284. many computer brands. It looks like a very well thought out thing
  5285. and  several  leading manufacturers have adopted it,  or  a  pre-
  5286. release  because they couldn't wait,  or modified their  previous
  5287. codes to conform to ISO (have exactly the same graphics,  but use
  5288. other codes points,  in line with this proposition).  That's IBM,
  5289. DEC,  Microsoft and Lotus for what I gathered.  It looks like the
  5290. future many, international and US, are working for.
  5291.  
  5292. The  on-the-way-ISO8859/x  users  should not  be  left  out.  The
  5293. problem  is parallel,  but their codes will be untranslatable  to
  5294. ours.  They  might be expected to start with pure ISO right  off.
  5295. Until the 16 bits (some say 32) codes sets will be  devised,  but
  5296. that's our children's Kermit probably.
  5297.  
  5298.  
  5299. Conclusion.
  5300.  
  5301. In  summary,  a Kermit implementation would be much enhanced  for
  5302. many people if simply:
  5303.  
  5304. - it  was  optionally  translating bytes during  text  mode  file
  5305. transfer (at the file I/O or equivalent level). Nothing elaborate
  5306. is  required  to  start this.  Just a pair  of  null  translation
  5307. tables, easily found and patched, and a couple of code lines will
  5308. cover both the "translation" and "optional" topics.
  5309.  
  5310. - it  was  doing  the same at the communication  line  I/O  level
  5311. during  terminal  mode  and,  when using 7-bits wide  data  path,
  5312. implementing the ISO 2022 SO/SI feature to use the upper half  of
  5313. the  set  (shift  out) and revert to the lower  one  (shift  in).
  5314. Several already do.
  5315.  
  5316.  
  5317. That's all. But a welcome leap further would be to:
  5318.  
  5319. - if  a particular system does not conform to ISO (like the  Mac,
  5320. misses  some of its graphics or uses others),  define a best  fit
  5321. one  to  one correspondence between its character set(s) and  ISO
  5322. (there  should  be total agreement as to which,  up to  with  the
  5323. manufacturer). It must involve the 256 codes in a revertible way.
  5324.  
  5325. - have   systems  supporting  terminals  do  it  in   ISO   mode,
  5326. preferrably on an 8-bit wide line.
  5327.  
  5328. - have these features bundled in options.
  5329.  
  5330.  
  5331. Thanks for your patience in reading.
  5332.  
  5333. Andr). Oops, not yet. Andre'.
  5334. 20-May-88 17:09:24-EDT,2113;000000000001
  5335. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5336. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 17:09:19-EDT
  5337. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 17:06:41 EDT
  5338. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5339.  1739; Fri, 20 May 88 17:06:39 EDT
  5340. Received: by BITNIC (Mailer X1.25) id 1594; Fri, 20 May 88 17:06:58 EDT
  5341. Date:         Fri, 20 May 88 13:55:00 CDT
  5342. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5343. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5344. From:         Rick Troth <TROTH%TAMCBA.BITNET@CUVMA.COLUMBIA.EDU>
  5345. Subject:      Re: iso2022
  5346. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5347. In-Reply-To:  Your message of Fri 20 May 88 11:57:31 EDT
  5348.  
  5349. Ed, et al -
  5350.  
  5351.                 I do not have access to a VT300 series terminal,
  5352. but on the VT200 series boxes:
  5353.  
  5354.         1) 00-1F are the usual ASCII control codes
  5355.         2) 20-7E are the usual ASCII graphics
  5356.         3) 80-9F are new control codes, including CSI
  5357.         4) A0-FE are new graphics, defaulting to DEC Supplemental
  5358.                 (looks pretty much like A0-FE in ISO 8859/1)
  5359.                 if you are in "Multi-National" mode.
  5360.  
  5361.                 On a 7-bit wire:
  5362.  
  5363.         3) 80-9F are represeted by ESC followed by one of 40-5F
  5364.         4) A0-FE are displayed by  SO, string of 20-7E, SI
  5365.                 (thus APL support on 7171 can be fudged into ISO8859 support)
  5366.                 (Phil - SO/SI does not affect controls)
  5367.  
  5368.  
  5369.                 Examples:
  5370.  
  5371.         3) The familiar (to VT100 users) cursor placement operation
  5372.            ESC  row ; col H   (7-bit)   is equivalent to
  5373.             CSI  row ; col H   (8-bit)
  5374.                 (that's "escape open-bracket ... ")
  5375.  
  5376.         4) The cent sign can be displayed by
  5377.             A2 (hex, 8-bit)   or with G1 as DEC Supplemental
  5378.             SO 22 (hex) SI   (7-bit)
  5379.  
  5380.                                                         - Rick
  5381. 20-May-88 22:41:04-EDT,1374;000000000001
  5382. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5383. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 20 May 88 22:41:01-EDT
  5384. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 20 May 88 22:38:17 EDT
  5385. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5386.  1935; Fri, 20 May 88 22:38:15 EDT
  5387. Received: by BITNIC (Mailer X1.25) id 4267; Fri, 20 May 88 22:39:42 EDT
  5388. Date:         Fri, 20 May 88 20:05:20 EST
  5389. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5390. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5391. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  5392. Subject:      Re: Obtaining ANSI and ISO Standards
  5393. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5394. In-Reply-To:  Message of Fri, 20 May 88 15:35:30 EDT from <HART@APLVM>
  5395.  
  5396. Just so people have a feeling for what "reasonable" means in terms of
  5397. ISO standard prices, here is a list of standards I picked up last
  5398. December (at ANSI):
  5399.  
  5400. standard      price    # pages
  5401. ----------    -----    -------
  5402. ISO 8859-1     $22         7
  5403. ISO 8859-2     $20         6
  5404. ISO 6937-1     $27        12
  5405. ISO 6937-2     $50        37
  5406.  
  5407. In short, plan on spending about 4X more than you would for a comparable
  5408. ANSI standard.
  5409. 24-May-88 07:45:14-EDT,3619;000000000001
  5410. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5411. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 24 May 88 07:45:08-EDT
  5412. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 24 May 88 07:42:43 EDT
  5413. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5414.  4184; Tue, 24 May 88 07:42:41 EDT
  5415. Received: by BITNIC (Mailer X1.25) id 1096; Tue, 24 May 88 07:43:26 EDT
  5416. Date:         Tue, 24 May 88 12:52:00 MET
  5417. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5418. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5419. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  5420. Subject:      Reply to 7171 change
  5421. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5422.  
  5423. Dear list subscribers
  5424. So, Mr. Sperberg MacQueen wants to be cursed. My connections with
  5425. hellish powers are not all that, but I'll try.
  5426.  
  5427. I am certainly one in the "community" who does not agree, but I can
  5428. respect Mr. SMQ's experiments, not, however, a proposal that only solves
  5429. US problems.
  5430.  
  5431. First, what is EBCDIC? If we take the yellow card (GX20-1850), we see
  5432. two columns, one "standard", one for the T-11 and TN chains. Also, there
  5433. are the GT10 type tables for the IBM 3800 printers, and the national
  5434. variants (see 3270 manuals). The differences affect only a restricted
  5435. number of graphics.
  5436.  
  5437.  ID    NAME                  US   TN Intern GT10 CP500
  5438. SM06 left  square bracket    --   AD   4A   AD   BA
  5439. SM08 right square bracket    --   BD   5A   BD   BB
  5440. SM11 left  curly  bracket    C0   8B   C0   C0   C0
  5441. SM14 right curly  bracket    D0   8D   D0   D0   D0
  5442. SC04 cent sign               4A   4A   --   4A   4A
  5443. SP02 exclamation mark        5A   5A   4F   5A   5A
  5444. SM13 vertical line           4F   4F   --   4F   4F
  5445. SM65 broken vertical line    6A   --   6A   6A   6A
  5446. SM07 reverse solidus (slash) E0   --   E0   E0   E0
  5447. SD19 tilde                   A1   --   A1   A1   A1
  5448. SD13 grave accent            79   --   79   79   79
  5449.  
  5450. This is valid except for national variants at some of the 14 codes:
  5451. 4A 5A 6A 79 5B 7B 7C 5F A1 C0 D0 E0 4F 7F ;
  5452. following US are:
  5453. Canadian Bilingual, English (UK), Hebrew, Japanese, Portuguese, Spanish;
  5454. following International are:
  5455. German, Belgian, Brazilian, Canadian French, Danish/Norwegian, Finnish/
  5456. Swedish, French, Italian, Swiss.
  5457. The best test case is 4F:
  5458. US/CP037: exclamation mark
  5459. Int/CP500: vertical line
  5460.  
  5461. As for the extensions, CP037 and CP500 seem to be identical. The NOT
  5462. sign is a separate problem to be discussed later on.
  5463.  
  5464. Second, what is ISO8859? Be warned, you do not solve anything if you
  5465. include ISO8859-1 only in the discussion, (a note: it used to be
  5466. ISO8859/1, but ISO changed very recently their rules for designating the
  5467. Parts of a Standard, now it is ISO8859-1). There will be very soon a new
  5468. set, called internally ISO-XYZ, being the harmonization of ISO6937 and
  5469. 8859.  SC2 will meet the week of 17 Oct. 1988 in London. Prepare your
  5470. campaign, start to lobby now!
  5471.  
  5472. But all this leaves the central question unanswered. Shall the code page
  5473. be adapted to the translate table or the reverse? Mr. SMQ has shown that
  5474. the translate table of the 7171 can be changed. Is that all?
  5475.  
  5476. It is time to discuss the merits of the code pages. I'll keep my own
  5477. opinion until my next contribution.
  5478.  
  5479. Yours faithfully, Johan van Wingen
  5480.  
  5481.  
  5482.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  5483.      Mail to                                :
  5484.  P. O. Box 486,  2300AL Leiden, Netherlands :
  5485.  
  5486. 25-May-88 06:24:14-EDT,1288;000000000001
  5487. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5488. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 06:24:09-EDT
  5489. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 06:21:58 EDT
  5490. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5491.  6244; Wed, 25 May 88 06:21:56 EDT
  5492. Received: by BITNIC (Mailer X1.25) id 0291; Wed, 25 May 88 06:22:52 EDT
  5493. Date:         Wed, 25 May 88 02:28:00 CDT
  5494. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5495. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5496. From:         Richard <TILLEY%UOFMCC.BITNET@CUVMA.COLUMBIA.EDU>
  5497. Subject:      Re:Reply to 7171 change
  5498. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5499.  
  5500. Johan van Wingen <MOSGLA@HLERUL2> says:
  5501. >you do not solve anything if you include ISO8859-1 only in the discussion,
  5502.  
  5503. I agree. The high order half if ISO8859-1 is little use to anyone.
  5504. Far better to use Adobe's "Standard Encoding" or even
  5505. Xerox's "Character Set 0" as a basis for an 8 bit ASCII.
  5506. Both of these codes store accents as seperate characters instead of
  5507. trying to store all possible combinations of accents and characters.
  5508.  
  5509. 25-May-88 09:35:49-EDT,1560;000000000001
  5510. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5511. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 09:35:47-EDT
  5512. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 09:33:38 EDT
  5513. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5514.  6396; Wed, 25 May 88 09:33:35 EDT
  5515. Received: by BITNIC (Mailer X1.25) id 2455; Wed, 25 May 88 09:34:05 EDT
  5516. Date:         Wed, 25 May 88 08:56:48 EDT
  5517. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5518. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5519. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  5520. Subject:      Usefulness of ISO 8859-1
  5521. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5522.  
  5523. In contrast to flying accent options,
  5524. the ISO 8859-1 character set and code is very useful.  It contains the
  5525. necessary characters for over 40 countries.  Compare that to ISO 646
  5526. and the National variations (one per language).  ISO 8859-1 also has the
  5527. extra characters needed to make the US 94 character EBCDIC and US ASCII X3.4
  5528. character sets match.  ISO 8859-1 was developed because the computer
  5529. manufacturers required a one-character per code point.
  5530.  
  5531. However, when a printer implements the ISO 8859-1 code, nothing says that
  5532. internally the printer could not use flying accents to form the characters.
  5533. However, they need to be careful about the "i" character with accents like
  5534. the umlaut.
  5535.  
  5536. Ed Hart
  5537. 25-May-88 09:36:58-EDT,2978;000000000001
  5538. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5539. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 09:36:54-EDT
  5540. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 09:34:48 EDT
  5541. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5542.  6400; Wed, 25 May 88 09:34:47 EDT
  5543. Received: by BITNIC (Mailer X1.25) id 2506; Wed, 25 May 88 09:35:17 EDT
  5544. Date:         Wed, 25 May 88 08:53:02 EST
  5545. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5546. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5547. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  5548. Subject:      RE:       Re:Reply to 7171 change
  5549. X-To:         ASCII/EBCDIC character set related issues
  5550.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  5551. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5552.  
  5553. Now, come on.  "Of little use to anyone" is clearly at least a bit of an
  5554. exaggeration.  And the store-the-character, store-the-position,
  5555. store-the-accent strategy ignores two important problems:
  5556.   - For many purposes, these characters-with-extra-marks are CHARACTERS,
  5557. not simply "some other character with an accent".
  5558.   - The programming language implications of trying to cope with
  5559. characters and accents stored separately are pretty unpleasant.  I'm not
  5560. asserting that they cannot be made to work, but people keep assuming
  5561. that
  5562.   * length(string) == number of characters in it
  5563.   * if length(string1) = length(string2), then they contain the same
  5564. number of characters *and* occupy the same amount of storage (i.e., that
  5565. either string1 or string2 can be copied into the storage occupied by the
  5566. other).
  5567.   * that there is such a thing as character-width, and that characters
  5568. can be extracted from strings and stored into a character-width object.
  5569.   * that a comparison for identity between character1 and character2
  5570. will be true iff they are the same character (and not that one of them
  5571. is followed by an accent that changes its meaning).    And
  5572.   * things can be sorted into collating order using simplistic
  5573. bit-compare algorithms.
  5574.    I stipulate that some of those principles overlap, and that a smaller
  5575. number of rules is possible.  I also stipulate that one can design
  5576. runtime to eliminate or hide all of the problems (given careful runtime
  5577. and user programming), but suggest that such runtime would get little
  5578. assistance from current hardware and, consequently, would tend to
  5579. deliver unacceptable performance.
  5580.    character-overstrike_indicator-accent approaches are fine for page
  5581. definition languages (I note that your two examples were both of that
  5582. class), and are OK for a data communications stream that will be
  5583. printed (or displayed), but not further processed, but really fairly
  5584. poor for either information interchange or processing and text
  5585. manipulation.
  5586.    John Klensin, MIT
  5587.  
  5588. 25-May-88 10:17:04-EDT,1907;000000000001
  5589. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5590. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 10:17:02-EDT
  5591. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 10:14:55 EDT
  5592. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5593.  6458; Wed, 25 May 88 10:14:53 EDT
  5594. Received: by BITNIC (Mailer X1.25) id 3323; Wed, 25 May 88 10:10:41 EDT
  5595. Date:         Wed, 25 May 88 14:58:00 MET
  5596. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5597. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5598. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  5599. Subject:      7171 and Mr.Troth
  5600. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5601.  
  5602. Dear list subscribers
  5603.  
  5604. I have been inspecting Mr. Troth's tables. The first one (Raw EBCDIC)
  5605. appears to have arrived quite correctly. If you turn HEX ON (under PDF)
  5606. you see that all 256 codes are there. I tried it on a 3278, a 3192-G,
  5607. a VT100 (by class=C71, that is by the 7171) and on a PC by KERMIT, also
  5608. by C71, and there is no difference. Only if you look at the actual
  5609. characters on the screen you see other representations.
  5610. This implies that 8-bit codes are being transferred by BITNET correctly.
  5611. Only as soon as you start interpreting those codes no longer as EBCDIC
  5612. problems arise. But that is a matter of local changes to character
  5613. interpretations of codes. If you turn on APL at your terminal, you get
  5614. other things to see. Why not invent an ISO8859-1 button?
  5615. This done, I do not understand what the fuss with the 7171 is about.
  5616. Who is fooling whom?
  5617. Yours faithfully, Johan van Wingen
  5618.  
  5619.  
  5620.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  5621.      Mail to                                :
  5622.  P. O. Box 486,  2300AL Leiden, Netherlands :
  5623.  
  5624. 25-May-88 15:53:48-EDT,2527;000000000001
  5625. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5626. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 15:53:43-EDT
  5627. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 15:53:33 EDT
  5628. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5629.  7079; Wed, 25 May 88 15:53:25 EDT
  5630. Received: by BITNIC (Mailer X1.25) id 1608; Wed, 25 May 88 15:54:04 EDT
  5631. Date:         Wed, 25 May 88 11:46:00 CDT
  5632. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5633. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5634. From:         Rick Troth <TROTH%TAMCBA.BITNET@CUVMA.COLUMBIA.EDU>
  5635. Subject:      Re: Usefulness of ISO 8859-1
  5636. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5637. In-Reply-To:  Your message of Wed 25 May 88 08:56:48 EDT
  5638.  
  5639.         oAmen to that,  Ed!   (Spanish syntax)
  5640.  
  5641.         The one-to-one ASCII to EBCDIC table(s) is *the strength* of the
  5642. ISO8859-1 set.  As I indicated in a recent long posting,  we suffer from
  5643. the confusion of three different EBCDIC's here at A&M.  The problem is
  5644. most clearly illustrated in the display of square brackets.
  5645.  
  5646.         Suppose some random user sits down at some random terminal.
  5647. He logs in and reads his Inter-Net mail with embedded brackets.
  5648. Whether he sees brackets or "something else" depends on what terminal
  5649. he is using and what code points the brackets were translated to by
  5650. whatever gateway passed the mail to BITNET.
  5651.  
  5652.          Y     display as left and right brackets on a 3192
  5653.         & a     display as left and right brackets on a 3180
  5654.         [ ]     display as left and right brackets on a 7171
  5655.  
  5656.         It so happens that the character set in the 3192 displays ALL
  5657. of the characters in the ISO8859-1 set.  The 3180 DOES NOT.  The 7171
  5658. DOES NOT.  If you map 7-bit ASCII to some of EBCDIC, then you may be
  5659. able to put up with this.  But ASCII machines are starting to use all
  5660. all eight bits.  Furthermore connectivity is the word of the day.
  5661.  
  5662.         Personally,  I would hope that ISO8859-2 can be mapped to
  5663. the coresponding national EBCDIC,  and likewise for ISO8859-3, etc.
  5664. I did not get the impression that Michael S-McQ nor anyone else on
  5665. this list wants to "leave Europe out in the cold".  But let's take one
  5666. step at a time,  please.  How does "raw EBCDIC" display on your tube?
  5667.  
  5668.                                                                  - Rick
  5669. 25-May-88 12:08:08-EDT,2494;000000000001
  5670. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5671. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 12:08:03-EDT
  5672. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 12:02:00 EDT
  5673. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5674.  6766; Wed, 25 May 88 12:01:58 EDT
  5675. Received: by BITNIC (Mailer X1.25) id 5126; Wed, 25 May 88 12:00:08 EDT
  5676. Date:         Wed, 25 May 88 10:06:12 CDT
  5677. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5678. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5679. From:         Phil Howard KA9WGN <PHIL%UIUCVMD.BITNET@CUVMA.COLUMBIA.EDU>
  5680. Subject:      Re: Usefulness of ISO 8859-1
  5681. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5682. In-Reply-To:  Your message of Wed, 25 May 88 08:56:48 EDT
  5683.  
  5684. > However, when a printer implements the ISO 8859-1 code, nothing says that
  5685. > internally the printer could not use flying accents to form the characters.
  5686. > However, they need to be careful about the "i" character with accents like
  5687. > the umlaut.
  5688.  
  5689. Does this mean that "flying accents" are only formed by overstriking?
  5690.  
  5691. Does a backspace control character separate the base character from its
  5692. accent mark?
  5693.  
  5694. (((  I would think this not necessary when designing a new code with   )))
  5695. (((  the sophistication of today's computers.  The accent code could   )))
  5696. (((  be made to preceed the base character, and the accent code would  )))
  5697. (((  imply a modification to the next coming base character.           )))
  5698.  
  5699. > character sets match.  ISO 8859-1 was developed because the computer
  5700. > manufacturers required a one-character per code point.
  5701.  
  5702. Not knowing the actual codes ISO puts out, it is hard to make specific comments
  5703. since they may be really part of a different code.  I once looked at a number
  5704. of ways to do this myself.  I looked at many languages and collected a list of
  5705. different accents.  Then, by combining them with the Roman alphabet, I came up
  5706. with over 3000 possibilities.  Double that again for Cyrillic.  And that is
  5707. just most of Europe.  Still, the number of actually used accented letters in
  5708. the various languages would put a stress on codifying them all in just 256
  5709. possible codes.
  5710.  
  5711. Just how many different languages are being codified here?  Does anyone have
  5712. a list of them?  Are these standards going to lock out certain languages?
  5713. 25-May-88 12:36:07-EDT,4047;000000000001
  5714. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5715. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 25 May 88 12:36:04-EDT
  5716. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 25 May 88 12:25:10 EDT
  5717. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5718.  6800; Wed, 25 May 88 12:25:08 EDT
  5719. Received: by BITNIC (Mailer X1.25) id 5801; Wed, 25 May 88 12:18:58 EDT
  5720. Date:         Wed, 25 May 88 10:18:42 CDT
  5721. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5722. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5723. From:         Phil Howard KA9WGN <PHIL%UIUCVMD.BITNET@CUVMA.COLUMBIA.EDU>
  5724. Subject:      RE:       Re:Reply to 7171 change
  5725. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5726. In-Reply-To:  Your message of Wed, 25 May 88 08:53:02 EST
  5727.  
  5728. >   - For many purposes, these characters-with-extra-marks are CHARACTERS,
  5729. > not simply "some other character with an accent".
  5730. >   - The programming language implications of trying to cope with
  5731. > characters and accents stored separately are pretty unpleasant.  I'm not
  5732. > asserting that they cannot be made to work, but people keep assuming
  5733. > that
  5734. >   * length(string) == number of characters in it
  5735. >   * if length(string1) = length(string2), then they contain the same
  5736. > number of characters *and* occupy the same amount of storage (i.e., that
  5737. > either string1 or string2 can be copied into the storage occupied by the
  5738. > other).
  5739. >   * that there is such a thing as character-width, and that characters
  5740. > can be extracted from strings and stored into a character-width object.
  5741. >   * that a comparison for identity between character1 and character2
  5742. > will be true iff they are the same character (and not that one of them
  5743. > is followed by an accent that changes its meaning).    And
  5744. >   * things can be sorted into collating order using simplistic
  5745. > bit-compare algorithms.
  5746.  
  5747. Is it absolutely necessary that the representation of character codes
  5748. INTERNAL to a machine, and EXTERNALLY (inter-machine communication) be
  5749. identical?   Clearly if not, a processing logic must be applied as a
  5750. gateway in and out of a machine to transpose the code sets.  This overhead
  5751. is typical, however, given that many communications protocols even now
  5752. include various forms of Huffman or Lempel-Ziv compression protocols.
  5753. So, overhead is a weak argument.
  5754.  
  5755. The last "I" in ASCII means "Interchange".  Does the implications also
  5756. apply in practice for ISO codes?
  5757.  
  5758. >    I stipulate that some of those principles overlap, and that a smaller
  5759. > number of rules is possible.  I also stipulate that one can design
  5760. > runtime to eliminate or hide all of the problems (given careful runtime
  5761. > and user programming), but suggest that such runtime would get little
  5762. > assistance from current hardware and, consequently, would tend to
  5763. > deliver unacceptable performance.
  5764.  
  5765. How about a wider character code for INTERNAL machine processing where the
  5766. convenience of fixed interval addressing is very important, and a RELATED
  5767. EXTERNAL code for "Interchanging" these codes knowing that typical uses
  5768. will involve small subsets of the overall code, making it possible to
  5769. apply an "obvious" compression of selecting code subsets.  Some data
  5770. compression techniques can actually do this for you and make a 16-bit
  5771. code set where less than 256 codes are typically used transmit just about
  5772. as efficiently as if the codes had been defined in an 8-bit set.
  5773.  
  5774. >    character-overstrike_indicator-accent approaches are fine for page
  5775.  
  5776. What's wrong with (accent_implying_zero_forward_space)-(character) coding?
  5777.  
  5778. > definition languages (I note that your two examples were both of that
  5779. > class), and are OK for a data communications stream that will be
  5780. > printed (or displayed), but not further processed, but really fairly
  5781. > poor for either information interchange or processing and text
  5782. > manipulation.
  5783. >    John Klensin, MIT
  5784. 27-May-88 20:42:03-EDT,1210;000000000001
  5785. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5786. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 27 May 88 20:41:59-EDT
  5787. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 27 May 88 20:42:32 EDT
  5788. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5789.  0543; Fri, 27 May 88 20:42:31 EDT
  5790. Received: by BITNIC (Mailer X1.25) id 0892; Fri, 27 May 88 20:42:29 EDT
  5791. Date:         Fri, 27 May 88 20:22:49 EST
  5792. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5793. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5794. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  5795. Subject:      ECMA registered codes via DRCS?
  5796. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5797.  
  5798. ISO2022 defines Dynamically Redefinable Character Sets (DRCS) - which
  5799. essentially allows a user to define and load their own character set.
  5800.  
  5801. VT200's and emulators (which means most terminals of recent vintage)
  5802. support DRCS.
  5803.  
  5804. Are there any DRCS's available for ECMA codes?
  5805.  
  5806. If not, does anyone know of any software tools for creating DRCS's?
  5807. 27-May-88 20:22:15-EDT,2696;000000000001
  5808. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5809. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Fri 27 May 88 20:22:09-EDT
  5810. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Fri, 27 May 88 20:22:44 EDT
  5811. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5812.  0539; Fri, 27 May 88 20:22:43 EDT
  5813. Received: by BITNIC (Mailer X1.25) id 0808; Fri, 27 May 88 20:22:29 EDT
  5814. Date:         Fri, 27 May 88 18:35:47 EST
  5815. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5816. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5817. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  5818. Subject:      Re: Extended ASCII with Kermit
  5819. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5820. In-Reply-To:  Message of Fri, 27 May 88 14:44:05 +0200 from <A-PIRARD@BLIULG11>
  5821.  
  5822. From my reading of ISO's 646, 2022, 4873, 8859-1 & 8859-2 I have come
  5823. to the conclusion that there is a fairly widespread misunderstanding of
  5824. ISO8859.  If I'm the one who has misunderstood I hope someone will take
  5825. the trouble to correct me.
  5826. People seem to think that you pick one of the ISO8859-x sets and then
  5827. those 256 characters are the only ones used.  However, ISO's 2022 & 4873
  5828. define a number of escape sequences for switching among different
  5829. versions (as they term character sets which conform to the standards).
  5830. What this means is that simple translation table mappings are not enough
  5831. to translate ISO to other code sets, one must also change translation
  5832. tables 'on the fly' as the escape sequences are encountered.  A somewhat
  5833. simplified example may help to illustrate the problem:
  5834.  
  5835. data stream
  5836. (ISO notation)   hex       comments
  5837. --------------   ---       --------
  5838. ESC 02/00 04/12  1B 20 4C  select level 1 of ISO4873
  5839. ESC 02/13 04/01  1B 2D 41  designate (and invoke) ISO8859-1's G1 set
  5840. 12/00            C0        1st 'real' character - capital A, grave accent
  5841. ESC 02/13 04/02  1B 2D 42  designate (and invoke) ISO8859-2's G1 set
  5842. 12/00            C0        2nd 'real' character - capital R, grave accent
  5843.  
  5844. Does an implementation which uses a single set of ISO8859-x characters
  5845. conform to the standard?
  5846. Even if it does, would it make any sense to standardize on a particular
  5847. ISO8859-x to the exclusion of others?
  5848. Finally, if one were to do so, how would the 2 character text in my
  5849. example be transmitted?
  5850.  
  5851. Any implementation which doesn't include the ISO escape sequences will
  5852. eventually have to incorporate some such mechanism.  I think the ISO
  5853. escape sequences should be a part of any standard which is adopted.
  5854. 28-May-88 06:13:40-EDT,1772;000000000001
  5855. Return-Path: <@CUVMA.COLUMBIA.EDU:A-PIRARD@BLIULG11.BITNET>
  5856. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Sat 28 May 88 06:13:30-EDT
  5857. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Sat, 28 May 88 06:13:55 EDT
  5858. Received: from VM1.ULG.AC.BE by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5859.  0716; Sat, 28 May 88 06:13:53 EDT
  5860. Received: by BLIULG11 (Mailer X1.25) id 1548; Sat, 28 May 88 12:12:35 +0200
  5861. Date:         Sat, 28 May 88 12:11:26 +0200
  5862. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  5863. Subject:      Precision to my ISO8859/1 document
  5864. To:           ISO8859@JHUVM,
  5865.               Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>,
  5866.               IBM-KERMIT@CU20B.COLUMBIA.EDU,
  5867.               Paul Placeway <PAUL@TUT.CIS.OHIO-STATE.EDU>,
  5868.               Matthias Aebi <K116430@CZHRZU1A>
  5869.  
  5870.  
  5871. In  the  document describing the ISO8859/1 and related  character
  5872. sets,  I  forgot to make the following remark to be added to  the
  5873. file. Sorry.
  5874.  
  5875. Andre'.
  5876.  
  5877. - The  character  range 80-9F is undefined in the  description of
  5878. ISO885/1 I have.  I don't know its real status,  but this feature
  5879. is welcome for two reasons.
  5880.      First, it avoids control characters during transmission on a
  5881. 7-bit  line (ISO2022:  an SO code shifts to the upper half of the
  5882. set,  an  SI code reverts to the lower one).  As an added  bonus,
  5883. this keeps Kermit overhead (8-th bit quoting) to a minimum.
  5884.      Second, it allows rearranging a previous 8-bit code set that
  5885. used this range for national characters.  These are moved to  the
  5886. ISO  positions and the expelled non-ISO characters can  be  moved
  5887. to the 80-9F range.
  5888.      What appears in my listing is the assignment made by IBM for
  5889. its graphic characters mainly.
  5890. 30-May-88 14:19:26-EDT,2798;000000000001
  5891. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5892. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Mon 30 May 88 14:19:21-EDT
  5893. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Mon, 30 May 88 05:53:51 EDT
  5894. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5895.  1929; Mon, 30 May 88 05:53:50 EDT
  5896. Received: by BITNIC (Mailer X1.25) id 0253; Mon, 30 May 88 05:53:10 EDT
  5897. Date:         Mon, 30 May 88 11:06:44 +0200
  5898. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5899. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5900. From:         Andre PIRARD <A-PIRARD%BLIULG11.BITNET@CUVMA.COLUMBIA.EDU>
  5901. Subject:      Re: Extended ASCII with Kermit
  5902. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5903. In-Reply-To:  Message of Fri, 27 May 88 18:35:47 EST from <KESICH@NYUCIMSA>
  5904.  
  5905. >People seem to think that you pick one of the ISO8859-x sets and then
  5906. >those 256 characters are the only ones used.  However, ISO's 2022 & 4873
  5907. >define a number of escape sequences for switching among different
  5908. >versions (as they term character sets which conform to the standards).
  5909. >What this means is that simple translation table mappings are not enough
  5910. >to translate ISO to other code sets, one must also change translation
  5911. >tables 'on the fly' as the escape sequences are encountered.  A somewhat
  5912. >simplified example may help to illustrate the problem:
  5913. >
  5914. >data stream
  5915. >(ISO notation)   hex       comments
  5916. >--------------   ---       --------
  5917. >ESC 02/00 04/12  1B 20 4C  select level 1 of ISO4873
  5918. >ESC 02/13 04/01  1B 2D 41  designate (and invoke) ISO8859-1's G1 set
  5919. >12/00            C0        1st 'real' character - capital A, grave accent
  5920. >ESC 02/13 04/02  1B 2D 42  designate (and invoke) ISO8859-2's G1 set
  5921. >12/00            C0        2nd 'real' character - capital R, grave accent
  5922.  
  5923. That's the way to build a super terminal to display data from a super
  5924. text processor that can manage all languages simultaneously.
  5925. But how will this processor store its text? Not in a plain 8-bit text
  5926. file obviously.
  5927. And that's what's I was talking of: transferring to-day's 8-bit files
  5928. that store one version of ISO8859 and terminal support for that
  5929. one version of code. Let's first agree on how to do that.
  5930. File transfer of more elaborate data will have to encode the data for
  5931. integrity anyway. So, the ISO scheme can apply only to terminal mode.
  5932.  
  5933. But thanks for the information John.
  5934. By the way, could you describe in a couple of lines how ISO defines
  5935. switching between the two halves of a single 8-bit set with SI/SO
  5936. for a 7-bit line? The mechanism looks fairly obvious, but I would hate
  5937. missing some subtle feature.
  5938.  
  5939. Andr).
  5940. 31-May-88 08:33:12-EDT,1095;000000000001
  5941. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5942. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 May 88 08:33:10-EDT
  5943. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 31 May 88 08:33:58 EDT
  5944. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5945.  2888; Tue, 31 May 88 08:33:56 EDT
  5946. Received: by BITNIC (Mailer X1.25) id 0442; Tue, 31 May 88 08:33:32 EDT
  5947. Date:         Tue, 31 May 88 08:24:11 EDT
  5948. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5949. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5950. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.COLUMBIA.EDU>
  5951. Subject:      Re: Precision to my ISO8859/1 document
  5952. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5953. In-Reply-To:  Your message of Sat, 28 May 88 12:11:26 +0200
  5954.  
  5955. ISO 8859-1 columns 8 and 9 (X'80' to X'9F') are reserved for the C1 control
  5956. character set.  They may not be used for (printable) characters, only for
  5957. control characters.
  5958. 31-May-88 09:15:25-EDT,3911;000000000001
  5959. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  5960. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 May 88 09:15:17-EDT
  5961. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 31 May 88 09:16:08 EDT
  5962. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  5963.  2930; Tue, 31 May 88 09:16:07 EDT
  5964. Received: by BITNIC (Mailer X1.25) id 2115; Tue, 31 May 88 09:14:59 EDT
  5965. Date:         Tue, 31 May 88 15:00:00 MET
  5966. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5967. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  5968. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.COLUMBIA.EDU>
  5969. Subject:      What is EBCDIC?
  5970. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  5971.  
  5972. Dear list subscribers
  5973. It is very difficult indeed to be clear and precise. Thus I have to
  5974. present a corrected version of the EBCDIC part of my "Reply to 7171
  5975. change". As CP037 and CP500 are not available here, please send me
  5976. any correction to these tables, in order that we know what we are
  5977. speaking about when we are discussing variants of EBCDIC.
  5978. Yours faithfully, Johan van Wingen
  5979.  
  5980. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  5981. First, what is EBCDIC? We consider for this moment the basic set with
  5982. 94 characters only.
  5983.  
  5984. If we take the yellow card (GX20-1850), we see two columns, one
  5985. "standard", one for the T-11 and TN chains.
  5986. Also, there are the GT10 type tables for the IBM 3800 printers.
  5987. Further, there are national variants, based on "US" and "International",
  5988. (see IBM3270 Information Display System, Character Set Reference,
  5989. GA27-2837-9, Figure 10-43).
  5990. Finally, there are CP037 and CP500, containing extensions.
  5991. (The 4250 code pages, which are still more different, are left out.)
  5992.  
  5993. The differences affect only a restricted number of graphics.
  5994. (the CP037 and CP500 are only a guess, please send corrections)
  5995.  
  5996.                                  Interna                         ISO
  5997.  ID    NAME                  US  tional  TN   GT10  CP037 CP500 8859-1
  5998.  
  5999. SM06 left  square bracket    --    4A    AD    AD    BA    4A    5B
  6000. SM08 right square bracket    --    5A    BD    BD    BB    5A    5D
  6001. SM11 left  curly  bracket    C0    C0    8B    8B    C0    C0    7B
  6002. SM14 right curly  bracket    D0    D0    9B    9B    D0    D0    7D
  6003. SC04 cent sign               4A    --    4A    4A    4A    4A    A2
  6004. SP02 exclamation mark        5A    4F    5A    5A    5A    4F    21
  6005. SM13 vertical line           4F    --    4F    4F    4F    5A    7C
  6006. SM65 broken vertical line    6A    6A    --    --    6A    6A    A6
  6007. SM07 reverse solidus (slash) E0    E0    --    E0    E0    E0    5C
  6008. SD19 tilde                   A1    A1    --    --    A1    A1    7E
  6009. SD13 grave accent            79    79    --    --    79    79    60
  6010. SM66 not sign                5F    5F    5F    5F    5F    5F    AC
  6011. SD15 circumflex accent       --    --    --    --    B0    B0    5E
  6012.  
  6013. This is valid except for national variants at some of the 14 codes:
  6014. 4A 5A 6A 79 5B 7B 7C 5F A1 C0 D0 E0 4F 7F ;
  6015. following US are:
  6016. Canadian Bilingual, English (UK), Hebrew, Japanese, Portuguese, Spanish;
  6017. following International are:
  6018. German, Belgian, Brazilian, Canadian French, Danish/Norwegian, Finnish/
  6019. Swedish, French, Italian, Swiss.
  6020.  
  6021. The best test case for determining your set is 4F:
  6022. US/CP037: exclamation mark
  6023. International/CP500: vertical line
  6024.  
  6025. As for the extensions, CP037 and CP500 seem to be identical, (TN and
  6026. GT10 have different extensions).
  6027.  
  6028. The NOT sign is a separate problem to be discussed later on.
  6029. """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
  6030.  
  6031.  
  6032.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6033.      Mail to                                :
  6034.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6035.  
  6036. 31-May-88 21:48:06-EDT,4711;000000000001
  6037. Return-Path: <@CUVMA.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6038. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Tue 31 May 88 21:48:00-EDT
  6039. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Tue, 31 May 88 21:48:36 EDT
  6040. Received: from BITNIC.BITNET by CUVMA.COLUMBIA.EDU (Mailer X1.25) with BSMTP id
  6041.  4073; Tue, 31 May 88 21:48:35 EDT
  6042. Received: by BITNIC (Mailer X1.25) id 2182; Tue, 31 May 88 21:43:33 EDT
  6043. Date:         Tue, 31 May 88 18:36:21 EST
  6044. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  6045. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.COLUMBIA.EDU>
  6046. From:         John Kesich <KESICH%NYUCIMSA.BITNET@CUVMA.COLUMBIA.EDU>
  6047. Subject:      Re: Extended ASCII with Kermit
  6048. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6049. In-Reply-To:  Message of Mon, 30 May 88 11:06:44 +0200 from <A-PIRARD@BLIULG11>
  6050.  
  6051. > That's the way to build a super terminal to display data from a super
  6052. > text processor that can manage all languages simultaneously.
  6053. > But how will this processor store its text? Not in a plain 8-bit text
  6054. > file obviously.
  6055. > And that's what's I was talking of: transferring to-day's 8-bit files
  6056. > that store one version of ISO8859 and terminal support for that
  6057. > one version of code. Let's first agree on how to do that.
  6058. > File transfer of more elaborate data will have to encode the data for
  6059. > integrity anyway. So, the ISO scheme can apply only to terminal mode.
  6060.  
  6061. By today's 8-bit codes I can only assume that you are refering to ECMA
  6062. registered codes (such as the ISO8859 character sets).  Each of these
  6063. codes has 2 registered designation sequences (G0 and G1 character sets
  6064. are designated seperately).  What I described in my previous note was not
  6065. a proposed ISO standard but something that has been around since 1973.
  6066. The only new element in the picture is ISO8859.  As I understand it,
  6067. ISO8859 represents the first set of internationally agreed upon VERSIONS
  6068. of ISO character sets.   ** perhaps someone could post a list of the other
  6069. ECMA registered character sets **
  6070. There is currently limited hardware support for these escape sequences, I
  6071. can only guess that they are more heavily used in Europe than in America.
  6072. However, even here the DRCS escape sequence defined in ISO2022 is widely
  6073. supported (as I mentioned in a previous note).  There is at least one word
  6074. processing package that I know of which makes use of it to provide alternate
  6075. characters (WordMARC which provides Greek characters and math symbols).
  6076. However, such programs as Tex, Troff, Script, MacWrite, etc should be able
  6077. to do the same.  (I can't guess at how much effort would be required,
  6078. but reinventing the ISO escape sequences - and I am sure they would be
  6079. reinvented - can't be easier.)
  6080.  
  6081. As far as I am concerned it makes no sense to adopt ISO8859 without the
  6082. related escape sequences.
  6083.  
  6084. > By the way, could you describe in a couple of lines how ISO defines
  6085. > switching between the two halves of a single 8-bit set with SI/SO
  6086. > for a 7-bit line? The mechanism looks fairly obvious, but I would hate
  6087. > missing some subtle feature.
  6088. I don't claim to be an expert, and I hope others will correct any mistakes,
  6089. but here is my understanding of how it works:
  6090. There are 3 sets of escape sequences:
  6091.  
  6092.              designator
  6093.         94 char     96 char       invoker    single-character-invoker
  6094.  
  6095. G0      ESC 2/8 f                 SI
  6096. G1      ESC 2/9 f   ESC 2/13 f    SO
  6097. G2      ESC 2/10 f  ESC 2/14 f    LS2        SS2
  6098. G3      ESC 2/11 f  ESC 2/15 f    LS3        SS3
  6099.  
  6100. where 'f' is the code assigned by ECMA in accordance with ISO2375.
  6101. and the shift sequences are defined as follows:
  6102.  
  6103. SO   0/14  (called LS1 in 8-bit environments - I don't know the difference)
  6104. SI   0/15  (called LS0 in 8-bit environments - I don't know the difference)
  6105. LS2  ESC 6/14
  6106. LS3  ESC 6/15
  6107. SS2  ESC 4/14  (8/14 in 8-bit environments)
  6108. SS3  ESC 4/15  (8/15 in 8-bit environments)
  6109.  
  6110. So you designate your 4 graphic character sets and then use the various
  6111. shift (invoker) sequences as needed.
  6112.  
  6113. For example:
  6114. ESC 2/8 4/2               designate ISO8859-1 G0 as your G0
  6115. ESC 2/13 4/1              designate ISO8859-1 G1 as your G1
  6116. ESC 2/14 4/2              designate ISO8859-2 G1 as your G2
  6117. SO 4/0                    'load' G1 (ISO8859-1 G1)
  6118. 4/0 6/0                   'print' A-grave a-grave
  6119. SS2 4/0                   'load' position 4/0 from G2 (ISO8859-2 G1)
  6120. 4/0 6/0                   'print' R-acute a-grave
  6121. SI                        'load' G0 (ISO8859-1 G0)
  6122. 4/0 6/0                   'print' @ `  (commercial at, grave accent)
  6123.  
  6124. I hope this will be helpful.
  6125.  6-Jun-88 10:20:23-EDT,3898;000000000001
  6126. Return-Path: <@CUVMA.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6127. Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Mon 6 Jun 88 10:20:19-EDT
  6128. Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Mon, 06 Jun 88 10:21:15 EDT
  6129. Received: from BITNIC.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6130.  id 0666; Mon, 06 Jun 88 10:21:08 EDT
  6131. Received: by BITNIC (Mailer X1.25) id 3087; Mon, 06 Jun 88 09:37:30 EDT
  6132. Date:         Mon, 6 Jun 88 15:19:00 MET
  6133. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6134. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6135. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6136. Subject:      What is EBCDIC? (2nd correction)
  6137. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6138.  
  6139. Dear list subscribers
  6140. With the help of Mr. Pirard's table I could correct the CP500 column.
  6141. Here is the second corrected version.
  6142. Yours faithfully, Johan van Wingen
  6143.  
  6144. ########################################################################
  6145.          What is EBCDIC? (2nd Correction)
  6146. ########################################################################
  6147. First, what is EBCDIC? We consider for this moment the basic set with
  6148. 94 characters only.
  6149.  
  6150. If we take the yellow card (GX20-1850), we see two columns, one
  6151. "standard", one for the T-11 and TN chains.
  6152. Also, there are the GT10 type tables for the IBM 3800 printers.
  6153. Further, there are national variants, based on "US" and "International",
  6154. (see IBM3270 Information Display System, Character Set Reference,
  6155. GA27-2837-9, Figure 10-43).
  6156. Finally, there are CP037 and CP500, containing extensions.
  6157. (The 4250 code pages, which are still more different, are left out.)
  6158.  
  6159. The differences affect only a restricted number of graphics.
  6160. A compromise between CP037 and CP500 should be possible.
  6161.  
  6162.                              ISO       Interna My
  6163.  ID    NAME                 8859-1 US  tional  TN   GT10  CP037 CP500 prop.
  6164.  
  6165. SM06 left  square bracket    5B    --    4A    AD    AD    BA    4A    4A
  6166. SM08 right square bracket    5D    --    5A    BD    BD    BB    5A    5A
  6167. SM11 left  curly  bracket    7B    C0    C0    8B    8B    C0    C0    C0
  6168. SM14 right curly  bracket    7D    D0    D0    9B    9B    D0    D0    D0
  6169. SC04 cent sign               A2    4A    --    4A    4A    4A    B0    BA
  6170. SP02 exclamation mark        21    5A    4F    5A    5A    5A    4F    6A
  6171. SM13 vertical line           7C    4F    --    4F    4F    4F    BB    4F
  6172. SM65 broken vertical line    A6    6A    6A    --    --    6A    6A    BB
  6173. SM07 reverse solidus (slash) 5C    E0    E0    --    E0    E0    E0    E0
  6174. SD19 tilde                   7E    A1    A1    --    --    A1    A1    A1
  6175. SD13 grave accent            60    79    79    --    --    79    79    79
  6176. SM66 not sign                AC    5F    5F    5F    5F    5F    BA    5F
  6177. SD15 circumflex accent       5E    --    --    --    --    B0    5F    B0
  6178.  
  6179. This is valid except for national variants at some of the 14 codes:
  6180. 4A 5A 6A 79 5B 7B 7C 5F A1 C0 D0 E0 4F 7F ;
  6181. following US are:
  6182. Canadian Bilingual, English (UK), Hebrew, Japanese, Portuguese, Spanish;
  6183. following International are:
  6184. German, Belgian, Brazilian, Canadian French, Danish/Norwegian, Finnish/
  6185. Swedish, French, Italian, Swiss.
  6186.  
  6187. The best test case for determining your set is 4F:
  6188. US/CP037: exclamation mark
  6189. International/CP500: vertical line
  6190.  
  6191. As for the extensions, CP037 and CP500 are identical, (TN and GT10 have
  6192. different extensions).
  6193.  
  6194. The NOT sign is a separate problem to be discussed later on.
  6195. ########################################################################
  6196.  
  6197.  
  6198.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6199.      Mail to                                :
  6200.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6201.  
  6202.  8-Jun-88 06:35:48-EDT,2223;000000000001
  6203. Return-Path: <@CUVMA.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6204. Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Wed 8 Jun 88 06:35:46-EDT
  6205. Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Wed, 08 Jun 88 06:36:44 EDT
  6206. Received: from BITNIC.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6207.  id 3019; Wed, 08 Jun 88 06:36:43 EDT
  6208. Received: by BITNIC (Mailer X1.25) id 4920; Wed, 08 Jun 88 06:36:38 EDT
  6209. Date:         Wed, 8 Jun 88 12:24:00 MET
  6210. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6211. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6212. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6213. Subject:      EBCDIC on screen
  6214. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6215.  
  6216. Dear list subscribers
  6217. What shows up on your screen when looking at all 256 bytes ("raw
  6218. EBCDIC") may depend on several things.
  6219. 1.  the hardware of your terminal
  6220. 2.  how the control unit (3174, 3274) has been customized
  6221. 3.  the presence of PS ("programmable storage")
  6222. 4.  the operating system (OS/MVS/TSO or VM/CMS)
  6223. 5.  the option chosen under your editor
  6224.     (with TSO/ISPF/PDF you may use PDF 0.1 setting one of 3278, 3278A,
  6225.     3278T, 3278CN, 3278KN, each giving a different screen content)
  6226. It would be helpful to know how some effects on several terminal types
  6227. may be achieved. I have no idea how to show CP037 on a 3192G. Here it is
  6228. a MVS-only site. It seems that most of the contributions came from
  6229. VM/CMS sites, producing very little that I could use directly. With all
  6230. editing done under ISPF/PDF, it would the best solution to have the GDDM
  6231. symbol sets for CP037 and CP500 (due to Mr. J. Wilhelm) accessible to
  6232. ISPF. As these can be easily supplemented by other sets, all code page
  6233. problems can be solved. As for printers either IEBIMAGE or APA software
  6234. can realize everything desirable. Can anyone report having experience in
  6235. doing this?
  6236. Yours faithfully, Johan van Wingen
  6237.  
  6238.  
  6239.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6240.      Mail to                                :
  6241.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6242.  
  6243.  8-Jun-88 09:38:53-EDT,11965;000000000001
  6244. Return-Path: <@CUVMA.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6245. Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Wed 8 Jun 88 09:38:42-EDT
  6246. Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Wed, 08 Jun 88 09:39:38 EDT
  6247. Received: from BITNIC.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6248.  id 3223; Wed, 08 Jun 88 09:39:35 EDT
  6249. Received: by BITNIC (Mailer X1.25) id 7377; Wed, 08 Jun 88 09:37:12 EDT
  6250. Date:         Wed, 8 Jun 88 15:23:00 MET
  6251. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6252. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6253. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6254. Subject:      Notation
  6255. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6256.  
  6257. Dear list subscribers
  6258. It seems convenient to have a compact representation of the character
  6259. content of tables under discussion, enabling an immediate view on their
  6260. differences. Thus I extended a notation system, such as previously
  6261. sent, for all characters in ISO8859-1, -2 and -9, (the last one includes
  6262. Turkish, and is still to be approved).
  6263. The code used for vertical line is 4F, that for exclamation sign 5A.
  6264. Yours faithfully, Johan van Wingen
  6265.  
  6266.  
  6267.  
  6268.  
  6269.   A NOTATION SYSTEM FOR LETTERS NOT IN ASCII OR 94-EBCDIC
  6270.  
  6271.   The notation consists of two characters, the first being one of
  6272.   a restricted set of special characters, the second being one out of
  6273.   the common subset of ASCII and 94-EBCDIC. Thus it is suitable for
  6274.   processing by a program to a single byte code.
  6275.   Reference is made to the character identifications (ID) found in
  6276.   ISO6937, (these consist of two letters and two digits).
  6277.  
  6278.   First characters:
  6279.   (descriptions taken from ISO 6937-2, additions between parentheses,
  6280.    numbering system for identification taken from ISO6937-1, p. 7)
  6281.  
  6282.   /  acute accent                           11,12
  6283.   \  grave accent                           13,14
  6284.   ^  circumflex accent                      15,17
  6285.   %  diaeresis (umlaut, trema)              17,18
  6286.   ~  tilde                                  19,20
  6287.   *  caron (hachek)                         21,22
  6288.   #  breve (Rumanian a)                     23,24
  6289.   #  double acute accent (Hungarian o,u)    25,26
  6290.   @  ring (above: a,u)                      27,28
  6291.   @  dot (above: z)                         29,30
  6292.   =  macron (upper line)                    31,32
  6293.   $  cedilla (c,s,t)                        41,42
  6294.   $  ogonek (Polish a,e)                    43,44
  6295.   $  (barred: o, eth, thorn)                61....
  6296.   _  (underline, fraction)
  6297.   &  (ligature: ae,oe,sz)                   51,52
  6298.   ?  (dot below)
  6299.  
  6300.    REGULAR LETTERS AND DECIMAL DIGITS
  6301.  
  6302.  not.   ID       Name or description
  6303.  
  6304.      a LA01   small a
  6305.      A LA02   capital A
  6306.      :  :      :
  6307.      z LZ01   small z
  6308.      Z LZ02   capital z
  6309.      1 ND01   digit one
  6310.      :  :      :
  6311.      9 ND09   digit nine
  6312.      0 ND10   digit zero
  6313.  
  6314.    VOWELS
  6315.  
  6316.  not.   ID       Name or description
  6317.  
  6318.   /a   LA11   small a with acute accent
  6319.   \a   LA13   small a with grave accent
  6320.   ^a   LA15   small a with circumflex accent
  6321.   %a   LA17   small a with diaeresis or umlaut mark
  6322.   ~a   LA19   small a with tilde
  6323.   #a   LA23   small a with breve
  6324.   @a   LA27   small a with ring
  6325.   =a   LA31   small a with macron
  6326.   $a   LA43   small a with ogonek
  6327.   &a   LA51   small ae diphtong
  6328.   /e   LE11   small e with acute accent
  6329.   \e   LE13   small e with grave accent
  6330.   ^e   LE15   small e with circumflex accent
  6331.   %e   LE17   small e with diaeresis or umlaut mark
  6332.   *e   LE21   small e with caron
  6333.   @e   LE29   small e with dot above
  6334.   =e   LE31   small e with macron
  6335.   $e   LE43   small e with ogonek
  6336.   /i   LI11   small i with acute accent
  6337.   \i   LI13   small i with grave accent
  6338.   ^i   LI15   small i with circumflex accent
  6339.   %i   LI17   small i with diaeresis
  6340.   ~i   LI19   small i with tilde
  6341.   =i   LI31   small i with macron
  6342.   $i   LI43   small i with ogonek
  6343.   &i   LI51   small ij ligature
  6344.   @i   LI61   small i without dot
  6345.   /o   LO11   small o with acute accent
  6346.   \o   LO13   small o with grave accent
  6347.   ^o   LO15   small o with circumflex accent
  6348.   %o   LO17   small o with diaeresis or umlaut mark
  6349.   ~o   LO19   small o with tilde
  6350.   #o   LO25   small o with double acute accent
  6351.   =o   LO31   small o with macron
  6352.   &o   LO51   small oe ligature
  6353.   $o   LO51   small o with slash
  6354.   /u   LU11   small u with acute accent
  6355.   \u   LU13   small u with grave accent
  6356.   ^u   LU15   small u with circumflex accent
  6357.   %u   LU17   small u with diaeresis or umlaut mark
  6358.   ~u   LU19   small u with tilde
  6359.   #u   LU25   small u with double acute accent
  6360.   @u   LU27   small u with ring
  6361.   =u   LU31   small u with macron
  6362.   $u   LU43   small u with ogonek
  6363.   /y   LY11   small y with acute accent
  6364.   \y   LY13   small y with grave accent
  6365.   ^y   LY15   small y with circumflex accent
  6366.   %y   LY17   small y with diaeresis or umlaut mark
  6367.  
  6368.    CONSONANTS (ISO8859-1, -2 and -9 only)
  6369.  
  6370.  not.   ID       Name or description
  6371.  
  6372.   /c   LC11   small c with acute accent
  6373.   *c   LC21   small c with caron
  6374.   $c   LC41   small c with cedilla
  6375.   *d   LD21   small d with caron
  6376.   =d   LD61   small d with stroke
  6377.   $d   LD63   small eth, Icelandic
  6378.   #g   LG23   small g with breve
  6379.   /l   LL11   small l with acute accent
  6380.   *l   LL21   small n with caron
  6381.   $l   LL61   small l with stroke
  6382.   /n   LN11   small n with acute accent
  6383.   ~n   LN19   small n with tilde
  6384.   *n   LN21   small l with caron
  6385.   /r   LR11   small r with acute accent
  6386.   *r   LR21   small r with caron
  6387.   /s   LS11   small s with acute accent
  6388.   *s   LS21   small s with caron
  6389.   $s   LS41   small s with cedilla
  6390.   &s   LS61   small sharp s, German
  6391.   $p   LT17   small thorn, Icelandic
  6392.   *t   LT21   small t with caron
  6393.   $t   LT41   small t with cedilla
  6394.   /z   LZ11   small z with acute accent
  6395.   *z   LZ21   small z with caron
  6396.   @z   LZ29   small z with dot above
  6397.  
  6398.   Capital letters have even numbers, odd + 1.
  6399.   But notice the following:
  6400.  
  6401.      i LI01   small i
  6402.   @i   LI61   small i without dot
  6403.      I LI02   capital I (without dot)
  6404.   @I   LI30   capital I with dot above
  6405.   $D   LD62   capital D with stroke, Icelandic eth
  6406.  
  6407.    DIGITS AND NUMBERS
  6408.  
  6409.  not.   ID       Name or description
  6410.  
  6411.   @1   NS01   superscript one
  6412.   @2   NS02   superscript two
  6413.   @3   NS03   superscript three
  6414.   _2   NF01   fraction one-half
  6415.   _3   NF04   fraction one-quarter
  6416.   _4   NF05   fraction three-quarters
  6417.  
  6418.    SPECIAL CHARACTERS
  6419.  
  6420.  not.   ID       Name or description
  6421.  
  6422.   =f   SC01   general currency sign
  6423.   =L   SC02   pound sign
  6424.      $ SC03   dollar sign
  6425.   =c   SC04   cent sign
  6426.   =Y   SC05   yen
  6427.  
  6428.      ! SP02   exclamation mark
  6429.   *!   SP03   inverted exclamation mark
  6430.      " SP04   quotation mark
  6431.      ' SP05   apostrophe
  6432.      ( SP06   left parenthesis
  6433.      ) SP07   right parenthesis
  6434.      , SP08   comma
  6435.      _ SP09   low line
  6436.      - SP10   hyphen or minus sign
  6437.      . SP11   full stop, period
  6438.      / SP12   solidus
  6439.      : SP13   colon
  6440.      ; SP14   semicolon
  6441.      ? SP15   question mark
  6442.   *?   SP16   inverted question mark
  6443.   *<   SP17   angle quotation mark left
  6444.   *>   SP18   angle quotation mark right
  6445.  
  6446.      + SA01   plus sign
  6447.   _+   SA02   plus or minus sign
  6448.      < SA03   less-than sign
  6449.      = SA04   equals sign
  6450.      > SA05   greater-than sign
  6451.   _:   SA06   divide sign
  6452.   _*   SA07   multiply sign
  6453.  
  6454.      # SM01   number sign
  6455.      % SM02   percent sign
  6456.      & SM03   ampersand
  6457.      * SM04   asterisk
  6458.      @ SM05   commercial at
  6459.   *(   SM06   left square bracket
  6460.      \ SM07   reverse solidus
  6461.   *)   SM08   right square bracket
  6462.      { SM11   left curly bracket
  6463.      | SM13   vertical line
  6464.      } SM14   right curly bracket
  6465.   #m   SM17   micro sign
  6466.   @0   SM19   degree sign
  6467.   _o   SM20   ordinal indicator masculine
  6468.   _a   SM21   ordinal indicator feminine
  6469.   #S   SM24   section sign
  6470.   #p   SM25   pilchrow
  6471.   #.   SM26   middle dot
  6472.   #c   SM52   copyright sign
  6473.   #r   SM53   registered sign
  6474.   *| : SM65   broken bar
  6475.      ^ SM66   not sign
  6476.  
  6477.   @/   SD11   acute accent
  6478.   @\ ` SD13   grave accent
  6479.   @^   SD15   circumflex accent
  6480.   @%   SD17   diaeresis or umlaut mark
  6481.   @$ ~ SD19   tilde
  6482.   @*   SD21   caron
  6483.   @#   SD23   breve
  6484.   @"   SD25   double acute accent
  6485.   @0   SD27   ring
  6486.   @@   SD29   dot above
  6487.   @=   SD31   macron
  6488.   _)   SD41   cedilla
  6489.   _(   SD42   ogonek
  6490.  
  6491.   NOTE: If necessary, the following characters will denoted as:
  6492.   SP          space
  6493.   NB          no-break space
  6494.   SH          soft hyphen
  6495.  
  6496.  
  6497.  
  6498.     ISO8859-1                             ISO8859-2
  6499.  
  6500.                                         .
  6501.     2. 3. 4. 5. 6. 7. A. B. C. D. E. F. . 2. 3. 4. 5. 6. 7. A. B. C. D. E. F.
  6502.                                         .
  6503. .0      0  @  P  `  p NB @0 \A $D \a $d .     0  @  P  `  p NB @0 /R $D /r =d .
  6504. .1   !  1  A  Q  a  q *! _+ /A ~N /a ~n .  !  1  A  Q  a  q $A $a /A /N /a /n .
  6505. .2   "  2  B  R  b  r =c @2 ^A \O ^a \o .  "  2  B  R  b  r @# _( ^A *N ^a *n .
  6506. .3   #  3  C  S  c  s =L @3 ~A /O ~a /o .  #  3  C  S  c  s $L $l #A /O #a /o .
  6507. .4   $  4  D  T  d  t =f @/ %A ^O %a ^o .  $  4  D  T  d  t =f @/ %A ^O %a ^o .
  6508. .5   %  5  E  U  e  u =Y #m @A ~O @a ~o .  %  5  E  U  e  u *L *l /L #O /l #o .
  6509. .6   &  6  F  V  f  v *| #p &A %O &a %o .  &  6  F  V  f  v /S /s /C %O /c %o .
  6510. .7   '  7  G  W  g  w #S #. $C _* $c _: .  '  7  G  W  g  w #S @* $C _* $c _: .
  6511. .8   (  8  H  X  h  x @% _) \E $O \e $o .  (  8  H  X  h  x @% _) *C *R *c *r .
  6512. .9   )  9  I  Y  i  y #c @1 /E \U /e \u .  )  9  I  Y  i  y *S *s /E @U /e @u .
  6513. .A   *  :  J  Z  j  z _a _o ^E /U ^e /u .  *  :  J  Z  j  z $S $s $E /U $e /u .
  6514. .B   +  ;  K *(  k  { *< *> %E ^U %e ^u .  +  ;  K *(  k  { *T *t %E #U %e #u .
  6515. .C   ,  <  L  \  l  |  ^ _4 \I %U \i %u .  ,  <  L  \  l  | /Z /z *E %U *e %u .
  6516. .D   -  =  M *)  m  } SH _2 /I /Y /i /y .  -  =  M *)  m  } SH @" /I /Y /i /y .
  6517. .E   .  >  N @^  n  ~ #r _3 ^I $P ^i $p .  .  >  N @^  n  ~ *Z *z ^I $T ^i $t .
  6518. .F   /  ?  O  _  o  _ @= *? %I /s %i %y .  /  ?  O  _  o  _ @Z @z *D /s *d @@ .
  6519.  
  6520.  
  6521.                CP037                    .            CP500
  6522.                                         .
  6523.                                         .
  6524.     4. 5. 6. 7. 8. 9. A. B. C. D. E. F. . 4. 5. 6. 7. 8. 9. A. B. C. D. E. F.
  6525.                                         .
  6526. .0      &  - $o $O @0 #m  ^  {  }  \  0 .     &  - $o $O @0 #m =c  {  }  \  0
  6527. .1  NS /e  / /E  a  j  ~ =L  A  J _:  1 . NS /e  / /E  a  j  ~ =L  A  J _:  1
  6528. .2  ^a ^e ^A ^E  b  k  s =Y  B  K  S  2 . ^a ^e ^A ^E  b  k  s =Y  B  K  S  2
  6529. .3  %a %e %A %E  c  l  t #.  C  L  T  3 . %a %e %A %E  c  l  t #.  C  L  T  3
  6530. .4  \a \e \A \E  d  m  u #c  D  M  U  4 . \a \e \A \E  d  m  u #c  D  M  U  4
  6531. .5  /a /i /A /I  e  n  v #S  E  N  V  5 . /a /i /A /I  e  n  v #S  E  N  V  5
  6532. .6  ~a ^i ~A ^I  f  o  w #p  F  O  W  6 . ~a ^i ~A ^I  f  o  w #p  F  O  W  6
  6533. .7  @a %i @A %I  g  p  x _4  G  P  X  7 . @a %i @A %I  g  p  x _4  G  P  X  7
  6534. .8  $c \i $C \I  h  q  y _2  H  Q  Y  8 . $c \i $C \I  h  q  y _2  H  Q  Y  8
  6535. .9  ~n &s ~N  `  i  r  z _3  I  R  Z  9 . ~n &s ~N  `  i  r  z _3  I  R  Z  9
  6536. .A  =c  ! *|  : *< _a *! *( SH @1 @2 @3 . *( *) *|  : *< _a *!  ^ SH @1 @2 @3
  6537. .B   .  $  ,  # *> _o *? *) ^o ^u ^O ^U .  .  $  ,  # *> _o *?  | ^o ^u ^O ^U
  6538. .C   <  *  %  @ $d &a $D @= %o %u %O %U .  <  *  %  @ $d &a $D @= %o %u %O %U
  6539. .D   (  )  _  ' /y _) /Y @% \o \u \O \U .  (  )  _  ' /y _) /Y @% \o \u \O \U
  6540. .E   +  ;  >  = $p &A $P @/ /o /u /O /U .  +  ;  >  = $p &A $P @/ /o /u /O /U
  6541. .F   |  ^  ?  " _+ =f #r _* ~o %y ~O    .  ! @^  ?  " _+ =f #r _* ~o %y ~O
  6542.                                         .
  6543.                                         .
  6544.  
  6545.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6546.      Mail to                                :
  6547.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6548.  
  6549.  8-Jun-88 13:59:09-EDT,1972;000000000001
  6550. Return-Path: <@CUVMA.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6551. Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Wed 8 Jun 88 13:59:06-EDT
  6552. Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Wed, 08 Jun 88 14:00:03 EDT
  6553. Received: from BITNIC.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6554.  id 3836; Wed, 08 Jun 88 13:59:58 EDT
  6555. Received: by BITNIC (Mailer X1.25) id 8680; Wed, 08 Jun 88 13:59:49 EDT
  6556. Date:         Wed, 8 Jun 88 13:37:58 EDT
  6557. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6558. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6559. From:         Edwin Hart <HART%APLVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6560. Subject:      ISO 8859-1, -2, -3, . . . -9 Standards and High Level Languages
  6561. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6562.  
  6563. I am trying to understand two areas:
  6564.  
  6565. 1.  I have copies of ISO 8859-1, through -4.  What languages are covered by
  6566.     -5, through -9?
  6567.  
  6568. 2.  Did ISO put any restrictions on High Level (Programming) Languages with
  6569.     respect to the 8859 series of codes?  In particular I can think of two
  6570.     possibilities:
  6571.  
  6572.     a.  Only characters in common to all ISO 8859 codes are valid in
  6573.         high level languages for operators, etc.  From my look at 8859-1
  6574.         through -4, this means that code points X'20' through X'7F' and
  6575.         multiplication (small x) and division symbols.
  6576.  
  6577.     b.  Only characters in ISO 8859-1 are valid for high level languages.
  6578.         The IBM NOT symbol "^" (X'5F' for CP 37 and X'BA' for CP 500) is
  6579.         included in 8859-1 but not in -2, -3, -4.
  6580.  
  6581.     Using 2.b. implies that 8859-1 must be common to terminals in use in
  6582.     several countries where the primary code is -2 through -9.  Using 2.a.
  6583.     means that the NOT symbol will be unavailable for programming languages.
  6584.  
  6585. Thank you for your comments,
  6586. Ed Hart
  6587.  8-Jun-88 16:15:54-EDT,2586;000000000001
  6588. Return-Path: <@CUVMA.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6589. Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Wed 8 Jun 88 16:15:49-EDT
  6590. Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Wed, 08 Jun 88 16:16:41 EDT
  6591. Received: from BITNIC.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6592.  id 4203; Wed, 08 Jun 88 16:16:40 EDT
  6593. Received: by BITNIC (Mailer X1.25) id 2403; Wed, 08 Jun 88 16:15:44 EDT
  6594. Date:         Wed, 8 Jun 88 15:42:44 EST
  6595. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6596. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6597. From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  6598. Subject:      RE:       ISO 8859-1, -2, -3,
  6599.               . . . -9 Standards and High Level Languages
  6600. X-To:         ASCII/EBCDIC character set related issues
  6601.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  6602. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6603.  
  6604.   There has been some discussion about "requiring" the programming
  6605. languages to make a common statement about codes, but nothing definitive
  6606. has happened.  The strongest statements have been about support for
  6607. multi-octet character sets, which has nothing to do with ISO8859.
  6608.   There was a strong suggestion several years ago that the languages
  6609. avoid the use of any character not in the ISO646 Basic Table (i.e.,
  6610. seven-bit graphics with all national use positions excluded), but it
  6611. mostly resulted in a survey of deviants (almost everyone) and little
  6612. action.   The one noticable consequence of that effort may well be the
  6613. exclamation mark/vertical bar confusion about which character to use for
  6614. "or", and the similar tilde/diresis problem with "not".
  6615.   The different programming language standards differ in how they
  6616. approach character sets.  A few say what amounts to "you will use
  6617. ASCII".  At the other extreme, at least one says "use whatever external
  6618. form you like, as long as there is an abstraction that maps it into...".
  6619. Some of those approaches are more easily consistent with ISO8859
  6620. variations than others.  There has been, as far as I know, no serious
  6621. proposal for a common ISO8859 subset for programming languages.  The
  6622. common subset is an ISO646 subset.
  6623.   Finally, it is very difficult for the working groups in one
  6624. subcommittee (e.g., character sets and codes) to require the working
  6625. groups in another subcommittee (e.g., programming languages) to do (or
  6626. not do) anything.   That is just not how the process works.
  6627.  
  6628. 12-Jun-88 08:24:22-EDT,1957;000000000001
  6629. Return-Path: <@CUVMA.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6630. Received: from CUVMA.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Sun 12 Jun 88 08:24:20-EDT
  6631. Received: from CUVMA.CC.COLUMBIA.EDU(MAILER) by CUVMA.CC.COLUMBIA.EDU(SMTP) ; Sun, 12 Jun 88 08:23:36 EDT
  6632. Received: from BITNIC.BITNET by CUVMA.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6633.  id 6094; Fri, 10 Jun 88 12:58:25 EDT
  6634. Received: by BITNIC (Mailer X1.25) id 5835; Fri, 10 Jun 88 12:58:15 EDT
  6635. Date:         Fri, 10 Jun 88 16:50:00 MET
  6636. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6637. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6638. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMA.CC.COLUMBIA.EDU>
  6639. Subject:      a few notes
  6640. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6641.  
  6642. Dear list subscribers
  6643. A few little points this time.
  6644. 1.  People who cannot get CP037 and CP500 elsewhere may consult a new
  6645.     IBM publication (Jan. 1988) which just arrived here.
  6646.     It is SC33-0554-00 GDDM Type faces and Shading Patterns.
  6647. 2.  Please correct an error in the CP037 table recently mailed by me.
  6648.     At B0 "^" should be "@^".
  6649. 3.  Mr. Hart is quite right in concluding that the NOT sign only occurs
  6650.     in ISO8859-1. Apparently people in Poland or Hungary are not
  6651.     supposed by ISO/TC97/SC2 to use PL/I, which is not according to the
  6652.     facts.
  6653. 4.  As most programming language standards are much older than ISO8859
  6654.     (1987), it cannot be expected that these take it into account.
  6655.     There is much more to say about the relation, but that must come at
  6656.     a later moment.
  6657. 5.  A list of all the relevant standards was mailed 24 March, and is
  6658.     contained in LOG8803.
  6659. Yours faithfully, johan van Wingen
  6660.  
  6661.  
  6662.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6663.      Mail to                                :
  6664.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6665.  
  6666. 15-Jul-88 11:40:15-EDT,3236;000000000001
  6667. Return-Path: <@CUVMB.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6668. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Fri 15 Jul 88 11:40:12-EDT
  6669. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 15 Jul 88 11:36:26 EDT
  6670. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6671.  id 4961; Fri, 15 Jul 88 11:36:22 EDT
  6672. Received: by BITNIC (Mailer X1.25) id 7043; Fri, 15 Jul 88 11:36:33 EDT
  6673. Date:         Fri, 15 Jul 88 17:12:00 MET
  6674. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMB.CC.COLUMBIA.EDU>
  6675. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMB.CC.COLUMBIA.EDU>
  6676. From:         Johan van Wingen <MOSGLA%HLERUL2.BITNET@CUVMB.CC.COLUMBIA.EDU>
  6677. Subject:      Code switching
  6678. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6679.  
  6680. Dear list subscribers
  6681.  
  6682. My congratulations to Mr. Kesich for his excellent analysis. I sent
  6683. a copy of it and of Mr Hart's mailing to the SEAS Secretary
  6684. (DECK@RCSCK11). I hope both of you will not mind.
  6685. It is strange to see how IBM attitudes are with respect to ISO
  6686. standards, for one can find IBM people at all key positions in ISO
  6687. committees. Chairman of ISO/TC97, now ISO/IEC JTC1, is J. Rankine, from
  6688. IBM. Convener of SC2/WG2 (multibyte characters) is J. Andersen, IBM. In
  6689. SC2/WG3, (7-8 bit codes) you find Mr. W. F. Bohn, IBM. And this is a
  6690. far from complete list.
  6691.  
  6692. As for the problem of switching to another code page, I looked at CP870,
  6693. which should be the equivalent of ISO 8859-2 (Eastern Europe).
  6694. I was surprised that it is not identical with the code page
  6695. you get when you convert ISO 8859-2 with the same translate table as for
  6696. producing CP037 from ISO 8859-1. This has curious consequences.
  6697. Suppose you use ISO 2022 for table switching in a 8859 file.
  6698. Then if you have
  6699. <start with 8859-1> \a <shift to 8859-2> /r <end>
  6700. the codes for \a and /r are identical, but they produce a different
  6701. graphic as a result of the shift, ("a" with grave accent is denoted by
  6702. \a, and "r" with acute accent with /r). Now, if you translate this file
  6703. to EBCDIC with the customary translate table, all codes are converted
  6704. accordingly, equal codes remaining equal. But this does not produce a /r
  6705. any more, when the shift is translated to cause switching from CP037 to
  6706. CP870. This implies that an extra function is required at translating,
  6707. to switch also the translate table at finding a shift code. This puts an
  6708. additional burden to our poor hardware and software.
  6709.  
  6710. A note for people who complained that ISO does not keep to its own rules
  6711. when introducing 96-character sets. It appears that there is a Third
  6712. edition of ISO 2022 (1986-05-01) which differs from the Second
  6713. (1982-12-15) edition in this respect. I became aware of this only very
  6714. recently.
  6715.  
  6716. A few corrections should be made in the tables I sent. In that one
  6717. headed ISO8859-1 position 7F should be blank, and DF should contain &s,
  6718. not /s. The table for ISO8859-2 contains the same errors.
  6719.  
  6720. Yours faithfully, Johan van Wingen
  6721.  
  6722.  
  6723.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6724.      Mail to                                :
  6725.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6726.  
  6727. 15-Jul-88 13:37:31-EDT,3313;000000000001
  6728. Return-Path: <@CUVMB.CC.COLUMBIA.EDU:ISO8859@JHUVM.BITNET>
  6729. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Fri 15 Jul 88 13:37:29-EDT
  6730. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 15 Jul 88 13:33:45 EDT
  6731. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6732.  id 5256; Fri, 15 Jul 88 13:33:40 EDT
  6733. Received: by BITNIC (Mailer X1.25) id 8100; Fri, 15 Jul 88 13:33:23 EDT
  6734. Date:         Fri, 15 Jul 88 10:57:21 CDT
  6735. Reply-To:     ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMB.CC.COLUMBIA.EDU>
  6736. Sender:       ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@CUVMB.CC.COLUMBIA.EDU>
  6737. From:         Michael Sperberg-McQueen <U18189%UICVM.BITNET@CUVMB.CC.COLUMBIA.EDU>
  6738. Subject:      IBM and standards (PS/2 code page, ISO8859-2 translation)
  6739. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  6740.  
  6741. Footnote to John Kesich's remarks about IBM and standards:  it's not the
  6742. programs I care about (any program that hard codes non-standard
  6743. character set extensions is asking for everything it gets), but the
  6744. users' data.  You don't really think PC users should have to convert all
  6745. of their data with non-ASCII characters when they move from PCs to PSs,
  6746. do you?  You don't really think they would, even if they were supposed
  6747. to, do you?  I don't want the phone calls I would get if IBM had moved
  6748. the umlauts to their ISO 8859-1 positions.  And you don't either.
  6749.  
  6750. Yes, it would have been nice for the PC to have had a rational extension
  6751. of ASCII instead of the mess it actually has.  Yes, it would be nice if
  6752. the PS/2 could switch code pages in flight.  Yes, it would have been
  6753. nice for IBM to adhere fully to ISO 8859-1.  But given the original PC
  6754. character set, given the hardware the PS/2 actually has, and given IBM's
  6755. unwillingness to make users eat data conversion costs even for their own
  6756. good, the PS/2 code page does look (to me) like a step forward.  Let's
  6757. rejoice:  it's not often we see even small steps moving in the right
  6758. direction.
  6759.  
  6760. Footnote to J. W. van Wingen's remark about ISO 8859-2 translation:
  6761. doesn't IBM's decision to avoid data conversion problems by retaining
  6762. national versions of the extended EBCDIC code pages imply, already and
  6763. by itself, the impossibility of using the same translate table for the
  6764. various parts of ISO8859?  I agree it's a shame, it is a rather large
  6765. step in the wrong direction.  But is it a surprise?  At least part of
  6766. the mapping must be determined by the existing EBCDICs for Greece,
  6767. Israel, and so on.  What firm wants to impose immense data conversion
  6768. costs on whole countries of users, if they can avoid them by fouling
  6769. up the EBCDIC/ASCII translation problem a little bit more?  (I don't
  6770. mean just IBM -- I've seen ASCII machines screw up the translation too.)
  6771.  
  6772.  
  6773.  
  6774. It's depressing to think how long lists like this one are going to be
  6775. necessary.  Our poor hardware and software are going to continue to be
  6776. strained.  (By the way, thanks to JWvW for acknowledging that ISO 2022
  6777. had changed recently on the 94/96 character issue.  I thought I was
  6778. going crazy.)
  6779.  
  6780. All the above pessimism is my own and not the official policy of my
  6781. employer.
  6782.  
  6783. Michael Sperberg-McQueen, University of Illinois at Chicago
  6784. 31-Aug-88  2:52:45-GMT,3038;000000000001
  6785. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA02759; Tue, 30 Aug 88 22:52:39 EDT
  6786. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Tue 30 Aug 88 22:51:54-EDT
  6787. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 30 Aug 88 22:51:17 EDT
  6788. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6789.  id 7711; Tue, 30 Aug 88 22:51:16 EDT
  6790. Received: by BITNIC (Mailer X1.25) id 7025; Tue, 30 Aug 88 22:53:09 EDT
  6791. Date:         Tue, 30 Aug 88 19:49:00 CDT
  6792. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6793. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6794. From: Richard <TILLEY%UOFMCC.BITNET@cuvmb.cc.columbia.edu>
  6795. Subject:      Re: SHARE White Paper
  6796. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  6797.  
  6798. >>IBM was following an international standard to our benefit.
  6799. If this were true no mapping would be needed.
  6800. Do you receive money from these people?
  6801.  
  6802. >>If you do not like the character set, your complaint is with ISO--not IBM
  6803. ISO8859-1 fills the need for a multi-lingual Latin character
  6804. set very well. Many people at many installations including this one
  6805. will be happy with it.  Perhaps most people in some W. European
  6806. countries will be happy with it. I have no complaints with ISO.
  6807. However, I get the impression that some members of this list believe
  6808. this character set is suitable for *general* use in North America.
  6809. Have I misunderstood?
  6810.  
  6811. >>IBM finally gave us the potential to have a 1-to-1 mapping between
  6812. >>CECPs 37 and 500 and an 8-bit "ASCII" ...
  6813. It would be an excellent achievement if this effort produced an
  6814. 8 bit ASCII-to-EBCDIC conversion that gained as widespread use as
  6815. the most popular of the current 7 bit tables.
  6816. Code page 500 IS *NOT* just as much EBCDIC as code page 37 is,
  6817. because the former is inlikely to gain widespread use.
  6818. The latter has some chance although there will be a game of
  6819. musical brackets for the next decade. So whats a thousand wasted
  6820. man years?
  6821.  
  6822. >>Special characters, like the ones needed for publishing,
  6823. >>will require code page switching.
  6824. Agree. What I would like to minimize is the number of translate tables
  6825. tables visible to the user. Preferably just one for most users.
  6826.  
  6827. >>If you look at Code Page 500 and the "Standard" ASCII-to-EBCDIC conversions
  6828. >>you will discover that code page 500 maps very will into 7-bit ASCII.
  6829. Does your installation use "Standard" ASCII-to-EBCDIC conversions
  6830. to attach ASCII terminals to your EBCDIC mainframe?
  6831. I can think of 3 printable things to say about this table:
  6832.  - Some people use it.
  6833.  - Most people do not use it.
  6834.  - It has produced F.U.D.
  6835.  
  6836. Having 2 Code Pages for ISO8859-1 has produced F.U.D.
  6837. Moving Brackets from where IBM once recommended has produced F.U.D.
  6838. Moving Braces from where IBM once recommended has produced 15 years of F.U.D.
  6839. With no obvious explanation for these changes, one begins to
  6840.    suspect that their only purpose is the production of F.U.D.
  6841.  
  6842.  
  6843. 31-Aug-88  3:59:43-GMT,1785;000000000001
  6844. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA06584; Tue, 30 Aug 88 23:59:40 EDT
  6845. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Tue 30 Aug 88 23:58:56-EDT
  6846. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 30 Aug 88 23:58:20 EDT
  6847. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6848.  id 7745; Tue, 30 Aug 88 23:58:19 EDT
  6849. Received: by BITNIC (Mailer X1.25) id 7513; Wed, 31 Aug 88 00:00:15 EDT
  6850. Date:         Tue, 30 Aug 88 23:38:03 EST
  6851. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6852. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6853. From: John C Klensin <KLENSIN@infoods.mit.edu>
  6854. Subject:      RE:       Re: SHARE White Paper
  6855. X-To:         ASCII/EBCDIC character set related issues
  6856.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  6857. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  6858.  
  6859. For English and French-speaking North American purposes, since ISO8859-1
  6860. is a superset of ASCII (with all of the leading-zero-bit characters in
  6861. the same positions as the ASCII seven-bit characters), and contains, as
  6862. far as I know, an adequate set of non-ASCII characters (diacritical
  6863. markings, etc) to represent French, there appears to be no reason why it
  6864. should not be adopted for most general use when:
  6865.  - an eight bit set can be handled and processed   and
  6866.  - an ANSI/ISO character set is to be used, rather than, e.g., EBCDIC.
  6867. So, yes, it has been assumed that, in these contexts, 8859-1 is suitable
  6868. for general USA and Canadian use.  I lack the experience to know whether
  6869. it would be adequate/suitable for general Mexican use, so can't make a
  6870. general statement about North America.
  6871.  
  6872.  
  6873. 31-Aug-88 17:00:15-GMT,5256;000000000001
  6874. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA02848; Wed, 31 Aug 88 12:59:57 EDT
  6875. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Wed 31 Aug 88 12:59:11-EDT
  6876. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 31 Aug 88 12:58:34 EDT
  6877. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6878.  id 8301; Wed, 31 Aug 88 12:58:32 EDT
  6879. Received: by BITNIC (Mailer X1.25) id 4246; Wed, 31 Aug 88 12:59:51 EDT
  6880. Date:         Wed, 31 Aug 88 09:40:27 EDT
  6881. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6882. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6883. From: Edwin Hart <HART%APLVM.BITNET@cuvmb.cc.columbia.edu>
  6884. Subject:      Re: SHARE White Paper
  6885. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  6886. In-Reply-To:  Your message of Tue, 30 Aug 88 19:49:00 CDT
  6887.  
  6888. I am NOT getting paid by IBM to work in this area.  They could not affort it.
  6889. In fact, my manager and wife and children
  6890. have many ideas about how I could better use the time I am
  6891. spending on this effort.  90% of my week at SHARE was devoted to these
  6892. issues rather than attending other sessions which would have benefited my
  6893. installation more (in the short term).  I am working in this area because I too
  6894. am angry and frustrated.  We have tried to fix this problem for the last
  6895. 15 years and have been unsuccessful.
  6896.  
  6897. Do I like IBM's failure to make a decision on one EBCDIC for Latin Alphabet
  6898. Number 1?  NO!|  (If you are using CP 500 you would see "|!".)
  6899. In fact, IBM has taken an internal IBM argument and made it into
  6900. an international argument by encouraging code page 500 adoption in Belgium
  6901. and Switzerland.  My words for that are unprintable.  Such actions are
  6902. irresponsible and show no regard for customers.
  6903.  
  6904. Code page 500 is being widely used here and abroad--especially in Belgium and
  6905. Switzerland.  One of the members of the SHARE committee was using it
  6906. in the U.S. on 3274s just to avoid the ASCII-EBCDIC translate issues.  Messages
  6907. from Belgian installations on EARN have been coded in code page 500.
  6908. A recent message to me stated that code page 37 was not up for consideration
  6909. and that IBM documentation (and he quoted it) said to use code page 500 for
  6910. international operations.  I believe he was from Germany.  Just weeks ago,
  6911. I talked to an IBM contact in the Corporate standards area.  He said that IBM
  6912. as a Corporation (meaning all of the IBM development Divisions)
  6913. has NOT decided on one EBCDIC code page for ISO Latin Alphabet Number 1.
  6914.  
  6915. Concerning changing the code points for brackets from the TN/T11 print train,
  6916. if we have a requirement to move them back, we can certainly tell IBM that.
  6917. (We have, in fact, drafted such a requirement.)
  6918.  
  6919. Part of the problem is that IBM is too big and that too many people within
  6920. IBM have no idea of the problems.  The other part is that to correct the
  6921. problems requires changes to too many IBM products, and requires customers
  6922. to convert a lot of data and programs.  IBM understands big customers.  When US
  6923. multinational banks, insurance companies, manufacturers, oil companies start
  6924. telling IBM to fix the problems, IBM might put MORE resources into the effort
  6925. than they have now.  The intent of the SHARE paper is to have it approved as
  6926. a SHAREwide position paper.  In other words, to get approval from the 30 SHARE
  6927. managers who come from not only the Universities but also Commercial accounts.
  6928. As a part time effort, it will be 9 to 12 months before we can obtain SHAREwide
  6929. status.
  6930.  
  6931. If you want to contribute to the effort you are welcome.  But if you are angry,
  6932. take it out on IBM--not me.  I need some help with the discussions at the SHARE
  6933. meetings.  I need feedback on the content of the paper.  Is the paper clear?
  6934. Does it read smoothly?  Does it really describe all of the problems?  Where are
  6935. the mistakes in the paper?  Solutions to the problems are going to cost IBM
  6936. millions (billions?) of dollars, what business justification do we have to
  6937. convince IBM to spend that kind of money?  If you were faced with solving all
  6938. of the problems, it would be easier to stick your head in the sand that to try
  6939. to find a solution.  It will take an IBM Corporate commitment to solve the
  6940. problems.  One IBM Division cannot do it alone.  Right now, the IBM Corporation
  6941. has a tremondous dollar commitment to Systems Applications Architecture.  SAA
  6942. is the right target for this effort.  We have a window of opportunity.  If the
  6943. paper could have been handed over to IBM as a SHAREwide position paper in
  6944. August, we could have had an earlier and harder impact.
  6945.  
  6946. We have IBM people who work with the Committee.  They are commited to working
  6947. for solutions.  Material from SHARE European Association (SEAS) and the
  6948. SHARE white paper effort have already been used to influence IBM decision
  6949. makers to commit resources to solve the problems.  If you come to the SHARE
  6950. meeting, use some restraint when talking to the IBM people who are listening
  6951. and trying to help us.  They are people just like you and I.  They will get
  6952. very defensive if you start screaming at them.  We have a good working
  6953. relationship and I do not want to ruin it this far into the effort.
  6954.  
  6955. Ed Hart
  6956.  
  6957.  2-Sep-88 12:54:15-GMT,2369;000000000001
  6958. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA28559; Fri, 2 Sep 88 08:54:12 EDT
  6959. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Fri 2 Sep 88 08:53:26-EDT
  6960. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 02 Sep 88 08:47:33 EDT
  6961. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  6962.  id 0170; Fri, 02 Sep 88 08:47:31 EDT
  6963. Received: by BITNIC (Mailer X1.25) id 7006; Fri, 02 Sep 88 08:45:44 EDT
  6964. Date:         Thu, 1 Sep 88 16:49:00 MET
  6965. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6966. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  6967. From: Johan van Wingen <MOSGLA%HLERUL2.BITNET@cuvmb.cc.columbia.edu>
  6968. Subject:      SC2 meeting
  6969. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  6970.  
  6971.  
  6972. Dear list subscribers
  6973.  
  6974. The paper by Mr. Hart is a very valuable contribution to the character
  6975. code discussion with IBM. But we should not forget that also ISO codes
  6976. have their imperfections. ISO standards are not conceived in a ivory
  6977. tower, and development can be influenced. The responsible subcommittee
  6978. ISO/IEC JTC1/SC2 will meet in the week of 17 October in London.
  6979. Attendance is restricted to national delegates. You can be one, if you
  6980. be appointed by your national standards institute (the money for the
  6981. trip you have to provide yourself, mostly). If there is a national SC2
  6982. for your country, they will nominate. But, often they are in want for
  6983. people knowing the matter, who are also prepared to do some work. So,
  6984. contact your NSI, ask for the names of the people charged with character
  6985. codes and tell them your interests. If you are successful we'll see each
  6986. other in London, if not, explain to me your ideas, perhaps I can do
  6987. something with it. (For US citizens, ANSI rules are different, you have
  6988. to be backed by some organization.) Should you not know where your NSI
  6989. is, contact me.
  6990. I have just completed the first draft of a paper for SC22 and SC2, on
  6991. Coded Character Sets and Programming Languages. Its 800 lines will be
  6992. sent to Mr. Hart, to be ordered on request from JHUVM, for your comment.
  6993. Yours faithfully, Johan van Wingen
  6994.  
  6995.  FROM  J. W. van Wingen    MOSGLA@HLERUL2   :
  6996.      Mail to                                :
  6997.  P. O. Box 486,  2300AL Leiden, Netherlands :
  6998.  
  6999.  
  7000.  9-Sep-88 14:19:35-GMT,3809;000000000001
  7001. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA26215; Fri, 9 Sep 88 10:19:19 EDT
  7002. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Fri 9 Sep 88 10:28:00-EDT
  7003. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 09 Sep 88 10:26:38 EDT
  7004. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7005.  id 5539; Fri, 09 Sep 88 10:26:37 EDT
  7006. Received: by BITNIC (Mailer X1.25) id 4428; Fri, 09 Sep 88 10:28:30 EDT
  7007. Date:         Fri, 9 Sep 88 12:12:11 +0200
  7008. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7009. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7010. From: Andre PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
  7011. Subject:      Re: CP 37 vs CP 500 vs ?
  7012. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  7013. In-Reply-To:  Message of Wed, 7 Sep 88 17:18:52 EST from <KESICH@NYUCIMSA>
  7014.  
  7015. >What is BITNET's position on all this - have they chosen an official
  7016.  
  7017. BITNET transfers files without conversion and ignores codes issues apparently,
  7018. being mostly EBCDIC-EBCDIC or restricted to understanding notes.
  7019. But the problem *had* to be solved when the data goes through an ASCII-EBCDIC
  7020. gateway. These, to the best of my knowledge, converged to translating ASCII
  7021. to "that" EBCDIC which is Edwin's proposition: CECP 037 with brackets
  7022. at AD,BD. But they also convert ASCII circumflex 5E to EBCDIC 5F which is
  7023. the not sign in 037. Much EBCDIC data is consequently stored on BITNET servers
  7024. in this code. These gateways have thus established a de-facto standard.
  7025. Pressing them to change their translation to respect that of the
  7026. graphics "circumflex" and "not sign" would certainly cause acute problems.
  7027. On the other hand, when (if?) a BITNET standard code will exist, it would be
  7028. most welcome these gateways perform 8-bit translation of this code to ISO8859.
  7029. The other side is 8-bit mostly, isn't it?
  7030. And while we are at it, why not ask them to implement a "no conversion"
  7031. feature that would be specified in the RFC header?
  7032. Will other versions of ISO8859 and their corresponding EBCDICs (one each :-) )
  7033. be defined so that they use the same translation?
  7034.  
  7035. To be specific, I'd like to make sure the modified CECP 037 is as follows:
  7036.  
  7037. - 037 brackets are moved from BA to AD and BB to BD.
  7038. - the displaced characters conversely move from AD to BA and BD to BB.
  7039. - thus we have ISO-CECP 037' conversion 5B-AD 5D-BD DD-BA A8-BB.
  7040. ? will "circumflex" and "not sign" still be 5E-B0 AC-5F (1)
  7041.   or as per the gateways 5E-5F and consequently AC-B0 ? (2)
  7042.  
  7043. I could not find a better solution than to implement (1) for terminal mode
  7044. and (2) for file transfer. (2) for terminal mode would impair either ISO8859
  7045. or CECP037 and worse, ASCII or EBCDIC.
  7046.  
  7047. Right?  Any comment?
  7048.  
  7049. >      1) code page translation can be implemented automatically and
  7050. >         transparently when data traverses certain RSCS links
  7051.  
  7052. IBM says so, but it is not that easy.
  7053. Translating requires both source and destination codes to be known, binary
  7054. being a special case where the table is null translation.
  7055. If a receiver cares to indicate its codepage, the only way to know the source
  7056. one is to have the sender tag the file accordingly. Many can be expected not
  7057. to care for that.
  7058. A by-site code tag to be added to the BITNET tables could be imagined,
  7059. but one still has to know if the file is binary or text and really that
  7060. installation's code.
  7061. No, I think this would add to the problem of knowing what was the source code
  7062. that of also knowing what translation RSCS did use and keep us checking files
  7063. codes forever. And the tagging of files can take longer to install than using
  7064. a common code, which is a better long term solution towards everyone's promised
  7065. peace of mind.
  7066.  
  7067. Andr).
  7068.  
  7069.  9-Sep-88 19:44:39-GMT,1699;000000000001
  7070. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA18632; Fri, 9 Sep 88 15:44:28 EDT
  7071. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Fri 9 Sep 88 15:53:27-EDT
  7072. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 09 Sep 88 15:52:01 EDT
  7073. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7074.  id 6067; Fri, 09 Sep 88 15:52:00 EDT
  7075. Received: by BITNIC (Mailer X1.25) id 1166; Fri, 09 Sep 88 15:52:02 EDT
  7076. Date:         Fri, 9 Sep 88 15:14:26 EDT
  7077. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7078. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7079. From: Roger Fajman <RAF%NIHCU.BITNET@cuvmb.cc.columbia.edu>
  7080. Subject:      Re:  CP37 code assignments
  7081. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  7082.  
  7083. Getting any given program to accept multiple code points for brackets
  7084. or whatever characters is only half the battle.  It also has to be able
  7085. to produce output that will be readable on the devices you are using.
  7086. How would you like to read a listing of a C program in which all the
  7087. brackets and braces printed as blanks?
  7088.  
  7089. As for BITNET, it seems to me that the network should pick a single
  7090. standard code page for EBCDIC text files and nodes should be encouraged
  7091. to translate whatever local code page they are using to that standard
  7092. as the file is transmitted.  The receiver can then translate it to
  7093. whatever they use.  I don't think that intermediate nodes should be
  7094. performing translations.  At this point, however, it seems best to see
  7095. what IBM does before making a decision about which code page to use.
  7096.  
  7097. 10-Sep-88  8:29:24-GMT,4925;000000000001
  7098. Received: from CU20B.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22026; Sat, 10 Sep 88 04:29:20 EDT
  7099. Received: from CUVMB.CC.COLUMBIA.EDU by CU20B.CC.COLUMBIA.EDU with TCP; Sat 10 Sep 88 04:29:12-EDT
  7100. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Sat, 10 Sep 88 04:27:49 EDT
  7101. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7102.  id 6437; Sat, 10 Sep 88 04:27:47 EDT
  7103. Received: by BITNIC (Mailer X1.25) id 6492; Sat, 10 Sep 88 04:29:38 EDT
  7104. Date:         Sat, 10 Sep 88 03:20:00 CDT
  7105. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7106. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7107. From: Richard <TILLEY%UOFMCC.BITNET@cuvmb.cc.columbia.edu>
  7108. Subject:      Re: CP 37 vs CP 500 vs ?
  7109. To: Frank da Cruz <SY.FDC@cu20b.cc.columbia.edu>
  7110.  
  7111. >   - thus we have ISO-CECP 037' conversion 5B-AD 5D-BD DD-BA A8-BB.
  7112. >   ? will "circumflex" and "not sign" still be 5E-B0 AC-5F (1)
  7113. >     or as per the gateways 5E-5F and consequently AC-B0 ? (2)
  7114. >
  7115. >   I could not find a better solution than to implement (1) for terminal mode
  7116. >   and (2) for file transfer. (2) for terminal mode would impair either ISO8859
  7117. >   or CECP037 and worse, ASCII or EBCDIC.
  7118.  
  7119. A better solution is to use (2) for both terminal mode and for file transfer.
  7120. This has the effect of interchanging "not" and "circumflex" in CP 37 so that
  7121. it would agree with the current de facto standard.
  7122. This standard is widely used in software that supports ASCII terminals such as
  7123. Waterloo Script, Kermit, and SAS. We rarely have to make mods to software.
  7124. Following existing standards is the easiest way to get a "Standard" accepted,
  7125. since it already has been accepted. No changes to gateways or languages such
  7126. as PLI would be needed. Existing EBCDIC devices would display a "not sign"
  7127. instead of a "circumflex" unless they were changed.
  7128.  
  7129. I believe that it is the nature of standards to evolve unless a lot of work
  7130. is done to invent new standards that do not follow the emerging one.
  7131. Such work can cause many years of problems. A good example is the original
  7132. "bit mapped" ASCII keyboard which took decades to finally expire.
  7133. IBM's decision to ignore both there own, and SHARE's recommmendations for
  7134. the position of "braces" is another example. In this case
  7135. it was the original standard that died.  The point is that it takes
  7136. at least a decade of "evolution" to resolve the confusion so caused.
  7137.  
  7138. The reason for the current relatively stable ASCII/EBCDIC standard is
  7139. that many years have elapsed since an existing standard was ignored.
  7140. I am not counting the new "Standard" in the VS Fortran manual since
  7141. it is too silly to be a threat. However CP 37 as it exists is very
  7142. much a threat. The lower half is only wrong in 3 places. This table
  7143. could very well become the next standard but only after another
  7144. decade of confusion. This confusion would not be "to our benefit."
  7145. However a modified CP 37 Version 2 as suggested above would become
  7146. a standard almost overnight.
  7147.  
  7148. One is tempted to wonder why, each time a standard evolves, a monkey
  7149. wrench is then thrown?  I don't believe the excuses that have been
  7150. suggested - IBM is not aware of the problem or is too big or cannot
  7151. afford to follow standards. Following standards is much easier
  7152. than ignoring them.  Who cares where the brackets and braces and
  7153. circumflex, tilde, vertical, etc. are, as long as they don't
  7154. dance around. This battle of the brackets may be a minor skermish
  7155. in the war between ASCII and EBCDIC. The eventual winner of this
  7156. war will be the one supported by the most software, much like
  7157. the VCR war between BETA and VHS. It has been suggested that it
  7158. is easy to modify software. This is true for software that has no
  7159. explicit support for ASCII terminals. I once installed a version
  7160. of APL from Yale that had more translate tables than I could count.
  7161. Some in TCAM. Some in APL itself. Some in "auxillary processors".
  7162. Data often went through more than one table serially, so that
  7163. changes to one table required changes to others. Unless there is
  7164. a standard translate it is a mistake to use ASCII terminals on
  7165. corporate mainframes.
  7166.  
  7167. Dedicated ASCII terminals seem to be going the way of dedicated
  7168. word processors - to be replaced with micros. The latter are able
  7169. to emulate either ASCII or EBCDIC terminals. Ten more years of
  7170. confusion will discourage developers from including ASCII support
  7171. in their software.
  7172.  
  7173. This current effort by SHARE to create a new "Standard" is likely
  7174. to delay the evolution of a standard since it is seeking support
  7175. from an organization that doesnt want a standard to evolve. Neither
  7176. SHARE nor BITNET could impose a standard without the help of
  7177. a rich organization. How about the US military? If they can make
  7178. COBOL a standard, then this should be trivial!
  7179.  
  7180. Sorry for the overall negative tone. I hope a few positive notes
  7181. crept through.
  7182.  
  7183. Date:         Fri, 4 Nov 88 20:23:43 GMT
  7184. Sender:       ASCII/EBCDIC character set related issues <ISO8859@JHUVM>
  7185. From:         "Matthias Melcher +49 6221 5645-23,-01" <$28@DHDURZ1>
  7186. Subject:      Code Page 037 vs. 500
  7187. To:           Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
  7188.  
  7189. Today we received IBM's answer to our formal enquiry about their
  7190. recommendation concerning the choice between code page 500 and 037:
  7191.  
  7192. "The statement of Mr. Hart is correct that IBM has not decided on
  7193. a single code page with the character repertoire for the international
  7194. standard ISO 8859-1. This would not be within the meaning of the CECP
  7195. (Country Extended Code Page) concept either, which is supposed to
  7196. enable the user to undisturbedly migrate from the current to the
  7197. extended character repertoire of the respective EBCDIC version in use.
  7198.  
  7199. This does not alter the fact, however, that IBM declared the table 500
  7200. the "strategic" code page and - as correctly quoted by Mr. Melcher
  7201. from the CECP announcement - recommend it for international
  7202. applications.
  7203.  
  7204. The decision which table to use is always up to the user himself.
  7205. Regarding the internationality, however, of the network under discussion
  7206. I would consider it false and short-sighted to prefer a national version
  7207. of EBCDIC (even if it is the American one) to the international version.
  7208. This is especially true because also non-EBCDIC oriented devices and
  7209. systems will be connected to the network (7- and 8-bit ASCII). A
  7210. one-to-one correspondence of the characters of 7-bit ASCII to the
  7211. restricted EBCDIC, for instance, is given only when using table 500."
  7212.  
  7213. (Wilhelm Friedrich Bohn, National Requirements and Standards,
  7214. IBM Headquarter, Stuttgart, Germany)
  7215. 11-Nov-88 22:13:58-GMT,1851;000000000001
  7216. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA11215; Fri, 11 Nov 88 17:13:41 EST
  7217. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 11 Nov 88 17:14:28 EDT
  7218. Received: from PSUVM.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7219.  id 5046; Fri, 11 Nov 88 17:14:26 EDT
  7220. Received: by PSUVM (Mailer X1.25) id 5545; Fri, 11 Nov 88 17:07:53 EST
  7221. Date:         Fri, 11 Nov 88 13:23:35 CST
  7222. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7223. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7224. From: Rick Troth <TROTH%TAMCBA.BITNET@cuvmb.cc.columbia.edu>
  7225. Subject:      Re: Code Page 037 vs. 500
  7226. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7227. In-Reply-To:  Message of Fri, 4 Nov 88 20:23:43 GMT from <$28@DHDURZ1>
  7228.  
  7229.         That code page 500 is "strategic" conflicts with the CECP objective
  7230. of "undisturbed" migration because:  all of the gateways on this international
  7231. network (that translate EBCDIC to ASCII and vice versa) conform to an EBCDIC
  7232. code page incompatible with CP 500.  How can you "undistrubedly" migrate when
  7233. everything current is written for a not-compatible code set?
  7234.  
  7235.         But obviously Code Page 037 is not satisfactory either,  although it
  7236. does conform to most existing compilers (except C, TeX, SAS, etc).  Ed, what do
  7237. do we call a modified CP 037?  "Network EBCDIC" ?  "Code Page 037-M" ?
  7238. And if we just swap the brackets from CP 37 to their Kermit/WiscNet/7171
  7239. points,  what do we do about the circumflex -vs- logical not problem?
  7240.  
  7241. "Truth is truth"                             - Rick Troth <TROTH@TAMCBA.BITNET>
  7242.         Louis Gossett, Jr.                                 TAMCBA VM Operations
  7243.                 "Enemy Mine"                      Texas A&M College of Business
  7244.  
  7245. 12-Nov-88  3:19:46-GMT,2265;000000000001
  7246. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA05421; Fri, 11 Nov 88 22:19:43 EST
  7247. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Fri, 11 Nov 88 22:20:33 EDT
  7248. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7249.  id 5301; Fri, 11 Nov 88 22:20:31 EDT
  7250. Received: by BITNIC (Mailer X1.25) id 1093; Fri, 11 Nov 88 22:19:50 EST
  7251. Date:         Fri, 11 Nov 88 21:39:41 EST
  7252. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7253. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7254. From: Edwin Hart <HART%APLVM.BITNET@cuvmb.cc.columbia.edu>
  7255. Subject:      Re: Code Page 037 vs. 500
  7256. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7257. In-Reply-To:  Your message of Fri, 11 Nov 88 13:23:35 CST
  7258.  
  7259. In the SHARE paper we are asking for one "Reference EBCDIC", it may be
  7260. code page 500 v1 or code page 37 v1 (or v2 with the brackets at X'AD' and
  7261. X'BD'.  I do not know.  I get conflicting requirements from discussions.
  7262.  
  7263.   1.  Some say give me one standard, I don't care what it is as long as
  7264.       you support it.  (I would include compiler support here.)  I will
  7265.       convert once, but don't ever ask met to do it again.
  7266.   2.  Others say give me one standard but make it code page 37 with the
  7267.       brackets in the TN/T11 code points.
  7268.   3.  Many Europeans have already converted to code page 500, they do not
  7269.       want to convert to code page 37.  I can't blame them.  However, they
  7270.       are already 99% there with code page 500.  (characters at 7 code points
  7271.       are shuffled around between CP 37 and CP 500).
  7272.  
  7273. For the logical not problem, I see requirements for:
  7274.  
  7275.   1.  a utility to help you convert data and programs from many different
  7276.       code pages into the new "Reference EBCDIC and ASCII" code pages.
  7277.       I also want it to be able to map both the EBCDIC not (^) and circumflex
  7278.       (5) into the logical NOT.  I also want both vertical bar (|) and split
  7279.       vertical bar (:) to map into the logical OR.  Some also want the tilde
  7280.       to map into the logical NOT.
  7281.   2.  compilers to recognize (possibly as a user invoked option) these kinds
  7282.       of relationships
  7283.  
  7284. What do you think?
  7285. Ed Hart
  7286.  
  7287. 17-Nov-88  1:15:26-GMT,3794;000000000001
  7288. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA23325; Wed, 16 Nov 88 20:15:09 EST
  7289. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 16 Nov 88 20:15:13 EDT
  7290. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7291.  id 1534; Wed, 16 Nov 88 20:15:10 EDT
  7292. Received: by BITNIC (Mailer X1.25) id 3262; Wed, 16 Nov 88 20:14:30 EST
  7293. Date:         Wed, 16 Nov 88 19:35:58 +0100
  7294. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7295. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7296. From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
  7297. Subject:      Re: Code Page 037 vs. 500
  7298. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7299. In-Reply-To:  Message of Fri, 4 Nov 88 20:23:43 GMT from <$28@DHDURZ1>
  7300.  
  7301. >Today we received IBM's answer to our formal enquiry about their
  7302. >recommendation concerning the choice between code page 500 and 037:
  7303. > [text deleted]
  7304. >enable the user to undisturbedly migrate from the current to the
  7305. >extended character repertoire of the respective EBCDIC version in use.
  7306. >
  7307. >This does not alter the fact, however, that IBM declared the table 500
  7308. >the "strategic" code page and - as correctly quoted by Mr. Melcher
  7309. >from the CECP announcement - recommend it for international
  7310. >applications.
  7311. >
  7312. >The decision which table to use is always up to the user himself.
  7313.  
  7314. Before CECP's, we (Belgian) decided of an ASCII/EBCDIC conversion table
  7315. when we started to use communication software. This was in fact
  7316. removing a historical mod and adopting the standard VM tables. From
  7317. then on, every software in sight, the 7171's, and joining BITNET were
  7318. telling us we had made the right move.
  7319. Having two kinds of 3270 terminals and some funny printers was
  7320. considered as the inevitable result of the chaos of the computing
  7321. world. Without our accented letters, we were used to restrictions and
  7322. didn't care much as long as a capital A was a capital A.
  7323.  
  7324. That the hardware finally supporting these accented letters was of
  7325. that strange kind too was discovered by chance and it came as a shock
  7326. when I did. Only later could we raise a discussion with IBM and hear
  7327. the same tune as the one quoted above and of the existence of 037.
  7328. Only later did I learn from BITNET that our code is called a ghost
  7329. name 037 v2 and that many people love ghosts.
  7330.  
  7331. What undisturbed migration means to us is that I had to start CECP 500
  7332. support on our 7171's and file transfer in addition to 037 v2. That it
  7333. took a long time, catalysed a serious bug in the PC (KEYB losing
  7334. interrupts) and an annoying feature of the 7171 in APL mode
  7335. (refreshing the end of line on overstrike) and raises embarrassing
  7336. questions from our users.
  7337.  
  7338. >Regarding the internationality, however, of the network under discussion
  7339. >I would consider it false and short-sighted to prefer a national version
  7340. >of EBCDIC (even if it is the American one) to the international version.
  7341.  
  7342. I *am* short-sighted, but still can tell an exclamation mark instead
  7343. of a vertical bar in a VM help screen.
  7344. Why does such a strategic code lack a decent font on our 3812?
  7345. Is all that software really going to be converted or is GDDM be a
  7346. CECP 500 to 037 translator for European use only?
  7347.  
  7348. >This is especially true because also non-EBCDIC oriented devices and
  7349. >systems will be connected to the network (7- and 8-bit ASCII). A
  7350. >one-to-one correspondence of the characters of 7-bit ASCII to the
  7351. >restricted EBCDIC, for instance, is given only when using table 500."
  7352.  
  7353. I can translate any PC code page to any CECP for the simple reason
  7354. that IBM has defined translation between all these tables and ISO8859
  7355. and claims it's the rule of the game of future communication.
  7356. And I applaud this point.
  7357.  
  7358. Andr).
  7359.  
  7360. 17-Nov-88  1:24:46-GMT,5138;000000000001
  7361. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA24689; Wed, 16 Nov 88 20:24:42 EST
  7362. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 16 Nov 88 20:24:47 EDT
  7363. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7364.  id 1544; Wed, 16 Nov 88 20:24:45 EDT
  7365. Received: by BITNIC (Mailer X1.25) id 3501; Wed, 16 Nov 88 20:24:11 EST
  7366. Date:         Wed, 16 Nov 88 17:38:08 +0100
  7367. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7368. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7369. From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
  7370. Subject:      Re: Code Page 037 vs. 500
  7371. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7372. In-Reply-To:  Message of Mon, 14 Nov 88 09:18:18 EST from <GILBERT@YALEVM>
  7373.  
  7374. Two problems of codes are discussed on this list.
  7375. The first is the meaning of computer encoded data and is an intricate
  7376. one indeed. And I totally aggree that software must be designed to be
  7377. code independent.
  7378. The second is that our networks are text based and do not transport
  7379. data in an undisturbed way, just because of of a lack of agreement in
  7380. the field of the first problem. What should be a simple matter is
  7381. hidden behind a puzzle, despite a simple evident solution.
  7382.  
  7383. Either code A and B do not represent the same objects and there is no
  7384. meaning attached to transcoding one to the other. Or they do and there
  7385. is no theorical reason more than one should exist. Practically
  7386. however, at least ASCII and EBCDIC exist for 7-bits codes and a host
  7387. of looking alike ones for 8-bit extensions.
  7388.  
  7389. To cope with N+1 codes that can fully transcode one to the other (or
  7390. whose similarity is such that an approximate transcoding can be
  7391. defined and accepted), a common single reference code is needed and
  7392. should be the favoured vehicle. Else, every user of one of these must
  7393. cope with N translate tables (and find out which to use) instead of a
  7394. single one. This amounts to a total of N! tables pairs (some will
  7395. write N| :-) instead of N. This is what I call each minding his own
  7396. business.
  7397. I would have reached more than 100000 otherwise.
  7398. At least, there should be no ambiguity as to the code used on a given
  7399. data path in terms of translation to the reference one, and, by
  7400. extension, to any other, when, for any reason, a code other than the
  7401. chosen reference one is used. This means the transcodings by gateways
  7402. should be coherent and the data unchanged when it returns to a path
  7403. using the same code.
  7404. Given that, anyone will be able to peacefully send his C source file
  7405. to anyone.
  7406.  
  7407. Transporting data that cannot meaningfully transcode to the reference
  7408. code would suggest that a so-called binary mode should be implemented,
  7409. that is no translation across gateways, in fact the less ambiguous
  7410. translation. But if we have agreed upon the first point, we know that
  7411. user B will receive unmodified data from user A as long as both ends
  7412. communication lines use the same code.
  7413. If they don't and the data is meant to be usable on the receiving
  7414. system, two codes exist to represent the data.
  7415. These two codes should translate the same way as would data of the
  7416. reference code. This is the second rule of the game.
  7417.  
  7418. Of course, 8-bit codes will travel easily only on 8-bit paths, but I
  7419. think 8-bit communication is one thing easily at hand.
  7420. 8-bit codes are limited, but just as 8-bit I/O chips are still used
  7421. with 32-bit processors I see no near future for wider.
  7422. So, we must admit a single 8-bit code will not cover all needs. The
  7423. various ISO8859 versions are the most obvious example and it makes me
  7424. sorry to see that we are forced to repeat with 8-bit a cause of the
  7425. present problem, which was tucking different codes on 7-bit. But this
  7426. time, we are limited by hardware.
  7427. So, unless code switching techniques are used (exactly what the
  7428. extension to 8-bit is trying to avoid), the x of ISO8859-x will be a
  7429. tag of the data. But the data lines will be independent of x.
  7430.  
  7431. The problem of deciding of wich translate tables to use is complicated
  7432. by the fact that it must be discussed in terms of practical existing
  7433. codes and will favour one instead of the other. And this raises
  7434. religion wars, apparently only in the EBCDIC world. Ironically enough
  7435. because of a 7-bit problem only and a handful of code points.
  7436.  
  7437. ISO8859 does not look like controversed in the ASCII world and is what
  7438. I take as the reference one.
  7439. But is must be emphasised that all devices loose their ASCII label
  7440. when considered with an 8-bit point of view. An IBM PC, Macintosh or
  7441. whatever must translate its code to ISO8859 on the communication line,
  7442. be it for text file transfer or terminal mode. This requires that a
  7443. precise translate table be defined for the 256 code points. This has
  7444. been done by IBM, but I have been unable to obtain that from Apple. I
  7445. did not even try others.
  7446.  
  7447. If anyone knows any, I am much interested.
  7448.  
  7449. All this with the best of my limited knowledge of a code called
  7450. English. But this is another problem that was forced upon us by the ages.
  7451. Let us at least make simple what we can invent.
  7452.  
  7453. Andr).
  7454.  
  7455. 23-Nov-88  5:19:08-GMT,1710;000000000001
  7456. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA00983; Wed, 23 Nov 88 00:19:04 EST
  7457. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 23 Nov 88 00:08:06 EDT
  7458. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7459.  id 0162; Wed, 23 Nov 88 00:08:05 EDT
  7460. Received: by BITNIC (Mailer X1.25) id 2703; Wed, 23 Nov 88 00:07:59 EST
  7461. Date:         Tue, 22 Nov 88 12:13:20 CST
  7462. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7463. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7464. From: Michael Sperberg-McQueen <U18189%UICVM.BITNET@cuvmb.cc.columbia.edu>
  7465. Subject:      TCP/IP support for ISO8859?
  7466. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7467.  
  7468. When I asked this question on the TCP list, no one answered, either
  7469. because they thought it uninteresting, or because they didn't know the
  7470. answer, or because they didn't understand the question.  This list ought
  7471. at least to understand the question.
  7472.  
  7473. I am using IBM's VM and PC TCP/IP products to Telnet into our 3081
  7474. running VM/CMS as a virtual 3270, across an Ethernet.  The connection is
  7475. clearly an eight-bit connection, and the code points not assigned by
  7476. 94-character EBCDIC are being mapped into the eight-bit extended ASCII
  7477. of my PS/2.
  7478.  
  7479. The question:  does anyone know where this mapping is being done, or
  7480. what is needed to customize it (or, I should say, to correct it) so that
  7481. it maps correctly from the PS/2 modification of ISO8859-1 to one or the
  7482. other of the extended EBCDIC code pages?
  7483.  
  7484. Many thanks for any hints or tips.
  7485.  
  7486. -Michael Sperberg-McQueen
  7487.  University of Illinois at Chicago
  7488.  
  7489. 23-Nov-88  5:19:12-GMT,1918;000000000001
  7490. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA00987; Wed, 23 Nov 88 00:19:07 EST
  7491. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 23 Nov 88 00:13:13 EDT
  7492. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7493.  id 0170; Wed, 23 Nov 88 00:13:12 EDT
  7494. Received: by BITNIC (Mailer X1.25) id 2958; Wed, 23 Nov 88 00:12:57 EST
  7495. Date:         Tue, 22 Nov 88 18:19:46 +0100
  7496. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7497. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7498. From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
  7499. Subject:      Translation of ASCII DEL
  7500. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7501.  
  7502. A discussion with John Chandler raised a question.
  7503. I modified his Kermit 370 tables as per the tables I got from IBM
  7504. as the official ones and I once sent to this list to have Kermit
  7505. translate 037 v2 to ISO8859 by default.
  7506. Modifying IBM's 037 to be 037 v2 and applying them to Kermit's
  7507. was only extending the Kermit tables. Except that the Ascii DEL was
  7508. now translated to EBCDIC FF instead of the former 07 which is labeled
  7509. as DEL in the EBCDIC chart.
  7510.  
  7511. What happens is that, in addition to PC graphic symbols, IBM tucked two
  7512. characters in the ISO 80-9F unassigned range:
  7513. 9Fa=07e=Florin sign     LI61
  7514. 9Ea=0Ae=i dotless small SC07
  7515. Other control codes that Kermit used to translate to nulls now have
  7516. a definition for a graphic in that range.
  7517. I see something good in the IBM tables. They are defined for all the 256
  7518. code points and are revertible. I take it as IBM strictest right to
  7519. define a translation of its 32 additional Ctl characters to the 32 undefined
  7520. ones of ISO8859 for that sake. Why they chose not to assign the florin
  7521. sign to FF, I don't know.
  7522.  
  7523. A Florin is a Gulden, isn't it Johan?
  7524.  
  7525. Any idea?
  7526.  
  7527. Andr).
  7528.  
  7529. 23-Nov-88  5:19:06-GMT,1231;000000000001
  7530. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA00979; Wed, 23 Nov 88 00:19:01 EST
  7531. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 23 Nov 88 00:03:47 EDT
  7532. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7533.  id 0160; Wed, 23 Nov 88 00:03:45 EDT
  7534. Received: by BITNIC (Mailer X1.25) id 2554; Wed, 23 Nov 88 00:03:49 EST
  7535. Date:         Tue, 22 Nov 88 15:38:09 EST
  7536. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7537. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7538. From: Edwin Hart <HART%APLVM.BITNET@cuvmb.cc.columbia.edu>
  7539. Subject:      Re: TCP/IP support for ISO8859?
  7540. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7541. In-Reply-To:  Your message of Tue, 22 Nov 88 12:13:20 CST
  7542.  
  7543. IBM VM TCP/IP connection to PC and translations.
  7544.  
  7545. You might try using code page switching with DOS 3.3 or 4.1 to use code page
  7546. 850 which contains all of the characters of ISO 8859-1.  I am using it
  7547. successfully with the IBM PC 3270 Emulation Program Version 3.03 to transmit
  7548. files back and forth over a 3270 coax connection to Code Page 37, v1 on the
  7549. mainframe.
  7550.  
  7551. Ed Hart
  7552.  
  7553. 29-Nov-88  2:41:21-GMT,2646;000000000001
  7554. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA08871; Mon, 28 Nov 88 21:41:12 EST
  7555. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 28 Nov 88 21:40:57 EDT
  7556. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7557.  id 5924; Mon, 28 Nov 88 21:40:55 EDT
  7558. Received: by BITNIC (Mailer X1.25) id 4552; Mon, 28 Nov 88 21:36:54 EST
  7559. Date:         Wed, 23 Nov 88 12:43:09 CST
  7560. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7561. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7562. From: Rick Troth <TROTH%TAMCBA.BITNET@cuvmb.cc.columbia.edu>
  7563. Subject:      Re: Code Page 037 vs. 500
  7564. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7565. In-Reply-To:  Message of Fri, 11 Nov 88 21:39:41 EST from <HART@APLVM>
  7566.  
  7567.         Ed,  you answered my questions concisely.  Thank you.  I have put off
  7568. replying because you asked what I think and that means I will have to stop and
  7569. do so.
  7570.  
  7571.         I suggested to the networking group that Texas A&M adopt Code Page 37
  7572. and was met with  "hem ... haw"  response.  So I waited,  hoping that something
  7573. would develope from Share 71.5 or elsewhere.  Then I read the statement from
  7574. IBM in Europe (was that Germany?) supporting Code Page 500 for  "international"
  7575. use;  that bothers me since I am partial to CP 037,  (see below).
  7576.  
  7577.         We are a  "traditional VM EBCDIC"  site:  we have a 7171,  run Kermit
  7578. quite a bit,  have an RSCS connection to dozens of VAXen,  etc.  What I can now
  7579. call CP 37 V2 will work VERY well for us.  (Over and over again)  because of
  7580. the defacto translation in WISCNET and cousins,  CP 37 V2 is an easy extension
  7581. of  "EBCDIC".
  7582.  
  7583.         As I am a C fan of late,  the 7 points different between CP 037 and
  7584. CP 500 is the biggest headache IBM has created lately  (second to CP R5).
  7585. In C,  !  means  "logical NOT"  and  |  means  "bitwise OR".  Furthermore,
  7586. !=  is the relation  "does not equal"  and  |=  is bitwise OR assignment.
  7587. Brackets  []  (I now use points AD and BD without fear!)  are used to sub-
  7588. script arrays.  In a world without CP 500,  multiple code points can be mapped
  7589. to a signle meaning without having to toggle a compiler option switch,  as in
  7590. AD, BA, and (from "the 3180 set") 41 all being mapped to an open bracket.
  7591. But enter CP 500 and such  "universal mapping"  fails.
  7592.  
  7593. "It is free;  it is not cheap."                Rick Troth <TROTH@TAMCBA.BITNET>
  7594.  - Chris Osborne                                           TAMCBA VM Operations
  7595.                                                   Texas A&M College of Business
  7596.  
  7597. 29-Nov-88 14:37:38-GMT,1540;000000000001
  7598. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA13335; Tue, 29 Nov 88 09:37:34 EST
  7599. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 29 Nov 88 09:37:18 EDT
  7600. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7601.  id 6376; Tue, 29 Nov 88 09:37:16 EDT
  7602. Received: by BITNIC (Mailer X1.25) id 5902; Tue, 29 Nov 88 08:56:37 EST
  7603. Date:         Tue, 29 Nov 88 08:39:11 EST
  7604. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7605. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7606. From: Edwin Hart <HART%APLVM.BITNET@cuvmb.cc.columbia.edu>
  7607. Subject:      Re: Code Page 037 vs. 500
  7608. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7609. In-Reply-To:  Your message of Wed, 23 Nov 88 12:43:09 CST
  7610.  
  7611. I am writing the requirements in the paper now.  Basically we ask that IBM
  7612. standardize on one CECP for Latin alphabet no. 1 as defined in ISO 8859-1.
  7613. Although the wording will say SHARE prefers Code Page 37 over 500, we say
  7614. that CP 500 is acceptable if the EBCDIC compilers are modified to use CP 500
  7615. code points.  Furthermore, if IBM selects CP 37 as the base, we require that
  7616. either the IBM PASCAL and C compilers (on mainframe and midrange) be changed
  7617. to use the BA, BB brackets or that CP 37 v2 be defined with brackets in the
  7618. AD, BD code points.  In any case some kind of translation utility is required
  7619. for migration, particularly in Europe.
  7620.  
  7621. Wait for the exact wording.
  7622.  
  7623. Ed Hart
  7624.  
  7625. 15-Dec-88 13:36:32-GMT,1876;000000000001
  7626. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA00874; Thu, 15 Dec 88 08:36:27 EST
  7627. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 15 Dec 88 08:38:44 EDT
  7628. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7629.  id 6322; Thu, 15 Dec 88 08:38:42 EDT
  7630. Received: by BITNIC (Mailer X1.25) id 8918; Thu, 15 Dec 88 08:38:54 EST
  7631. Date:         Thu, 15 Dec 88 14:31:00 CET
  7632. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7633. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7634. From: Johan van Wingen <MOSGLA%HLERUL2.BITNET@cuvmb.cc.columbia.edu>
  7635. Subject:      sc2
  7636. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7637.  
  7638.  
  7639. Dear list subscribers
  7640. I paused a while with contributing to the list. Thorough comments on the
  7641. various proposals require more time than I had as yet, but some news
  7642. from the ISO JTC1/SC2 meeting in London, 17-21 Oct. may interest you. I
  7643. also attended WG2, Multiple octet coding.
  7644.  
  7645. Of course nothing was said about EBCDIC, but Mr. W. F. Bohn was there,
  7646. and at least two other people from IBM.  A number of Resolutions was
  7647. adopted, I'll give the text in my next contribution.
  7648.  
  7649. Some comments I cannot leave to a later moment. I was quite perplexed
  7650. when reading that CP037 has "versions". What does this mean? Also it was
  7651. proposed to copy things from Postscript. It should be remembered that
  7652. Adobe is taking an active part in ISO standardization and may change its
  7653. code tables to those from ISO just the moment it likes. Besides that,
  7654. ISO is now busy with developing the successor of Postscript called SPDL,
  7655. Standard Page Description Language. Doing the actual work are people
  7656. from Adobe, Xerox and IBM.
  7657.  
  7658. FROM  J. W. van Wingen    MOSGLA@HLERUL2
  7659. Mail to
  7660. P. O. Box 486,  2300AL Leiden, Netherlands
  7661.  
  7662. 12-Jan-89 23:47:35-GMT,1997;000000000001
  7663. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA20709; Thu, 12 Jan 89 18:47:27 EST
  7664. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 18:46:25 EDT
  7665. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7666.  id 0810; Thu, 12 Jan 89 18:46:23 EDT
  7667. Received: by BITNIC (Mailer X1.25) id 8384; Thu, 12 Jan 89 18:48:25 EST
  7668. Date:         Thu, 12 Jan 89 18:44:04 EST
  7669. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7670. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7671. From: Brian Eliot <USERALVE%RPITSMTS.BITNET@cuvmb.cc.columbia.edu>
  7672. Subject:      IBM 3174 code page/character set description
  7673. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7674.  
  7675. A new manual I just received contains some interesting material on this
  7676. topic.  It is
  7677.  
  7678.   GA27-3831-0  "3174 Subsystem Control Unit Character Set Reference"
  7679.  
  7680. I believe this replaces the earlier manual
  7681.  
  7682.   GA27-2837    "IBM 3270 Information Display System Character Set Reference"
  7683.  
  7684. which applies to older 3270 control units.  The items I noted were
  7685.  
  7686.  1.  3270 national language support is described in terms of "code pages"
  7687.      and "character sets" rather than the earlier "I/O interface codes".
  7688.      Thus the description clearly distinguishes character sets, character
  7689.      generators (display hardware), and code pages.
  7690.  
  7691.  2.  There is a description of the values returned by a Query Reply
  7692.      (Character Sets) structured field.  This query may be used to ask
  7693.      the terminal what character set/code page combinations it supports.
  7694.      Only a few terminals support the CGCSGID field.
  7695.  
  7696.  3.  In conjunction with the manual GA23-0214-3 "3174 Subsystem Control
  7697.      Unit Customizing Guide" you can find out about Country Extended Code
  7698.      Page (CECP) support.
  7699.  
  7700.  4.  A mapping is implicitly defined for certain control codes between
  7701.      EBCDIC and ASCII-8 (a.k.a. ISO 8859).
  7702.  
  7703. 12-Jan-89 22:16:53-GMT,1561;000000000001
  7704. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA16573; Thu, 12 Jan 89 17:16:48 EST
  7705. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Thu, 12 Jan 89 17:15:46 EDT
  7706. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7707.  id 0586; Thu, 12 Jan 89 17:15:45 EDT
  7708. Received: by BITNIC (Mailer X1.25) id 0476; Thu, 12 Jan 89 17:16:55 EST
  7709. Date:         Thu, 12 Jan 89 16:21:32 EST
  7710. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7711. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7712. From: Frank da Cruz <fdc@cunixc.cc.columbia.edu>
  7713. Subject:      ISO8859 vs Kermit
  7714. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7715.  
  7716. We are looking into the possibility of adding ISO8859 transfer syntax to the
  7717. Kermit protocol, to allow for transfer of textual data in other than the Roman
  7718. ASCII alphabet, including the transfer of text in mixed alphabets.
  7719.  
  7720. Unfortunately, I have yet to see the actual 8859 documents, and I don't really
  7721. understand how one transmits (or stores) text in mixed alphabets.  Is there
  7722. some kind of meta-character or sequence that introduces an "alphabet shift",
  7723. followed by a code that designates the alphabet to be used?  If so, can anyone
  7724. describe the actual mechanism, what the alphabet codes are, etc?  (Not the
  7725. alphabets themselves!  Just the mechanism for identifying them and switching
  7726. among them.)
  7727.  
  7728. Any information, insights, suggestions, caveats, etc, would be most
  7729. appreciated.
  7730.  
  7731.  
  7732. 16-Jan-89 15:45:20-GMT,5629;000000000001
  7733. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA26322; Mon, 16 Jan 89 10:45:16 EST
  7734. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 16 Jan 89 10:44:21 EDT
  7735. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7736.  id 4417; Mon, 16 Jan 89 10:44:19 EDT
  7737. Received: by BITNIC (Mailer X1.25) id 2349; Mon, 16 Jan 89 10:45:57 EST
  7738. Date:         Mon, 16 Jan 89 14:00:17 +0100
  7739. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7740. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7741. From: Andre' PIRARD <A-PIRARD%BLIULG11.BITNET@cuvmb.cc.columbia.edu>
  7742. Subject:      Re: ISO8859 vs Kermit
  7743. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7744. In-Reply-To:  Message of Thu,
  7745.               12 Jan 89 16:21:32 EST from <fdc@CUNIXC.CC.COLUMBIA.EDU>
  7746.  
  7747. >We are looking into the possibility of adding ISO8859 transfer syntax to the
  7748. >Kermit protocol, to allow for transfer of textual data in other than the Roman
  7749. >ASCII alphabet, including the transfer of text in mixed alphabets.
  7750.  
  7751. Nice to meet you here too, Frank,
  7752.  
  7753. Well,  it's  true ISO and ANSI define escape mechanisms to switch
  7754. from  one character set to another and in particular between  the
  7755. G0  and G1 sets of a single version of ISO 8859 when  transmitted
  7756. over a 7-bit line.  I don't think the intent is to define a means
  7757. to  store the data,  what Kermit is involved in transmitting.  It
  7758. would both be very inefficient in terms of storage space and ease
  7759. of  processing and take us back to the previous  situation  where
  7760. accented letters were stored in the form of printer-ready symbols
  7761. overstrikes,  exactly  what ISO is trying to avoid.  While  these
  7762. escape mechanisms can be used to implement a super terminal (this
  7763. may  apply to a Kermit's terminal mode) which would know all  ISO
  7764. 8859  versions  and would be driven by a fancy  host,  this  host
  7765. would be better off storing its data in 16-bits or more elements.
  7766. Consequently,  Kermit  would  transmit these.  I think  that  the
  7767. ISO8859 versions are exclusive,  but that they must translate the
  7768. same  way between ANSI and EBCDIC.  IBM switches character  sets,
  7769. but does not mix them.
  7770.  
  7771. 16 or more bits codes is a final solution,  but puts a heavy load
  7772. upon  hardware.  The  only place I've read anything like  it  but
  7773. theory  is in the OS/2 technical manual which speaks of  DBCS  in
  7774. chapter 6 ("Language DBCS environment vector of lead bytes",  how
  7775. filename  elements are not truncated in case DBCS is involved and
  7776. such faint remarks I'd like to know more about).  But DBCS  still
  7777. means  "double  byte character sets" and does not look like  true
  7778. 16-bit codes.
  7779.  
  7780. Anyone knows more about that?
  7781.  
  7782. As to Kermit dealing with ISO 8859, I've done that between IBM PC
  7783. and CMS,  and it may be interesting to explain how.  Both the CMS
  7784. (and it could be TSO) through the 7171 and the IBM PC act as  ISO
  7785. 8859 host and terminal respectively,  because I assume every byte
  7786. that  travels on the communication line is (at least supposed  to
  7787. be)  coded  in ISO.  Which version is irrelevant if I'm right  in
  7788. saying  all versions translate the same between ANSI/ISO  and  an
  7789. IBM mainframe code page. The IBM world is the worst case, because
  7790. code  pages  for  a single ISO version are multiple on  the  same
  7791. machine.  The  working  in  a different ISO  version  would  just
  7792. involve  a code page switch in terminal mode and when having  DOS
  7793. process the data.
  7794.  
  7795. - The  7171  translate tables have been set up to  translate  the
  7796. host  code  page to/from ISO 8859/x.  Which code page for the  /x
  7797. version  is used (037v2 or 500) is selected by the answer to  the
  7798. terminal type request.
  7799. - CMS  Kermit  translate  tables have  been  modified  to  extend
  7800. ASCII/EBCDIC  translation  to ISO/CECP 037v2 to minimize  dynamic
  7801. redefinition.  E. G. selecting CECP 500 is now a handful of SETs.
  7802. Thanks to John Chandler for a versatile file transfer translation
  7803. support.
  7804. - The program on the micro translates transferred text files from
  7805. the line's ISO code to/from a user's selectable one (437,  850 or
  7806. ISO itself which means no translation). This is super easy to add
  7807. to any Kermit (just the user interface causes problems).
  7808. - It does the same for terminal mode.  Easy too: SI/SO + a simple
  7809. translation some already do.
  7810.  
  7811. This  is  in line with the idea I once developed  on  the  Kermit
  7812. lists  that  using  ISO  as  the  inter-systems  vehicle   really
  7813. simplifies the handling and user understanding of the various IBM
  7814. or  other's codes (each system deals with its own(s)).  In  fact,
  7815. I've  made  a step beyond that.  In addition to the one for  file
  7816. transfer,  the translations made in the program on the micro  are
  7817. made  at  the  keyboard  and screen  interfaces.  This  means  it
  7818. processes the ISO code in memory (but it could be any) and  never
  7819. does  translation of the line code.  The internal encoding of the
  7820. program's  messages is ISO;  this makes them independent  of  the
  7821. code  page the systems uses.  Two translation are made.  One  for
  7822. menu mode and the other for terminal mode.  The one for menu mode
  7823. is  the  translation  between ISO and the system's code  page  at
  7824. startup.  The one for terminal mode is the user's choice and  may
  7825. also  implies  a code page the system is asked to switch to  each
  7826. time the user enters terminal mode.
  7827.  
  7828. Again,  there is no restrictions on which code can be  used.  New
  7829. ones can be added to the program by configuration,  including the
  7830. null-translation-throughout  so  that it remains compatible  with
  7831. any Kermit implementation.
  7832.  
  7833. I hope this will help.
  7834.  
  7835. Andr).
  7836.  
  7837. 16-Jan-89 20:46:31-GMT,1906;000000000001
  7838. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA08283; Mon, 16 Jan 89 15:46:28 EST
  7839. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Mon, 16 Jan 89 15:45:33 EDT
  7840. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7841.  id 4742; Mon, 16 Jan 89 15:45:31 EDT
  7842. Received: by BITNIC (Mailer X1.25) id 5200; Mon, 16 Jan 89 15:47:36 EST
  7843. Date:         Mon, 16 Jan 89 10:49:33 EST
  7844. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7845. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7846. From: Edwin Hart <HART%APLVM.BITNET@cuvmb.cc.columbia.edu>
  7847. Subject:      Re: ISO8859 vs Kermit
  7848. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7849. In-Reply-To:  Kermit and ISO 8859
  7850.  
  7851. For character set switching, see the ISO 2022 standard.  The ANSI X3.134.1
  7852. standard, 8-bit ASCII Structure and Rules appears to have the information
  7853. you will need.  ANSI X3.134.2 is the U.S. equivalent of ISO 8859-1.  However,
  7854. as I read it, it allows the 8859-1 characters to exist in the 7-bit world.
  7855. This may be of interest to you.  You should also read about IBM Country
  7856. Extended Code Pages (9 of them) which have the same character set as ISO
  7857. 8859-1, and PC Multilingual Code Page 850.  (See SHARE 69 Proceedings, pp.
  7858. 19-28, August, 1987.)
  7859.  
  7860. With respect to ISO 8859-2, and the corresponding IBM Code Page, the translate
  7861. table for these two is DIFFERENT from the one for 8859-1 to CECPs.  I do not
  7862. know about the other 8859 and IBM code page translate tables.
  7863.  
  7864. If you have an IBM APA printer and SCRIPT, I can send you code tables for
  7865. ISO 8859-1, CECP 37 v1. Data Processing Code Page, and CECP 500 v1. Office
  7866. Systems Code Page.  The code tables print correctly except for about 5-10
  7867. characters.
  7868.  
  7869. ISO standards are available from ANSI which is right in New York City.
  7870.  
  7871. Ed Hart
  7872.  
  7873. 24-Jan-89 12:15:21-GMT,3335;000000000001
  7874. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29846; Tue, 24 Jan 89 07:15:09 EST
  7875. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Tue, 24 Jan 89 07:13:04 EDT
  7876. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7877.  id 5066; Tue, 24 Jan 89 07:13:02 EDT
  7878. Received: by BITNIC (Mailer X1.25) id 3455; Tue, 24 Jan 89 07:14:59 EST
  7879. Date:         Tue, 24 Jan 89 12:45:00 CET
  7880. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7881. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7882. From: Johan van Wingen <MOSGLA%HLERUL2.BITNET@cuvmb.cc.columbia.edu>
  7883. Subject:      Parts of ISO 8859
  7884. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7885.  
  7886.  
  7887. Dear list subscribers
  7888. Here is the information that was wanted about ISO 8859.
  7889.   ISO 8859               8-bit single byte coded graphic character sets
  7890.   ISO 8859/1  1987-02-15  Latin alphabet no. 1
  7891.   ISO 8859/2  1987-02-15  Latin alphabet no. 2
  7892.   ISO 8859/3  1988-04-15  Latin alphabet no. 3
  7893.   ISO 8859/4  1988-04-15  Latin alphabet no. 4
  7894.   DIS 8859/5 (1988-03-15) Latin/Cyrillic alphabet
  7895.   ISO 8859/6  1988-08-15  Latin/Arabic alphabet
  7896.   ISO 8859/7  1987-11-15  Latin/Greek alphabet
  7897.   ISO 8859/8  1988-06-15  Latin/Hebrew alphabet
  7898.   DIS 8859/9 (1989-02-15) Latin alphabet no. 5
  7899.   ISO 9036    1987-04-15  Arabic 7-bit coded character set
  7900.                       for information interchange
  7901.   (date for a DIS means "voting terminates on:".)
  7902.  
  7903. There is a list of languages covered by each of the 9 parts, under
  7904. "Field of application". This includes:
  7905. for Part 1:
  7906. Spanish, Portuguese, Italian, French, English, Irish, German, Dutch,
  7907. Danish, Faeroese, Icelandic, Norwegian, Swedish, Finnish.
  7908. for Part 2:
  7909. English, German,
  7910. Czech, Slovak, Hungarian, Polish, Rumanian, Serbocroatian, Slovene,
  7911. Albanian.
  7912. for Part 3:
  7913. Spanish, Italian, French, English, German, Dutch,
  7914. Afrikaans, Catalan, Maltese, Turkish, Esperanto.
  7915. for Part 4:
  7916. English, German,
  7917. Danish, Greenlandic, Norwegian, Swedish, Finnish, Lappish,
  7918. Estonian, Latvian, Lithuanian.
  7919. for Part 5:
  7920. English,
  7921. Russian, Byelorussian, Ukrainian, Bulgarian, Serbocroatian, Macedonian.
  7922. for Part 9:
  7923. (as Part1, but with Turkish instead of Icelandic)
  7924.  
  7925. Annex A gives: "The coded character set of this part of ISO 8859 contains
  7926. graphic characters used in at least the following countries:".
  7927. This includes:
  7928. for Part 1: all countries of North, South and Middle America, Australia,
  7929. New Zealand, Spain, Portugal, Italy, France, United Kingdom, Ireland,
  7930. Switzerland, Liechtenstein, Austria, Germany,
  7931. Belgium, The Netherlands, Luxemburg,
  7932. Denmark, Faroe Islands, Iceland, Norway, Sweden, Finland.
  7933. for Part 2:  Switzerland, Austria, Germany,
  7934. Czechoslovakia, Hungary, Poland, Romania, Yugoslavia, Albania.
  7935.  
  7936. The Parts 1,2,3,4,9 include MULTIPLY and DIVIDE, always with the same
  7937. code. Parts 5,6,7,8 do not.
  7938.  
  7939.   Correspondence between ISO and ECMA standards
  7940.     ISO    ECMA    Registration number of escape sequence (ISO 2375)
  7941.    8859/1    94    100
  7942.    8859/2    94    101
  7943.    8859/3    94    109
  7944.    8859/4    94    110
  7945.    8859/5   113    111
  7946.    8859/6   114    127
  7947.    8859/7   118    126
  7948.    8859/8   121    138
  7949.    8859/9   128    148
  7950.  
  7951. FROM  J. W. van Wingen    MOSGLA@HLERUL2
  7952. Mail to
  7953. P. O. Box 486,  2300AL Leiden, Netherlands
  7954.  
  7955.  1-Feb-89 17:19:02-GMT,1904;000000000001
  7956. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29458; Wed, 1 Feb 89 12:18:28 EST
  7957. Received: from CUVMB.CC.COLUMBIA.EDU(MAILER) by CUVMB.CC.COLUMBIA.EDU(SMTP) ; Wed, 01 Feb 89 12:13:15 EDT
  7958. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7959.  id 6487; Wed, 01 Feb 89 09:33:07 EDT
  7960. Received: by BITNIC (Mailer X1.25) id 5236; Wed, 01 Feb 89 10:30:55 EST
  7961. Date:         Wed, 1 Feb 89 14:53:00 CET
  7962. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7963. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM.BITNET@cuvmb.cc.columbia.edu>
  7964. From: Johan van Wingen <MOSGLA%HLERUL2.BITNET@cuvmb.cc.columbia.edu>
  7965. Subject:      ISO 8859-5
  7966. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  7967.  
  7968.  
  7969. Dear list subscribers
  7970. I just received ECMA Memento 1989. It includes a list of ECMA Standards,
  7971. with the remark: "Free copies of all documents listed below are
  7972. available upon request."  They are mostly identical of those of ISO.
  7973. The address is ECMA Headquarters, Rue du Rhone 114, CC-1204 GENEVA,
  7974. Switzerland, (Telex 222.88, after 1989-06-14 41.32.37). The document
  7975. numbers are in my previous mailing.
  7976. As for Cyrillic (8859-5), the code is NEW (from the USSR). Col.s 11,12
  7977. now contain 32 capitals and 14,15 32 small letters in the CORRECT
  7978. alphabetic order. Col. 10 contains the capitals of Jugocyrillic etc.,
  7979. and col. 15 the small ones. In 10 there is NBSP, E-trema, Dj, G-acc,
  7980. Ukr. E, Maced. S, I, I-trema, J, Lj, Nj, H-barred, K-acc, SHY, U-short,
  7981. Dz. In 15 there is "No" at 15/00 and "SS" (paragraph sign) at 15/13.
  7982. Note that the Jugoslav Nat. Standard is different, conforming to
  7983. the alphabetic order of the Latin transliteration, (just like the old
  7984. GOST).  DIS 8859-5.2 contains several mistakes in the letter names.
  7985.  
  7986. FROM  J. W. van Wingen    MOSGLA@HLERUL2
  7987. Mail to
  7988. P. O. Box 486,  2300AL Leiden, Netherlands
  7989.  
  7990. 10-Feb-89 14:29:42-GMT,1391;000000000001
  7991. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA21089; Fri, 10 Feb 89 09:29:37 EST
  7992. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 4820; Fri, 10 Feb 89 09:27:09 EST
  7993. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  7994.  id 9342; Fri, 10 Feb 89 09:27:08 EST
  7995. Received: by BITNIC (Mailer X1.25) id 8149; Fri, 10 Feb 89 10:28:02 EST
  7996. Date:         Fri, 10 Feb 89 15:03:00 CET
  7997. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  7998. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  7999. From: Johan van Wingen <MOSGLA%HLERUL2@cuvmb.cc.columbia.edu>
  8000. Subject:      ISO10646
  8001. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8002.  
  8003.  
  8004. Dear list subscribers
  8005. First Draft Proposal DP 10646, Multiple octet coded character set (SC2 N
  8006. 1987) arrived last Monday. It is 140 pages. The voting period ends
  8007. 1989-05-30. It is under the care of ISO/IEC JTC1/SC2/WG2. It will have
  8008. considerable influence on coding in the next decade. To give you an
  8009. impression on what it is about, I'll mail a copy of an Informal
  8010. Introduction on it (3 pages).  Be warned, it contains box characters,
  8011. conform to GT12 (or even TN?). All the letters, however, are orthodox.
  8012.  
  8013. FROM  J. W. van Wingen    MOSGLA@HLERUL2
  8014. Mail to
  8015. P. O. Box 486,  2300AL Leiden, Netherlands
  8016.  
  8017. 10-Feb-89 15:02:53-GMT,11012;000000000001
  8018. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA23517; Fri, 10 Feb 89 10:02:45 EST
  8019. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 4834; Fri, 10 Feb 89 10:00:16 EST
  8020. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8021.  id 9387; Fri, 10 Feb 89 10:00:15 EST
  8022. Received: by BITNIC (Mailer X1.25) id 8442; Fri, 10 Feb 89 10:56:02 EST
  8023. Date:         Fri, 10 Feb 89 15:27:00 CET
  8024. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8025. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8026. From: Johan van Wingen <MOSGLA%HLERUL2@cuvmb.cc.columbia.edu>
  8027. Subject:      Informal Introduction to ISO 10646
  8028. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8029.  
  8030.  
  8031. 1
  8032.  
  8033.   INTERNATIONAL ORGANIZATION FOR STANDARDIZATION    ISO/IEC JTC1/SC2/WG2
  8034.   INTERNATIONAL ELECTROTECHNICAL COMMISSION                       N 274
  8035.  
  8036.   Joint Technical Committee 1
  8037.   Subcommittee 2 Characters and Information Coding, Working Group 2
  8038.  
  8039.  
  8040.  
  8041.  
  8042.  
  8043.   ======================================================================
  8044.   Introduction to ISO 10646 - Multiple-Octet Coded Character Set
  8045.   ======================================================================
  8046.  
  8047.   A new standard is being developed within Working Group 2 of ISO/IEC
  8048.   JTC1/SC2 for the multiple-octet coded character set. Formal drafts
  8049.   will be issued during 1989.
  8050.  
  8051.   Its purpose is to provide a single character code which will permit
  8052. +     _______
  8053.   the written form of all present-day languages throughout the world to
  8054.   be used within computers, to be processed and interchanged. All types
  8055.   of text written in character form will be provided for, from simple
  8056.   commercial documents to publication of technical reports etc. Also the
  8057.   bibliographic requirements of librarians will be met.
  8058.  
  8059.   The structure of the whole code may be illustrated thus, with an octet
  8060. +     _________                                                    _____
  8061.   of bits for each dimension:
  8062.  
  8063.  
  8064.  
  8065.                                            ZDDDDDDDDDDDDDDDDDDD?
  8066.                                       ZDDDDDDDDDDDDDDDDDDD?    3
  8067.                                  ZDDDDDDDDDDDDDDDDDDD?    3    3
  8068.                             ZDDDDDDDDDDDDDDDDDDD?    3    3    3
  8069.      Plane             ZDDDDDDDDDDDDDDDDDDD?    3    3    3    3
  8070.     /             ZDDDDDDDDDDDDDDDDDDD?    3    3    3    3    3
  8071.    /         ZDDDDDDDDDDDDDDDDDDD?    3    3    3    3    3    3
  8072.   ZDD>  ZDDDDDDDDDDDDDDDDDDD?    3    3    3    3    3    3    3
  8073.   3Cell 3                   3    3    3    3    3    3    3    3
  8074.   3     3  ZDDDDDD?  ZDDDDDD    3    3    3    3    3    3    3
  8075.   V     3  3  A00 3  3  A01 3    3    3    3    3    3    3    3
  8076.   Row   3  DDDDDD  DDDDDD    3    3    3    3    3    3    3
  8077.         3  3      3  3      3    3    3    3    3    3    3    3
  8078.         3  3  J1  3  3  DD  3    3    3    3    3    3    3    3
  8079.         3  3      3  3      3    3    3    3    3    3    3    3
  8080.         3  @DDDDDDY  @DDDDDD    3    3    3    3    3    3    3
  8081.         3                   3    3    3    3    3    3    3DDDDY
  8082.         3  ZDDDDDD?  ZDDDDDD    3    3    3    3    3DDDDY
  8083.         3  3  A10 3  3  A11 3    3    3    3    3DDDDY (future
  8084.         3  DDDDDD  DDDDDD    3    3    3DDDDY   standardization)
  8085.         3  3      3  3      3    3    3DDDDY (Korean)
  8086.         3  3  C1  3  3  K1  3    3DDDDY (Japanese)
  8087.         3  3      3  3      3DDDDY (Chinese)
  8088.         @DDJDDDDDDJDDJDDDDDDY (bibliographic)
  8089.  
  8090.     Basic multi-lingual plane                  Supplementary planes
  8091.  
  8092.  
  8093.  
  8094.  
  8095.   The basic multi-lingual plane will contain four segments for graphic
  8096. +     _________________________                   ________
  8097.   characters, each holding 96 * 96 characters.
  8098.  
  8099.   Each segment will be divided into two zones: an alphabetic zone of
  8100. +                                       _____
  8101.   16 * 96 characters, and another zone either for the most-frequently
  8102.   used characters of the Chinese, Japanese and Korean ideographic
  8103.   scripts, or for certain special purposes.
  8104.  
  8105.   The shaded area outside the graphic quadrants will be used for control
  8106. +                                                                _______
  8107.   functions. All those of ISO 6429, ISO 6937 and ISO 8613 will be
  8108. + _________
  8109.   available, with the same coding.
  8110.  
  8111.   The supplementary planes will accomodate characters that overflow from
  8112. + ________________________
  8113.   the basic multi-lingual plane.
  8114. 1
  8115.   A coded character anywhere in the code may be uniquely identified by
  8116.   means of three octets:
  8117.  
  8118.    m-s  ZDDDDDDDDDDDDDD>DDDDDDDDDDDDDD>DDDDDDDDDDDDDD?  l-s
  8119.         3 Plane-octet  3 Row-octet    3 Cell-octet   3
  8120.         @DDDDDDDDDDDDDDJDDDDDDDDDDDDDDJDDDDDDDDDDDDDDY
  8121.  
  8122.     NOTE: Sequences of characters run horizontally along the rows, not
  8123.           vertically as in previous code tables.
  8124.  
  8125.   The code may be used in different forms-of-use:
  8126. +                                   ____________
  8127.  
  8128.     a) A four-octet form, in which the three octets for the character
  8129.        are preceded by one for systems use. Three octet coding will
  8130.        never be used.
  8131.  
  8132.     b) A two-octet form, restricted exclusively to a single plane.
  8133.        Especially for users with alphabetic scripts, this will
  8134.        accomodate probably 99% of their applications.
  8135.  
  8136.     c) A two-octet form with extension using occasional four-octets.
  8137.  
  8138.     d) A compacted form, permitting strings of related characters to be
  8139.        used as single-octets.
  8140.  
  8141.   The basic multi-lingual plane is being designed to permit easy
  8142.   inter-working with existing 8-bit codes. Generally, conversion will be
  8143.   by the table look-up technique; however, conversion with ISO 8859
  8144.   parts 1,2,5,6,7,8 may use a simple algorithm.
  8145.  
  8146.   All designation, invocation and shifting as in ISO 2022 will be
  8147.   avoided.
  8148. + _______
  8149.  
  8150.   It is considered that the consequent simplification of software,
  8151. +                                      __________________________
  8152.   especially for generalized applications in the OSI environment, will
  8153.   make this code economically attractive despite the the relatively
  8154.   extravagant use of bits.
  8155.  
  8156.   The layout of the basic multi-lingual plane may be illustrated in
  8157. +     ______        _________________________
  8158.   FIGURE 1 (next page), the axes being not drawn linearly.
  8159.  
  8160.     NOTE: The value of any octet is shown in simple decimal notation,
  8161.           e.g.  032, 255.
  8162.  
  8163.   The contents of any of the rows are set out in detailed code tables.
  8164. +                                                ____________________
  8165.   These are drawn on a pro-forma which shows a complete row in twelve
  8166.   strips, each of 16 graphic characters.
  8167.  
  8168.   Because the code is designed to be used as a whole, especially the
  8169.   basic multi-lingual plane, no significance attaches to whether certain
  8170.   characters are in the left hand or right-hand halves of a row, or
  8171.   early or late in the code table.
  8172.  
  8173.   A character once included in the code table is not duplicated
  8174.   elsewhere. Therefore for any particular application characters will
  8175.   be taken from many different places in the code table. For example
  8176.   users within Greece will find Greek letters in row 040, the equivalent
  8177.   Latin letters they use for transliteration in row 032, and some
  8178.   symbols they use in row 034.
  8179.  
  8180.   It will be trivially easy to adapt any equipment designed for the
  8181.   Japanese or Chinese scripts to provide all the characters of the basic
  8182.   multi-lingual plane. Therefore it is expected that suitable
  8183.   cost-effective equipment will become readily available.
  8184. + ________________________
  8185.  
  8186.   The feature of fixed length coding, especially in the two-octet
  8187. +                ___________________
  8188.   mode-of-use, will make this code very easy to use in high-level
  8189.   programming languages and other software as employed for OSI and ODA.
  8190.  
  8191.  
  8192.   Hugh McG Ross, editor.                        Revised  Oct.  1988
  8193.  
  8194.  
  8195. 1
  8196.  
  8197.  
  8198.  
  8199.   FIGURE 1    ISO 10646  Structure of the basic multi-lingual plane
  8200.  
  8201.  
  8202.         /   /                      /  /                       /
  8203.   Row. /000/032   Cell-octet   126/  /160                 255/
  8204.   oct.ZDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD?
  8205.    0003                                                     3
  8206.       3  ZDDDDDDDDDDDDDDDDDDDDDDD?  ZDDDDDDDDDDDDDDDDDDDDDDD
  8207.    0323  3   Latin script for    3  3 European languages    3 \
  8208.    0333  3   ISO 8859-1 and -2   3  3 and ISO 6937-2        3  \
  8209.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD   \
  8210.    0343  3   Extended symbols    3  3 from ISO 8879         3    \
  8211.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD     \
  8212.    0353  3   Extended Latin      3  3 script for            3      \
  8213.       3  3     all world         3  3 languages             3       \
  8214.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD        \
  8215.    0373  3   Special African and 3  3 phonetic letters      3         \
  8216.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD Alphabetic
  8217.    0383  3   Cyrillic script for 3  3 major languages       3
  8218.       3  3     Cyrillic for all  3  3 minority languages    3   scripts
  8219.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD          /
  8220.    0403  3       Greek script    3  3 for all               3         /
  8221.       3  3          forms of     3  3  writing              3        /
  8222.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD       /
  8223.    0423  3   Arabic script for   3  3 all languages         3      /
  8224.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD     /
  8225.    0433  3            Hebrew     3  3 script                3    /
  8226.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD   /
  8227.    0443  3             Other     3  3 scripts               3  /
  8228.       3  3                       3  3                       3 /
  8229.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD
  8230.    0483  3     Japanese          3  3    Special Purpose    3 Ideographs
  8231.       3  3     JIS X 0208        3  3                       3
  8232.    1263  3                       3  3                       3
  8233.       3  @DDDDDDDDDDDDDDDDDDDDDDDY  @DDDDDDDDDDDDDDDDDDDDDDD
  8234.       3                                                     3
  8235.       3  ZDDDDDDDDDDDDDDDDDDDDDDD?  ZDDDDDDDDDDDDDDDDDDDDDDD \
  8236.    1603  3                       3  3                       3  \
  8237.       3  3             Indian    3  3 scripts               3   \
  8238.       3  3                       3  3                       3
  8239.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD Alphabetic
  8240.       3  3         Mathematical  3  3 symbols               3   /
  8241.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD  /
  8242.       3  3           Oriental    3  3 scripts               3 /
  8243.       3  DDDDDDDDDDDDDDDDDDDDDDD  DDDDDDDDDDDDDDDDDDDDDDD
  8244.    1763  3      Chinese          3  3    Korean             3 Ideographs
  8245.       3  3      GB 2312          3  3   KS C 5601           3
  8246.    2553  3                       3  3                       3
  8247.       @DDJDDDDDDDDDDDDDDDDDDDDDDDJDDJDDDDDDDDDDDDDDDDDDDDDDDY
  8248.  
  8249. 15-Feb-89 13:29:51-GMT,1151;000000000001
  8250. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA01608; Wed, 15 Feb 89 08:29:47 EST
  8251. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 6673; Wed, 15 Feb 89 08:29:42 EST
  8252. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8253.  id 6388; Wed, 15 Feb 89 08:29:41 EST
  8254. Received: by BITNIC (Mailer X1.25) id 0664; Wed, 15 Feb 89 08:30:46 EST
  8255. Date:         Wed, 15 Feb 89 08:25:54 EST
  8256. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8257. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8258. From: Edwin Hart <HART%APLVM@cuvmb.cc.columbia.edu>
  8259. Subject:      Re: Requirements Feedback/Agreements and Disagreements
  8260. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8261. In-Reply-To:  Translations, AECS Requirement 6
  8262.  
  8263. Inheirent in ISO 8859-1 and the Country Extended Code Pages (EBCDIC) is a
  8264. one-to-one mapping for the characters.  We require that the one-to-one
  8265. relation be extended to control characters.  This will allow "round-trip"
  8266. integrity for all data.  See AECS Requirement 6.
  8267.  
  8268. Ed Hart
  8269.  
  8270. 15-Feb-89 17:42:38-GMT,1684;000000000001
  8271. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA22518; Wed, 15 Feb 89 12:42:27 EST
  8272. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 6801; Wed, 15 Feb 89 12:42:34 EST
  8273. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8274.  id 6915; Wed, 15 Feb 89 12:42:33 EST
  8275. Received: by BITNIC (Mailer X1.25) id 8074; Wed, 15 Feb 89 12:06:41 EST
  8276. Date:         Wed, 15 Feb 89 10:37:02 EST
  8277. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8278. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8279. From: Edwin Hart <HART%APLVM@cuvmb.cc.columbia.edu>
  8280. Subject:      Re: Requirements Feedback/Agreements and Disagreements
  8281. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8282. In-Reply-To:  Your message of Wed, 15 Feb 89 08:52:52 EST
  8283.  
  8284. >I would agree with rick's statement above that such translation be one-to-one
  8285. >reversible.  I would add another primary requirement: the code for any
  8286. >printable ASCII character be translated to a EBCDIC code that represents
  8287. >the same printable character.   These two requirements will mean that some
  8288. >printable EBCDIC characters are lost, but that is life!
  8289.  
  8290. The IBM Country Extended Code Pages (CECPs) and ISO 8859-1 share the same
  8291. character set.  In other words, if a character is in a CECP, it is in 8859-1
  8292. and vice versa.  Thus, for graphic characters (those which display),
  8293. a one-to-one mapping exists.  The pieces are already in place for your
  8294. requirement IF you move to the 8-bit ASCII world of ISO 8859-1 (which uses
  8295. ANSI X3.4-1986 (U.S. ASCII) as the left half of the code table).
  8296.  
  8297. Ed Hart
  8298.  
  8299. 15-Feb-89 18:13:19-GMT,3094;000000000001
  8300. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA24860; Wed, 15 Feb 89 13:12:57 EST
  8301. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 6815; Wed, 15 Feb 89 13:13:04 EST
  8302. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8303.  id 6991; Wed, 15 Feb 89 13:13:03 EST
  8304. Received: by BITNIC (Mailer X1.25) id 8118; Wed, 15 Feb 89 12:07:02 EST
  8305. Date:         Wed, 15 Feb 89 16:22:00 CET
  8306. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8307. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8308. From: Johan van Wingen <MOSGLA%HLERUL2@cuvmb.cc.columbia.edu>
  8309. Subject:      SHARE Requirements 2
  8310. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8311.  
  8312.  
  8313. Dear list subscribers
  8314. Here is my next installment.
  8315. Some little writing errors first.
  8316. P. 1  prividing --> providing
  8317. P. 1  Polyas --> Pllya (P/olya)
  8318. P. 2  coexistance --> coexistence
  8319. P. 4  Stardards --> Standards
  8320. Now the requirements:
  8321. R8: This contradicts what is said in R1:
  8322. " ........  End users should be concerned with using  applications,  not  how
  8323. " the  character  data  is encoded.   IBM must hide the way character data is
  8324. " encoded.  How the character data is coded must be invisible  to  end  users
  8325. " and  applications developers.  However, ...................................
  8326. R22: Such a thing may be included. It shall, however, only express an
  8327. INTENTION, not act as a barrier to interpreting data differently. Of
  8328. course, this facility cannot be meant only for DURING THE MIGRATION.
  8329. The last paragraph is far too optimistic in regarding the issues it
  8330. reflects.
  8331. R23: This is too vague to me. It should say that there should be as few
  8332. borders as possible, acting as code barriers. IBM should state clearly
  8333. that national CECP are only a short-term approach, and that a unique
  8334. EBCDIC is what is aimed at, a compromise between CP037 and CP500.
  8335. If and when that is said, we can start discussing with IBM what should
  8336. be in it.
  8337. With ISO 8859 we have only the East-West and perhaps the North-South
  8338. code barrier, and if we succeed with the 254 char. set, we have even
  8339. the Iron Curtain eliminated. A good question: how sacrosanct are
  8340. cols 0-3 of EBCDIC? We may need them for the next conversion scheme.
  8341. R25: ISO 646 is quite dead now, and will only be kept for the CCITT
  8342. Telematic Services.
  8343. R27: At present a printer will prints blanks for unprintables, which
  8344. I prefer over the proposed options.
  8345. R28: IBM will say: You are knocking at the wrong door. Nothing prevents
  8346. you at going to ANSI or their counterparts with these ideas.
  8347.  
  8348. A thing I missed is a position towards multi-byte sets. Do not overlook
  8349. that IBM included support for it in TSO/ISPF and produced the 5550 for
  8350. the Japanese market. Are we willing to code our Latin letters with two
  8351. bytes instead of one, just for mixing more alphabets and scripts in
  8352. one document in the future? Xerox has it, but that will not become the
  8353. ISO Standard.
  8354.  
  8355. FROM  J. W. van Wingen    MOSGLA@HLERUL2
  8356. Mail to
  8357. P. O. Box 486,  2300AL Leiden, Netherlands
  8358.  
  8359. 16-Feb-89 11:55:05-GMT,3191;000000000001
  8360. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA05038; Thu, 16 Feb 89 06:54:58 EST
  8361. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 7166; Thu, 16 Feb 89 06:51:56 EST
  8362. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8363.  id 8203; Thu, 16 Feb 89 06:51:55 EST
  8364. Received: by BITNIC (Mailer X1.25) id 4088; Thu, 16 Feb 89 06:52:19 EST
  8365. Date:         Thu, 16 Feb 89 12:48:00 CET
  8366. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8367. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8368. From: Johan van Wingen <MOSGLA%HLERUL2@cuvmb.cc.columbia.edu>
  8369. Subject:      SHARE req. 3
  8370. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8371.  
  8372.  
  8373. Dear list subscribers
  8374. As a further installment I would like to discuss the use of the term
  8375. "character set". ASCII is often called thus, but in fact the code is
  8376. meant. There are two concepts, that of the set of characters, and that
  8377. of the way these are represented by bytes. The ISO term for the first
  8378. is "repertoire", (strictly speaking it is used only in ISO 6937, not in
  8379. ISO 8859). We may introduce that term into the EBCDIC world too. Thus
  8380. ISO 8859-1, CP037 and CP500 share the same repertoire, but have
  8381. different coding, as do the several CECP's for Western Europe. CP850
  8382. contains this repertoire as a subset, with again different coding.
  8383. The ASCII repertoire (7-bit) is a subset of all those in the 9 parts of
  8384. ISO 8859, always with the same coding. The repertoire of ISO 8859-2 is
  8385. identical to that of CP870 (as far known to me, can anybody tell me in
  8386. which IBM manual it is defined?), but not with the same coding. I hope
  8387. this will be helpful.
  8388.  
  8389. Just as a bonus I offer the following text in German (from Goethe's
  8390. Faust), which, I hope, I have correctly coded in CP037, (I am not going
  8391. to provide a translation). It may serve as a motto to our effort, for
  8392. it is an early description of a conversion algorithm, with appropriate
  8393. comments by the Devil.
  8394.  
  8395.   Die Hexe
  8396.   (mit groer Emphase f
  8397.   Du mut verstehn!
  8398.           Aus Eins mach Zehn,
  8399.           Und Zwei la gehn,
  8400.           Und Drei mach gleich,
  8401.           So bist du reich.
  8402.           Verlier die Vier!
  8403.           Aus Funf und Sechs,
  8404.           So sagt die Hex,
  8405.           Mach Sieben und Acht,
  8406.           So ist's vollbracht:
  8407.           Und Neun ist Eins,
  8408.           Und Zehn ist keins.
  8409.           Das ist das Hexen-Einmaleins!
  8410.   Faust.  Mich dunkt die Alte Spricht im Fieber.
  8411.   Mephistopheles.  Das ist noch lange nicht voruber,
  8412.   Ich kenn es wohl, so klingt das ganze Buch;
  8413.   Ich habe manche Zeit damit verloren,
  8414.   Denn ein vollkommner Widerspruch
  8415.   Bleibt gleich geheimnisvoll fur Kluge wie fur Toren.
  8416.   Mein Freund, die Kunst ist alt und neu.
  8417.   Es war die Art zu allen Zeiten,
  8418.   Durch Drei und Eins, und Eins und Drei
  8419.   Irrtum statt Wahrheit zu verbreiten.
  8420.   So schw
  8421.   Wer will sich mit den Narrn befassen?
  8422.   Gew>hnlich glaubt der Mensch, wenn er nur Worte h>rt,
  8423.   Es musse sich dabei doch auch was denken lassen.
  8424.  
  8425.   Goethe, Faust Teil I, 2540-2566
  8426.  
  8427. FROM  J. W. van Wingen    MOSGLA@HLERUL2
  8428. Mail to
  8429. P. O. Box 486,  2300AL Leiden, Netherlands
  8430.  
  8431. 16-Feb-89 17:40:39-GMT,8033;000000000001
  8432. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA27630; Thu, 16 Feb 89 12:40:31 EST
  8433. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 7322; Thu, 16 Feb 89 12:37:39 EST
  8434. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8435.  id 9192; Thu, 16 Feb 89 12:37:38 EST
  8436. Received: by BITNIC (Mailer X1.25) id 4482; Thu, 16 Feb 89 12:09:57 EST
  8437. Date:         Thu, 16 Feb 89 08:38:37 EST
  8438. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8439. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8440. From: Edwin Hart <HART%APLVM@cuvmb.cc.columbia.edu>
  8441. Subject:      Re: SHARE req. 3
  8442. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8443. In-Reply-To:  Code Page 500 versus 37:  Compromise Needed?
  8444.  
  8445. (This note started to a reply to Johan van Wingen's note with the Faust quote
  8446. in German.  But once I started writing it, I was writing about an area which
  8447. concerns me.  I believe that IBM will resolve the code page 37 versus 500
  8448. issue by supporting both of them for the long-term.  To me, the political
  8449. situation dictates that kind of solution from IBM.  I would be interested in
  8450. your thoughts.)
  8451.  
  8452. Although I cannot read German, I know the Faust text came through correctly.
  8453. The reason is that the code points (ISO code positions (hex values)) for
  8454. code page 37 and code page 500 for the alphabet, numbers, and most other
  8455. characters are exactly the same.  They only differ for 7 characters and
  8456. code points:
  8457.  
  8458.   Code Point        37 V1                        500 V1
  8459.  
  8460.      4A         US cent                   Left Square Bracket 
  8461.      4F         Vertical Bar |             Exclamation Point |
  8462.      5A         Exclamation Point !        Right Square Bracket !
  8463.      5F         Logical Not ^              Circumflex ^
  8464.      B0         Circumflex 5               US cent 5
  8465.      BA         Left Square Bracket       Logical Not 
  8466.      BB         Right Square Bracket Y     Vertical Bar |
  8467.  
  8468. (The 37 V1 column uses CP 37 characters and
  8469. the 500 V1 column uses CP 500 characters (I hope!). Ed Hart)
  8470.  
  8471. I am concerned IBM will not standardize on one EBCDIC code page.
  8472. With Europe, CP 500 seems to be firmly entrenched.  In the US, Canada,
  8473. and Portugal, CP 37 is entrenced.  With this situation, I believe IBM will
  8474. respond by narrowing from 9 CECPs to two CECPs:  CP 37 v1 and CP 500 v1.
  8475. They will do this to maintain data compatibility with data customers are
  8476. already using to to avoid offending customers who have recently converted
  8477. data to CP 37 or CP 500.  Then IBM will build systems to
  8478. automatically do the translations between CP 37 and 500 for mail, etc.
  8479.  
  8480. An alternative to standardizing on both CP 37 and CP 500 is for ALL OF US to
  8481. find a compromise code page somewhere between CP 37 and CP 500.  The compromise
  8482. must be something we can accept--because it cannot be perfect.  Before
  8483. suggesting anything, I want to raise the following issues:
  8484.  
  8485. 1.  Mainframe and Midrange Programming Languages depend on the US code page(s).
  8486.     Since the US Standard EBCDIC does not define code points for brackets,
  8487.     many products use the TN/T11 print train standard code points for brackets:
  8488.     X'AD' and X'BD'.
  8489. 2.  EBCDIC Code Point X'5F' should be reserved for the NOT function
  8490.     because it is ingrained in the IBM products.  However,
  8491.     the ISO 8859 family of codes does not have the NOT character (cp 37 ^/
  8492.     cp 500 ) in any code but ISO 8859-1.  Consequently, the NOT character
  8493.     should not be
  8494.     allowed in programming language syntax.  However, in EBCDIC, the compilers
  8495.     use code point X'5F' for NOT.  For ASCII terminals, it is fairly common to
  8496.     map the ASCII circumflex (cp 37 5/cp 500 ^) into the EBCDIC NOT (cp 37 ^/
  8497.     cp 500 5).  (This may be the result of the ASCII-1968 standard which
  8498.     allowed the ASCII X'5E' code point to have "stylized graphics".
  8499.     If use of the NOT character (cp 37 ^/cp 500 5) is an issue to IBM, they
  8500.     should change the compilers to accept the code points for either the NOT
  8501.     or circumflex characters.
  8502. 3.  EBCDIC Code Point X'4F' should be reserved for the vertical bar character
  8503.     (cp 37 |/cp 500 Y) because it is ingrained in the IBM products.  This is
  8504.     another code point and character
  8505.     used in programming languages for the OR function.
  8506. 4.  Brackets in CP 37 or CP 500 do not match the code points generally
  8507.     used, X'AD' and X'BD'.  The Code Page 37 assignments for brackets are not
  8508.     widely used.  Code points for brackets affect the PASCAL and C
  8509.     programming languages.
  8510.     Therefore, regardless of the code selected (CP 37 or 500),
  8511.     both PASCAL and C compilers must be changed for new code points
  8512.     for brackets.
  8513. 5.  The C language uses the exclamation point character (cp 37 !/cp 500 |).
  8514.     However, because of issue number 4, the C compiler must be changed for
  8515.     brackets.  If C must be changed for brackets, changing C for a new
  8516.     code point for the exclamation point is not unreasonable.
  8517. 6.  To my knowledge, mainframes do not place any syntactic significance to the
  8518.     US EBCDIC code points X'4A' (cp 37 /cp 500 5) or X'B0' (cp 37 5/cp 500 ^).
  8519.     Therefore, character assignments to these code points is not as critical
  8520.     as the others mentioned earlier.
  8521.  
  8522. Based on these issues, I would recommend a compromise code point assignment.
  8523. This recommendation uses code point assignments for characters from both CP 37
  8524. and CP 500.
  8525.  
  8526.  
  8527. The first two code points are the most critical assignments.
  8528.   X'5F' to circumflex (issue 2)  (cp 500)
  8529.   X'4F' to vertical bar (issue 3) (cp 37)
  8530.  
  8531. These assignment for brackets is a recommendation.
  8532.   X'4A' and '5A' to left and right brackets (issue 4) (cp 500)
  8533.     The reasons for this choice are:
  8534.     1. The code points X'AD' and X'BD' are unavailable in CP 37 and CP 500,
  8535.        and I believe we should focus on fixing the differences between the
  8536.        two code pages rather than creating more differences.
  8537.     2. The Code Page 37 code points for brackets are not widely used.
  8538.     3. The X'4A' and X'5A' code points are in wide use in Europe
  8539.        in Country-specific EBCDIC code pages.
  8540.     4. The code points are next to each other in the code table.
  8541.  
  8542. Code points for the remaining characters may be defined by IBM.  I believe
  8543. that the assignments are not critical and therefore, we would waste time
  8544. discussing assignments.  If I am wrong, tell me.
  8545.  
  8546.     US cent (cp 37 /cp 500 5)
  8547.     Exclamation point (cp 37 !/cp 500 |)
  8548.     NOT (cp 37 ^/cp 500 5)
  8549.  
  8550.  
  8551. What are your thoughs?
  8552.  
  8553.   1.  Should we continue to request one EBCDIC code page selected from
  8554.       cp 37 or cp 500?
  8555.   2.  Should we request cp 37 v2 with brackets at code points X'AD' and
  8556.       X'BD'?
  8557.   3.  Should we pursue a technical compromise similar to this one to solve
  8558.       what I perceive as very serious political problems?  This assumes that
  8559.       one EBCDIC code page for ISO Latin alphabet number 1 is so critical
  8560.       that installations will be willing to convert to it, and those
  8561.       installations who have already converted to CP 37 or CP 500 would be
  8562.       willing to change again (They might be more willing if the character
  8563.       and code point changes had minimum effect on them; that is, they
  8564.       do not use the characters affected.).
  8565.   4.  Should we be prepared to accept the idea that the political situation
  8566.       will dictate a technical solution of two code pages:  37 and 500?
  8567.  
  8568. Before you answer, please consider what kind of changes your installation will
  8569. REALLY be willing to make to obtain one EBCDIC code for ISO Latin alphabet
  8570. number one.  Are US and Canadian installations really willing to convert
  8571. their data, documents, and source programs to one EBCDIC code page if IBM
  8572. selects code page 500 as the long-term solution?  Are installations in Europe
  8573. who have recently converted to code page 500, willing to make another
  8574. conversion to code page 37 or to some compromise code page between code page
  8575. 37 and 500?
  8576.  
  8577.  
  8578. Thank you for all of your comments to date.
  8579. Sincerely,
  8580.  
  8581. Ed Hart
  8582.  
  8583. 16-Feb-89 22:59:43-GMT,2459;000000000001
  8584. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA23485; Thu, 16 Feb 89 17:59:38 EST
  8585. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 7471; Thu, 16 Feb 89 17:56:51 EST
  8586. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8587.  id 9809; Thu, 16 Feb 89 17:56:50 EST
  8588. Received: by BITNIC (Mailer X1.25) id 5958; Thu, 16 Feb 89 17:57:49 EST
  8589. Date:         Thu, 16 Feb 89 14:25:40 EST
  8590. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8591. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8592. From: John C Klensin <KLENSIN%INFOODS.MIT.EDU@cuvmb.cc.columbia.edu>
  8593. Subject:      RE:       Re: Requirements Feedback/Agreements and Disagreements
  8594. X-To:         ASCII/EBCDIC character set related issues
  8595.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  8596. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8597.  
  8598.     Actually, the vertical bar / exclamation-point swapping is a result
  8599. of the "national character use" positions of ISO 646 and early efforts
  8600. to confine certain things, like Standards for programming languages that
  8601. were initially defined in terms of EBCDIC, to the basic version
  8602. positions.  The controversy also included some strange discussions about
  8603. whether ! (exclamation-point) "looked more" like EBCDIC "solid vertical
  8604. bar" than "|" (ASCII broken vertical bar) did.
  8605.    It has been well over a decade since the predecessor of todays's ISO
  8606. character set committees started sending little notes to programming
  8607. language standards committees encouraging them (us) to clean up their
  8608. acts and use *only* the basic character set of ISO646.  Since the basic
  8609. character set does not contain | (broken vertical bar at 7/12) and does
  8610. not contain ^ (carat or circumflex at 5/14) or ~ (tilde at 7/14) either,
  8611. the "obvious" solution was to map EBCDIC vertical bar into ISO646 2/1
  8612. (exclamation mark) and to do something creative with EBCDIC not-sign,
  8613. like writing <> rather than ^= or ~=.
  8614.    And, of course, since the character set folks were willing to tell
  8615. the language folks what *not* to do, but not what to do instead, there
  8616. was no "standard" about the 'solutions'.
  8617.    Sometimes good intentions go a little astray.
  8618.  
  8619.    John Klensin, MIT       Klensin@INFOODS.MIT.EDU
  8620.    To identify the perspective from which the above is written:
  8621.    Chair, ANSI X3J1 (PL/I); Project Editor for PL/I, ISO/IEC JTC1/SC22
  8622.  
  8623.  
  8624. 17-Feb-89 16:57:51-GMT,7823;000000000001
  8625. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA12654; Fri, 17 Feb 89 11:57:32 EST
  8626. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 7759; Fri, 17 Feb 89 11:54:44 EST
  8627. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8628.  id 1152; Fri, 17 Feb 89 11:54:43 EST
  8629. Received: by BITNIC (Mailer X1.25) id 7044; Fri, 17 Feb 89 11:50:32 EST
  8630. Date:         Fri, 17 Feb 89 09:25:15 EST
  8631. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8632. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8633. From: John C Klensin <KLENSIN%INFOODS.MIT.EDU@cuvmb.cc.columbia.edu>
  8634. Subject:      RE:       Re: SHARE req. 3
  8635. X-To:         ASCII/EBCDIC character set related issues
  8636.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  8637. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8638.  
  8639. I find myself strongly in agreement with Ed's main point here, that,
  8640. absent both a strong recommendation from the user community AND a
  8641. clear willingness to bear pain, IBM will "compromise" on two code pages.
  8642. That would be an improvement, but...
  8643.  
  8644. A few small observations and quibbles:
  8645.  
  8646. >2.  EBCDIC Code Point X'5F' should be reserved for the NOT function
  8647. >    because it is ingrained in the IBM products.  However,
  8648. >    the ISO 8859 family of codes does not have the NOT character (cp 37 ^/
  8649. >    cp 500 ) in any code but ISO 8859-1.  Consequently, the NOT character
  8650. >    should not be
  8651. >    allowed in programming language syntax.  However, in EBCDIC, the compilers
  8652. >    use code point X'5F' for NOT.  For ASCII terminals, it is fairly common to
  8653. >    map the ASCII circumflex (cp 37 5/cp 500 ^) into the EBCDIC NOT (cp 37 ^/
  8654. >    cp 500 5).  (This may be the result of the ASCII-1968 standard which
  8655. >    allowed the ASCII X'5E' code point to have "stylized graphics".
  8656. >    If use of the NOT character (cp 37 ^/cp 500 5) is an issue to IBM, they
  8657. >    should change the compilers to accept the code points for either the NOT
  8658. >    or circumflex characters.
  8659.    Several implementations of ISO-standard compilers permit either ASCII
  8660. caret/circumflex or ASCII tilde as the appropriate stylization of what
  8661. started our as an EBCDIC 'not'.  With the introduction of 'not' in
  8662. ISO8859-1, I expect that some vendors will decide to accept that too.
  8663. Or, worse, instead.  As I indicated in my note yesterday, parts of this
  8664. conversion mess started out in the other direction.  Unlike the custom
  8665. in some of the communications and OSI Standards (the CCITT PAD standards
  8666. are excellent examples), the ISO programming language Standards do not,
  8667. in general, specify the codings of the character sets to be used, even
  8668. in ASCII; their language is a more or less specific version of "use
  8669. characters that look like this".  That has resulted in some tough
  8670. intra-ASCII conversion problems which some vendors, responding to
  8671. perceived user needs, have resolved by mapping more than one ASCII
  8672. character onto a given language character.  All of this confuses the
  8673. 'unambigious translation between ASCII and EBCDIC' problem considerably,
  8674. since we can't unambiguously translate between ASCII and ASCII when the
  8675. semantics assigned by a programming langauge to a character are
  8676. considered.
  8677.   The three important examples that I know of are:
  8678.    EBCDIC NOT maps to ASCII caret/circumflex and/or ASCII tilde
  8679.    EBCDIC vertical bar maps to ASCII exclamation-mark and/or ASCII
  8680. broken vertical bar (yesterday's discussion)
  8681.    EBCDIC (single-)quote maps to ASCII quote (i.e., double quote) and/or
  8682. ASCII (acute) accent.
  8683.   Since, for all of the vendors who chose one of each of these
  8684. code/graphics pairs and some of those who chose them as alternatives,
  8685. the "other" character is permitted in strings, translation between one
  8686. set of conventions or the other--and hence back to EBCDIC code pages--
  8687. that are semantics-preserving have to be done by a parsing process,
  8688. sometimes with a few heuristics, rather than by character by character
  8689. translation in a data stream.  It makes it hard to make firm statements
  8690. about what programming languages "do" or "should do".
  8691.  
  8692. >6.  To my knowledge, mainframes do not place any syntactic significance to the
  8693. >    US EBCDIC code points X'4A' (cp 37 /cp 500 5) or X'B0'
  8694. >    (cp 37 5/cp 500 ^).
  8695.   Probably nothing Standardized.  X'4A' is the character that is often
  8696. used as a stylization of ASCII back-slant/reverse-solidus in some
  8697. software, especially terminal emulators and is used as a separator in
  8698. some widely-circulated applications packages (precisely because it is
  8699. not used by anything else).  I know of nothing that uses X'B0', or
  8700. anything else in column B in a critical way as a character with semantic
  8701. significance, but that may be just my lack of knowledge.
  8702.  
  8703. >Based on these issues, I would recommend a compromise code point assignment.
  8704. >This recommendation uses code point assignments for characters from both CP 37
  8705. >and CP 500.
  8706. >
  8707. >The first two code points are the most critical assignments.
  8708. >  X'5F' to circumflex (issue 2)  (cp 500)
  8709. >  X'4F' to vertical bar (issue 3) (cp 37)
  8710. >
  8711. >These assignment for brackets is a recommendation.
  8712. >  X'4A' and '5A' to left and right brackets (issue 4) (cp 500)
  8713. This seems technically reasonable and politically attractive.
  8714.  
  8715. >Code points for the remaining characters may be defined by IBM.  I believe
  8716. >that the assignments are not critical and therefore, we would waste time
  8717. >discussing assignments.  If I am wrong, tell me.
  8718. I agree, but the recommendation must stress, perhaps even more strongly
  8719. than the present text, that "defined by IBM" means "defined once, in one
  8720. place", not "IBM may define a series of alternatives".
  8721. >    Exclamation point (cp 37 !/cp 500 |)
  8722. >    NOT (cp 37 ^/cp 500 5)
  8723. Also see comments on these characters above.
  8724.  
  8725. >From what I've seen of IBM's decision-making in other areas, they tend
  8726. to prefer leaving those who are already unhappy in that state, rather
  8727. than making, or even risking making, those who are happy less happy.
  8728. Consequently, pushing even toward two (only) code pages is going to be a
  8729. tough one.  The case will, I think, be considerably strengthened if the
  8730. people who want something are in a position to say "this change is going
  8731. to hurt us a lot too, but it is important if there is going to be a
  8732. future in which things are not worse".  Part of the argument that should
  8733. be made, and which I don't think Ed's draft makes clearly enough, is
  8734. that, if we can get
  8735.  (a) Unambiguous and reversible mappings between ISO8859-n and EBCDIC
  8736. CPm, with IBM agreement to specify the "official" 'n,m' pairs in a public
  8737. way and to increase 'm' as needed as 'n' increases.  There really is no
  8738. alternative to this, unfortunately: if 'n' has to rise above 1 because
  8739. of character set content (not just code point mapping), then the number
  8740. of code pages will have to rise above 1.
  8741.  (b) A single, standard, compromise, EBCDIC code page to be use in IBM
  8742. operating systems and products, especially programming languages and
  8743. data communications, such that alternate code pages are used the way
  8744. alternate ISO8859-n forms are used: locally or by control-sequence
  8745. introduced departures from the 'standard'.  And, as with ISO8859, the
  8746. "alternate" code pages are built up from a common core that permits
  8747. those operating systems and products to be completely standard across
  8748. code pages.  Otherwise, you just get the present chaos at a new point.
  8749.  ...then we will be satisified, if not happy.  And, more important, IBM
  8750. will be spared a strong case for replacing EBCDIC internally with
  8751. ISO8859 at some point in the future, since no one (well, nearly no one)
  8752. should care what they do internally as long as they communicate clearly
  8753. at the boundaries.
  8754.   More than that is probably unrealistic to hope for.  On the other
  8755. hand, that is quite a lot.
  8756.  
  8757. John Klensin
  8758.  
  8759.  
  8760.  
  8761. 18-Feb-89  2:42:59-GMT,2397;000000000001
  8762. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA05609; Fri, 17 Feb 89 21:42:56 EST
  8763. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 8032; Fri, 17 Feb 89 21:40:37 EST
  8764. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8765.  id 2119; Fri, 17 Feb 89 21:40:36 EST
  8766. Received: by BITNIC (Mailer X1.25) id 0444; Fri, 17 Feb 89 21:34:38 EST
  8767. Date:         Fri, 17 Feb 89 14:42:37 EST
  8768. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8769. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8770. From: John C Klensin <KLENSIN%INFOODS.MIT.EDU@cuvmb.cc.columbia.edu>
  8771. Subject:      RE:       Re: SHARE req. 3
  8772. X-To:         ASCII/EBCDIC character set related issues
  8773.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  8774. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8775.  
  8776. >        Personally,  (you're all going to laugh)...
  8777. > ... in such a way that EBCDIC and ASCII be transparent to the user.
  8778. I promise not to laugh if you promise to not make me hold my breath.
  8779. I'd expect to see a distinct temperature drop in the usual hot place
  8780. sometime first.  Not that it might not be a good idea, but all of us put
  8781. together are not worth one large bank or insurance company in terms of
  8782. getting IBM to change its ways, policies, or software.
  8783.  
  8784. >  The day will come when type "char" in C will be
  8785. >16 bits rather than the current 8.
  8786. That will be the day that most of the C programs in the world stop
  8787. working.  Keep in mind that this change will seriously alter the
  8788. semantics of every C program that believes that 'char' == 'int' == one
  8789. eight bit byte.  Lots of stuff, including parts of the language
  8790. definition, seem to depend on that assumption.  What you might see
  8791. instead is the introduction of 'longchar', with the use of 'char'
  8792. gradually disappearing, but that is not transparent and not something
  8793. that is likely to happen soon either.
  8794.  
  8795. >  EBCDIC would play
  8796. >only a minor roll and then go the way of card punches.
  8797.   Clearly the "right" solution.  Now let me introduce you to the guy in
  8798. the next office who has been trying to get me to attach a card
  8799. reader/punch to my VAX for the last four years so he can process his
  8800. data archive (which closely resembles a row of 24 drawer grey cabinets
  8801. in the hall).
  8802.  
  8803.    John Klensin, MIT  (Klensin@INFOODS.MIT.EDU)
  8804.  
  8805.  
  8806. 22-Feb-89 11:20:40-GMT,9164;000000000001
  8807. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA28035; Wed, 22 Feb 89 06:20:35 EST
  8808. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 9571; Wed, 22 Feb 89 06:27:49 EST
  8809. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8810.  id 7285; Wed, 22 Feb 89 06:27:47 EST
  8811. Received: by BITNIC (Mailer X1.25) id 5851; Wed, 22 Feb 89 06:28:06 EST
  8812. Date:         Wed, 22 Feb 89 12:19:00 CET
  8813. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8814. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8815. From: Johan van Wingen <MOSGLA%HLERUL2@cuvmb.cc.columbia.edu>
  8816. Subject:      ISO 8859 trouble spots
  8817. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8818.  
  8819.  
  8820. Dear list subscribers
  8821. The following document I intend to submit to ISO/JTC1/SC2/WG3 for their
  8822. next meeting. But before doing that I would like to have your comments
  8823. on it.
  8824. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
  8825. 1
  8826.   THE REMAINING TROUBLE SPOTS IN ISO 8859
  8827.  
  8828.   0.  Introduction
  8829.  
  8830.   The several parts of ISO 8859 have been approved a few years ago and
  8831.   are now being implememented increasingly. A lot of experience has been
  8832.   collected. In general the reaction has been that the standard is
  8833.   excellent, but some weaker points of the standard are now becoming
  8834.   visible. These should be discussed before habits grow entrenched.
  8835.   Applications in the field of programming languages have been the
  8836.   source of most of the comments.
  8837.  
  8838.   1.  The problem of diacritics
  8839.  
  8840.   There is a long tradition in the writing and printing industry for
  8841.   extending the available 26 letter Latin alphabet. Extra letters are
  8842.   created by putting a little mark over or under a letter. These are
  8843.   called "diacritical marks": accents, umlauts, cedilla's and so on.
  8844.   They are also used in some languages for putting a stress on a
  8845.   syllable. (Barring a letter is not considered applying a diacritic.)
  8846.   Where the number of available characters was severely restricted, as
  8847.   with typewriters, separate diacritics provided a solution with the
  8848.   practice of overprinting. This approach was copied in ISO 646 using
  8849.   BACKSPACE, and with ISO 6937-2 using non-spacing diacritics. ISO 646
  8850.   provided only a few: underline, acute, grave and circumflex accent,
  8851.   diaeresis (umlaut), overline/tilde. These can also be used
  8852.   free-standing, that is without BACKSPACE, in which form they soon
  8853.   acquired a new meaning: low line, apostrophe, prime, upward arrow
  8854.   head, quotation mark. The comma could also be used for cedilla. This
  8855.   double use (already considerably reduced in ISO 646-1983) was not
  8856.   allowed in ISO 6937-2, where diacritics (a larger set) must occur only
  8857.   in predefined combinations with certain letters, or, exceptionally,
  8858.   with a SPACE. They are always non-spacing. In order to preserve the
  8859.   existing characters from ISO 646, ISO 6937-2 contains both a spacing
  8860.   and a non-spacing circumflex, grave accent and tilde. This introduces
  8861.   a double way of representing three characters. Astonishingly, the
  8862.   standard prefers for these three the single byte representation, the
  8863.   other "is deprecated".
  8864.  
  8865.   In ISO 8859 diacritics occur again. But all characters in it are
  8866.   always spacing without exception. However, diacritics have no meaning
  8867.   in itself. What is the use of a free-standing cedilla? One can only
  8868.   conclude that their presence is useless and a waste of valuable
  8869.   positions. Keeping them there can lead to two undesirable
  8870.   developments.  First, implementers may violate the rules of ISO 8859
  8871.   by making the diacritics non-spacing, or second, they may attach to
  8872.   them, when free-standing, a new meaning, as has been done with the
  8873.   circumflex, often used as "control". These characters deserve to be
  8874.   removed at the first opportunity. It will make it possible to include
  8875.   Turkish in ISO 8859-1.
  8876.  
  8877.   2.  The Logical OR and the Logical NOT
  8878.  
  8879.   A need for characters having the meaning of the Logical OR and the
  8880.   Logical NOT was introduced by PL/I (1964). The first compilers used
  8881.   EBCDIC. Thus the problem for ASCII and ISO 646 became apparent only
  8882.   somewhat later. As there were no positions left, some way of escape
  8883.   had to be found.
  8884.  
  8885. 1 ASCII (USAS X3.4-1968) contains in 6.4:
  8886.   "No specific meaning is prescribed for any graphics in the code table
  8887.   except that which is understood by the users. Furthermore, this
  8888.   standard does not specify a type style for the printing or display of
  8889.   the various graphic characters. In specific applications, it may be
  8890.   desirable to employ distinctive styling of individual graphics to
  8891.   facilitate their use for specific purposes as, for example, to stylize
  8892.   the graphics in code positions 2/1 and 5/14 into those frequently
  8893.   associated with Logical OR and Logical NOT, respectively."
  8894.   (These graphics normally represent Exclamation Point and Circumflex.)
  8895.  
  8896.   In ISO R 646-1967 the text is somewhat different:
  8897.   "4.3 Interpretation of graphics
  8898.   The meaning of the graphics is not defined by this ISO Recommendation.
  8899.   It will be necessary to reach agreement on the meaning and this will
  8900.   depend upon the particular application except in cases where other ISO
  8901.   Recommendations already exist. However no interpretation may be chosen
  8902.   which is contradictory to the customary meaning. A graphic symbol can
  8903.   have more than one meaning, e.g. the graphical symbol - (minus) also
  8904.   can have the meaning of hyphen or separation mark. The font design of
  8905.   the symbol is not part of this ISO Recommendation."
  8906.  
  8907.   Mackenzie (2) comments on this:
  8908.   "The last sentence of Section 4.3 leaves the question of "font design"
  8909.   open; that is, a manufacturer could design Exclamation Point to look
  8910.   like Vertical Bar and Circumflex like NOT sign. The LOGICAL OR/Logical
  8911.   NOT problem had finally been solved."
  8912.   Unfortunately this was an illusion, as we shall see.
  8913.  
  8914.   In ISO 646-1973 we still find in 5.3:
  8915.   "The names chosen to denote graphic characters are intended to reflect
  8916.   their customary meanings. However, this International Standard does
  8917.   not define and does not restrict the meanings of graphic characters.
  8918.   In addition, it does not specify a particular style or font design for
  8919.   the graphic characters."
  8920.  
  8921.   In ISO 646-1983 we find at the end of 4. :
  8922.   "The names chosen to denote graphic characters are intended to reflect
  8923.   their customary meaning. However, this International Standard does
  8924.   not define and does not restrict the meanings of graphic characters.
  8925.   Neither does it specify a particular style or font design for
  8926.   the graphic characters when imaged."
  8927.  
  8928.   Graphic characters are distinguished by their name, not by their
  8929.   shape. In ISO 646 the Vertical Line turns up, that can be used for
  8930.   Logical OR, but that name is not included. Equally, Upward Arrow Head,
  8931.   Circumflex (for 5/14) is never additionally named Logical NOT. Thus a
  8932.   sound basis for using both in this way is missing. Nevertheless,
  8933.   widespread use of Vertical Line and Circumflex for OR and NOT could be
  8934.   found, just as * and / are employed for "multiply" and "divide". This
  8935.   development cannot easily be redressed. Thus it was a most unfortunate
  8936.   idea to include a new code for NOT in ISO 8859-1. Confusion was
  8937.   aggravated by not including it in ISO 8859-2. It continues to cause
  8938.   problems at attempting to establish a uniform translate table for
  8939.   EBCDIC - ISO8859.
  8940.  
  8941. 1 3.   Obsolete signs
  8942.  
  8943.   A compiler writer needs to know how a certain character in a program
  8944.   has to be classified, as a digit, as a letter (mostly it does not
  8945.   matter which) or a special character with a given meaning. Checking
  8946.   whether a byte is meant to be a letter would be easier if the letter
  8947.   areas of ISO 8859 would have been contiguous. Instead of that, quite
  8948.   obsolete characters for multiply and divide, for which * and / are
  8949.   used in programs for more then 25 years, have been inserted in the
  8950.   middle of a column. A look-up table is required to decide whether a
  8951.   character is considered a letter or not. Even if this cannot be
  8952.   avoided anyway, the introduction of unnecessary exceptions is always
  8953.   a bad thing, as is the destruction of a stable convention. It is no
  8954.   good if language designers are now going to be pressed for including
  8955.   two graphic symbols, meaning the same thing, into the syntax.
  8956.   Removing "multiply" and "divide" would make place for putting in the
  8957.   French ligature "OE" and "oe" again, which the logic of 6937 wanted
  8958.   to keep and that of 8859 wanted to go.
  8959.  
  8960.   4.  Icelandic versus Turkish
  8961.  
  8962.   Mixing characters from several parts from ISO 8859 requires invoking
  8963.   the help of ISO 2022, which much hardware does not support. This
  8964.   imposes a considerable cultural barrier between certain groups of
  8965.   nations. If this barrier coincides with one raised by world politics
  8966.   things are as they are. But if there is none, other priorities should
  8967.   dominate. We have now Latin alphabet no. 5 (ISO 8859-9), and it should
  8968.   be discussed whether or not one including Turkish should prevail over
  8969.   one with Icelandic. There are more as 100 times as many Turks as there
  8970.   are Icelanders.
  8971.  
  8972. 23-Feb-89  0:47:38-GMT,1729;000000000001
  8973. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29033; Wed, 22 Feb 89 19:47:35 EST
  8974. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0013; Wed, 22 Feb 89 19:45:28 EST
  8975. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  8976.  id 8428; Wed, 22 Feb 89 19:45:27 EST
  8977. Received: by BITNIC (Mailer X1.25) id 3817; Wed, 22 Feb 89 19:25:18 EST
  8978. Date:         Wed, 22 Feb 89 14:52:39 EST
  8979. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8980. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  8981. From: Edwin Hart <HART%APLVM@cuvmb.cc.columbia.edu>
  8982. Subject:      Re: ISO 8859 trouble spots
  8983. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  8984. In-Reply-To:  Criticism of ISO 8859
  8985.  
  8986. I read through your note on ISO 8859 problems.  I agree.  I would add that
  8987. the PL/1 not symbol is only in ISO 8859-1 (and maybe -9, I have not seen -9).
  8988.  
  8989. Also, many sites in North America map the ASCII tilde (7/14) into the EBCDIC
  8990. Not.  Formal logic courses frequently use tilde as the Not operator.  The
  8991. courses also use V for inclusive Or, and a circumflex-like character for
  8992. logical And.  At some of my SHARE presentations, several people said "Do not
  8993. use the circumflex character to mean logical Not."
  8994.  
  8995. In my note about a compromise EBCDIC code page for Reference EBCDIC-1,
  8996. I proposed keeping the Not FUNCTION at EBCDIC code point X'5F'
  8997. but using the circumflex CHARACTER there because circumflex was a character
  8998. common to all of the ISO 8859 standards, and one would presume that people
  8999. using other ISO 8859 parts would want to use PL/1 or other languages which
  9000. use a Not symbol.
  9001.  
  9002. Ed Hart
  9003.  
  9004. 23-Feb-89  0:54:58-GMT,2902;000000000001
  9005. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA29402; Wed, 22 Feb 89 19:54:55 EST
  9006. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0017; Wed, 22 Feb 89 19:52:48 EST
  9007. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  9008.  id 8444; Wed, 22 Feb 89 19:52:47 EST
  9009. Received: by BITNIC (Mailer X1.25) id 3909; Wed, 22 Feb 89 19:30:21 EST
  9010. Date:         Wed, 22 Feb 89 16:19:27 EST
  9011. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9012. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9013. From: "Nelson H.F. Beebe" <Beebe%SCIENCE.UTAH.EDU@cuvmb.cc.columbia.edu>
  9014. Subject:      Comment on ISO 8859 multiply and divide
  9015. X-To:         ISO8859%JHUVM.BITNET@CUNYVM.CUNY.EDU
  9016. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  9017. In-Reply-To:  Message from "Johan van Wingen <MOSGLA@HLERUL2.BITNET>" of Wed 22
  9018.               Feb 89 04:32:00-MST
  9019.  
  9020. Johan van Wingen <MOSGLA@HLERUL2.BITNET> in a posting dated Wed,
  9021. 22 Feb 89 12:19:00 CET remarks:
  9022.  
  9023. >> ... Instead of that, quite
  9024. >> obsolete characters for multiply and divide, for which * and /
  9025. >> are used in programs for more then 25 years, have been
  9026. >> inserted in the middle of a column.
  9027. >> ... Removing "multiply" and "divide" would make place for
  9028. >> putting in the French ligature "OE" and "oe" again, which the
  9029. >> logic of 6937 wanted to keep and that of 8859 wanted to go.
  9030.  
  9031. I have not seen a printed representation of these two characters.
  9032. If, as I presume, they are a centered sans-serif x for multiply,
  9033. and a minus with a dot above and below for divide, then there is
  9034. another problem.  In the English-speaking world, that symbol is
  9035. used to mean division, but in Denmark (and possibly elsewhere in
  9036. Scandinavia), it means subtract!
  9037.  
  9038. While circumflex may have been used as a logical NOT in PL/1
  9039. environments running with ISO character sets, I would like to
  9040. point out that in the C language, exclamation point is used as a
  9041. Boolean (logical) NOT, tilde is used as a one's complement
  9042. (another kind of NOT) and circumflex as an exclusive OR.  It
  9043. would surprise me if there is not now substantially more code
  9044. extant in C than in PL/1.
  9045.  
  9046. Given that both EBCDIC and the ISO character sets each contain an
  9047. exclamation point, and each contain a (possibly-split) bar, it is
  9048. foolish to consider mapping exclamation point into vertical bar.
  9049. No responsible editor would permit a vertical bar to be used in
  9050. natural language text to mean exclamation point, and the heavy use of
  9051. both symbols in the C programming language for completely
  9052. different purposes (that lead to syntactically correct, but
  9053. semantically wrong, code, when the two are exchanged, as I have
  9054. earlier pointed out on this list) require that a mapping of
  9055. between exclamation point and vertical bar be discouraged, if not
  9056. outright forbidden.
  9057. -------
  9058.  
  9059. 23-Feb-89 14:48:41-GMT,1850;000000000001
  9060. Received: from CUVMB.CC.COLUMBIA.EDU by cunixc.cc.columbia.edu (5.54/5.10) id AA21150; Thu, 23 Feb 89 09:48:33 EST
  9061. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.CC.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0179; Thu, 23 Feb 89 09:46:35 EST
  9062. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  9063.  id 9016; Thu, 23 Feb 89 09:46:34 EST
  9064. Received: by BITNIC (Mailer X1.25) id 6564; Thu, 23 Feb 89 09:34:37 EST
  9065. Date:         Wed, 22 Feb 89 23:52:20 EST
  9066. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9067. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9068. From: John C Klensin <KLENSIN%INFOODS.MIT.EDU@cuvmb.cc.columbia.edu>
  9069. Subject:      RE:       Comment on ISO 8859 multiply and divide
  9070. X-To:         ASCII/EBCDIC character set related issues
  9071.               <ISO8859%JHUVM.BITNET@MITVMA.MIT.EDU>
  9072. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  9073.  
  9074. In those environments that run with EBCDIC, I would strongly suspect
  9075. that there is more PL/I use than C use.  Even today.  And more COBOL use
  9076. than either.   There are also approved, cast-in-concrete ISO and ANSI
  9077. Standards for PL/I and only Draft Proposals for C; your comments could
  9078. be construed as "C should be changed prior to standardization, because
  9079. it uses too many characters in violation of the style in which other
  9080. programming languages, etc., use them".  That is not a proposal or
  9081. suggestion, serious or otherwise, just a comment about how things work.
  9082.  
  9083. What is more important is that this type of semi-quantitative reasoning
  9084. won't solve any problems.  What it will do is to encourage the vendor to
  9085. say "ok, different character sets for different audiences, since the
  9086. market pressures run against goring the oxen of large customers", which is
  9087. what we are trying to avoid.
  9088.  
  9089.   John Klensin, MIT
  9090.  
  9091.  
  9092. 24-Feb-89 12:33:52-GMT,3034;000000000001
  9093. Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA04125; Fri, 24 Feb 89 07:33:49 EST
  9094. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0657; Fri, 24 Feb 89 07:31:58 EST
  9095. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  9096.  id 0750; Fri, 24 Feb 89 07:31:57 EST
  9097. Received: by BITNIC (Mailer X1.25) id 7970; Fri, 24 Feb 89 07:14:40 EST
  9098. Date:         Thu, 23 Feb 89 01:59:06 PST
  9099. Reply-To: "Joan M. Winters" <WINTERS%SLACVM@cuvmb.cc.columbia.edu>
  9100. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9101. From: "Joan M. Winters" <WINTERS%SLACVM@cuvmb.cc.columbia.edu>
  9102. Subject:      Summary of Responses on Hex Codes for Curly Braces
  9103. X-Cc:         SAXTON@SLACSLD, JXH@SLACVM, WBJ@SLACVM, BEBO@CERNVM,
  9104.               COTTRELL@SLACVM
  9105. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  9106.  
  9107. Folks - Finally, here's my summary on what hexadecimal codes are
  9108. actually used around the EBCDIC world to define curly braces (graphic
  9109. characters {} at my place), primarily from you on the ISO8859 list.  To
  9110. simplify, of the 20 institutions total I heard from:
  9111.  
  9112. 16  use  X'C0' and X'D0'
  9113.  3  use  X'8B' and X'9B'
  9114.  1  uses X'C0' and X'D0' for terminals, X'8B' and X'9B' for printers
  9115.  
  9116. "Use" means these are the only, default, or primary codes for braces.
  9117.  
  9118. Of the 16, 4 mentioned that by default they print both pairs of code
  9119. points as braces, even though on input they encode braces only as
  9120. X'C0' and X'D0'.  Another provides such "bi-lingual" code sets for
  9121. printers, but not by default.  In addition to SLAC, 1 site has old
  9122. Tektronix-style plotting software that considers braces to be X'8B'
  9123. and X'9B', in spite of a general EBCDIC use of X'C0' and X'D0'.
  9124.  
  9125. No organization mentioned plans to convert their code points for
  9126. braces.  However, 6 noted conversion within recent years to X'C0'
  9127. and X'D0';  3 within the last two years.  1 of the X'8B' and X'9B'
  9128. places said they may change some things to accept both code pairs.
  9129. Another seems already to have good support for both.  The site with
  9130. the X'8B' and X'9B' printer-only default has a new character set that
  9131. prints braces for both code pairs.
  9132.  
  9133. The places that had converted to X'C0' and X'D0' seemed basically
  9134. content with the change.  1 site said they'd never convert again;  2
  9135. said if the standard required it, they would one more time.  1
  9136. organization even made a plea for being able to re-use the X'8B' and
  9137. X'9B' codes points for other characters.  Of the places that use X'8B'
  9138. and X'9B', 1 said they'd most likely convert to a standard if such
  9139. came to exist.
  9140.  
  9141. It's hard to classify some responses.  As usual in this area, answers
  9142. often differ within an organization, depending on the exact
  9143. circumstances.  I'm bringing the mail I got to SHARE, for those of you
  9144. who'll be there and are interested in the gory details.
  9145.  
  9146. I enjoyed reading your notes, in all their variations.  Thank you very
  9147. much for your help!                                 Joan Winters
  9148.  
  9149.  7-Mar-89 22:12:59-GMT,9208;000000000201
  9150. Return-Path: <@cuvmb.cc.columbia.edu:ISO8859@JHUVM.BITNET>
  9151. Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
  9152.     id AA17364; Tue, 7 Mar 89 17:12:54 EST
  9153. Message-Id: <8903072212.AA17364@watsun.cc.columbia.edu>
  9154. Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA28389; Tue, 7 Mar 89 17:11:14 EST
  9155. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 5041; Tue, 07 Mar 89 17:09:02 EST
  9156. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  9157.  id 6947; Tue, 07 Mar 89 17:09:00 EST
  9158. Received: by BITNIC (Mailer X1.25) id 4183; Tue, 07 Mar 89 17:04:18 EST
  9159. Date:         Tue, 7 Mar 89 15:27:55 EST
  9160. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9161. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9162. From: Edwin Hart <HART%APLVM@cuvmb.cc.columbia.edu>
  9163. Subject:      White Paper Executive Summary
  9164. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  9165.  
  9166. Enclosed is a redraft of the Executive Summary of the paper.  It is exactly
  9167. two pages long on an IBM 3820 printer.  It is 4 pages on a 1403.
  9168.  
  9169. I would appreciate any comments by Friday (March 10).
  9170.  
  9171. Thank you.
  9172. Ed Hart
  9173.  
  9174.  
  9175.                              Executive Summary
  9176.  
  9177.           . . . Let us go down, and there confound their language,
  9178.             that they may not understand one another's speech.
  9179.  
  9180.                                                               Genesis  11:7
  9181.  
  9182.      Unless IBM resolves fundamental character set and code issues, Systems
  9183. Application  Architecture  (SAA)  will  fail  to fully meet its consistency
  9184. goal.  Inconsistencies make using IBM  equipment  unnecessarily  difficult.
  9185. People  find  it difficult (1) to exploit PS/2s with mainframe and midrange
  9186. systems, (2) to communicate business information and mail  internationally,
  9187. and  (3)  to  exploit  applications  and high-level languages.   Because of
  9188. mainframe and communications inconsistencies on  a  PS/2,  end  users  type
  9189. certain characters and are confused by the results.  Character set and code
  9190. problems  create  a human factors trap for end usersthe very people SAA is
  9191. to  serve.    The inconsistencies affect not only IBM's European customers6
  9192. but also IBM's U. S. and Canadian, English-speaking customers.   In  short,
  9193. the  inconsistencies  make IBM systems more difficult to use for both naive
  9194. and experienced end users, and this must change for SAA to succeed.
  9195.  
  9196. Character Set and Code Problems
  9197.  
  9198.      Since the early 1970s, end users have experienced many  problems  with
  9199. ASCII  and EBCDIC character sets and codes.  The fundamental problem occurs
  9200. because certain  characters  change  when  people  move  them  between  IBM
  9201. systems,  MVS/TSO,  VM/CMS, OS/400, and the PS/2.  This problem consists of
  9202. four interrelated facets.
  9203.  
  9204. The ASCII and EBCDIC Character Sets and Codes Are Inconsistent.
  9205.  
  9206.      The ASCII and EBCDIC character sets do not match.    Three  ASCII  and
  9207. three EBCDIC characters exist in one code but not the other.  Moreover, the
  9208. ASCII  standard evolved but many IBM products still reflect the back level,
  9209. 1968 standard, rather than the 1977 or 1986 version.   EBCDIC  is  not  one
  9210. code  but a family of codes.  People misunderstand this.  In the U. S., end
  9211. users use several EBCDIC codes (U. S. standard EBCDIC, TN/T11 print  train,
  9212. and various coded fonts for the IBM 3800 printer series, and office systems
  9213. EBCDIC).    End  users  are confused because the same character will have a
  9214. different binary value assigned in  different  EBCDIC  codes,  and  certain
  9215. binary  values  will  have  different character assignments.   As a result,
  9216. users of IBM computers must be aware of the code being used.
  9217.  
  9218. Translations between ASCII and EBCDIC Are Inconsistent.
  9219.  
  9220.      Depending  on  the  computer  and communications system, people obtain
  9221. different results when certain keys are struck on a PS/2 or ASCII terminal.
  9222. MVS uses translations different  from  VM;  communication  controllers  use
  9223. different  translations  than  protocol  converters; ASCII tapes have yet a
  9224. different translation.  End users cannot understand this.
  9225.  
  9226.      In addition, the IBM "standard" ASCII-to-EBCDIC translation  makes  no
  9227. sense  to  English-speaking U. S. and Canadian customers, or to anyone else
  9228. for that matter.  For example, to force an end user to type the  ASCII  "!"
  9229. to  enter  an  EBCDIC "|", and the ASCII "[" to enter an EBCDIC "!", simply
  9230. makes no sense| (oops) !
  9231.  
  9232. Required Characters Are Absent from ASCII and EBCDIC.
  9233.  
  9234.      Characters required for modern applications and programming  languages
  9235. are   missing  from  ASCII  and  EBCDIC.    High  level  languages  require
  9236. syntactically-significant characters to have specific binary values.    For
  9237. example,   the  NOT  symbol,  "^",  must  be  X5F.    To  compensate,  many
  9238. installations  modified  the  translate  tables.     High-level   languages
  9239. frequently  allow  alternate,  multiple character sequences for the missing
  9240. characters.     However,  end   users   insisted   on   typing   just   one
  9241. characterespecially  when the character is on the keyboard.  Also, because
  9242. U. S. standard  EBCDIC  lacks  bracket  characters,  installations  defined
  9243. EBCDIC-to-EBCDIC  translate tables for IBM 3270 terminals to use IBM's high
  9244. level languages.
  9245.  
  9246. IBM's Apparent Character Set and Code Strategy Is Inadequate.
  9247.  
  9248.      IBM appears to have embarked on a strategy which will resolve many  of
  9249. the  problems.   It seems to be based on standardizing on the character set
  9250. of the ISO} 8859-1 standard which contains most of the characters  required
  9251. for  Western  European  languages.    For  EBCDIC, IBM created nine Country
  9252. Extended Code Pages by expanding the  language-dependent  EBCDIC  codes  to
  9253. contain  the  full  character  set.    For  the  PS/2,  IBM  created its PC
  9254. Multilingual Code.  With these changes, the Western European character  set
  9255. is available on all SAA computers.
  9256.  
  9257.  
  9258.  
  9259. The International Organization for Standardization.
  9260.  
  9261.      Although  we  are  beginning  to  see  some benefits, this strategy is
  9262. inadequate.  It was designed so customers could avoid  a  data  conversion.
  9263. However,  IBM has never announced any strategy.  As a result, installations
  9264. in Europe and North America are diverging  by  focusing  on  two  different
  9265. Country Extended Code Pages for the long-term.
  9266.  
  9267. Requirements
  9268.  
  9269.      Because  the problems and issues are interrelated, customers demand an
  9270. integrated solution.  The primary objective is to preserve the  meaning  of
  9271. character  data  across  SAA  systems.    This  objective expands into four
  9272. different requirement categories.
  9273.  
  9274. 1.  IBM needs an architecture for character sets and codes in SAA.  Many of
  9275.     the end user problems result not from a lack of standards but from  too
  9276.     many inconsistent standards.  IBM must focus on one EBCDIC code and one
  9277.     ASCII code for the Western European character set.  The paper refers to
  9278.     these  as  "Reference EBCDIC" and "Reference ASCII".  IBM must announce
  9279.     its direction so customers can  start  planning.    Implementing  these
  9280.     requirements  will  solve many issues of the first three problem areas.
  9281.     Not implementing them will (a) put IBM at a disadvantage to competitors
  9282.     (like Digital Equipment Corporation) which use the ISO 8859-1 code, (b)
  9283.     will allow  the  existing  proliferation  of  code  inconsistencies  to
  9284.     continue, and (c) make solving the problems later much worse.  However,
  9285.     merely defining standards in SAA is insufficient.
  9286.  
  9287. 2.  IBM  SAA  products  must  exploit the "Reference EBCDIC" and "Reference
  9288.     ASCII" codes.   People use computers for  applications.    Recall  that
  9289.     current  applications  only  support  specific  codes.   Therefore, SAA
  9290.     products must use the "Reference EBCDIC" and "Reference ASCII" codes.
  9291.  
  9292. 3.  Installations require help migrating  to  the  "Reference  EBCDIC"  and
  9293.     "Reference  ASCII" codes. The migration period will extend over several
  9294.     years because customers face both IBM and non-IBM software  conversions
  9295.     and  have inventories of older equipment.  The primary concerns are (1)
  9296.     to migrate once, (2) to minimize difficulties during migration, (3)  to
  9297.     allow  each  installation  to choose its own migration plan, and (4) to
  9298.     provide tools to assist migration.  Implementing migration requirements
  9299.     will help customers rise above the mire of present problems.
  9300.  
  9301. 4.  SHARE must become more involved in Standards issues.  This is an  issue
  9302.     not  for  IBM  but for SHARE.   SHARE must influence standards to avoid
  9303.     future problems.
  9304.  
  9305.      This summarizes the SHARE requirements for resolving the problems  and
  9306. issues.    They will not be easy to resolve.  If they were, customers could
  9307. have resolved them years ago.  Resolution will require difficult  decisions
  9308. for IBM and its customers.  Nevertheless, the decisions must be made.  Some
  9309. in  IBM  believe that nothing need be done now.  This is untrue because the
  9310. problems become worse every day.  SAA provides a unique opportunity for IBM
  9311. and its customers to break with past problems, and make a fresh start.  But
  9312. IBM must act quickly or lose the opportunity.  Act now!
  9313. 30-Mar-89 20:32:22-GMT,6876;000000000411
  9314. Return-Path: <@cuvmb.cc.columbia.edu:ISO8859@JHUVM.BITNET>
  9315. Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
  9316.     id AA19127; Thu, 30 Mar 89 15:32:15 EST
  9317. Message-Id: <8903302032.AA19127@watsun.cc.columbia.edu>
  9318. Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA22424; Thu, 30 Mar 89 15:29:26 EST
  9319. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 4600; Thu, 30 Mar 89 15:27:44 EST
  9320. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  9321.  id 0924; Thu, 30 Mar 89 15:27:43 EST
  9322. Received: by BITNIC (Mailer X1.25) id 0137; Thu, 30 Mar 89 15:28:38 EST
  9323. Date:         Thu, 30 Mar 89 12:47:24 CST
  9324. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9325. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9326. From: Michael Sperberg-McQueen <U18189%UICVM@cuvmb.cc.columbia.edu>
  9327. Subject:      query about overstruck characters in ISO 8859
  9328. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  9329.  
  9330. Johan van Wingen has pointed out several times in this forum that in ISO
  9331. 8859, as opposed to ISO 6937, 646, and other earlier coded character
  9332. sets, it is illegal to use backspaces to overstrike two characters as a
  9333. method of obtaining a new character.  At least, that's what I understood
  9334. him to say.  ISO 8859-1 : 1987 (E) says (paragraph 7) "The use of
  9335. control functions, such as BACKSPACE or CARRIAGE RETURN for the coded
  9336. representation of composite characters is prohibited by ISO 8859."
  9337.  
  9338. I have two questions:  (1) just what sorts of activities are supposed to
  9339. be forbidden here? and (2) why?
  9340.  
  9341. To be more specific:  if I need to print a Serbo-Croatian word
  9342. containing a 'c' with an acute accent, I could probably do any of the
  9343. following things (depending on my system environment).  Which of them
  9344. are legal, and which illegal?  And can we construct a rationale for the
  9345. legality and illegality of each?  (= *should* they be legal?)
  9346.  
  9347. (a) embed the sequence 'c' BACKSPACE ´. (hex 63 07 B4) in my file
  9348. (if I'm using an editor that allows me to embed backspace characters, as
  9349. some do and some don't) and let the printer, the display, and other
  9350. devices deal with it as best they can.  The display will probably show
  9351. me the acute, and the printer will do an overstrike, unless it's a line
  9352. printer, in which case I may get a variety of things but almost
  9353. certainly not what I want.
  9354.  
  9355. (b) use a Script command like ".dc bs <" and then use the combination
  9356. 'c<´.' in my file.  Script will arrange to have the acute and the
  9357. 'c' overstruck, either by issuing a backspace or by doing something
  9358. else.
  9359.  
  9360. (c) use the same Script command, and also define a Script symbol with
  9361. ".sr cacute = 'c<´.'" or ".sr cacute = 'c&sysbs.´."  and then
  9362. in my file use "&cacute." instead of "c<´."
  9363.  
  9364. (d) use some relevant system facility (either in Script or in a
  9365. microcomputer word processor) to define the width of hex B4 as 0.  Then
  9366. send the sequence hex B4 63 to the printer.
  9367.  
  9368. (e) use the editor or some (imaginary) Script facilities to embed a
  9369. sequence like ESC '-' 'B' (hex 1B 2D 42) at the beginning of my file to
  9370. set up ISO 8859-2 as my G1 character set, and then in my file embed
  9371. SHIFT-IN X'B6' SHIFT-OUT (hex 0F B6 0E) for the acute-accented 'c'
  9372.  
  9373. (f) embed the ESC '-' 'B' sequence in some way, use Script's symbol
  9374. facility to define ".sr cacute = &x'0FB60E' " and then use "&cacute."
  9375. in my file as usual.
  9376.  
  9377. If I understand the text of paragraph 7, approach (a) is clearly in
  9378. violation of the spirit and letter of the standard.  What about approach
  9379. (b)?  In my file, I'm not using any control characters to create
  9380. composite characters:  only graphics.  I don't expect any editor to
  9381. resolve the multi-character encoding for me and display an accented 'c'.
  9382. But I am, I admit, using backspace or CR in the printer stream (or if
  9383. the printer is more sophisticated, maybe something even more devious).
  9384. Or perhaps I'm not.  I don't know what Script97 does with the Xerox
  9385. 9700; all I know is that the ".sr" command given should give me
  9386. something resembling the character I want on my output.
  9387.  
  9388. Approach (c) is much the same as (b), except that a lot of these symbols
  9389. are already defined at installation.  Is it a violation of the standard
  9390. to use them, if they produce backspaces in the printer data stream?
  9391.  
  9392. Approach (d) avoids the backspace in the data stream, but probably
  9393. violates another part of paragraph 7:  "None of these characters are
  9394. <q>non-spacing<eq>."
  9395.  
  9396. Approach (e) and (f) sound as though they are what the standards
  9397. committee expects us to do.  But given that very few pieces of software
  9398. will handle such escape sequences, I am not sure what paragraph 7 can
  9399. mean or is supposed to mean for sites, developers, or end users.  If I
  9400. cannot use character 11/4 (acute accent) to form composite characters,
  9401. why is it there?  For use in mathematics to distinguish symbols (K and
  9402. K' = K-prime)?  In that case it would be far better to use slots 11/4,
  9403. 10/8, 11/8, and 10/15 to include Turkish, and define another single
  9404. character set for all sorts of mathematical symbols.  ("Lead us
  9405. not into temptation.")
  9406.  
  9407. I imagine the point of paragraph 7 must be to say that extension of the
  9408. character set to handle things like accented 'c' should be done through
  9409. the extension techniques defined by other ISO standards, and not by
  9410. overstriking characters of the ISO 8859 sets.  In an ideal world, all
  9411. the equipment would support ISO 8859-1 through -9, and ISO 2022 and so
  9412. on.  But in the real world -- is it considered a violation of ISO 8859
  9413. to use non-standard code extension techniques in order to make
  9414. non-conforming equipment produce appropriate results?  Our printer
  9415. probably doesn't have a-umlaut as a separate character.  Is it a
  9416. violation of paragraph 7 to write a printer driver that reads character
  9417. 14/4 from a file and sends an overstrike sequence including BACKSPACE to
  9418. the printer?  Would it be a violation if the printer driver translated
  9419. from ISO 8859 to ISO 6937?
  9420.  
  9421. Frankly, I find the blanket prohibition against use of BACKSPACE and CR
  9422. in paragraph 7 a bit confusing and don't believe I understand the logic
  9423. behind it.
  9424.  
  9425. I am involved in a large international project to formulate methods for
  9426. encoding literary and linguistic data in machine-readable form.  It is
  9427. important that we be able to recommend sound practice for encoding
  9428. diacritics.  To me, that means practice which agrees with relevant
  9429. standards.  But it is also essential that the recommended practice be
  9430. something that people can actually work with using the software that
  9431. exists.  So I am particularly interested in finding out what the
  9432. character set committee had in mind when they wrote paragraph 7.
  9433.  
  9434. -Michael Sperberg-McQueen
  9435.  Editor in Chief, ACH / ACL / ALLC Text Encoding Initiative
  9436.  University of Illinois at Chicago
  9437.  
  9438. 31-Mar-89  2:05:08-GMT,2089;000000000001
  9439. Return-Path: <@cuvmb.cc.columbia.edu:ISO8859@JHUVM.BITNET>
  9440. Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
  9441.     id AA20280; Thu, 30 Mar 89 21:05:06 EST
  9442. Message-Id: <8903310205.AA20280@watsun.cc.columbia.edu>
  9443. Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA19487; Thu, 30 Mar 89 21:01:50 EST
  9444. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 4791; Thu, 30 Mar 89 21:00:35 EST
  9445. Received: from BITNIC.BITNET by CUVMB.CC.COLUMBIA.EDU (Mailer X1.25) with BSMTP
  9446.  id 1560; Thu, 30 Mar 89 21:00:34 EST
  9447. Received: by BITNIC (Mailer X1.25) id 8444; Thu, 30 Mar 89 21:01:34 EST
  9448. Date:         Thu, 30 Mar 89 18:53:57 EST
  9449. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9450. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9451. From: Frank da Cruz <fdc%WATSUN.CC.COLUMBIA.EDU@cuvmb.cc.columbia.edu>
  9452. Subject:      Re: query about overstruck characters in ISO 8859
  9453. X-To:         ASCII/EBCDIC character set related issues
  9454.               <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  9455. X-Cc:         Christine M Gianone <cmg@watsun.cc.columbia.edu>
  9456. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  9457. In-Reply-To:  Your message of Thu, 30 Mar 89 12:47:24 CST
  9458.  
  9459. We share your curiosity about the ISO8859 prohibition on composite
  9460. characters.  Not that it doesn't make sense -- ISO 8859 wants a character
  9461. to be a character, so that it is possible for character and string
  9462. oriented software to deal with text in a uniform way.  Hence ISO 8859
  9463. shuns the composite "character building" allowed by ISO 646, and *required*
  9464. by CCITT T.61.  Our curiosity, like yours, is about how mixed-alphabet
  9465. data is to be stored on disk.  This relates closely to an extension to the
  9466. Kermit file transfer protocol that we're working on, for transferring text
  9467. in mixed alphabets between unlike systems.  If you'd like to read & comment
  9468. on it, or want to be added to the "isokermit" discussion group, let us
  9469. know.  - Christine Gianone and Frank da Cruz
  9470.  
  9471. 31-Mar-89 11:09:56-GMT,7097;000000000000
  9472. Return-Path: <@mitvma.mit.edu:KLENSIN@INFOODS.MIT.EDU>
  9473. Received: from mitvma.mit.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
  9474.     id AA21290; Fri, 31 Mar 89 06:09:52 EST
  9475. Received: from INFOODS.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with TCP; Fri, 31 Mar 89 06:09:44 EST
  9476. Received: by INFOODS id <00002470066@INFOODS.MIT.EDU> ;
  9477.        Fri, 31 Mar 89 06:01:57 EST
  9478. Date: Fri, 31 Mar 89 05:24:36 EST
  9479. From: John C Klensin <KLENSIN@INFOODS.MIT.EDU>
  9480. Subject: Overstruck characters and 8859
  9481. To: Frank da Cruz <@mitvma.mit.edu:fdc@watsun.cc.columbia.edu>
  9482. X-Vms-Mail-To: EXOS%"Frank da Cruz <@mitvma:fdc@watsun.cc.columbia.edu>"
  9483. Message-Id: <890331052436.00002470066@INFOODS.MIT.EDU>
  9484.  
  9485. Frank,
  9486.   First of all, if you have an isokermit list going, please add
  9487. me to it.  Maybe, even though the newsletters seem to have stopped 
  9488. getting through to here, and info-kermit-request respondeth not, I can
  9489. get that. 
  9490.    Klensin@INFOODS.MIT.EDU
  9491.  
  9492.   I'm waiting until I have a chance to study the responses to the 
  9493. original question for a bit before I put together a response of my own
  9494. (which, by then, may not be necessary) but let me provide a piece of the
  9495. answer from a standards-policy viewpoint.
  9496.   One of the big problems with this evolving standards stuff is a global
  9497. lack of coordination. We are at a sufficiently primitive point that
  9498. "coordination" means "telling other people what you are doing", and we
  9499. are not doing very well at that. ANSI has just initiated its third--in
  9500. about as many years--attempt at a system for on standards developer
  9501. notifying others when new projects are initiated.  The other two fizzled
  9502. out into nothing in short order and, in at least some respects, the
  9503. ISO/IEC/CCITT situation is worse. 
  9504.   Now, against that backdrop, ISO/IEC JTC1/SC2 and its ANSI/X3
  9505. equivalent ought to be forced to (a) make clear statements about what
  9506. each of these character set standards is *for* and how each relates to,
  9507. and can be translated to and from, any of the others and (b) understand
  9508. that more alternatives is often a vice, not a virtue.  Otherwise, they
  9509. are headed, and heading us, rapidly down the path that IEEE 802 seemed
  9510. to be going down for a while: you can "standardize" any network physical
  9511. and link level technology you like, as long as you can write a clear
  9512. specification.  Better than not writing a clear specfication, I suppose.
  9513.   SC22 (ISO programming languages) has finally (after umpity years) 
  9514. established a strong liaison with SC2 and is beginning to say "look 
  9515. guys, some of these things are impossibly difficult in use, and there 
  9516. are some things you have to specify".  It is not clear that will cure 
  9517. the problem.
  9518.   Anyway, CCITT's traditional goal has been clear--to transmit the 
  9519. maximum number of character representations down a communications line, 
  9520. with minimum switching around, and a minimum requirement for really 
  9521. fancy hardware at the far end.  Hence a lot of overstrike logic.  *Some* 
  9522. of the SC2 standards follow that tack, and are standards for 
  9523. transmission of characters over communications links.  But, if you are 
  9524. trying to do a programming language system--especially if you are trying 
  9525. to compare, catenate, or overlay character strings--variable-length 
  9526. logical characters (which is what a graphic BS graphic amounts to) is a 
  9527. pain in the neck to deal with.  Even the definition of the length of a 
  9528. string gets funny when length-in-"bytes" is not equal to length-in-
  9529. logical-characters.   So 8859 comes along, and, with good intentions and 
  9530. for good reasons, they say, or try to say, "no composite characters".
  9531.   And, of course, someone comes along and says "but I want to have 
  9532. composite characters, how do I do it?"  In the 8859 world, you don't.  
  9533. You have a code point and, at any point, you need to know which 8859 
  9534. element that code point is to be interpreted with respect to.  That 
  9535. combination of character set and code point--I know of one experimental 
  9536. implementation in progress that simply canonicalizes all of the 
  9537. switching into and out of 8859 sets into representing each "character" 
  9538. internally with two octets, the 8859/n set and the code--gives a unique, 
  9539. testable character, under a rule that two character sets means two 
  9540. different characters, even if the graphics are the same.  If you want a 
  9541. rule that says "if the graphics and/or character names are the same, the 
  9542. characters are the same", then you need a further canonicalizer that 
  9543. prefers, for example, low-numbered 8859 sets to high-numbered ones.  And 
  9544. dealing with multiple sets requires very high tech devices, which can 
  9545. understand all of them and, presumably, bit map characters onto the 
  9546. screen.  'Taint a $400 terminal.
  9547.  
  9548.   The kermit meta-question depends on what you are trying to do, and 
  9549. what needs you are trying to solve and, to partially repeat what I've 
  9550. said earlier, the needs and requirements are different enough that I'd 
  9551. get out my ten foot pole and use it to define a boundary between "data 
  9552. transfer" and a lot of very complex data transformation issues.  Let me 
  9553. suggest a nasty analogy.  Plus or minus a certain amount of precision 
  9554. loss, it is possible to convert any floating point number representation 
  9555. into any other.  I don't much favor the idea, but it would be possible 
  9556. to invent a way of defining floating point formats, and to define a 
  9557. "kermit-standard" floating point.  You could then fix up an attribute 
  9558. packet that would say "this here file is completely in kermit-standard 
  9559. floating point" and expect that kermits at both ends would convert 
  9560. between local representations and that format.  Problem is that either
  9561. it would work only for files that contained nothing but floating point 
  9562. numbers, or you would have to invent a mechanism for flagging which 
  9563. values were floating point and which were something else.  The number of 
  9564. "pure" floating point files drops each year, especially since people 
  9565. want to transmit, e.g., array dimensionality, with their data files. 
  9566. And, right after you headed down that slippery slope, we would be 
  9567. talking about a general kermit self-describing file.
  9568.   I would think about this as a way to describe the "thing" that is 
  9569. being transmitted--an atomic file, if you will.  "thing" descriptions 
  9570. are pretty simple: 646Text.  You-better-not-mess-with-this-"binary". 
  9571. 8859-1Text.  8859-nText, where "n" is another attribute.  Now, there is 
  9572. nothing wrong with T.61Text as a "thing", as long as no one has 
  9573. delusions about conversions between graphic stylizations associated with 
  9574. T.61 and characters associated with 8859-n being performed 
  9575. automatically, especially in poor, helpless, kermit programs as distinct 
  9576. from converters with lots of user-adaptable tables and heuristics of 
  9577. their own.  T.61, if I recall, lacks even the elementary required 
  9578. canonicalization rules that made string compares work on Multics (those 
  9579. are, effectively, designed around the "if it looks the same, it is the 
  9580. same" principle, something that 8859 implicitly disavows).
  9581.  
  9582.    john
  9583.    Identification of hat being worn as this is written:
  9584.      Chairman, ACM Standards Committee; Member, ANSI/ISSB.
  9585.    Klensin@INFOODS.MIT.EDU
  9586.  
  9587.  
  9588. 31-Mar-89 16:05:07-GMT,37228;000000000001
  9589. Return-Path: <FDCCU@cuvmb.cc.columbia.edu>
  9590. Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
  9591.     id AA21708; Fri, 31 Mar 89 11:05:03 EST
  9592. Message-Id: <8903311605.AA21708@watsun.cc.columbia.edu>
  9593. Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA27286; Fri, 31 Mar 89 11:01:38 EST
  9594. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 5027; Fri, 31 Mar 89 11:00:28 EST
  9595. Received: by CUVMB (Mailer X1.25) id 2511; Fri, 31 Mar 89 11:00:25 EST
  9596. Date: 03/31 10:11:34
  9597. From: FDCCU@cuvmb.cc.columbia.edu
  9598. Subject: PUN file from RSCS - MOSGLA.MAIL
  9599. X-Tag: FILE (4053) ORIGIN HLERUL2  MAILER    3/31/89  5:15:33 E.S.T.
  9600. To: fdc@cunixc.cc.columbia.edu
  9601. Reply-To: MAILER%HLERUL2@cuvmb.cc.columbia.edu
  9602.  
  9603. Date:    Fri, 31 Mar 89 16:57 CET
  9604. From:    "Johan van Wingen"                          <MOSGLA@HLERUL2>
  9605. To:      "M. Sperberg-McQueen"                <U35395@UICVM>,
  9606.          "F. da Cruz"                         <FDCCU@CUVMA>,
  9607.          "E. Hart"                            <HART@APLVM>
  9608. Subject: overstruck characters
  9609.  
  9610. Dear Character Overstrikers
  9611. By way of attempt to convince you that there are good reasons for
  9612. prohibiting composite characters in ISO 8859 I send here the revised
  9613. version of my ISO paper (Ed, you have seen the first version). It are
  9614. 670 lines.
  9615.  
  9616. _ INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
  9617.  
  9618.  
  9619.                                                ISO/IEC JTC1/SC2  N 1961R
  9620.  
  9621.  
  9622.                                                ISO/IEC JTC1/SC22 N  578R
  9623. -
  9624.                                                          September 1988
  9625.  |                                                   Revised April 1989
  9626. 0|                                                          VERSION 1.2
  9627. - CODED CHARACTER SETS AND PROGRAMMING LANGUAGES
  9628. - Johan W van Wingen
  9629. 0 Leiden, the Netherlands
  9630.  
  9631. - Personal contribution
  9632.  
  9633. - Table of Contents
  9634. 0 0   Introduction
  9635.   0.1   The Problem
  9636.   0.2   Terminology, notations and conventions
  9637. 0 1   Coded Character Sets
  9638.   1.1   The birth of ASCII
  9639.   1.2   Extension of the character set
  9640.   1.3   Composite characters
  9641.   1.4   Multiple-byte character sets
  9642. 0 2   Languages
  9643.   2.1   Computer data processing
  9644.   2.2   Operating system considerations
  9645.   2.3   Basic elements of the language
  9646.  |2.4   Problems of character representation
  9647.   2.5   Non-English languages and Information processing
  9648.   2.5.1   Linguistic skeleton of the language
  9649.   2.5.2   Identifiers
  9650.   2.5.3   Comments
  9651.   2.5.4   Handling textual data in the program
  9652.   2.5.4.1   Unrestricted strings
  9653.   2.5.4.2   Restrictions on string content and their validation
  9654.   2.5.4.3   The type "character"
  9655. 0 3   Sorting considerations
  9656. 0 4   Conclusions
  9657.  |4.1   Recommendations to SC22
  9658.  |4.2   Recommendations to SC2
  9659.  |4.3   Unsolved issues
  9660. 0 Annexes
  9661.  
  9662. 1
  9663.  
  9664.                   Entia non sunt multiplicanda praeter necessitatem.
  9665.                   (Entities are not to be multiplied beyond necessity.)
  9666.                                                    William of Occam
  9667.  
  9668.   0  INTRODUCTION
  9669.  
  9670.   0.1  The problem
  9671.  
  9672.   In recent years there has been an increasing demand for computer
  9673.   facilities that do not need the English language for their expression.
  9674.   In the field of International Standards this affects in the first
  9675.   place the work of ISO/IEC JTC1/SC2, Characters and Information Coding,
  9676.   because this committee develops the elementary tools for expressing
  9677.   everything dependent on language. SC22, Languages (for Information
  9678.   Processing) is one of the important users of these tools, and at the
  9679.   same time the primary target for requirements from non-English
  9680.   speakers. At its 1987 Washington meeting two resolutions were adopted,
  9681.   that formulated the principles of a future policy (see SC22 N 406,
  9682.   Resolutions 85 and 86).
  9683.  
  9684.   Up to now several papers have been produced on the subject, (SC22 N
  9685.   113,357,410,403,410,444,460,470,509, SC22/WG10 N 130,204,208,211,213,
  9686.   214), a number of them by the SC2/SC22 Liaison, Mr. Holka. These
  9687.   showed to SC22 that the SC2 matter is far from simple, and difficult
  9688.   to explain. In a reaction, on N 410 in particular, the Convener of
  9689.   SC2/WG3 complained of inaccuracies, of the use of a non-standard
  9690.   terminology, and of a general ignorance of the aspects of the work of
  9691.   SC2 (N 509). To resolve the issues he suggested a joint meeting of SC2
  9692.   and SC22 delegates, which idea is to be acclaimed. The present paper
  9693.   is intended as a first contribution to the working documents for that
  9694.   meeting, and as a renewed attempt at illustrating the relations
  9695.   between the SC22 and SC2 products in a clear way, while acknowledging
  9696.   the valuable ideas and suggestions from Mr. Holka.
  9697.  
  9698.   This paper does not express any opinion of the Netherlands Member
  9699.   Body (NNI), not from any disagreement on the content, but because
  9700.   taking any position is considered premature at the moment.
  9701.  
  9702.   0.2  Terminology, notations and conventions
  9703.  
  9704.   The terminology in this paper is that of the ISO standards in the
  9705.   field. The terms "bit pattern", "bit combination", "byte" are used
  9706.   almost as synonyms, "bit string" is not used. "Byte" is not restricted
  9707.   to 8-bit combinations. For those, "octet" is used instead. Bytes are
  9708.   denoted with the customary hexadecimal representation, but
  9709.   incidentally also according to the ISO convention (15/15 for FF).
  9710.   Where clear from the context, "character" means "graphic character".
  9711.   All graphic characters that are not letters or digits are called
  9712.   "specials". The terms "control character" and "control function" are
  9713.   used as defined in ISO 2022. Where "language" is used, it is in the
  9714.   sense of the SC22 scope, unless it can be derived from the context
  9715.   that "natural language" is meant.
  9716.  
  9717. 1 1  CODED CHARACTER SETS
  9718.  
  9719.   1.1  The birth of ASCII
  9720.  
  9721.   The idea of coding data is rather old. For several purposes it
  9722.   appeared necessary to represent texts or numbers in a form other than
  9723.   spoken or written. The Morse code was an important step in a long
  9724.   development, as was the Hollerith punched card. The idea of having
  9725.   holes as a unit of information, the bit, was very fruitful, and could
  9726.   be generalized for use on electronic media. As early as 1931 the 5-bit
  9727.   TELEX code (CCITT # 2) was adopted, introducing the concept of bit
  9728.   pattern, or bit combination. As main areas of application of
  9729.   representing data with bit patterns emerged in the course of time:
  9730.  
  9731.   1. Storage of data.
  9732.      Numerical results of the census could be stored
  9733.      in punched cards and manipulated in a simple way.
  9734.      Sorting in particular became easy to do.
  9735.   2. Transmission of data.
  9736.      Texts could be transferred by telex in an easier way
  9737.      than was possible by Morse code.
  9738.   3. Processing data by a computer.
  9739.      When computers were developed, bit patterns played
  9740.      an essential role. Storage and registers were organized
  9741.      in "machine words", bit patterns of fixed length. Most
  9742.      popular were 24,32,36,48,60,64.
  9743.  
  9744.   Increasing use of electronic methods necessitated the adoption of
  9745.   standards, which had to serve the areas of application where data
  9746.   interchange was of primary importance. Thus ASCII, a 7-bit code
  9747.  |(characters mapped on 7-bit patterns) saw the light in 1963. An
  9748.   excellent description of the developments leading up to ASCII is found
  9749.   in the paper by Bemer (1) and the book by Mackenzie (2).
  9750.  
  9751.   ASCII provided codes (assigned bit combinations) for 94 graphic
  9752.   characters (26 letters, 52 after 1968, 10 digits and 32 specials), the
  9753.   SPACE and 33 control characters for control functions. The code table
  9754.   is in FIG 1. The control characters are in columns 0 and 1, the
  9755.   capital letters in 4 and 5, small letters (after 1968) in 6 and 7,
  9756.   digits in 3, SPACE at position 2/0, DELETE at 7/15, specials in the
  9757.   positions left over.
  9758.  
  9759.   ASCII was designed by its structure to serve the first two application
  9760.   areas well.
  9761.  
  9762.   -- By assigning to letters bit patterns in ascending order without
  9763.   gaps, a contiguous "collating sequence" could be defined, easily
  9764.   implementable on a electronic device. (The old telex code did not
  9765.   possess this property.)
  9766.  
  9767.   -- By providing codes for control functions and making them easily
  9768.   recognizable by putting them together in two columns of the code
  9769.   tables, ASCII was well suited for transmission of data, text in
  9770.   particular.
  9771.  
  9772. 1 For internal processing by a computer ASCII was not very well adapted.
  9773.   A 7-bit machine word is hardly usable. For internal representation of
  9774.   codes 6-bit or 8-bit "bytes" were much better, as 6-bit bytes could be
  9775.   contained in a 24,36,48,60 bit machine word 4,6.8,10 times, or a 8-bit
  9776.   byte in a 32 or 64 byte word. Only DEC succeeded in putting 5 ASCII
  9777.   characters into a 36-bit word. It is no surprise that many computer
  9778.   manufacturers defined their own 6 or 8-bit coded character sets for
  9779.   their specific machine use. Particularly influential became EBCDIC
  9780.  |from IBM (FIG 1).
  9781.  
  9782.   ASCII has another important property (not present in the old TELEX
  9783.   code). Every character of the set has a unique code, and every bit
  9784.   combination has a unique meaning. The presence of 8-bit bytes in a
  9785.   computer poses a new problem. If we want to transfer collections of
  9786.   these outside the computer ASCII does not provide facilities. We may
  9787.   define certain 8-bit combinations as being equivalent to ASCII codes,
  9788.   but even then we are faced with the fact that there are 128 left
  9789.   without a clear meaning. For the interpretation of these we would need
  9790.  |what we could call a Standard for Charactered Code Sets. In other
  9791.  |words, a standard (as it is now) specifies a mapping of every
  9792.  |character it includes to a single byte. What we want is that it also
  9793.  |says how every byte shall be interpreted as a character.
  9794.  
  9795.   The essence of data communication by transmitting characters coded in
  9796.   deviation from ASCII is "a previous agreement between sender and
  9797.   recipient of the data". The problem with transferring computer data
  9798.   from and to storage is that it is mostly not clear who sender and
  9799.   recipient are. Not only should coding be defined, but also
  9800.   interpretation. A statement that certain "bit combinations shall not
  9801.   be used" is as sensible as saying "a program shall not contain
  9802.   errors". It is the task of the programmer to code his program
  9803.   correctly, but of the compiler to interpret the sequence of bytes,
  9804.   without stopping at the first unrepresented byte.
  9805.  
  9806.   1.2 Extension of the character set
  9807.  
  9808.   It was clear from the start that ASCII deserved an international
  9809.   status such as could be achieved under the responsibility of ISO.
  9810.   Because countries other than the US have different requirements to the
  9811.   contents of the coded character set the approved document ISO R 646
  9812.   contains options for a number of positions in the code table. Once
  9813.   exercised, the result is a National Version, ASCII being the US
  9814.   National Version. Unfortunately this implied that the principle of
  9815.   unique code-character correspondence was abandoned.
  9816.  
  9817.   With the rules of ISO R 646-1968 (revised in 1973 and 1983) it became
  9818.   possible to code texts in Danish or Swedish, which carry a 29 letter
  9819.   alphabet, at the price of losing 6 specials. Further needs such as
  9820.   accented letters (for French) or additional specials could not be
  9821.   satisfied.
  9822.  
  9823.   To this purpose an extension scheme was devised, standardized as ISO
  9824.   2022. The idea is that different characters may be coded with the same
  9825.   bit combination. To indicate which character is meant, a control
  9826.   function SHIFT is inserted (several are defined) or a ESCAPE sequence
  9827.   with analogous effects. At reading (or receiving), each time a SHIFT
  9828.   or ESCAPE sequence is detected, the "state" of the reader changes, and
  9829.   a different code table is accessed. (Possible code tables may be a
  9830.   national version of ISO 646, or one registered by the Registration
  9831.   authority.)
  9832.  
  9833. 1 ISO 2022 provides the means for coding an almost unlimited number of
  9834.   characters by a single, but not unique bit combination. It is not
  9835.   restricted to 7-bits, but was later extended to include 8-bit coded
  9836.   character sets, as soon as the structure of these was defined in ISO
  9837.   4873. Because reading data encoded according to ISO 2022 requires a
  9838.   finite state machine with very many states, practical use never has
  9839.   been extensive. With the advent of hardware with 8-bit facilities
  9840.   partial solutions for the more urgent problems became feasible.
  9841.   Nevertheless, ISO 2022 supplies the general method in all cases where
  9842.   switching of code tables is unavoidable. Even for multiple-byte coded
  9843.   sets rules are defined.
  9844.  
  9845.   ISO 4873 specifies the structure of 8-bit coded character sets, but
  9846.   does not define a single code table. It fixes the content of some
  9847.   areas, but for the rest only options are given. For the purpose of ISO
  9848.   2022 sets are identified with a set designation C0,C1,G0,G1. Control
  9849.   characters occupy columns 0,1 (C0), 8,9 (C1). Columns 2-7 (G0) are
  9850.   identical with those of ISO 646 (including its options). For 10-15
  9851.   (G1), options for 94 or 96 characters are specified. Thus ISO 4873 is
  9852.   only a generic standard, providing for 188 or 190 graphic characters.
  9853.  
  9854.   1.3  Composite characters
  9855.  
  9856.   In order to restrict the complexities of coding by the ISO 2022
  9857.   method, especially where hardware does not allow midstream code table
  9858.   switching, other approaches for extending the available number of
  9859.   graphic characters were recommended. Some characters can be
  9860.   represented by combinations of several other characters. Following the
  9861.   practice of overprinting, ISO 646 allows creation of composite graphic
  9862.   characters by the use of BACKSPACE and/or CARRIAGE RETURN. But it
  9863.   warns (on p. 7):  "According to clause 5 it is permitted to use
  9864.   composite graphic characters and there is no limit to their number.
  9865.   Because of this freedom, their processing and imaging may cause
  9866.   difficulties at the receiving end. Therefore agreement between sender
  9867.   and recipient is recommended if composite characters are used."
  9868.  
  9869.   To meet this pitfall, ISO 6937 follows a different approach. There are
  9870.   simple and composite graphic characters. Several characters are coded
  9871.   with a single bit combination (digits, specials, letters of the Latin
  9872.   alphabet and some additional ones). Others are coded by a double one:
  9873.   the first representing a diacritical mark (non-spacing), the second a
  9874.   Latin letter (spacing). Arbitrary composite graphic characters are not
  9875.   allowed. The number of graphic characters defined by ISO 6937-2 is
  9876.   restricted to those occurring in a "repertoire". Equally, not all
  9877.   "duples" are permitted, only those included in the repertoire. It is
  9878.   assumed that these duples can be displayed by hardware (the "character
  9879.   imaging device") as one single graphic symbol. ISO 6937-2 defines a
  9880.  |"primary" (G0) and a "secondary" (G1) set, which can be combined to
  9881.  |form the graphic character part of an 8-bit code (popularly, the left
  9882.  |and the right hand of the table). In this way a unique, but mixed
  9883.   single/double octet representation of characters is created. All
  9884.   European languages and several others can thus be represented.
  9885.  
  9886. 1 ISO 8859 was developed for presenting a unique single octet
  9887.   representation of graphic characters. Because not all characters that
  9888.   are desired can be accomodated in a 94+96 code table, ISO 8859 is in
  9889.   several parts, each defined for a particular region of the world,
  9890.   serving the need of groups of languages (Europe: West, East, North,
  9891.   South; Cyrillic, Greek, Arabic, Hebrew). Each part contains the 94
  9892.   (G0) from ASCII as a subset, suppleted by a varying 96 (G1) set
  9893.  |(FIG 2, IBM followed by extending its EBCDIC to contain the same 190
  9894.  |graphic characters, FIG 3). Thus the code of ISO 8859 is only unique
  9895.   in a restricted sense. Where graphics from different regions are to
  9896.   be combined in a text, switching techniques from ISO 2022 are
  9897.   required.
  9898.  
  9899.   1.4  Multiple-byte coded character sets
  9900.  
  9901.   Multiple-byte character sets have attracted a lot of attention, in
  9902.   recent times. From this it might seem that it is a clearly defined
  9903.   concept. But it is not, it is not even a new one. Four schemes have
  9904.   emerged as yet:
  9905.  
  9906.   --- That of ISO 646. Characters may be represented by 1,3,5 or more
  9907.   bytes, by use of sequences such as "char" BACKSPACE "char", and so on.
  9908.  
  9909.   --- That of ISO 6937-2. Graphic characters may be formed from
  9910.   diacritic plus letter, giving a mixed single/double byte
  9911.   representation.
  9912.  
  9913.   --- The scheme used by the Chinese, Japanese and Korean national
  9914.   standards. A graphic character is represented by two bytes, each taken
  9915.   from a 7-bit set with 94 positions, the same as is used for the
  9916.   graphic characters in ASCII.
  9917.  
  9918.  |--- A standard in development by SC2/WG2, to which the number DP 10646
  9919.  |now has been assigned. All imaginable characters of the whole world
  9920.   (except cuneiform and hieroglyphs) are uniquely represented with 4
  9921.   bytes per character.  This is the price to be paid for doing without
  9922.   ISO 2022.
  9923.  |
  9924.  |Besides these four, several schemes have been invented and used in
  9925.  |Japan and China that mix single and double byte character
  9926.  |representations, in a bewildering variation.
  9927.  
  9928.   2.  LANGUAGES
  9929.  
  9930.   2.1  Computer data processing
  9931.  
  9932.   Computer data processing consists, in its simplest form, of a program
  9933.   operating on data. Data has to be represented in bit patterns, that
  9934.   is, in machine words, or parts thereof that can be addressed by the
  9935.   hardware organization. Some of these parts may be considered as a
  9936.  |character, or better yet, as the internal representation of a single
  9937.  |character. Mostly, the bit patterns of these representations
  9938.   are not identical to those found in any ISO standard.
  9939.  |
  9940. 1 A program is written in a language. It may exist written on paper, or
  9941.   even in the mind of the programmer. But as soon as it is prepared for
  9942.   input into the computer it consists of a sequence of character
  9943.  |representations, perhaps divided into lines by some device. Once
  9944.   stored in the computer, there is no intrinsic difference between a
  9945.   program and data. Both need representation. After the program has been
  9946.   compiled to an executable form, its representation has changed, but is
  9947.   still expressed in the bit pattern of the machine. What makes data a
  9948.   (potential) program is the place in storage, a matter of
  9949.   interpretation by the computer.
  9950.  
  9951.   2.2  Operating system considerations
  9952.  
  9953.   Computers, at present, do not work by single programs only. It is the
  9954.   Operating System that, as one of its tasks, performs the data
  9955.   management. It assigns meaning to some data, and decides on the shape
  9956.   of output or on the validity of input, quite often outside the control
  9957.   of the program that is supposed to handle these. In fact, speaking in
  9958.   transmission terms, it acts both as "sender and recipient of the
  9959.   data". Because of that, it generally stores the description of the
  9960.   nature of the data outside the data itself, contrary to the practice
  9961.   in transmission ("announcers" being part of the data stream).
  9962.  
  9963.   Another aspect of the data management is the division of data into
  9964.   "records" (and sometimes "blocks"). This may be a different concept
  9965.   from that of "line", such as is defined by the language of the
  9966.   application program.
  9967.  
  9968.   2.3  Basic elements of languages
  9969.  
  9970.   A program is, according to the language definition, always built from
  9971.  |basic elements. They may be called "characters" or "basic symbols",
  9972.  |but they are essentially of an immaterial nature. They may look like
  9973.  |letters or mathematical symbols, but sometimes they may never be used
  9974.  |outside that particular programming language, like some APL
  9975.  |characters. To be suitable for input into a computer they must be
  9976.  |transliterated into sequences (or perhaps lines of sequences) of those
  9977.  |characters the computer can represent. The transliteration rules, from
  9978.  |the abstract character (used in the language definition) to the
  9979.  |concrete character of the machine, are traditionally called "hardware
  9980.  |representation". The concrete character sequences on the input medium
  9981.  |are read in by the computer, and processed by the language compiler.
  9982.  |This external representation of the basic element will then be
  9983.  |converted again, now to the internal representation used by the
  9984.  |compiler, often an integral value.
  9985.  |
  9986.   The importance of this step is sometimes ignored by defining the
  9987.   character set of the language (if there is one thus called, otherwise
  9988.   the list of all the symbols needed for expressing a program in the
  9989.  |language) as being identical to that from an existing standard for
  9990.  |coded character sets, without indication for any extension. At this
  9991.   point the restriction of the elements to English expression creeps in.
  9992.  |Some designers of a language have even been so silly, that they use
  9993.  |brackets and braces, without substitutes, not realizing that this
  9994.  |precludes its use in Scandinavia, where these characters are replaced
  9995.  |by letters from the extended alphabet in use there.
  9996.  
  9997. 1|2.4  Problems of character representation
  9998.  
  9999.  |Even with a single byte character representation, coded programs
  10000.  |generally have to be translated into the character set of the actual
  10001.   computer at input. This may be a one-to-one process only.
  10002.   But if characters are represented by a varying number of bytes things
  10003.   grow worse. This is aggravated when the hardware representation is not
  10004.   unique. APL uses graphic characters not found in any ISO standard.
  10005.  |These can be produced as composite characters using BACKSPACE (in the
  10006.  |following abbreviated to $). Now, if we want an underlined capital A,
  10007.   we can write A$_ or _$A (with ISO 646), or _A (with ISO 6937-2).
  10008.   Which of these is acceptable is a matter of hardware representation.
  10009.  |One may do, or both, or several others.
  10010.  |
  10011.   In ALGOL 60 end is a single basic element, that can be written as
  10012. +             ___
  10013.   e$_n$_d$_ or _$e_$n_$d, but also as end$$$___ or ___$$$end, with a
  10014.   surprising number of other combinations possible, (ISO 6937-2 allows
  10015.  |only _e_n_d, which is an improvement). If all of this is permitted we
  10016.   have created the "line reconstruction problem", which was solved in
  10017.   the ALGOL 60 compiler for the Ferranti ATLAS (4). Few people are
  10018.   prepared nowadays to accept these complexities. Should an ISO 2022
  10019.   style of coding be permitted, including code table switching in the
  10020.   middle of program lines, then designing an adequate hardware
  10021.   representation scheme requires real genius.
  10022.  
  10023.  |There is another point to consider. In certain parts of a program
  10024.  |literal use of characters is needed (in strings for example). They
  10025.  |have to be stored and handled as such by the compiler, and thus an
  10026.  |internal representation is required, in contrast with the external
  10027.  |representation in which they are being read in. If they are always
  10028.  |being coded with the same number of bytes both representations can be
  10029.  |made identical. Otherwise many implementers may have to resort to an
  10030.  |internal mapping on integers. Then it would be difficult to use the
  10031.  |hardware of the present day octet-machines efficiently. If integer
  10032.  |arithmetic is to become needed for handling characters, the clock has
  10033.  |put just backwards to the situation of 25 years ago, when Fortran and
  10034.  |Algol provided for character processing this method only.
  10035.  
  10036.   The conclusion must be drawn that, other than in exceptional
  10037.   situations, only coded character sets that are unmixed and unshifted,
  10038.  |not permitting the use of BACKSPACE, are acceptable for coding a
  10039.   program text. Otherwise, strict and perhaps complex rules are required
  10040.   to ensure a unique hardware representation. These sets are ASCII, and
  10041.   the single parts of ISO 8859, that is ISO 4873 without shift (called
  10042.   Level 1). A consistent double-octet scheme, such as found in the
  10043.   "west-pacific" standards, may also be considered.
  10044.  
  10045.   2.5  Non-English languages and Information Processing
  10046.  
  10047.   Traditionally, the Information Processing world is English speaking
  10048.   only. Now that the access to this world is no longer reserved to an
  10049.   intellectual elite, this practice has become a untenable barrier to
  10050.   large groups of people. The extent of the problems has been
  10051.   excellently summarized in the SEAS White Paper on National Language
  10052.   support (3). With programming languages we distinguish four areas
  10053.   requiring attention.
  10054.  
  10055. 1 2.5.1  Linguistic skeleton of the language
  10056.  
  10057.   Almost every language has a number of elements looking like words from
  10058.   the English language. Some have been assigned a fixed role, some may
  10059.   be chosen freely. Those that are fixed, together with some specials
  10060.   (brackets, separators, delimiters), constitute the linguistic skeleton
  10061.   of every program. According to the specific language definition, they
  10062.   may be called "word symbols", "reserved words" or "keywords". They are
  10063.   supposed to show a program as a running text in English. It is clear
  10064.   that it is not generally possible to translate every single word into
  10065.   another natural language without violating its syntactic rules. Some
  10066.  |statements may even become ambiguous. Language definitions explicitly
  10067.  |containing provision for expressing programs in languages other than
  10068.  |English are scarce, that of ALGOL 68 being the most notable. The ALGOL
  10069.  |68 Report has been translated successfully into Bulgarian and Chinese
  10070.  |(5). But in general it may be advisable to keep the word symbols as
  10071.  |they are in English.
  10072.  
  10073.   2.5.2  Identifiers
  10074.  
  10075.   For naming quantities, variables, labels and so on, "identifiers" are
  10076.   commonly used. These word-like constructs are mostly defined as
  10077.   starting with a letter, and continuing with letters, digits and,
  10078.   sometimes, the low line. The problem lies in the definition of
  10079.   "letter". In the beginning only capital letters were allowed, but even
  10080.   after adding 26 small ones the Scandinavian languages cannot be
  10081.   served. As compilers to a large extent are US products (or written
  10082.   elsewhere with an eye on the US market) they use ASCII or EBCDIC. This
  10083.   means that characters from a national version of ISO 646 are
  10084.   interpreted as specials (brackets etc.). Applying an 8-bit code like
  10085.   one from ISO 8859 is the way out. But even then, the compiler has to
  10086.   be told which part of 8859 the program makes use of, because what may
  10087.   be a letter in one part may be a special in another (FIG 4).
  10088.  
  10089.   Mixing characters from several parts from ISO 8859 requires invoking
  10090.   the help of ISO 2022, which a compiler writer would not like. Checking
  10091.   whether a byte is meant to be a letter would be easier if the letter
  10092.   areas of ISO 8859 would have been contiguous. Instead of that, quite
  10093.   obsolete characters for multiply and divide, for which * and / are
  10094.   used in programs for more then 25 years, have been inserted in the
  10095.   middle of a column. A look-up table is required to decide whether a
  10096.   character is considered a letter or not. This cannot be avoided anyway
  10097.   if a double-octet representation is used.
  10098.  
  10099.   2.5.3  Comments
  10100.  
  10101.  |In general a comment does not present problems when containing any
  10102.  |byte, if it is only clear where it stops (or begins). If a ";"
  10103.  |(semi-colon) is defined for stopping, and the hardware representation
  10104.   transliterates this as ".," unintended effects may occur, especially
  10105.   if spaces are ignored. Besides this, it does not matter which
  10106.  |characters the bytes represent, even if some of them cannot be
  10107.  |displayed properly.
  10108.  
  10109. 1 2.5.4  Handling textual data in the program
  10110.  
  10111.   In order to produce output of text, means to handle its elements must
  10112.   be provided. The usual method is a "string", also called "text
  10113.   constant" or "text literal". A string need not consist of single
  10114.   characters; it may even be nested, in some languages. If we take the
  10115.   simplest form, it remains to be specified what a string can contain:
  10116.   "graphic characters", or "anything that is allowed by the processor",
  10117.   say "bytes".
  10118.  
  10119.  |-- If "graphic characters", some may be represented by a single byte,
  10120.      some by a double. There may be a SHIFT character in it, causing a
  10121.      change of character set from capital to small letters, or to a
  10122.      different national alphabet. All this can be implemented, and has
  10123.      been, as early as 1962, in the Dijkstra ALGOL 60 compiler for the
  10124.      X1. However, problems arise when operations on strings are
  10125.      introduced, not provided in the definition of ALGOL 60.
  10126.  
  10127.  |-- If "anything", bytes may be all 6-bit, or all 8-bit, as with the
  10128.      48-bit word Burroughs computer, where a word may contain 8 6-bit
  10129.      bytes, or 6 8-bytes, necessitating the inclusion in a program of a
  10130.      more precise description of the kind of string that is meant, with
  10131.      a type indicator.
  10132.  
  10133.   Only if the program is coded according to a standard, that is, by
  10134.   defining a unique relationship between all bytes and all characters,
  10135.   it becomes possible to have characters and bytes indiscriminately as
  10136.   elements of a string, and to introduce counting the number of those
  10137.  |elements without ambiguity. Internal and external representation can
  10138.  |be made identical. If not, the character count can be different from
  10139.  |the byte count, and string parsing is necessary.
  10140.  
  10141.   There remains the question, even with a single octet character
  10142.   representation such as that from ISO 8859, what to do with a byte
  10143.   that is not "printable", because there is no graphic character defined
  10144.   for it. It should be remembered, however, that actual printing is
  10145.   outside the control of the application program, and left to the
  10146.   supervision of the operating system, which may process options as to
  10147.   the selection of a printing font, or a coded character set. This may
  10148.   result in something quite different from that in which the program
  10149.   originally was coded (FIG 5,6).
  10150.  
  10151.   FIG 5 shows a little program (in SNOBOL) that converts Greek text in
  10152.   Latin transliteration to one in single Greek letters (even with
  10153.   diacritics). It is printed with the normal printing font which does
  10154.   not include these Greek letters, which are thus invisible (though
  10155.   present) in the result string (HEXALL). But exactly the same program
  10156.   can also be printed (FIG 6) with a Greek font corresponding to a Greek
  10157.   character set, which shows the contents of the string clearly, but the
  10158.   identifiers all in Greek. To the compiler it does not make a
  10159.  |difference, because all the bytes are the same.
  10160.  |In FIG 7 it is demonstrated that if a proportional script is used, a
  10161.  |table layout may be completely obscured.
  10162.  |In that style a program cannot be understood from its printout only.
  10163.  
  10164.   It is the task of the operating system as well, to deal with the
  10165.   control characters or sequences in the text. There are two aspects to
  10166.   be envisaged: presenting the program text for inspection and
  10167.   understanding, and specifying certain actions to be performed by the
  10168.   output.
  10169.  |
  10170. 1 As ISO 6429 specifies, the control functions indicated may be
  10171.   disabled, and interpreted as graphic characters, by changing the
  10172.   "mode" of a device at detecting a specific control function in the
  10173.   data stream, and restoring the action by another. ISO 2047 specifies
  10174.   graphic representations for the control characters of ISO 646. Thus
  10175.   every byte of a program can be shown, if only the ISO standards have
  10176.  |been implemented. Modern terminals like the DEC VT340 allow setting
  10177.  |the "mode" at will, and then display on the screen the text according
  10178.  |to the option chosen.
  10179.  
  10180.   As for specifying actions in a program regarding the output, the
  10181.   desired effect may be realized either by putting a certain character
  10182.   sequence in an output string including control functions, or by
  10183.   calling a library function. In fact, both methods should be
  10184.   available, because neither can cover all situations. There will never
  10185.   be enough library functions to create the effects to be caused by a
  10186.   specific byte sequence. On the other hand, for example, detection of a
  10187.   NEW LINE character by the operating system may not result in the
  10188.   effect intended. Requiring transfer to a new output line by CALL
  10189.   NEWLINE may cause, in a fixed length record environment, the storing
  10190.   of the current line, padded at the right by spaces up to the required
  10191.   length. In a variable length record environment, it may put the number
  10192.   of bytes in the current line before it, and store the whole. Or it may
  10193.   simply store the current line with a new line character attached at
  10194.   the end. (The use of the first byte of a record for printer control is
  10195.   not considered here for simplicity.) All this should be kept outside
  10196.   the control of the application program, and thus not defined by the
  10197.   programming language.
  10198.  
  10199.   2.5.4.1  Unrestricted strings
  10200.  
  10201.   If these problems have been sorted out, and a string is to contain
  10202.   octets only, without any restriction, regardless of their meaning in
  10203.   any code, operations on strings do not pose difficulties. A type
  10204.   "string" can be introduced, with string constants and string
  10205.   variables. A LENGTH function can be provided, substrings can be
  10206.   defined, starting from a given element number to another, and
  10207.  |concatenation is possible. The string can behave like an octet
  10208.   array. Because any stream of octets can be produced, files can be
  10209.   prepared and sent, which can be read by the recipient according to the
  10210.   rules of ISO 6937-2, or even ISO 2022. No special provision is
  10211.   required for double-octet character sets, if these are carefully
  10212.   designed like the Chinese, Japanese and Korean sets. The string
  10213.   'STANDARD' will then be printed without hesitation by a Japanese
  10214.   printer as four Japanese characters (of course with a quite different
  10215.   meaning).
  10216.  
  10217.   2.5.4.2  Restrictions on content of strings and their validation
  10218.  
  10219.   It is only if certain restrictions are put on the contents of strings
  10220.   that things become complicated again. This may happen if it is
  10221.   required that a certain string have an even length, because
  10222.   double-byte characters will be put into it. Also, restrictions may be
  10223.   introduced regarding the validity of some octets (making illegal those
  10224.   that are not "printable"). It is imaginable to define string types
  10225.   that have the desired property, and have them checked for syntax by
  10226.   the compiler. But library functions can perform the checking for
  10227.   validity on string arguments equally well, without further
  10228.   complicating the string syntax of the language.
  10229.  
  10230. 1 2.5.4.3  The type "character"
  10231.  
  10232.   Several languages know a type "character" for a single byte string
  10233.   (the CHARACTER type in FORTRAN is in fact a string type). Longer
  10234.   strings may be defined as character arrays. A function ORD can be
  10235.   defined with a string argument, giving an integer value, the byte
  10236.   converted to decimal. Conversely, a function CHAR with integer
  10237.   argument may deliver a character. This scheme presupposes a single
  10238.   byte and unique character representation. A double-byte but unique
  10239.   code requires an appropriate new type, and new functions, but no
  10240.   special tricks. All others cause a mess.
  10241.  
  10242.   3  SORTING CONSIDERATIONS
  10243.  
  10244.   The topic of sorting belongs only partially to the subject of
  10245.   programming languages. It is only because some of them know the
  10246.   concept of "collating sequence" that it is dealt with here.
  10247.   Historically, it was of utmost importance that numbers could be sorted
  10248.   on base of their bit representation. Also, in the period of capital
  10249.   letters only, putting words into alphabetic sequence could be
  10250.   performed based on a collating sequence defined by the code table. But
  10251.   when requirements became more subtle (as with a telephone directory or
  10252.   a lexicon) bit patterns were only of little help. Thus the merit of
  10253.   having letters contiguously in a code table has become increasingly
  10254.   insignificant. Non-English languages may even have a varied order for
  10255.   the same accented letters, or assign letter combinations an unexpected
  10256.   place in their alphabet. Further discussion can be found in Mackenzie
  10257.   (2) and in the SEAS White Paper (3).
  10258.  
  10259.   One aspect should be pointed at, however. Many compilers are able to
  10260.   produce an identifier list from the program, alphabetically sorted. If
  10261.   identifiers are to contain characters other than those from ASCII, it
  10262.   is unclear how these are to be sorted. It may be that the order from
  10263.   the chosen part of ISO 8859 is kept, but that may not correspond to
  10264.  |national usage. But one should not confuse "ordering" with "sorting".
  10265.  |Only with one-case Latin letters sorting can be directly derived from
  10266.  |the ordering according to the numeric value of the codes, in all other
  10267.  |cases a key transformation is needed. If some identifiers are to be
  10268.   read from right to left (Hebrew, Arabic) more problems turn up.
  10269.  
  10270.   4  CONCLUSIONS
  10271.  
  10272.  |Many of the comments on the non-English or multiple-octet issue one
  10273.  |finds in the literature (even in ISO documents) are too imprecise or
  10274.   too incomplete to be really of use to the language standard developer.
  10275.   In the preceding lines an attempt has been made to clarify the issues
  10276.   which depend on coded character sets. The actual work of providing
  10277.   solutions has to be done by the SC22 Working Groups itself.
  10278.  
  10279.  |Nevertheless, some recommendations may be given for consideration
  10280.  |either by SC22, or by SC2, or by both.
  10281.  |< recommendations still under revision, will be released later >
  10282.   Annexes are not included for space reasons, and special characters.
  10283.  
  10284. 29-May-89 16:49:25-GMT,2703;000000000001
  10285. Return-Path: <@cuvmb.cc.columbia.edu:ISO8859@JHUVM.BITNET>
  10286. Received: from cunixc.cc.columbia.edu by watsun.cc.columbia.edu (4.0/SMI-4.0)
  10287.     id AA26983; Mon, 29 May 89 12:49:23 EDT
  10288. Message-Id: <8905291649.AA26983@watsun.cc.columbia.edu>
  10289. Received: from CUVMB.COLUMBIA.EDU (cuvmb.cc.columbia.edu) by cunixc.cc.columbia.edu (5.54/5.10) id AA11207; Mon, 29 May 89 12:48:37 EDT
  10290. Received: from CUVMB.CC.COLUMBIA.EDU by CUVMB.COLUMBIA.EDU (IBM VM SMTP R1.2) with BSMTP id 0097; Mon, 29 May 89 12:48:32 EDT
  10291. Received: from PSUVM.PSU.EDU by CUVMB.CC.COLUMBIA.EDU (Mailer R2.03B) with
  10292.  BSMTP id 3204; Mon, 29 May 89 12:48:31 EDT
  10293. Received: by PSUVM (Mailer R2.03B) id 7252; Mon, 29 May 89 12:44:05 EDT
  10294. Date:         Mon, 29 May 89 17:31:00 CET
  10295. Reply-To: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  10296. Sender: ASCII/EBCDIC character set related issues <ISO8859%JHUVM@cuvmb.cc.columbia.edu>
  10297. From: Johan van Wingen <MOSGLA%HLERUL2@cuvmb.cc.columbia.edu>
  10298. Subject:      CP850 vs ISO 8859-1
  10299. To: Frank da Cruz <SY.FDC@cunixc.cc.columbia.edu>
  10300.  
  10301. Date:    Mon,  1 May 89 16:15 CET
  10302. From:    "Johan van Wingen"                          <MOSGLA>
  10303. To:      "E. Hart"                            <HART@APLVM>
  10304. Subject: ISO equivalent of CP850
  10305.  
  10306. Dear List Subscribers
  10307. There is an issue not sufficiently discussed up to now.
  10308. It is proposed replacing CP850 by ISO 8859-1. I applaud this, because
  10309. CP850 is a miserable misconstruct. But, as with CP437, it has 256
  10310. graphic characters, where ISO 8859-1 has only 190 (SPACE not included),
  10311. with 65 positions reserved for control characters. Thus both are not
  10312. equivalent. Even if we prefer the more logical distribution of graphics
  10313. over the code page of ISO 8859 to the chaos of CP850, we have not said
  10314. anything about filling the four empty columns (0,1,8,9).
  10315. Our attempt at having a 254 graphic set as an extension of ISO 8859-1
  10316. has failed for the moment. The question is what users want:
  10317. 1. An additional 64 graphics
  10318.    1.1  on the PC only
  10319.    1.2  also under VM or MVS (what to do with the controls)
  10320. 2. 64 controls only, either on PC or mainframe
  10321. 3. bytes interpreted as controls or as graphics, depending on "mode set"
  10322.    (this is more or less available with MS/DOS, but with CP437, CP850,
  10323.    and also with DEC VT340, not with 3270 terminals as far I know)
  10324. The question is, if we want 64 extra graphics, which should we select.
  10325. There is no guidance in any ISO standard.
  10326. I am rather concerned about this, because I am thinking on presenting
  10327. a new attempt for a 254 graphic set, and before showing it anybody,
  10328. comments would welcome contributing to its content.
  10329.  
  10330. FROM  J. W. van Wingen    MOSGLA@HLERUL2.BITNET
  10331. Mail to
  10332. P. O. Box 486,  2300AL Leiden, Netherlands
  10333.  
  10334.  
  10335.