rfc166.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页

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    |        +-----+
                +---------+