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. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Rand Corporation Rand Corporation As of 15 July we had contacted or been contacted by the sites listed below. The matrix indicates the elements of Network software we have verified at each site. University California Los Angeles (UCLA) Rand Corporation Rand Corporation Massachusetts Institute of Technology (MIT) University California Santa Barbara (UCSB) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The purpose of this protocol is to provide at each site a standard mechanism to receive sequential files for immediate or deferred printing or other uses. System Development Corporation ( SDC) Rand Corporation Rand Corporation We have exercised Lincoln Labs Network software as follows: NCP, ICP, ASCII Telnet (user and server), login procedure, access to CMS, and operator and console communication. All behave according to current specifications. University California Los Angeles (UCLA), CCN University California Los Angeles (UCLA), NMC We have noticed a possible deadlock situation which may arise using the Initial Connection Protocol (ICP) specified in Document #2 (NIC #7101 in the Current Network Protocols Notebook NIC #7104). University California Los Angeles (UCLA), Computer Science Dept, NMC

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

I would like to collect information on the use of socket numbers for "standard" service programs. For example Loggers (telnet servers) Listen on socket 1. What sockets at your host are Listened to by what programs? Massachusetts Institute of Technology (MIT), Project MAC The next meeting of the Network Working Group will be hosted by M.I.T.'s Project MAC in Cambridge, Massachusetts. Harvard University The current "give back" - "return" scheme seems to put the cart before the horse in that the "return" command indicates the amount of space the sending host is returning rather than the amount of space it has left after decrementing by the amount specified in the "give back" command. Considering the fact that allocation counters at sending and receiving hosts may get out of synchronization and the fact that the receiving host has a preemptive priority in the allocation of its resources, it is only logical that the receiving host be able to find out exactly how much of its buffer space a sending host thinks it can claim. NWG Steering Committee M.I.T.'s Project MAC has agreed to host the next Network Working Group Meeting in Cambridge, Massachusetts. Bolt Beranek and Newman (BBN) During the week of 16 August, we installed a new version of the IMP system, version 2505. Rand Corporation As of August 21 we had performed the following verifications with the sites listed below. These verifications were done on an arranged basis and do not indicate any degree of continuous availability. Bolt Baranek and Newman (BBN) By early December there will be six Terminal IMPs incorporated into the network, with additional Terminal IMPs scheduled for delivery at a rate of about one per month thereafter. For this reason the implementation of network protocols (and deviations from them) may be of interest to the network community. This note describes the choices made by the Terminal IMP system programmers where choices are permitted by the protocols, and documents some instances of non-compliance with protocols. University of California, Santa Barbara (UCSB), Computer Research Lab The following documents are hereby revised: 1) 'Specifications for Network Use of the UCSB On-Line System [16 October 70, RFC 74, NIC 5417], (2) 'Network Specifications for Remote Job Entry and Remote Job Output Retrieval at UCSB' [22 March 71, RFC 105, NIC 5775], and (3) 'Network Specifications for UCSB's Simple-Minded File System' [26 April 71, RFC 122, NIC 5834]. Bolt Baranek and Newman (BBN) To help us expand our role as NCC, we will be changing the status reporting facility of the IMP. The change will take place within the next month and should be transparent to the hosts. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The Network Information Center has planned to provide service for network users on a regular basis Monday through Friday. Bolt Baranek and Newman (BBN) It should be noted that the Terminal IMP will be unable to directly implement the currently-proposed mailbox protocol for the following reasons: The Mitre Corporation (MITRE) IN EACH TELNET IMPLEMENTATION, A LIST OF HOST NMEUMONICS IS PROVIDED FOR THE USER TO INDICATE THE SERVING HOST DESIRED. CURRENTLY, EACH SITE EMPLOYS THEIR OWN SPECIAL LIST. RATHER THAN REQUIRE THE USER TO BE COGNIZANT OF THE IDIOSYNCRASIES OF EACH LIST, ESPECIALLY WHEN CHAINED THROUGH SEVERAL HOSTS VIA TELNET, IT HAS BEEN RECOMMENDED THAT STANDARD HOST DESIGNATORS BE ADOPTED. THE FOLLOWING LIST OF SIX CHARACTER DESIGNATORS IS PROPOSED AS THE STANDARD LIST. REGISTER ANY OBJECTIONS BY 3 OCTOBER TO P. KARP (703) 893-3500 X2391, X2318. AN OFFICIAL POLICY AND IMPLEMENTATION DATE WILL BE SET ON 8 OCTOBER. Rand Corporation Rand Corporation The attached memo indicates data rates typical of our use of RJS at UCLA CCN. Bolt Baranek and Newman (BBN) The second statement before statement 20 in the FORTRAN program on page 7 of RFC #70should read N=1 University California Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC) I suggest 8 character names and the following list: National Bureau of Standards (NBS) The present protocol for communication between a TIP and attached terminals requires character-oriented transmission and provides for no error control. In the design of this protocol, it was apparently assumed that the majority of terminals attached to a TIP would be interactive, be normally used in a character-by-character mode both for transmission to and from the terminal, and normally support a human user who would in effect be in the communication loop. The human user would thus be in a position to detect any significant telecommunication-induced errors both by direct observation of the character stream and, more importantly, by examining the computer output in the context of his ongoing interaction. The effectiveness of this means for error detection and initiation of corrective measures when necessary is not adequate in the following cases: The Rand Corporation The Rand Corporation Massachusetts Institute of Technology (MIT), Project MAC At the last Network Graphics meeting held in July at M.I.T., we tentatively scheduled the next Network Graphics meeting which is being hosted by Stanford AI, for October 17, 18, and 19. Massachusetts Institute of Technology (MIT) Massachusetts Institute of Technology (MIT) We agree with Peggy Karp (See RFC #226) that there would be some benefit in standardizing the symbolic host names used in TELNET programs. Bolt Baranek and Newman (BBN) Beginning with this RFC, BBN will report on the status of most Network Hosts approximately once every two weeks. The information for these reports will be gained from talking to people at each site, and from experimental "data". These data will be the results of daily attempts to log into each of the Hosts which might be accessible to a Network user; the attempts will have been made from the BBN prototype Terminal IMP at a random time each weekday. University of California, Los Angeles (UCLA), Computer Science Department, NMC In RFC #226, Peggy Karp suggested that there be a set of standard host names, that the names be 6 characters in length, and gave a partial list. In RFC #229, I suggested 8 character names and gave a longer list. Here I present my list again with some modifications. I also suggest that as far as possible the Standard host names be consistent with the site names used by the Network Information Center. It also seems to me to be a good idea to consult with each host's technical liaison officer before assigning that host's name. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The NIC strongly favors standardization of host names. University of California, Los Angeles (UCLA), Campus Computing Network (CCN) University of California, Los Angeles (UCLA), Campus Computing Network (CCN) CCN is in full agreement that a standard set of host mnemonics should be selected. However, your proposed set is not fully satisfactory. Bolt Baranek and Newman (BBN) Due to extensive typographic errors in RFC #235, I have decided to reissue the first of our experimental site status reports. In compiling RFC #235, I followed the principle that timeliness was somewhat more important than extremely careful editing; this seemed to me to be in keeping with the original RFC philosophy. I am sorry for any embarrassment this may have caused to anyone associated with the Network, and accept full responsibility for the content of RFC #235. I will try to do a better job in the future. Bolt Baranek and Newman (BBN) Several times we have been asked if computers can be connected through serial communication lines to ports on the Terminal IMP's Multi-Line Controller (MLC) [related questions about the level of software support provided by the Terminal IMP to such a connection, have also been raised]. In the past we have said, "Please don't!" We now say, "Sure, but will that really help you the way you think it will?" International Business Machines (IBM), Thomas J. Watson Research Center International Business Machines (IBM), Thomas J. Watson Research Center International Business Machines (IBM), Thomas J. Watson Research Center Massachusetts Institute of Technology (MIT), Project MAC

+1 617 864 6900 x1450

Guaranteed arrival reservations for rooms at the Hotel Sonesta in Cambridge, Massachusetts have been made for NWGM attendees who have made reservations through Project MAC. Massachusetts Institute of Technology (MIT), Project MAC The next Networks Graphics Meeting has been scheduled to commence the evening of Sunday, November 21st and adjourn Tuesday, November 23rd. The Stanford Artifical Intellegence Project will host the meeting. The MITRE Corporation (MITRE) In RFC #226, BBN's TENEX list of Host names was set up as a strawman set of standard Host names. Comments received since then (an RFC actually generated comments!!!) have influenced me to propose the following general rules for forming Host names. University of Illinois, Center for Advanced Computation

Urbana IL 61801 US +1 217 333 6375

