RFC 166 (rfc166) - Page 2 of 20


Data Reconfiguration Service: An implementation specification



Alternative Format: Original Text Document



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.