human-nets@ucbvax.ARPA (05/17/85)
From: Charles McGrew (The Moderator) <Human-Nets-Request@Rutgers>
HUMAN-NETS Digest Friday, 17 May 1985 Volume 8 : Issue 17
Today's Topics:
Computers and People - An Electronic Communications wish list
----------------------------------------------------------------------
Date: 15 May 1985 13:10-EDT
From: Nathaniel.Borenstein@CMU-CS-ZOG.ARPA
Subject: LONG Communications wish list
ELECTRONIC COMMUNICATIONS: A WISH LIST
Nathaniel S. Borenstein
Jonathan Rosenberg
Information Technology Center
Carnegie-Mellon University
Pittsburgh, Pennsylvania 15213
This document describes everything we would like to see in an electronic
communication system. While we are making such a list as the first step toward
building such a system, the list should not be read as a description of what we
will ultimately build; rather, it is an attempt to define the ideal system, of
which we hope our actual system will ultimately be a reasonable approximation.
In trying to define this ideal system, we are asking the help of anyone with an
interest in electronic communication. We want to make our wish list as
complete as possible, so that we can begin our actual design with a very broad
idea of what electronic communication makes possible. All suggestions for
items not on this list would be gratefully appreciated. They may be sent via
netmail to nsb@cmu-cs-zog.arpa. (ITC members can send internal mail.)
Although netmail responses are preferred, you may also send us mail at the
physical address above. We thank you in advance for your assistance; we
anticipate that the volume of response will be too large to permit individual
acknowledgements.
THE BIG PICTURE
We imagine a system in which mail, mailing lists, bulletin boards, news groups,
and events calendars are integrated into a unified framework. Users should
have the option of treating bulletin boards and similar forms of communication
as either identical or separate from individual mail. We want to represent
messages in a common logical database; that is, it will appear to the user as
if there is a single database of messages, including his own mail and any other
forums of communication to which he has access privileges. Whether or not
private mail should actually be stored as part of the large database is an open
question.
RELIABLE DELIVERY
Reliable delivery is absolutely essential in an electronic communication
system; ideally, everything should be delivered as requested. Barring that,
the user should always be notified of any delivery problems.
FAST DELIVERY
Delivery should be fast; users should be able to quickly verify that messages
have been delivered to their destinations.
AUTHENTICATED DELIVERY
Delivery should be secure; authentication mechanisms should assure accurate
naming of the user sending the message (assuming, of course, that the normal
login procedures have been effective in establishing a user's identity). For
mail sent beyond the local network, a special header set should be provided to
help track the mail (e.g. to document where the mail originated and how the
original destination address was specified.) Sufficient information to
facilitate replies from remote sites should also be provided.
SIMPLE DELIVERY
Delivery should be simple from the user's end; in a multi-machine environment,
it should be necessary only to know a user's name to have the mail delivered to
the correct machine.
ROBUST DELIVERY
Delivery should be robust; when machines are not working, the system should
reroute mail around them or hold mail until they are working. The system
should be easily told by an individual to forward his mail to a certain
address, when his "home" machine changes.
EFFICIENT DELIVERY
The system should support efficient delivery of mail to large groups of users.
In particular, it should be possible even to send mail to every user of the
system without overloading the file system or the network.
VOLUME AND PERFORMANCE MONITORING
The system should be heavily instrumented to monitor mail volume and traffic
patterns, and to supply data about performance of the system at different times
of day and under other variations of the environment (e.g. network load).
THE COMMUNICATIONS DATABASE
All Communications should be stored as a database of messages, with appropriate
mechanisms for protection and access, in such a way as to support extremely
general schemes for classifying and relating messages. It should support the
efficient extraction of salient features of messages, such as the sender's name
or various classification features, without requiring expensive parsing while
the user waits. Basically, the database must be designed with the rest of this
wish list in mind.
MULTI-DIMENSIONAL MESSAGES
It should be possible to link messages together to create multi-dimensional
communication. For example, a message read by a large number of users may
generate a large number of responses, which are of interest only to those who
were interested in the original message. Replies to messages should be made
available on a "want-to-know" basis. Reply messages may continue a discussion
stimulated by the original message, or may simply comment on (annotate) the
message itself. Such annotations might be made publicly (as part of a public
message forum) or privately, for an individual's future reference. It should
also be able to relate two messages that are not replies to each other by
specifying "See-also" links between them.
CLASSIFICATION OF MESSAGES
Messages should be classifiable by any number of attributes. For example, a
classification "Emacs" might apply to any messages dealing with the Emacs
editor. The set of messages so classified could thus be viewed as a more
conventional electronic bulletin board on the subject of Emacs, but would be
far more flexible. Inappropriately classified messages could be reclassified,
and messages could efficiently appear in multiple classifications. The names
of message classifications should not be case sensitive. Associated with each
classification should be a "permanent" message, explaining the purpose of the
classification, who it is intended for, why it was created, and so on.
REVIEWS OF MESSAGES: MANAGEMENT OF INFORMATION FLOOD
A common problem with electronic communication systems like UNIX netnews is
information flood. This is the phenomenon whereby the sheer volume of
information discourages most users from reading any of it. In our ideal
system, this problem would be rendered more manageable by reviews of messages.
For any given topic, there are always some people who are strongly enough
interested to read a large volume of material. Any such individual should be
able to declare himself a reviewer, and to indicate, for each message he sees,
whether or not the message is worth reading. Other users would then be able to
specify any logical function of reviewers' opinions as a filter on the set of
messages they might be shown. Users would be able to say, for example, "show
me all the messages about Emacs that James Gosling thought were worth reading,"
or "show me all the jokes from net.jokes that either Lily Tomlin or Bill Cosby
read and thought were funny but that Bob Hope didn't like." Reviewers'
opinions might also be consulted in deciding whether or not a notice belonged
in a certain classification.
MANNER OF CLASSIFICATION
Messages can be classified in several fashions. First of all, the sender of
the message can specify how it should be classified, e.g. "this message is of
general interest" or "this message is for the 'emacs' classification". Second,
certain classifications may be defined to automatically classify messages by
key words, senders, or destinations (e.g. mailing lists from the outside
world). Third, mechanisms could allow after-the-fact reclassification of
messages. Certain individuals could be authorized to add or remove messages
from particular classifications, while system administrators might be given
such privileges for all classifications. Voting mechanisms might allow the
community as a whole to change classifications, and the use of the reviewer
mechanism in this context has already been mentioned.
It should be a simple matter to create new classifications; any user should be
able to create a classification and tell the world that it represents a
discussion group on a certain topic. The creator of a classification should be
able to specify certain parameters, e.g. who can and can't view messages in the
classification, but these specifications should be subject to simple revision
by the system administrators.
If it is possible for any user to create new classifications, it must also be
possible to merge classifications that should never have been separate. This
should certainly be within the power of the system administrators; it might
also be made possible to merge two classifications if some person or group of
people with dictatorial powers over each of the classifications agree to do so,
but the mechanisms for verifying this agreement could prove difficult to
implement without being cumbersome.
FLEXIBLE APPEARANCE TIMING: EVENTS CALENDARS
It should be possible to send notices to the community regarding an event in
the future, with the timing of the notice geared to the event rather than the
time of posting. That is, it should be possible to announce an event for May
14, and to have the notice appear to the users keyed to that date; users could
then choose to see notices that pertained to any time up to a certain date, in
order to preview events in a coming interval. What this suggests is a blurring
of the line between mail or bulletin board notices and event scheduling
(calendar) programs or reminder services. At the database level, at least, no
such distinction needs to exist; the user should have the option of viewing the
scheduling calendar as part of or separate from the larger database of
communications.
In addition to making it possible to integrate events calendars into the larger
communications database, it should also be possible to access such calendars in
several other ways. For example, it should be a simple manner to extract a
simple, one-page schedule of the week's event in a reasonable layout for
posting on a physical bulletin board. Similarly, the front end to the system
should be highly flexible; the dates for which events are scheduled should be
specifiable in a very broad input language.
CONNECTIONS TO THE OUTSIDE
A system such as the one wished for here would inevitably have many
incompatibilities with the communication systems in outside networks, such as
ARPAnet and usenet. Therefore it is essential that a clean gateway be
constructed. This gateway should take externally generated communications --
mail, ARPAnet mailing lists, UNIX netnews, and the like -- and convert them to
our internal format (store them in our database). For outgoing communications,
it should remove local dependencies and warn local users about features that
will not work with mail sent to the outside.
SECURITY OF COMMUNICATIONS
It is desirable to be able to make messages private or public in varying
degrees. Some messages should be unreadable by anyone but the recipient, some
should be readable by everyone, and some should be readable by all members of a
particular project or group of friends.
Anonymous messages are a thorny issue in most systems; aside from the fact that
it is nearly always possible to beat a system and send messages anonymously, it
should be realized that it is sometimes desirable and reasonable to do so --
for purposes of harmless jokes, for example, or for discussions about AIDS. We
suspect that facilitating harmless anonymous mail may discourage attempts to
break the system, and hence decrease the likelihood of harmful anonymous mail.
The mechanism we propose is pseudonyms. It should be possible to send mail
pseudonymously -- that is, with the sender's true name known and preserved by
the system, but not shown to the intended recipients. Since the name is
actually preserved, it will be possible to trace malicious or threatening mail,
and this possibility should help to discourage such mail. Meanwhile, the
pseudonym facility should facilitate frank discussions of private topics in
public forums. The system could even provide the possibility of two people,
communicating under pseudonyms, deciding to mutually reveal themselves -- that
is, to make their identities known to each other but no one else. Essential to
the scheme is the idea that mail can be sent to the pseudonymous author of a
message without the sender ever knowing that person's real identity.
EDITING AND DELETING NOTICES
It should be a simple matter to edit or delete a notice existing in a public
place. The author of a notice should always have the right to edit or delete
it. These rights should also be selectively grantable to appropriate
individuals; for example, one might desire to give library staff members the
right to edit notices classified as "library policy". System maintainers will
probably want the right to edit all messages, to allow them to act quickly in
the event that a truly inappropriate notice (e.g. publishing credit card
numbers or military secrets) appears as a public message. Reviewers (see
above) may wish to edit any notice they are reviewing; their corrections should
be seen automatically by people who accept their reviews, though not by others.
Finally, everyone should have a method of editing a message and submitting it
to the author for inspection, thus facilitating friendly suggestions for
painlessly editing messages. Also desirable would be a method where editing
could be performed by some kind of consensus or voting method, but the details
of such a scheme are far from obvious.
RETURN RECEIPT REQUESTED MAIL
Few people are trusting enough to believe that mail delivery systems always
work correctly, and those people who are that trusting are fools. Therefore it
is desirable to have confirmation when a piece of vital mail is delivered
properly. However, it seems a mistake to trust entirely in automatic
mechanisms for this purpose. Therefore we propose a special class of mail,
"return receipt requested mail". When a user sends this kind of mail, special
information should be encoded in the mail which causes the recipient's
mail-reading program to notice that it is "return receipt requested". When the
recipient asks to see the mail, his mail program should tell him that it will
only show him the mail if he agrees that is is OK to tell the sender he has
read it; in effect, he will have to "sign for it" -- he will have to
acknowledge its receipt. This acknowledgment will cause another coded message
to be returned to the original sender, stating that the mail was received by a
human on the other end. Meanwhile, the sender's mail system should keep track
of all unacknowledged mail of this type, and warn the sender of such mail when
an overly long interval has passed without acknowledgement. (The length of
this interval should probably be customizable.)
PARCEL POST
A very common way for mail systems to be used, though they were not designed
for this purpose, is to transmit files. Many mail messages consist of a line
like "Here is the program you wanted:" followed by the contents of a file. The
recipient typically has to write the contents of the message into a file and
then edit it to remove the extra, mail-related information at the top (and
sometimes even the bottom). "Parcel post" mail, however, could streamline this
process. Files could be shipped via the mail system, with state information
encoding the fact that that the mail is actually a file, with a certain default
name. When a user receives such mail, and asks to read it, the system should
instead tell him: "This is parcel post mail; is it OK to write it out as file
x?" Of course, the system should warn about any possible conflict of file
names, and it might also be desirable to make it impossible to write out files
which are directly executable or which have certain critical names (e.g.
".cshrc").
Another method for passing files around via mail might be to encode references
to files as part of messages. When a message is viewed, this information could
cause the mail system to ask "Do you want to see file x?" and to offer a menu
of actions regarding that file. This offers the advantage of not transmitting
long files as mail, but simply transmitting pointers to the files instead. Of
course, the files would need to be added on to the messages when they left the
local network, in order for non-local users to receive all of the related
information.
VARYING INTERFACE STYLES
Experience with past bulletin board and mail systems strongly suggests that
there is no "right" user interface for such systems. For a given such
application, there are usually a few distinct styles of interaction, and a
group of users that prefer each interaction style. In order to provide users
with the option of multiple interaction styles, most systems have ultimately
duplicated large amounts of program, data, or both. In an ideal system,
everything not related to the user interface itself should be provided via a
common set of publicly available subroutines. This should make it much easier
and more efficient to build several styles of interaction, and hence more
likely that the world of possible interaction styles is more fully explored and
implemented.
TRANSMISSION OF SPECIALIZED FILES
The system should support the transmission of specially-formatted files as mail
messages, even those in non-standard (e.g. non-ASCII) format. Most
particularly, in the ITC, the system should properly transmit base editor
files. This will allow messages to include complicated pictures, and perhaps
even, eventually, to make the candles flicker on the birthday cake that is
drawn on the screen.
USEFUL HELP SYSTEM
Any system that fulfills even a fraction of the wishes on this list will be
extremely complicated, at least with regard to the advanced features.
Top-quality documentation, and a help system that simplifies access to that
documentation on-line, should be provided.
SEARCH FACILITIES
Mechanisms should be provided to facilitate search through the database for
messages matching a particular specification, e.g. messages from Ronald Reagan
pertaining to the Strategic Defense Initiative. Such features will obviously
be highly database-intensive, and should certainly be among those features that
do not need to be rewritten each time a new user interface is designed.
PURGING AND ARCHIVING
A database of the size discussed here is likely to grow at the rate of many
megabytes daily. Obviously, not all messages can be kept on-line forever. The
system should be designed to regularly purge and archive old notices; these
notices should be backed up to a long-term storage medium such as magnetic
tape, and hence be available when they are really needed. Purging intervals --
that is, the amount of time a message is preserved before archival -- should be
specifiable for each classification, with a global default (probably something
like two months). A message should be purged when it is older than the purging
interval for all of its classifications.
MAILING LISTS
The system should support the compilation and use of mailing lists, for sending
private mail to particular groups of people. It should also be possible to
send mail in reply to all messages matching a certain specification, e.g. all
messages in a certain class, or all new messages except the one from Jim
Morris.
OTHER STUFF ???
The list above, though long, is undoubtedly incomplete. We would like to have
as complete a wish list as possible before we become too heavily involved in
the details of the design of a new system, which will include as many of the
wishes as possible. We will be very grateful for all comments and suggestions
to improve this wish list. Once again, we can not individually acknowledge all
replies, but will nonetheless be grateful for them. Please send all comments
to the net address or physical address given at the beginning of this document.
Thank you for your assistance.
------------------------------
End of HUMAN-NETS Digest
************************