The purpose of this message is to pass on to all members of the Network an agreement reached between Messrs. Steve Crocker of ARPA and R. F. Borelli of the University of Illinois. The Center for Advanced Computation has agreed to study the feasibility of a coordinating point for purchases of equipment and supplies to be used on the network. University California Los Angeles (UCLA), Computer Science, NMC There are several aspects of the proposed Data Transfer Protocol (RFC #171) and File Transfer Protocol (RFC #172) which we believe could use further clarification and perhaps revision. Interest in transferring larger amounts of data than is typically sent via the usual TELNET connection is increasing, and at least at UCLA-NMC implementation attempts have pointed out several difficulties with the proposed protocols. Computer Corporation of America (CCA)

575 Technology Square Cambridge MA 02139 US +1 617 491 3670

The USAF Environmental Technical Applications Center (ETAC) is providing weather data for the ARPA Network. Ultimately there will be ten years of high quality surface and upper air weather observations, as well as hemispheric grid point analyses. The observations are generated by approximately 5000 surface and 1200 upper air stations, distributed all over the world. Bolt Baranek and Newman (BBN) The purpose of this RFC is to report on the recent status of most Network Hosts. Stanford University (SU), Artificial Intelligence (AI) Laboratory Stanford will be the site of the second network graphics meeting. Bolt Baranek and Newman (BBN) We will shortly install (or perhaps will have already installed) a new version of the IMP system, Version 2513. The new version incorporates two principal changes: Bolt Baranek and Newman (BBN) The normal method of connecting a Host computer to the ARPA Network is, and will continue to be, placing an IMP at the Host site and making a short-distance hard-wire connection. However, during the past several months we have become increasingly aware of the occasional desire to interface a Host to some IMP via a long-distance connection (where long-distance, in this context, is any cable run longer than 2000 feet but may typically be tens of miles) via either a hard-wire or telephone circuit. We believe that any good solution to the general problem of interfacing Hosts to IMPs must satisfy at least the following criteria: 1) The characteristics of the connection should be such that the undetected error rate can be expected to be extremely low. 2) The bandwidth of the connection should not be intrinsically limited to a low value. 3) The nature of the connection should be such that the Host may establish multiple network "conversations", i.e., it should have all the power of a normal Host connection. Massachusetts Institute of Technology (MIT) University of California, Los Angeles (UCLA) Bolt Beranek and Newman (BBN) Rand Corporation Rand Corporation Bolt Beranek and Newman (BBN) Stanford Research Institute (SRI) Harvard University Stanford Research Institute (SRI) University California Santa Barbara (UCSB) This Paper is a revision of RF 172, Mic 6794. The changes to RFC 172are given below. The protocol is then restated for your ocnvenience. Bolt Beranek and Newman Inc. (BBN) This RFC reports on the status of most.Network Hosts from October 26 to November 5 Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from November 8 to November 19. University California Los Angeles (UCLA), Computer Science Department, Network Measurement Center (NMC) It was suggested at the recent network graphics meeting (@ SAIL 21-23 November) that it would be a good idea to include in the Resources Notebook information about the graphics facilities at each site. University California Los Angeles (UCLA), Network Measurement Center (NMC) At UCLA-NMC we have recently completed implementation of a program which utilizes UCSB's storage capability via their Simple Minded File System (See RFC #122by Jim White for a description of SMFS). The use of the program is detailed in Appendix A. We learned a number of things in the implementation effort and subsequent usage. We think a number of these apply towards the development of a net- word-wide File Transfer Protocol, and we hope to stimulate further dis- cussion of these issues. We discovered some things in the UCSB protocol that we would like to see included in the network-wide protocol, and we see some things that are in the currently proposed net protocol and are unfortunately absent from the UCSB protocol. Bolt Baranek and Newman (BBN) In the process of generating RFC #271we have discovered a set of errors in BBN Report No. 1822 (NIC 7958). Bolt Baranek and Newman (BBN) We are planning to install a new version of the IMP System, version 2514. The new version is scheduled for field installation Thursday, January 13, 1972 between noon and 1 PM EST, and will require the assistance of IMP-site personnel at each site. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The Network Information Center is a logical place to handle this problem of Standard Host Names and so the ball now rests here. This is clearly a delicate subject with people having strong feelings and attachments to names. No past proposal, including RFC 247, NIC 7668, has yet achieved any acceptance. This identification seems a natural thing and should be taken into account in setting up a naming scheme. Therefore, the following proposal is offered which I hope may be satisfactory to everyone. The Mitre Corporation (MITRE) Actual experiences and experimentation with network systems and subsystems will be an important supplement to existing NIC documentation. For this reason, MITRE, to facilitate local user access to network resources, is planning to establish a local GUIDE TO NETWORK USAGE to supplement the Resources Notebook and other NIC documentation. The Guide will be tailored to the needs of MITRE users and will contain information on network systems and subsystems. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The Network Information Center is planning to run a course on the use of its Online System (NLS), including use of the Journal, at SRI. The dates are to be Nov. 29, 30. Massachusetts Institute of Technology (MIT), DMCG University California Los Angeles (UCLA), CCN RAND Corporation RAND Corporation Bolt Beranek and Newman Inc. (BBN), NET Harvard University Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) University California Santa Barbara (UCSB) The file transfer committee met and discussed the Mail Box Protocol RFC 221, NIC 7612. The potential utility for the mechanism was confirmed and a couple of changes suggested. We first give the changes and then restate the Protocol. Stanford Research Institute (SRI), Augmentation Research Center (ARC) The enclosed list of host names is a draft. Bolt Baranek and Newman (BBN) On November 16, an informal meeting was held at UCLA to discuss prospects for a network standard Remote Job Service (RJS) protocol. Project MAC The second Network Graphics Group Meeting was convened at the Stanford Artificial Intelligence Lab at 6:00p.m. Sunday, November 21st. University of California (UCLA), Los Angeles, Campus Computing Network (CCN) Case Western Reserve University (CWRU) Not much has been written about graphics on the ARPANET when the volume of the NIC collection is considered. Presently it contains some 8000 entries of which only about 20 are on the subject of graphics. The reason is probably similar to that given by L. G. Roberts in A FORWARD LOOK (NIC 7542) as the reason that data base sharing or software sharing will not be important topics for several more years: the NET hasn't been up long enough for interested people to have enough of the facts to know if it is feasible and to think creatively. This paper is therefore aimed at bringing together the present state of graphics on the NET for the newcomer and attempting to add a little more distance to the ground covered so far. I will start with an overview, then proceed to briefly describe past work, and finally add some of my own thoughts. The Mitre Corporation (MITRE) Georgetown University is designing a Learning Resource Center (LRC), part of which may consist of a system to enable computer query (hopefully on-line) of G.U.'s Library holdings. The ARPA community might be of assistance in either of two ways: 1. One or more organizations may have a Library Retrieval System that they would like to share with Georgetown 2. Since there probably are needs for such a system at most organizations, and since it would be highly beneficial for one organization to be able to query other library holdings as well, and subsequently arrange for inter-library loans, the ARPA community might undertake to design a Network Library Information System. If sufficient interest in such a system exists, a working group could be set up to establish the necessary protocols and iron out details of the system. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from December 6 to December 18. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from December 20 to December 30. Stanford Research Institute (SRI), Augmentation Research Center (ARC) The enclosed is what we hope will be accepted as a list of official formal host names and nicknames. As no other subject worked on by the NWG has generated so much comment, it is worthwhile to review briefly how this list came into being. The need for some standard set of names recognized by NCP's and Telnets and usable on hardcopy to designate a persons affiliation had been recognized for some time and several sets of names were in use. International Business Machines (IBM), Thomas J. Watson Research Center The bibliography is broken into seven subject areas - general data structures, data description, data conversion, data management, data security, data transmission, and computer network design. Two of these areas, general data structures and data management, cover a very broad range of subjects: however, in these two areas, only entries that seem to be specially pertinent to computer networks and data sharing are included. The bibliography also contains an index of authors. International Business Machines (IBM)

+1 914 945 1159

Massachusetts Institute of Technology (MIT), Project MAC The Mitre Corporation (MITRE) University of Illinois Massachusetts Institute of Technology (MIT), Project MAC Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from January 3 to January 15. Massachusetts Institute of Technology (MIT) As mentioned in RFC 265, the opcode of '00' is set aside for the clarify the use of 'set data type' in file transfer operations. In many systems such as Multics at MIT, there is no provision to identify the type of data (i.e., ASCII or numeric) stored in files. Bolt Baranek and Newman (BBN) University of Illinois, Urbana, Center for Advanced Computation

333 Advanced Computation Building Urbana IL 61801 US +1 217 333 8060

We intend to build an Information Management and Statistical System for the ILLIAC IV. It is intended to support various areas of research whose problems are ILLIAC IV suited and whose data bases are large. Bolt Baranek and Newman (BBN) On Saturday morning, March 4, 1972, at 0800 EST the BBN IMP (#5) will go off the air to allow for a move of the equipment to a new location in BBN's facilities. University California Santa Barbara (UCSB), Computer Research Laboratory The following are three lists to be used for distribution of Network documents. Bolt Baranek and Newman (BBN) In response to a recent minor flurry of confusion, it seems worth announcing publicly the fact that new IMPs are tested (almost always) on the ARPA Net here at BBN before delivery to the intended site. Accordingly, sites should not be surprised to receive RFCs or at least RSTs from IMPs or Hosts they thought didn't exist, or at least did not exist yet. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from January 31 to February 11. Rand Corporation Massachusetts Institute of Technology (MIT), DMCG

545 Main Street Cambridge MA 02139 US +1 617 864 6900 x1458

Several months ago a SURVEY program was implemented on the MIT-DMCG ITS PDP-10 system to aid in gathering information on the availability of various HOSTS on the ARPANET. The purpose of this Request for Comments is threefold: 1. to inform the Network Working Group of the existence of this information gathering service and about getting access to it, 2. to present the results of SURVEY for its first few months, and 3. to correct errors in our data or collection methods. Massachusetts Institute of Technology (MIT), Project MAC The objective of this workshop is to arrive at a unified convention for ARPANET data and file transfer. Massachusetts Institute of Technology (MIT), Project MAC Our experience with ad hoc techniques of data and file transfer over the ARPANET together with a better knowledge of terminal IMP (TIP) capabilities and Datacomputer requirements has indicated to us that the Data Transfer Protocol (DTP) (see ref 1) and the File Transfer Protocol (FTP) (see ref 2) could undergo revision. Our effort in implementing DTP and FTP has revealed areas in which the protocols could be simplified without degrading their usefulness. This paper suggests some specific changes in DTP and FTP that should make them more useful and/or simplify implementation. The attempt here is to stimulate thinking so that we may come up with a better protocol at the forthcoming Data and File Transfer Workshop (see ref 3). University California Santa Barbara (UCSB), Computer Research Laboratory Bolt Baranek and Newman (BBN) We are currently considering a redefinition of the IMP-to-Host error message types (type 1 and type 8) and the creation of additional IMP-to-Host error message types. We believe that these changes will assist the Hosts in determining appropriate recovery action, without causing any serious reprogramming problems. Our current plans are to install these changes within a few months; therefore we should be informed of any strong negative reactions relatively quickly. Raytheon Corporation Current development of Computer Based Instruction (CBI) systems seem to be directed toward two types of system: 1.) Small to medium scale, dedicated, stand alone systems (such as the IBM 1130, 1500, 1800 complexes) or medium scale systems with dedicated network implications (such as TICKET), and 2.) Large, centralized, dedicated systems with dedicated network implications (such as PLATO). Mitre Corporation The next network graphics working group meeting has definitely been scheduled for April 16-18 at The Mitre Corporation, McLean, Virginia. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from February 14 to February 25. International Business Machines (IBM) International Business Machines (IBM) The meeting had two different phases. The first included presentations of applications of networks and development work in the design to allow data sharing in a computer network, the second was a working meeting in which was discussed what the data management working group should do. University California Los Angeles (UCLA), Computer Science Department, NMC University California Los Angeles (UCLA), Computer Science Department, NMC

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

At the October 1971 Network Working Group Meeting, I promised to promptly produce a document which clearly and succinctly specified and explained the Official Telnet Protocol. This document fails to meet any part of that promise. This document was not produced promptly. This document is neither clear nor succinct. There is NO Official Telnet Protocol. The following pages present my understanding of the ad hoc Telnet protocol. There are some who have serious questions about this protocol. The proposed changes to the protocol are given in Section IV. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from February 28 to March 10. The ETAC Terminal IMP (Network address 148) was installed during this period. MITRE Corporation This RFC is in response to Tom O'Sullivan's probe for comments on Computer Based Instruction. MITRE is currently doing some pre liminary work in the area,at the present time limited to use of CAI-related network resources. The most expedient way for me to respond is by attaching excerpts taken from a recent status report prepared for internal MITRE use, intended for staff not generally familiar with the ARPANET. Comments directed at specific items in Tom's attachment will follow in a future RFC. We welcome comments on our activities and would like to participate in any CBI dialogs that take place. University California Los Angeles (UCLA), NMC

