RFC 451 (rfc451) - Page 2 of 3

Tentative proposal for a Unified User Level Protocol

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