Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


Network Working Group D. Crocker Request for Comments: 585 UCLA-NMC Category: Users N. Neigus NIC: 18259 BBN-NET

                                                            J. Feinler
                                                              J. Iseli
            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.


 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.


    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


 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
    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
    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

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
       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
       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
       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
       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
 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


 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
 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc585.txt · Last modified: 2000/12/05 20:31 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki