%%This is latex
\documentstyle[11pt,twocolumn]{article}

\begin{document}

\section{Introduction}

One of the most useful purposes computers and computer networks serve
is aiding communication among people.  More and more experience is
being gained in this area of computer use, and while such communication
has some problems and certainly differences from traditional oral and
written communication, it is not premature to declare victory.  At the
same time it is important to look at different types of electronic
communication to explore the needs they meet (or fail to meet) with an
eye toward what improvements remain to be made.

\subsection {Types of Electronic Communication}

If we exclude from electronic communication telephones, fax machines,
real-time video and voice conferencing and the like, electronic mail
is the most widely known and accepted method of electronic
communication found.  Using a well understood metaphor, that of the
postal service, even unsophisticated users can pick up the basic
concepts without much effort.

E-mail, as it is known, is generally
batch oriented, and like the postal system mail flows from one user to
its recipients.  Each user has some mechanism for retrieving his new
mail (checking his mailbox) and for posting his mail for later
delivery (dropping it in the outgoing mailbox).  Mailing lists exist
and facilitate communication with large numbers of people interested
in the same topic.  Each member of the list receives a separate copy
of each message sent to that list.

Interactive messages have proven quite useful.  Unlike e-mail they are
used only when the sender and recipient are both logged in.  Instead
of waiting for delivery whenever the mail system gets around to it,
they are usually delivered at once and displayed immediately on the
receivers screen in some fashion.  Interactive activate messages are
useful for short, real-time queries ("When do you want to leave for
the movie?  Do you know where the source for discuss is?").   Such
message systems are most effective when they take advantage of large
computer networks
\footnote{is it really the rendevous function that is important?}
[ref talk and zephyr], but single machine systems
are still useful [reference out of the box bsd write].   [Should the
difference between talk/chat and a zwrite style be mentioned or is
this already too much detail?] \footnote{shouldn't interactive messages
come before e-mail?}

Electronic bulletin boards (or bboards) allow users to "post" messages
in a place which other users may peruse at a later date.  Just as with
real-word bulletin boards, bboards generally are restricted to
specific topics and have a large number many readers, frequently in
the hundreds for dial in micro-computer based systems, or thousands
for the UUCP based netnews. [reference some netnews document] The
readers of a electronic bulletin board be scattered throughout a
state, country, and even the world, since once posted a message may be
transmitted to other systems which store local copies for their users.
They may also choose to forward the message to yet another computer.
Messages frequently expire after a few days or weeks, depending upon
the disk space resources of the system or systems involved.

Electronic conferencing, which is subtly different from bboards, is
designed for a smaller number of users, frequently with privacy
concerns, and with long term archival requirements.  Not only do
conferencing systems allow users to communicate with others interested
in particular topics, but they prevent unauthorized users from reading
such communication.  For example, the Professors and teaching
assistants running a course might want to discuss possible quiz
questions, but be confident that students would not be able to read
their conversations (at least until after the quiz!).  Also there is
frequently a requirement to retain the discussion for a long period of
time so that people joining the organization at a later date may
come up to speed by reading what has gone before.   While conferencing
systems may have bboard like facilities to 
periodically purge older entries and they are easily used for archival
purposes and have more advanced mechanisms sorting through older
entries.

In contrast to e-mail the entries are stored in one place so
the user need not know all the people interested in his message.
Those interested will go to the message, rather than the message
coming to them.  Most importantly this allows other people to later
decide they are interested in the message and to access it as they
would any other message in the conferencing system, rather than having
to hunt around for possibly non-existent saved mail archives.

\subsection{The Distributed Services Environment}

MIT's Project Athena is an
example of a computer utility based on the [a?] distributed services
model of computation.  [reference the "athena paper", perhaps Win's as
well as Jennifer and Dan's latest] Athena has order of magnitude 1000
workstations (of several different types) scattered around campus, in
locations ranging from public terminal rooms, to private offices and
living groups.  Workstations and servers are connected by a high
speed network.  Each workstation has a moderate sized hard disk
used for storing essential software and for swap space.  Most system software
and user files are obtained from remote file servers.  The location of
both the system software and a user's filesystem are determined by a
network name service called {\it hesiod}.  Authentication, essential
because the network is unsecured and public workstations are under
total control of it's current user (the root passwords are even
published!), is provided by the {\it kerberos} network service.
Electronic mail service is provided by a central mailhub, responsible
for re-writing the headers in order to present a unified address-space,
and for distributing messages for internal users to a post office
server.  Users can retrieve their mail from their post office server,
located using {\it hesiod}, via the Post Office Protocol modified to
use {\it kerberos} authentication.  The {\it zephyr} notification
system provides delivery of interactive messages from users to other
users or from service providing processes to users requesting
notification.  {\it Zephyr} also makes use of {\it hesiod} to find
its servers and of {\it kerberos} to provide authentication of messages. [SMS?]

The MIT {\it Student Information Processing Board}, a volunteer
organization dedicated to better student computing at MIT [maybe we
need to write a paper about the SIPB???], undertook the task of
developing an electronic conferencing system for this environment in
1986(?).  Much of {\it discuss} came out of the SIPB's experience with
the {\it Multics} conferencing system {\it forum} and a desire to see
it extended beyond a single machine environment.  The part-time
efforts of Stan Zanarotti, Ken Raeburn, and Bill Sommerfeld, have
resulted in a solid production level system, which has been adopted
for by Athena's System Development and User Services, and portions of
MIT's Laboratory for Computer Science (LCS).  SIPB, Athena, and LCS
run {\it discuss} as a network service for themselves and the MIT community.

This paper will talk about the design choices and implementation
lessons learned during the development and initial deployment of {\it
discuss}, particullary those which are important in a distributed
computer environment.  We will start with the basic model of a {\it
meeting} which is the foundation of {\it discuss} and follow with a
description of the currently implement user interfaces.  Then the
client/server model will be explored along with the communication
issues caused by such a split in duties.  Next the topic of
authentication and authorization will be covered, showing how {\it
discuss} builds on {\it kerberos} to provide authentication, but develops
its own application level authorization scheme that is required by a
conferencing system.  User notification of new transactions using the
{\it zephyr} notification system will be covered along with its
interaction with access control.  Finally, we will talk about the
implementation lessons learned and of the future of {\it discuss}.

\section {Electronic Meetings}

Meetings are the central concept in {\it Discuss}.  Users attend a
set of meetings, just as you might attend a regular set of face to
face meetings.  For each meeting you attend you listen to what other
participants have to say, and you can contribute as you wish.  However
unlike face to face meetings, not all the participants in a {\it
discuss} meeting need be present at the same time.  And of course they
need not even been geographically close either, as long as their is a
network connection between the user and the machine on which the
meeting is stored.

Meetings are sets of transactions.  Each transaction is labeled with
the author (unless the author wishes to remain anonymous), a subject,
the time it was entered, and a unique transaction number.  The
contents of the transaction are stored as uninterpreted eight bit
data, though the only existing client user interfaces are only
prepared to receive ASCII text.  Discuss keeps track of which
transactions a user has seen and has the ability to only display transactions
which are new to the user.  

Replies are treated specially.  When a user replies to a given
transaction the subject of the reply is "Re: original transaction
subject", but more importantly a pointer is associated with the new
transaction which indicates which transaction is the
original.   The original transaction also has a forwarding pointer to
the reply.  In this manner a chain of transactions can be created and
easy walked through.  If one replies to a transaction in the middle of
a chain, discuss simplifies the pointers by pretending that you have
replied to the transaction at the end of the chain.  Each transaction in
a chain has a previous reference ({\it pref}) and a next reference
({\it nref}), except for the first ({\it fref}) and last ({\it lref})
transactions in the chain, which only have a {\it nref} or {\it pref},
respectively.  [This is a fine place for a pretty picture.]

Transaction numbers are assigned in a strict order, unlike the {\it
notes} conferencing system, and unlike the {\it netnews} bboard system
they are consistent for all readers of the meeting.  Replies are
simply given the next transaction number and threaded to produce a
chain as described above.  If transactions are deleted, the
transaction number namespace is left unchanged, thus not every
transaction number need correspond to an existing transaction.

Entering a message in more than one meeting and having the ability for
the user to only see the message once is not supported. [Can't tell who
has seen a given transaction.  Privacy and no server side state.]

\end{document}