3804 Boelter Hall Los Angeles CA 90024 US +1 213 825 4864

University California Los Angeles (UCLA), NMC

3804 Boelter Hall Los Angeles CA 90024 US +1 213 825 4733

The Network Measurement Group would like to establish a network standard socket number for a Process Discard service (not all HOSTs need cooperate.) To do this, it is necessary to know which sockets at each HOST have already been allocated to standard network functions. University California Los Angeles (UCLA), NMC On March 17, 1972, at MIT project MAC, the following group met to discuss plans to perform measurement experiments on the ARPANET: The purpose of the meeting was to discuss existing and planned measurements of network and HOST behavior. University of California, Los Angeles (UCLA), NMC There will be a meeting to discuss Remote Job Entry (RJE) protocols in the ARPA Network on Friday 21 April 72. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from March 13 to March 24. During this period the SRI-AI computer became a server. Massachusetts Institute of Technology (MIT), Project MAC On April 14 and 15, 1972, a Data and File Transfer Workshop was held at M.I.T., Cambridge, Mass. University of California, Los Angeles (UCLA), Computer Science, NMC I hereby propose the following changes to the Telnet protocol. If no substantial negative response is received by 15 May 72 it will be assumed that these changes are desired and should be incorporated in any "Official Telnet Protocol". First I suggest that we drop the idea of a "minimum" implementation and require a standard implementation which includes all aspects of the protocol. Second I suggest that we eliminate the DATA TYPE signals. Third I suggest that we do away with HIDE YOUR INPUT signal. SRI/Network Information Center Bolt Beranek and Newman (BBN) This RFC reports on the status of most Network Hosts from March 27 to April 7. Bolt Beranek and Newman (BBN), NET We are planning to release IMPSYS 2600 on May 15, 1972, between 12 noon and 3 p.m. E.D.T. As discussed at the March 16 seminar held at BBN, this release constitutes a major change to the IMP program. Because of the magnitude of the change, the system will be released on an experimental basis. If problems develop, then the current system, IMPSYS 2514, will be reloaded and the cutover for IMPSYS 2600 will be rescheduled for some later time. Bolt Beranek and Newman (BBN) This RFC reports on the status of most Network Hosts from April 10 to April 21. Bolt Beranek and Newman (BBN) Vint Cerf of UCLA Network Measurement Center has just indicated to us a requirement to carry out certain performance experiments on the network prior to installation of the new IMP software on May 15. University of California, Santa Barbara (UCSB), Computer Research Laboratory The former interface to the network for our 360-75 was replaced by a production unit similar to the NASA- AMES and USC versions. This controller went into operation 1 May 1972. We would be pleased to hear of any difficulties network users encounter, while operating with UCSB, that might be related to this unit. Thank you. The MITRE Corporation At its meeting on April 16-18 the network Graphics working group began to consider the definition of levels of protocol for graphic Input Protocol. Bolt Beranek and Newman (BBN) Raytheon Company The proposed change to the TELNET protocol calling for one standard protocol and dropping the idea of minimum implementation seems reasonable at this time. Bolt Beranek and Newman (BBN) This RFC reports on the status of most Network Hosts from April 24 to May 5. Bolt Beranek and Newman (BBN) This RFC reports on the status of most Network Hosts from May 8 to May 19. University of Illinois MPSX is a newer version of the IBM project MPS, used for integer programming. From what I've been told, MPSX outperforms the previous package. In addition, it has available a feature of mixed integer programming. University of California, Los Angeles (UCLA), Computer Science, NMC The consideration of using space satellite transmission links in the ARPANET should be cause for some thought by the parties making use of the network. University of California, Los Angeles (UCLA), Computer Science, NMC I suggest that for debugging and measurement purposes those hosts which are willing implement an "Echo" process. University of California, Los Angeles (UCLA), Computer Science, NMC I suggest that for debugging and measurement purposes those hosts which are willing implement a "Discard" process. University of California, Los Angeles (UCLA), NMC I propose that there be a czar (me ?) who hands out official socket numbers for use by standard protocols. This czar should also keep track of and publish a list of those socket numbers where host specific services can be obtained. University of California, Santa Barbara (UCSB) For the past year UCSB has provided free use of the UCSB On-line System to Network sites. Recharges for this service are being paid for by the Computer Research Lab with funds out of our current ARPA contract. Connect time for the month of April totaled 152 hours. Presently, all users are running on the same account: User Number=196, ID Code=57372, User Name=ARPA. As such, it is difficult to monitor the amount of use by each site. Consequently, we are changing the login procedure for Network users, effective 1 June 72. University of California, Los Angeles (UCLA), School of Engineering and Applied Science, Computer Science Department

3804 Boelter Hall Los Angeles CA 90024 US

(tips) Information form about ARPANET TIPS: We are attempting to provide additional information for TIP users of the NET. The availability of such information should allow more flexibility to TIP users and thereby make NET use easier. Massachusetts Institute of Technology (MIT), Project MAC University of Hawaii (UH), ALOHA SYSTEM Long transmission delays such as those inherent in satellite communication are most certainly a cause for concern among users of remote interactive systems. Since the University of Hawaii will, by the end of this year, be linked to the ARPANET via satellite, the consequences of such delays are perhaps of more immediate concern to us than to current members of the surface net. Consequently the BCC 500 research group here has been studying various solutions to the problems of buffer allocation, partitioned echoing, etc. re-introduced in RFC 346. Generally, the solutions come from extensions to the original design concepts of the BCC 500 distributed communication system. Bolt Beranek and Newman Inc. (BBN), ARPA Network Control Center(NCC)

50 Moulton Street Cambridge MA 02138 US +1 617 661 0100

Bolt Baranek and Newman (BBN) We have still not managed to get the new IMP system up. Massachusetts Institute of Technology (MIT), DMCG In response to RFCs 347 and 348, ECHO and DISCARD, MIT-DMCG (Host 106) now has deamon processes that will respond to RFCs on sockets 7 and 9. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from June 5 to June 16. SRI/Network Information Center National Bureau of Standards Bolt Beranek and Newman Inc. (BBN) You will shortly be sent a revised version of the "TIP User's Guide." Besides now having a loose leaf format, mainly descriptions of new commands have been added. Appendix B will be an alphabetical list of all TIP commands. Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from June 19 to June 30. University of California, Los Angeles (UCLA), Campus Computing Network (CCN) Chuck Holland's draft proposal (RFC #360) is an excellent document, very complete and consistent Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from July 17 to July 28. Bolt Baranek and Newman (BBN) The International Computer Communications Conference, scheduled for 24-26 October 1972 at the Washington, D.C. Hilton Hotel, is a newly organized conference intended to address a broad set of issues in the Computer Communications field. Approximately 17 sessions are currently planned for the conference. The social implications of this field are a matter of widespread interest that reaches society in almost all walks of life; education, medicine, research, business and government. All these areas will be affected as the field develops. Stanford Research Institute (SRI), Augmentation Research Center (ARC) I called Bob Kahn and had a good chat with him about some aspects of the ICCC meeting demonstration. Stanford University, Artificial Intelligence (AI) It would be nice to be able to have documents stored in computers that could include arbitrary characters and to be able to display them on any CRT screen, edit them using any keyboard, and print them on any printer. The object of this memorandum is to suggest how to get there from here with special reference to the ARPA network. Bolt Baranek and Newman (BBN) There are two significant developments in the operation of the network which should be of interest to all sites: Bolt Baranek and Newman (BBN) This RFC reports on the status of most Network Hosts from July 31 to August 4. University of California, Los Angeles (UCLA), Campus Computing Network (CCN) IBM's Time Sharing Option ("TSO") is now available at CCN for use via the Network with Telnet Protocol. University of Illinois, Center for Advanced Computation There have been several efforts in the past few years to develop high quality libraries of mathematical and statistical subroutines. Some of the projects mentioned in the literature include: 1. The Bell Laboratories numerical mathematics program library project. 2. IMSL Inc.: IMSL Library I, mathematical-statistical computer subroutines 3. The NATS (National Science Foundation,Argonne Laboratories, Stanford and Texas) joint project on the Wilkinson linear algebra routines. The ARPA Network could further enhance the desirability of such libraries as they would become another sharable network resource. Although the diversity of network computing no doubt requires an equally diverse set of mathematical software, and in spite of the fact everyone has their own software hangups - not to mention hardware!, it seems everyone could benefit from some type of information interchange regarding mathematical software of interest. Massachusetts Institute of Technology (MIT), Project MAC The following comments pertain to the File Transfer Protocol, NWG/RFC 354. The comments include errata, further discussion, emphasis points, and additions to the protocol. I shall incorporate these comments into the main protocol document after we have had sufficient experience. Bolt Beranek and Newman Inc. (BBN) Bolt Beranek and Newman Inc. (BBN) This is the second letter to TIP users. The first was RFC #365. There will be more letters to TIP users as they seem to us to be a good way to keep you informed about what's going on. We suggest you keep these letters with your TIP User's Guide (TUG) as we will use the letters to provide documentation of TIP system changes which are made before we can get TUG revisions printed and distributed. (It is almost inevitable that the TUG revisions follow actual system changes. Further more, these letters will allow us more discussion of new commands than in TUG.) University of California, Los Angeles (UCLA), Campus Computing Network (CCN)

+1 213 825 7438

University of California, Los Angeles (UCLA), CCM Massachusetts Institute of Technology (MIT), Lincoln Laboratory (LL) Through this RFC, I am registering my objection to two of the three suggestions for changing the TELNET protocol as described in RFC 328 and am adding my suggestion for the interpretation of the TELNET Reverse Break Control Code. Bolt Beranek and Newman Inc. (BBN) This note describes two changes to the IMP-Host communication protocol described in BBN Report 1822 and revised in RFC 381. The first deals with the IMP-to-Host interface and the 30-second timeout mechanism on each IMP transmission to the Host. The second deals with the Host-to-IMP interface and proposes a new timeout mechanism. These changes are independent; in statement and in implementation. We invite comments on each proposal. If no adverse comments are received, they will be installed in the network on Tuesday, October 10 (if serious adverse comments are received, action will be delayed until early November). Bolt Beranek and Newman Inc.(BBN) This note provides a description of the switches on the front panel of IMPs and TIPs that are important to the correct operation of the network software. We have had some difficulty in the past when certain of these switches were set incorrectly, This RFC will be updated as necessary, to notify site personnel of changes to the settings. University of Illinois, Center for Advanced Computation, ANTS

+1 217 333 9354

I have obtained some feedback concerning my suggestion in RFC 474 that the Working Group meeting be held here on May 11, 1973. University of California, Santa Barbara (UCSB)

