summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc82.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc82.txt')
-rw-r--r--doc/rfc/rfc82.txt1011
1 files changed, 1011 insertions, 0 deletions
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: <opcode> <length> <data>. 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]
+