human-nets@ucbvax.ARPA (06/18/85)
From: Charles McGrew (The Moderator) <Human-Nets-Request@Rutgers>
HUMAN-NETS Digest Monday, 17 Jun 1985 Volume 8 : Issue 19
Today's Topics:
Computers and People - Re: Mail System Specs
----------------------------------------------------------------------
Date: 30-May-85 06:32 PDT
From: David Potter - McDonnell Douglas/AUGMENT Div.
From: <DAP.TYM@OFFICE-2>
Subject: Mail System Specs
To: nsb@cmu-cs-zog.arpa
Comment: Re your recent "LONG Communications wish list," this is a generalized
specification for an electronic mail system which we developed for internal
use. Not Company Confidential, though, and I thought both you and the Net
might find it of interest. Also, please feel free to forward my previous reply
to Human-Nets -- I neglected to do so myself.
-- David
GENERAL REQUIREMENTS FOR A COMPLETE ELECTRONIC MESSAGE SYSTEM
An Electronic Message System should:
* accept input from a wide range of terminals
* be easy to use, easy to learn, with logical and consistent commands
* handle short memos to very large documents equally well
* distribute and receive messages within its host computer, between other
such hosts, across networks, and between other message systems
* optionally, be integrated in a consistent manner with capabilities
provided by a comprehensive office information system
* provide features that aid the organization, archiving, and retrieval of
messages to support personal and organizational needs
* provide privacy and secure, long term storage of messages
* provide online help in addition to online and hardcopy documentation
* operate on reliable, cost effective hardware and be connected to one or
more nationwide/worldwide computer networks
* be able to handle millions of messages and many thousands of users and
user addresses as needed
SPECIFIC FEATURES OF A COMPLETE ELECTRONIC MESSAGE SYSTEM
Terminal
The message system must be easily usable by users with printing terminals
as well as those with display terminals. Full duplex ASCII terminals
must be supported.
User Interface
Basic functions should be prompt-driven.
Additional functions should be English command-driven, with menu command
selections optional.
Composing or Drafting Messages
Users should be prompted for required fields, such as:
To:
Cc:
Subject:
Message:
Send?:
Command mode should be available for designating optional fields, such
as:
Access Limited To:
Acknowledgement of System Delivery Requested:
Acknowledgement of User Receipt Requested:
Action (specified):
Addendum To:
Author:
Blind Cc:
Comment:
Delivery Timing Specifications:
Rush: (immediate)
Soon: (hour or less)
Defer: (Overnight)
Start Delivery (at date/time):
Stop Delivery (at date/time if not yet delivered):
Extend Access To:
File Copy:
From:
In reply To:
Keywords:
Part of:
References:
Reply To:
Route (in succession) To:
Pass (to next recipient):
Subcollections:
Submit To Library:
Editing Capabilities
Editing During Entry:
The following functions should be available during user text entry:
Backspace character, word, text, paragraph.
Retype line, paragraph
Current position indication
Continuous entry mode
Extended Editing Capabilities:
The following functions should be available for additional editing
operations:
Insert, Delete, Replace, Move, Copy, Transpose, Append, Break,
Sort, as appropriate, on entities such as:
Character, Word, Text, Visible Text Strings, Invisible Text
Strings, Paragraph, Groups of Paragraphs, Section, File, and
Message
Ideally, the text editor would facilitate the structuring of
information in hierarchical form, with commands provided for the
viewing of selected portions of messages (long messages may be
considered to be documents) according to their structure.
Accepting Prepared Input From Stand-alone Terminals
Users must be able to easily transfer pre-typed, formatted text from
stand-alone terminals to the message system.
Message Files
One primary file should be designated for receipt of messages. In
addition, other user-designated files should be available for placement
of messages as part of the users' message management operations.
Message Formats
Message formats must be consistent with required MILNET message format
protocols. This includes, at a minimum, adherence to MILNET-specified
required fields and addressing protocols.
Message Identifiers
Message identifiers must be unique for each message. Within the
identifier scheme, the number of such identifiers must be expandable to
at least 1 million unique messages.
Message Headers
Message headers should contain at least the unique message identifier,
the date the message was transmitted by the sender, and the text of the
subject of the message.
Message Fields -- Required and Optional
Required message fields should be kept to a minimum to facilitate use for
simple transmissions and use by relatively un-trained users. In
addition, there should be a wide range of optional fields available to
facilitate use of the message system for personal and organizational
information management.
Message Body
The user should be able to place up to 300 disk pages of information in
the message body field. The user should be able to format the message
text in any manner desired, using the editing commands available in the
message system or commands accessible in a more comprehensive system with
which the message system may be integrated.
The full text of the message should be delivered to all recipients except
where limited distribution is specified by the sender. In those cases,
the full text of the specified message should be available as recorded
messages in the library. In such cases, only header information and
other necessary fields, such as the location of the library copy of the
full text, would be sent to the addressees.
Message Categories
User-named message categories should be able to be created by commands so
that users may store messages in ways that meet their own particular
needs for later retrieval and review.
Message Drafts
The message system should enable users to prepare drafts of messages that
may be sent at a later time. These drafts of messages should be stored
for future use and should be easily accessed, further edited if
necessary, and sent in the normal manner.
Users should be able to add or delete optional fields, edit existing
text, or enter new text at any stage of the message preparation process
after supplying the text for required fields.
Pre-specified Message Forms
The message system should provide the capability for users to prepare
message forms in advance for later input to the message system. Any or
all of the optional message fields should be part of such message forms
and should be selectable and ordered at the user's option. Upon each
user submission of a message form to the message system, the system
should prompt for any fields that contain no pre-entered data and should
complete the message sending process in the normal manner.
Blank Entries In Fields
The message system should accept blank entries in all fields other than
the required fields that must contain entries. Fields omitted from the
message should be considered to have been designated as blank by the
sender.
Message Privacy
Each message should by default be private to and viewable only by the
sender, the recipients of the message, and others designated by the
sender.
Signatures
The system should facilitate the verifiable placement of "signatures" on
messages and documents where appropriate.
Spelling Correction
The message system should provide the capability for users to check and
correct the spelling of text in messages. This should be available in
both interactive and "batch" modes and accessible within the message
system or optionally accessible within the overall office information
system if such exists.
Identification System
The message system should have an extensive Identification system where
all relevant information about each user and his/her address is stored.
This information should be accessible to the message system for
verification and distribution purposes and to users to support the
addressing process.
Looking Up User Identifications/Addresses
Users should be able to locate and view specific user information on the
basis of: individual identification codes, last name, and Soundex text.
Distribution Lists
Users should be able to prepare their own distribution lists and submit
them to the message system for use in message distribution. In addition,
the identification system should provide the capability for users to
designate "official" list names and associated user identifications as
distribution lists.
Verifying Distribution Lists
The message system should verify all addresses in distribution lists (for
the message system) and inform the sender of any non-valid addresses
specified and the fact that those particular messages were not delivered.
File Copies
The message system should enable users to specify a file or files where
copies of selected messages will be placed by the message system for file
purposes.
Message Distribution System
The message system should provide a process that is continually available
for the distribution of messages to their proper destination including
messages addressed intra-host, cross-host, or inter-network.
The distribution system should be capable of making repeated attempts to
forward messages and when delivery is not possible, should notify the
sender of the non-delivery.
The message system should be able to re-format certain messages so as to
adapt to the required formats of other approved message systems.
Passing Messages Along the Approval Chain
The message system should support the organizational approval process
(where needed) by providing the capability for the sender to specify the
succession of approving recipients. The system should facilitate
subsequent approvals and the further distribution of messages along the
route. The system should also permit parallel information copies of
messages.
Permanent Recording of Messages -- a Library
The message system should provide the capability for users to send
messages and longer documents to a library for permanent recording and
later retrieval.
User Profiles
The message system should provide users with the option of setting
available options relative to their particular terminal and customary use
of the message system to be the default mode for their own use. These
options should be changeable by users as desired.
Receiving Messages
Users should be notified that they have new, un-read messages upon login
to the system and whenever they specifically request such information by
issuing the appropriate command.
Message/Header Selection
Each message in each message category should be assigned, in addition to
its permanent unique identifier, a temporary message number that can be
easily used to select messages for reading, printing, and message
management operations. Such numbers would preferably be from 1 to n in
each category, depending on the order and number of messages in the
category at any point in time.
Users should be able to print or display only the message headers in
selected message categories.
Reading Messages
New message headers should be presented to the user upon entry into the
message system. The user should be able to select and read messages
easily whenever desired. Single messages, groups of messages, or all
messages in a message category should be selectable by command. Users
with display terminals should be able to view one screen at a time if
desired, continuing to view subsequent screens when ready.
Accessing Recorded Messages
Users should be able to easily locate and read messages that have been
recorded in the library, after receiving notification of such messages
through the normal message distribution process. Recorded messages
should be viewed or copied only, but should not be able to be changed by
users.
Answering Messages
Users should be able to answer messages by command selection of such
messages and be prompted for required fields where needed identifier and
addressing information is not already known to the system. The entire
set of optional fields should be available for use in such replies even
if not used in the original message. Users should be able to specify
distribution of the answering message as being the same as the
distribution of the original message, just to the sender, or to any
additional addressees.
Forwarding Messages
Users should be able to forward messages by command selection of such
messages and be prompted for required fields where needed identifier and
addressing information is not already known to the system. Users should
be prompted for any comments they wish to append to the forwarded
message. Users should be able to specify distribution of forwarded
messages to any desired addressees.
Identifying Foreign-system Messages
Messages received from other message systems should be assigned unique
message identifiers consistent with the identifier scheme of the message
system. In addition, any foreign-system message identifying information
should be retained for possible use in answering and forwarding
operations.
Answering/Forwarding Foreign-system Messages
Users should be able to answer or forward messages received from foreign
message systems in the same manner that they would perform such
operations on messages originating within their own message system. Such
answered or forwarded messages should be distributed to selected
addressees within any recognized message system, including the systems
from which they originated.
Printing Messages and Optional Formatting
Users should be able to print single messages, groups of messages, or
entire message categories on a variety of printing terminals.
Messages should be formatted exactly as received or, optionally, in
special user-designated formats under the control of integrated print
formatting functions that may be available to the users.
Message Management
Users should be able to delete or move single messages, groups of
messages, or entire message categories as they wish. Users should be
able to undelete messages if desired unless the they have requested that
the system (by command or profile setting) permanently remove them from
the file.
Searching for Messages
Users should be able to view or print a list of category names, message
headers in any category, or view or print headers or the full text
messages on the basis of text strings contained in the To, Cc, From, or
Subject fields. User should be able to specify single messages or groups
of messages.
File and Directory Management
The message system must provide the user with the ability to list
information about any or all files in his or her directory, viewing such
file information as the times and dates of: file creation, last write,
and last read, as well as file protection status and file size. Such
information about other users' files shall also be available, subject to
file protection features.
Library Functions
Users should be able to place selected messages in a central library for
permanent storage with access restrictions specified by the user placing
such items in the library.
Each message or document entered into the library should be protected
from future changes and all relevant reference information should be
entered into a user-accessible catalog. Future reading of such catalogs
should take into account specific file privacy protection settings on a
message by message and user by user basis.
Library documents should have a common default print format for
uniformity in printing. Users should be able to enter additional
printing format specifications as they wish prior to submission to the
library.
The full text of all messages and documents must be contained in the
version submitted to the library. However, at the sender's option, only
relevant reference information may be delivered to people listed in the
addressee fields.
The library should be open-ended, providing for both online disk and
offline long term archival tape storage.
It should be possible for various sub-units of an organization to create
separate and private libraries and their corresponding catalogs as
required.
Searching for a Document Using the Library Catalog
Users should be able to locate documents or messages filed in the library
without knowing precisely where they are filed. Users should be able to
search through the library catalog(s) on the basis of several different
criteria or Boolean combinations thereof:
Message subject
"From" Field
"To" field
Keywords (sender-assigned)
Date (or range of dates)
Other message header fields
This catalog-searching capability, which should be accessible to the user
via a simple keyboard command, should search through the catalog and find
citation that match the user's search criteria. Users should be able to
further specify whether the search is case dependent or independent.
They should also be able to specify that the specified text be searched
for anywhere in a field or as the first word or words in a field Boolean
connectors should also be available -- e.g., use of the words "and" and
"or" to combine searches, and the word "not" to negate searches.
Examples of Searches:
Subject "Standards and Procedures" AND From "RBJ.NYSNET"
This search would match all citations with the exact text
"Standards and Procedures" as the first words in the Subject field
and with the uppercase text "RBJ.NYSNET" as the first word in the
From field.
From "ELT.NYSNET" OR From "ADAMS@MIT-MC" AND Subject ~ ["proposal"]
This search would match all citations with the uppercase text
"ELT.NYSNET" or uppercase text "ADAMS@MIT-MC" as the first words in
the From field that also contain the text "proposal" somewhere in
the Subject field.
From "SRK.NYSNET" AND Subject ~ ["library Searching"] AND Posted
Between July 21, 1983 July 30, 1983.
This search would match all citations with the uppercase text
"SRK.NYSNET" as the first word in the From field that also contain
the text "library searching" in the Subject field, and that were
posted between July 21, 1983 and July 30, 1983.
Integration and Consistency with Other Office Information System
Capabilities
It is preferable that the message system be integrated into a
larger-scale office information system. If so, message system commands
must be consistent in presentation, wording, and action with other
commands in the system. Any appropriate command in the overall system
should be available for use at any point in message system operation.
Any information in any file accessible by the sender should be available
for incorporation into message fields.
Online Questionmark and Help Features
Users should be able to see a listing of all commands immediately
available for use at the next stage of their command specification,
preferably by typing a question mark. Display terminal users should be
able to indicate their next command by cursor selection directly from
such lists.
Online "Help" files should be available and easily accessible at each
stage of every message system command. This information should define
the user's command state and offer references to relevant information
needed to help determine the next appropriate command. Users should be
able to proceed as far down the command chain as needed.
The user's command state should remain as it was before requesting Help,
so the user can continue to specify commands from that point.
Hardcopy User Documentation for Beginners and Advanced Users
Documentation in hardcopy must be available in various forms to assist
both beginning and more experienced users to use the message system.
Such documentation must be consistent in style and content with online
documentation, including the Help information, and should be presented in
an logical order and format that facilitates both comprehensive learning
and specific information lookup.
------------------------------
End of HUMAN-NETS Digest
************************