University California Los Angeles (UCLA) Stanford Research Institute (SRI) University California Los Angeles (UCLA) The Network Working Group seems to consist of Steve Carr of Utah, Jeff Rulifson and Bill Duvall at SRI, and Steve Crocker and Gerard Deloche at UCLA. Membership is not closed. The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experiments with the network. Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series. Stanford Research Institute (SRI) International Stanford Research Institute (SRI) International

333 Ravenswood Menlo Park CA 94025 US +1 415 326 6200 x4116

The Decode-Encode Language (DEL) is a machine independent language tailored to two specific computer network tasks: accepting input codes from interactive consoles, giving immediate feedback, and packing the resulting information into message packets for network transmissin. and accepting message packets from another computer, unpacking them, building trees of display information, and sending other information to the user at his interactive station. This is a working document for the evolution of the DEL language. Comments should be made through Jeff Rulifson at SRI. University California Los Angeles (UCLA) I talked with Bob Kahn at BB&N yesterday. We talked about code conversion in the IMP's, the IMP-HOST communication and HOST software. University of California, Los Angeles (UCLA) This note is a revision of NWG/RFC #3 The Network Working Group seems to consist of Steve Carr at Utah, Elmer Shapiro and Bill English SRI, Steve Crocker at UCLA, John Haefner at RAND, Paul Rovner and Jim Curry at Lincoln Labs. Membership is not closed. The Network Working Group (NWG is concerned with the HOST software, the strategies for using the network, and initial experience with the network. Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series. University California Los Angeles (UCLA) Referring to NWG/RFC: 11, it appears that file transmissions over auxiliary connections will require some mechanism to specify "END-OF-FILE." It is proposed that a length 0 (zero) message be used for this purpose. University of Utah University California Los Angeles (UCLA) M.I.T. is now to receive all Network Working Group memos. System Development Corporation (SDC) University California Los Angeles (UCLA) It is suggested that link 1 be used for the HOST-HOST control link and link 0 be used for IMP-IMP control. System Development Corporation (SDC) There is a wide variance in swap rates between core and auxiliary store among the HOST systems to be nodes in the ARPA IMP network. The slower of these, of which our 360/50 system with 2303 drump swap store is an example, might improve the utility of the network not only for themselves but for all nodes if the two protocol suggestions of this note were to be adopted. University California Los Angeles (UCLA) For concreteness, we suggest the use of standard 7-bit ASCII embedded in an 8 bit byte whose high order bit is always 0. University California Los Angeles (UCLA) At UCLA on October 10, there was a network meeting attended by: University of California, Santa Barbara (UCSB) The network program at a site must be prepared to send or receive more than one control message in a single control communication. During the time that the control link is blocked awaiting RFNM, it is possible that a number of control messages to a particular remote host will accumulate. When the link is unblocked, these should all be sent in a single communication for greatest efficiency. For receiving, it will be necessary to have a loop which returns to decode and take action on successive control messages until the control communication is exhausted. University of California, Los Angeles (UCLA) This note is a revision of NWG/RFC 10 and 16,. The Network Working Group consists of interested people from existing or potential ARPA network sites. Membership is not closed. The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experience with the network. Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by and included in this series. University of California, Los Angeles (UCLA) Because it may be desirable to reserve one or more link numbers for instrumentation purposes, and because 256 link numbers are many more than are needed, we suggest that no link number over 63 be used. At UCLA, we will implement our tables to take advantage of this limitation. We also note that 32 may be even more realistic, but 64 is certainly sufficient. University California Los Angeles (UCLA) This note is a revision of NWG/RFC 10, 16, and 24,,. The Network Working Group consists of interested people from existing or potential ARPA network sites. Membership is not closed. The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experience with the network. Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series. Stanford Research Institute (SRI) We are about to install a relatively accurate real-time clock on our system. I would like any comments relative to Network time standards for such things as delay measurement so we can decide how good our clock should be. Bolt Baranek and Newman (BBN) A "millisecond" clock should be satisfactory for most network measurements. Round-trip message transit times typically should be at least on the order of tens to hundreds of milliseconds. The IMP contains a 16-bit hardware clock which is incremented every 100 microseconds to allow for timing of internal events within the IMP, as for example, during tracing.However, most measurements are made using a 25.6 ms. software clock. University of California, Los Angeles (UCLA) This note is a revision of NWG/RFC 10, 16, 24, and 27,.,. The Network Working Group consists of interested pleople from existing or potential ARPA network sites. Membership is not closed. The Network Working Group (NWG) is concerned with the HOST software, the strategies for using the network, and initial experience with the network. Documentation of the NWG's effort is through notes such as this. Notes may be produced at any site by anybody and included in this series. Bolt, Beranek, and Newman (BBN) Massachusetts Institute of Technology (MIT), Lincoln Laboratory University of California, Los Angeles (UCLA) Re: NWG/RFC's #28 and 29,. The addition of a clock in one or more of the network HOST's seems to be very desireable since it (or they) would allow user-oriented message delay measurements. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The ARC clock system provides a time reference that is written into the core memory of the XDS 940 Computer. There are two types of time information available--absolute and relative. University of California, Los Angeles (UCLA) I expect to have the details of the new network protocol as outlined in NWG/RFC #33ready in two weeks. University California Los Angeles (UCLA) University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA), Campus Computing Network (CCN) The proposed protocol does not allow for the possible multiplexing of connections over links. Rand Corporation Rand Corporation We offer the following suggestions to be considered as additions to the April 28th 1970 protocol grammar specifications. Rand Corporation Rand Corporation We have recently discussed NWG/RFC Nos. 36 and 39,with Steve Crocker, UCLA. Steve has asked that we elaborate on the errors, queries, and HOST status that were mentioned in NWG/RFC #39. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) I have occasionally found myself in a situatuation in Which I see a message from site X on my IMP teletype, but I don't know the time and date of the message. I find this annoying, since a response to it may be in order if it is (say) less than an hour old, but not if it is several hours old. The situation is not improved by the existence of sites that now span all time zones of the U.S. and do not have direct voice connection. It is requested that everyone tag their IMP to IMP teletype messages that cause no response at the receiving IMP. The transmitting IMP site should use 24 hour time and include the time zone designation. Massachusetts Institute of Technology (MIT), Lincoln Laboratory Massachusetts Institute of Technology (MIT), Lincoln Laboratory

