diff options
Diffstat (limited to 'doc/rfc/rfc666.txt')
| -rw-r--r-- | doc/rfc/rfc666.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc666.txt b/doc/rfc/rfc666.txt new file mode 100644 index 0000000..d5aa5e0 --- /dev/null +++ b/doc/rfc/rfc666.txt @@ -0,0 +1,1067 @@ + + + + + + +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 + areas: + + 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 + + +Context + + 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. + +Responses + + 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.) + + +Arguments + + 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 + + +Case + + 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). + + +Prompts + + 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. + + +Login + + 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 + implemented." + + +"Mail" + + 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 + languages. + + + + +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 + logout + + + + +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. + + +APPENDIX 1. THE COMMON COMMAND SUBSET + + 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. + + local + Enter the local command environment. + + ftp + Enter the FTP environment. + + rje + Enter the RJE environment. + logout + Logout and sever the Telnet connection. + + logout -save + Logout but keep the Telnet connection. + + map + 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 + + + readmail + 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). + + who + 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. + + listdir + List the contents of the current working directory. (Local format + acceptable.) + + 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 + pathname. + + 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. + + typewd + 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. + + +APPENDIX 2. MAP COMMAND CONVENTIONS + + This appendix will eventually contain the case-mapping conventions + detailed in RFC 411. + + +APPENDIX 3. EDIT COMMAND REQUESTS + + 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] + |