Framework and Functions of the "MS" Personal Message System: A Report prepared for DEFENSE ADVANCED RESEARCH PROJECTS AGENCY by David H. Crocker December 1977
NOTICE: THIS WORK MAY BE PROTECTED BY COPYRIGHT
YOU ARE REQUIRED TO READ THE COPYRIGHT NOTICE AT THIS LINK BEFORE YOU READ THE FOLLOWING WORK, THAT IS AVAILABLE SOLELY FOR PRIVATE STUDY, SCHOLARSHIP OR RESEARCH PURSUANT TO 17 U.S.C. SECTION 107 AND 108. IN THE EVENT THAT THE LIBRARY DETERMINES THAT UNLAWFUL COPYING OF THIS WORK HAS OCCURRED, THE LIBRARY HAS THE RIGHT TO BLOCK THE I.P. ADDRESS AT WHICH THE UNLAWFUL COPYING APPEARED TO HAVE OCCURRED. THANK YOU FOR RESPECTING THE RIGHTS OF COPYRIGHT OWNERS.
ARPA ORDER NO.: 189-1 7P10 Information Processing Techniques
R-2134-ARPA
December 1977 Framework and Functions of the "MS" Personal Message System
David H. Crocker A Report prepared for DEFENSE ADVANCED RESEARCH PROJECTS AGENCY
The research described in this report was sponsored by the Defense Advanced Research Projects Agency under Contract No. DAHCl5-73-C-0181.
Reports of The Rand Corporation do not necessarily reflect the opinions or policies of the sponsors of Rand research.
Published by The Rand Corporation
ARPA ORDER NO.: 189-1 7P10 Information Processing Techniques
R-2134-ARPA December 1977
Framework and Functions of the "MS" Personal Message System
David H. Crocker
A Report prepared for
DEFENSE ADVANCED RESEARCH PROJECTS AGENCY
Rand SANTA MONICA, CA. 90406
APPROVED FOR PUBLIC RELEASE; DISTRIBUTION UNLIMITED
PREFACE
A coordinated set of programs for minicomputers in the Digital Equipment Corporation PDP-11 series is being developed by The Rand Corporation as part of its research for the Information Processing Techniques Office of the Defense Advanced Research Projects Agency (ARPA). This computer software will enable a user to perform such tasks as text manipulation, "reminder" functions, rule-directed "user agent" functions, and manipulation of electronic mail.
This report describes the design of one such program--the "MS" message system. Early electronic mail systems have existed on the larger computers. MS incorporates and expands upon many of the functions and concepts of such systems within an integrated package, using the Unix operating system, for users of PDP-11 minicomputers.
The report should be of interest to users and designers of computer-based communication network message systems. Familiarity with the Unix operating system, although not critical to an understanding of the text, would be helpful to most readers. This document is not intended to serve as a user's guide. As specific interfaces with human operators are constructed for MS, specific user's guides are being written.
SUMMARY
One of the earliest and most popular applications of the ARPANET computer communications network has been the transfer of text messages between people using different computers. This "electronic mail" capability was originally grafted onto existing informal facilities; however, they quickly proved inadequate. A large network greatly expands the base of potential communicators; when coupled with the communication convenience of a message system, there results a considerable expansion to the list of features desired by users. Systems which have responded to these increased user needs have resided on medium- and large-scaled computers.
The Unix operating system, which runs on DEC PDP-11 minicomputer hardware, has not benefited from recent advances in network mail technology. This report describes some of the issues surrounding the design of such technology and specifies a system which transfers it to Unix. In the form specified, MS is intended to be an interim facility, having maximal utility for three to five years. In addition, the system is expected to provide a base for future generations of Unix message systems.
The MS environment consists of several pieces of software to compose, transmit, receive, review, and manipulate messages. Messages reside in file t'folders" and may contain any number of fields, or "components". The user can arbitrarily name, create, and modify these components. In particular, a draft message is provided for composing new mail and modification of old messages is allowed. The user is thereby given a relatively homogeneous and unrestricted environment for manipulating mail, although facilities for data-base management (filing and cataloging) and for personal tailoring of system behavior are relatively primitive.
The specifications in this report differ from the style of most system specifications; normally, either the way the system is to appear at its interface to human users, or else the range of primitive operations and "data objects" available is defined. Although they have more of the flavor of an interface description, the specifications here do not describe the precise way in which users formulate requests. That is, the functions, to be made available to human users, are described; however, the command language for invoking those functions is not. The reason for this idiosyncratic specification style is that several very different command interfaces are being constructed, and it is hoped that specification at this level will simplify the task of implementing them.
A number of features, normally reserved for user interfaces, are provided by the basic MS system; it is intended that these features will facilitate the design of interfaces to adequately respond to psychological aspects of using interactive computer systems and, in particular, that the appearance of the system will conform to typical users' cognitive models of a message-processing environment. This report includes discussion of these issues.
ACKNOWLEDGMENTS
This system description has benefited from the support of a large number of people. Many of the ideas in this document have been freely incorporated from those instantiated in existing systems, mentioned in the Introduction, and from a continuing set of discussions about message systems, which has taken place among more than seventy researchers distributed around the country and using ARPA Network message systems. In particular, Robert Anderson, Carl Sunshine, Stockton Gaines, James Gillogly (all of Rand), Steven Zucker (formerly with Rand), Stephen Kent (a summer Consultant from MIT), David Farber (University of Delaware), John Vittal (Bolt Beranek & Newman), and Kenneth Pogran (MIT) have reviewed and enhanced the original system specifications. William Crosby is the system's primary implementor, with Steven Tepper implementing the network, address, and initial conmand-specification software; both have been diligent at finding inconsistencies in and omissions from the original specifications. Sally Wallace, Grace Carter, and Lynn Anderson of Rand, and Cathy Koerner, formerly with Rand, were tolerant subjects for informal experiments conducted to select function characteristics for the system.
CONTENTS
• PREFACE
• SUMMARY
• ACKNOWLEDGMENTS
• FIGURES
• Section
• I . INTRODUCTION
o Background
o Framework for Using Message Systems
o An Operational Model
o Scope of Specification and Implementation
o Overview of MS Design
• II. SYSTEM FRAMEWORK
o Message Folders
o Message Components
o Message Creation
o Text Transfer and Structured Text
o Specification of Addresses
o Transmission and Receipt of Messages
o Sequence Specification
o Profile and More Structured Text
• III . FUNCTION DEFINITIONS
• IV . STATUS OF THE IMPLEMENTATION
• V . CONCLUSIONS
• Appendix
o A . SUMMARY OF FUNCTIONS
o B . SAMPLE COMMAND INTERFACE
o C . NON-EXISTENT OR DISCARDED TEXT
o D . A COMMAND INTERFACE SCENARIO
• REFERENCES
• FIGURES
o Sample MSG session
o Sample Shell session
o Sample MS session
o File and directory organization in Unix
o Relationship between data in MS
o Groups of messages (M) and components (C)
o Defaults for the Copy function
o Defaults for the Map function
I. INTRODUCTION
BACKGROUND
Time-shared computers typically have a system which allows their users to pass informal messages among themselves. As long as a computer is not connected to other computers, its community of users remains relatively small and geographically local, and its message system tends to remain relatively simple and used only for terse, infrequent communications.
The advent of the ARPA computer communications network (ARPANET) (Roberts & Wessler, 1970; Crocker, Heafner, Metcalfe & Postel, 1972) has dramatically changed such usage patterns. Message systems, coupled with a large network, result in a substantial pool of potential users who can obtain rapid delivery of messages (relative to the U.S. Postal Service) and an asynchronous interaction style which allows composition, transmission, receipt, and perusal at the convenience of each participant. The telephone allows more rapid delivery of information and an interaction style which often leads to greater effective bandwidth, but it requires participants to schedule contacts. It is therefore not surprising that a computer-based message system can fill an important niche in human communication and has become extremely popular with its community of users, replacing a substantial portion of normal mail and telephone activity.
Initially, the network communication capability was simply grafted onto existing intra-machine message facilities; however, growth in use of the facilities has led to considerable expansion of the list of features desired by users (Uhlig, 1977). For an introduction to the context and economics of electronic mail, see Vezza (1975), Vezza and Broos (1976), and Panko (1976).
The first integrated ARPANET-based software to gain wide acceptance for this type of "automated office" application was the BANANARD system (Yonke, 1975) and its successor, MSG (Vittal, 1975), written at U.S.C.'s Information Sciences Institute (ISI) for the Tenex operating system (Bobrow, Burchfiel, Murphy & Tomlinson, 1971; Myer, Barnaby & Plummer, 1971) which runs on Digital Equipment Corporation (DEC) PDP-10 hardware. MSG provides basic capabilities for creating, sending, viewing, storing, answering, and forwarding messages; its database management and message-revision functions are rather primitive. See Fig. 1 for an annotated scenario of a typical session with MSG.
Over the past several years, other message-system development efforts have begun; all attempt to provide a quantum improvement to the level of capabilities offered in MSG. Among development efforts, Stanford Research Institute's Augmentation Research Center (Engelbart, 1972), IS1 (Tugender & Oestreicher, 1975), Bolt Beranek and Newman (Myer & Mooers, 1976), and MIT's Dynamic Modeling Systems project (Broos, Black & Vezza, 1975) have been most noteworthy in the ARPA community.
2 INTRODUCTION
User first types the character after "<-"; MSG prints rest of word; may be repeated for qualifiers, such as "all messages". User's text is in boldface; comments are in the right column.
MSG -- version of 1 April 1976
The Unix time-sharing system (Ritchie & Thompson, 1974), which runs on DEC PDP-11 minicomputer hardware, has not benefited from these later developments and has had only an informally-developed system with capabilities at about the level of BANANARD. Rand has undertaken the design and development of a more complete and integrated message system, transferring proven message-system technology onto a minicomputer. This system, called MS (pronounced "mizzt'), was to provide capabilities at least equivalent to those of the MSG system and it has been designed to evolve to the level of state-of-the-art systems. The initial version of MS was to have a projected life-span of three to five years.
MS became operational at Rand at the end of 1976 and received limited distribution to other ARPA-project Unix machines by summer 1977. The system appears to provide a better framework for growth than was expected. It has been continually modified, as experience has uncovered deficiencies in the original design; no major problems have been encountered in effecting these changes.
Due to the evolutionary nature of MS, this document cannot be a definitive specification of all of the system's features. Therefore, a portion of the text is devoted to extensive explanation of the perspective with which design decisions are being made. Some of the perspective is the result of constructing MS after the ISI, BBN, MIT and SRI systems and reflects various of their characteristics. Since a message system is a complex environment, it is not possible to list those reflections accurately or completely. Attention also has been given to the importance of psychological and environmental factors in the use of interactive computer systems. While such social issues can be characterized globally, and the resulting basic design decisions can be discussed, it is not possible to explain all ways in which MS has been affected by these considerations.
FRAMEWORK FOR USING --USING MESSAGE SYSTEMS
As suggested by the sample MSG session in Fig. 1, messages on the ARPANET can be characterized as "memos". They are relatively structured and, since they must be represented in a single coding system (the ASCII character set), can have only one typeface, size, and color -- though it should be noted that the system or terminal used by the receiver of a message can (at least potentially) choose the face, size and color. At present, it is not possible to send drawings, facsimile, speech, or structured text. Such restrictions make ARPANET mail appropriate for most intra-organization and some interorganization communications. The ARPANET message environment is currently biased towards use as an informal communication mechanism but is being adapted for more formal activity. In normal offices, this combination represents a substantial portion of paper-based communication and can be expected to result in a considerable amount of computer-based mail-processing. Experience with ARPANET message activity by managers bears out this expectation. Even with somewhat restricted machinery, such as terminals which print at only thirty characters a second, it is not uncommon for a user to process twenty to fifty messages a day.
It appears that most users of computer message systems are extremely intolerant of idiosyncratic system behavior. They wish to use the system to communicate with other humans and do not want the computer--the communication medium--to intrude on that process. Curiously, this fact tends to apply even to those with a high degree of sophistication about computing.
This phenomenon also occurs with users of certain other tools, such as text editors. These systems augment rather basic human communication activities and require a kind of "intimate interaction," which can be characterized as sustained request/response sequences with most transactions involving conceptually simple actions by the computer and requiring between one-half and two seconds to complete. (Carbornell, Elkind & Nickerson, 1968). Much of this activity is characterized as requiring "routine cognitive skill" (Card, Moran & Newell, 1976).
Since the system is to be used for communication which is exemplified in older and heavily-exercised technology, it is assumed that users have an extensive conceptual model of the communication domain. It is further assumed that a system which performs in ways which deviate from that model will be viewed as "idiosyncratic" and impeding the efforts of the user. Problems occurring during this sort of interaction can be expected to be as irritating as having a pen which leaks or a typewriter with keys that jam. Therefore, a major design goal for MS is to provide an integrated set of necessary and sufficient functions which conform to the target user's cognitive model of a regular office-memo system. At this stage, no attempt is being made to emulate a full-scale inter-organization mail system.
AN OPERATIONAL MODEL
The scope of the MS project has not permitted empirical verification of the majority of its assumptions about the presence and characteristics of users' conceptual models for message activity. The project has had to rely upon the intuitive appeal of its assumptions and the degree to which other systems seem to succeed or fail in terms of their conformance and deviation from that model. Work by Heafner (1976), Heafner and Miller (1976), and others suggests that the model does exist and can be characterized. Work by Brown and Klerer (1975), Kennedy (1975), Walther, (1973) and Carlisle (1974) suggests that the degree to which a system conforms to users' expectations and abilities will have a significant effect upon their use of that system.
Because the system processes structured "memos", the basic unit of manipulation is taken to be the "component1'. A hierarchy is formed by having memos (or "messages") consist of collections of particular components, and "folders" as collections of particular messages. Messages have some common components, such as "To" , "From", and "cc" , but individual messages may have additional components with unique names. In addition, common names vary between contexts, such as the difference between business and military terminology. MS attempts to give users complete control over the naming and accessing of components.
A message assumes an identity as soon as any of its text is created. Over the life of a message, various actions may be performed on it. Some of these actions occur more commonly at certain phases than at others; however, this generally does not mean that these actions are prohibited during other phases. For example, a message is often revised before it is sent and rarely revised afterwards; but some revisions may occur, as when recipients make notations in its margins or when one recipient is part of a message "coordination" process and charged with passing a revised version of the message onto others.
Within an office environment, messages typically arrive at a person's "inbox", are viewed and perhaps acted upon, and are then filed into an appropriate folder which contains related messages. Later, the person may wish to take other actions relating to the material in the folder. All of this activity occurs on the person's desk. Several folders may be open at one time.
Two of the more common actions people take are responding to a message and forwarding a copy of it to others. In both cases, material in the original message determines portions of the new message. For responses, the title ("Subject") and the names of the originator and recipients are used; and for forwarded messages, only the name(s) of new recipient(s) must be added. Another common action is the creation of a new message for a third party.
When a comparison is made between the way these actions are normally performed in an office and the way they are performed using some existing computer-based message systems, several issues of operational styles surface:
1. Messages which are being created ("draft" messages) must be treated in fundamentally the same way as messages which have already been sent (and received);
2. A message may have "draft" status for an extended period of time, rather than being sent immediately after creation; and
3. Several draft messages may exist at one time.
The first point implies a more general issue: humans often do not make distinctions in the same ways as computers. For efficiency, a computer might handle a draft message differently than it handles "old" messages or that it might copy some kinds of text differently than other kinds. Humans, however, are generally not conscious of the conceptual distinctions which lead to these differences in handling. Imposing such distinctions upon users is another case in which the system will probably be classed as idiosyncratic and counterproductive.
The final way in which MS attempts to conform to users' expectations is in the vocabulary used to describe and invoke its processing. Concern for this level of detail has been questioned, on the theory that humans are quite good at learning new terms and, in fact, they are not consistent in their own use of vocabulary. That is, there probably does not exist a set of terms which is consistent among users and, even if there is, using that set rather than another will probably not greatly affect a user's performance with, or attitude towards, a message system.
In the belief that computer-oriented users and designers cannot be used as references for testing the presence and nature of such vocabulary in the potential user population, several informal experiments were conducted. Subjects were secretaries who had little or no experience using computers. In each case, relatively neutral language was used to explain a typical office situation which required use of a single word for referencing a particular object or action. The subject was then asked what word or symbol was most appropriate in that situation. In most cases, subjects immediately had a term they thought best and the terms were relatively consistent among subjects.
For example, a message being created is called a "draft"; the structured part of a memo is called the "headers"; and placing a message into a folder is called "filing". While such terms may seem trivially obvious, many message systems use terms which do not even approximate those offered by subjects. In fact, some systems use terms which have significantly different implications. For example, to "put" a message somewhere means that the original message changes location; however in some systems, the word is often used to cause an action which only places a copy of the message somewhere. It should be noted that, as Heafner (1976) has demonstrated, acquiring this sort of empirical data, in a methodologically valid manner, is relatively easy and inexpensive.
It is difficult to substantiate the claim that use of the most predictable vocabulary actually affects users' performance and attitudes. Except for that cited earlier, little research has been done to test the idea. It is noteworthy, however, that subjects in the informal experiment often reacted quite strongly when queried for certain vocabulary; their choices were so well-ingrained that they could not believe there was any question about their selection. Telling them of the terms used by some computer systems often evoked laughter. It seems to the author that such a reaction establishes a mental set which is quite likely to deter users from a system and cause them confusion when dealing with it. This is particularly critical during their initial use, since they will often already have enough difficulty becoming familiar with computer-related conventions and concepts that cannot be avoided.
SCOPE OF SPECIFICATION IMPLEMENTATION
This document, and the style of the resulting system implementation it specifies, is a bit unusual and deserves some explanation. Most system specifications address either the human interface or the internal design -- how the system appears to human users or what data structures and function primitives are to exist. The specification for MS is at neither level, although it has more of the flavor of an interface description. In particular, the document may be viewed as specifying the human interface, minus the command language. That is, the functions, to be made available to human users, are described; but the precise way in which users formulate requests to MS is not.
The reason for this idiosyncratic specification style is that several very different command interfaces are being constructed and it is hoped that specifying the system at this level will assist interface builders in realizing and accommodating some of the user issues described above. (The concern for proper vocabulary, therefore, is more representative of a lobbying effort than of a guarantee for what is to be provided in the command interfaces.) Experience to date suggests that the construction of interfaces is, in fact, simplified.
Three general-purpose interfaces have already been constructed. The first, described in Appendix B, is intended to be similar to the basic syntax of the Unix Shell (Thompson & Ritchie, 1975), which is the program that users employ to gain access to most of Unix's capabilities. (See Fig. 2 for a sample Shell session.) This choice was made because MS is intended for use on other Unices in other environments, and having a familiar command specification style was deemed more important than providing an especially "friendly" interface. Fig. 3 shows a sample session, using the Shell-syntax interface; and Appendix D contains an extended example of using this interface. The second interface constructed emulates the Unix "mail" command and is primarily intended for use by programs to send mail to users. The third interface emulates MSG, since MSG is a de facto standard on the ARPANET, with behaviors that are already familiar to many people.
In general, it is expected that users will be provided with a single command interface to the full message system, rather than be forced to deal with two or more different systems--for example, one program for creating and sending messages and another for reading and filing them. This should not preclude additional interfaces to subsets of the system, as would be appropriate if the user only wanted to send a message quickly. However, such programs should be strict subsets of the full system.
The level of the MS project effort has also had a major effect upon the system's design. To construct a fully-detailed and monolithic message processing environment requires a much larger effort than has been possible with MS. In addition, the fact that the system is intended for use in various organizational contexts and by users of differing expertise makes it almost impossible to build a system which responds to users' needs. Consequently, important segments of a full message environment have received little or no attention and decisions have been made with the expectation that other Unix capabilities will be used to augment MS. For example, MS has fairly primitive data-base management (i.e., filing and cataloging) facilities and message folders have been implemented in a way which allows them to be modified by programs, such as text editors, which access them directly, rather than through the message system.
Fig. 2-Sample Shell Session
Fig. 3-Sample MS session
OVERVIEW OF MS DESIGN
The original mail system on Unix was judged sufficiently primitive that compatibility with it was not attempted. For example, the structuring of folders that contain messages differs. Current Unix software which utilizes parts of the Unix mail facility therefore needs to be modified to use the new and improved product. Systems which merely create and then send messages need not be modified, since the mail-command emulator interface allows creation of mail in exactly the same way as is done by the old Unix mail system.
The MS message environment consists of several pieces of software to compose, transmit, receive, review, and manipulate messages and to tailor the message environment. In addition, there are file folders [*] which contain messages. Messages, in turn, contain any number of components. In accordance with the user issues discussed earlier, an effort has been made to make the system as homogeneous as possible. For example, messages which are being created by the user and messages which have been received are equally accessible. Most system functions have a number of options available. To allow users to indicate which option settings they typically wish to employ, a profile is planned for each user.
Users will normally deal directly only with the Shell-invocable software (see Fig. 2) and with the folders which contain messages. The process of Composing messages entails placement of text into the various components of a draft message. For example, names and addresses go into the "To" and "cc" components and the text of the message goes into the body. his ma^ be done repeatedly, allowing the user to employ a text editor to modify individual components. Transmission is an automatic process which packages the draft message to conform with ARPANET mail format standards (Pogran, Vittal, Crocker & Henderson, 1977) and delivers it into the mailboxes of all the indicated addressees. When receiving messages, the user may selectively -Show them at the computer terminal. Further manipulation of mail can involve Forwarding copies to additional recipients, Replying to its authors, Filing for later reference, Listing copies on a printer and/or Discarding (into the system's "wastebasket").
The messages in a folder are like a stack of messages in a normal office file folder; they are ordered and may be referenced by their index number (i-e., position in the folder). Any number of messages may be in a folder. They contain some number of components, most of which may consist of arbitrary strings of text. In some situations, batches of messages may be referenced; special labels are allowed for specifying them. At any given moment, the system has a current folder and a current message which are under scrutiny. (The standard folder is the inbox). Having them keeps the user from being forced to specify a folder and message index for every function. Contrary to most other message systems, most MS functions can operate on any component of any message in any folder, without requiring the user to respecify the current message or folder. Some functions cause the index of the current message to be changed; these are indicated in the functions descriptions, in Section 111. When the user invokes MS, the current message is set to be just before the first recent message, so that the user may conveniently sequence through recently-arrived mail, or to the first message in the folder if there is no new mail.
When a user issues a Shell command to start the message system, the standard action will typically be to Open a folder, where this folder will usually be the user's primary folder, the inbox. (See Fig. 3.1 This folder is structured like any other file which contains mail, except that new mail is placed there by the Unix mail delivery system. Current specifications call for mail to be delivered only to this folder; however, a later version may allow incoming mail to be diverted automatically to other folders, as might be appropriate to activities such as teleconferencing.
Modifications to processed messages (i-e., mail which has already been sent or received by the user) are allowed; however, in some cases, such modifications may cause the system to take note. Such exception-taking is intended only as a safety feature, as described below.
The system maintains a draft message, in its own folder. A message with "draft" status has not yet been Sent and is subject to more modification than other messages and therefore is not subject to normal access checking by functions. Current specifications allow only one draft message at a time; however there appear to be no problems in eventually permitting an arbitrary number of them. When a message is sent, a unique message-id, a timestamp, and the name of the sender are affixed if necessary.
The user can arbitrarily name, create and modify components. 'l-To" , W-ee" , and "Subject" are common components, but others are possible. For example, MS has a simple reporting mechanism, which allows users to send comments and complaints to the MS support staff. It automatically fills out the destination addresses and then prompts the user for the report. It also creates a component called "MS-Version" which allows the support staff to know what version of the system the user had. Such a component will not occur elsewhere, and users are given equally unlimited creative license to formulate their own component names.
Note that no program need know the names of all possible components. To facilitate user specification and manipulation, command interfaces typically maintain a list of the common component names, and the basic system is familiar with the required "Sender", "Message-Id", "Timestamp", and "To" components, as well as "cc" , "fCC" (file carbon copy), and "Subject", for the draft. Contents of these are verified or created by the system. With the exception of the first three of these components, all components of all messages may be modified, as described above.
Finally, any component may be passed to a program for manipulation. Formatting and typographical-error detection are two system-known programs. Others may be added, such as comparison of two versions of a message.
II. SYSTEM FRAMEWORK
MESSAGE FOLDERS
Unix organizes stored data files in a hierarchical fashion. Indexes to files and other subordinate indexes are called directories. The primary directory usually may be thought of as a filing cabinet. In a typical case, the secondary directories may be thought of as the drawers in the cabinet, and they may contain data files. Other organizational styles are possible and may become quite complex, as demonstrated by example C in Fig. 4 The simplest organization is to have only one directory and keep all files in it. Whatever the case, the user begins each session with Unix "looking at" an initial directory. If this directory contains another directory, called mail, then various standard MS files or folders are placed there. Otherwise, these folders are placed directly into the initial directory. Currently, standard folders are inbox, draft, and msreport and backup folders for draft and msreport; msreport is used by the Report function and will not be necessary when MS allows multiple draft messages.
MS folders actually consist of two Unix files. One is a clear, readable text file, organized in a fashion conforming to the ARPANET standard syntax (Pogran, et al. 1977). The second is a parallel file containing structure, status, and history information. Simple strings of special characters are used to separate messages in the "cleartext" file. If a message's format is violated, recovery is then quite simple, and the structural information in the parallel file is generally redundant and easily reconstructed. The structural information allows the system to manipulate messages and components efficiently.
This approach is in accordance with the concern for integrating MS into the general Unix environment and for allowing the user to have unrestricted access to messages, through other Unix word-processing tools which are already familiar, such as text editors and Shell commands. Separating structural information from the data also makes it convenient to have multiple "perspectives" (or indexes) to the data. The parallel file is normally hidden from the user so that he must only deal consciously with "real" message files.
Most text-transferring functions preserve the text in its structured, processable form. The List, Scan, and Show functions are notable exceptions and do not move the information in a form compatible with further processing as a message, since they completely reorganize the text into a single string. The Copy and Map functions can also perform this alteration, under certain circumstances.
As more systems come to manipulate message files automatically, the environment will have to distinguish between activity by humans and activity by their software agents. An example of this problem occurs when another computer program checks the inbox for certain types of mail, but the human still wants to be notified of new mail. Simply checking the length of the inbox file, or when it was last read, will therefore not provide an accurate indication of when the human last looked at the file. MS provides a solution to part of the problem: a folder may be opened with a passive status, so that no ' permanent actions can be performed on the folder. This capability allows automata to peruse and copy the contents of a folder, without leaving a trace of their activity in it.
A. Simple directory, with no sub-directories
B. Directory with 1 level of sub-directories (like cabinet with drawers )
C. Complex directory structure, with several levels Fig. 4-Examples of file and directory
MESSAGE COMPONENTS
As mentioned in the Introduction, a list of common component names is generally maintained and is used for defaults with certain functions; but such defaulting is only for convenience. At all times, MS allows modification to this list by the user, either through the Profile or at the time of creating specific components.
One of the pieces of information the system keeps about known component names is whether they are used to specify addresses. Including such a component in a message causes the message to be sent to those listed in the component. The user is able to control whether the contents of that component are included in the copy of the message sent to:
1. All recipients of the message; or
2. Other recipients named in that list; or
3. Only the author(s) copy.
This curious feature is derived from the concept of the blind carbon copy; the decision to provide so general a facility is due to a discussion with Stephen Crocker of ISI, during which the variety of distribution conventions followed by different organizations became evident. Rather than impose a single style of distributing information about who receives a message, MS lets individual users decide. The Profile allows users to alter which components are candidates for containing addresses (to be interpreted by the mail-sending process) and to alter the inclusion settings described above. In the case of the third option, a recipient's copy will show only his/her name in the component.
A more general facility would consider components to have a "data-type", with various attributes. For example, the above case would be of data-type "address" with a "distribution" attribute.
The system also allows specification of component equivalences. That is, a component name may be equivalent to some "generic1' name, as in the case of "Action-to" being equivalent to "To1' . This facility is necessary due to the amount of variety found on the ARPANET, in the (justifiable) absence of complete naming standards. The author favors this variety, since it is the only significant control the sender can have on message appearance and the labels often have differential import, as with military versus business memo terminology.
MESSAGE CREATION
Normally, the draft message always exists, and is in a standard message folder so that creating new message text, modifying it, and then sending it when ready can be done in a fairly natural and user-controllable manner. The Compose, Ned, @, Correct, and Format functions, in particular, are provided to facilitate the process, but the user may easily follow different creation paths with other tools.
As described earlier, three pieces of information (and possibly more, later) are not completely controllable by the user: message creator name, message transmission date, and message identification tag. The default is for the system to place the first two pieces of information into the From and Date components, respectively. If the user explicitly manipulates one, then its backup component (Sender or Timestamp) is created. Neither the backup nor message-tag components may be modified by the user.
While typing text into a component, users often need to be able to indicate places for other text to be inserted from files such as those containing documents. Although such an action is not handled by the basic system, it should be a feature in most interfaces. A more general capability would allow the user also to include text from other components and from the output of programs.
TEXT TRANSFER AND STRUCTURED TEXT
By definition, the core of a mail system is its ability to transfer text. When done between people or systems, this is message transmission. Individuals spend most of their message processing time transferring text within their own environment ("office" or "desk"). It is important, therefore, that this type of "local" text transferring be easy to perform. MS attempts to provide reasonable access to the functions that are most frequently useful for transferring text in messages which are on a "desk". There is little experience with unusual text transferring capabilities, such as "cut and paste" editing, which might be desired by users of a computer-based mail system; however, discussions and experience on the ARPANET have led to the conclusion that the range of desired functions is large and as soon as users can conceptualize a function, they want it very much.
A computer-based message system, like MS, must be able to transfer fundamentally different types of text "objects", such as components, document files, and user input. This makes it very difficult to characterize a conceptual space for a single, "generic" transfer function; however MS attempts the characterization with its Map function. The function represents another attempt to direct interface builders, so that appropriate consideration will be given to the psychological aspects of system behavior. This section analyzes the transfer domain and describes its parameters, as used by Map. Actual behaviors are described in Section 111, "Function Definitions."
The Map function represents an extreme attempt to provide the user with as integrated an environment as possible. It assumes that humans, in fact, are not aware of a distinction between transfers and , therefore do not want to be forced to make one. Experience with early versions of MS suggests that the Map function may be overly ambitious. The Add and Copy functions are provided to facilitate a subset of the transfer functions which are performed frequently. The File function also performs a transfer function; additionally it Discards the source version.
A distinction must be made between human behavior which uses the generic transfer function and the analysis which attempts to understand it; this is similar to the distinction between "performance" and "competence" which linguists make. The former appears to be common enough, normally, to be performed subconsciously, as indicated by the lack of "awareness" cited above; however, gaining an intellectual understanding of the process appears to be quite difficult.
Due to the difficulties in understanding the generic function, it may be useful to review the domain of activity. The MS message system interacts with a number of related entities. The basic computer entity, which can be manipulated, is a string of text, usually acquired from the user's terminal or from a data file which is not part of the message system. Within the message system, these strings of text are placed into various components of messages. A collection of these components may constitute a message and a collection of messages may constitute a folder. Messages and folders are said to be "structured" because they are made of discrete sub-wits. Fig. 5 shows the relationship between these entities.
Map is able to embody the several types of copying by using information about the source and destination to decide what kind of transfer to make. Because of the structural relationship between text entities, all text transferring may be viewed relative to components.
Four parameters of transferring are discernible:
1. Merging to a string: if more than one component provides source text, then whether to preserve their structural integrity, versus merging their contents into a single sequential string of text, e-g., a single component;
2. Merging to a message: if more than one message provides source text, then whether to preserve the exact structural relationships between the messages, versus mapping them into a single structure;
3. Naming: if the source is a component, then whether to preface the component's text with the component's name; and
4. Addition/Creation: whether the source is to be added to an existing structure, versus having it added to a . new one.
Fig. 5 -- Relationship between data in MS
The second alternative of the first parameter will cause transformation from internal message-system structure into clear text. The second alternative of the second parameter causes several messages to be merged into one. When the destination is merely sequential (clear) text, the third parameter determines whether the text will be "labelled" with the name of its originating component (e.g., "From", "Subject" or "To"). The fourth parameter primarily distinguishes between adding messages to a file and adding components to an existing message. Having text "added to an existing structure" can involve adding a message to an existing folder, adding components to an existing message, or adding text to the end of an existing component. In the first two cases, some new structure is also created, of course, but the focus is upon the act of adding.
If, at this point, it seems questionable that this degree of attention to such complexities is really necessary, it is worth remembering that if a person wishing to use one of these permutations does not find it available, s/he will curse the system designer for lack of foresight.
Some examples of the transfers which users are likely to want to perform, may help clarify the situation. Note that all text is transferred from a source and is appended to the end of destination(2) (components or folders), if they already exist:
1. The typical action of adding text, from a file or the terminal, to one or more components;
2. Merging the contents of existing components into a sequential string and then copying it into one or more components, as would be done when forwarding a message, by copying it into the body of a new message, or printing a message on a lineprinter;
3. Copying the contents of existing components into components of the same name, in another message of the current folder; this is a kind of "forms" processing;
4. Copying one or more messages to the end of a folder, that is, filing mail for future reference.
5. Copying one or more messages to the end of a sequential string (either a component or a document file), the logical next step, after performing step 2, above;
6. Merging components of several messages into a single message and then converting to a sequential format, as a formalized combination of steps 2 and 5.
_______________
Notes:
*Official names of MS functions begin with a capital letter and are underscored whenever used in this document; other official terminology is underscored when introduced. Names of message components are in quotation marks.
