Network Working Group J. Postel Request for Comments: 77 UCLA NIC 5604 20 November 1970 Network Meeting Report 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. The meeting will be lumped together and ideas may or may not be identified as to their originator. The meetings were chaired by Steve Crocker. The meetings began with a listing of topics of concern. 1) A site or group should be designated as protocol testers. As NCP's are implemented they should be subjected to comprehensive testing by an independent group. 2) The Host-Host protocol needs reworking in several areas: error control, overload conditions, allocation of resources, status information, and system crash problems. 3) The immediate need for specification of TELNET, the third level program which allows people to pass through their local hosts and use remote hosts. TELNET must provide facilities to log in at a distant site, run programs, transmit files, and call for help. This call for help is likely to mean getting a systems programmer at the remote site "taking control" of the user console. 4) The documentation of systems on the network must become available to all sites. This is to be done by the NIC with the cooperation of the other sites. Particularly useful will be on-line documentation. It is suggested that each site have an identical hard copy device (e.g. a line printer) suitable for reproducing documents. 5) The use of graphics consoles on the network will require a graphics protocol. People interested in this problem should write position papers on such a protocol. A meeting may be held between the authors of such papers if sufficient interest develops. The papers should be distributed as NWG/RFC's before 1 January 71. 6) Some sites must account for use of their computer resources, thus there must be some network accounting scheme. Sites can be categorized as Research Centers vs. Service Centers. The Service centers tend to have big machines, lots of users, and accounting problems; while the Research Centers tend to have specialized hardware, a small number of users, and no accounting at all. J. Postel [Page 1] RFC 77 Network Meeting Report 20 November 1970 7) Some people are interested in the network as an object of study. In particular UCLA-Computer Science, and BBN wish to perform measurements on the network. Is it appropriate to ask the NCP to keep statistics? After this opening some discussion followed. It was generally felt that changes to the protocol should be made in bunches and at about six-month intervals rather than a continuous stream of small changes. Also that a lead time of three months was not over optimistic. The proposed change to the IMP-Host protocol to get rid of marking was generally approved but it will not be implemented for some time since casual changes to the protocol are undesirable. Tom O'Sullivan suggested that perhaps new and old protocols could work together, that is the new protocol would support the old one as well as provide better mechanisms where possible. Steve Crocker suggested that a new protocol might be developed as a private experimental protocol between two or three sites. It was stressed that it is necessary that the network be used to gain experience, and that we should get teletype-like console use of remote systems going before we get too involved in graphics. Perhaps the graphics protocol should be developed by a different set of people. The scheduling of a graphics protocol meeting was thus discouraged, but papers should still be written. Strong feelings were expressed in favour of first developing use of remote subsystems and file transmission instead of worrying about graphics at this stage. It was suggested that development of protocols at the higher levels be driven by applications. Documentation will be a major concern for network users. Several people mentioned that users at their sites have already begun to inquire about the network. As Eric Harslem put it "What does the ARPA Network have to offer?" Some sites (Multics, SRI) keep system documentation on-line. It was suggested that the trillion bit store be used to keep on-line documentation of all systems. At this point Doug Engelbart gave a presentation on the Network Information Center (NIC). The goals or services of NIC have not been well defined by anyone and have been left up to NIC to define. NIC has decided that one urgent task is to make information about the network and the host systems on the network available to users of the network. Doug has found that some people feel threatened by the revelation of their documentation inadequacy. Doug's project at SRI has built up a system that allows the user to create catalogs and indices into a collection of information. The system has a master catalog of all information files. Each user may have a number of private (or shared) catalogs. The system provides a means of examining on-line the catalogs J. Postel [Page 2] RFC 77 Network Meeting Report 20 November 1970 and amending them. The system also provides a means to examine any information file which happens to be on-line and for creating new information files on-line. Several problems will delay the NIC from coming on the network. One of these is the switch from the XDS-940 to the PDP-10 (TENEX). The switch is being made because the 940 system is inadequate to handle the anticipated load. At first it was planned to offer service on the 940 and switch to the 10 when it came up, but too much effort would be required for a very small payoff. Doug explained the working of the Network Dialoge System. At each site there is a communication agent and a technical liaison officer. The agents will be trained by NIC to use the facilities of NIC to get information about the Network and other sites. The agents will acquire from NIC documents of interest to users at the local site, be able to contact NIC at a toll free number, and should have an on-line console into the network (and therefore NIC). Thus the Network Dialoge System is a network of people (the agents). Steve Crocker then brought us up to date on the status of the network. He drew a picture of what is connected and what is proposed. He discussed the level of implementation at various sites. Eric Harslem mentioned that RAND and UCSB had conducted tests of their NCP implementations last week (10 Nov 70) and that things worked well. Frank Heart announced that BBN was planning the development of a "Terminal" IMP. The Terminal IMP would support some large number of a wide range of consoles as well as provide the normal IMP functions. At this point we broke and scheduled to reconvene Tuesday morning. The Tuesday meeting started with Doug giving another pass at explaining the SRI system at a more detailed level. The basic thing to deal with is the collection. The user can query over the collection or over sub collections. The user can obtain bibliographic references of three kinds: a) full references, b) first line, c) author indexed. Information files of the collection may be on-line, in tape libraries, or only in hard copy. It is suggested that much data could be kept at other network sites, for example the trillion bit store and before that perhaps on disk at UCSB. If files are kept at other sites then the system must be able to retrieve them automatically when they are requested. The subsystem to be used is called TODAS. TODAS is an evolving program and the documentation of TODAS is inadequate. In TODAS, file are organized hierarchically, each paragraph is numbered, and it is possible to do context analysis on the text. J. Postel [Page 3] RFC 77 Network Meeting Report 20 November 1970 Doug then mentioned some things about the console interaction. This raised a question about half vs. full duplex and line oriented vs. character oriented systems. The remainder of the meeting revolved around this issue. I shall try to define the terms as I understand them for purpose of clarity in the following. Half duplex is the situation where the console, a peripheral processor or some very low level software, echos the character entered. The console can not be used to input data while output is in progress. Full duplex is the situation where the character typed is echoed by software, and input can be done at the same time as output. In line oriented systems the user enters a complete line terminated by an extra sensitive and of line character (e.g. carriage return). Often the keyboard is then locked until after the next output. In character oriented systems each character the user enters is interpreted by software before it is echoed and the echo may be different from the character entered. In particular after a few character the software may guess what the user wants and complete the line for him. The following chart will be used for clarity. | Half Duplex | Full Duplex ______________|_____________|_____________ | | Character | | Oriented | type1 | type2 | | ______________|_____________|_____________ | | Line | | Oriented | type3 | type4 | | ______________|_____________|_____________ It was discovered that many people don't really know where their own systems fit in this chart and are very vague about what it means to interact with a system in a different than their own. Doug stated that NIC has a system of type 2 but would try to provide service to all types of systems. The following table shows systems with their interaction type and categorization as to Research vs. Service Center. J. Postel [Page 4] RFC 77 Network Meeting Report 20 November 1970 System Interaction Type Categorization UCLA - Sigma-7 2 - char, full Research UCLA - 360/91 3 - line, half Service MIT - Multics 3 - line, half Service SDC 3 - line, half ? RAND 3 or 4 - line, ? ? SRI 2 - char, full ? Al Vezza promised to study this problem and to circulate his results as an NWG/RFC. It was pointed out that line oriented systems usually allow line editing of the form "delete last character" (back space) and "delete line", however this feature does not alter their classification as to interaction type. Concern arose over what do line oriented systems expect to receive from the network for a connection acting as console input to a subsystem. Steve Crocker made the suggestion that when using a line oriented system transmission be in lines. More precisely that transmission be in strings of the following form. n c1 c2 ...cn where 1 <= n <= 120 (n is eight bits) and if ci is an "end of line" character then i = n This suggestion was not immediately accepted and some discussion took place regarding the significance of Host-Imp-Host message boundaries. Doug brought up file transmission and the problem of finding the end of the file, which provoked more discussion. At this point the meeting broke up with a third session scheduled for 8:00 p.m. Wednesday evening. The Wednesday meeting began with the suggestion that at future xJCC's there be an official ARPA Network hotel with a block of rooms on one floor and a nearby meeting room for networkers. This suggestion was favored by all. Steve Crocker asked how people felt about these meetings. The general feeling was that the meetings were very useful and should occur about 3 months apart. Al Vezza pointed out that meetings this size (15 - 30 people) are good for bringing up problems but not for putting them down. Steve proposed that 3 or 4 people be designated to solve particular problems. Al responded that 3 people can't legislate. That any such J. Postel [Page 5] RFC 77 Network Meeting Report 20 November 1970 solution must be considered in the same way as a proposal by an individual. Steve persuaded Peggy Karp to act as NWG/RFC editor. This is a job independent of cataloging RFC's or assigning numbers (functions now performed by NIC). The RFC editor will only categorize RFC as "hot issues", current, out of date, or superseded. The subject of Logger protocol -- that is, how to get the first connection -- needs to be officially defined. NWG/RFC #66 suggests one way. Eric Harslem will revise this and send it out as proposed official protocol. Ed Myer will also send out a proposal. Steve then opened up discussion of the topics of the previous meeting by suggesting we talk about the following: Message boundaries, half duplex vs. ull duplex, line oriented vs. character oriented, file transmission, byte counts in messages, byte sizes and transactional units. It was proposed that transactions on the command link (i.e. between NCP's) be always in multiples of eight bits. This mean that the length field in the ECO, ERP, and ERR commands will always have three low order zeroes. This was approved. Steve then proposed that connections could be established with a declared byte size and a maximum record length in bytes. Transactional units on this type of connection would be of the form n c1 c2 c3 ... cn where 0 <= n <= max record length if n = 0 then the transactional unit acts like a semaphore. Steve suggested that we should look into the theory of information exchange, particularly along the lines of Richard Kaline (NWG/RFC #60). Perhaps for each information unit sent there should be some status response. The next question was on file transmission. In particular, how do you find the end? Frank Heart suggested that with each portion there be a flag indicating "this is not the end" until in the last portion the flag is switched to indicate "this is the end". Eric Harslem suggested that each portion should have an "opcode" field, a length field, and the text which is length bits (bytes?) long. This appears to be like the data types proposed at the Lincoln Lab meeting last spring. Ed Myer proposed that two connections be used, one for the file transmission and the other to control it. The file control connection would specify the data connection and indicate that transmission as about to start. After the sender had completed the file transmission he would send on the file control link the total number of bits sent. The receiver would then know how many bits to receive and exactly where the end of the file should be. Bob Metcalfe was concerned that some of the proposals mixed J. Postel [Page 6] RFC 77 Network Meeting Report 20 November 1970 control information with data and felt that perhaps this mixing should be avoided. Steve asked if anybody could suggest an advisor we might talk about these problems. Bob Metcalfe suggested Anatol Holt. Bob Sundberg suggested George Mealy. Eric Harslem and Peggy Karp suggested that people who worked on the COIN System might be helpful. Frank Heart suggested that no one has solved these problems. Steve proposed that Service Centers offer line oriented interaction with no echoing of the input. Any simple editing (e.g. back space) would be done at the using site. Ed Meyer suggested that there be official protocols for both line oriented and character oriented interaction. Steve promised to write a NWG/RFC clarifying the issues and laying out the arguments on full transactions, byte counts, and accumulating data on the receive side. It was felt that these were hard problems that needed more thought. Thus the meeting was adjourned with the request that people circulate any ideas or proposals as NWG/RFC's. Ed Myer took notes and agreed to also prepare a NWG/RFC summarizing these meetings. J. Postel [Page 7] RFC 77 Network Meeting Report 20 November 1970 Network Meeting Attendance List 16 - 18 Nov. 70 Houston Name Site Sessions 1. Dick Benjamin MITRE 1 2. Jack Bouknight Illinois - CAC 1,2 3. Al Cocanower MERIT 1,3 4. Steve Crocker UCLA - SPADE 1,2,3 5. Doug Engelbart SRI - ARC 1,2,3 6. Wayne Fischer MERIT 3 7. Richard Greenblatt MIT - AI 1 8. Eric Harslem RAND 1,2,3 9. Frank Heart BBN 1,2,3 10. Allen Joseph ORNL 1 11. Peggy Karp MITRE 1,2,3 12. William Kehl UCLA - CCN 1 13. Bob Long SDC 1,2,3 14. Jim Madden Illinois - CAC 1,2 15. Bob Metcalfe MIT - DM 1,3 16. Edwin Myer MIT Multics 1,2,3 17. Ari Ollikainen UCLA - SPADE 1,2,3 18. Tom O'Sullivan Raytheon 1,2,3 19. Jon Postel UCLA - SPADE 1,2,3 20. Chris Reeve MIT - DM 1,3 J. Postel [Page 8] RFC 77 Network Meeting Report 20 November 1970 Network Meeting Attendance List 16 - 18 Nov. 70 Houston Name Site Sessions 21. Tijaart Schipper UCLA - CCN 1 22. Michael Sher Illinois - CAC 1 23. Bob Sundberg Harvard 1,2,3 24. Hal Van Zoeren CMU 1,2,3 25. Albert Vezza MIT - DM 1,2,3 26. Alfred Vorhaus MITRE 1 27. Clark Weissman SDC 1 [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gottfried Janik 02/98 ] J. Postel [Page 9] ------------------------------------------------------------------------- Network Working Group Edwin W. Meyer, Jr. Request for Comments #82 MIT Project MAC Network Information Center #5619 December9, 1970 Network Meeting Notes The following summary was transcribed from notes I took at three network meetings held in Houston during the 1970 Fall Joint Computer Conference. Although I have tried to be objective, unavoidably these notes present a biased view of the meetings. This is due in part to my preoccupation with certain topics and possible misunderstanding of various discussions. While I have tried to accurately paraphrase the statements of the attendees, the import of some may have been twisted. Attendees of Monday Meeting Dick Benjamin MITRE Jack Bouknight UI-CAC Al Cocanower MIRUT Steve Crocker UCLA Dough Engelbart SRI Richard Greenblatt MIT-MAC Eric Harslem RAND Frank Heart BBN Allen Joseph ORNL (Oak Ridge) Peggy Karp MITRE William B. Kehl UCLA Bob Long SDC Jim Madden UI-CAC Bob Metcalfe MIT-MAC Edwin Meyer MIT-MAC Ari Ollikainen UCLA Tom O'Sullivan Raytheon Jon Postel UCLA Chris Reeve MIT-MAC Tjaart Schipper UCAL-CCN Michael S. Sher UI-CAC Bob Sundberg Harvard Hal van Zoeren CMU Albert Vezza MIT-MAC Alfred H. Vorhaus MITRE Clark Weissman SDC Meyer [Page 1] RFC 82 Network Meeting Notes December 1970 Network Meeting 8:05 PM Monday, 11/16/70 Crocker: Not everybody is here, so lets talk until more people get here. is everybody satisfied with the agenda in my announcement ? Meyer: We should talk about logger protocol. Operational usage of the net- work, as opposed to experiments, depends on its implementation. Introductions to all around. Crocker: I have an agenda, but want suggestions for topics. 1) I will make introductory remarks. 2) I will list topics of concern. 3) Englebart will talk about the Network Information Center 4) I will review the status of sites. Introductory remarks 1) ARPA will not pay for the coffee and pastry being served, so please chip in to help me pay for it. 2) I am going to devote full time to network coordination in an official capacity. My goals are: (a) to build up usability of the network. (b) to establish protocol levels, (c) ? Areas of importance 1) Some site of coalition of sites should prepare a method by which a site's NCP could be checked out. 2) Reworking of NCP protocol. Some issues could be solved better: (a) error control, (b) flow control, (c) overloading - loosing network states, (d) simplification and relayering of protocol. 3) Telnet system console interaction, or logger protocol. How to get into the system and how to get help when in trouble. 4) Documentation of individual hosts. Network Info Center involved. Perhaps each site could be provided with a facsimile device. 5) More sophisticated consoles, particularly graphics consoles, to be attached through network. There should be a working group to formulate and workout a format for handling sophisticated consoles. There will be a graphics meeting in January in Colorado or Utah. The price of admission is to write a proposal. I expect up to 30 people. I will pick a small subset to develop specifications. Meyer [Page 2] RFC 82 Network Meeting Notes December 1970 6) Accounting - In the 2nd half of 1971 more sites will come on where accounting is important. (They want to send bills.) Larry Roberts says that there will be a kind of banking system with bills passed around. Two types of sites: billing sites, and free but limited access research sites. I see no fundamental problems. What happens when a research site talks to a billing site? I think it is do-able. 7) Measurements - the network is a tool, but it is also a model that is better than a simulation package. Various people want to make measurements. This could be supported by keeping statistics in NCP's What about increasing the NCP's to include these? Long: Putting accounting and measuring into NCP's costs space. Keep additions to a minimum. Weissman: What about scheduled availability of various systems? Crocker: This has to be coordinated with each individual system ? : What happens to connections when a system goes down? Crocker: What about graphics proposals? I will write my own paper as a proposal. It uses the DEC 340 as a model. Modes assumes scope system a memory. Both output-input are included in standards making. I want a competent protocol to be developed out of the working group. Crocker: What about documentation? Meyer: Documentation on how to use other systems are a must. Only this can motivate operational use of the network. --: What about putting documents on-line at each site, or at least abstracts. Crocker: What sites have documents on-line? (MIT and Harvard) How do the sites feel about keeping documents on some foreign system? Crocker: What about reworking the protocol? Harslem: We have logged into the UCSB system and are debugging cooperatively. Harslem: We are impressed with eliminating marking and padding (per RFC 67). Meyer [Page 3] RFC 82 Network Meeting Notes December 1970 Crocker: We discussed this with the sites. Most seemed to accept it, but some reservations. What about changes to the basic protocol. I'm Meyer has something to say. Meyer: The position at Project MAC is that at this point we are opposed to changes other than critical fixes. Time spent on changes is time that won't be spent on developing other necessary and interesting protocols and systems. And we at Multics have a long lead time for creation and installation of changes. Weissman: I prefer to put in changes in one chunk, say at 6 month intervals. rather than in bits pieces. O'Sullivan: Can't current and new systems work simultaneously? Crocker: If the changes involve the IMP, no, because all IMPs want to operate the same system. Meyer: The feeling at M.I.T. is that to be a success, the network needs desperately to be used operationally. If another year passes without significant operational use, it might go down the drain. --: And documentation is critical towards motivating operational usage. Engelbart: Perhaps we should put off graphics several months so as not to delay typewriters. Typewriters are important. --: But would that be sufficiently impressive for DOD people? Engelbart: But if it turns out to be a can of worms in two years... --: But do the two (typewriters and graphics) development groups interact? Vezza and Engelbart: Yes. Crocker: Let's hear more about this. Harslem: We want to be able to access files. Crocker: Then perhaps the graphics effort would dilute typewriter development. Is it the consensus of this group that we shouldn't have a graphics meeting? Vezza: Newcomers should work on graphics, not established people. Prohibit current people form going to this meeting. Meyer [Page 4] RFC 82 Network Meeting Notes December 1970 Meyer: That would be very frustrating. Benjamin: Why not solicit position papers (but have no meeting). Weissman: Character transmission is easier than graphic transmission More experiments needed for graphics. The lead time for developing a graphic protocol is much longer than for typewriters. Vezza: I agree. Crocker: There will be more meetings in the next few days to work on problems of getting useful work over the network. Intermission 9:15 PM Crocker: Engelbart will speak on Network Information Center. Engelbart: NIC grew as an ad hoc thing, with no specific directives from ARPA. What kinds of things were envisioned? (1) Sophisticated query systems, (2) Basic information about systems at each site. Everyone feels very vulnerable about the state of documentation at his own site. Everyone agrees: better documents necessary. We see ourselves as providing the following services: 1) collecting hard-copy material; 2) on-line querying of catalogs and indices of these; 3) giving access to this material. We decided to go hard copy rather than on-line, perhaps on microfiche. Engelbart: As 940 was to be used for the documentation system, expandable as usage increase. We are switching form a 940 to a 10X to better expand service capacity. Amount of capacity goes up considerably. This has held up work on other facets. A conscious gamble. We are worried about getting of the ground. We are short on funds for more secondary storage and are interested in using other hosts for tertiary storage. The cost of implementing the protocol on the 940 was too high for potential gains, so it was given up. Few sites would be up by January when our 940 was to be shipped out. Engelbart: We have created a Network Dialogue System. This is a network of human agents. At each site there is: a) technical communications agent (secretary) and b) a technical liaison person. We are encouraging agents to talk to us and have created "Enterprise" phone numbers so they can talk toll free. Meyer [Page 5] RFC 82 Network Meeting Notes December 1970 Engelbart: We are at first sending out a tiny kit to each agent, a growing collection of network reference information. One person (agent) at each site is to be trained to handle the set of documents and retrieve information of contact another site's technical liaison. This involves a public dialogue, keeping a record of the documents passing back and forth. This is a sort of "human IMP" network, structured as follows: ________________________________ | | | ________________ | | | local | | one | | reference | | <== site ____________ | | material | | ( ) | -----------------| | ( ) | | => (____________) | | || \\ | | || Other sites | | || \\ | ________ | || ____________ | local =====> | |================ ( ) | users | agent |=====|===============( ) | =====> |________| | (____________) | | |________________________________| 1) Master collection has all material. 2) Each local collection has a subset considered most useful. --: What about restricting access to documents? Engelbart: All files are public files in this system. Vezza: You can send a private memo rather than use the NIC service. Engelbart: The master collection contains books and other documents. Cataloged on-line. Hard copy stuff can be duplicated. For information that passes the value test, the service is to store, catalog, index, and provide access to documents. We will support a number of different terminal. We are prepared to go a long time with hard copy items, but can establish a hard copy to on-line transcription service for a price. Weissman: What about distributing OCR Selectric balls to sites? --: Will NIC take what is sent or actively search it out? Meyer [Page 6] RFC 82 Network Meeting Notes December 1970 Engelbart: More or less what comes our way. A system will exist in Spring 1971, to allow an agent to insert items into a catalog. The dialogue that goes on will determine which way the data base grows. We are pretty sure that eventually SRI will have to charge because of many potential users not at primary sites seeking limit resources. --: What about an NCP for your 10X. Engelbart: If BBN's NCP is ready by February 1971, we'll use it. Crocker: How do people get access? Engelbart: Each site is registered. Any person who gets in on a site's account has its access. We won't worry about accounting until saturation occurs. We would like to encourage use of the agent system to create and use a survey of resources at each site. Some subgroup should talk about this. Crocker: When can people meet to discuss this? (Tomorrow morning) Engelbart: We have nice facilities for developing mailing lists, private bibliographies, personnel profiles, but it depends on the interest of the network people. Engelbart: Agents have been set up with MIT, UCLA, RAND, UI, Utah, etc. A good percentage of sites Vezza: Many sites are sending out stuff 3rd and 4th class. Takes too much time. Crocker: Site status report. ILLIAC IV not to be operational until mid-71, on network later (72?). Other possible sites: RADC, AWS, NCAR. Currently up: UCSB, RAND. Imminent (January 71): MIT BBN, Harvard, UCLA, Utah, LL, SDC. Some percentage by end of year rest in January. Heart: A brand new IMP system (major change) goes in tomorrow. Some more sites are thinking about coming on. The network will grow consider- ably beyond what's already on board. We too are interested in site resource information. No long term interest, but we will put information on paper to help ARPA. Crocker: A lot of people are yawning. What about meeting schedules? During FJCC's? 1 day vs. 2 day meetings? What about dual East and West coast meetings? End of Meeting Meyer [Page 7] RFC 82 Network Meeting Notes December 1970 Network Meeting 9:15 AM Tuesday, 11/17/70 Crocker: Engelbart will talk in more detail. Later may discuss logger protocol and file transfer. Engelbart: Basic thing is a collection of documents with a catalog to describe it. Entry has lots of data items, including where to find it. Techniques for adding and updating entries. We do it now, but would want to give capability to other sides, partly because we can't determine what's of value. (Displayed 3 types of printout.) 1) Catalog listing, by ordinal index in collection and NIC index. for inventory control, finding out what's there. 2) Compacted format on one line. 3) Sorted by author-one line per entry. We Will have procedures where an untrained user can manage a collection. Meyer: How are these systems implemented? Engelbart: We have a compiler-compiler on the 940. Our subsystems are written in specialized high level language. We are moving this over to the 10X. Heart: How many people can the 10X support in rough figures? Engelbart: Perhaps 100-1000 collections. --: Perhaps people could supply own DEC tapes for additional storage. Engelbart: Could, but requires on-site operator. Slow access. We don't have money for more storage, but are considering shipping files down to UCSB. We provide on-line querying of on-line data. Willing to worry about data management, whether or not we store it. Crocker: Please describe the various subsystems. (Description by Engelbart follows.) Heart: Have people tried to use it over the network? Engelbart: No. Don't have an NCP on the 940. Decided against putting it in a system that is going away. The biggest hang up is when 10X gets an NCP. Bobrow developing it, but it is slipping. Heart: Who is going to get at it (SRI) early? UI: Illinois can access only SRI to begin with. Meyer [Page 8] RFC 82 Network Meeting Notes December 1970 Postel, UCLA: We plan to use it. Heart: Would be a significant task if someone would take it as a goal to get into Engelbart's system. MITRE: We're going to use other systems form BBN's 10X. Engelbart: We are trying to isolate essential subsystems for people to use easily. Files are organized hierarchically and will fill out as years go by. Documents are referenced by pathnames. (Discussion of systems follows.) Crocker: Row does one get into the system? (Engelbart describes entry sequence to TOdas.) Crocker: How does one get registered on the system? Engelbart: Ultimately by personal entry, but currently there is one user id per site. Meyer: I think we're ignoring unsolved problems in the typewriter interfacing. For example, the entry sequence to TOdas, where the user type one or two characters and the system types out the remaining chars of a key word, will be frustrating to use form half-duplex system like Multics. Our system will not recognize an input line until a new line is typed. Various: Discussion of 1/2 duplex communication. Brings out distinction between a) Full duplex systems where system echoes input vs. 1/2 duplex where input typed locally, and b) systems where each character is recognized as it is typed in vs. systems where entire line is recognized only after EOL char. Crocker: Isn't Multics the only half-duplex line-oriented system on the net- work? Meyer: I can't believe this. Don't the IBM systems operate like that? Engelbart: We could have a 1/2 duplex interface on our system (SRI). Is it the Multics hardware that enforces this restriction? Meyer: Yes, the input-output controller.* ______________________________________________ * The Multics IO controller's typewriter adaptor is 1/2 duplex, but can accept break characters other than the "new line" character. Meyer [Page 9] RFC 82 Network Meeting Notes December 1970 Engelbart: Each system should have a preprocessor to talk with other systems. We're going to put a graphics interface onto the network. Meyer: How do you view these interfaces? Do these adhere to some network standard, or ill each system construct an interface to you? Engelbart: Standard network protocol. Crocker: Let's move on to other things. O'Sullivan: What about 2741's on your (CMU) 10X system. Do you have serious interfacing problems? (CMU's 2741's go through a software package that transforms them into TTY 37's. No serious difficulty.) Various: Brief discussion on how Multics handles input. Sundberg, HARVARD: Out 10X can take char-oriented input, but our higher level subsystems prefer line-oriented input. --: What about the efficiency of transmitting messages through the network one character at a time? Crocker: There is more output, which goes packed, than input, so the input inefficiency is negligible. Engelbart: We plan to have several different ports into our system. If each system had an NIC module; it could communicate with us without the necessity of a login. We prefer a batch-type system, where a site sends spooled batch of edit requests, gets stuff back, and frees ports. The typewriter transmission by line problem could be handled similar to spooled-up requests. We encourage spooling, but will support interactive users. We can support more batch than inter- active people. * The Multics IO controller's typewriter adaptor is 1/2 duplex, but can accept break characters other than the "new line" character. Vezza: Do people feel that the full and 1/2 duplex issue is a problem? Let all the people go back and find out about this. M.I.T. with a full and 1/2 duplex system 20 feet apart can help here. O'Sullivan: There seem to be 2 issues: (1) echoing (full duplex) vs. 1/2 duplex. (2) single character vs. full line transmission. Meyer [Page 10] RFC 82 Network Meeting Notes December 1970 Crocker: Two definitions: Serving host - provides computation; using host - parasitic, manages user's terminal. This view network usage as a link between local user and foreign server. Vezza: What about 1/2 duplex - full duplex interconnection if some full duplex systems echo other than what was input. Crocker: Two independent possibilities. Let's diagram: | "2741" | "33, 35, 37" | | hard wire | 2 separate | | local echo | lines all | | computer does | printed | | not echo | | ____________|_________________|___________________| Process | hard | X | each | | | character | | | ____________|_________________|___________________| Process | X | easy | only after | | | EOL | | | ____________|_________________|___________________| Crocker: I claim there are really only two possibilities (marked by X's). Postel: Why about a system where echoing is done at such a low level that it can't be deleted. Crocker: If so, it's like non-echoing. Van Zoeren: Out system thinks we have full duplex TTY's, but our 2741's are attached via a software transformation box. Meyer: What happens when non-echoing systems are attached to echoing systems via the network? I type my input line, then the echoing system responds with my input, then some output. My system can't filter this because there is no way of differentiating echo from output. Crocker: This isn't necessarily a bad thing. I type command abbreviation to SRI; then next output line is an expanded form of the input command. Meyer: Our goal should be one common protocol rather than a bunch of kludgy schemes to implement communication between specific pairs of hosts. Meyer [Page 11] RFC 82 Network Meeting Notes December 1970 Long, SDC: We prefer to receive a full line fed through the network. Crocker: Let's differentiate between research centers and service centers. Only the service centers are concerned with a half- duplex interface. (lower left hand X on chart). These include SRI, BBN, Multics. O'Sullivan: What about research center? Crocker: They can call up service centers, but may themselves be hard to use. Illinois: Then the ILLIAC IV will have to be half-duplex. Postel: I think half-duplex, line-oriented is weaker (than full- duplex, character-oriented protocol). Sundberg: Harvard can go either way, but prefer line-oriented system. Engelbart: Graphics terminals harder to put on network because of non-standard input. Harslem: You're thinking of the keys as function keys rather than input keys. Engelbart: I'm worried about people who want to use graphics. O'Sullivan: We haven't spoken to the problem of what kind of protocol should be established. Crocker: That's not a difficult technical thing. We'll get to that later and make a decision. Meyer: I'm not authorized to make any decision. I'm to report back to the MAC group. Crocker: Okay. Then, a proposal, to be accepted through the normal mechanism. Intermission Crocker: I will propose how to handle X'ed boxes, ignoring hard and ease boxes: Line-Oriented Input - 8 bit ascii including End of Line character: n, C1,...,Cn; Cn=EOL Meyer [Page 12] RFC 82 Network Meeting Notes December 1970 120>n>>_1 n is the character count in an 8-bit field. The character count precedes the line so as to give the software system the same efficiency as the hardware system, the computer doesn't have to scan for the EOL. Vezza: Don't you get the length information with the IMP message? Crocker: My philosophy is that IMP message boundaries should be completely invisible. Long: I object to splitting typewriter messages into two separate chunks. Crocker: What is your objection, 1) Lines beginning on message boundaries or 2) message not beginning on a line boundary? Long: Both. Engelbart: Each host should write an interface to handle the most common terminal types. Crocker: The official protocol does not allow IMP message boundaries to have any significance. Engelbart: I don't want to worry about IMP message boundaries. The network should be invisible (at this level). Vezza, Long: We'll concede, we'll go along. Meyer: I'd like to change the restriction. The last character in the line packet need not be an EOL (as when an output does not advance to a ne line), but an EOL cannot appear in the midst of a packet. Van Zoeren: I don't like this restriction. Meyer: Count tells us that any EOL is at the end, we need not scan. Crocker: The EOL is the character that tells the system to take action. Harslem: Our system has 46 function keys, not just one EOL. Crocker: How about if C, E {breakset}; i=n. This s more complex, because have to transmit a breakset. I'll propose this in a moment. How about this: message oriented (1/2 duplex) connection Meyer [Page 13] RFC 82 Network Meeting Notes December 1970 between User and Server hosts for console interaction. Local echo, no server echo. This is for line oriented service systems. These are slight generalizations of Multics conventions. Meyer: I'm sure other systems other than Multics use it. It's not as bad as you seem to think. Engelbart: Upper management should know that it is bad. Meyer: That's not clear. There are efficiency questions. Van Zoeren: I don't want to have to transmit files this way. Crocker: This is for consoles, not file transmission. Engelbart: We need a unified scheme for data transmission. O'Sullivan: (For consoles) we're to devise a way to tell a system where its interrupt should be simulated. Crocker: There is a general problem of data transmission for tapes and files. O'Sullivan: But we have the specific problem of implementing typewriter communications. Engelbart: But what we need is a general way of sending stuff through the network (so it is invisible) and have the host interpret it as it wants to. Meyer: There should be one console interface for the network, not several at each site. Crocker: This problem is perhaps overblown. Engelbart, Meyer, O'Sullivan: Discussion about supporting specific terminal types. Engelbart: I'll draw a graph of systems vs. terminal type. The intersection of a system and a terminal that is accepted by that system is marked by a dot. Network communication problem is one of finding a terminal at local host that is also supported at the target host. Meyer [Page 14] RFC 82 Network Meeting Notes December 1970 _____|_____|_____|_____|_____ | | | | systems_____|_____|_____._____|_____ | | | | _____|_____._____|_____|_____ | | | | _____|_____|_____|_____|_____ | | | | terminals Crocker: There is a general problem of a subsystem reacting to input. Let's propose that input should be sent as a full message or in multiples of 8-bits. Vezza: Are we constraining too much? Meyer: Why is it necessary to have 8-bit multiples? Crocker, Engelbart: Okay throw that away. End of Second Meeting Network Meeting 8:20 PM Wednesday, 11/18/70 (The following notes are greatly condensed and attempt only to present the major themes discussed at this meeting.) Crocker: Let's meet at the SJCC with more prior organization. Let's have several day meetings at 2-3 month intervals. We've got a lot of good discussion on the next level protocol. Let a subgroup work if out. (Harslem volunteers to redraft the logger protocol proposed in RFC 66. Meyer will revise proposal in RFC 46.) Meyer: Let's go back, discuss these issues, write proposals. Later we have an open meeting to decide on a formal proposal. Crocker: Small group is better, perhaps I'll pick a subset. Meyer [Page 15] RFC 82 Network Meeting Notes December 1970 Vezza: It's true that things aren't settled here. Major proposals should be on paper preparatory to a meeting. We can't legislate what a small group does. It has no more authority than an individual. (Karp of MITRE volunteers to produce a bibliography of network documents, perhaps by January.) (Who has implemented logger protocol? UCSB and UCLA mod 91 have or are planning. SDC may have it by 21/1, found it awkward, willing to change.) (Discussion of file transmission. Crocker proposes that a future protocol change might attach a byte size such as 8, 32, 36 bits to a connection.) (Regarding control links, everything is transmitted in 8-bit bytes except ECO, ERP, ERR commands, No objection was voiced to changing the protocol so that they also must be multiples of 8-bit bytes.) (Discussion of how to specify the end of a file. Prior transmission of bit count, or send EOR character at end? Suggestion that we want global solution to the general problem of sending an arbitrary length message, rather than just file transmission.) (Discussion of "transaction units" or record sizes. What is an optimum transaction unit size? IMP message boundaries are invisible (by protocol fiat) and are not connected with this discussion. Multics block size was brought up. Nearest thing is page size, 1024 words.) (How to specify end of file. Engelbart says send data packets, then EOF packet. Crocker suggests that CLSing connection can act as EOF. Vezza suggests that IMP message boundaries be used to determine end. If less than full IMP message, this is last part of file. Meyer suggests use of two connections, data channel and control channel, over which all control messages, such as file name, bit length, etc. are passed.) (Discussion concerning different situations in which whole file, part of the file, or the whole file in arbitrary chunks was wanted.) Meyer: Why not defer this, and talk about typewriter communications, which is most critical. Vezza: Engelbart wants a clean general solution. Meyer [Page 16] RFC 82 Network Meeting Notes December 1970 Crocker: If we get an ad hoc solution now, it may interfere with implementing a general solution later. (Crocker proposes format for transmitting a file of arbitrary length records of fixed sized bytes of 8-26 bits. A record is less than 10^5 bytes. Each record is headed by a count byte.) 1 2 n 1 2 m |----------------------------------------------------| | n | | | | | m | | | | | |----------------------------------------------------| <------- record -----------> <-------- record -------> O'Sullivan: Does this model fit a terminal which has character and graphic modes? (Discussion about differences between keyboard and file transmission. Uncertainty as to whether a global solution would fit both.) (Who wants to ship files through the network? Multics and 6-10, RAND to UCLA, MITRE using BBN.) Crocker: Let's go away thinking about this and propose solutions later. (Harslem proposes format for transmitting data with operation codes. Each record consists of: . Gives the opportunity to send many type of status info.) (Discussion regarding sending data and control information intermixed or on separate connections. Issues of pollution of data vs. synchronization and race problems. Claimed that synchrony problems are easily overcome.) (Suggestion that we really don't know much about this area. We should go off and write.) Intermission Crocker: What has to be done before we can log onto other systems? Meyer: 3 issues: 1) ho to establish the connection, 2) what is the character set, 3) what is the mode of transmission (relating to full and 1/2 duplex problem). (Discussion of orienting standard protocol towards service systems which generally are line-oriented and 1/2 duplex. Any systems offering services to have a 1/2 duplex interface.) Meyer [Page 17] RFC 82 Network Meeting Notes December 1970 (Discussion of whether possible or desirable for the logger protocol to allow transmission of partial lines in a IMP message. Less efficient to take partial lines, reasonable to send full line. Pointed out that NCP protocol disallows any meaning to IMP message boundaries, so systems must be prepared to accept lines straddling IMP message boundaries. However, best to send complete line.) (Discussion of whether line-oriented protocol protocol should bend so as to accept single character transmission from full duplex systems. Seems that we are coming up with a protocol to allow any system to use a line- oriented system. To use a char-oriented system form other systems is more difficult and requires a separate protocol.) Heart: I am in favor of an immediate solution. Postel: Once something goes in, it will be hard to change it. Crocker: I think these meetings will turn out to be more important than we ever wanted them to be. I am more concerned with the long term effects than the starting date. Van Zoeren: If we don't decide it, somebody else will decide it the bad way. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gottfried Janik 2/98 ] Meyer [Page 18] ------------------------------------------------------------------------ Network Working Group S. Crocker Request for Comments #75 UCLA 14 Oct. 70 Network Meeting 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. The purpose of this meeting is to discuss several topics related to the practical use of the network. I have in mind: (a) accounting mechanisms (b) documentation distribution (c) person-to-person message sending and message storing (d) access to systems by foreign users Attendees are invited to raise other topics. I envision that this meeting will spawn smaller subsidiary meetings during the FJCC to pursue these or related topics. Prospective attendees should notify my secretary Benita Kirstel (213) 825-2368 so that we can be sure the room is large enough. Unexpected attendees are nevertheless invited. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Lloyd Duhon 4/97] [Page 1]