+1 805 961 3454

University of California, Santa Barbara (UCSB)

+1 805 961 4047

At present, users with TEKTRONIX or IMLAC terminals or with systems that support the proposed level 0 graphics protocol can access UCSB graphics. Listed below are the ICP sockets for the currently supported terminals and protocols. University of California, Santa Barbara (UCSB) Two new commands have been added to UCSB's Simple Minded File System (SMFS). University of Illinois, Center for Advanced Computation Conversion of NGP-0 coordinates to floating point PDP-10 coordinates was discussed in RFC #387. In general, however, it is undesirable to convert NGP coordinates to floating point coordinates because real devices require integer addressing. This week the RAND IMP was temporarily removed from the Network and a new IMP was installed at ISI. This is to correct a typographic error in RFC# 404. Bolt Beranek and Newman (BBN) This note is a reminder that the procedures suggested in RFC # 381 for scheduling IMP software maintenance have now been in effect for a period of about two months. Massachusetts Institute of Technology (MIT), DMCG Massachusetts Institute of Technology (MIT), DMCG Bolt Baranek and Newman (BBN), NET University of California, Los Angeles (UCLA) The following idea for a protocol (or service) is offered as an aid to network use for new users: a single billing and account creation and validation system, so that a manager of a "goal oriented project" could: authorize a set of user's ids to gain access to and utilize resources at the entire or a specified subset of the server hosts. create a set of accounts which the users will expend, and which will be used as the breakdown for a single bill to be presented to the project manager. Bolt Beranek and Newman (BBN) The IMP currently delays accepting input from a Host for 30 seconds after the Host has come up. This delay serves to allow the fact that the Host is up to propagate through the network. Massachusetts Institute of Technology (MIT), MULTICS Two recently-installed features of the Multics Network software might be of general interest to the Network community, and should be of particular interest to those who use Multics via TIP's: The attached document is the HELP file for the Utah-10 implementation of the User FTP Process. This is what the user has typed on his console when he types 'HELP cr' and as such is the only documention produced to date. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The ARC PDP-10 system will be unavailable for ARC and NIC users from Friday, November 17 (6:00 pm PST ) through Sunday, November 26. (10:00 pm PST). Bolt Baranek and Newman (BBN) As actual or attempted Network use has grown, it has become increasingly apparent that users with real problems to solve are not afforded the kinds of software assistance and consulting services normally provided by computer service facilities. University of California, Los Angeles (UCLA), Campus Computing Network (CCN)

+1 213 825 7438

Bolt Baranek and Newman (BBN) Now that networking is becoming commonplace, people are beginning to measure the cost of their network software and network use. Stanford Research Institute (SRI), ARPA Network Information Center I hereby propose that there be a standard process implemented on whatever hosts desire which generates character data with out any regard to input. In some sense the process is the converse of the discard process. Many hosts have an existing terminal testing program [e.g. TTYTST] which would suit this function adequately. This Character Generator process would listen for a request for connection and execute the Initial Connection Protocol (ICP) as specified in NIC 7104 the "Current Network Protocols" notebook. Upon completion of the ICP the Character Generator process would begin to send characters into the network as buffer space is made available. The Character Generator process is terminated by closing the connections. University of California, Santa Barbara (UCSB) This document replaces RFC 399, which introduced the Login and Logout commands for UCSB's SMFS, but was incomplete. RFC 399 is restated here, followed by a description of the nature of the response elicted by these commands University of California, Los Angeles (UCLA), Computer Science Department, NMC

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

Bolt Baranek and Newman (BBN)

50 Moulton Street Cambridge MA 02139 US +1 617 661 0100

The czar of socket numbers [Jon Postel] has established the following assignments for socket numbers used for public functions. Note that a socket number is a 40 bit quantity, the first 8 bits being the host specification, the next 24 bits being site specific, and the last 8 bits being user specified - these last 8 bits are called the AEN [it stands for, cleverly enough, Another Eightbit Number]. Bolt Baranek and Newman (BBN), NET As explained in RFC 381, we believe that we can minimize the disruption caused by the release of new IMP software systems by doing them on a regularly scheduled basis. This note is an attempt to be a status report concerning an experiment based on the desire of users, at their consoles, to converse with one another, and perhaps to get some debugging assistance. Bolt Baranek and Newman (BBN), NET This note presents the current IMP/TIP Preventive Maintenance schedule. Preventive Maintenance is scheduled on a monthly basis, and a given machine is normally scheduled at the same time each month; wherever possible the time is chosen to coincide with the PM time for the Host(s) at the site. Stanford Research Institute (SRI) Since the exchange of knowledge and techniques (not to mention programs) is a central motivating factor in the development of the ARPANET, it seems only reasonable that we begin to systematize the process now that someone (MITRE and the government agencies on whose behalf it is acting) feels there is enough information to be worth collecting. Obviously, the network community should be in a position to profit from such compilation at least as much as outside agencies. Bolt Baranek and Newman (BBN), NET This revision contains two major changes to RFC #434. University of California, Los Angeles (UCLA), CCN Bolt Baranek and Newman (BBN), NET While Vint's notes on IMPSYS flow-control from the March 16, 1972, meeting (RFC 442) seem reasonably accurate and while he does cite our Quarterly Technical Report #13, he might have done better to cite BBN's two formal publications relevant to the IMPSYS flow-control scheme: Massachusetts Institute of Technology (MIT), Multics In response to popular demand, and in view of the fact that we've found an extra bit of budget, the timeout on sampling ("anonymous") use of Multics via the Net has been increased to 5 cpu minutes (from 1 cpu minute); coupled with various internal speedups, this change should allow the performance of substantive experiments in a single session. Massachusetts Institute of Technology (MIT), Multics Now that proposals for expansions to the Telnet Protocol are in vogue again (RFC's 426 and 435, for example), I'd like to promote some discussion of a particular favorite of my own. Please note that this is presented as a tentative proposal: it's an attempt to consider the desirability of a new approach, not a rigorous specification. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The purpose of this RFC is to announce a meeting at SRI-ARC on the Network Mail problem discussed at the January 1973 Principal Investigators' Meeting in San Diego. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) This RFC announces a slight change in the meeting time for the Network Mail meeting discussed in RFC #453. Bolt Baranek and Newman (BBN), NET To any TIP users who have not been receiving updates to their TIP User's Guide or who have not been receiving copies of TIP User's Group Notes: please send me your name (along with the TIP and Host you normally use) and I'll make sure you get on a distribution list for these materials. In recent times, a steady stream of questionnaires has been arriving from the network community. Bolt Baranek and Newman (BBN), NET

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

Since the publication of RFC #318 there have been a great number of proposals for changes and/or extensions to the (still unofficial) TELNET Protocol. It now seems appropriate to have a meeting of concerned parties to try, once again, to reach a consensus position and define an "official" protocol (with perhaps, some room for optional expansion). The Mitre Corporation University of California, Los Angeles (UCLA), NMC Massachusetts Institute of Technology (MIT), DMCG Most of the comments in RFC 430 by Bob Braden are useful suggestions which should be included in the forthcoming official FTP specification. This RFC represents my response to Braden's comments and other views. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The purpose of this RFC is to present a framework for coordinating all the surveys and data gathering efforts concerned with "resource notebook" type of information. University of California, Los Angeles (UCLA), CCN Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Bolt Baranek and Newman (BBN), TENEX The Socket which supports the TIP News Facility has been changed to socket 367 (Octal) at BBN-TENEX.. Bolt Beranek and Newman, Inc. (BBN), TENEX

50 Moulton Street Cambridge MA 02139 US +1 617 491 1850 x483 BTHOMAS@BBN-TENEX

An executive program is one which accepts and interprets commands from a user, calling upon other programs to provide the resources required to satisfy each command. There is currently interest in making resources on the ARPANET available to the user via a standard, conversational facility which one might call an ARPANET Executive. University of Illinois, Center for Advanced Computation, ANTS This is a reply to Craig Maxwell's (UCLA-NMC) "Request for graphics information" of 3/7/73. University of Illinois, Center for Advanced Computation, ANTS

Urbana IL 61801 US +1 217 333 9354 BUNCH@USC-ISI

Ira Cotton (NBS) has proposed that Illinois host the next NGWG meeting and that it be held in early May. Bolt Baranek and Newman (BBN), NET This revision contains two types of changes to RFC #447. First, the retrofits to Utah, Belvoir, NOAA, USC, Stanford, ISI, Case, and CCA have been completed and are therefore removed from the schedule. Second, the retrofits to UCSB, ETAC, Aberdeen, and Rome have been rescheduled. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) At the Network Mail Meeting (see -- 14317,) the NIC outlined it's requirements for implementing FTP Journal delivery and submission. It had always been our thinking that those two services should rely upon the File Transfer Protocol's MLFL command for their implementation. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) University of California, Santa Barbara (UCSB) University of California, Santa Barbara (UCSB) Bolt Beranek and Newman (BBN) Bolt Beranek and Newman (BBN) In the past several months, many people have commented to me about their difficulty in transferring files. The hang up appears to be with systems that have some flavor of security, but on which the user has no access privileges. Specifically, the FTP server demands a user and password before it will grant any system access. The loophole which people have been using is the MAIL FILE facility, which is both limited in scope and intended for other purposes. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Network users have expressed interest in holding NLS classes at sites on the Network, instead of at SRI-ARC. University of California, Los Angeles (UCLA), NMC This is a comment on the proposal by Burchfiel and Tomlinson in RFC 467 for a procedure in the host-to host protocol for resynchronization of connection status. University of California, Santa Barbara (UCSB) By using UCSB's Network Standard RJS* users can now gain access to UCLA-CCN's RJS without converting to the UCLA protocol. In addition, the need to use and create files in an intermediate host is avoided. For example, TIP users may operate with hot card readers and printers through UCSB's Remote Job Server and have their jobs execute at UCLA-CCN. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) This RFC announces a new TNLS Quick Reference Card. It documents all of the basic commands required for everyday TNLS usage as well as some special purpose features. University of California, Los Angeles (UCLA), CCN Most of the recent documents on mail protocols have discussed the facilities desired at "post-office" hosts, i.e. those which provide store-and-forward services. CCN has no plans to provide post-office services; we expect to receive mail only for the staff of CCN. Our greatest concern is to get messages reliably to and from our administrative and user support people who don't habitually use on-line terminals, so we are printing out all mail and distributing it by courier/secretary. Let me say a friendly word for SNDMSG. This Tenex command, which uses the FTP MAIL command to deliver messages, is very simple but extremely useful--probably because it is so simple. Furthermore, it is one of the well-kept secrets of the Network that SNDMSG can be used to send messages to any host which supports the MAIL command (without requiring logon to FTP). Thus, to send a message to anyone at CCN, the recommended procedure is to do SNDMSG to "name@CCN". This connects to CCN's FTP and sends a "MAIL name" command followed by the message. We now accept any "name" and print an immediate upper-case copy which is distributed to the recipient's office. So, if you SNDMSG to "BRADEN@CCN", your message will end up on my desk, usually within a few hours. Bolt Beranek and Newman (BBN) This workshop will focus on various aspects of the question: What steps can be taken to automate access to the distributed resources on the ARPANET? Massachusetts Institute of Technology (MIT), Multics In using the File Transfer Protocol, I've noticed that the choice of names for two crucial commands is faulty. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)

