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/rfc585.txt | 507 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc585.txt (limited to 'doc/rfc/rfc585.txt') 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] + -- cgit v1.2.3