Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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
 the discussion of the "call" command, below.)  Note that the UULP is
 not being advanced as a panacea: It is assumed that the actual
 transactions carried out are most likely not going to be in the
 common command language (although some certainly could be); however,
 what is furnished is a known way of getting the presumably special-
 cased programs executing elsewhere.  Also, it offers a convenient
 environment into which can be placed such new functions, which we
 would like to have become generic, as Day's File Access Protocol.
 All of which seems to be a fair amount of mileage to get out of a
 distaste for remembering whether you find out who's logged in by
 saying "systat", "users", "s.who:c", "listf tty", or "who"....

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


 Although ultimately intended to become the general responder to the
 Initial Connection Protocol, the UULP is initially to be a Telnet
 Protocol "negotiated option".  When the option is enabled, the Server
 Host will furnish a command environment which supports the common
 conventions and commands discussed herein.
 In a sense, the UULP is a "selector".  That is, the common command
 subset includes commands to exit from the common command environment
 and enter various other environments, along the lines of CCN's
 current Telnet Server.  To exit from the UULP environment to the
 "native" command processor, the UULP command is "local" (see also the
 discussion of Case, below).  Note that all commands terminate in
 Telnet "Newline" (currently cr-lf), unless altered by the "eol"
 command (below); internal separator is space (blank).  (Entrance into
 other environments -- such as the FTP Server -- is discussed below.)
 There are two reasons for introducing a mechanism other than the
 apparently natural one of simply de-negotiating the option: First, it
 is bound to be more convenient for the user to type a command than to
 escape to his User Telnet program to cause the option disabling.
 Second, it is hoped that eventually the UULP will be legislated to be
 the default environment encountered by any Network login, in which
 case the natural way to enter the Server's "native" command
 environment would be by UULP command.
    Note: all UULP commands discussed herein are listed in Appendix 1,
    categorized as to optionality, with brief descriptions given.  The
    appendix may be taken as a first-pass UULP Users' Manual.


 Any optional commands which are not supported by a particular Server
 are to be responded to by a message of the form "Not implemented:
 commandname.", where the variable is the name of the command which
 was requested.  Note that throughout this document, all literals must
 be sent exactly as specified, so as to allow for the possibility of
 Servers' being driven by programs (including "automata" or "command
 macros") in addition to "live" users.
 In general, the view has been taken here that a small number of
 literal, constrained responses is superior to a vast variety of
 numerically coded responses in which text may vary.  Again, the
 motivation is to achieve an economy of mechanism.  For on the coded
 model, there must be a coordinator of code assignments, which is just
 as well avoided.  Further, as has been experienced in the use of the
 FTP, when there are many codes there are many ambiguities.  (The
 sender may have a perfectly valid case for choosing, say, 452, while

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

 the receiver may have an equally good interpretation of the codes'
 definitions for expecting, say, 453.)  Experience with a related
 "error table" mechanism on Multics also bears out the assertion that
 coded responses create both managerial and technical problems.  A
 final objection to numeric codes might be considered irrelevant by
 live some, but I think that the aesthetics of the situation do merit
 some attention.  And when the common command language is being
 employed by live users, it seems to me that they would only be
 distracted by all those numbers flying around.  (Nor can we assume
 that the numbers could be stripped by their "User UULP", for one of
 the basic goals here is to make it straightforward enough for a user
 at a TIP to deal with.)


 During the review process, it became evident that some global
 comments on arguments were in order.  Two areas in particular appear
 to have led to some confusion: the strategy of specification of
 arguments on the command line, and the question of "control
 arguments".  On the first score, the goal of "front-endability" must
 be recalled.  Consider two native implementations of a particular
 command, one of which (A) expects to collect its arguments by
 interrogation of the user, and the other of which (B) expects to
 receive them on invocation (being invoked as a closed subroutine).
 Now, it is easy to imagine that a "Server UULP" could feed the
 arguments to A as needed without requiring A to be rewritten, but it
 is quite difficult to see how B could be made to interrogate for
 arguments without extensive rewriting.  Therefore, a "least common
 denominator" approach of specifying arguments in advance incurs the
 minimum cost in terms of reworking existing implementations.
 On the second score, I have borrowed a notion from the Multics
 command language's convention called "control arguments" because it
 seems to be quite convenient in actual practice.  The key is that
 some arguments are meant as literals, usually specifying a mode or
 control function to the command, while others are variables,
 specifying something like a particular file name or user identifier.
 A common example is a "mail" command, where the variables are the
 user identifiers and the Host identifiers, and the "control argument"
 is the designator that user identifiers have ceased and Host
 identifiers have begun.  The convention used here is to begin the
 control argument with a hyphen, as this character never seems to be
 used to begin variable arguments.  Thus, we use "-at" in the mail
 example.  Although it is not a deep philosophical point, this
 approach does relieve argument lists of order-dependency, and feels
 right to me.

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


 Although it appears to have been legislated out of existence by the
 specification of the Network Virtual Terminal's keyboard in the
 Telnet Protocol, the question of what to do about users at upper-
 case-only terminals remains a thorny one in practice.  There are two
 aspects to consider: the alphabetic case of commands, and the ability
 to cause "case-mapping" in order to allow lower-case input.  Some
 Servers have no local problems with the first aspect, as they operate
 internally in all upper-case or all lower-case and merely map all
 input appropriately.  (Problems do arise, though, when one is using
 the User FTP on such a system to deal with a mixed-case system, for
 example.) Other Servers, however, attach the normal linguistic
 significance to case.  (E.g., Smith's name is "Smith" -- not "SMITH",
 and not "smith".)  To minimise superfluous processing for those
 Servers which are indifferent to case, all UULP commands are to be
 recognized as such whether they arrive as all upper-case or all
 lower-case.  (They will be shown here as all lower merely for typing
 convenience.) Note that arbitrarily mixed case is not recognized, as
 it is an unwarranted assumption about local implementation to suppose
 that input will necessarily be case-mapped.
 On the second aspect, any Server which does distinguish between
 upper- and lower-case in commands' arguments (a.k.a. parameters) must
 furnish a UULP "map" command as specified in Appendix 2 in order to
 support logins from upper-case-only terminals attached to User Hosts
 which either do not support the Telnet Protocol's dictum that all 128
 ASCII codes must be generable, or support it awkwardly.  This seems a
 simpler and preferable solution than the alternative of legislating
 that upper-case Network-wide personal identifiers (and perhaps even
 Network Virtual Path Names) be pre-conditions to a usable common
 command subset.  (As noted below, these latter concepts will fit in
 smoothly when they are agreed upon.  The point here, though, is that
 we need not deprive ourselves of the benefits of a UULP until they
 are agreed upon.)