Lexington MA 02173 US +1 617 862 5500 x7354

On Friday, 8 May 1970, at 9:30 AM a meeting at M.I.T. Lincoln Laboratory is proposed. A description of LIL (Local Interaction Language) for the TSP (Terminal Support Processor) system will be presented. The purpose of the TSP system is to provide a flexible I/O capability for network users. In order to achieve maximum flexibility, the system is user-programmable in an interpretable language called LIL. University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) We are currently preparing a clean version of the Network protocol, hopefully suitable for immediate implementation. As advertised, we will send these specs out on April 28. Massachusetts Institute of Technology (MIT) The attached document contains comments and suggestions of the Network Working Group at Project MAC. It is based upon the protocol outlined in NWG/RFC 33, 36,, and later documents. This proposal is intended as a contribution to the dialog leading to a protocol specification to be accepted by the entire Network Working Group. We solicit your comments. University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) BBN has given us the attached comments on NWG/RFC 33, but wouldn't publish them being relectant to embarrass us. Embarrassment notwithstanding, we found the comments particularly useful and decided to share them with our friends. Bill Crowther is the author. University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) Massachusetts Institute of Technology (MIT), Project MAC On April 21 and 23 Thomas P. Skinner and I had telephone conversations with Steve Crocker at UCLA relating to the network protocol, specifically regarding our proposal in NWG/RFC 46. RAND Corporation RAND Corporation We find the Meyer proposal (Note #46) to be the most acceptable to dare, for exactly the reasons that he enumerates; viz., simple, suffices for most planned uses of the Network, easy to implement, can be extended. University California Los Angeles (UCLA) University California Los Angeles (UCLA) University of California, Los Angeles (UCLA) During the Spring Joint Computer Conference in Atlantic City, Larry Roberts, Barry Wessler, Cordell Green, Jon Postel and I discussed rules for establishing and modifying an official Host-Host protocol. University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) Harvard University Harvard University Harvard University Harvard University University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) While involved in attempting to specify the formal protocol, we also attempted to formulate a prototypical NCP in an Algol-like language. Harvard University Harvard University University of Utah University of Utah In our view of the world each host has a set of four programs to allow a user teletype to communicate with a foreign monitor. The exact implementation of these programs is highly installation-dependent. Thus all explanations are meant to describe functional characteristics rather than design. Harvard University Harvard University In the course of writing NWG/RFC #54several new ideas became apparent. Since these ideas had not previously been discussed by the NWG, or were sufficiently imprecise, it was decided not to include them in the official protocol proffering. We thought, however, that they might be proper subjects for discussion and later inclusion in the second level protocol. Massachusetts Institute of Technology (MIT), Project MAC At the last network meeting, the question of logical and physical message distinctions was raised. An argument was made in favor of never running two logical messages together as one or more physical messages. Another method of stating this is that a logical message must begin on a physical message boundary. This did not, however, solve the problem of locating the end of a logical message. A rather poor technique was suggested by myself which consisted of using the first partial physical message as an indication of the last physical message of the logical message. This technique was thrown out for a number of very valid reasons. The solution that seemed most pleasing was the inclusion of some sort of a bit count or data type specification to precede the logical message. Most everyone seemed to like this even though it was stated in a very general way. Massachusetts Institute of Technology (MIT), Project MAC The method of flow control described in RFC 54, prior allocation of buffer space by the use of ALL network commands, has one particular advantage. If no more than 100% of an NCP's buffer space is allocated, the situation in which more messages are presented to a HOST then it can handle will never arise. However, this scheme has very serious disadvantages: Massachusetts Institute of Technology (MIT), Lincoln Laboratory This RFC defines a new NCP protocol that is simple enough to be implemented on a very small computer, yet can be extended for efficient operation on large timesharing machines. Because worst case storage requirements can be predicted, a conservative implementation can be freed of complicated resource allocation and storage control procedures. A general error recovery procedure is also defined. Bolt Beranek and Newman (BBN) Bolt Beranek and Newman, Inc. (BBN)

