rfc138.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       Bob Anderson
Request for Comments: 138                                           Rand
NIC 6715                                                       Vint Cerf
                                                                    UCLA
                                                            Eric Harslem
                                                            John Heafner
                                                                    Rand
                                                              Jim Madden
                                                          U. of Illinois
                                                            Bob Metcalfe
                                                                     MIT
                                                           Arie Shoshani
                                                                     SDC
                                                               Jim White
                                                                    UCSB
                                                              David Wood
                                                                   Mitre
                                                           28 April 1971

         STATUS REPORT ON PROPOSED DATA RECONFIGURATION SERVICE

                                 CONTENTS
     I.  INTRODUCTION .................................    2

         Purpose of this RFC ..........................    2
         Motivation ...................................    2

    II.  OVERVIEW OF DATA RECONFIGURATION SERVICE .....    3

         Elements of Data Reconfiguration Service .....    3
         Conceptual Network Connections ...............    3
         Connection Protocols and Message Formats .....    4
         Example Connection Configurations ............    6

   III.  THE FORM MACHINE .............................    7

         Input/Output Stream and Forms ................    7
         Form Machine BNF Syntax ......................    7
         Alternate Specification of Form Machine Syntax    8
         Forms ........................................    9
         Rules ........................................   10
         Terms ........................................   10

           Term Format 1 ..............................   11
           Term Format 2 ..............................   11
           Term Format 3 ..............................   13
           Term Format 4 ..............................   13
           Application of a Term ......................   14



Anderson, et al.                                                [Page 1]

RFC 138               Data Reconfiguration Service          April 1971


           Restrictions and Interpretations of
             Term Functions ...........................   14
         Term and Rule Sequencing .....................   16

    IV.  EXAMPLES .....................................   16

         Remarks ......................................   16
         Field Insertion ..............................   17
         Deletion .....................................   17
         Variable Length Records ......................   17
         String Length Computation ....................   18
         Transposition ................................   18
         Character Packing and Unpacking ..............   18

     V.  PROPOSED USES OF DATA RECONFIGURATION SERVICE    19

    VI.  IMPLEMENTATION PLANS .........................   20

   Appendix A .........................................   21

         Note 1 to the DRS Working Group ..............   21
         Note 2 to the DRS Working Group ..............   22

I.  INTRODUCTION

   PURPOSE OF THIS RFC

   The purpose of this RFC is to describe, in part, a proposed Network
   experiment and to solicit comments on any aspect of the experiment.
   The experiment involves a software mechanism to reformat Network data
   streams.  The mechanism can be adapted to numerous Network
   application programs.  We hope that the results of the experiment
   will lead to a further standard service that embodies the principles
   described in this RFC.   We would like comments on the
   appropriateness of this work as a Network experiment and also
   comments on particular Network data reformatting needs that could not
   easily be accomplished using these techniques.

MOTIVATION

   Application programs require specific data I/O formats yet the
   formats are different from program to program.  We take the position
   that the Network should adapt to the individual program requirements
   rather than changing each program to comply with a standard.  This
   position doesn't preclude the use of standards that describe the
   formats of regular message contents; it is merely an interpretation
   of a standard as being a desirable mode of operation but not a
   necessary one.



Anderson, et al.                                                [Page 2]

RFC 138               Data Reconfiguration Service          April 1971


   In addition to differing program requirements, a format mismatch
   problem occurs where users wish to employ many different kinds of
   consoles to attach to a single service program.  It is desirable to
   have the Network adapt to individual console configurations rather
   than requiring unique software packages for each console
   transformation.

   One approach to providing adaptation is for those sites with
   substantial computing power to offer a data reconfiguration service;
   a proposed example of such a service is described here.

   The envisioned modus operandi of the service is that an applications
   programmer defines _forms_ that describe data reconfigurations.  The
   service stores the forms by name.  At a later time, a user (perhaps a
   non-programmer) employs the service to accomplish a particular
   transformation of a Network data stream, simply by calling the form
   by name.

   We have attempted to provide a notation tailored to some specifically
   needed instances of data reformatting while keeping the notation and
   its underlying implementation within some utility range that is
   bounded on the lower end by a notation expressive enough to make the
   experimental service useful, and that is bounded on the upper end by
   a notation short of a general purpose programming language.


II.  OVERVIEW OF THE DATA RECONFIGURATION SERVICE

ELEMENTS OF THE DATA RECONFIGURATION SERVICE

   An implementation of the Data Reconfiguration Service (DRS) includes
   modules for connection protocols, a handler of some requests that can
   be made of the service, a compiler and/or interpreter (called the
   Form Machine) to act on those requests, and a file storage module for
   saving and retrieving definitions of data reconfigurations (forms).
   This section highlights connection protocols and requests.  The next
   section covers the Form Machine language in some detail.  File
   storage is not described in this document because it is transparent
   to the use of the service and its implementation is different at each
   DRS host.

