Browse Prior Art Database

Protocols and Data Formats (RFC0080)

IP.com Disclosure Number: IPCOM000005899D
Original Publication Date: 1970-Dec-01
Included in the Prior Art Database: 2001-Nov-15
Document File: 10 page(s) / 18K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Harslem: AUTHOR [+2]

Abstract

Because of recent discussions of protocols and data formats we issue this note to highlight our current attitudes and investigations in those regards. We first discuss some specific sequences, and then offer some thoughts on two general implementation approaches that will handle these and other specifics. We wish to place emphasis on the _general solutions_ and not on the specifics.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 22% of the total text.

Network Working Group                                         E. Harslem

Request for Comments: 80                                      J. Heafner

NIC: 5608                                                           RAND

                                                         1 December 1970

                       PROTOCOLS AND DATA FORMATS

   Because of recent discussions of protocols and data formats we issue

   this note to highlight our current attitudes and investigations in

   those regards.  We first discuss some specific sequences, and then

   offer some thoughts on two general implementation approaches that

   will handle these and other specifics.  We wish to place emphasis on

   the _general solutions_ and not on the specifics.

INITIAL CONNECTION PROTOCOLS

   We wish to make two points concerning specific Initial Connection

   Protocols (IPCs).  Firstly, the IPC described in NEW/RFC #66--its

   generality and a restatement of that ICP.  Secondly, a proposal for a

   variant ICP using basically the same logic as NWG/RFC #66.

I. NWG/RFC #66

   The only technical error in this IPC is that as diagrammed both the

   Server and User send ALL messages before the connections are

   established which is inconsistent with Network Document No. 1.  This

   can easily be remedied as will be shown in the restatement below.

   In terms of generality, any ICP that is adopted as a standard should

   apply to more situations than a process calling a logger.  That is,

   some Network service processes that hook directly to a user process,

   independent of logger action, could perhaps use a standard ICP.

   Thus, as is shown below, the process name field of the server socket

   should be a parameter with a value of zero being a special case for

   loggers.

   Restatement of NWG/RFC #66 (using the same wording where appropriate)

      1. To initiate contact, the using process attaches a receive

         socket (US) and requests connection to process SERV socket #1

         in the serving HOST.  (SERV = 0 for ICP to the logger.)  As a

         result the using NCP sends:

Harslem, et. al.                                                [Page 1]

RFC 80                 Protocols and Data Formats        1 December 1970

            1              4                 3          1     1

         +-----+---------------------+---------------+-----+-----+

         | RTS |          US         |      SERV     |  1  |  P  |

         +-----+---------------------+---------------+-----+-----+

         over link 1, where P is the receive link.

      2. The serving process (SERV) may decide to refuse to the call, in

         which case it closes the connection.  If it accepts the call,

         the serving process completes the connection (via an INIT

         system call, hence an STR).

            1           3          1            4

         +-----+----------------+-----+--------------------+

         | STR |      SERV      |  1  |         US         |

         +-----+----------------+-----+--------------------+

      3. When the connection is completed, the user process allocates a

         nominal amount of space to the connection, resulting in the NCP

         sending:

            1     1            4

         +-----+-----+--------------------+

         | ALL |  P  |       SPACE        |

         +-----+-----+--------------------+

         where SPACE is the amount.

      4. The serving process then selects the socket pair it wishes to

         assign this user.  It sends exactly an even 32 bit number over

         the connection.  This even 32 bit number (SS) is the receive

         socket in the serving HOST.  This socket and the next higher

         numbered socket are reserved for the using process.

      5. It then closes the connection.  The...