summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc585.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc585.txt')
-rw-r--r--doc/rfc/rfc585.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc585.txt b/doc/rfc/rfc585.txt
new file mode 100644
index 0000000..f21308e
--- /dev/null
+++ b/doc/rfc/rfc585.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group D. Crocker
+Request for Comments: 585 UCLA-NMC
+Category: Users N. Neigus
+NIC: 18259 BBN-NET
+ J. Feinler
+ SRI-ARC
+ J. Iseli
+ MITRE-TIP
+ 6-Nov-73
+
+
+ Arpanet Users Interest Working Group Meeting
+
+ A new group, the Arpanet Users Interest Working Group (USING) is the
+ outgrowth of a meeting held in Boston on May 22-23, 1973. The
+ meeting, cochaired by Dave Crocker, UCLA-NMC, and Nancy Neigus, BBN,
+ followed BBN's Resource Sharing Workshop.
+
+PURPOSE
+
+ The USING meeting was seen by the members as a forum for Network
+ Users to air complaints, exchange information, voice desires, and
+ present concrete proposals for the design and implementation of
+ user-oriented Network capabilities.
+
+ The group will devote itself to lobbying on behalf of user interests,
+ to promoting and facilitating resource sharing, to improving user
+ interfaces (support), and to studies of standardization. The
+ ultimate goal will be provide users identification of, and
+ facilitated access to, whatever resources on the Network they might
+ wish to use.
+
+ Neigus, Crocker, and Iseli of MITRE were selected to define the
+ objectives and goals of USING in more detail, and they will present
+ their discussion in a later publication.
+
+ATTENDEES
+
+ Dave Crocker, UCLA-NMC, Co-Chairperson
+ Nancy Neigus, BBN, Co-Chairperson
+ Ken Bowles, UCSD-CC
+ Frank Brignoli, NSRDC
+ Jim Calvin, CASE-10
+ Jake Feinler, NIC
+ Wayne Hathaway, NASA-AMES
+ Jean Iseli, MITRE
+ Mike Kudlick, NIC
+ Mike Padlipsky, MIT-MULTICS
+
+
+
+Crocker, et al. Users [Page 1]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ Lee Richardson, USC-ISI
+ Ron Stoughton, UCSB
+ Jim White, NIC
+ Steve Wolf, UCLA-CCN
+ Joe Wyatt, Harvard
+
+CATEGORIES OF CONCERN
+
+ The meeting began by attempting to create a relatively complete list
+ of topics directly relevant to users. The intention was to then
+ discuss some of these categories in detail. The categories of
+ concern to users are listed here along with a brief outline of the
+ discussion and recommendations associated with each category. Not
+ all topics were discussed fully due to time limitations. It was
+ acknowledged that some of the recommendations were quite extensive,
+ but that they should be mentioned even though their implementation
+ would be far off.
+
+ 1. Online and Offline Documentation, Information Sharing, and
+ Consulting
+
+ a. There is a general need to upgrade the quality, technical
+ accuracy, timeliness, dissemination, and format of both online
+ and offline documentation.
+
+ b. Documentation should avoid "buzz" words (jargon), and should
+ follow easily understood syntax conventions, abbreviation
+ standards, reference citation rules, etc. However, there
+ probably cannot be a standard format for writing documentation.
+
+ c. Offline documentation should be well indexed, should contain a
+ good table-of-contents, and should be written in an easily
+ browsable format. Online documentation should be presented in
+ a browse mode with well-labeled categories of information as
+ well as a keyword search capability.
+
+ d. Documentation should be identified with date/author/version
+ information, particularly in large online documents, so that it
+ is easier to keep the most current version of a document and to
+ query the author, in the event of problems with the
+ documentation.
+
+ e. Network news needs to be gathered and intelligently distributed
+ to users (Network PR).
+
+ f. Users need several levels and styles of access to
+ documentation, whether online or offline, based upon their
+ experience, interests, and preferences.
+
+
+
+Crocker, et al. Users [Page 2]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ g. Each server site should also provide some degree of information
+ variety in online "help" mechanisms, tailored to fit the needs
+ and experience of different user types.
+
+ In addition, entering "Help" from the EXEC level of a system
+ should direct a user to ALL procedural-type information.
+
+ h. New users should be carefully introduced to the Network by way
+ of a New Users Packet (NUP). Since the MITRE-TIP group is the
+ official contact for new users, they should design such a
+ packet and incorporate suggestions from USING.
+
+ This packet should eventually contain, among other things:
+
+ a definition of, and introduction to the Network
+
+ a list of sites
+
+ step-by-step scenarios for accessing functional documents an
+ related online items
+
+ a definition of who can get on the Network
+
+ some quick-reference charts showing a list of Network
+ services available to new users
+
+ and an introduction to Network groups, including USING, as
+ well as the names of Network consultants, assistants, and
+ the like.
+
+ i. Information-accessing mechanisms should be provided for users,
+ including interactive tutorials, user scenarios, and other
+ training mechanisms.
+
+ j. A Network-wide "who, what, where and when" information system
+ should be implemented. (This was nicknamed the Network Yellow
+ Pages.) Discussion of support for such a system focused on
+ obtaining some form of central funding.
+
+ k. The concept of `Regional Agents' for collecting information for
+ the Resource Notebook was discussed.
+
+ Several felt that what was really needed was a `rebirth' of the
+ original concept of Technical Liaison as the person who
+ provides information to the NIC and technical assistance to
+ users.
+
+
+
+
+
+Crocker, et al. Users [Page 3]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ There was concern voiced about the number of people collecting
+ information and the redundancy of the requests received by
+ sites.
+
+ There was also concern about what incentives there are (or
+ should be or can be) for Liaisons to perform their tasks
+ adequately by providing truly up-to-date and complete
+ information (carrot vs. stick).
+
+ l. Server Sites should provide a variety of consulting services to
+ supplement `help' and general information services.
+ Consultants could represent the whole Network, a group of
+ sites, a single site, general areas such as software, or
+ specific applications processes. This could fit into the
+ workings of the Network Servers Group.
+
+ 2. Standardization for the User
+
+ a. If they so desire, users should only have to learn one
+ Executive (command) language, rather than 20. Rather than have
+ every site change its interface to the user, it was suggested
+ that there be a Network Common Command Language Protocol which
+ is translated to/from the host's own Executive command
+ language.
+
+ As with FTP and RJE, a human user should be able to type in CCL
+ Protocol directly, though many sites may want to allow a local
+ user to type in their local Executive language, and then they
+ will translate it into CCLP, for the foreign host.
+
+ Any Network Common Command Language should be compatible with
+ batch systems as well as with interactive systems, and should
+ provide an effective means for batch job submission and
+ control.
+
+ Bowles, Hathaway, and Stoughton volunteered to outline specs
+ for Network command language that would be compatible with
+ ideas suggested by Padlipsky and discussed at the meeting.
+
+ b. One of the functions to included in a Common Command Language
+ is a simple editor, which Padlipsky has outlined. The editor
+ should be easy for users to learn as well as for servers to
+ implement or interface to their own editors.
+
+
+
+
+
+
+
+
+Crocker, et al. Users [Page 4]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ 3. Status/Measurement of Site Performance
+
+ a. A variety of performance measures, for the individual sites,
+ needs to be derived, acquired, maintained, and made available
+ to users.
+
+ This could include some attempt to measure average "response
+ time", relative costs (relative to type of task, that is),
+ availability/reliability, etc.
+
+ b. Mechanisms are needed for software certification and for
+ measuring and verifying the accuracy and/or reliability of
+ systems, hardware, protocols, applications software, etc.
+
+ 4. User Feedback Mechanisms
+
+ a. There is a need for a uniform Network gripe/suggestion
+ mechanism. This should cover several types of gripes,
+ including program bugs and service complaints.
+
+ b. Each user registering a complaint deserves immediate
+ acknowledgement and some indication of what, if any, action
+ will be taken.
+
+ c. The NIC should set up Network ident groups for Principal
+ Investigators, Liaisons, Station Agents, Accounts
+ Administrators, Consultants, etc., so that users can easily
+ direct their comments, inquiries and mail to these groups.
+
+ d. A Network Servers Group should be started, to coordinate the
+ activities (to the extent possible) of the servers (a Server's
+ Cartel?). It would also provide a focus for user complaints
+ and suggestions.
+
+ (The group was originally dubbed the "Tobacco Institute". The
+ Tobacco Institute acts as a representative for the disparate
+ Tobacco companies, and attempts to convince the public that
+ smoking is good for them.)
+
+ The point of the Servers Group -- rather than trying to
+ convince the Network public that servers are good for them --
+ would be for servers to help each other with common tasks (such
+ as documentation) that are too big for each to handle alone.
+
+ This eventually works in the users interest, because the
+ servers (in the Network free-market economy) are dependent
+ upon the users for their livelihood.
+
+
+
+
+Crocker, et al. Users [Page 5]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ There should be cooperation between the Server Group and USING,
+ but the groups would NOT be comprised of the same people. They
+ are on opposite sides of the product.
+
+ e. Station Agents should supply users with information of a
+ clerical nature such as names, phone numbers, titles,
+ documentations, etc. To be able to do this, the Agents must
+ first HAVE this information.
+
+ 5. Messages to Users
+
+ a. Messages to users, such as error messages or diagnostics,
+ should be simple, clear, and meaningful to users.
+
+ b. The user should have the ability to control notifications given
+ to him, by being able to queue messages or refuse them.
+
+ c. Users should be able to suppress diagnostics or to specify
+ abbreviated or expanded versions.
+
+ 6. Tailoring of Resources for Users
+
+ a. Interfaces to users should support different levels of user
+ proficiency, without being a burden to the more proficient
+ user.
+
+ That is, a new user needs more prompting, etc. A more
+ experienced user does not need and DOES NOT WANT such
+ prompting. So the capabilities of the interface, which are not
+ needed by a specific user, should be transparent.
+
+ b. A method for work flow management that permits a user to set up
+ a sequence of computer tasks that are contingent upon one
+ another is needed. The user should be able to describe this
+ sequence interactively and then be able to detach and continue
+ with other work while the sequence of tasks is being carried
+ out.
+
+ 7. Personal Information Management System
+
+ a. Users need a system for managing all types of machine-based
+ contacts such as mail, links, journal items, etc.
+
+ Such a system should `log' what has been received and allow the
+ user to keep a copy, if desired.
+
+ It should also provide the user with options for organizing his
+ personal information.
+
+
+
+Crocker, et al. Users [Page 6]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ b. A personal `calendar' or reminder system would be handy,
+ especially if it allowed one to look ahead to coming events as
+ well as to check events for the current day or week.
+
+ c. A `return to sender' feature is needed in the Network-wide mail
+ address system.
+
+ d. (Discussion of the current work on the Mail Protocol indicated
+ that some of these ideas are already being considered)
+
+ 8. Uniform Accounting Procedures and Online Status of Accounts
+
+ a. This topic was covered in detail by sections of the Resource
+ Sharing Workshop. It is mentioned here only because it is a
+ problem of real concern to users.
+
+ 9. Trial Usage and Browsing
+
+ a. Ideally, users should be allowed some `free' sampling of
+ systems and features available at each site. Practically, this
+ presents problems of space allocation, accounting, consulting,
+ etc. Although none of these problems are easy to solve
+ equitably, an attempt should still be made to provide some free
+ usage to everyone.
+ b. Several types of trial usage should be considered, such as for
+ those who will make an immediate commitment and those who wish
+ merely to sample, without making any commitment.
+
+ 10. Prelogon Facilities
+
+ a. Some facilities should be available as prelogon facilities, so
+ that any user can access them whether or not he has an account,
+ directory, etc., at a given site. Some sites will not be able
+ to support many of these functions, so a required set must be
+ kept to a minimum.
+
+ 11. Remote User Facilitation
+
+ a. Users not only need help with actual use of systems from a
+ remote site, but they also need facilitation of administrative
+ tasks. Station Agents should be able to handle most of these
+ problems or transfer the user to the proper person. System
+ access requirements, account and billing problems, and document
+ acquisition need particular attention.
+
+
+
+
+
+
+
+Crocker, et al. Users [Page 7]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ b. There should be a simple mechanism for users to acquire/update
+ information in functional documents such as the Resource Note-
+ book and in files such as identification files. Publications
+ or files of this sort should combine the collective input of
+ all the users.
+
+ 12. Transportability of Resources and Information
+
+ a. Users should be able to easily transfer information, such as
+ files, memos, mail, online documentation, (programs?!?) etc.,
+ from one site to another.
+
+ 13. Network Utilities
+
+ a. Should distributed data banks and similar features be
+ considered Network utilities that can be used by all?
+
+ The idea of "Network Utilities" was recognized as an
+ interesting one by the group, but there was little agreement as
+ to what constitutes Network utilities or how they should be
+ supported.
+
+CURRENT PLANS
+
+ 1. Neigus, Crocker, and Iseli will draft the scope, objectives,
+ goals, and priorities of USING and will submit their
+ recommendations for approval by the members.
+
+ 2. MITRE will design a New User's Packet incorporating ideas from
+ USING.
+
+ 3. Bowles, Hathaway, and Stoughton will write preliminary specs for a
+ Network Common Command Language Protocol. All members should
+ suggest a list of commands for consideration.
+
+ 4. Padlipsky will produce specifications for a simple, standard
+ editor (NETED) which could easily be implemented by server hosts.
+
+ 5. A general Users Group (NIC ident = USERS) will be formed, to allow
+ any interested person to monitor user-oriented activities,
+ especially those of USING. Anyone interested in being in USERS
+ should contact Dave Crocker (DHC).
+
+
+
+
+
+
+
+
+
+Crocker, et al. Users [Page 8]
+
+RFC 585 USING Working Group Meeting November 1973
+
+
+ 6. Activities of the group will be reported in the ARPAnet News, and
+ a user's forum column will be made available for user's comments.
+
+ 7. The group will meet again in the Fall of 1973 at the Network
+ Information Center in Menlo Park, California.
+
+
+ [ This RFC was put into machine readable form for entry ]
+ [ into the online RFC archives by Via Genie 3/00 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crocker, et al. Users [Page 9]
+