CONCEPTUAL NETWORK CONNECTIONS

   There are three conceptual Network connections to the DRS, see Fig.
   1.

         1)  The control connection (CC) is between an originating user
             and the DRS.  A form specifying data reconfiguration is



Anderson, et al.                                                [Page 3]

RFC 138               Data Reconfiguration Service          April 1971


             defined over this connection and is applied to data passing
             over the two connections described below.
         2)  The user connection (UC) is between a user process and the
             DRS.
         3)  The server connection (SC) is between the DRS and the
             serving process.

   Since the goal is to adapt the Network to user and server processes,
   a minimum of requirements are imposed on the UC and SC.


      +-------------+   CC   +-----------+   SC   +-----------+
      | ORIGINATING +--------+    DRS    +--------+ SERVER    |
      |    USER     |   ^    |           |    ^   | PROCESS   |
      +-------------+   |    +------+----+    |   +-----------+
                        |          /          |
                     Telnet       / <------ Simplex or Duplex
                    Protocol   UC/            Connections
                   Connection   /
                               /
                        +-----+-----+
                        | USER      |
                        | PROCESS   |
                        +-----------+

                Figure 1.  DRS Network Connections


CONNECTION PROTOCOLS AND MESSAGE FORMATS

   Over a control connection the dialog is directly between an
   originating user and the DRS.  Here the user is defining forms or
   assigning forms to connections for reformatting.

   The user connects to the DRS via the initial connection protocol
   (ICP) specified in NWG/RFC #80, version 1.  Rather than going through
   a logger, the user calls on a particular socket on which the DRS
   always listens.  DRS switches the user to another socket pair.

   Messages sent over a control connection are of the types and formats
   to be specified for TELNET.  Thus, a user at a terminal should be
   able to connect to a DRS via his local TELNET, for example, as shown
   in Fig.  2.








Anderson, et al.                                                [Page 4]

RFC 138               Data Reconfiguration Service          April 1971


                                          +--------------+
                         +--------+  CC   |              |
                 +-------+ TELNET +-------+     DRS      |
                 |       +--------+       |              |
                 |                        +--------------+
      +----------+---------+
      |      USER          |
      |(TERMINAL OR PROGRAM|
      +--------------------+

           Figure 2.  A TELNET Connection to DRS

   When a user connects to DRS he supplies a six-character user ID (UID)
   as a qualifier to guarantee the uniqueness of his form names.  He
   will have (at least) the following commands:

         1.  DEFFORM (name)
         2.  ENDFORM (name)

             These two commands define a form, the text of which is
             chronologically entered between them.  The (name) is six
             characters.  The form is stored in the DRS local file
             system.

         3.  PURGE (name)

             The named form, as qualified by the current UID, is purged
             from the DRS file system.

         4.  LISTNAMES (UID)

             The unqualified names of all forms assigned to UID are
             returned.

         5.  LISTFORM (name)

             The source text of a named form is returned.

         6.  DUPLEXCONNECT (user site, user send, user receive,
                        user method, server site, server
                        send, server receive, server method,
                        user-to-server form, server-to-user form)

         7.  SIMPLEXCONNECT (send site, send socket, send
                          method, receive site, receive
                          socket, receive method, form)





Anderson, et al.                                                [Page 5]

RFC 138               Data Reconfiguration Service          April 1971


   Either one, both, or neither of the two parties specified in 6 or 7
   may be at the same host as the party issuing the request.  Sites and
   sockets specify user and server for the connection.  Method indicates
   the way in which the connection is established.  Three options are
   provided:
        1)  Site/socket already connected to DRS as a dummy
            control connection.  (A dummy control connection
            should not also be the real control connection.)
        2)  Connect via standard ICP. (Only for command no. 6.)
        3)  Connect directly via STR, RTS.

EXAMPLE CONNECTION CONFIGURATIONS

   There are basically two modes of DRS operation: 1) the user wishes to
   establish a DRS UC/SC connection(s) between two programs and 2) the
   user wants to establish the same connection(s) where he (his
   terminal) is at the end of the UC or the SC.  The latter case is
   appropriate when the user wishes to interact from his terminal with
   the serving process (e.g., a logger).

   In the first case (Fig. 1, where the originating user is either a
   terminal or a program) the user issues the appropriate CONNECT
   command.  The UC/SC can be simplex or duplex.

   The second case has two possible configurations, shown in Figs. 3 and
   4.

               +--------+  CC  +--------+      +------+
               |        +------+        |  SC  |      |
     +------+ /| TELNET |  UC  |  DRS   +------+  SP  |
     |      |/ |        +------+        |      |      |
     | USER | /+--------+      +--------+      +------+
     |      |/
     +------+

            Figure 3.  Use of Dummy Control Connection