diff options
Diffstat (limited to 'doc/rfc/rfc138.txt')
| -rw-r--r-- | doc/rfc/rfc138.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc138.txt b/doc/rfc/rfc138.txt new file mode 100644 index 0000000..3968365 --- /dev/null +++ b/doc/rfc/rfc138.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group Bob Anderson +Request for Comments: 138 Rand +NIC 6715 Vint Cerf + UCLA + Eric Harslem + John Heafner + Rand + Jim Madden + U. of Illinois + Bob Metcalfe + MIT + Arie Shoshani + SDC + Jim White + UCSB + David Wood + Mitre + 28 April 1971 + + STATUS REPORT ON PROPOSED DATA RECONFIGURATION SERVICE + + CONTENTS + I. INTRODUCTION ................................. 2 + + Purpose of this RFC .......................... 2 + Motivation ................................... 2 + + II. OVERVIEW OF DATA RECONFIGURATION SERVICE ..... 3 + + Elements of Data Reconfiguration Service ..... 3 + Conceptual Network Connections ............... 3 + Connection Protocols and Message Formats ..... 4 + Example Connection Configurations ............ 6 + + III. THE FORM MACHINE ............................. 7 + + Input/Output Stream and Forms ................ 7 + Form Machine BNF Syntax ...................... 7 + Alternate Specification of Form Machine Syntax 8 + Forms ........................................ 9 + Rules ........................................ 10 + Terms ........................................ 10 + + Term Format 1 .............................. 11 + Term Format 2 .............................. 11 + Term Format 3 .............................. 13 + Term Format 4 .............................. 13 + Application of a Term ...................... 14 + + + +Anderson, et al. [Page 1] + +RFC 138 Data Reconfiguration Service April 1971 + + + Restrictions and Interpretations of + Term Functions ........................... 14 + Term and Rule Sequencing ..................... 16 + + IV. EXAMPLES ..................................... 16 + + Remarks ...................................... 16 + Field Insertion .............................. 17 + Deletion ..................................... 17 + Variable Length Records ...................... 17 + String Length Computation .................... 18 + Transposition ................................ 18 + Character Packing and Unpacking .............. 18 + + V. PROPOSED USES OF DATA RECONFIGURATION SERVICE 19 + + VI. IMPLEMENTATION PLANS ......................... 20 + + Appendix A ......................................... 21 + + Note 1 to the DRS Working Group .............. 21 + Note 2 to the DRS Working Group .............. 22 + +I. INTRODUCTION + + PURPOSE OF THIS RFC + + The purpose of this RFC is to describe, in part, a proposed Network + experiment and to solicit comments on any aspect of the experiment. + The experiment involves a software mechanism to reformat Network data + streams. The mechanism can be adapted to numerous Network + application programs. We hope that the results of the experiment + will lead to a further standard service that embodies the principles + described in this RFC. We would like comments on the + appropriateness of this work as a Network experiment and also + comments on particular Network data reformatting needs that could not + easily be accomplished using these techniques. + +MOTIVATION + + Application programs require specific data I/O formats yet the + formats are different from program to program. We take the position + that the Network should adapt to the individual program requirements + rather than changing each program to comply with a standard. This + position doesn't preclude the use of standards that describe the + formats of regular message contents; it is merely an interpretation + of a standard as being a desirable mode of operation but not a + necessary one. + + + +Anderson, et al. [Page 2] + +RFC 138 Data Reconfiguration Service April 1971 + + + In addition to differing program requirements, a format mismatch + problem occurs where users wish to employ many different kinds of + consoles to attach to a single service program. It is desirable to + have the Network adapt to individual console configurations rather + than requiring unique software packages for each console + transformation. + + One approach to providing adaptation is for those sites with + substantial computing power to offer a data reconfiguration service; + a proposed example of such a service is described here. + + The envisioned modus operandi of the service is that an applications + programmer defines _forms_ that describe data reconfigurations. The + service stores the forms by name. At a later time, a user (perhaps a + non-programmer) employs the service to accomplish a particular + transformation of a Network data stream, simply by calling the form + by name. + + We have attempted to provide a notation tailored to some specifically + needed instances of data reformatting while keeping the notation and + its underlying implementation within some utility range that is + bounded on the lower end by a notation expressive enough to make the + experimental service useful, and that is bounded on the upper end by + a notation short of a general purpose programming language. + + +II. OVERVIEW OF THE DATA RECONFIGURATION SERVICE + +ELEMENTS OF THE DATA RECONFIGURATION SERVICE + + An implementation of the Data Reconfiguration Service (DRS) includes + modules for connection protocols, a handler of some requests that can + be made of the service, a compiler and/or interpreter (called the + Form Machine) to act on those requests, and a file storage module for + saving and retrieving definitions of data reconfigurations (forms). + This section highlights connection protocols and requests. The next + section covers the Form Machine language in some detail. File + storage is not described in this document because it is transparent + to the use of the service and its implementation is different at each + DRS host. + +CONCEPTUAL NETWORK CONNECTIONS + + There are three conceptual Network connections to the DRS, see Fig. + 1. + + 1) The control connection (CC) is between an originating user + and the DRS. A form specifying data reconfiguration is + + + +Anderson, et al. [Page 3] + +RFC 138 Data Reconfiguration Service April 1971 + + + defined over this connection and is applied to data passing + over the two connections described below. + 2) The user connection (UC) is between a user process and the + DRS. + 3) The server connection (SC) is between the DRS and the + serving process. + + Since the goal is to adapt the Network to user and server processes, + a minimum of requirements are imposed on the UC and SC. + + + +-------------+ CC +-----------+ SC +-----------+ + | ORIGINATING +--------+ DRS +--------+ SERVER | + | USER | ^ | | ^ | PROCESS | + +-------------+ | +------+----+ | +-----------+ + | / | + Telnet / <------ Simplex or Duplex + Protocol UC/ Connections + Connection / + / + +-----+-----+ + | USER | + | PROCESS | + +-----------+ + + Figure 1. DRS Network Connections + + +CONNECTION PROTOCOLS AND MESSAGE FORMATS + + Over a control connection the dialog is directly between an + originating user and the DRS. Here the user is defining forms or + assigning forms to connections for reformatting. + + The user connects to the DRS via the initial connection protocol + (ICP) specified in NWG/RFC #80, version 1. Rather than going through + a logger, the user calls on a particular socket on which the DRS + always listens. DRS switches the user to another socket pair. + + Messages sent over a control connection are of the types and formats + to be specified for TELNET. Thus, a user at a terminal should be + able to connect to a DRS via his local TELNET, for example, as shown + in Fig. 2. + + + + + + + + +Anderson, et al. [Page 4] + +RFC 138 Data Reconfiguration Service April 1971 + + + +--------------+ + +--------+ CC | | + +-------+ TELNET +-------+ DRS | + | +--------+ | | + | +--------------+ + +----------+---------+ + | USER | + |(TERMINAL OR PROGRAM| + +--------------------+ + + Figure 2. A TELNET Connection to DRS + + When a user connects to DRS he supplies a six-character user ID (UID) + as a qualifier to guarantee the uniqueness of his form names. He + will have (at least) the following commands: + + 1. DEFFORM (name) + 2. ENDFORM (name) + + These two commands define a form, the text of which is + chronologically entered between them. The (name) is six + characters. The form is stored in the DRS local file + system. + + 3. PURGE (name) + + The named form, as qualified by the current UID, is purged + from the DRS file system. + + 4. LISTNAMES (UID) + + The unqualified names of all forms assigned to UID are + returned. + + 5. LISTFORM (name) + + The source text of a named form is returned. + + 6. DUPLEXCONNECT (user site, user send, user receive, + user method, server site, server + send, server receive, server method, + user-to-server form, server-to-user form) + + 7. SIMPLEXCONNECT (send site, send socket, send + method, receive site, receive + socket, receive method, form) + + + + + +Anderson, et al. [Page 5] + +RFC 138 Data Reconfiguration Service April 1971 + + + Either one, both, or neither of the two parties specified in 6 or 7 + may be at the same host as the party issuing the request. Sites and + sockets specify user and server for the connection. Method indicates + the way in which the connection is established. Three options are + provided: + 1) Site/socket already connected to DRS as a dummy + control connection. (A dummy control connection + should not also be the real control connection.) + 2) Connect via standard ICP. (Only for command no. 6.) + 3) Connect directly via STR, RTS. + +EXAMPLE CONNECTION CONFIGURATIONS + + There are basically two modes of DRS operation: 1) the user wishes to + establish a DRS UC/SC connection(s) between two programs and 2) the + user wants to establish the same connection(s) where he (his + terminal) is at the end of the UC or the SC. The latter case is + appropriate when the user wishes to interact from his terminal with + the serving process (e.g., a logger). + + In the first case (Fig. 1, where the originating user is either a + terminal or a program) the user issues the appropriate CONNECT + command. The UC/SC can be simplex or duplex. + + The second case has two possible configurations, shown in Figs. 3 and + 4. + + +--------+ CC +--------+ +------+ + | +------+ | SC | | + +------+ /| TELNET | UC | DRS +------+ SP | + | |/ | +------+ | | | + | USER | /+--------+ +--------+ +------+ + | |/ + +------+ + + Figure 3. Use of Dummy Control Connection + + +--------+ + +------+ /| USER | CC +--------+ +------+ + | |/ | SIDE +------+ | SC | | + | USER | +--------+ UC | DRS +------+ SP | + | |\ | SERVING+------+ | | | + +------+ \| SIDE | +--------+ +------+ + +--------+ + + Figure 4. Use of Server TELNET + + + + + +Anderson, et al. [Page 6] + +RFC 138 Data Reconfiguration Service April 1971 + + + In Fig. 3 the user instructs his TELNET to make two duplex + connections to DRS. One is used for control information (the CC) and + the other is a dummy. When he issues the CONNECT he references the + dummy duplex connection (UC) using the "already connected" option. + + In Fig. 4 the user has his TELNET (user side) call the DRS. When he + issues the CONNECT the DRS calls the TELNET (server side) which + accepts the call on behalf of the console. This distinction is known + only to the user since to the DRS the configuration in Fig. 4 appears + identical to that in Fig. 1. Two points should be noted: + + 1) TELNET protocol is needed only to define forms and direct + connections. It is not required for the using and serving + processes. + 2) The using and serving processes need only a minimum of + modification for Network use, i.e., an NCP interface. + + +III. THE FORM MACHINE + +INPUT/OUTPUT STREAMS AND FORMS + + This section describes the syntax and semantics of forms that specify + the data reconfigurations. The Form Machine gets an input stream, + reformats the input stream according to a form describing the + reconfiguration, and emits the reformatted data as an output stream. + + In reading this section it will be helpful to envision the + application of a form to the data stream as depicted in Fig. 5. An + input stream pointer identifies the position of data (in the input + stream) that is being analyzed at any given time by a part of the + form. Likewise, an output stream pointer locates data being emitted + in the output stream. + + + /\/\ /\/\ + ^ | | FORM | | ^ + | | | ----------------- | | | + | | | +- ----------------- -+ | | | + | | | | CURRENT PART OF | | | | +INPUT | |<= CURRENT < ----------------- > CURRENT => | | OUTPUT +STREAM | | POINTER | FORM BEING APPLIED | POINTER | | STREAM + | | +- ----------------- -+ | | + | | ----------------- | | + | | ----------------- | | + | | ----------------- | | + \/\/ \/\/ + Figure 5. Application of Form to Data Streams + + + +Anderson, et al. [Page 7] + +RFC 138 Data Reconfiguration Service April 1971 + + +FORM MACHINE BNF SYNTAX + + form ::= rule | rule form + + rule ;;= label inputstream outputstream ; + + label ::= INTEGER | <null> + + inputstream ::= terms | <null> + + terms ::= term | terms , term + + outputstream ::= : terms | <null> + + term ::= identifier | identifier descriptor | + descriptor | comparator + + identifier ::= an alpha character followed by 0 to 3 + alphamerics + + descriptor ::= (replicationexpression , datatype , + valueexpression , lengthexpression control) + + comparator ::= (value connective value control) | + (identifier .<=>. control) + + replicationexpression ::= arithmeticexpression | <null> + + datatype ::= B | O | X | E | A + + valueexpression ::= value | <null> + + lengthexpression ::= # | arithmeticexpression | <null> + + connective ::= .LE. | .LT. | .GE. | .GT. | .EQ. | .NE. + + value ::= literal | arithmeticexpression + + arithmeticexpression ::= primary | primary operator + arithmeticexpression + + primary ::= identifier | L(identifier) | V(identifier) | + INTEGER + + operator ::= + | - | * | / + + literal ::= literaltype "string" + + + + +Anderson, et al. [Page 8] + +RFC 138 Data Reconfiguration Service April 1971 + + + literaltype ::= B | O | X | E | A + + string ::= from 0 to 256 characters + + control ::= : options | <null> + + options ::= S(where) | F(where) | U(where) | + S(where) , F(where) | + F(where) , S(where) + + where ::= arithmeticexpression | R(arithmeticexpression) + + + +ALTERNATE SPECIFICATION OF FORM MACHINE SYNTAX + + infinity +form ::= {rule} + 1 + 1 1 1 +rule ::= {INTEGER} {terms} {:terms} ; + 0 0 0 + infinity +terms ::= term {,term} + 0 + 1 +term ::= identifier | {identifier} descriptor + 0 + | comparator + 1 +descriptor ::= ({arithmeticexpression} , datatype , + 0 + 1 1 1 + {value} , {lengthexpression} {:options} + 0 0 0 + 1 +comparator ::= (value connective value {:options} ) | + 0 + 1 + (identifier .<=. value {:options} ) + 0 +connective ::= .LE. | .LT. | .GE. | .GT. | .EQ. | .NE. + +lengthexpression ::= # | arithmeticexpression + +datatype ::= B | O | X | E | A + +value ::= literal | arithmeticexpression + + + +Anderson, et al. [Page 9] + +RFC 138 Data Reconfiguration Service April 1971 + + + infinity +arithmeticexpression ::= primary {operator primary} + 0 +operator ::= + | - | * | / + +primary ::= identifier | L(identifier) | + V(identifier) | INTEGER + 256 +literal ::= literaltype "{CHARACTER} " + 0 +literaltype ::= B | O | X | A | E + 1 +options ::= S(where) {,F(where)} | + 0 + 1 + F(where) {,S(where)} | U(where) + 0 + +where ::= arithmeticexpression | + R(arithmeticexpression) + 3 +identifier ::= ALPHABETIC {ALPHAMERIC} + 0 + +FORMS + + A form is an ordered set of rules. + + form ::= rule | rule form + + The current rule is applied to the current position of the input + stream. If the (input stream part of a) rule fails to correctly + describe the contents of the current input then another rule is made + current and applied to the current position of the input stream. The + next rule to be made current is either explicitly specified by the + current term in the current rule or it is the next sequential rule by + default. Flow of control is more fully described under TERM AND RULE + SEQUENCING. + + If the (input stream part of a) rule succeeds in correctly describing + the current input stream, then some data may be emitted at the + current position in the output stream according to the rule. The + input and output stream pointers are advanced over the described and + emitted data, respectively, and the next rule is applied to the now + current position of the input stream. + + Application of the form is terminated when an explicit return + (R(arithmeticexpression)) is encountered in a rule. The user and + + + +Anderson, et al. [Page 10] + +RFC 138 Data Reconfiguration Service April 1971 + + + server connections are closed and the return code + (arithmeticexpression) is sent to the originating user. + +RULES + + A rule is a replacement, comparison, and/or an assignment operation + of the form shown below. + + rule ::= label inputstream outputstream ; + + A label is the name of a rule and it exists so that the rule may be + referenced elsewhere in the form for explicit rule transfer of + control. Labels are of the form below. + + label ::= INTEGER | <null> + + The optional integer labels are in the range 0 >= INTEGER >= 9999. + The rules need not be labeled in ascending numerical order. + +TERMS + + The inputstream (describing the input stream to be matched) and the + outputstream (describing data to be emitted in the output stream) + consist of zero or more terms and are of the form shown below. + + inputstream ::= terms | <null> + outputstream ::= :terms | <null> + terms ::= term | terms , term + + Terms are of one of four formats as indicated below. + + term ::= identifier | identifier descriptor | + descriptor | comparator + +Term Format 1 + + The first term format is shown below. + + identifier + + The identifier is a symbolic reference to a previously identified + term (term format 2) in the form. It takes on the same attributes + (value, length, type) as the term by that name. Term format 1 is + normally used to emit data in the output stream. + + Identifiers are formed by an alpha character followed by 0 to 3 + alphameric characters. + + + + +Anderson, et al. [Page 11] + +RFC 138 Data Reconfiguration Service April 1971 + + +Term Format 2 + + The second term format is shown below. + + identifier descriptor + + Term format 2 is generally used as an input stream term but can be + used as an output stream term. + + A descriptor is defined as shown below. + + descriptor ::= (replicationexpression, datatype, + valueexpression, lengthexpression + control) + + The identifier is the symbolic name of the term in the usual + programming language sense. It takes on the type, length, and value + attributes of the term and it may be referenced elsewhere in the + form. + + The replication expression is defined below. + + replicationexpression ::= arithmeticexpression | <null> + arithmeticexpression ::= primary | primary operator + arithmeticexpression + operator ::= + | - | * | / + primary ::= identifier | L(identifier) | V(identifier) | + INTEGER + + The replication expression is a repeat function applied to the + combined data type and value expression. It expresses the number of + times that the value (of the data type/value expression) is to be + repeated within the field length denoted by the data type/length + expression. + + A null replication expression has the value of one. Arithmetic + expressions are evaluated from left-to-right with no precedence. (It + is anticipated that this interpretation might be changed, if + necessary.) + + The L(identifier) is a length operator that generates a 32-bit binary + integer corresponding to the length of the term named. The + V(identifier) is a value operator that generates a 32-bit binary + integer corresponding to the value of the term named. (See + Restrictions and Interpretations of Term Functions.) The value + operator is intended to convert character strings to their numerical + correspondents. + + + + +Anderson, et al. [Page 12] + +RFC 138 Data Reconfiguration Service April 1971 + + + The data type is defined below. + + datatype ::= B | O | X | E | A + + The data type describes the kind of data that the term represents. + (It is expected that additional data types, such as floating point + and user-defined types, will be added as needed.) + + Data Type Meaning Unit Length + + B Bit string 1 bit + O Bit string 3 bits + X Bit string 4 bits + E EBCDIC character 8 bits + A Network ASCII character 8 bits + + The value expression is defined below. + + valueexpression ::= value | <null> + value ::= literal | arithmeticexpression + literal ::= literaltype "string" + literaltype ::= B | O | X | E | A + + The value expression is the unit value of a term expressed in the + format indicated by the data type. It is repeated according to the + replication expression, in a field whose length is constrained by the + length expression. + + A null value expression in the input stream defaults to the data + present in the input stream. The data must comply with the datatype + attribute, however. + + A null value expression generates padding according to Restrictions + and Interpretations of Term Functions. + + The length expression is defined below. + + lengthexpression ::= # | arithmeticexpression | <null> + + The length expression states the length of the field containing the + value expression as expanded by the replication expression. If the + value of the length expression is less then the length implied by the + expanded value expression, then the expanded value expression is + truncated, see Restrictions and Interpretations of Term Functions. + + The terminal symbol # means an arbitrary length, explicitly + terminated by the value of the next term. The # is legal only in the + input stream and not in the output stream. + + + +Anderson, et al. [Page 13] + +RFC 138 Data Reconfiguration Service April 1971 + + + If the length expression is less than or equal to zero, the term + succeeds but the appropriate stream pointer is not advanced. + Positive lengths cause the appropriate stream pointer to be advanced + if the term otherwise succeeds. + + Control is defined under TERM AND RULE SEQUENCING. + +Term Format 3 + + Term format 3 is shown below. + + descriptor + + It is identical to term format 2 with the omission of the identifier. + Term format 3 is generally used in the output stream. It is used in + the input stream where input data is to be passed over but not + retained for emission or later reference. + +Term Format 4 + + The fourth term format is shown below. + + comparator ::= (value connective value control) | + (identifier .<=. value control) + value ::= literal | arithmeticexpression + literal ::= literaltype "string" + literaltype ::= B | O | X | E | A + string ::= from 0 to 256 characters + connective ::= .LE. | .LT. | .GE. | .GT. | .EQ. | .NE. + + The fourth term format is used for assignment and comparison. + + The assignment operator .<=. assigns the value to the identifier. + The connectives have their usual meaning. Values to be compared must + have the same type and length attributes or an error condition arises + and the form fails. + +The Application of a Term + + The elements of a term are applied by the following sequence of + steps. + + 1. The data type and value expression together specify a unit + value, call it x. + + 2. The replication expression specifies the number of times x + is to be repeated (or copied) in concatenated fashion. The + value of the concatenated xs becomes, say, y of length L1. + + + +Anderson, et al. [Page 14] + +RFC 138 Data Reconfiguration Service April 1971 + + + 3. The data type and the length expression together specify a + field length of the input area (call it L2) that begins at + the current stream pointer position. + + 4. The value of y is truncated to y' if L1 > L2. Call the + truncated length L1'. + + 5. If the term is an input stream term, then the value y' of + length L1' is compared to the input value beginning at the + current input pointer position. + + 6. If the values are identical over the length L1' then the + input value of length L2 (may be greater than L1') starting + at the current pointer position in the input area, becomes + the value of the term. + + In an output stream term, the procedure is the same except that the + source of input is the value of the term(s) named in the value + expression and the data is emitted in the output stream. + + The above procedure is modified to include a one term look-ahead + where lengths are indefinite because of the arbitrary symbol, #. + +Restrictions and Interpretations of Term Functions + + 1. Terms specifying indefinite lengths, through the use of the # + symbol must be separated by some type-specific data such as a + literal. (A literal isn't specifically required, however. An + arbitrary number of ASCII characters could be terminated by a + non-ASCII character.) # is legal only in the input stream, not + in the output stream. + + 2. Truncation and padding is as follows: + a) Character to character (A <--> E) conversion is left + justified and truncated or padded on the right with blanks. + b) Character to numeric and numeric to numeric conversions are + right-justified and truncated or padded on the left with + zeros. + c) Numeric to character conversion is right-justified and + left-padded with blanks. + + 3. The following are ignored in a form definition over the control + connection. + a) TAB, carriage return, etc. + b) blanks except within quotes. + c) /* string */ is treated as comments except within quotes. + + 4. The following defaults prevail where the term part is omitted. + + + +Anderson, et al. [Page 15] + +RFC 138 Data Reconfiguration Service April 1971 + + + a) The replication expression defaults to one. + b) The data type defaults to type B. + c) The value expression of an input stream term defaults to + the value found in the input stream, but the input stream + must conform to data type and length expression. The value + expression of an output stream term defaults to padding + only. + d) The length expression defaults to the size of the quantity + determined by replication expression, data type, and value + expression. + e) Control defaults to the next sequential term if a term is + successfully applied; else control defaults to the next + sequential rule. If _where_ evaluates to an undefined + _label_ the form fails. + + 5. Arithmetic expressions are evaluated left-to-right with no + precedence. + + 6. The following limits prevail. + + a) Binary lengths are <= 32 bits + b) Character strings are <= 256 8-bit characters + c) Identifier names are <= 4 characters + d) Maximum number of identifiers is <= 256 + e) Label integers are >= 0 and <= 9999 + + 7. Value and length operators product 32-bit binary integers. The + value operator is currently intended for converting A or E type + decimal character strings to their binary correspondents. For + example, the value of E'12' would be 0......01100. The value + of E'AB' would cause the form to fail. + + + + + + + + + + + + + + + + + + + + +Anderson, et al. [Page 16] + +RFC 138 Data Reconfiguration Service April 1971 + + +TERM AND RULE SEQUENCING + + Sequencing may be explicitly controlled by including control in a + term. + + control ::= :options | <null> + options ::= S(where) | F(where) | U(where) + S(where) , F(where) | + F(where) , S(where) + + where ::= arithmeticexpression | R(arithmeticexpression) + + S, F, and U denote success, fail, and unconditional transfers, + respectively. _Where_ evaluates to a _rule_ label, thus transfer can + be effected from within a rule (at the end of a term) to the + beginning of another rule. R means terminate the form and return the + evaluated expression to the initiator over the control connection (if + still open). + + If terms are not explicitly sequenced, the following defaults + prevail. + + 1) When a term fails go to the next sequential rule. + 2) When a term succeeds go to the next sequential + term within the rule. + (3) At the end of a rule, go to the next sequential + rule. + + Note in the following example, the correlation between transfer of + control and movement of the input pointer. + + 1 XYZ(,B,,8:S(2),F(3)) : XYZ ; + 2 . . . . . . . + 3 . . . . . . . + + The value of XYZ will never be emitted in the output stream since + control is transferred out of the rule upon either success or + failure. If the term succeeds, the 8 bits of input will be assigned + as the value of XYZ and rule 2 will then be applied to the same input + stream data. That is, since the complete rule 1 was not successfully + applied, then the input stream pointer is not advanced. + + + + + + + + + + +Anderson, et al. [Page 17] + +RFC 138 Data Reconfiguration Service April 1971 + + +IV. EXAMPLES + +REMARKS + + The following examples (forms and also single rules) are simple + representative uses of the Form Machine. The examples are expressed + in a term-per-line format only to aid the explanation. Typically, a + single rule might be written as a single line. + +FIELD INSERTION + + To insert a field, separate the input into the two terms to allow the + inserted field between them. For example, to do line numbering for a + 121 character/line printer with a leading carriage control character, + use the following form. + + (NUMB.<=>.1); /*initialize line number counter to one*/ + 1 CC(,E,,1:F(R(99))), /*pick up control character and save + as CC*/ + /*return a code of 99 upon exhaustion*/ + LINE(,E,,121 : F(R(98))) /*save text as LINE*/ + :CC, /*emit control character*/ + (,E,NUMB,2), /*emit counter in first two columns*/ + (,E,E".",1), /*emit period after line number*/ + (,E,LINE,117), /*emit text, truncated in 117 byte field*/ + (NUMB.<=.NUMB+1:U(1)); /*increment line counter and go to + rule one*/;; + +DELETION + + Data to be deleted should be isolated as separate terms on the left, + so they may be omitted (by not emitting them) on the right. + + (,B,,8), /*isolate 8 bits to ignore*/ + SAVE(,A,,10) /*extract 10 ASCII characters from + input stream*/ + :(,E,SAVE,); /*emit the characters in SAVE as EBCDIC + characters whose length defaults to the + length of SAVE, i.e., 10, and advance to + the next rule*/ + + In the above example, if either input stream term fails, + the next sequential rule is applied. + +VARIABLE LENGTH RECORDS + + Some devices, terminals and programs generate variable length + records. To following rule picks up variable length EBCDIC records + + + +Anderson, et al. [Page 18] + +RFC 138 Data Reconfiguration Service April 1971 + + + and translates them to ASCII. + + CHAR(,E,,#), /*pick up all (an arbitrary number of) + EBCDIC characters in the input stream*/ + (,X,X"FF",2) /*followed by a hexadecimal literal, + FF (terminal signal)*/ + :(,A,CHAR,), /*emit them as ASCII*/ + (,X,X"25",2); /*emit an ASCII carriage return*/ + +STRING LENGTH COMPUTATION + + It is often necessary to prefix a length field to an arbitrarily long + character string. The following rule prefixes an EBCDIC string with + a one-byte length field. + + Q(,E,,#), /*pick up all EBCDIC characters*/ + TS(,X,X"FF",2) /*followed by a hexadecimal literal, FF*/ + :(,B,L(Q)+2,8), /*emit the length of the characters + plus the length of the literal plus + the length of the count field itself, + in an 8-bit field*/ + Q, */emit the characters*/ + TS; */emit the terminal*/ + +TRANSPOSITION + + It is often desirable to reorder fields, such as the following + example. + + Q(,E,,20), R(,E,,10) , S(,E,,15), T(,E,,5) : R, T, S, Q ; + + The terms are emitted in a different order. + +CHARACTER PACKING AND UNPACKING + + In systems such as HASP, repeated sequences of characters are packed + into a count followed by the character, for more efficient storage + and transmission. The first form packs multiple characters and the + + + + + + + + + + + + + +Anderson, et al. [Page 19] + +RFC 138 Data Reconfiguration Service April 1971 + + + second unpacks them. + /*form to pack EBCDIC streams*/ + /*returns 99 if OK, input exhausted*/ + /*returns 98 if illegal EBCDIC*/ + /*look for terminal signal FF which is not a legal EBCDIC*/ + /*duplication count must be 0-254*/ + 1 (,X,X"FF",2 : S(R(99))) ; + /*pick up the EBCDIC and initialize count/* + CHAR(,E,,1 : F(R(98))) , (CNT .<=. 1) ; + /*count consecutive EBCDICs like CHAR*/ + 2 (,E,CHAR,1 : F(3)) , (CNT .<=. CNT+1 : U(2)) ; + /*emit count and current character*/ + 3 : (,B,CNT,8), CHAR, (:U(1)); + /*end of form*/;; + + /*form to unpack EBCDIC streams*/ + /*look for terminal*/ + 1 (,X,X"FF",2 : S(R(99))) ; + /*emit character the number of times indicated*/ + /*by the counter contents*/ + CNT(,B,,8), CHAR(,E,,1) : (CNT,E,CHAR,CNT:U(1)); + /*failure of form*/ + (:U(R(98))) ;; + + +V. PROPOSED USES OF DATA RECONFIGURATION SERVICE + + The following are some proposed uses of the DRS that were submitted + by the sites indicated. + + UCLA + 1. Pack/unpack text files. + 2. Preprocessor to scan META compiler input. + 3. Perhaps graphics. + + MIT + 1. Reformatting within file transfer service. + 2. Character conversions. + 3. Possible graphics service (Evans and Sutherland output + format). + 4. Reformat arguments of subroutines remote to each other. + + U. OF ILLINOIS + 1. Dependent upon remote use of DRS for many remote + services. + + SDC + 1. Would be essential to data transfer in general. + + + +Anderson, et al. [Page 20] + +RFC 138 Data Reconfiguration Service April 1971 + + + 2. Could be used in relation to data management language. + + UCSB + 1. Checkout of I/O formats of file system. + 2. Debugging Network services in general. + 3. Mapping their services into future standards. + + RAND + 1. To describe RJO/RJE message formats at UCSB. + 2. To describe RJS message formats at UCLA. + 3. To adapt Network to existing services, in general. + + MITRE + 1. Character conversions. + 2. Testing data formats going into data bases for correct + field formatting. + + VI. IMPLEMENTATION PLANS + + Four sites currently plan to implement and offer the service on an + experimental basis. + + 1. MIT Implementation of forms interpreter in MIDAS + (assembly). Perhaps Tree Meta compiler of + forms. Implementation on PDP-10. + + 2. UCLA Implementation on SIGMA-7 employing META-7 + to compile forms. + + 3. UCSB Implementation on 360/75. + + 4. RAND Initial implementation on 360/65; compiler to be written + in graphics CPS; compiled intermediate forms to be + interpreted by assembler language subroutine. Later + implemented on PDP-10. + + In addition to the above sites, the University of Illinois and Mitre + plan to experiment with the service. + + + + + + + + + + + + + +Anderson, et al. [Page 21] + +RFC 138 Data Reconfiguration Service April 1971 + + + APPENDIX A + +Note 1 to the DRS Working Group + + As you recall, we spent considerable time in discussing the use and + meaning of the arbitrary symbol, #. To summarize, it was clear that + inclusion of the # in both replication and length expressions led to + ambiguities. We settled on its restricted use in the length + expression of an input term, although no one was entirely satisfied + with this definition. + + Recently, Jim White has again commented on the #. Jim feels that it + is curious that one can pick up an arbitrary number of EBCDIC + characters, for example, but can't pick up an arbitrary number of + specific EBCDIC characters such as EBCDIC A's. Jim feels that a more + natural way to interpret the length, value, and replication + expressions would be as the IBM OS assembler interprets the + attributes of the pseudo instruction, define constant (CD). + + The IBM OS assembler uses the following format. + + 1 2 3 4 + duplication type modifiers nominal value + factor + + The duplication factor, if specified, causes the constant to be + generated the number of times indicated by the factor. The type + defines the type of constant being specified. Modifiers describe the + length, scaling, and exponent of the constant. Nominal value + supplies the constant described by the subfields that precede it. + + Assume that we use the # only as a duplication factor (replication + expression). Hence, in the example of the form to pack EBCDIC + characters, the counter and looping can be eliminated. + + CHAR(,E,,1) ; + LEN(#,#,CHAR,1) : (,B,L(LEN)+1,*) , CHAR ; + + The interpretation is that the data type, length expression, and + value expression make up the unit value. This quantity can then be + replicated. As our document now stands, only the data type and value + expression make up the unit value. + + The application of a term according to Jim's suggestion is as + follows. + 1. The data type, value expression, and length expression together + specify a unit value, call it x. + + + + +Anderson, et al. [Page 22] + +RFC 138 Data Reconfiguration Service April 1971 + + + 2. The replication expression specifies the number of times x is to + be repeated. The value of the concatenated xs becomes y of + length L. + 3. If the term is an input stream term then the value beginning at + the current input pointer position. + 4. If the input value satisfies the constraints of y over length L + then the input value of length L becomes the value of the term. + +Note 2 to the DRS Working Group + + There has been recent debate of whether the input pointer should be + advanced upon successful completion of a rule (as it now is defined) + or upon successful completion of each term. See the example on page + 22. If the input pointer is advanced upon successful completion of a + term, then rules become equivalent to terms. + + I would like to for us to discuss at the SJCC both the term + attributes and the input pointer advance issues. + + John + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Katsunori Tanaka 4/99 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + +Anderson, et al. [Page 23] + |