User Names

 As implied above, the various Servers have their various ways of
 expressing users' names.  Clearly, the principle of economy of memory
 dictates that there should be a common intermediate representation of
 names in and for the Network.  It is probably also clear that this
 representation will be based upon the Network Information Center's
 "NIC ID's".  However, it is unfortunately amply clear than an
 acceptable mechanism for securing up-to-date information cannot be
 legislated here - much less a mechanism for securely updating the
 implied data base.  Therefore, at this stage it seems to be the

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

 sensible thing to specify only the UULP syntax for conveying to the
 Server the fact that it is to treat a user name as a Network-wide
 name rather than as a local name, and let the supporting mechanisms
 evolve as they may.
 The prefacing of a name with an asterisk ("*") denotes a Network-wide
 name.  (Such names may be either all upper-case or all lower-case, as
 with UULP commands' names.) The name "*free" is explicitly reserved
 to mean that (in the context of logging in) a login is desired on a
 supported or sampling account, if such an account is available.  The
 response if no such account is available is to be "Invalid ident:
 *free."  When Network-wide names are generally available Servers will
 either map them into local names or cause them to be registered as
 local names as they prefer.  The point is that a Network-wide name
 will be "made to work" by the Server in the context of the UULP.

Special Characters and Signals

 Another area in which the facts of life must outweigh the letter of
 the Telnet Protocol if the user's convenience is to be served is that
 of "erase" and "kill" characters.  It is possible that User Telnets
 will uniformly facilitate the transmission of the Telnet control
 codes for generic character erase and generic line kill.  It is
 certain, however, that User Telnets will differ -- and users will, if
 they use more than one User Telnet, be again placed in the
 uncomfortable position of having to develop too many sets of
 reflexes.  Therefore, the UULP will optionally support the following
 commands: "erase char" and "kill char", where char is a printable
 ASCII character (to avoid possible conflicts with "control
 characters" which are recognized in the innermost areas of particular
 operating systems).  Presumably, unwary users can be instructed not
 to choose an alphabetic, so as to avoid being placed in a position
 where they cannot invoke certain commands (erase and kill themselves,
 for example, in which case they couldn't be changed).
 These commands are supplements to the related Telnet control codes,
 and have the same meanings.  The point here is that it may be far
 more convenient for a user to be able to say "erase #" and get the
 "#" to be recognized as the erase character by the Server than for
 the user to get his User Telnet to send the Telnet equivalent.  The
 commands are designated as optional because they may lead to severe
 implementation problems on some Servers, and because the equivalent
 functions do, after all, exist in Telnet.
    Note: the erasing is assumed to be performed "as early as
    possible".  That is, the sequence "erase x" "erase x" should come
    out equivalent to "erase x" "erase" -- the second appearance of

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

    "x" resulting in the erasing of the space in the command line.
    Presumably, this is a sufficiently uncommon path that anomalous
    results would be tolerated by the user community, but the intent
    ought to be clear.
 The Telnet "synch" and "break" mechanisms are, by their very nature,
 best left to Telnet.  End of line, however, might well be a different
 story.  Therefore, as a potential convenience, the UULP optionally
 supports "eol char" to ask the Server to treat char as the end of
 line character thenceforth.  To revert to Telnet Newline, "eol"
 (i.e., no argument, current terminator).


 Another aspect in which Servers vary while being the same is how they
 indicate "being at command level".  Some output "ready messages";
 others, "prompt characters".  For the UULP, where some functions will
 be performed by means of a command's logging in to another system,
 the ability to specify a known prompt character is extremely
 desirable.  The UULP command is "prompt char" where char is the
 character which is to be sent when the user's process (on the Server)
 is at command level.  It is explicitly permitted to prefix char to a
 line consisting of a "native" prompt or ready message.  Also, this
 command is explicitly acknowledged to be permissible prior to login.
 (Again, warning must be made of the bad results which can ensue if an
 alphabetic character is chosen.)
    Note: "prompt", "eol", "erase", and "kill" may all be re-invoked
    with a new value of char in order to change the relevant setting;
    all may be turned off by invocation with no argument.


 Perhaps the stickiest wicket of them all is the attempt to specify a
 generic login, but here we go.  The UULP login command is "login
 userident", where userident is either a locally-acceptable user
 identifier or a Network-wide identifier as discussed above.  Note
 that for utility in contexts to be discussed later, the locally-
 acceptable form must not contain spaces.  Servers may respond to the
 login attempt with arbitrary text (such as a "message of the day"),
 but some line of the response must be one of the following: a prompt
 (as discussed above; indicating, in the present context, successful
 login); "Password:"; or "Invalid ident: userident."  When passwords
 are required, it is the Server's responsibility either to send a mask
 or to successfully negotiate the Hide Your Input option.

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

 Note that "login *free" is specifically defined to require no
 password.  (If a "freeloader" has access to a User Telnet and has
 learned of the "*free" syntax, it is fruitless to assume that he
 couldn't have also read the common password.) If a password must be
 given, acceptable responses are arbitrary text containing a line
 beginning either with a prompt or with "Login unsuccessful." or with
 "Account:".  If an account is requested, the responses must be either
 the "Login unsuccessful" message or the text containing a prompt
 already described.  If any errors occur during the login sequence,
 users are to re-try by starting from the login command.  (I.e., it is
 not required that the Server "remember" idents or passwords.)
 It is explicitly acknowledged that an acceptable response to "login
 *free" is "Limited access only." (followed by a prompt).  This is
 intended to warn (human) users that the free account on the Server in
 question exists only to allow such functions as accepting mail and
 telling if a particular user happens to be logged in.  (For
 objections to "loginless" performance of such tasks, see RFC 491.
 Note also that nothing here says that a Server must do anything other
 than return a prompt in response to "login *free" in the event that
 loginless operation is natural to it.)  Given the UULP login
 discipline and the "prompt" command, it is reasonably straightforward
 for a program to login on a free account and perform one of these
 functions, for if the login command succeeded, the program will "see"
 a guaranteed prompt character.
 To make life simpler for those Hosts which normally have some sort of
 "daemon" process service mail and the like, a further expansion to
 login is in order.  The point here is that some Hosts may not know
 what sort of process to pass an unqualified "login *free" to, whereas
 they'd be sure what to do with an explicit request to process mail,
 do a who command, or set up console to console communications.
 Therefore, UULP "login" will allow a "control argument" (as discussed
 above) of either "-mail", "-who", or "-concom", and the respective
 UULP commands involved must use the respective strings in any login
 line they transmit.  Again, nothing is being said about what a Server
 has to do with the information, but some Servers need/want it.

Usage Information

 Most Servers offer some sort of on-line documentation, from calling
 sequences of commands to entire users' manuals.  There are two sorts
 of information of interest in the UULP environment: "normal" system
 information, and information about the particular Server's UULP
 implementation.  To learn how to get descriptions of "native"
 commands, the UULP command is "help -sys" (abbreviation: "?").  Note
 that "-sys" is viewed as a "control argument" and as such prefaced by

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

 a hyphen ("-") to facilitate distinction from other sorts of name
 (e.g., command names).  To get a description of the Server's UULP
 implementation, "help -uulp".  To get a description of a particular
 UULP command's implementation, "help comname".  To be reminded of how
 to use the help command, "help".
    Note: as with command names and Network-wide user names, control
    arguments may be either all upper-case or all lower-case.
 It is specifically acknowledged that "No peculiarities." is an
 appropriate response to "help comname" if nothing of interest need be
 said about the Server's implementation of the UULP command in
 question.  (After all, we're sparing users the necessity of studying
 a dozen or so users' manuals; the least they can do is to read the
 UULP command list.)  Appropriate information for less taciturn Hosts
 to furnish would be such data as local command invoked (if such be
 the case), argument syntax (e.g., pathname description, or name of
 help file about pathnames), "To be implemented.", or even "Not to be


 Even though a separate mail protocol is being evolved for general
 purposes, the UULP needs to address this topic as, by virtue of being
 login based, it allows systems which do access control and sender
 authentication on mail to make these abilities available to users
 within its framework of generic functions.  Therefore, to read one's
 mailbox, the UULP command is "readmail".  To have "live" input
 collected and sent to a local user, "mail userident"; to a remote
 user, "mail userident -at hostname", where the arguments have the
 "obvious" meanings.  To send a previously-created file, "mail -f
 filename userident -at hostname".  Several useridents may be
 furnished; the delimiter is space (blank).  Similar considerations
 apply to hostnames.  If both are lists, they sould be treated
 pairwise.  (A more elaborate syntax could be invented to deal with
 the desire to send to several users at a given host and then to other
 users at other hosts, but it seems unnecessary to do so at this
 point, for multiple invocations would get the job done.)
 The mail command prefaces the message with a line identifying the
 sender (Host and time desirable, but not mandatory).  For "live"
 collection, the end of message is indicated by a line consisting of
 only a period (".") followed by the regnant line terminator (usually
 the Telnet Newline, but see also the discussion of the eol command).
 If remote mail is not successfully transmitted, it is to be saved in
 a local file and that file's name is to be output as part of the
 failure message.  ("Queueing" for later transmission is admired, but

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

 not required.) The transmission mechanism will follow the general
 mail protocol.  Note that when invoked with a "-at" clause, the mail
 command will send "login *free -mail" to the remote Host(s), followed
 by a mail command with no "-at" clause.
 A desirable, but not required, embellishment to "readmail" would be
 the accepting of a Host name ("-at hostname") to cause the local Host
 to go off to the named Host (via "login *free -mail") and check for
 mail there.  Several hostnames could, of course, be specified.  A
 further embellishment, which would probably be quite expensive, would
 be to accept "-all" as a request to check all Hosts (or, perhaps, all
 Hosts known to have a free account for the purpose) for mail.

Direct Communication

 The ability to exchange messages directly with other logged in users
 is apparently greatly prized by many users.  Therefore, despite the
 fact that there is a sense in which this function is not within the
 purview of the UULP, we will address it, after a digression.
    Digression: The UULP assumes that there can be straightforward
    "front ends" at the various Servers which translate generic
    function calls in a common spelling to calls for specific, pre-
    existing "native" functions.  In the area of console to console
    communications, however, this premise does not really hold.  The
    problem is that both major "native" implementations known to the
    author are seriously flawed.  The TENEX "link" mechanism is both
    insecure (you've got no business seeing everything I type even if
    I'm careless enough to let you) and inconvenient (why should I be
    forced to remember that pesky semi-colon?  how do I get back into
    phase after I've forgotten one?).  It is also likely to be
    extremely difficult to simulate on systems which do not force
    Network I/O through local TTY buffers, even if the user interface
    were not subject to criticism.  The Multics "send_message"
    mechanism, on the other hand, has a more sophisticated design, but
    is absurdly expensive.  Therefore, the UULP mechanism to be
    described assumes that, for this function, new local
    implementations will be developed to support it.
 To permit console to console communications: "concom -on"; to refuse,
 "concom -off".  Default is off.  To enter message-sending mode:
 "concom userident -at hostname" ("-at" clause is optional).  To exit
 from message-sending mode, type a line consisting of only a period
 (cf.  Mail, above).  While in message-sending mode, each line will be
 transmitted as a unit.  The first message sent by concom must be
 prefaced by an identifying line, beginning "From:" and containing an
 appropriate address to which to reply.  The closing period-only line

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

 should be transmitted, so as to allow the other concom to close as
 well.  Acceptable error response is "Not available: userident."
 (which neither confirms nor denies the existence of the particular
 user -- a matter of concern on the security front).  The command
 must, of course, do whatever is necessary to transmit the messages;
 i.e., if locally invoked, access the local mechanism, and if invoked
 for remote communications, access the remote Host's concom command
 (via "login *free -concom").  Thus, a user at a TIP would use the
 local form of concom on the Host of the other party if this is
 convenient, or would use the remote form on his "usual" Server if the
 direct use is inconvenient for some reason (such as having no account
 there, say).
 The prerequisites for establishing communications are to find out if
 the user is logged in, and what "address" to use if so.  The
 mechanism for gathering this information is an expanded "who"
 command.  (Note that "who" is the UULP command to invoke the generic
 who's logged in function, with no constraints on format of reply.)
 The syntax is "who userident -at hostname", where both arguments may
 be multiple.  If no "-at" clause, then check local Host only.
 Response must begin "From hostname: userident:" followed by either an
 appropriate address (e.g., "ll" if local "concom" uses TTY numbers
 and userident is logged in on TTY ll), or "Not available."
 As with mail, a "-all" embellishment might be pleasant.  Note that
 the search for the specified user(s) -- whether or not "-all" is used
 -- still assumes that a "login *free -who" login will be used on the
 appropriate remote Host(s), followed by "who userident".  This is why
 responses to the expanded who command must be so rigidly specified.
 Note also that regardless of whether the inquiry is made in terms of
 Network-wide or local user name, the response must be appropriate for
 use in "concom".
 "Good" concom implementations will presumably do an expanded who
 command automatically, so as to spare the user the necessity of
 having to do it separately.  Indeed, the -concom control argument to
 login is defined to imply the ability to do a who as well as a concom
 to cater to this possibility.  It is tempting to legislate that such
 an approach be the rule, but the implementation implications are not
 quite clear enough to do so.  The implicit who should be viewed as a
 strong hint to implementers, though.

File Creation and Manipulation

 The common command subset must furnish the ability to create and
 manipulate files.  Creation is necessary in order to send mail on the
 one hand, and to produce source files for subsequent compilation on
 the other hand.  Manipulation (such as copying, renaming, typing out,

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

 and the like) is necessary both as a convenience aspect for users who
 seek to operate only in the common command language and as a means of
 performing desired batch functions (see below).  For file
 manipulation commands, the user could enter the File Transfer
 Protocol environment.  However, the FTP user interface is constrained
 by a very high degree of program-drivability.  It is also lacks
 abbreviations and suffers from the lack of mnemonicity dictated by
 limiting command names to four characters.  Further, some valuable
 functions (such as causing a file to be typed out) are not dealt
 with.  Therefore, various UULP file manipulation commands are given
 in Appendix 1.  They need not be addressed in detail here.  However,
 some context would be useful:
 The file manipulation commands assume that all Servers have some
 notion roughly corresponding to "the user's working directory".  All
 file names, whether the yet to be invented Network Virtual Pathname
 or the "local" variety, are taken to refer to files in this directory
 unless otherwise indicated.  That is, the user should not have to
 furnish "dsk:" or the like; it is taken as given that when he refers
 to file "x" he means "the file named 'x' in my current working
 directory" and the Server "knows" what that means.
 At the present stage of development of the UULP, it does not seem
 fruitful to go into a reasoned explication of the following
 statement.  For now, suffice it to say that those file manipulation
 commands (a copy of a foreign file, for example) which need to employ
 the FTP do employ the FTP and let it go at that.  As the context and
 implications of the protocol become more widely understood, the
 detailed implementation notes will be added to the file commands --
 and refined for the other commands, doubtless.  In a way, the common
 file commands may be viewed as a kind of "User FTP" of known human
 interface when they deal with foreign files.  (And, of course, until
 there's a Network virtual pathname, the issue doesn't really arise.)
 I expect that an "identify" command might be desirable, so that UULP
 commands which have to access other Servers in turn on behalf of the
 specific current user can have the necessary login information
 available to them.  Such a command is included in Appendix 1, but
 should rank as speculation for now.
 On the topic of file creation, matters are rather complicated.  It is
 clear that the ability to create files in the UULP environment is
 extremely desirable.  It is also clear that using mail to a fake
 address to get the file created, then renaming the "unsent mail" file
 is too byzantine to expect users to do.  Unfortunately, it is not
 clear exactly what the alternative is.  That is, it's fairly clear
 that we need a common editor, but it's not at all clear which editor
 it should be.

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

 Two widely-known editors come to mind: TECO and QED.  However, not
 everybody has them.  Even if everybody did, the "dialects" problem is
 bound to be a large one.  Even if all the relevant system programmers
 could agree, there remains the question of whether the intended user
 population would be willing to bother learning a language as complex
 as TECO or QED.  Therefore an optional UULP command to be called
 "neted" is proposed.  (See also RFC 569.) This editor is a line-
 oriented context editor (no "regular expressions", but also no line
 numbers).  It is copiously documented in Chapter 4 or the Multics
 Programmers' Manual, including an annotated listing of the (PL/I)
 source code.  A simple user's guide has been prepared (see Appendix
 3).  Several implementations already exist, and commitments have been
 made for more.  It may also be repugnant to some of the system
 programmers who would be called upon to implement it -- which is why
 it is optional, until and unless higher authority makes it mandatory.

Other Protocols

 The nominal initial impetus for proposing a UULP was to allow new
 Network user protocols to be invokable through a common mechanism,
 rather than requiring a new responding mechanism to be built for a
 new contact socket for each new protocol.  Although this goal has
 been shunted into the background by the admission of the true goal of
 the UULP, it has not been dropped completely.  Therefore, to enter
 the FTP Server environment, the UULP command is "ftp"; to enter the
 RJE Server environment, the UULP command is "rje".  Exit is as per
 the respective protocols.  (Where possible, exit should be back to
 the UULP environment.)

Invoking Foreign Programs

 There are two broad contexts in which it is desirable to cause a
 specific local program to be invoked from the common command
 environment: The User side of the connection may itself be a program,
 and the desired Server side program a specifically cooperating one;
 this is the more sophisticated context, of course.  The less
 sophisticated context assumes that the User side is a "live" user,
 and the desire is to invoke a compiler or an object program the user
 has already compiled in the common language -- again as a convenience
 to the user so that he may operate in a sort of "Server-transparent"
 mode.  (The latter case also covers "batch" use of the Server; see
 below.)  In both contexts, the important role of the UULP is to
 specify the mechanisms through which the particular programs may be
 invoked, irrespective of the idiosyncrasies of the Servers' command

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

 Programming languages are much too big a problem to tackle here.
 However, assuming that a user somehow manages to create a source
 program, he still wants some commonality of spelling in invoking the
 appropriate compiler, or even the object program.  As an optional but
 strongly recommended UULP command, then, "call name" should invoke
 object program name (where the named program may be a "native"
 command with arguments specified as appropriate).  The values "pl1",
 "-basic", "-fortran", "-lisp", etc., should be recognized as
 requesting the invocation of the appropriate language processor (to
 operate on a named source file or interpretively/interactively if no
 source file was named), with "reasonable" defaults in effect.  Note
 that this all is meant to imply that "native" commands are not
 directly invokable from the UULP environment (other than by "call"),
 to avoid potential naming conflicts between system commands and new
 UULP commands.
    Note that the "call" command in the UULP environment constitutes a
    rubric for "parallel" computation, given any ad hoc convention for
    the return of completion information.  (Writing on the Telnet
    write socket plus 2 would seem appropriate, provided the initiator
    has the ability to "listen" for the rfc; but even a response in
    the data stream as a special-cased program is assumed on the
    "user"side anyway.)

Other Matters

 The topic of "batch" mode merits some attention.  As with the file
 manipulation commands, more consultation is necessary for a firm
 spec.  However, I suspect that a "-batch" control argument to login
 should initiate batch mode processing by the Server, and given the
 call and identify commands all we might then require is a convention
 for designating the output file in order to return it via a copy
 command in the "job" itself (if output is to be returned rather than
 stored at the Server).  Of course, -batch will probably need some
 substructure as to password and timing matters.  More details will
 emerge in this area in future iterations.
 An admittedly fictionalized scenario might look like this:
 login Me -batch -pw xxx -shift 3
 copy *452<me>source.text source.pl2
 call -pl2 source
 call source input output
 identify Me2 yyy
 copy output *555>root>Me>output452

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

 where user "Me" wants the Server receiving the commands (either
 directly from him at a TIP or perhaps from some other Server on which
 he has created a file containing them) to set up a batch job for him,
 with password "xxx", to be run on Shift 3 (whenever that is).  The
 job first copies file "source.text" from directory "<me>" on Host 452
 into local file "source.pl2", then compiles it with the local PL2
 compiler, executes it (assuming a "Not found" response would go into
 a known file if compilation had failed) with specified arguments
 (presumably the names of files for input and output), then copies the
 "output" file to Host 555's file hierarchy at the indicated place,
 using the user identifier "Me2" and the password "yyy".  It's not
 elegant, but it ought to work.
 Finally, on the topic of logging out, the UULP command is "logout".
 The Server must close the Telnet connection after doing whatever is
 appropriate to effect a logout.  To retain the Telnet connection,
 "logout -save".  Having the Server close is viewed as a convenience
 for the user, in that it spares him the necessity of causing his User
 Telnet to close.  It is also desirable for program-driven
 applications, so as not to leave the connections "dangling" and not
 to require possibly complex negotiations with the User side to break
 the connection.


 Syntax                                                   Opt
 I. "Set-up" Commands
 login id arg
 The id may be Network-wide or Host-specific.
 "*free" is reserved.
 The arg may be "-mail", "-who", "-concom",
 "-batch", or may be absent.
 Result is to be either logged in or passed off to appropriate daemon.
 prompt char
 Specifies that char is to become or
 precede the normal prompt message.
 Acceptable prior to login.
 erase char                                                X
 Specifies that char is the erase character.
 Invocation with no argument reverts to default.
 kill char                                                 X

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

 Specifies that char is the kill character.
 Invocation with no argument reverts to default.
 eol char                                                  X
 Specifies that char is the newline character.
 Invocation with no argument reverts to default.
 Enter the local command environment.
 Enter the FTP environment.
 Enter the RJE environment.
 Logout and sever the Telnet connection.
 logout -save
 Logout but keep the Telnet connection.
 Apply the case-mapping conventions of Appendix 2.
 Required on Hosts to which case is significant.
 identify id arg                                            X
 Specifies that id is to be used as the user
 identifier in any "fanout" logins required.
 If arg is specified, it is to be either the
 password to be used in such logins or "-pw", in
 which case the Server will furnish a mask or negotiate the Hide Your
 Input Telnet option; if no arg, then no password is to be furnished
 on fanout logins.
 Default id is "*free".
 II.  Communications Commands
 Type out "mailbox".
 readmail (id) -at host                                     X
 Type out "mailbox" on remote Host host.
 Multiple Hosts may be specified,
 separated by spaces (blanks).

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

 Implies ability to change working directory
 at host to directory implied by known
 user identifier, or (optionally) by id.
 readmail -all                                              XX
 Search for mail.
 Extremely optional.
 mail id
 Collect input until line consisting of
 only a period (".") for mailing to local
 user specified by id.
 mail -f file id
 Send contents of specified file to specified
 local user.
 mail id -at host
 Collect input until line consisting of
 only a period (".") for mailing to remote
 user(s) at specified Host(s). Both id and
 host may be multiple, separated by spaces.
 (If multiple, they should be taken pairwise.)
 mail -f file id -at host
 Send contents of specified file to specified
 remote user(s).
 The generic who's logged in command.
 who id
 Is id logged in? Constrained responses.
 who id -at host
 Is the specified user logged in at the
 specified host. Constrained responses.
 concom -on
 Enable console to console communications.
 concom -off
 Disable console to console communications.
 concom id
 Send messages to specified local user
 until line consisting of only a period (".").

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

 concom id -at host
 Send messages to specified remote user.
 III.  File Commands
 type path
 Type out the contents of the specified file.
 Pathname may be local or Network-wide.
 Default to current working directory.
 List the contents of the current working directory.  (Local format
 listdir path
 List the contents of the specified directory.
 rename old new
 Change the specified file's name as indicated.
 addname old new                                             X
 Give the specified file the specified extra name.
 delete path
 Get rid of the specified file.
 ("Expunge" if necessary.)
 copy from to
 Make a copy of the file specified by the first pathname at the second
 link from to                                                X
 If your file system has such a concept, make a "link" between the two
 pathnames.  If no second argument,
 use same entry name in working directory.
 status path st                                              X
 If your file system has such a concept, give status information about
 the specified file or directory.
 changewd path                                               X
 If no argument, return to the "home" directory.
 Type out the pathname of the current working directory.
 neted path

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

 See Appendix 3.
 IV.  Invoking "Native" Programs
 call name (args)
 Invoke the specified program with the
 specified arguments (if any).
 The following names are reserved to indicate the
 invocation of the corresponding language processor: "-pl1", "-basic",
 "-fortran", "-lisp".
 (If no source file indicated, invoke "interpretively" if possible.)
 V. On-line Documentation
 help name
 Type out information about the specified UULP command.  If name is
 "-sys", type out information about how to use the local system's help
 mechanism; if
 "uulp", about the local system's UULP implementation.  If no name
 given,  describe the command itself.


 This appendix will eventually contain the case-mapping conventions
 detailed in RFC 411.


 This appendix will eventually contain descriptions of the neted
 command requests (a draft of which now exists), or a reference to the
 Resource Notebook version, if that gets published first.  For now, it
 should be sufficient to point out that the requests are basically
 locate, next, top, change, save, and quit -- i.e., it's the "old-
 fashioned" flavor of context editor.
 [Optical character recognition and initial proofreading performed
 11/20-21/04 by The Author.  A few original typos were corrected; some
 may remain.]

Padlipsky [Page 19]

/data/webs/external/dokuwiki/data/pages/rfc/rfc666.txt · Last modified: 2006/11/22 00:32 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki