Data Reconfiguration Service: An implementation specification
RFC 166

Document Type RFC - Unknown (May 1971; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 166 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text