Proposed User-User Protocol
RFC 91

Document Type RFC - Unknown (December 1970; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 91 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                    George H. Mealy
Request for Comments: 91                              Harvard University
                                                       December 27, 1970

                     A PROPOSED USER-USER PROTOCOL


   There are many good reasons, and maybe one or two bad ones, for
   making it appear that communication over the Network is only a
   special case of input/output -- at least as far as user programming
   is concerned.  Thus, for instance, the Harvard approach toward
   implementing the HOST-HOST protocol and Network Control Program
   treats each link as a "logical device" in PDP-10 terminology.
   Setting up a connection is similar to local device assignment, and
   communication over a link will make use of the standard system
   input/output UUO's.  This makes it possible to use existing programs
   in conjunction with the Network without modification -- at least if
   other PDP-10's are being dealt with.

   This takes us only so far, however.  The notion of a "logical device"
   does not exist on the PDP-10; it does on the IBM 360 (I am speaking
   here at the level of the operating system -- user program interface).
   Furthermore, in the absence of a Network standard requiring fixed
   representations for integers, reals, etc. (which I would oppose), any
   pair of user processes must arrive at a local agreement, and one or
   both must assume the burden of data conversion where necessary.  Any
   standard protocol should allow such agreements to be given expression
   and should accommodate at least the minimum of control information
   that will allow such agreements to function in practice.  Finally, we
   must note that the IMP-IMP and HOST-HOST protocols do not provide for
   a check that an action requested by a user process is actually
   accomplished by the other processes; this type of issue has always
   been regarded as subject to treatment at the USER-USER protocol

   This proposal is intended to face the above three types of issue only
   to a certain extent.  I can best explain that extent by stating the
   criteria I would use to judge any USER-USER protocol proposal:

Mealy                                                           [Page 1]
RFC 91               A Proposed User-User Protocol         December 1970

   1.   The notion of a (logical) _record_ should be present, and the
        notion of a _message_ should be suppressed. (To a FORTRAN pro-
        grammer, that which is written using one WRITE statement with no
        accompanying FORMAT is a record; to an OS/360 machine language
        programmer, PUT writes a record).

   2.   It should be possible to so implement the protocol in HOST sys-
        tems and/or library routines that now existing user programs can
        access files anywhere in the Network without program modifica-
        tion. (Initially, at least, this ability must be restricted to
        HOST systems of the same type).

   3.   The protocol should be implementable (not necessarily imple-
        mented) in any HOST system at the SVC or UUO level.  Specific
        knowledge of the characteristics of the other HOST involved
        should be unnecessary.

   It should be noted that the above imply that some user programs must
   be aware of the nature of the other HOST -- at least in each case
   where the second criterion fails.  As we make progress in (or give up
   on) the cases where the failure now occurs, the burden of accommodat-
   ing system differences will shift toward implementation in protocols
   (i.e., the HOST systems) or, by default, in user programs.

   Quite clearly, any proposal initiated today should be suspect as to
   the extent to which it "solves" ultimate problems.  How ambitious to
   be is strictly a matter of taste.  At this stage, I prefer to try
   something which I believe can be used by all of us (and, hence, is
   worth doing), goes a reasonable distance towards solving our short-
   range problems, is easy to do, and offers hope of viability in the
   long range view.  In the following, I intend to describe the proposal
   itself with, I hope, proper motivational arguments for its pieces.  I
   will then sketch the specific implementation we at Harvard are making
   for the PDP-10 and describe how we intend to apply it in the specific
   case of storage of files on other PDP-10's in the Network.


   The following protocol is intended to apply to the data bits in mes-
   sages between the end of the marking bits and the beginning of the
   padding bits. _The present IMP-IMP and HOST-HOST protocols are unaf-
   fected by this proposal_.

   The general principle is that each segment (this is not a technical
   term) of data is preceded by control information specifying its
   nature and extent.  The basic scheme has been evolved from that used
   in the SOS buffering system (see the papers in JACM, April 1959 and
Show full document text