diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc338.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc338.txt')
-rw-r--r-- | doc/rfc/rfc338.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc338.txt b/doc/rfc/rfc338.txt new file mode 100644 index 0000000..2e648b6 --- /dev/null +++ b/doc/rfc/rfc338.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group R.T. Braden +Request for Comments: 338 UCLA/CCN +NIC: 9931 17 May 1972 + + EBCDIC/ASCII MAPPING FOR NETWORK RJE + + +A. INTRODUCTION + + Under NETRJS [1], CCN's Network rje protocol [2], a virtual remote + batch terminal may be either EBCDIC or ASCII. CCN operates an IBM + 360/91 which performs all of its normal processing in EBCDIC. When a + virtual ASCII terminal signs onto NETRJS, CCN translates the "card + reader" stream to EBCDIC and translates the "printer" stream back to + ASCII [3]. + + In recent months, a number of ASCII hosts (RAND PDP-10, Utah PDP-10, + Illinois PDP-11) have completed user processes for NETRJS. Several + users at these sites have noted deficiencies in the ASCII/EBCDIC + mapping rules originally implemented in NETRJS. Since their + objections were well founded, we have altered the existing mapping + and added a new one. + + This RFC has three purposes: + + (1) to make all users of NETRJS aware of the changed ASCII mapping + + (2) to call this problem to the attention of the Network RJE + Protocol Committee + + (3) to knowledge and support Joel Winett's pioneering work [4] in + this area. + + +THE EBCDIC CHIMERA + + A year ago, Joel Winett Published RFC #183, containing the results of + his careful research into just what EBCDIC really means. He sounded + a clarion call for all EBCDIC sites to join in defining a Network + standards mapping. At this time, we at CCN were primarily absorbed + in the timely implementation of the NETRJS protocol to serve an + EBCDIC (!) user site, RAND, so we were not very supportive of his + efforts. + + RFC #183 is a valuable document; we hope a copy falls into the hands + of Armonk. It is clear from RFC #183 that EBCDIC consists of a + standard ("basic") set of characters, combined with a number of + overlapping ad-hoc character happenings. Fortunately, if we exclude + + + +Braden [Page 1] + +RFC 338 EBCDIC/ASCII MAPPING FOR NETWORK RJE May 1972 + + + special-purpose text composition programs, IBM 360 programs use only + the 89 "basic" EBCDIC graphics [5] shown in RFC #183 as well as in + Figure 1. An IBM 029 "EBCDIC" keypunch can create 63 graphics: the + 89 basic EBCDIC graphics less the 26 lower case letters. In fact, + OS/360 requires an even smaller subset of EBCDIC, 60 characters + commonly called the "PL/1 character set". The PL/1 set consists of + the 89 basic graphics, less the 26 lower case letters as well as the + three graphics <cent sign>!" (cent sign, exclamation point, and + quotation). + +C. CHARACTER MAPPING IN NETRJS + + We consider now the requirements of a ASCII/EBCDIC mapping for NETRJS + or any rje protocol. These requirements are as follows: + + Efficiency: + + The translation should be character-to-character, so that the CPU + operation "translate" can be used and character scans obviated. + This is important because a significant volume of character data + may be moved during rje operations. + + Usability: + + (1) All of the 89 EBCDIC graphics should be mapped into + corresponding ASCII characters. + + (2) The mapping should be as nearly transparent as possible, i.e., + whenever the same graphic appears in both sets, it should map + onto itself. + + (3) To minimize the adaptation required of an EBCDIC-oriented + programmer, the ASCII graphics should evoke the corresponding + EBCDIC graphic, when they are not identical. + + Theses considerations led us to incorporate Winett's rules II (a) and + III (b) (see page 4 of the RFC #183) into NETRJS: + + + ASCII EBCDIC + ----- ------ + | | + + ~ <bent bar> + + \ <cent sign> + + + + + +Braden [Page 2] + +RFC 338 EBCDIC/ASCII MAPPING FOR NETWORK RJE May 1972 + + + This defines all 89 basic EBCDIC graphics in terms of ASCII. + However, there is still a question of how to map the 6 "maverick" + ASCII characters ( []{}^` ) which are not in EBCDIC and not in the + list above. + + We could (and did) take the view that all CCN users are concerned + only with writing and executing normal 360 programs using EBCDIC and + that they would enter one of the maverick ASCII graphics only in + error. Our original choice, therefore, was to map the mavericks in + the input into EBCDIC question marks. We also assumed that, if a + user needs to access a larger subset of EBCDIC than the basic 89, he + should do so by doing his rje directly in EBCDIC. + + We now realize that there were two deficiencies in the original + mapping rules. + + 1. The 360 program may be intended to manipulate ASCII text from + the Network. In that case, the Network user needs to have all + ASCII characters, including the mavericks, uniquely mapped + into EBCDIC in some (standard) manner. + + 2. The present mapping is convenient only if a user at an AT&T + Model 33/35 Teletype (or simulator thereof) needs a different + mapping for ease of use. + + For the first case, we have changed the mapping of the 6 maverick + ASCII characters from "?", using instead Winett's rules III (c) and + III (d): + + + ASCII EBCDIC + ----- ------ + [ X'AD' + ] X'BD' + { X'8B' + } X'9B' + ^ X'71' + ` X'79' + + For the user with a Model 33/35 Teletype, we have expanded the set of + virtual remote batch terminal types, adding "TTY" to "ASCII" and + "EBCDIC". A user establishes his virtual remote batch terminal as + type TTY by either doing his initial ICP to socket 15 (vs. 11 for + EBCDIC, 13 for ASCII), or by doing an ICP to Socket 1 and entering + the command "TTYRJS" (vs. "RJS" for EBCDIC, "ARJS" for ASCII). The + mapping used by NETRJS for a TTY remote is: + + + + + +Braden [Page 3] + +RFC 338 EBCDIC/ASCII MAPPING FOR NETWORK RJE May 1972 + + + Model 33 Corresponding + Graphic ASCII EBCDIC + -------- ------------- ------ + \ \ <bent bar> + + <up arrow> ^ | + + <left arrow> _ _ + + [ [ <cent sign> + + ] ] X'BD' + + This is ugly, but it is probably the best we can do. + +D. CONCLUSIONS + + It is obvious that one pair of translation tables won't do the job; + NETRJS needs (at least) two mappings for each direction. How long + will it be before an important set of users appears with a different + terminal character set, requiring yet a different mapping? [6] An rje + server site needs to be prepared to provide a variety of translation + tables, and perhaps to allow a user to specify his own table(s); this + mini-subset of "Date Reconfiguration Service" might be necessary to + prevent translation-table-proliferation. The tendency in Network + discussions has been to put the burden upon the user sites to adapt + to different conventions. In the real world of users and servers, + the server will often have to do the adapting. + +NOTES AND REFERENCES + + [1] R.T. Braden, Interim NETRJS Specifications, RFC #189 (NIC + #7133), July 15, 1971. + + [2] Please note that "RJS" is the proper name of a particular rje + package written at CCN the generic name for remote batch + service is "rje". + + [3] Notice that the mapping question discussed in this RFC is + significant only for the virtual card reader and printer + connections in NETRJS. The punch connection is always + transparent, i.e., never translated. The remote operator + connections use the extended EBCDIC/ASCII mapping including + the maverick characters, but this is not important since + operator commands require only a limited character set. + + [4] Joel Winett, "_The_ EBCDIC Codes and their Mapping to ASCII", + RFC #183 (NIC #7127), July 21, 1971. + + + +Braden [Page 4] + +RFC 338 EBCDIC/ASCII MAPPING FOR NETWORK RJE May 1972 + + + [5] Winett lists only 88 basic EBCDIC graphics, excluding the + space which he regards as a control character. This is a + matter of taste, but we find it less confusing to include the + space as a graphic. + + [6] CCN recently received a new Teletype-replacement terminal. + This machine has a bastardized graphic character set -- mostly + ASCII, with a sprinkling of both (!) EBCDIC and TTY. + + + +-------------------------------------+ + | Full ASCII | + | a b ... z | ` ^ { } ~ | + | | + +-----+-------------------------------------+--------------+ + |33/35| | AT&T TWX | + | | ` [ ] | (Mod 33/35 | + | | | tty) | + +------+-----+------+-----------------------+ | | + |Basic | | | | | | + |EBCDIC| | | <SP> | | | + | | | " | A B ... Z | | <left arrow> | + | | | ! | 0 1 ... 9 | | | + | | | | + - * / ( ) | | <up arrow> | + | | | | . , ' = | | | + | | | | $ & | | | + | | | | < > : ? % # @ | | | + | | | | | | | + | +-----+------+-----------------------+------+--------------+ + | | | | | + | | | _ | | + | | | | | + | +------+-----------------------+------+ + | | | + | | PL/1 <bent bar> | | + | | Set | + | +-----------------------+ + | <cent sign> | + | Basic EBCDIC | + +-------------------------------------------+ + + Figure 1. Character Sets Commonly Abused + +[This RFC is also available in .PS and .PDF format.] + + [This RFC was put into machine readable form for entry] + [into the online RFC archives by Helene Morin, Viagenie, 12/99] + + + + +Braden [Page 5] + +RFC 338 EBCDIC/ASCII MAPPING FOR NETWORK RJE May 1972 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Braden [Page 6] + |