Movatterモバイル変換

Network Working Group                                  M.A. PadlipskyRequest for Comments # 451                             MIT-MulticsNIC # 14135                                            February 22, 1973Tentative Proposal for a Unified User Level ProtocolNow that proposals for expansions to the Telnet Protocol are in vogueagain (RFC's 426 and 435, for example), I'd like to promote somediscussion of a particular favorite of my own.  Please note that this ispresented as a tentative proposal: it's an attempt to consider thedesirability of a new approach, not a rigorous specification.  To beginsomewhat obliquely, for some time I've felt that we (the NWG) havefallen into a trap in regard to the Initial Connection Protocol.  Thepoint is that even though the ICP gives us the ability to define a"family" of ICPlets by varying the contact socket, there's no compellingreason why we should do so.  That we have done so in the FTP and RJEP Iview as unfortunate--but also undesirable and unnecessary.To take the "undesirable" aspects first, consider the following: If wecontinue 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 foreach new protocol.  By Occam's Razor (or the principle of economy ofmechanism, if you prefer), this is a bad thing.  Irrespective of therelative difficulty of implementing such mechanisms on the variousHosts, to implement them at all leads to a kind of conceptual clutter.Further, a different kind of confusion is introduced by the notion whichsome of our number seem to be entertaining, that the "later" user levelprotocols such as FTP are somehow still another level of abstraction upfrom Telnet.  So it seems to me that we could spare ourselves a lot ofbother, both practical and theoretical, if we could avoid spawningcontact sockets needlessly.Turning to the "unnecessary" aspects, I think that even if the caseagainst the current approach isn't completely convincing the case for aparticular alternative might be.  So to show that the multiple contactsocket ICP is unnecessary, I'll try to show that what I call the"unified user level protocol" (UULP) is better.  The first thing tonotice is that all the "later" protocols "speak Telnet".  This issensible: 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, arereally just ways of letting a user say to a Server "I don't know whatyou 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 myoutput through the Network Virtual Graphics Terminal module) for me now,Padlipsky                                                       [Page 1]

RFC 451           Unified User Level Protocol Proposal     February 1973why not simply put hooks in Telnet to indicate that a Network GenericFunction is wanted instead of a Host-specific one at a given point intime?  Then everybody can come in through Telnet in ways that arealready known (and usually debugged and optimized) and fan out to otherservices through a single mechanism, where that single mechanism can bewhatever is most appropriate to a particular Host.  This view has theadditional virtue of keeping the Host "Answering Service"-equivalentprocesses out of the act when new protocols come along -- where byAnswering Service, I mean that process which manages logins in generalfor a given Host.  This process is, of course, a particularly sensitiveone on those systems which worry about accounting and security.That's all probably a bit vague.  Perhaps some idea of how I think theUULP would work will cast some light on what I think it is.  What'sneeded is a way of letting the Server know that it's being given ageneric command (I decline to call it a Network Virtual command, but I'mafraid that might be what I mean) like "STOR" or "RETR" rather than alocal command like "who" or "sys".  What could be simpler than defininga Telnet Control Code (TCC) for "Network Generic Function Follows"?  Soif the Server Telnet receives a command line beginning with the NGF TCC(say, 277 octal), it just feeds the line to the appropriate process orprocedure (depending on the structure of its operating system).  Thisapproach also offers a handy way of communicating back the fact that aparticular protocol or piece thereof isn't available: define a TCC for"Unimplemented Generic Function".  This feels a lot cleaner than havinga 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 suchobjections as the one Braden raises inRFC 430, that "there is nomechanism within the FTP for _changing_ a password.  A user shouldn'thave to use a different protocol ... to merely change his password".With the UULP, any system which has a password changing ability wouldhave it available for all user level protocols because all of itsabilities are made available by the generic login.  This seems clearlysuperior to having to retrofit afterthought after afterthought to thevarious user level protocols as we come to realize that life is moreconvenient when we get away from the view that each protocol lives inits own island universe.  I understand that one of the main motivationsfor going the multiple contact socket route was to avoid syntactic (andsemantic) conflicts between the protocol and the particular Host's"normal" command processor; however, locking ourselves in to specialcommand processors exclusively is awfully procrustean.  So instead ofcutting off the limbs to fit the bed, why not use the UULP to expand thebed.Padlipsky                                                       [Page 2]

RFC 451           Unified User Level Protocol Proposal     February 1973Although this is a tentative proposal and not meant to be a detaileddesign spec, one elaboration suggests itself which might make thegeneral idea more attractive: For ease of implementation on somesystems, 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 sendingthe "Begin FTP" Telnet Control Code, waits for the Server to send eitherthe same code or the one for "Unimplemented Generic Function", and thenproceeds (or not) to send STOR's and RETR's and the like.  (It couldalso follow the "I will"/"I won't" style discipline ofRFC 435 if welike.) Probably each line is preceded by the Network Generic FunctionTCC so that systems which don't pass input off to some other process canstill distinguish between input to the system command processor andinput 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 methat the unified user level protocol I've sketched here ought to be noharder to implement than the multiple contact socket (MCS) ICP is.  Andthe advantages of the UULP over the MCS ICP in terms of ease ofextension and (at least in my mind, if not in this paper) clarity makeit seem worthwhile to consider further.  So rather than try to refine ithere, let me simply ask for comments both on the general notion and onthe necessary iteration of the design from sketch to spec.  (The Multicsscenario in ICCC booklet shows how to get "mail" to me, for those whodon'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]