Bob Dew <[EMAIL PROTECTED]> writes:
> But they're also migrating from AFS to DFS, aren't they?
Eventually, but we're migrating mail from AMDS to IMAP first.
> Maybe its not
> an issue here, but wasn't IMAP4 selected in part because of its built-in
> hooks for handling authentication ACLs?
The IMAP4 standard doesn't have built-in ACL's, we're adding them as
an extension.
> Has it been determined whether DFS will play any role in CMUs
> distributed mail project?
Yes; it has been determined that DFS will play no role in CMU's
distributed mail project. The IMAP mail store will be on the local
server disks.
>From a draft of a status report of the Andrew II Cyrus Electronic Mail
Project:
Use of a file system as the network access protocol for mail has
many drawbacks. AFS has not been implemented for Macintosh and DOS
machines. To support them, banks of translator machines were set up
with a special micro mail servers (mms) to make the mail in AFS
available to Macintoshes and PCs. The design limitations of the AFS
client and the AMS interactions with AFS made it necessary to have
more translator machines than actual file servers and performance
problems on the translator machines have been a continuous problem.
Using a remote filesystem as the network protocol for a mail and
bboard systems leads to many scale and availability problems. It is
important that network protocols designed for mail be used rather
than one for filesystems. Preferably,the mail protocol should be a
simple protocol to make implmentation of clients easier.
The core technology used by project Cyrus is the Internet Message
Access Protocol (IMAP4). IMAP4 specifies a network protocol for
accessing a remote message store from a client application. IMAP4 is
gaining increasing aceptance as the Internet standard for mail store
access. Many major universities, such as the University of Michigan,
are basing their future distributed mail solutions on IMAP4. IMAP4 is
planned to reach Draft Standard by mid 1994. The previous versions of
IMAP, IMAP2 and IMAP2bis which are backward compatable with IMAP4 are
already in widespread use. There are already clients in existence on
every major platform and many more in the works.
Unlike the other popular Internet mail protocols, POP, POP2 and POP3,
IMAP4 primarily describes a method of accessing a message store
where messages are retained on the remote server. The POP protocols
are primarily designed to act as store and forward engines. The
clients contact the remote message stores and download all their mail
to a local message store. For a population like students, this
difference is important. When the messages have been downloaded from a
message store to the client it becomes difficult to acheive the goal
of client mobility. Those messages are no longer easily accessable
from other clients. Even more important, many of the clients students
use have no permanent storage for their use. To get permanent storage
they must store the mail files in a remote filesystem. Storage of mail
in remote filesystems violates one of the goals of this project
because it can lead to many problems with scale and availability.
IMAP4 is a superset of the functionality provided by POP3. All the
functionality of a POP3 client can be mimiced using the IMAP4
protocol. The IMAP4 revision of the IMAP protocol adds support for
disconnected operation. This will allow for a client on a notebook
computer to download portions of a mail store and keep them
syncrhonized with the mail store over time.
One of the goals of Project Cyrus is to support the MIME internet
standard message interchange format. IMAP4 has rich support for MIME,
allowing the MIME structure to be examined without downloading the
whole message to the client and for individual MIME parts to be
downloaded. For example, if a MIME messages includes a 5meg audio
portion and your client does not support audio IMAP4 will allow all of
the message to be downloaded without that MIME part. This is also
important functionality for disconnected and slow link operation.
IMAP4 does not provide all the functionality needed for acheiving the
goals of accessing remote messages from multiple clients. There is
no mechanism for storing and reteiving client and user specific
information. When users move between clients it is important that
their profile information follow them. Even when they move between
machines and use the same client, their profile information must
follow them. One special type of user information is address books.
In addition they need a reliable mechanism to find what server
houses the folders they want to access including bboards. This is
especially true in a large environment where administrators may wish
to move users and bboards between mail servers in order to optimize
for performance and disk space.
Putting the missing functionality into IMAP4 would be overloading the
protocol with functions that are not neaded for purely accessing a
remote message store. Therefore, a sister protocol to IMAP4 has been
created which provide this missing functionality. This protocol, the
Internet Message Support Protocol (IMSP), provides three needed
functions; a central store of client and user option information,
address book storage and access, and finally a way to find folders and
their status from a central location.
The IMSP is very similar in structure and convention to IMAP4. This
should make implmentation of clients which support both IMAP4 and IMSP
much easier. A convention for naming options so that options common
to multiple clients can have a reliable name and to keep different
clients from stomping on eachother's personal namespace is established
with the IMSP.
It is the IMSP which really adds to functions necessary for scaling.
In order to ensure that the IMSP does not become a bottleneck or
single point of failure, provitions have been made in the protocol to
replicate the IMSP server.
