Date: Tue, 13 Dec 1994 18:28:59 -0600 (CST) From: Felix Gallo Subject: agent-tcl: a white paper Tue Dec 13 14:49:20 CST 1994 Felix Gallo The Demands of Agent-tcl: a prelude to [someone else's] RFC Synopsis: the notional language agent-tcl is a natural outgrowth of the safe-tcl efforts. Its purpose is to provide a framework for thought experiments about agent interaction. Note: this document is a draft. Please submit comments, additions, and questions to the author by sending e-mail to fsg@alumnet.com. I. safe-tcl vs. the agent paradigm Safe-tcl is a set of modifications to the tcl language designed to permit relatively safe migration of tcl scripts across boundaries of trust (for example, through electronic mail). It restricts use of the 'dangerous' tcl commands (such as filesystem access) in order to create a computing environment in which simple computations and transactions can take place without the executing user needing to hand- verify foreign scripts for nonmalicious intent. Agents are portable software objects which may 'travel' from computer to computer in order to accomplish some function (such as commercial purchases, information retrieval, information deposit, or distributed computation). Safe-tcl interpreters are currently not expressive enough to implement many of the features that a useful agent system requires. In particular, 1. safe-tcl cannot grant an agent the right to execute a command that would normally be considered 'unsafe' while maintaining the safeness of the remainder of its command set. safe-tcl's purpose is to restrict the richness of functionality of foreign programs. However, there are some viable instances in which the server may wish to permit agents to perform certain functions which require the use of unsafe commands, such as writing a line to a file. 2. safe-tcl has no mechanism for authentication of agents. the traditional view of agents includes the implementation of a carried-along 'state' which may prove useful at the destination. For instance, it may be beneficial to allow only 'trusted' agents to execute certain functions under some applications. 3. safe-tcl has no mechanism for encryption or decryption of agent programs or data. because the agent paradigm doesn't demand or rule out any particular transport mechanism, it must be assumed that agents will be carrying their data in an insecure environment. Hence, support must be provided for any data to be kept uncompromised and unchanged. Numbers 2 and 3 are protocol-dependent; the large mass of encryption, decryption and authentication program denies the possibility of a clear superior legal winner being pickable and standardizable. However, it should be possible for agents to negotiate their options with the server they arrive on in a standardized fashion. Number 1 is the big problem. One solution for it manages to solve the others via side-effect; the rest of this paper describes that solution. II. agent-tcl's rough definition Consider a language called agent-tcl, which describes a complete superset of the current implementation of safe-tcl. This language has several extra commands: 'require' 'require' is followed by a list of ordered pairs. The first element of each pair specifies the variable which 'must have' at least the minimum value of the second element. The command returns true if all requirement pairs are satisfied and returns a list containing triplets made up of the variable, the requested value, and the actual (insufficient) value if any requirement pair cannot be satisfied. If the first part of a pair is a defined command name, then the pair is satisfied if the second part of the pair is 'command' and the server permits that command's execution to this agent. Undefined values are treated as always insufficient with a value of 'undefined'. Example: % require { {cputime 50} {bytesfree 500} {version 5.65} } { {bytesfree 500 319} {cputime 20} } The purpose of this command is to provide a framework for the server and agent to negotiate a set of rules under which the agent must operate. In the example, the server does not have enough bytesfree for the agent's needs, and it has limited the cputime that the agent is allowed to 20. It is up to the agent what action to take upon failure to receive enough resources. 'query' 'query' asks the server for all of the variables that are currently defined along with their values and their status. It takes no arguments but returns all the available variables, all the available commands, and the current agent's permissions status (see 'permissions', far below) for each element, as a triad. For instance: % query {{bytesfree 319 GR} {cputime 20 GR} {xcoord 0 LW} {ycoord 0 LW} ... } extra commands have the value of 'defined'. 'unwind_agent' 'unwind_agent' takes five arguments: an authentication key, an encryption key (if necessary), and an authenticated, encrypted string of characters which, when decrypted, becomes a tcl script. For instance: unwind_agent -authmethod PEM -authkey EF45743743692AB43A -cryptmethod RC4 -cryptkey EB4874238620BA -crypttext 98765BE23874A2374624E... the unwind_agent command acts as a wrapper around the rest of the tcl script. When the interpreter gets and successfully decodes the encapsulated tcl script using the appropriate methodology, it immediately transfers the flow of execution to that script. the reason why this functionality is not subsumed into the transport layer is that the author guesses that having agents contained within agents could be useful in some applications. 'agent_send' I couldn't think of a better name. Anyway, 'agent_send' takes three arguments: a destination, a method, and an agent-tcl script. For example: agent_send -to ftp.uu.net -method {tcp port 4949} -code {... the methods used for the sending need to be standardized, but that's beyond the scope of this layer. III. permissions The permissions model is fairly simple. Each variable must have one of two scope states: G ('global'), which means that the variable is shared amongst all agents running on this server, or L ('local'), which means the variable has interpreter scope only. In addition, each variable must have one of three permission states: 'R', or read-only, 'W', or read-write, and 'N' (for 'none'). The 'none' state only exists for the sake of completeness, because in practice an interpreter would only ever set variables that it could in the future do something with. All the obvious rules apply; if a variable is 'R', then nobody can set it but it can be used as an rvalue, and so on. III. transactions The concept of a transaction is important to agents; it is likely that agents will want to set variables and communicate with their 'master' as well as the interpreter they're running on. The model the fictional language agent-tcl adopts is as follows: 1. The interpreter receives an agent from the transport layer. 2. The interpreter performs any necessary initialization functions in order to ready the execution environment for the agent. 3. The interpreter begins to execute the agent. 4. The agent determines if the server has acceptable resources and functionality. 5a. If it doesn't, it follows some exit path. 5b. If it does, the agent executes the appropriate transaction-style command and receives as its return value a tcl script. 6. The agent permutes the tcl script as necessary and sends it back to her 'master'. 7. The agent finishes executing and the interpreter completes. 8. Back on her master's machine, the transport layer gives the new agent to the interpreter and so on. IV. Interaction protocol All this begs the question of how an agent knows to execute a function called, for example, 'buy' and what to expect of it. Which is why I propose a higher level protocol which is followed by agent programmers and server programmers, called 'the interaction protocol' for lack of a better set of words. The interaction protocol: A. the following variables must be defined and must be readable. version the server's version level (a float) location the local hostname owner the e-mail address of the server's owner cryptmethods a list of all available decryption methods here authmethods a list of all available authentication methods here B. the following variables may be defined and may be readable; but these are the definitive names of the variables if they are to be defined, and no other variable may subsume their function. time the server's local time in seconds-since-epoch idnum the server's local integer notion of this agent's unique identification number on this server greet a greeting string cputime allowed cpu time (in seconds) credits number of remaining credits (implementation-specific) storage disk quota this agent has remaining memory memory quota this agent has remaining C. all commands wishing to be 'transaction class' must have the following calling syntax: functionname [-syntax] [arg1] [...argN] ...and must return a plaintext agent-tcl script in the event of a successful transaction, or false in the event of an unsuccessful transaction. D. the following transaction class commands are implemented exactly as written, if implemented at all (the implementation is not a requirement). buy [-syntax] [-item itemname] [-account accountnumber] [-accounttype accounttype] [-address deliveryaddress] return value: an agent with a wound-up (see 'unwind_agent', above) body containing 'set' commands that set 'time' to the transaction time, 'cost' to the cost in server-local currency, 'track' to a unique transaction tracking number, and 'eta' to an estimated delivery time. Any other information may also be provided at this time. [note: this is all a gedankenexperiment, so I'm not going to flesh out the functionality of the useful set of transaction class commands at the present time, but you get the idea] E. the following helper functions must be implemented if the related transaction class command is implemented. buy_catalog (no arguments) return value: a list of all of the items for sale that this particular server knows about, in the form { itemname cost-of-item } [see above note; this is only one of the helper functions that would be important if one implemented 'buy', but it conveys the general sense and provides an example for the E category of requirements for the protocol] V. Leftover items This document has failed to address: * the standardization of the agent transport layer under network protocols (Enabled Mail can be agent-tcl, and it works as it does currently) * what is the good set of 'basic' transaction class commands? * what is a complete and good set of standard variable names and functionalities? * should the names and functionalities of non-transaction-class commands also be standardized, or is the concept of the transaction class sufficient? * is passing agents back as return values too weighty? * does this technique bind too closely to tcl -- and if it does, then what subsets need to be revised in order to get this protocol and this methodology working with other languages? * how well does this bind with other agent technologies, such as telescript? Can a translation engine be written to handle telescript agents on an agent-tcl server, and vice versa? VI. Author's note Thanks for reading this! I have no ego attached to these words; if you wish to tear up the bad bits and claim the good bits as your own, please go right ahead. This document is in the public domain, although I retain the right to say that I'm releasing the latest version whenever I release a version of this document. I meant this draft to incite discussion and provoke thought. If you've been interested enough to read this far, then please take a moment or two to send me mail giving me your thoughts, comments, questions and improvements. I'll make future drafts available as the situation appears to warrant. If you're superinterested, please feel free to take this document over from me. Felix