From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc82.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc82.txt (limited to 'doc/rfc/rfc82.txt') diff --git a/doc/rfc/rfc82.txt b/doc/rfc/rfc82.txt new file mode 100644 index 0000000..a50bca6 --- /dev/null +++ b/doc/rfc/rfc82.txt @@ -0,0 +1,1011 @@ + + + + + + +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] + -- cgit v1.2.3