rfc77.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 508 行 · 第 1/2 页

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.