RFC 46 (rfc46) - Page 1 of 17

ARPA Network protocol notes

Alternative Format: Original Text Document
Next >
Network Working Group                                Edwin E. Meyer, Jr.
Request for Comments: 46           Massachusetts Institute of Technology
                                                           17 April 1970


                      ARPA Network Protocol Notes

   The attached document contains comments and suggestions of the
   Network Working Group at Project MAC.  It is based upon the protocol
   outlined in NWG/RFC 33, 36, and later documents.

   This proposal is intended as a contribution to the dialog leading to
   a protocol specification to be accepted by the entire Network Working
   Group.

   We solicit your comments.

I - INTRODUCTION

   In this document the Network Working Group at MIT Project MAC suggest
   modifications and extensions to the protocol specified by Carr,
   Crocker, and Cerf in a preprint of their 1970 SJCC paper and extended
   by Crocker in NWG/RFC 36.  This document broadly outlines our
   proposal but does not attempt to be a complete specification.  It is
   intended to be an indication of the type and extent of the protocol
   we think should be initially implemented.

   We agree with the basic concept of simplex communication between
   sockets having unique identifiers.  We propose the implementation of
   a slightly modified subset of the network commands specified in
   NWG/RFC 36 plus the ERR command as specified by Harslem and Heafner in
   NWG/RFC 40.

   Given the basic objective of getting all ARPA contractors onto the
   network and talking to each other at the earliest possible date, we
   think that it is important to implement an initial protocol that is
   reasonably simple yet extendable while providing for the major
   initial uses of the network.  It should be a simple protocol so as to
   elicit the broadest possible support and to be easily implementable
   at all installations with a minimum of added software.

   While the protocol will evolve, the fundamentals of a protocol
   accepted and implemented by all installations are likely to prove
   very resistant to change.  Thus it is very important to make the
   initial protocol open-ended and flexible.  A simple basic protocol is
   more likely to succeed in this respect than a complicated one.  This
Next >