RFC 451

Tentative Proposal for a Unified User Level Protocol ✨

okay bestie, this one is RFC 451 🦋 from the NWG (Network Working Group), written by M.A. Padlipsky at MIT-Multics and dated February 22, 1973. It's NIC # 14135. The header doesn't list a category, and it doesn't obsolete or update anything. It's a tentative proposal, so it's not a full spec, just an idea to think about 💜

Now that proposals to expand the Telnet Protocol are back in vogue (RFCs 426 and 435, for example), Padlipsky wants to talk about one of his favorites 🫶 He's clear that it's an attempt to consider a new approach, not a rigorous specification. To start somewhat obliquely, he's felt for a while that the NWG has fallen into a trap with the Initial Connection Protocol (ICP) 😭 The ICP lets you define a "family" of ICPlets by varying the contact socket, but there's no compelling reason to do that. He sees the choice made for FTP and RJEP as unfortunate, and also undesirable and unnecessary 💅

Let's do the "undesirable" part first. If we keep defining a new contact socket for every new user level protocol, we'll keep needing another new mechanism (process, procedure, or patch) to answer connection requests for each one. By Occam's Razor (or the principle of economy of mechanism, if you prefer), that's a bad thing 🙈 Even if these mechanisms are hard or easy to build on different Hosts, having them at all creates conceptual clutter. There's also a different kind of confusion from the idea some of us seem to be entertaining, that later user level protocols like FTP are somehow yet another level of abstraction up from Telnet. So we could save ourselves a lot of practical and theoretical bother if we stopped spawning contact sockets needlessly ✨

Now the "unnecessary" part. Even if the case against the current approach isn't totally convincing, the case for a particular alternative might be 👑 To show that the multiple contact socket ICP is unnecessary, he tries to show that what he calls the "unified user level protocol" (UULP) is better. First, notice that all the "later" protocols "speak Telnet" 🌸 That's sensible, because Telnet works, by and large. So why not use it? Right. But why not use it even more? FTP, RJEP, and even the initiating part of the Network Graphics Protocol are really just ways for a user to tell a Server "I don't know what you call it on your system, but please perform the whatever function (push or pull a file, start or stop a batch job, funnel some of my output through the Network Virtual Graphics Terminal module) for me now." So why not put hooks in Telnet to show that a Network Generic Function is wanted instead of a Host-specific one at a given point in time? 🧚 Then everybody can come in through Telnet in ways that are already known (and usually debugged and optimized), and fan out to other services through a single mechanism, which can be whatever is most appropriate to a particular Host. This also keeps the Host "Answering Service"-equivalent processes out of the act when new protocols come along. By Answering Service, he means the process that manages logins in general for a given Host, and it's especially sensitive on systems that worry about accounting and security 🔥

That's probably a bit vague, so maybe an idea of how the UULP would work will shed some light 💖 What's needed is a way to let the Server know it's being given a generic command (he declines to call it a Network Virtual command, but he's afraid that might be what he means) like STOR or RETR, rather than a local command like who or sys 🎀 What could be simpler than defining a Telnet Control Code (TCC) for "Network Generic Function Follows"? So if the Server Telnet receives a command line beginning with the NGF TCC (say, 277 octal), it just feeds the line to the appropriate process or procedure, depending on the structure of its operating system ✨ This also gives a handy way to communicate that a particular protocol or piece of one isn't available: define a TCC for "Unimplemented Generic Function". That feels a lot cleaner than having a close on socket 3 mean anything from "no FTP Server exists here" to "the FTP Server happens to be busy" 💅

Notice that the UULP automatically answers objections like the one Braden raises in RFC 430: "there is no mechanism within the FTP for _changing_ a password. A user shouldn't have to use a different protocol ... to merely change his password" 🙈 With the UULP, any system that can change passwords would have that ability available for all user level protocols, because all of its abilities are made available by the generic login. This seems clearly superior to retrofitting afterthought after afterthought onto the various user level protocols as we realize that life is more convenient when we stop treating each protocol like its own island universe 🌈 He understands that one main motivation for the multiple contact socket route was to avoid syntactic (and semantic) conflicts between the protocol and the Host's "normal" command processor. But locking ourselves into special command processors exclusively is awfully procrustean 😭 So instead of cutting off the limbs to fit the bed, why not use the UULP to expand the bed? 🛏️✨

Though this is tentative and not meant to be a detailed design spec, there's one elaboration that might make the general idea more attractive 🍓 For ease of implementation on some systems, it would probably be a good idea to define additional TCCs for "Begin User Protocol". So the user side starts FTP by sending the "Begin FTP" Telnet Control Code, waits for the Server to send either the same code or the one for "Unimplemented Generic Function", and then proceeds (or not) to send STORs and RETRs and the like. (It could also follow the "I will"/"I won't" style discipline of RFC 435 if we like.) Probably each line is preceded by the Network Generic Function TCC, so systems that don't pass input off to some other process can still tell input meant for the system command processor apart from input meant for the procedure(s) that perform the protocol in question. Perhaps it would be preferable to have an "End Protocol" TCC, though 🦋

Now, he's the first to admit that what makes sense to him, on his system, may not make sense on somebody else's 🫶 But it does seem plausible to him that the UULP he's sketched here ought to be no harder to implement than the multiple contact socket (MCS) ICP. And the advantages of the UULP over the MCS ICP, in terms of ease of extension and (at least in his mind, if not in this paper) clarity, make it seem worth considering further 👑 So rather than trying to refine it here, he simply asks for comments both on the general notion and on the necessary iteration of the design from sketch to spec. (The Multics scenario in ICCC booklet shows how to get "mail" to him, for those who don't feel like RFCing or phoning 📬💜)

       [ 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.             9/99 ]