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/rfc451.txt | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 171 insertions(+) create mode 100644 doc/rfc/rfc451.txt (limited to 'doc/rfc/rfc451.txt') diff --git a/doc/rfc/rfc451.txt b/doc/rfc/rfc451.txt new file mode 100644 index 0000000..78172b1 --- /dev/null +++ b/doc/rfc/rfc451.txt @@ -0,0 +1,171 @@ + + + + + + +Network Working Group M.A. Padlipsky +Request for Comments # 451 MIT-Multics +NIC # 14135 February 22, 1973 + + + Tentative Proposal for a Unified User Level Protocol + + +Now that proposals for expansions to the Telnet Protocol are in vogue +again (RFC's 426 and 435, for example), I'd like to promote some +discussion of a particular favorite of my own. Please note that this is +presented as a tentative proposal: it's an attempt to consider the +desirability of a new approach, not a rigorous specification. To begin +somewhat obliquely, for some time I've felt that we (the NWG) have +fallen into a trap in regard to the Initial Connection Protocol. The +point is that even though the ICP gives us the ability to define a +"family" of ICPlets by varying the contact socket, there's no compelling +reason why we should do so. That we have done so in the FTP and RJEP I +view as unfortunate--but also undesirable and unnecessary. + +To take the "undesirable" aspects first, consider the following: If we +continue to define a new contact socket for every new "user level" +protocol we come up with, we'll continue to need another new mechanism +(process, procedure, or patch) to respond to requests for connection for +each new protocol. By Occam's Razor (or the principle of economy of +mechanism, if you prefer), this is a bad thing. Irrespective of the +relative difficulty of implementing such mechanisms on the various +Hosts, to implement them at all leads to a kind of conceptual clutter. +Further, a different kind of confusion is introduced by the notion which +some of our number seem to be entertaining, that the "later" user level +protocols such as FTP are somehow still another level of abstraction up +from Telnet. So it seems to me that we could spare ourselves a lot of +bother, both practical and theoretical, if we could avoid spawning +contact sockets needlessly. + +Turning to the "unnecessary" aspects, I think that even if the case +against the current approach isn't completely convincing the case for a +particular alternative might be. So to show that the multiple contact +socket ICP is unnecessary, I'll try to show that what I call the +"unified user level protocol" (UULP) is better. The first thing to +notice is that all the "later" protocols "speak Telnet". This is +sensible: Telnet works, by and large. Why not make use of it? Right. +But why not make even more use of it? In view of the fact that FTP, +RJEP, and even the initiating part of the Network Graphics Protocol, are +really just ways of letting a user say to 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, + + + +Padlipsky [Page 1] + +RFC 451 Unified User Level Protocol Proposal February 1973 + + +why not simply put hooks in Telnet to indicate 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, where that single mechanism can be +whatever is most appropriate to a particular Host. This view has the +additional virtue of keeping the Host "Answering Service"-equivalent +processes out of the act when new protocols come along -- where by +Answering Service, I mean that process which manages logins in general +for a given Host. This process is, of course, a particularly sensitive +one on those systems which worry about accounting and security. + +That's all probably a bit vague. Perhaps some idea of how I think the +UULP would work will cast some light on what I think it is. What's +needed is a way of letting the Server know that it's being given a +generic command (I decline to call it a Network Virtual command, but I'm +afraid that might be what I mean) 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 +approach also offers a handy way of communicating back the fact that a +particular protocol or piece thereof isn't available: define a TCC for +"Unimplemented Generic Function". This 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 provides the answer to such +objections as the one Braden raises in RFC 430, that "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 which has a password changing ability would +have it available for all user level protocols because all of its +abilities are made available by the generic login. This seems clearly +superior to having to retrofit afterthought after afterthought to the +various user level protocols as we come to realize that life is more +convenient when we get away from the view that each protocol lives in +its own island universe. I understand that one of the main motivations +for going the multiple contact socket route was to avoid syntactic (and +semantic) conflicts between the protocol and the particular Host's +"normal" command processor; however, locking ourselves in to 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. + + + + + + +Padlipsky [Page 2] + +RFC 451 Unified User Level Protocol Proposal February 1973 + + +Although this is a tentative proposal and not meant to be a detailed +design spec, one elaboration suggests itself which might make the +general idea more attractive: For ease of implementation on some +systems, it would probably be a good idea to define additional TCC's for +"Begin User Protocol". That is, the user side starts the 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 STOR's and RETR's 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 that systems which don't pass input off to some other process can +still distinguish between input to the system command processor and +input to the procedure(s) which perform(s) the protocol in question, +although perhaps it would be preferable to have an "End Protocol" TCC. + +Now, I'm the first to admit that what makes sense to me, on my system, +may not make sense on somebody else's. But it does seem plausible to me +that the unified user level protocol I've sketched here ought to be no +harder to implement than the multiple contact socket (MCS) ICP is. And +the advantages of the UULP over the MCS ICP in terms of ease of +extension and (at least in my mind, if not in this paper) clarity make +it seem worthwhile to consider further. So rather than try to refine it +here, let me simply ask 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 me, 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 ] + + + + + + + + + + + + +Padlipsky [Page 3] + -- cgit v1.2.3