10 Moulton Street Cambridge MA 02138 US

On 8 May 1970, a Network Working Group meeting was hosted at Lincoln Labs. A/S Norsk Data-Elektonikk Eliminate marking. Instead, make all regular messages into two message: The first containing just the leader and indicating that the data follows in the second (next) message. Do this both from the source Host to its IMP and from the destination IMP to its Host. Bolt Baranek and Newman (BBN) Before he left for Norway, Dave Walden observed that there was a simple change to the Host/IMP specifications which would eliminate all "marking" problems. The change is to separate the leader from the text of regular messages, and then to send them as consecutive messages instead of one packed message. The text would then start on a word boundary no matter what the word lengths of the machines involved. The process would take place on both IMP-to-Host and Host-to-IMP messages. University of California, Los Angeles (UCLA) The protocol provides a scheme for buffer allocation. Massachusetts Institute of Technology (MIT) Please delete my name from your distribution list and add that of Mr. Albert Vezza. University of California, Los Angeles (UCLA) The padding on a message is a string of the form 10*. For Hosts with word lengths 16, 32, 48, etc., bits long, this string is necessarily in the last word received from the Imp. University of California, Los Angeles (UCLA), Campus Computing Network (CCN) In case of reading a message from the IMP, it may be impossible for the receiving NCP to determine the length of the message if an input error occurs. The following protocol will be used at the CCN-Host at UCLA to resynchronize flow control. Massachusetts Institute of Technology (MIT), Project MAC Bill Crowther's RFC No. 67raised a much more fundamental issue than the question of marking. Any change to presently established protocol is going to involve changes in the hardware/software development efforts that have, in some instances, been going on for over 6 months. In the case of Multics, this effort has yielded programs either complete or in the advanced debugging stages. This is no doubt true for many other sites as well. University of California, Los Angeles (UCLA) Bill's suggestion is a good one; however, my current policy is to encourage the most rapid implementation of the protocol in document #1, and his suggested modification should be delayed. It seems to me most important to gain experience using the network before making changes to the protocol which are not dictated by necessity. University of California, Los Angeles (UCLA) Taking advantage of the FJCC in Houston, I have scheduled a meeting of the Network Working Group in room Astro VII of the Astroworld Hotel at 8:00 p.m. on Monday, November 16, 1970. University of Illinois University of Illinois University of Illinois Shortly after the first of the year, 1971, the Center for Advanced Computation (CAC) at the University of Illinois will begin to use the facilities of the ARPA network. University of California, Los Angeles (UCLA) This is a report on a series of three Network Working Group meetings at the Fall Joint Computer Conference, November 16, 17 and 18 in Houston, Texas. Rand Corporation Rand Corporation Massachusetts Institute of Technology (MIT), Project MAC A conflict was recently discovered between the official NCP protocol as described in protocol document 1 and the logger protocol as described in RFC 66by Steve Crocker. Steve suggested that we put out an RFC to alert the network community to this point. University of Illinois, Center for Advanced Computation