Menlo Park CA 94025 US

In September 1971, NIC arranged for all Sites then on the Network to have phone service to NIC with all tolls billed to NIC. (7554,). NASA Ames Research Center (AMES-67) I would like to second Edwin Meyer's (RFC #492) strong opposition to the proposals made in RFC #467 concerning solutions to the "lost allocate" and "half-closed" phenomena. In particular I support all of his principles concerning the "half-closed" phenomenon. I also agree that the proposed "lost allocate" solution tends to mask the real problem of lost messages. I would, however, like to propose the following alternative scheme for recognizing lost messages. AMES-67 I would like to make the following comments on the proposed new TELNET Protocol Specification (NIC # 15372) and TELNET Option Specification (NIC 15373). In general I feel the new TELNET protocol is far superior to the previous version. There are, however, a few items of substance which I feel should be changed, as well as some recommended editorial changes. University of California, Los Angeles (UCLA), NMC Bolt Baranek and Newman (BBN), NET At the recent workshop on "Automated Resource Sharing on the ARPANET", considerable interest was expressed on the topic of network security. In particular, representatives of several sites felt that uncontrolled use of IMP DDT made access control mechanisms quite vulnerable to interception or tampering.* Massachusetts Institute of Technology (MIT), DMCG The purpose of this message is to inform the network community that the survey program at MIT-DMCG computer system is in operation now. University of Southern California (USC)

University Park, Olin Hall Room 330H Los Angeles CA 90007 US +1 213 746 2694

University of California, San Diego (UCSD), CC Massachusetts Institute of Technology (MIT), Multics In RFC 514, Will Kantrowitz returns to the theme of his superb RFC 459. There are too many people spending too much time asking for too much information about Network Hosts. In RFC 519, John Pickens returns to the theme of his rather querulous RFC 369. It's not easy to learn how to use network Hosts. On the one hand, it would seem that there's a veritable feast of information going around; on the other hand it would seem that there's a terrible famine. Can this apparent contradiction be resolved? Bolt Baranek and Newman (BBN), NET It has been noted that the IMP message format (specified in BBN Report 1822) constrains network users to low throughputs if messages are to be uniquely identified via the link number. We have recently implemented a change in the IMP/Host protocol which alleviates this difficulty. University of Calfornia, Los Angeles (UCLA), NMC University of Calfornia, Los Angeles (UCLA), NMC Bolt Beranek and Newman, Inc. (BBN)

10 Moulton Street Cambridge MA 02138 US

Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Bolt Baranek and Newman (BBN), NET As given in BBN Report 1822 (Specifications for the Interconnection of a Host and an IMP), IMP to Host message type 2 specifies that the IMP local to the Host is going down; the message further says when the IMP is going down, for how long, and why. Xerox Palo Alto Research Center (PARC), MAXC For the past couple of weeks, the NIC NCP has been keeping statistics on total incoming messages, incoming host-host control opcodes, and size of outgoing messages. SDAC, TIP Isn't the idea of a single access protocol simple enough that one could be specified, and a socket reserved for it, before the proposed mail protocol becomes official? The result would be that MP could be the first protocol implemented under UULP (or whatever it is to be called), and the other protocols could be "moved" as soon as any problems in the official specifications could be worked out, and at the convenience of implementors. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) A number of people have responded to my proposal for a Mail Protocol (JEW RFC 524 -- 17140,2:y). In the current RFC, I've attempted to collect and respond to the questions, complaints, and suggestions that various individuals in the Network community have offered. I intend to critique myself in a forthcoming RFC. Massachusetts Institute of Technology (MIT), Project MAC We at MIT-DN have implemented the new TELNET protocol (both server and user). This RFC describes our experience with the implementation (particularly the use of GO AHEAD) and in bringing the new User and Server TELNET's in operation (the new TELNET is not compatible with the old). We have a few suggestions here which should help other implementors and lead to a smoother transition to the new protocol. Massachusetts Institute of Technology (MIT), DMCG Massachusetts Institute of Technology (MIT), MULTICS Bolt Baranek and Newman (BBN), TENEX Stanford Research Institute (SRI), Augmentation Research Center (ARC) One of the deficiences of the current FTP mail protocol is that it makes no provision for the explicit specification of such header information as author, title, and date. Many systems send that information, but each in a different format. One fairly serious result of this lack of standardization is that it's next to impossible for a system or user program to intelligently process incoming mail. Xerox Palo Alto Research Center (PARC). MAXC The following computation of cross-country network bandwidth was contributed by Butler Lampson of PARC. Bolt Baranek and Newman (BBN), NET This note serves as a brief correction to several fundamental errors in RFC 567 by L. Peter Deutsch. The MITRE Corporation

Westgate Research Park Mail Stop W185 McLean VA 22101 US +1 703 893 3500 x2350 POSTEL@ISI

