RFC 76 (rfc76) - Page 3 of 15
Connection by name: User oriented protocol
Original Text Document
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
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
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.
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.