Network Meeting Epilogue, etc
RFC 37

Document Type RFC - Unknown (March 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 37 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        S. Crocker
Request for Comments: 37                                           UCLA
                                                          20 March 1970

                     Network Meeting Epilogue, etc.

The Meeting

  On Tuesday, March 17, 1970, I hosted a Network meeting at UCLA.
  About 25 people attended, including representatives from MIT, LL,
  BBN, Harvard, SRI, Utah, UCSB, SDC, RAND and UCLA.  I presented a
  modification of the protocol in NWG/RFC #33; the modifications are
  sketchily documented in NWG/RFC #36.  The main modification is the
  facility for dynamic reconnection.

  The protocol based on sockets and undistinguished simplex
  connections is quite different from the previous protocol as
  documented in NWG/RFC #11.  The impetus for making such changes came
  out of the network meeting on December 8, 1969, at Utah, at which
  time the limitations of a log-in requirement and the inability to
  connect arbitrary processes was seriously challenged.  Accordingly,
  the primary reason for the recent meeting was to sample opinion on
  the new protocol.

  Recollections may vary, but it is my opinion that the protocol was
  widely accepted and that the criticism and discussion fell into two

  1.  Questioning the complexity and usefulness of the full protocol,
      especially the need for dynamic reconnection.

  2.  Other topics, particularly character set translation, higher
      level languages, incompatible equipment, etc.

  Notably lacking was any criticism of the basic concepts of sockets
  and connections.  (Some have since surfaced.)  The following
  agreements were made:

  1.  By April 30, I would be responsible for publishing an
      implementable specification along lines presented.

  2.  Any interested party would communicate with me (at least)
      immediately if he wished to modify the protocol.

                                                                [Page 1]
RFC 37             Network Meeting Epilogue, etc.         20 March 1970

  3.  If major modifications come under consideration, interested
      parties would meet again.  This would happen in two to three

  4.  Jim Forgie of Lincoln Labs tentatively agreed to host a meeting
      on higher level network languages, probably near Spring Joint

Mailing List Changes

  Paul Rovner of LL is replaced by

                   James Forgie
                   Mass. Institute of Technology
                   Lincoln Laboratory C158
                   P.O. Box 73
                   Lexington, Mass. 02173

                   telephone at (617) 862-5500 ext. 7173

  Professor George MEaly is added

                   George Mealy
                   Rm. 220
                   Aitken Computation Lab.
                   Harvard University
                   Cambridge, Massachusetts 02138

                   telephone at (617) 868-1020 ext. 4355


  In all of our writing we have used the term process, to mean a
  program which has an assigned location counter and an address space.
  A program is merely a pattern of bits stored in some file.  A new
  process is created only by an already existing process.  The
  previous process must execute an atomic operation (forc, attach,
  etc.) to cause such a creation.  Processes may either cause their
  own demise or be terminated by another (usually superior) process.

  The above definition corresponds to the definition given by
  Vyssotsky, et al on pp.  206, 207 of "Structure of the Multics
  Supervisor" in the FJCC proceedings, 1965.

                                                                [Page 2]
RFC 37             Network Meeting Epilogue, etc.         20 March 1970

  Because a process may create another process, and because in general
  the two processes are indistinguishable when viewed externally, I
  know of no reasonable way for two processes to request connection
  directly with each other.  The function of sockets is to provide a
  standard interface between processes.

The Days After

  In the time since the meeting I have had conversations with Steve
  Wolfe (UCLA-CCN), Bill Crowther (BBN), and John Heafner and Erick
  Harslem (RAND).  Wolf's comments will appear as NWG/RFC #38 and fall
  into a class I will comment on below.

  Crowther submitted the following:

  "A brief description of two ideas for simplifying the host protocol
  described at the March meeting.  These ideas have not been carefully
  worked out.

  Idea 1. To Reconnect.

  "A NCP wanting to Reconnect tells each of his neighbors "I want to
  reconnect".  They wait until there are no messages in transit and
  respond "OK".  He then says "Reconnect as follows" and they do it.
  In the Rare condition, the NCP gets back an "I want to reconnect
  instead of an "OK", then one must go and one must stop.  So treat a
Show full document text