Single access to standard protocols
One login for all network services instead of a separate entry point for each.
Owen, A.D., "Single access to standard protocols", RFC 552, DOI 10.17487/RFC0552, July 1973, <https://www.rfc-editor.org/info/rfc552>.
@misc{rfc552,
series = {Request for Comments},
number = 552,
howpublished = {RFC 552},
publisher = {RFC Editor},
doi = {10.17487/RFC0552},
url = {https://www.rfc-editor.org/info/rfc552},
author = {A.D. Owen},
title = {{Single access to standard protocols}},
pagetotal = 1,
year = 1973,
month = jul,
} RFC text
Network Working Group Buz Owen
RFC # 552 SDAC-TIP
NIC # 17809 13 July, 1973
Single access to Standard Protocols
Isn't the idea of a single access protocol simple enough that one could
be specified, and a socket reserved for it, before the proposed mail
protocol becomes official? The result would be that MP could be the
first protocol implemented under UULP (or whatever it is to be called),
and the other protocols could be "moved" as soon as any problems in the
official specifications could be worked out, and at the convenience of
implementors.
The single access protocol might have the following commands:
USER
PASS
ACCT
MAIL
FTP
RJS
DRS (?)
HELP (?)
BYE
following Jim White's idea of nested command and reply spaces.
This doesn't address the question of "what is free", or of the
interrelationships between the various protocols, but it doesn't make
those problem any worse, only a little different.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with ]
[ support from GTE, formerly BBN Corp. 10/99 ]
AI ELI5
On this page
§1Too Many Front Doors
Network protocols in 1973 each required separate connection and login: FTP had one entry point, mail had another, remote job submission (RJS) had its own. Users had to authenticate separately at each protocol, learning different command sets and behavior.
The author asks: why not specify a single access protocol with one reserved socket before the mail protocol becomes official? This unified entry point could be simple and flexible enough that protocols could be moved to it at the convenience of their implementors.
You have to log in to mail, then log in to file transfer, then log in to job submission. Why not one login that lets you pick what you want?
§2The Unified Protocol Structure
The proposal outlines commands for this unified access layer: USER, PASS, and ACCT would handle authentication. MAIL, FTP, RJS, and DRS would select the service. A HELP command and BYE to disconnect round out the set.
The commands would nest following a model of command and reply spaces (referenced from Jim White's earlier work). This approach does not address what resources are free to use or how protocols interrelate, but it does not worsen those problems—it just structures them differently.
Say USER and your name, PASS and your password, then pick MAIL or FTP or another service from a menu. The nested commands let each service have its own sub-commands underneath.
§3Benefits of Unified Access
A single reserved socket for all standard protocols would simplify user experience. Instead of learning separate login procedures for mail, FTP, and other services, users would authenticate once and then select their service. This is simple enough to specify and implement before the proposed mail protocol becomes official.
The proposal suggests that the new mail protocol could be the first to use this unified access framework, with other protocols moved over as their specifications stabilize and implementors are ready.
One login for mail, one for FTP, one for remote jobs—it is confusing. One login that lets you pick which service keeps things simple.