From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc166.txt | 1123 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc166.txt (limited to 'doc/rfc/rfc166.txt') diff --git a/doc/rfc/rfc166.txt b/doc/rfc/rfc166.txt new file mode 100644 index 0000000..599bcde --- /dev/null +++ b/doc/rfc/rfc166.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group Bob Anderson +Request for Comments: 166 Rand +NIC 6780 Vint Cerf + UCLA + Eric Harslem + John Haefner + Rand + Jim Madden + U. of Illinois + Bob Metcalfe + MIT + Arie Shoshani + SDC + Jim White + UCSB + David Wood + Mitre + 25 May 1971 + + DATA RECONFIGURATION SERVICE -- AN IMPLEMENTATION SPECIFICATION + + CONTENTS + + I. INTRODUCTION ................................... 2 + + Purpose of this RFC ............................ 2 + Motivation ..................................... 2 + + II. OVERVIEW OF THE DATA RECONFIGURATION SERVICE ... 3 + + Elements of the Data Reconfiguration SERVICE ... 3 + Conceptual Network Connections ................. 3 + Conception Protocols and Message Formats ....... 4 + Example Connection Configurations .............. 7 + + III. THE FORM MACHINE ............................... 8 + + Input/Output Streams and Forms ................. 8 + Form Machine BNF Syntax ........................ 8 + Alternate Specification of Form Machine Syntax . 9 + Forms .......................................... 10 + Rules .......................................... 10 + Terms .......................................... 11 + + Term Format 1 ................................ 11 + Term Format 2 ................................ 11 + Term Format 3 ................................ 14 + Term Format 4 ................................ 14 + + + +Anderson, et al. [Page 1] + +RFC 166 Data Reconfiguration Service May 1971 + + + The Application of a Term .................... 14 + Restrictions and Interpretations of Term + Functions .................................. 15 + + Term and Rule Sequencing ..................... 16 + + IV. EXAMPLES ....................................... 17 + + Remarks ........................................ 17 + Field Insertion ................................ 17 + Deletion ....................................... 17 + Variable Length Records ........................ 18 + String Length Computation ...................... 18 + Transposition .................................. 18 + Character Packing and Unpacking ................ 18 + + + I. INTRODUCTION + +PURPOSE OF THIS RFC + + The Purpose of this RFC is to specify the Data Reconfiguration + Service (DRS.) + + The DRS experiment involves a software mechanism to reformat Network + data streams. The mechanism can be adapted to numerous Network + application programs. We hope that the result of the experiment will + lead to a future standard service that embodies the principles + described in this RFC. + + +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. + + 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. + + + +Anderson, et al. [Page 2] + +RFC 166 Data Reconfiguration Service May 1971 + + + One approach to providing adaptation is for those sites with + substantial computing power to offer a data reconfiguration service; + this document is a specification of such a service. + + 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 describes 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 an 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. Forms specifying data reconfigurations are + defined over this connection. The user indicates (once) + forms to be applied to data passing over the two + connections described below. + + 2) The user connection (UC) is between a user process and the + DRS. + + + +Anderson, et al. [Page 3] + +RFC 166 Data Reconfiguration Service May 1971 + + + 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. + + +------------+ +------+ +---------+ + | ORIGINATING| CC | DRS | SC | SERVER | + | USER |--------------| |----------| PROCESS | + +------------+ ^ +------+ ^ +---------+ + | / | + | UC/ <-----\ | + | / \ | + | +-----------+ \| + TELNET ---------+ | USER | +-- Simplex or Duplex + Protocol | PROCESS | Connections + Connection +-----------+ + + + 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 predefined forms to connections for reformatting. + + The user connects to the DRS via the standard initial connection + protocol (ICP). Rather than going through a logger, the user calls + on a particular socket on which the DRS alway listens. (Experimental + socket numbers will be published later.) DRS switches the user to + another socket pair. + + Messages sent over a control connection are of the types and formats + specified for TELNET. (The data type code should specify ASCII -- + the default.) 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. + + +---------+ CC +---------+ + +---------| TELNET |-------| DRS | + | +---------+ +---------+ + +-----------------------+ + | USER | + | (TERMINAL OR PROGRAM) | + +-----------------------+ + + Figure 2. A TELNET Connection to DRS + + + +Anderson, et al. [Page 4] + +RFC 166 Data Reconfiguration Service May 1971 + + + 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 initially have the following commands: + + 1. DEFFORM (form) + 2. ENDFORM (form) + + These two commands define a form, the text of which is + chronologically entered between them. The form is stored + in the DRS local file system. + + 3. PURGE (form) + + 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 (form) + + The source text of a named form is returned. + + 6. DUPLEXCONNECT (user site, user receive socket, user method, + server site, server receive socket, server method, user- + to-server form name, server-to-user form name) + + A duplex connection is made between two processes using the + receive sockets and the sockets one greater. Method is + defined below. The forms define the transformations on + these connections. + + 7. SIMPLEXCONNECT (user site, user socket, user method, server + site, server socket, server method, form) + + A simplex connection is made between the two sockets as + specified by method. + + 8. ABORT (site, receive socket) + + The reconfiguration of data is terminated by closing both + the UC and SC specified in part in the command. + + 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 + + + +Anderson, et al. [Page 5] + +RFC 166 Data Reconfiguration Service May 1971 + + + the way in which the connection is established. + + The following rules apply to these commands: + + 1) Commands may be abbreviated to the minimum number of + characters to identify them uniquely. + + 2) All commands should be at the start of a line. + + 3) Parameters are enclosed in parentheses and separated by + commas. + + 4) Imbedded blanks are ignored. + + 5) The parameters are: + + form name 1-6 characters + UID 1-6 characters + Site 1-2 characters specifying + the hexadecimal host number + Socket 1-8 characters specifying the + hexadecimal socket number + Method A single character + + 6) Method has the following values: + + C The site/socket is already connected + to the DRS as a dummy control connection + (should not be the real control connection). + I Connect via the standard ICP (does not + apply to SIMPLEXCONNECT). + D Connect directly via STR, RTS. + + The DRS will make at least the following minimal + responses to the user: + + 1) A positive or negative acknowledgement after + each line (CR/LF) + 2) If a form fails or terminates + TERMINATE, ASCII Host # as hex, ASCII Socket # as hex, + ASCII Return Code as decimal + thus identifying at least one end of the connection. + + + + + + + + + +Anderson, et al. [Page 6] + +RFC 166 Data Reconfiguration Service May 1971 + + +EXAMPLE CONNECTION CONFIGURATIONS + + There are basically two modes of DRS operation: 1) the user wishes to + establish a DRS UC/SC connection(s) between the 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 | | + | USER | | TELNET | UC | DRS |--------| SP | + | |----| |---------| | | | + +-------+ +--------+ +-----+ +----+ + + Figure 3. Use of Dummy Control Connection + + +---------+ + +------+ /| USER | CC +-----+ + | |---/ | SIDE |--------| | SC +----+ + | USER | +---------+ UC | DRS |--------| SP | + | |---\ | SERVING |--------| | +----+ + +------+ \| SIDE | +-----+ + +---------+ + + Figure 4. Use of Server TELNET + + 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 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 + + + +Anderson, et al. [Page 7] + +RFC 166 Data Reconfiguration Service May 1971 + + + 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 8] + +RFC 166 Data Reconfiguration Service May 1971 + + +FORM MACHINE BNF SYNTAX + + form ::= rule | rule form + + rule ;;= label inputstream outputstream ; + + label ::= INTEGER | + + inputstream ::= terms | + + terms ::= term | terms , term + + outputstream ::= : terms | + + term ::= identifier | identifier descriptor | + descriptor | comparator + + identifier ::= an alpha character followed by 0 to 3 + alphanumerics + + descriptor ::= (replicationexpression , datatype , + valueexpression , lengthexpression control) + + comparator ::= (value connective value control) | + (identifier *<=* control) + + replicationexpression ::= # | arithmeticexpression | + + datatype ::= B | O | X | E | A + + valueexpression ::= value | + + lengthexpression ::= arithmeticexpression | + + 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 9] + +RFC 166 Data Reconfiguration Service May 1971 + + + literaltype ::= B | O | X | E | A + + string ::= from 0 to 256 characters + + control ::= : options | + + 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 10] + +RFC 166 Data Reconfiguration Service May 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 11] + +RFC 166 Data Reconfiguration Service May 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 | + + 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 | + outputstream ::= :terms | + 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 + alphanumeric characters. + + + + +Anderson, et al. [Page 12] + +RFC 166 Data Reconfiguration Service May 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, value, and + replication attributes of the term and it may be referenced elsewhere + in the form. + + The replication expression, if specified, causes the unit value of + the term to be generated the number of times indicated by the value + of the replication expression. The unit value of the term (quantity + to be replicated) is determined from the data type, value expression, + and length expression attributes. The data type defines the kind of + data being specified. The value expression specifies a nominal value + that is augmented by the other term attributes. The length + expression determines the unit length of the term. (See the IBM SRL + Form C28-6514 for a similar interpretation of the pseudo instruction, + defined constant, after which the descriptor was modeled.) + + The replication expression is defined below. + + replicationexpression ::= # | arithmeticexpression | + 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 value, and length expressions. It expresses the + number of times that the nominal value is to be repeated. + + The terminal symbol # means an arbitrary replication factor. It must + be explicitly terminated by a match or non-match to the input stream. + This termination may result from the same or the following term. + + + + +Anderson, et al. [Page 13] + +RFC 166 Data Reconfiguration Service May 1971 + + + A null replication expression has the value of one. Arithmetic + expressions are evaluated from left-to-right with no precedence. + + 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. + + 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 | + value ::= literal | arithmeticexpression + literal ::= literaltype "string" + literaltype ::= B | O | X | E | A + + The value expression is the nominal value of a term expressed in the + format indicated by the data type. It is repeated according to the + replication 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 | + + + +Anderson, et al. [Page 14] + +RFC 166 Data Reconfiguration Service May 1971 + + + The length expression states the length of the field containing the + value expression. + + 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, value expression, and length expression + together specify a unit value, call it x. + + + + +Anderson, et al. [Page 15] + +RFC 166 Data Reconfiguration Service May 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 of y of + length L is tested with the input 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. + + 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 replicated values are of indefinite length because of the + arbitrary symbol, #. + +Restrictions and Interpretations of Term Functions + + 1. Terms having indefinite lengths because their values are + repeated according to 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.) + + 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 conversions is right-justified and + left-padded with blanks. + + 3. The following are ignored in a form definition over the control + connection. + a) TELNET control characters. + 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. + + a) The replication expression defaults to one. + b) # in an output stream term defaults to one. + c) The value expression of an input stream term defaults to + + + +Anderson, et al. [Page 16] + +RFC 166 Data Reconfiguration Service May 1971 + + + the value found in the input stream, but the input stream + must conform to the data type and length expression. The + value expression of an output stream term defaults to + padding only. + e) The length expression defaults to the size of the quantity + determined by the data type and value expression. + f) 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. + +TERM AND RULE SEQUENCING + + Sequencing may be explicitly controlled by including control in a + term. + + control ::= :options | + 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. + + + +Anderson, et al. [Page 17] + +RFC 166 Data Reconfiguration Service May 1971 + + + 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 left hand side of rule 1 + was not successfully applied, the input stream pointer is not + advanced. + + 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*/;; + + + +Anderson, et al. [Page 18] + +RFC 166 Data Reconfiguration Service May 1971 + + +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. The following rule picks up variable length + EBCDIC records and translates them to ASCII. + + CHAR(#,E,,1), /*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,,1), /*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*/ + + + + + + + + +Anderson, et al. [Page 19] + +RFC 166 Data Reconfiguration Service May 1971 + + +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 + 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 an EBCDIC char/* + CHAR(,E,,1) ; + /*get identical EBCDIC chars/* + LEN(#,E,CHAR,1) + /*emit the count and the char/* + : (,B,L(LEN)+1,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 count, in a field the length indicated*/ + /*by the counter contents*/ + CNT(,B,,8), CHAR(,E,,1) : (CNT,E,CHAR,1:U(1)); + /*failure of form*/ + (:U(R(98))) ;; + + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by Simone Demmel 03/98 ] + + + + + + +Anderson, et al. [Page 20] + -- cgit v1.2.3