Hereafter proposed protocols shall be submitted in the form of on-line documents, preferably as nls files at the Network Information Center. This will greatly facilitate the review process and enable editorial and substantive changes to proceed quickly. This also will permit timely updating of protocol documents as may be neccessitated by future decisions. On-line documents are also easily distributed to the network community. If you find great difficulty in complying with this request please contact me. MITRE Corporation, TIP University of California, Los Angeles (UCLA), New Media Centers (NMC) Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET) University of California, Los Angeles (UCLA), New Media Centers (NMC) Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET) Stanford Research Institute (SRI), Augmentation Research Center (ARC) MITRE Corporation, TIP A new group, the Arpanet Users Interest Working Group (USING) is the outgrowth of a meeting held in Boston on May 22-23, 1973. Bolt Beranek and Newman (BBN) MITRE Corporation (MITRE) NASA Ames Research Center (AMES-67) This note is a reply to Edward Taft's "Second Thoughts on TELNET Go-Ahead" (NIC #20812). Xerox Palo Alto Research Center (PARC), MAXC In this RFC we present objections to the requirement that hosts implement the Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol Specification (NIC #15372). Attached are the latest network maps -- geographic and logical -- and a list of Hosts connected to the ARPANET. The geographic map shows all IMPs and TIPs currently installed in the subnetwork. SRI/Network Information Center University of California, Los Angeles (UCLA), CCN Discusses some unusual interface issues for the Plato terminal. Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET) Xerox Palo Alto Research Center (PARC), MAXC Bolt Baranek and Newman (BBN), TENEX The MITRE Corporation Xerox Palo Alto Research Center (PARC), MAXC University of California, Santa Barbara (UCSB) University of California, Santa Barbara (UCSB) There are several aspects of the File Transfer Protocol that constitute serious drawbacks. Stanford Research Institute (SRI), Augmentation Research Center (ARC) We at the NIC agree with Peter Deutsch's suggestion (in RFC# 606 / NIC# 21246) that the NIC maintain an online ASCII text file of Host names, addresses, and attributes. Stanford Research Institute (SRI), Augmentation Research Center (ARC) Within the next few weeks we will be transferring computer services for our ROME, ARPA, and NIC users from the ARC/NIC system to a new system we are installing at TYMSHARE in Cupertino, Ca. Computer Corporation of America (CCA) Computer Corporation of America (CCA) Computer Corporation of America (CCA) Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET) Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET) Bolt Baranek and Newman, Network Control Center (BBN), NET Massachusetts Institute of Technology (MIT), Multics Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET) University of California, Los Angeles (UCLA), NMC There seems to be an increasing call for a Network Standard Data Pathname (NSDP); that is, a standardized means of referring to a specific location for/of a collection of bits somewhere on the Network. Xerox Palo Alto Research Center (PARC), MAXC Xerox Palo Alto Research Center (PARC), MAXC The NCP in use at HARV-10, CMU-10A, and CMU-10B collects a number of operating and error statistics, which may be typed out on demand by any user by means of the 'IMP ERROR' command, as shown on the sample typescript. University of California, Los Angeles (UCLA), New Media Centers (NMC) University of California, Los Angeles (UCLA), New Media Centers (NMC) In one of our current measurement projects we are interested in the average values of important network parameters. For this purpose we collect data on the network activity over seven consecutive days. This data collection is only interrupted by down-time or maintenance of either the net or our collecting facility (the "late" Sigma-7 or, in future, the 360/91 at CCN). Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Intitute (SRI), Augmentation Research Center (ARC) Bolt Beranek and Newman Inc. (BBN), Network Control Center (NET)

50 Moulton Street Cambridge MA 02138 US

From time to time it is necessary for an IMP or TIP to be taken down other than during its scheduled Preventive Maintenance period. Examples of such cases are retrofit programs and the off-line diagnosis and repair of intermittent problems. In the past we have scheduled these downs with our "primary site contact" at the affected site; in our view this individual was responsible for representing all of the hosts (and TIP users) connected to that IMP/TIP. Although this policy has worked well in the past, the recent proliferation of Very Distant Hosts, together with complaints from representatives of other (local or distant) Hosts, has caused us to review our procedures. University of California, Santa Barbara (UCSB) Peter Deutsch in RFC #606 pointed out the desirability of having a single host maintain a data base containing official host names and host addresses, as well as other information of secondary importance. Mike Kudlick in RFC #608 agreed with the concept, and proposed that the NIC would implement Peter's ideas. I would like to add my voice to those in support of such a service, and express a few ideas for its modification. University of California, Santa Barbara (UCSB) University of California, Santa Barbara (UCSB) AMES Research Center (AMES-67) Stanford Research Institute (SRI), Augmentation Research Center (ARC) There are several aspects of the File Transfer Protocol of RFC 542 that constitute serious drawbacks. Some of these are quite basic in nature, and imply substantial design changes; these will be discussed in a later RFC. Others could be remedied with very little effort, and this should be done as soon as possible. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) We agree with the suggestion in RFC 623 that more than one Host should be responsible for maintaining a copy of the Hostnames data base. The NIC is certainly willing to continue to maintain the master data base, and make it available to any secondary Host that volunteers to maintain a copy. We would be pleased to have UCSB serve as one of the secondary Hosts. University of Los Angeles (UCLA), New Media Centers (NMC) University of Los Angeles (UCLA), New Media Centers (NMC) Lockup or deadlock conditions are one of the most serious system malfunctions that can occur in a computer system or network. Communication protocols have to be designed very carefully to avoid the occurrence of these lockups. Their common characteristic is that they occur only under unusual circumstances which were not foreseen or deemed too unlikely to occur by the protocol designers. (However, these designers often are not the ones in a position to evaluate such likelihoods quantitatively.) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)

Menlo Park CA 94025 US +1 415 329 0742 Feinler@SRI-ARC

The online ASCII text file of official hostnames as defined in RFCs 606 and 608 is now available at OFFICE-1 (Hostaddr. 43 decimal) with pathname NETINFOHOSTS.TXT. Currently the file includes hostname, host address, and host status. We hope to be adding additional attributes soon. This file will be maintained by the NIC, and all hosts are encouraged to use these hostnames in their monitors. Changes or additions will be added on a weekly basis. Each network host will be responsible for accessing this file via FTP for new information. Stanford Research Institute (SRI), Augmentation Research Center (ARC) Stanford Research Institute (SRI), Augmentation Research Center (ARC) Network users may send mail to individuals and to groups, input as messages or entire files, through the Network Journal, using SNDMSG or their site's mail system. The mail is converted at NIC into NLS files, Journalized, and sent to specified recipients. Short messages may be received as messages, longer ones as citations to files which may be retrieved immediately, and also later, by using FTP. Mail sent to NIC with a "/" in the user-name field invokes the Net Journal. Bolt Beranek and Newman (BBN) Universite de Liege

49 Avenue des Tilleuls Liege B-4000 BE

The "Association des Ingenieurs Electriciens sortis de l'Institut Electrotechnique Montefiore A.I.M.)" organizes a meeting on "Mini-Computers and Data Communication" in Liege from January 20 to January-22, 1975. University of California, Los Angeles (UCLA), NMC The transmission of digitized speech over the ARPANET represents a new dimension in the use of packet switching systems. The throughput and delay requirements for this newly emerging application area are quite different from the throughput and delay requirements for interactive use or file transfers. In particular, we need to achieve a high throughput for small messages since long messages result in long source delays to fill the large buffers. Therefore we are currently studying the throughput limits for single-packet messages. We realize that up to now little attempt was made to optimize throughput for low delay traffic. It was nevertheless surprising for us to find out that the observed throughput for single-packet messages is in many cases only about one fourth of what one would expect. In what follows we are going to explain why this happens and what could be done to correct this situation. Bolt Beranek and Newman (BBN), NET This note presents the current IMP/TIP Preventive Maintenance schedule. Preventive Maintenance is scheduled on a monthly basis and a given machine is normally scheduled at the same time each month; wherever possible the time is chosen to coincide with the PM time for the Host(s) at the site. Bolt Beranek and Newman (BBN), NET Sometime between May 8 and May 22, probably toward the end of that period, the Haskins Laboratory "Very Distant Host" connection will be moved from BBN (IMP #5) to Harvard (IMP #9). The Host Number of the Haskins machine will remain Host 3 (numbering from zero to three). Thus, the Network Address of the Haskins Laboratory Host will change from 197 to 201. Since the date of the change is dependent on installation of new circuits by the local telephone company, I am unable to give the actual date more precisely. Theoretical and practical motivation for redesign. Multipacket messages; host retransmission; duplicate detection; sequencing; acknowledgement. Bolt Beranek and Newman (BBN), TENEX Bolt Beranek and Newman (BBN), NET Bolt Beranek and Newman (BBN), TENEX Bolt Beranek and Newman (BBN), NET During the past months we have felt strong pressure to improve the reliability of TIP/TENEX network connection as improvement in the reliability of users' connections between TENEXs and TIPs would have major impact on the appearance of overall network reliability due to the large number and high visibility of TENEXs and TIPs. Despite the emphasis on TIP/TENEX interaction, all work done applies equally well to interactions between Hosts of any type. Bolt Baranek and Newman (BBN), NET Effective immediately, the Host at Stanford Electronics Research Lab. (SU-DSL), a Very Distant Host connected to the SRI IMP, has its address changed from IMP 2, Host 2, to IMP 2 Host 3. Thus its "Network Address" is changed from 130 to 194. Host 2 on IMP 2 will eventually be a PDP-11 operated by the SRI Artificial Intelligence Center. Bolt Baranek and Newman (BBN), NET This note presents the current IMP/TIP Preventive Maintenance schedule. Preventive Maintenance is scheduled on a monthly basis and a given machine is normally scheduled at the same time each month; wherever possible the time is chosen to coincide with the PM time for the Host(s) at the site. This document describes a revised set of reply codes for the File Transfer Protocol. Bolt Baranek and Newman (BBN) This document describes a proposed protocol to be used in an implementation of a PDP-11 network Bootstrap service and a cross-network debugger. The protocol is designed for debugging processes running under an operating system which can perform some of the "lower level" debugging tasks, such as planting and removing breakpoints and single stepping. A subset of the protocol could be used if such a capability does not exist (a stand-alone program for example). Bolt Baranek and Newman (BBN), TENEX This note describes the problem of signature authentication for network mail, presents a general approach to the problem and proposes a specific implementation of that approach. Providing a mechanism for specifying all attributes of a collection of bits; see also RFC 615. Approaches to Front-End protocol processing using available hardware and software. University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC University of California, Los Angeles (UCLA), NMC Options defined in RFCs 651-658. Bolt Baranek and Newman (BBN), NET In the next few weeks several changes will be made to the IMP software including changes to the IMP/Host software interface as specified in BBN Report No. 1822, Specifications for the Interconnection of a Host and an IMP. These changes come in four areas: a) decoupling of the message number sequences of Hosts; b) Host/Host access control; c) expansion of the message number window from four to eight; and d) provision for messages outside the normal message number mechanism. All changes are backward compatible with possible minor exceptions in timing. An old version; see RFC 694. Massachusetts Institute of Technology (MIT), Project MAC With the growth of Multics usage in the ARPA Network community, users often need to transfer large amounts of data from Multics to other systems. However, Multics performance in this area has been less than optimal and there clearly exists a need to improve the situation. Even within Project MAC there are users who regularly ship files back and forth between Multics and other Project MAC computer systems. Recently the Cambridge Information Systems Laboratory (CISL) development Multics system was connected to the ARPA Network. This has generated considerable interest among the members of the CSR (Computer Systems Research) and CISL groups in using the Multics file transfer facility for transmission of Multics system tapes (MST) from one Multics system to the other. At currently realizable data transfer rates, transmission of a typical MST, (approximately 12 million bits), takes about half an hour. The usefulness of the present file transfer system is severely limited by its low bandwidth. One of the reasons for such a poor performance is the output buffering strategy in the Multics IMP DIM (IMP Device Interface Manager.) With the hope of making a significant performance improvement, we recently changed the IMP DIM buffering strategy. To assess the effects of this change an experiment was conducted between the service machine (MIT Multics) and the development machine (CISL Multics.) This memo reports the experiment and its results. Massachusetts Institute of Technology (MIT), Project MAC Discusses and proposes a common command language. Approved scheme to connect host ports to the network. Bolt Baranek and Newman (BBN), TENEXA Experience with implementation in RSEXEC context. Bolt Baranek and Newman (BBN), TENEX Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)

Menlo Park CA 94025 US +1 415 326 6200 x3718 POSTEL@SRI-ARC

Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)

Menlo Park CA 94025 US +1 415 326 6200 x2960 WHITE@SRI-ARC

As many of you may know SRI is part of a team working on the National Software Works project. In the course of our work we have developed a Procedure Call Protocol to be used between the modules which make up the NSW. Bolt Baranek and Newman (BBN), TENEX Bolt Baranek and Newman (BBN), TENEX Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) An earlier poll of Telnet server implementation status. Updates RFCs 701, 702 and 669; see also RFC 703. Extends message field definition beyond RFC 561 attempts to establish syntactic and semantic standards for ARPANET; see also RFCs 733 and 822. University Of Illinois

210 Advanced Computation Bldg. Urbana IL 61801 US +1 217 333 8469 HOLMGREN@BBN

Bolt Beranek and Newman (BBN) Bolt Baranek and Newman (BBN), TENEX Bolt Baranek and Newman (BBN), TENEX Cross-network debugging is a means whereby a programmer at one computer on a network can debug a program which executes on another computer. One form of cross-net debugging has been in use for some years by programmers who maintain IMPs on the ARPA network. Another form has been used by ARPA network users who employ TELNET or RSEXEC to log into a distant computer and remotely run a debugger on that machine. In both of these cases, the debugger is almost entirely resident in the same machine as the subject program, and only a remote means of access to that computer distinguishes the activity from single-computer debugging. In our case, we use a PDP-10 to perform complex debugging manipulations. Simple manipulations, and complex actions which the PDP-10 has partially digested into simple actions, are sent over the ARPA network to a PDP-11. The portion of the debugger resident in the PDP-11, where the subject program executes, can perform only simple actions (examine, deposit, start, stop, set breakpoint, etc.). This division of debugging computation between the two machines is implemented and in use at BBN. A user s manual is available (as (BBN] DOCUMENTATION XNET.DOC) describing the debugger s features and discussing some of the issues involved. The purpose of this RFC is to describe our experience with response times the debugger exhibits. Response time is a serious problem in any elaboration to a debugger. Here we wish to discuss the contribution of communicating over the ARPA network to response time. The debugger (X-NET) keeps statistics during each debugging session, and a debugger command prints them out. We used a "standard scenario" to measure response times on two occasions. The first was debugging a PDP-11 at BBN on the same IMP as the PDP-10. The second was with a PDP-11 at SRI-ARC in California, with at least nine IMPs intervening. Stanford University (SU), Artificial Intelligence (AI) I recently decided it was time for an overhaul of our FTP user and server programs. This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong -- and a few things that everyone seemed to be doing differently from each other. When I enquired about this, the response from some quarters was "Oh, you're running version 1!" Bolt Baranek and Newman (BBN)

WALDEN@BBN

