doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

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 | <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
+                       alphanumerics
+
+   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 9]
+
+RFC 166               Data Reconfiguration Service              May 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 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 | <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
+   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 | <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 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 | <null>
+            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 | <null>
+
+
+
+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 | <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.
+
+
+
+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]
+