RFC 76 (rfc76) - Page 3 of 15

Connection by name: User oriented protocol

RFC 76         Connection-By-Name: User-Oriented Protocol   October 1970


   The format of  is that of the responding host for the
   current discussion.  Future discussions about foreign-user usage of
   host facilities may result in a standard format for the entire
   network.

   Most systems can identify files by one  plus the .
   Others, such as the Burroughs B6500 use multifile identifiers where
   many  may be used in the .  The set of  is that
   proposed in RFC 66, i.e., ASCII.

   The proposed extensions involve a "request" for information and
   several variants of a "response" to the request.

   A. Request for Socket Number for this Label

      

   The RFSNL is sent on the control link to the destination host
   requesting the socket number of the attached .

   B. Acknowledgement of Request

   Upon receipt of an , the destination host returns one of three
   responses:

      

   The first response returns the requested socket number and signifies
   that the user, device, or process exists.  The second response
   returns the requested socket number but signifies that the user,
   device, or process is not currently available for connection.  The
   last response signifies that no such user, device, or process exists.

   C. Discussion

   The above extensions to the protocol are intended to enhance user
   acclimation to network usage.  The element of strangeness is subdued
   and, in fact, for user of the B6500 erased.  Attached to this RFC is
   an appendix containing a preliminary description of the user language
   of the network port facility being brought up at the CAC.  We now
   present a sample user session on the CAC facility and detail how the
   protocol is used to establish the proper communication paths.





Bouknight, et al.