This note sketches the design of an expansion to the IMP/host and host/IMP protocol which will include among other things the possibility of addressing hosts on more than 63 IMPs. Our intention in this expansion is to correct certain existing limits without fundamental changes in the philosophy of the IMP/host protocol; i.e., while many issues which would represent fundamental changes to the IMP/host protocol are presently under discussion in the world-wide packet-switching com unity, we are not able to undertake massive fundamental changes on a time scale compatible with the short term needs for network improvement (e.g., already there are almost 60 IMPs). Bolt Baranek and Newman (BBN) Implementation of the New TELNET Protocol has now become the top priority item on the TIP development queue. Because what is done in the TIP potentially affects what is done at a number of hosts, below we give the implementation schedule to which we hope to adhere. The attached figure describes the finite state machine used in TENEX version 1.33 to implement the ARPANET Host to Host protocol. This memo updates that of 27 August 1971, TENEX memo number 113, with regard to the finite state machine. Other parts of that memo have been incorporated into the JSYS manual and other documents. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This is a set of comments on Dave Walden's RFC 687 suggesting a set of changes to the host--imp protocol. Stanford University (SU), Artifical Intelligence (AI) This is a slight revision of RFC 686, mainly differing in the discussion of print files. Reading several RFCs that I (sigh) never heard of before writing 686 has convinced me that although I was right all along it was for the wrong reasons. The list of reply codes is also slightly different to reflect the four lists in RFCs 354, 454, 542, and 640 more completely. Let me also suggest that if there are no objections before June 1, everyone take it as official that HELP should return 200, that SRVR should be used as discussed below, and that "permanent" 4xx errors be changed to 5xx. And thanks to Jon Postel who just spent all evening helping me straighten this all out. Aside from a cry of anguish by the site responsible for the security hassle described below, I've only had one comment on this, which was unfavorable but, alas, unspecific. Let me just say, in the hopes of avoiding more such, that I am not just trying to step on toes for the fun of it, and that I don't think the positive changes to FTP-1 proposed here are necessarily the best possible thing. What they are, I think, is easily doable. The great-FTP-in-the-sky isn't showing any signs of universal acceptability, and it shouldn't stand in the way of solving immediate problems. Leaving Well Enough Alone I recently decided it was time for an overhaul of our FTP user and server programs. This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong--and a few things that everyone seemed to be doing differently from each other. When I enquired about this, the response from some quarters was "Oh, you're running Version 1!" University of California, Los Angeles (UCLA), CCN Basically, the proposed set of changes in RFC 687 seems reasonable, as are the comments in RFC 690. References to documents and contacts concerning the various protocols used in the ARPANET, as well as recent developments; updates RFC 661. Observations on current international standards recommendations from IFIP working group 6.1; see also RFCs 692, 690, 687. SUMEX-AIM University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This RFC is a slightly annotated list of the 100 RFCs from RFC 600 through RFC 699. This is a kind of status report on these RFCs. Bolt Baranek and Newman (BBN), TENEXA THIS IS THE FIRST OF WHAT ARE PLANNED TO BE MONTHLY REPORTS ON THE STATUS OF THE NEW-PROTOCOL TELNET IMPLEMENTAIONS ON THE SERVER HOSTS ON THE ARPA NETWORK. INCLUDED IN THIS REPORT ARE DATA ONLY ON SERVER TELNETS AT THE VARIOUS SITES. ONE WOULD HOPE THAT ANY SITE WITH AN OPERATIONAL NEW-PROTOCOL SERVER TELNET WOULD ALSO BOAST A NEW-PROTOCOL USER TELNET; WE CAN CERTAINLY ASSUME THIS FOR TENEX SITES AT WHICH TENEX 1.32 IS OPERATING. HOWEVER, NO FURTHER CLAIMS ARE MADE FOR THE SERVER DATA CONTAINED IN THIS REPORT. Bolt Baranek and Newman (BBN), TENEXA LAST MONTH'S SURVEY PRODUCED A GRATIFYING AMOUNT OF FEEDBACK CLARIFYING THE STATUS OF SEVERAL SITES; HOWEVER THERE HAVE BEEN VERY FEW CHANGES IN THE STATUS OF HOST SERVERS. THE CHANGES IN THIS MONTH'S LIST, IN NUMERICAL ORDER (HOST NUMBER THROUGHOUT ARE OCTAL): Bolt Baranek and Newman (BBN), TENEXA In the nearly five months since the last report several new server sites have joined the network and there has been some significant progress in New-Protocol implementation. Perhaps the New-Protocol implementation on the TIPs scheduled for the end of the year will encourage further progress in the near future. Bolt Beranek and Newman (BBN) This note is a revision of RFC 687 and sketches the design of an expansion to the IMP/host and host/IMP protocol which will include among other things the possibility of addressing hosts on more than 63 IMPs. Our intention in this expansion is to correct certain existing limits without fundamental changes in the philosophy of the IMP/host protocol; i.e., while many issues which would represent fundamental changes to the IMP/host protocol are presently under discussion in the world-wide packet-switching community, we are not able to undertake massive fundamental changes on a time scale compatible with the short term needs for network improvement (e.g., already there are 62 IMPs). University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 BRYAN@ISI

NSA NSA ACC This is a working document which has been developed as the specification and guideline for design of a Burroughs B6700 attachment to an ARPA-Style network. The approach is to utilize a front-end processor with a new protocol for network operation. That protocol, described herein, has been built upon the concepts expressed by M.A. Padlipsky, et al, in NIC# 31117, RFC# 647.. This proposed, site-specific, FEP implementation is the work of Gerald Bailey and Keith McCloghrie of NSA and of David Grothe of ACC. It has already sustained some corrections provided by MAP. It will be helpful if interested networkers will review and provide comments to us. Stanford Research Institute (SRI), Augmentation Research Center (ARC) In the ARPA Network Host/IMP interface protocol there is no mechanism for the Host to selectively refuse messages. This means that a Host which desires to receive some particular messages must read all messages addressed to it. Such a Host could be sent many messages by a malfunctioning Host. This would constitute a denial of service to the normal users of this Host. Both the local users and the network communication could suffer. The services denied are the processor time consumed in examining the undesired messages and rejecting them, and the loss of network thruput or increased delay due to the unnecessary busyness of the network. It would be useful for a Host to be able to decline messages from sources it believes are misbehaving or are simply annoying. If the Host/IMP interface protocol allowed the Host to say to the IMP "refuse messages from Host X", the IMPs could discard the unwanted messages at their earliest opportunity returning a "refused" notice to the offending Host. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC)

Menlo Park CA 94025 US +1 415 326 6200 x2960

This paper proposes a high-level, application-independent protocol and software framework that would extend the local programming environment to embrace modules in other computers within a resource sharing computer network, and thereby facilitate the construction of distributed systems and encourage the sharing of resources. The work reported here was supported by the Advanced Research Projects Agency of the Department of Defense, and by the Rome Air Development Center of the Air Force. This paper has been submitted for publication in the Proceedings of the 1976 National Computer Conference. Stanford Research Institute (SRI), Augmentation Research Center (ARC)

Menlo Park CA 94025 US +1 415 326 6200 x2960

This paper suggests some extensions to the simple Procedure Call Protocol described in a previous paper (27197). By expanding the procedure call model and standardizing other common forms of inter-process interaction, such extensions would provide the applications programmer with an even more powerful distributed programming system. Massachusetts Institute of Technology (MIT)

JFH@MIT-DMS

A mechanism is defined for use by message servers in transferring data between hosts. The mechanism, called the MSDTP, is defined in terms of a model of the process as a translation between two sets of items, the abstract entities such as 'strings' and 'integers', and the formats used to represent such data as a byte stream. A proposed organization of a general data transfer mechanism is described, and the manner in which the MSDTP would be used in that environment is presented. Over the past few months we have become aware that there has been some confusion as to how to operate a Host connected to an IMP as a Very Distant Host (or VDH). Therefore, next time BBN Report 1822 ("Specifications for the Interconnection of a Host and an IMP") is revised, we will include additional information on how the IMP side of a VDH connection works and how the Host side may operate most efficiently. As an interim measure, we are distributing this RFC which takes the form of a (logical) update to Appendix F of BBN Report 1822. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) The following is the significant portion of a dialog on RCTE that has followed the publication of RFC 718. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Experience with processing mail on the Arpanet has pointed up many addressing issues, including: 1. People's names are not the same as their addresses; 2. Mailing lists can get quite long; 3. To allow responding, messages often need to carry all of their mailing list with them; 4. It would be very useful to be able to send mail to files other than the person's primary mailbox. Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) This note addresses the problem of implementing a reliable out-of-band signal for use in a host-to-host protocol. It is motivated by the fact that such a satisfactory mechanism does not exist in the Transmission Control Protocol (TCP) of Cerf et. al.,. In addition to discussing some requirements for such an out-of-band signal (interrupts) and the implications for the implementation of the requirements, a discussion of the problem for the TCP case will be presented. While the ARPANET host-to-host protocol does not support reliable transmission of either data or controls, it does meet the other requirements we have for an out-of-band control signal and will be drawn upon to provide a solution for the TCP case. Massachusetts Institute of Technology (MIT) This paper addresses some issues concerned with the design of distributed services. In particular, it is concerned with the characteristics of the interactions, between programs which support some service at various network sites. The ideas presented are derived mainly from experience with various service protocolson the ARPANET. A model is developed of interactions between programs. Salient features of this model which promote and simplify the construction of reliable, responsive services are identified. These dualities are motivated by problems experienced with various ARPANET protocols and in the design and maintenance of programs which use these protocols in the performance of some service. Using this model as a template, the general architecture of one possible interaction protocol is presented. This mechanism provides a foundation on which protocols would be constructed for particular services, simplifying the process of creating services which are easy to implement and maintain, and appear reliable and responsive to the customer. This presentation is meant to serve as an introduction to a specific instance of such a protocol, called the RRP, which is defined in one of the references. Massachusetts Institute of Technology (MIT), LCS/CSR

Pogran@MIT-Multics

Bolt Baranek and Newman (BBN)

Vittal@BBN-TENEXA

The Rand Corporation, Information Sciences Department

DCrocker@Rand-Unix

Bolt Baranek and Newman (BBN)

Henderson@BBN-TENEXD

Command and Control Technical Center WWMCCS ADP Director of the Defense Communications Agency

Washington DC 20305 US

University of Illinois at Urbana-Champaign, Center for Advanced Computation

Urbana IL 61801 US

Stanford Research Institute (SRI) International, Augmentation Research Center (ARC) University of California, Irvine Massechusetts Institute of Technology (MIT), Artifical Intelligence Designers of Telnet options should be aware of the following possible case in the Telnet protocol which may generate unexpected behavior on either end of the connection. Although at present none of the existing options are susceptible to this problem, it could arise in the future. Rand Corporation, ISD

Dcrocker@Rand-Unix

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

The Rand Corporation, Information Sciences Department

1700 Main St Santa Monica CA 90406 US DCrocker@Rand-Unix

Bolt Beranek and Newman Inc. (BBN)

50 Moulton St. Cambridge MA 02138 US Vittal@BBN-TenexD

Massachusets Institute of Technology (MIT), Laboratory for Computer Science

545 Technology Square Cambridge MA 02139 US Pogran@MIT-Multics

Bolt Beranek and Newman Inc. (BBN)

50 Moulton St. Cambridge MA 02138 US Henderson@BBN-TenexD

Stanford University, Artifical Intelligence The Rand Corporation, Information Sciences Department

Dcrocker@Rand-Unix

Carnegie-Mellon University (CMU)

Gumpertz@CMU-10A

