\begindata{text,539484024} \textdsversion{12} \template{default} \define{global } \define{null menu:[null]} \define{itemize menu:[Region,Itemize] attr:[LeftMargin LeftMargin Inch 32768]} \define{notetotypesetter menu:[Region,NoteToTypesetter] attr:[Flags PassThru Int Set]} \define{p menu:[Other,P] attr:[FontFace Bold Int Set]} \chapter{1 The Andrew Message System: A Portable, Distributed System for Multi-Media Electronic Communication} Nathaniel Borenstein Craig Everhart Jonathan Rosenbertg \section{1.1 Introduction} The Andrew Message System (AMS) is a project with the goal of producing a production-quality electronic communication environment with several types of functionality which have hitherto either not been provided by electronic message systems or have been found only in experimental systems. The primary contributions of the AMS are: \itemize{\p{Machine and location independence}: Users of the AMS can read mail or bulletin boards once on an advanced workstation (Sun, IBM-RT, or MicroVax), the next time on an IBM PC, or on any other machine on which the system runs, and will always see a consistent database of messages and user profiling information. See the NonUnix documents for more information. \p{Integration of communication database}: The AMS treats mail, distribution lists, bulletin boards, and event calendars uniformly as \italic{messages}, allowing users to manipulate all of these after learning to use a single interface. \p{Separation of interface from functionality}: The AMS architecture makes it easy to support multiple user interfaces while preserving for each the highest functionality. For example, AMS supports a fancy bitmap-based interface for the advanced workstations (Messages), and a teletype-based interface which runs identically on the workstations, on dialup lines, and on IBM PC's (CUI), and a PC-based interface that uses menus familiar to PC users (VUI). \p{Support for multi-media communication}: The AMS is designed to support messages that include formatted text, complex graphics, and even animation, although some of these messages will obviously look their best only when viewed with the more advanced interfaces. \p{Support for coping with information flood}: Several mechanisms in the AMS are being implemented as possible mechanisms for dealing with the flood of information that is increasingly overwhelming users of electronic communication systems on networks such as the ARPA Internet. In order to permit the reasonable evaluation of these mechanisms, The AMS has been designed to prevent performance degradation in the face of the megabytes of messages now being fed into the system from diverse sites on various networks. \p{Flexible Architecture}: The AMS has been designed for easy expansion to include various kinds of functionality not yet foreseen or implemented. }This paper will describe the AMS in major sections: \itemize{\p{Background}: To understand the design of the Andrew Message System, it is first necessary to understand a bit about the structure of the Andrew project as a whole and its distributed file system (AFS) in particular. We will also review some other related work in the area of electronic communication. \p{Desiderata}: One of the first steps in the design of the AMS was an extensive survey of users of various electronic communication systems, in an attempt to define the largest possible set of goals for such a system. We present the "wish list" gleaned from this survey, as it significantly shaped the design of the system. Of course, it was never planned that we would implement every item on the wish list, but we did design our system to accommodate as many of them as possible, and the list should be useful to designers of future systems. \p{Architecture}: In this section we describe the overall design of the AMS, and explain how certain aspects of the architecture are essential to permit the achievement of goals from the wish list. } \section{1.2 Background} \subsection{1.2.1 The Andrew System} The Andrew project is a joint venture of IBM and Carnegie-Mellon University, started in 1982. The goal of which is to produce a suitable working environment for academic use of computers. The project is described in detail in [CACM-ARTICLE], but a few key points should be noted here. In Andrew, each user works on an advanced workstation (currently an IBM RT, Sun, or Dec MicroVax computer) running UNIX and connected to a campus-wide network over which it can talk to any of several dedicated file server machines. There were two basic parts to Andrew, then known as VIRTUE and VICE. VIRTUE was the user interface portion, which ran on the workstation, and includes a window manager, base editor subroutine library, and a number of application programs (e.g. the text editor) which exploited the facilities offered by the large bitmap display. VIRTUE evolved to eventually become ATK. VICE was the original name for the Andrew File System (AFS); it emulates a UNIX file system transparently, so that as users move from one workstation to another, the picture they see of their files remains consistent at all times. Both ATK and AFS have strongly influenced the design of the Andrew Message System Each has made some parts of the system much easier and some parts much more difficult. ATK, through the base editor library, makes it almost trivial to deal with multi-media messages, but thus introduces serious complexities into the manner in which messages are sent and received to non-Andrew systems. AFS makes it easy to create a message database which is entirely location-independent, but introduces, by its very existence, new kinds of failure conditions neither expected nor dealt with robustly by software written for standalone UNIX systems. In particular, the file system conceptually simplified the mail delivery mechanism, but at the same time mandated a complete rewrite of existing UNIX mail delivery programs. The stated objective of the Andrew project was to produce an effective working environment for high-function workstations. Since one of the goals of the Andrew Message System was to produce a message system that was portable even to such lower-functionality machines as IBM PC's and Apple Macintoshes, this required that our design be more general than Andrew's, and in particular that our communication mechanisms, though based at bottom on AFS, be more general and more portable than AFS itself. \subsection{1.2.2 Relevant Previous work on Message Systems} Although time and space do not permit us a complete survey of previous work on message systems, a few previous efforts influenced our design so strongly that they should be mentioned here. The Grapevine system [CITATION] first demonstrated the feasability and utility of truly distributed electronic message systems. Malone's work on the information lens [CITATIONS] has stimulated our interest in mechanisms for dealing with information flood, and indeed we hope to implement some of Malone's ideas in future versions of the AMS. Part of the guiding vision for any modern view of electronic communication can be found in Turoff and Hiltz's works [CITATIONS], especially \italic{The Network Nation} [CITATION]. Our ideas about user interfaces have been shaped by a succession of user interfaces for mail and bulletin board systems, most notably TOPS-10 RdMail [CITATION], various Emacs-based message systems [BAGS & OTHER CITATIONS], earlier Andrew systems for mail and bulletin boards [CITATION], and several interfaces to the UNIX netnews system [CITATION]. Our passion for an integrated communication environment with a coherent and clean design can be traced in large part to personal experience with communication systems lacking in these aspects [CITE--BB PAPER]. \section{1.3 Desiderata for Electronic Communication Systems} As stated previously, a central part of the initial design phase of the AMS project was the compilation of a "wish list" for electronic communication. This list was derived from a series of surveys conducted via the ARPA Internet and several local electronic bulletin board systems. Participants were encouraged to indulge their wildest flights of fancy; the primary purpose of the exercise was to insure that our initial vision was wide enough. We tried to design the AMS to permit the eventual inclusion of as much of the wish list as possible, even if many of the features were beyond our initial resources for implementation. To help provide the implementers of future systems with a vision at least as broad, we reproduce that list below: \subsection{1.3.1 The Wish List} \paragraph{1.3.1.1 Delivery and Performance Issues} \leftindent{100% reliable delivery -- All messages delivered, returned, or sent to maintainer. Fast delivery -- alternate delivery speeds, with fastest delivery at extra cost or for privileged users. Fast confirmation of delivery for senders' peace of mind. Simple delivery -- local users addressed by name only, with lookup in a community "phone book". Locally reliable support for external networks, including ARPAnet, uucp, BITNET, CSNet, etc. and all reasonable protocols (DARPA, uucp, CCITT X.400, NBS-10, SMTP, XMODEM, KERMIT) Database of "clues" for paths to machines on external networks. Good construction of "Reply-to" addresses for responses to externally-generated messages. Conversion of all outgoing messages to conform to ARPAnet header standards. Robust delivery. Automatic daily testing of connections to any cooperating machines (machines with a "BOUNCE" mail address, which simply sends all mail sent to it back to the sender unless it bears traces of a bounce loop). Hooks for users to specify automatic processing of incoming or outgoing mail. The biggest use will probably be auto-cc's, which will be useful for forwarding external bboard notices and for allowing users to participate in experiments monitoring message system usage. Will also be useful for "undigesting" messages arriving from external world in "digest" form. Automatic system monitoring. Collection of aggregate data on system use and performance for fine-tuning the system and for research on message system usage. Self-monitoring for internal consistency and automatic bug reporting. Fast performance of all "basic" functions -- sending mail, reading personal mail and standard message groups. } \paragraph{1.3.1.2 Privacy/Protection Issues} \leftindent{Dominant principle should be First Amendment: all users should have as much self-expression as is feasible. Also, privacy should be preserved to all reasonable limits. Each message classification will have separate categories identifying those users who can: read the messages, enter new messages, edit the messages, respond to existing messages. (Also, who pays for each message.) Access to external networks must be easily limited to certain individuals or specifically denied to certain individuals. Access to the message system itself or to particular portions of it should be easily limited in the case of abuses. Provision for breaking privacy restrictions (e.g. to deal with antisocial behavior such as pseudonymously publishing credit card numbers) must be structured and limited. For example, privacy restrictions may be circumvented only by three system maintainers acting as a group, supplying all three passwords. By default, the system should trust the login identification of a user, but it should be possible to make specific message databases (e.g. sensitive bboards or personal mail) accessable only with the use of a secondary password. Only data that does not identify individuals will be collected automatically and without user permission. "Pseudonymous" messages should be supported and protected. Users should be able to send messages by pseudonyms, with their real identities known to the system but obtainable only in extreme circumstances (e.g. by a group of system maintainers together, as mentioned above). Truly anonymous messages should not be possible, as experience with existing message systems indicates that this will lead to widespread abuses. Provision should be made to allow people to communicate by pseudonym; that is, the pseudonyms will serve as aliases understood by the mail system but not revealed by it. Provision should also be made for mutual revelation of pseudonyms; "I'll tell you mine if you tell me yours" should be an enforceable offer, with the revelation of identities mutual and simultaneous. The creation of new user or group identities should be controlled but flexible. Anyone should be able to create anonymous or pseudonymous users, but these should be clearly discernable as such. (That is, pseudonyms should not resemble real names such as "Ronald Reagan", but instead should be something like "pseudo-Ronald Reagan".) Users should be able to create users that appear as "versions" of themselves, e.g. "John Doe.secretary". When messages are modified, a modification history should preserve so that claims about its previous state may be investigated and settled. } \paragraph{1.3.1.3 Economic Issues} \leftindent{Ability to charge users either for each message sent or for storage of preserved messages, or both. Ability to charge users for the privilege of reading your message or database. Alternate delivery speeds, with fastest delivery at extra cost. Ability to charge varying amounts for varying types of message and delivery. Ability to surcharge senders of "junk mail"; when abusive or excessive mail is sent, the recipient should be able to (moderately) increase the cost to the sender. } \paragraph{1.3.1.4 Message Structure and Database Issues} \leftindent{First class mail: mail from one individual to one or more other individuals. Registered Mail, Return Receipt Requested: For a still higher charge, the confirmation will occur only after a human recipient has agreed to confirm receipt of the mail. Recipients can refuse receipt of such mail, but will then be unable to read the mail's contents. Parcel Post: Mail may enclose or consist of files as "parcels". Software on the recipient end should make it simple to restore a file to its original format in the recipient's disk area. Special provision should be made for encoding and decoding binary files and groups of files, and for "peeking" at a file before allowing it to appear on your disk space. Form Letters: Provision should be made for constructing form letters to be sent out in customized form as appropriate (for example, explaining rules for using a laboratory, etc.). Mailing lists: mail to a public or private list of people. In a private list, the complete set of recipients may not be visible to those recipients without the proper access privileges. Spreading distribution list or "approval sequence". Messages can be sent to a group of people specifying additional recipients to whom the message will go after the first recipients verify the message. Messages to more than one individual implemented efficiently (i.e. with minimal multiple physical copies). Message databases: in addition to individuals, messages can be sent to databases (bulletin boards) which may be public or private to groups. Each message database has its own protection status, a policy statement explaining the purpose and conventions of the database, and a "duration" specification telling how long messages exist once they appear. Each database also has a set of responsible parties who can edit and delete messages, and a party who is charged for the storage used by the database. Databases should be logical entities; a message in multiple databases need not exist in two physical copies. Individual mail will appear simply as a private message database. Users should be able to define logical message databases which combine message databases, and to use such logical database names in commands relating to reading and writing messages. (When a user tries to send a message to such a logical database, the system should give him the option of sending to all or some of the components, e.g. sending messages to sf-lovers locally and/or on usenet and/or on ARPAnet.) In addition to databases which are added to by specific actions, other databases may be constructed to which messages are automatically added when they match certain criteria. (However, these databases must not interfere with the other protection mechanisms; a message on a private database should not become public simply because it contains a certain key word.) It should also be possible to search message databases by arbitrary key words and for other specific message information. Incorrectly classified messages -- those inappropriate to a specific database -- should be easily reclassifiable by individuals with the appropriate access rights. Each database can be divided into sub-databases to deal with particular sub-topics, and individuals should be able to specify that they are reading only the top-level notices, all notices recursively, or some combination of some but not all sub-databases. Reviews of Messages: Any individual with read-access to a message database should be able to declare himself a "reviewer" for that database. He will then indicate whether or not each message he reads is worth reading. Other individuals can then use his reviews, or an arbitrary function of the reviews of several reviewers (e.g. a majority vote, weighted average, etc.) to pre-screen messages. Provision should be made for helping users choose reviewers, for automatically using all active reviewers, and for not penalizing users who depend on the views of a reviewer who becomes inactive. (Using all active reviewers is actually a form of voluntary voting about messages, which may be most desirable for certain types of databases. It might even be the criterion for the duration over which an individual message is preserved. For this type of database, it might be desirable to consider every user a reviewer, but to maintain only aggregate reviewing data.) "Hooks" should be left in the system to allow for future incorporation of "intelligent" automatic classification mechanisms and filters on incoming and outgoing mail. The system must be designed to support an aggregate database of messages that is enormous, probably including millions of messages, some very long. The message format should use the internal ITC datastream, to allow for inclusion of mixed text, graphics, and any other media which will be locally supported. Such local dependencies must be filtered out at the interface with external networks, and when transmitting message bodies to PC's and other machines that do not support the full datastream. Messages should be easily encoded and decoded using public key cryptography. A less costly encoding scheme should be available for potentially offensive notices, along the lines of the netnews "rot13" convention. Everyone who reads a message should have the option of responding to it; messages posted in response to other messages (annotations, corrections, rebuttals, answers, etc.) should appear as a subgroup of messages visible when the user is looking at the base message. A message may be posted in response to another message, as a new message in its own right, or both. Thus the overall structure of the message database is a DAG. (The structure is acyclic because no message can ever be a response to a later message.) In general, if the system showed you a message it will show you the responses, as they come in, as a "sub-database" to which you are subscribed. Provision should be made for smoothly converting a message which generated many responses into a genuine sub-database, which individual users can then explicitly specify a preference or aversion to seeing. } \paragraph{1.3.1.5 Timing & Editing Issues} \leftindent{Associated with each message should be several pieces of timing information: when the message is to appear, how long it should last before going away (possibly forever), and how often to appear (possibly at regular intervals, e.g. every April 1 or on the third Tuesday of each month),. Also stored with each message should be a note describing any need to archive a message before deletion. For each message group, certain users should have privileges allowing them to edit all messages, again with an appropriate audit trail. Any user should have the right to try to edit any message he can read; if he is not permitted to actually edit it, he should be able to submit it as a suggested edit to someone who does have the right to edit it. Deleting a message will be subject to the same rules as editing a message. Messages will have associated with them a "time of last modification". This time is updated each time a message is created or edited, and each time a response to the message (or a response to a response, etc.) is created. Users will be able to search the database to find messages in certain categories modified after certain times, or to see all messages regardless of modification time. Since people most often use such systems in "update" mode -- that is, seeing all messsages that have appeared since the last reading -- the database should be structured for maximum efficiency in this situation. } \paragraph{1.3.1.6 Interface Issues} \leftindent{The system must be portable; it must run on a wide range of hardware from state-of-the-art workstations to teletypes. The set of messages seen, and the state information about what has been seen in the past, should be the same for a given user no matter what hardware he is using. That is, it should be routine to read mail one day on one machine, and the next day on a different machine. The interface on the various machines should be as consistent as possible. A "dumb" typescript interface should be available on all machines to maximize consistency. A "smart video terminal" interface should be available consistently on all hardware that can support it. Advanced interfaces on workstations should be kept as consistent with the other interfaces as possible, with the other interfaces available as a subset of the advanced system. As much code as possible should be written in highly portable C, to help maximize consistency. The aforementioned standard interfaces should have distinct styles, to suit the inevitable disparities of user preferences. The typescript interface should be command-driven, the full-screen interface should be control-character-driven (a la Emacs), and the workstation interface should be mouse-and-menu-driven. A prompt-driven novice interface would also be desirable, as would a stream-oriented interface for use by client programs. The command-driven programs should be designed to easily support multi-lingual interaction, to simplify use of the program for foreign nationals or in ports to foreign sites. The full screen interfaces should use windowing to divide the screen, when appropriate, into areas for message headers, message bodies, message composition, help, and typescript-style interaction. Not all such windows need always be visible, however. All windows should be independently scrollable. Commands should give simple support to file operations, such as writing messages into files, reading files into messages being composed, and so on. Messages should be easily printed or added to additional public or private databases. Appropriate conversions should be easily made for converting a "current" notice into a "reminder" notice about an event on a future date. Features should easily permit replying to messages and forwarding messages. It should be easy to get a list of all message groups, or all message groups matching certain criteria. For those with the appropriate privileges, it should be a simple matter to alter the protection status of a message group, e.g. to give new people permission to read or write messages in it. Generally irrelevant state information -- e.g. most headers from messages arriving via the ARPAnet -- should be generally invisible, but available on request. As many interface features as reasonably possible should be made customization options, to give users more control over the style of interaction. Customization information, like messages themselves, should be universally available regardless of hardware being used, even though some of it may be ignored by some interfaces. The interface should validate all addresses for outgoing messages as early as possible, so that the user need not wait until the final delivery attempt to learn of addressing errors. Provision should be made for automatically informing those users who want to be informed about the creation of all new message databases to which the user has access privileges. Error messages should be clear and informative. Useful on-line help and a readable, "need-to-know" structured manual should be available. Spelling correction should be available for all messages being composed. It should be automatic or optional, at the user's preference. All commands should be specifiable either as command line arguments, as entries in an initialization file, or interactively as the program is run. } \paragraph{1.3.1.7 Integration Issues} \leftindent{The system should integrate all locally available media, e.g. graphics. The system should have a smooth interface with external networks. The system should be well-integrated with local application programs. The system should be able to be integrated with future electronic funds transfer mechanisms, to allow users to mail each other money, for example, or to pay bills from their workstations. The system should be available on nearly all the machines on the CMU campus, specifically including Andrew workstations, IBM PC's, Macintoshes, VAX systems running both UNIX and VMS, and TOPS systems. Those machines not integrated into the new system should at least be able to communicate via mail at the same level as machines on external networks. Wherever possible, automatic mechanisms should be provided to allow users to move messages from an older mail system to the new system, thus lessening transition costs. The system should be as extensible as possible; everything should be written in as general a way as efficiency allows, so that unforseen future additions to the system are more likely to be possible. } \section{1.4 Architecture} \subsection{1.4.1 Two process architecure} One particular item from the wish list -- the desire to have the system available on the widest possible range of machines -- has played a major role in the architecture of our system. In order to make the system available on such low-end machines as the IBM PC and Apple MacIntosh, it was clearly necessary to segment the functionality of the system into two major parts: the part which accesses, stores, and alters information in the database, and the part which interacts with the user on whatever machine he or she is on. The former, which we call the \italic{message server}, must run on a machine with full access to the message database stored in AFS. The latter, the user interface component, needs only to be able to talk to a message server via an agreed-upon mechanism. The mechanism by which the message server and its clients communicate is called SNAP (for Simple Network Application Protocol), which was developed for both the Message System and to connect IBM PC's to the Vice file system via special servers. SNAP is a very simple communication package that may be used by applications to perform remote procedure calls. Communication in SNAP is decidedly one-way; the client makes calls upon the server and waits for answers from it. The client code in SNAP has been kept extremely simple to facilitate portability to multiple machines. Communication via SNAP is also connectionless; packets are sent back and forth as datagrams, with essentially no connection state. The simple picture of a client talking to a message server via SNAP is not, however, the whole story. AFS has an elaborate authentication mechanism by which it guarantees the security and privacy of users' files. Since the connectionless nature of the SNAP conversation would make it extremely easy for \italic{any} process on the network to talk to a message server, some mechanism needed to be provided to guarantee the security of these conversations. The main guarantor of security and authentication in the message system is a process called the \italic{guardian}. The guardian acts as the "gateway" to all SNAP servers. When a client wishes to open a conversation with a message server, it first contacts the guardian on the appropriate machine and says, in effect, "Give me a message server." It provides a user id and a password. The guardian then authenticates the user with AFS (an elaborate procedure which involves talking to the AFS authentication server). If the authentication succeeds, the client is given the address of a message server and an encryption key. (If no message server is yet running for the user on that machine, the guardian starts one, which it can do because it runs as root, the UNIX superuser.) The security of the conversation between the client and the message server is thus doubly guaranteed: without authentication, in order to break into the system a user must first *guess* the address of a running message server, and then guess the encryption key. The guardian also performs a few other useful services, such as giving clients early notification if the message server has gone away. So far we have seen only the process-level architecture of the system. Next we will consider, in turn, the two major parts of the system, the message server and its clients. \subsection{1.4.2 Message server, White Pages and Delivery system} The message server, as stated previously, performs all of the actual database-related activities in the message system. It also acts on requests from clients to look up user names and to deliver messages to other users. To do this, it interacts with two other, as yet unmentioned, components of the Andrew Message System, the \italic{White Pages} and the \italic{delivery system}. The White Pages are a subroutine library which matches incomplete user name specifications to known user names. In particular, it does "best-matching" on partial names, so that a user can address mail to "N Bore" and have this automatically matched to the user id "nsb", which belongs to "Nathaniel Borenstein". See the WP documents for more information on the White Pages. The delivery system is another extremely complicated subsystem. This is a suite of programs dedicated to the process of actually moving mail from one user to another. These programs are complex primarily because of the effort devoted to making mail delivery reliable in the face of network problems, AFS problems, and other complications. See the AMDS documents for more information on the Delivery System. \subsection{1.4.3 The Message Server Clients} In previous sections, the overall architecture of the message system was described in terms of the guardian, the message server, and the message server's clients. In this section, we will at last discuss the clients, which are the programs that users actually see. Each of the clients is linked with a subroutine library, called the \italic{common user interface library}, or CUI library. The CUI library includes SNAP and all of the procedures that hide SNAP from the interface programmer (by providing the apperance of direct calls to the message server), and some additional abstractions of context which are not provided by the connectionless nature of the interface with the message server. The simplest client is simply called the cui, or common user interface. This program, like the cui library, is written in extremely portable C and make only minimal assumptions about the runtime environment and machine type. This makes it possible to promise that cui will be available on every system that supports the Andrew Message System, allowing users who switch frequently between systems to avoid learning more than a single interface. Accordingly, the cui is line-oriented, and can run equally well (or equally poorly, depending on how you feel about such simple interfaces) on an advanced workstation, a PC, and a teletype communicating over a dialup line. The most advanced client of the message server it the program known simply as \italic{messages}. This is a program which runs only on a workstation (Sun, Vax, or IBM RT) running the Andrew window manager. The messages program includes the ATK \italic{base editor subroutine library}, which provides application programs with multiple fonts, multiple display areas, scrollable displays, and intermixed text and graphics. \section{1.5 Acknowledgements} A large number of people have participated in the design and implementation of the Andrew Message System, and an extremely large number of people -- our user community -- have helped out with comments and suggestions. In addition to the authors, important work has been contributed directly by Mark Chance, Sue Pawlowski, Bob Glickstein and Adam Stoller. Moreover, the system would not be possible without extensive libraries and other facilities provided by the rest of the Information Technology Center at Carnegie Mellon, most notably the AFS Group and the User Interface Group. Their contribution is gratefully acknowledged. \begindata{bp,537558784} \enddata{bp,537558784} \view{bpv,537558784,1468,0,0} Copyright 1992 Carnegie Mellon University and IBM. All rights reserved. \smaller{\smaller{$Disclaimer: Permission to use, copy, modify, and distribute this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice, this permission notice, and the following disclaimer appear in supporting documentation, and that the names of IBM, Carnegie Mellon University, and other copyright holders, not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. IBM, CARNEGIE MELLON UNIVERSITY, AND THE OTHER COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL IBM, CARNEGIE MELLON UNIVERSITY, OR ANY OTHER COPYRIGHT HOLDER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. $ }}\enddata{text,539484024}