RFC 138 (rfc138) - Page 2 of 23

Status report on proposed Data Reconfiguration Service

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.