Stanford University, Artifical Intelligence Stanford Research Institute (SRI) International, KL This note describes an extension to the File Transfer Protocol which provides for "sending" a message to a logged-in user, as well as variants for mailing it normally whether the user is logged in or not. Stanford Research Institute (SRI) International, KL This note describes the Time Server protocol, as currently implemented on ITS hosts (i.e. MIT-(AI/ML/MC/DMS)). The idea is to provide a site-independent, machine readable date and time in as efficient and swift a manner as possible; its motivation arises from the fact that not all systems have a date/time clock, and all are subject to occasional human or machine error. The use of time-servers makes it possible to quickly confirm or correct a system's idea of the time, by making a brief poll of several independent sites on the network. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIB

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. University of California, Los Angeles (UCLA), CCN University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Stanford Research Institute (SRI) International, KL Stanford Research Institute (SRI), KL

JZS@CCA

Bolt Beranek and Newman (BBN) Massachusetts Institute of Technology (MIT), Artifical Intelligence (AI) Stanford University, Artifical Intelligence Stanford University, Artifical Intelligence Massachusetts Institute of Technology (MIT), Multics University of Southern California (USC) / Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIB

Massechusetts Institute of Technology (MIT)

PDL@MIT-DMS

Two surveys of Arpanet Server hosts were run between September 20, 1978 and December 11, 1978. The intent was to determine the response of the host's Server FTP program Stanford University, Artifical Intelligence The network host table in use at MITand Stanford is described. This host table is superior to the NIC and Tenex host tables in several ways. A binary file, compiled from this host table, is also described. This file is used by subsystems on MIT's ITS and Stanford's WAITS timesharing systems for efficiency in host and network lookups. University of Southern California (USC) / Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC) / Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

There is now interest in sustantially extending the scope of the computer mail system used in the ARPANET to allow communication of voice, fax, graphics, as well as text information between users in different networks as wells as within the ARPANET. The discussion of a transition from the current ARPANET sndmsg environment and mechanisms to a more general internet environment and richer mechanisms must consider techniques for continued activity during the transition. In addition, there is a current need for a mechanism to support the interaction of the several already existing NSW-like message environments with the ARPANET message environment. This memo discusses some possible alternatives for computer mail addressing for hosts outside the ARPANET in the short term. This memo is hopelessly Tenex oriented in its descriptions and examples. University of Southern California (USC) / Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIB

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. SRI International, Telecommunications Sciences Center

333 Ravenswood Menlo Park CA 94025 US

SRI International, Telecommunications Sciences Center

333 Ravenswood Menlo Park CA 94025 US

SRI International, Telecommunications Sciences Center

333 Ravenswood Menlo Park CA 94025 US

In this paper a new method for distributing and updating host name/address information in large computer networks is described. The technique uses datagrams to provide a simple transaction-based query/response service. A provisional service is being provided by the Arpanet Network Information Center (NIC) and is used by mobile packet radio terminals, as well as by several Arpanet DEC-10 hosts. Extensions to the service are suggested that would expand the query functionality to allow more flexible query formats as well as queries for service addresses. Several architectural approaches with potential for expansion into a distributed internet environment are proposed. This technique may be utilized in support of other distributed applications such as user identification and group distribution for computer based mail. Bolt Beranek and Newman (BBN)

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

University of Southern California (USC) / Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIB

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIE

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. National Bureau of Standards (NBS) Occasionally it is necessary to send mail to someone on the net who is known only as the incumbent in an official position. Often the mail is undeliverable because of employee turnover. We have also had such a problem at NBS and have therefore created MAIL address synonyms such as SYSTEMS, MANAGEMENT, and LIAISON to ensure that mail is correctly delivered no matter who the incumbent happens to be. I suggest that all systems which permit MAIL address synonyms install them. I further suggest that the NIC or the ARPANet management select a standardized set of synonyms, thus increasing their utility. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

In recent years the ARPA Network Research Program has had as one concern the interconnection of networks. In the course of this research a family of protocols suitable for an internetwork environment has emerged. Much of this work is documented in a series of project memos called Internet Experiment Notes or IENs. A few of these IENs document protocols in the internet protocol family. Most of the major internet protocol documents have also been issued as RFCs. The situation has evolved to the point that it is appropriate for the internet family of protocols to replace the old ARPANET protocols. To this end an Internet Protocol Handbook will be prepared by the Network Information Center. This Handbook is tentatively planned to be available at the end of 1980. This Internet Protocol Handbook will closely parallel the old ARPANET Protocol Handbook, and will primarily be a collection of existing RFCs and IENs. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIF

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. Advanced Research Projects Agency (ARPA) University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Defense Advanced Research Projects Agency (DARPA) University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

The internet family of protocols is replacing the old ARPANET protocols. To this end an Internet Protocol Handbook will be prepared by the Network Information Center. This Handbook is tentatively planned to be available at the end of 1980. This Internet Protocol Handbook will closely parallel the old ARPANET Protocol Handbook, and will primarily be a collection of existing RFCs and IENs.

dm@bbn-unix

dan@bbn-unix

ADOwen@bbnd

As a part of the Remote Site Maintenance (RSM) project for ARPA, BBN has installed and maintains the software of several DEC PDP-11s running the Unix operating system. Since Unix has a tree-like directory structure, in which directories are as easy to manipulate as ordinary files, we have found it convenient to expand the FTP servers on these machines to include commands which deal with the creation of directories. Since there are other hosts on the ARPA net which have tree-like directories, including Tops-20 and Multics, we have tried to make these commands as general as possible. University of Southern California (USC) / Information Sciences Institue

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIF

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

COMSAT Laboratories LLL University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

SRI International The MITRE Corporation, MITRE C(3) Division, (3) Operations

1820 Dolley Madison Boulevard McLean VA 22102-3481 US

The MITRE Corporation, MITRE C(3) Division, (3) Operations

1820 Dolley Madison Boulevard McLean VA 22102-3481 US

Massechusetts Institute of Technology (MIT) University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

We are creating an implementation of MTP for TOPS20. The programs are written in BLISS-10. This implementation supports the MTP user and server functions using both TCP and NCP transport services, and provides interfaces to other mail delivery mechanisms. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Data General Corporation

4400 Computer Drive MS E111 Westborough MA 01580 US +1 617 366 8911 x3056

The increasingly familiar and ubiquitous Reference Model of Open Systems Interconnection, currently being considered by the International Organization for Standardization (ISO) for promotion to the status of a Draft International Standard, is based on the explicit assumption that a "connection" - an association between two or more communicating entities, possessing certain characteristics over and above those possessed by the entities themselves - is required for the transfer of data in an Open Systems Interconnection (OSI) environment. Although the connection-oriented model of communications behavior has proven to be an extremely powerful concept, and has been applied successfully to the design and implementation of protocols and systems covering a wide range of applications, a growing body of research and experience suggests that a complementary concept - connectionless data transmission - is an essential part of the Open Systems Interconnection architecture, and should be embraced as such by the OSI Reference Model. This paper explores the concept of connectionless data transmission and its relationship to the more familiar concepts of connection-oriented data transfer, developing a rationale for the inclusion of the connectionless concept in the Reference Model as an integral part of the standard description of the OSI architecture. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Bolt Beranek and Newman Inc. On October 27, 1980, there was an unusual occurrence on the ARPANET. For a period of several hours, the network appeared to be unusable, due to what was later diagnosed as a high priority software process running out of control. Network-wide disturbances are extremely unusual in the ARPANET (none has occurred in several years), and as a result, many people have expressed interest in learning more about the etiology of this particular incident. The purpose of this note is to explain what the symptoms of the problem were, what the underlying causes were, and what lessons can be drawn. As we shall see, the immediate cause of the problem was a rather freakish hardware malfunction (which is not likely to recur) which caused a faulty sequence of network control packets to be generated. This faulty sequence of control packets in turn affected the apportionment of software resources in the IMPs, causing one of the IMP processes to use an excessive amount of resources, to the detriment of other IMP processes. Restoring the network to operational condition was a relatively straightforward task. There was no damage other than the outage itself, and no residual problems once the network was restored. Nevertheless, it is quite interesting to see the way in which unusual (indeed, unique) circumstances can bring out vulnerabilities in network control protocols, and that shall be the focus of this paper. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US

Advanced Research Projects Agency (ARPA) In general, precedence is a tool for deciding how to allocate resources when systems are saturated. In circuit switched systems, the resource is circuits; in message switched systems the resource is the message switch processor; and in packet switching the resource is the packet switching system itself. This capability can be realized in AUTODIN II without adding any new mechanisms to TCP (except to make precedence of incoming connection requests visible to the processes which use TCP). To allow pre-emptive access to a particular terminal, the software (i.e., THP) which supports terminal access to the TAC can be configured so as to always have a LISTEN posted for that terminal, even if the terminal has a connection in operation. For example in the ARPANET TENEX systems, the user TELNET permits a user to have many connections open at one time - the user can switch among them at will. To the extent that this can be done without violating security requirements, one could imagine a multi-connection THP which always leaves a LISTEN pending for incoming connection requests. If a connection is established, the THP can decide, based on its precedence, whether to pre-empt any existing connection and to switch the user to the high precedence one. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This memo describes the relationship between the Internet Protocol (IP)Type of Service and the service parameters of specific networks. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This note describes a proposed format for storing simple bitmaps (one bit per pixel) in a file. These files may be very large and the intent is to use this format for short term storage and passing data between closely coupled programs. The data in the file should be stored in 8-bit bytes (octets). Bitmaps may be any size. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

COMSAT Laboratories University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

This RFC is a slightly annotated list of the 100 RFCs from RFC 700 through RFC 799. This is a kind of status report on these RFCs. University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

Bolt Beranek and Newman Inc.

malis@bbn-unix

International Telephone and Telegraph Consultative Committee (CCITT) University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

National Bureau of Standards University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University College London (UCL), Department of Computer Science This note describes the features of the computerized facsimile system developed in the Department of Computer Science at UCL. First its functions are considered and the related experimental work is reported. Then the disciplines for system design are discussed. Finally, the implementation of the systems are described, while detailed descriptions are given as appendices. SRI International, Network Information Center SRI International, Network Information Center SRI International, Network Information Center SRI International, Network Information Center SRI International, Network Information Center SRI International, Network Information Center Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group Massachusetts Institute of Technology (MIT), Laboratory for Computer Science Computer Systems and Communications Group Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group Massachusetts Institute of Technology (MIT), Laboratory for Computer Science, Computer Systems and Communications Group University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

SRI International University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511

University of Southern California (USC)/Information Sciences Institute

4676 Admiralty Way Marina del Rey CA 90291 US +1 213 822 1511 POSTEL@ISIF

This Network Working Group Request for Comments documents the currently assigned values from several series of numbers used in network protocol implementations.