RFC 364

Serving remote users on the ARPANET

πŸ“… published July 1972, from ietf

RFC 364: Serving Remote Users on the ARPANET πŸŽ€ Network Working Group, Marshall D. Abrams, National Bureau of Standards πŸ›οΈ NIC 10606, July 11, 1972 πŸ“… References: NIC 6801 πŸ“š This copy doesn't list a category, and it doesn't say what it obsoletes or updates. πŸ€·β€β™€οΈ


Problem Statement

okay so bestie, second only to the host being down πŸ’€, the most annoying thing when you try to use the service hosts on the NET is that the admin procedures and info sharing are just not it for remote users 😭. This paper breaks down the problem and suggests fixes 🫢.

When computer systems start serving remote users, the procedures that made everything work for local users might not be good enough for people who are off-site 🌸. Maybe those procedures were already kinda bad, but the local crew made up informal procedures to fill the gaps πŸ™ˆ. Or maybe the formal ones were totally fine for locals and just fell apart when you tried to extend them to remote users πŸ’”. Either way, this paper says there's a problem and offers some suggestions to make it better ✨.


Existing Information

I've tried to use the info that's already out there, so first I'll go through the existing sources and explain why they don't cover everything we need 🧐.

There's the resource notebook index πŸ“–. It's an ordered list of attributes, and each one points you to the main entry for hosts that have that attribute πŸ—‚οΈ. Once the index is complete, it will point to the main entries in the resource notebook, which is what we're looking at next πŸ‘€. Honestly, the main entry is a summary of the hardware and software services available πŸ’». At this site, these entries work like a "shopping list," so you can pick the service center hosts that might work for the computing you want to do πŸ›’. You also get some admin info. Using the outline of a host-site subsection, that info covers: I. Personnel; V.B. Rate structure; V.D. Long-term storage; VII. Login; VIII. Operator Communication; IX. Miscellaneous; and X. Programs πŸ“‹. The "IX. Miscellaneous" section says they plan to add a detailed documentation section in a future revision of the resource book, and that is super urgently needed 🚨. This paper includes a proposal that could be the outline for that section πŸ¦‹.

The NIC is another source of info about serving hosts 🌐. Some sites have sent their existing documentation to the NIC, and some have even written special documents to help network users πŸ™Œ. There are a few problems though 😬. It can be hard to find out these documents exist, especially if you're new to the ARPANET or the NIC 🫠. And NIC policy is to lend the documents out, which is fine for browsing but NOT okay for reference πŸ’….


Information Required

Here's a questionnaire-style format with extra outline entries that could be used to supplement NIC 6801 πŸ“.

XI. Administrative Procedures relating to Financial Arrangements

  • Who does a prospective user contact?
  • Is there a way to sample using the system (gratis)?
  • How does one open an account for computer services?
  • How does one obtain the necessary blank administrative forms?
  • Can all expenses (e.g., manuals, postage) be charged to the computer services account?
  • How does one determine the status of his account?
  • What is the relationship of a number of users to accounts?
  • How can one determine the charges accruing during a session?
  • How often are account statements issued?
  • How current are account statements when issued?

XII. Information Dissemination

A. Documentation

  • Is there a "beginners pocket"? Does it contain examples?
  • Is there a list of documents available? Where? Where are published documents sold?
  • How does the remote user obtain these documents?
  • May document purchases be charged to the account?
  • How are errata sheets distributed?
  • How often are manuals updated? How are updates announced?
  • What local documentation is available/necessary?
  • What manufacturer hardware/software documentation is available/necessary?
  • Is manufacturer documentation available from the same source as local documentation and with the same arrangements?
  • What is the mechanism for resolution of conflicts amongst manuals?
  • Is documentation available for each subsystem and application program?
  • Is there a printed newsletter or equivalent? If so, what is the procedure for becoming a subscriber? For obtaining back issues?
  • Is there a "message of the day" automatically presented?
  • How does an irregular user keep informed of past "messages of the day"?
  • Is there an on-line information service like a newspaper? How does one obtain "back issues" of the "newspaper"?

B. User Assistance

  • Is there a (required) single point of contact for remote users?
  • What is his level of technical competence?
  • What is his level of administrative responsibility?
  • When the contact person cannot answer a question, will he follow it up with the appropriate in-house person? Will the remote user be referred to the in-house person? To what extent will a remote user be permitted or denied access to technical and administrative staff?
  • What priority does the local user have relative to the remote user?
  • Is there a telephone service for answering questions?
  • Is INWATS or equivalent provided?
  • What are the service hours?
  • Is there an on-line assistance mechanism? How does it work?
  • Is there a mechanism for sending messages to an off-line user consultant?

C. Technical Capabilities and Requirements

  • Is there an index of system capabilities?

1. Communications

  • How do you log in (or whatever it is called)?
  • What device assumptions are made concerning lines per page, columns per line, (separate) line feed, (separate) carriage return, (combined) carriage return line feed, horizontal tab, vertical tab, form feed, and back space?
  • Have any of the non-printing ASCII characters been assigned non-standard functions?

2. Command language

  • What is the minimum set of control statements required?
  • Where are the control statements documented?
  • What are the installation defaults on control statements?

3. File System and Editor(s)

  • What are the attributes of the file system? Describe the naming conventions of the defaults.
  • How is a set, subset, and superset of "files" defined, related and named?
  • What is the minimum information about the file system that is required in order to use the editor(s) and language processors?
  • Are names divided into adjectival qualifiers? What are these called? Are there restrictions? Defaults?
  • Describe the editor(s) characteristics. What documentation is available?
  • Are there in-line editing features (e.g., erase immediately preceding character, erase entire line)? Describe.

4. Languages

  • What language processors are available?
  • How are the processors implemented (e.g., batch compiler, interpreter, incremental computer)? What difference does it make to the user?
  • What is the compatibility of your language dialect(s) with the standard and with other dialects?
  • To what extent can program units written in different languages communicate? Discuss data types, representations, and structures as well as subroutine linkage conventions.

XIII. Operations

  • What measures are in effect to preserve the security of one's files and accounts?
  • Can a remote user direct printing, punched cards, plotting, etc. to an on-site device? How does he get his output mailed to him?
  • What off-line secondary storage is available? How is it used? What does it cost?
  • How does the remote user request, renew, release, mount and demount tapes and disk packs?
  • What arrangements are there for mailing off-line storage media? Is the operating staff aware that there are remote users?
  • Are there services available to local users not available to remote users; and conversely?
  • Is there on-line file storage? What does it cost? What limits are imposed? How often is it backed-up?
  • Does the announced operating schedule consider users in different time zones?
  • Is the announced schedule closely followed?
  • How are remote users notified of changes in the schedule?

Implementation

A lot of the info suggested here would be useful for local users too 🏠. Some of it might already be in local docs πŸ“„. The point is that remote users usually can't easily find this stuff, especially when they're juggling several remote hosts 😩. Presenting the info in a standard outline format would be a huge service 🎁. I also get that writing this up could mean duplicating work, and you'd end up with two documents that both need updating whenever something changes πŸ™ƒ. One fix is to follow the outline when you put together a guide to the literature available from the host site πŸ“šβœ¨.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alan Ford 10/99 ]

πŸ“¦ where this page comes from