168 Engineering Research Laboratory Urbana IL 61801 US

Please ask your Technical Liaison Contact if he will send me as many references as he can in the subject areas of data communications and communications theory. Massachusetts Institute of Technology (MIT), Project MAC The following summary was transcribed from notes I took at three network meetings held in Houston during the 1970 Fall Joint Computer Conference. University of California, Los Angeles (UCLA) In line with the consensus of the Houston Network Working Group meeting in November, we will hold general Network Working Group meetings approximately every three months. The Spring and Fall meetings will be synchronized to the Joint Computer Conferences. The others will be moved around in order to promote exposure to the various sites and spread the burden of hosting. University of California, Los Angeles (UCLA) *A typical arrangement of facilities is to have a console attached to a computer at the user's site, and to be using the computational facilities of a remote site. Information entered by the user is transmitted to the remote Host, and output from the remote Host is transmitted back to the local user. In this proposal I am concerned with specifying the form of the output stream for the case that the output portion of the console is a typical refresh display with point, vector and character drawing capability. Devices in this class include the DEC 338, DEC 340, IBM 2250, and IMLAC PDS-1. Massachusetts Institute of Technology (MIT), Project MAC

545 Technology Square Room 830 Cambridge MA 02139 US +1 617 864 6900 x6026

Project MAC is planning a network graphics meeting to be held in April. University of California, Los Angeles (UCLA), Campus Computing Network (CCN) Harvard University Bolt Baranek and Newman (BBN) A review of the Initial Connection Protocol (ICP) first described in RFC #66and restated in RFC #80has revealed an area of ambiguity, which in turn reflects an ambiguity in the Host-Host Protocol Document No. 1. This is the definition of the message sent over the connection from "Server socket #1". In both referenced RFC's, the message is defined as "exactly an even 32 bit number". It is not clear, however, whether this 32 bit number is meant to follow an eight-bit "message data type" code or not, stemming from the fact that the Host-Host Protocol makes provision for such codes but does not seem to absolutely demand them. University of California, Los Angeles (UCLA), Computer Science Department

3732 Boelter Hall Los Angeles CA 90024 US +1 213 825 2368

Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) With the ARPA Network Host-to-Host Protocol specified and at least partially implemented at a number of sites, the question of what steps should be taken next arises. There appears to be a widespread feeling among Network participants that the first step should be the specification and implementation of what has been called the "Logger Protocol"; the Computer Network Group at project MAC agrees. The term "logger" has been commonly used to indicate the basic mechanism to gain access (to "login") to a system from a console. A network logger is intended to specify how the existing logger of a network host is to interface to the network so as to permit a login from a console attached to another host. Mitre Corporation The next meeting of the Network Working Group will be held in Atlantic City, New Jersey coincident with the SJCC. MITRE Corporation The NWG/RFC Guide is an attempt to introduce some order into the NWG/RFC series, which now numbers 102. The Guide categorizes the NWG/RFC notes, identifies topics under discussion and the relevant NWG/RFCs, and indicates whether the notes are current, obsolete, or superseded. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) University California Los Angeles (UCLA) At the NWG meeting in Urbana on 17-19 February 1971, a committee was established to look at the Host/Host protocol and see what changes were immediately desirable or necessary. Massachusetts Institute of Technology (MIT), Lincoln Laboratory (LL) The current protocol specifications contain a serious logical error in the implementation of the program interrupt function. This paper discusses the problem and offers a solution that is simple to implement. University of California, Los Angeles (UCLA), Computer Science University of California, Los Angeles (UCLA), Computer Science At the Network meeting at the University of Illinois, it was agreed to reserve a link for use in measurements. The link chosen was the highest unassigned link which was incorrectly calculated to be number 223. The correct number is 191. Therefore, Link 191 will be assigned for measurement use. Use of this link should be cleared with the Liasion Officer at the Network Measurement Center (NMC). University of California, Santa Barbara (UCSB), Computer Research Lab. In the discussions that follow, 'byte' means 8 bits, with those eight bits numbered 0-7 from left to right. RDS The answer to a number of questions about the characteristics and operation of Network HOSTS will be useful to implementers of some early versions of TELNET, and/or to the USER/SERVER SITE PROTOCOL Committee in their consideration of a full TELNET PROTOCOL specification. University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) University of California, Los Angeles (UCLA) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Attendance List at the Urbana NWG Meeting University of California, Los Angeles (UCLA) It is time to set serious schedules for the implementation of NCP's and Telnets. To facilitate matters, John Heafner of Rand has agreed to monitor each site's progress and test its implementation. Rand Corporation Rand Corporation Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) University of California, Los Angeles (UCLA) In order to use our time in Atlantic City more effectively, I would like to organize the meetings around discussions of advertised topics, with published status reports and position papers. I envision our time being divided into three phases. University of California, Los Angeles (UCLA) Document No. 1 and NWG/RFC No. 107gave a very detailed description of connection establishment, connection termination and flow control over the Network. Throughout the implementation of the NCP it was discovered that the handling of ERR control commands, messages of types other than 0 (regular), 4 (nop), and 5 (rfnm), and messages with the From-imp bit on are not well discussed so that problems arise when they occur. The Protocol is not complete if the above situations are not handled clearly, and the Host-Host Protocol Glitch Cleaning Committee should take this into consideration. In this document, experience with these unfavorable situations and suggestions for handling are given: Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) INFORMATION REQUIRED FOR EACH SERVICE AVAILABLE TO THE NETWORK There are two classes of information which a site needs to provide for each service or process it makes available over the Network: i) information required by system programmers in order to establish a connection to the facility ii) information required by a user to gain access to and use the facility The above two basic kinds of information which need to be in each facility description will comprise a "functional document" (see RFC 115, NIC (5822,) for a description of functional documents and recommended procedures for updating them). University of California, Santa Barbara (UCSB), Computer Research Lab University of California, Santa Barbara (UCSB) University of California, Los Angeles (UCLA) By Initial Connection Protocol (ICP), I mean a third level protocol which is initiated by a user process at one site in order to contact a server process at another site. Typically, the user process will be a Telnet and the server process will be a logger, but there may be other cases. In this RFC, I wish to describe a family of ICPs suitable for establishing one pair of connections (one in each direction) between any user process and any server process, and to propose further a particular subset of this family as the standard ICP for connecting user processes to loggers on systems which accept teletype-like devices. Network Information Center (NIC) On page 7 of RFC 107, the RTS (1.) should be an STR. Ames Research Center The basic approach of transmitting an intermediate, device independent language which is translated into specific device codes at the receiving host is sound. It appears to be the only approach that will allow thought to be centered on picture descriptions. Ames Research Center This note is intended as a response to an RFC which suggested that nodes describe their graphics environment. University of California, Los Angeles (UCLA), Computer Science The following is my interpretation of the exchange between NCP's which would be necessary to carry out the Initial Connection Protocol of RFC123. Rand Corporation Rand Corporation Massachusetts Institute of Technology (MIT) Rand Corporation The purpose of RFC #111, as I interpret it, is two-fold: 1) To establish realistic implementation schedules and to make them known to the Network community so as to expedite everyone's planning of productive use of Network Services. 2) To uncover implementation techniques and strategies that were most successful and might be useful in future implementations. Rand Corporation Rand Corporation University of California, Santa Barbara (UCSB) On page 5 of RFC 107, at the end of the section titled 'V. Flow Control', the partial sentence: Each of these numbers is interpreted as "the number of 128ths of the current allocation" to be returned if it is in the range zero to 128... should read: ...if it is the range of zero to 127,... Harvard University Massachusetts Institute of Technology (MIT), Project MAC

