Specification of the Unified User-Level Protocol
RFC 666

Document Type RFC - Unknown (November 1974; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text html pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 666 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       M. Padlipsky
Request for Comment: 666                                26 November 1974
NIC: 31396

            Specification of the Unified User-Level Protocol

   After many discussions of my RFC 451, I discovered that the "Unified
   User-Level Protocol" proposed therein had evolved into what had
   always been its underlying motivation, a common command language.
   There are several reasons why this latter approach satisfies the
   original goals of the UULP and goes beyond them into even more useful

   1. User convenience.  As evidenced by the good response to the common
   editor "neted", the Network Working Group has come to acknowledge the
   fact that the convenience of non-system programmer users of the
   Network must be served.  Allowing users to invoke the same generic
   functions -- including "batch" jobs -- irrespective of which Server
   Host they happen to be using is surely a compelling initial
   justification for a common command language.  Note that the concern
   with generic functions -- which "all" Servers do, one way or another
   -- is intended to emphasize the common command subset aspects of the
   language, rather than the "linguistic" elegance of it all.  The
   attempt is to specify an easy way of getting many things done, not a
   complicated way of getting "everything" done.

   2. "Resource sharing".  Another area which is receiving attention in
   the NWG of late is that of "automatic" or program-driven invocation
   of resources on foreign systems.  A common intermediate
   representation of some sort is clearly necessary to perform such
   functions if we are to avoid the old "n by m problem" of the Telnet
   Protocol -- in this case, n Hosts would otherwise have to keep track
   of m command languages.  For the common intermediate representation
   to be human-usable seems to kill two birds with one stone, as
   expanded upon in the next point.

   3. Economy of mechanism.  In RFC 451, I advanced the claim that a
   single user-level protocol which connected via socket 1 and Telnet
   would offer economy of mechanism in that new responders would not be
   required to service Initial Connection Protocols on socket after
   socket as protocol after protocol evolved.  This consideration still
   applies, but an even greater economy is visible when we consider the
   context of resource sharing.  For if the common command language is
   designed for direct employment by users, as the present proposal is,
   there is no need for users on terminal support "mini-Hosts" (e.g.,
   ANTS and TIPs) to require an intermediary server when all they
   actually want is to work on a particular Server in the common

Padlipsky                                                       [Page 1]
RFC 666               Unified User-Level Protocol          November 1974

   language.  (This is especially true in light of the fact that many
   such users are not professional programmers -- and are familiar with
   no command language.)  That is, if resource sharing is achieved by an
   intermediate language which is only suitable for programs, you would
   have to learn the native command language of Server B if you didn't
   want to incur the expense of using Server A only to get at generic
   functions on Server B.  (And you might still have to learn the native
   language of Server A, even if the expense of using two Servers where
   one would do isn't a factor.)

   4. Front-ending.  Another benefit of the common command language
   proposed here is that it is by and large intended to lend itself to
   implementation by front-ending onto existing commands.  Thus, the
   unpleasant necessity of throwing out existing implementations is
   minimized.  Indeed, the approach taken is a conscious effort to come
   up with a common command language by addition to "native" command
   languages rather than by replacement, for the compelling reason that
   it would be unworkable as well as ill-advised to attempt to legislate
   the richness represented by existing command languages out of
   existence.  Further, as it is a closed environment, no naming
   conflicts with native commands would arise.

   5. Accounting and authentication.  As evidenced by the spate of RFCs
   about the implications of the FTP in regard to both accounting for
   use of Network services and authenticating users' identifications
   (Bressler's RFC 487, Pogran's RFC 501, and my RFC 505 -- and even
   491), this area is still up in the air.  The generic login command
   proposed here should help matters, as it allows the Server to
   associate an appropriate process with the connection while actuating
   appropriate accounting and access control as well, if it chooses.

   6. Process-process functions.  By enabling the invocation of foreign
   object programs, the present proposal offers a rubric in which such
   process-to-process functions as "parallelism" can be performed.  (See
Show full document text