545 Technology Square Room 201 Cambridge MA 02139 US +1 617 864 6900 x1458

Project MAC will host a Network Graphics Meeting on the 18th, 19th, and 20th of July 1971. University of California, Los Angeles (UCLA) The NWG meeting will be from 8 p.m., Sunday, May 16 through Wednesday evening May 19. Rand Corporation Rand Corporation A file transfer protocol is needed. Bushan's proposal would satisfy a particular current need that we have, as well as short-term envisioned needs University California Los Angeles (UCLA), Network Measurement Center (NMC) University California Los Angeles (UCLA), Network Measurement Center (NMC) On sending a message to a foreign site, the following situations can occur: 1. Destination IMP down - Type 7 message is returned. 2. Destination IMP up but destination IMP-HOST interface is down - Type 7 message is returned. 3. Destination IMP and IMP-HOST interface up, but IMP-HOST inter-face is not taking messages - Type 9 message is returned after IMP time-out (ask BBN for time). 4. Destination IMP and IMP-HOST interface up and IMP-HOST interface is taking messages - Type 5 (rfnm) message is returned. A suggestion for handling type 7 and type 9 messages has been made in NWG/RFC #117. In this document we would like to discuss in detail the problem: what should happen to the HOST-HOST protocol on receiving a rfnm? University California Los Angeles (UCLA), Network Measurement Center (NMC) University California Los Angeles (UCLA), Network Measurement Center (NMC) University California Los Angeles (UCLA), Network Measurement Center (NMC) University California Los Angeles (UCLA), Network Measurement Center (NMC) We should like to comment on a race condition discovered in the ICP as proposed in NWG/RFC #123. The problem arises when the server attempts to initiate a second connection to the user's receive socket and the first connection is not yet closed. Mitre Corporation International Business Machines (IBM) Mitre Corporation The formation of a committee to address the problems of achieving data sharing on the ARPA Network, as suggested by Arie Shoshani (RFC #140) is desirable at this point of network development. Massachusetts Institute of Technology (MIT), Lincoln Laboratory A socket is defined to be the unique identification to or from which information is transmitted in the network. The socket is specified as a 32 bit number with even sockets identifying receiving sockets and odd sockets identifying sending sockets. A socket is also identified by the host in which the sending or receiving processer is located. Massachusetts Institute of Technology (MIT), Project MAC The requirement that byte size 's' be 32-bits for the initial connection imposes some severe strains on some of the 36-bit machines. University of California, Los Angeles (UCLA) Dr. Roberts informs me that it is now unlikely that he will be able to attend the Monday afternoon session of the NWG meeting, but that he will be able to attend the Tuesday evening session. Massachusetts Institute of Technology (MIT), Lincoln Laboratory ***A WORKING PAPER*** This material has not been reviewed for public release and is intended only for use within the ARPA network. It should not be quoted or cited in any publication not related to the ARPA network. System Development Corporation (SDC) Bob Long at SDC noticed that the order in which messages go out to the network depend on the local NCP. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The Stanford Research Institute's Artificial Intelligence Group (SRAI in the four-letter abbreviations) expects connection to the ARPA net as a research center after conversion this summer to a TENEX from our current PDP-10. University of California, Los Angeles (UCLA) As a pedagogical device for describing functions such as the one below | | +----------------- | /: | / : | / : | / : | / : | / : -----+------------------------------------ | a | where two formulae, f1 and f2, are necessary for adjoining domains but the function is continous at the boundary point, I usually write the description in the form ARPA Network Note: This list includes all Network Liaisons and others who should receive initial distribution of formal documents. It supersedes RFC 95, and corresponds to Current Directory of Network Participants, NIC 5799. University of Illinois As of the date of the report, 26 April, the Illinois Site has complete operational hardware connecting the PDP-11 system with the IMP. SRI/Network Information Center System Development Corporation (SDC) In NWG/RFC #143a race condition in the ICP was described and a solution was suggested. The problem arises because the Host-Host protocol does not specify what the NCP should do when it gets more than one request of STR (or RTS) to the same socket. As a result this decision depends on the particular implementation: some may queue these requests (SDC for example), some will refuse a request if the socket is already connected (UCLA for example), etc. University of California, Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC) This is an informal statement of material discussed at the SJCC. There are two problems. 1. Movement of data from one site to another. 2. Interpretation of the data at receiving site. Massachusetts Institute of Technology (MIT), Project MAC Harvard University Massachusetts Institute of Technology (MIT), Lincoln Laboratory The current NCP Protocol says nothing about how hosts should assign socket numbers to process ports, except that the low-order bit is to specify socket gender (i.e., send or receive). Two recent proposals call for additional network-wide conventions on the 32-bit socket-number. The first proposal asks that a portion of the socket number be reserved for a network-unique user number for accounting and access control. The second proposal asks that the high-order 16 bits of the socket number be zero to assist smaller hosts in reducing the space required for socket number tables. It is recommended that both of these proposals be set aside. Because a large perturbation of the current NCP Protocol is required to provide adequate handles for accounting and access control, and because the socket number is already underpowered for its use, it is recommended that both proposals be set aside until serious consideration can be given to a major NCP Protocol overhaul The following three lists are those to be used for distribution of Network documents. List A should be used by sites when they distribute their own documents. to get RFC's to Liaisons as quickly as possible. All but local mail should be sent Air Mail. Lists B and C will be used by NIC in making distribution of copies to non-site Network Participants and to Station Agents. These Lists supercede RPC 95and RFC 155. For phone numbers and lists of names by sites see the Current Directory of Network Participants. Massachusetts Institute of Technology (MIT) University of California, Los Angeles (UCLA) Bolt Beranek and Newman (BBN) The Rand Corporation The Rand Corporation Bolt Beranek and Newman (BBN) Stanford Research Institute (SRI) Harvard University Stanford Research Institute (SRI) University of California, Santa Barbara (UCSB) Massachusetts Institute of Technology (MIT) University of California, Los Angeles (UCLA) Bolt Beranek and Newman (BBN) The Rand Corporation The Rand Corporation Bolt Beranek and Newman (BBN) Stanford Research Institute (SRI) Harvard University Stanford Research Institute (SRI) University of California, Santa Barbara (UCSB) MITRE Corporation International Business Machines (IBM) The data management discussions at the recent NWG meeting resulted in the formation of a Network Data Management Committee to be chaired by Doug McKay, IBM. University of California, Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC) University of California, Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC) The Rand Corporation The Rand Corporation We agree with the conclusions reached by Abhay, Bob, and Joel in RFC #167, "Socket Conventions Reconsidered," (see RFC #129, scheme #4) - especially the necessity for a major NCP overhaul. Our main departure in thinking from RFC #167 concerns the socket length. (See RFC #164, page 21.) Since there is an apparently serious TIP storage consideration, Rand- assigned sockets will have the high-order 16 bits zero. For the particular programs (current and pending) that Rand must access, repeatability of socket name (RFC #167, page 3) is not necessary for the user process and also not necessary for the server process except for initial contact (ICP) sockets. Massachusetts Institute of Technology (MIT) Massachusetts Institute of Technology (MIT) Massachusetts Institute of Technology (MIT) University of California, Los Angeles (UCLA) There are at least the following three views on the use of byte size for network connections*: 1) Byte size should not be used at all. 2) Byte size is solely for the convenience of NCP's. 3) Byte size choice is a user-level prerogative. Ames Research Center

Moffett Field CA 94035 US

As more nodes are connected to the ARPA network, the types of graphical display processors available to users is quite varied. To attempt to facilitate the transmission of graphical information over the network, a device independent description of a display is described. The using host may make any conversions necessary to realize the picture on a specific device. It is also possible to interpose a form machine as proposed by Heafner and Harslem in RFC #94. Some of the items and entities described herein were first discussed by Steve Crocker in RFC #86. It is intended that this description is to be oriented to a refresh display with point, vector, and character drawing capability, these types of devices include the IBM 2250, IMLAC PDS-1, the DEC 338, and DEC 340, as well as the Evans and Sutherland LDS-1. However, direct video storage tube devices represented by the ARDS, Tektronix and Computer devices can also serve as clumsy interactive devices. Hard copy devices, such as microfilm or plotters, can also be used at the using host's discretion. The MITRE Corporation Bolt Beranek and Newman (BBN) Today Steve Crocker asked me to announce that from now on link numbers 2-71 (decimal), inclusive, are to be valid for use in connections. Bolt Baranek and Newman (BBN)

50 Moulton Street Cambridge MA 02138 US +1 617 491 1850 x441

As noted in RFC #164(page 35), a subcommittee of the NWG, under the chairmanship of Abhay Bhushan, is currently generating proposals for a "data transfer protocol" and a "file transfer protocol". The subcommittee has decided that the file transfer protocol should provide standard methods for requesting the transfer of a file but should not, at this time, attempt to standardize file naming conventions, access control conventions, and the like. Thus a user who is, for example, trying to store a file on a remote Host will be required to use the file naming conventions appropriate to the remote Host. Given the above point of view, it becomes imperative for users to have some source of information about Host file conventions. AMES RESEARCH CENTER This RFC is intended to modifiy the proposal for a device independent graphical display description discussed in RFC #177. Thanks are due to Stan Mantiply of Ames for his ideas. The main changes are in the definition of coordinate areas to avoid one problem encountered with the old definition and to provide more flexibility. Terms used are those defined in RFC #177. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC), ARPA Network Information Center The Network Information Center is working to compile a list of all Site-produced reports which are of interest to Network participants. Reports procuced under ARPA IPT contracts and any other relevant reports produced by the Sites on information processing, network planning, the hardware and sorfware for the projects, and some general reports on the subject concerns of individual Sites, are being identified, to be listed and acquired for the Network Information Center collection. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC), ARPA Network Information Center The Network Information Center asks that whenever basic manuals or handbooks are produced by Network participants, a sufficient quantity be made to supply NIC with copies for distribution. International Business Machines (IBM), Thomas J. Watson Research Center International Business Machines (IBM), Thomas J. Watson Research Center This RFC is being circulated as an information RFC. Its intent is to convey some of the thinking and philosophy that went into IBM's network protocol and overall network design.