lgl@cac.washington.edu (Laurence Lundblade) (08/07/90)
Here at U of Washington we're doing some work with IMAP, mostly
writing clients. You probably know that IMAP (Interactive Mail Access
Protocol, rfc1064) is similar to P7, particular in it's reason for
existence. One of the advantages is that the user may read his mail
from different PC's since it is all stored in one central place. He
may use one PC when in one office, and a different PC from another
office, and some other client when dialed in from home. It seems that
users won't be able to switch client CPUs so freely when clients begin
storing things, such as an address book, on the local CPU. The user
would have to manually maintain consistency between address books on
all his client machines. The reason a mailer might store things on the
client machine is because P7 doesn't provide any means to store it
on the server. I haven't got a hold of the X.400 docs yet and it's
going to be a while, so I thought I'd ask here if P7 has any features
for storing other state on the server, in particular, an address book.
(or could this be in X.500??)
A second request is for details on how the MS works. Does it store
messages in different, named, mailboxes or folders? Does the protocol
support getting a list of the names of these mailboxes or folders?
Thanks..
--
Laurence Lundblade 206-543-5617
lgl@cac.washington.edu
Networks and Distributed Computing, U of Washington, SeattleS.Shaw@edinburgh.ac.UK (08/08/90)
> Subject: P7 question > From: Laurence Lundblade <lgl@edu.washington.cac> > .... so I thought I'd ask here if P7 has any features > for storing other state on the server, in particular, an address book. P7 does not provide any means for the UA to initiate the storage of any information on his Message Store (other than by sending himself a message, or the use of certain registration services). So he cannot store a draft message nor a copy of a submitted message nor an address book (though all three are desirable). > A second request is for details on how the MS works. Does it store > messages in different, named, mailboxes or folders? Does the protocol > support getting a list of the names of these mailboxes or folders? The short answer is that the MS provides only a single, flat store for holding delivered messages, identified by sequence number, with no facilities for partitioning messages into groups. However, there are proposals before ISO and CCITT to extend the functionality of the MS in order to satisfy a more realistic set of user requirements than the current standard addresses. Some background information might be useful. Essentially, the 1988 Message Store was intended to overcome the problems introduced by the P3 protocol. The main problems are: o P3 assumes that UAs are always available to take delivery of messages at the convenience of the delivering MTA. (The hold-for-delivery mechanism was intended to operate exceptionally, and only for very limited periods.) Whenever the user's workstation is not operating as a UA then messages arriving at the MTA may be declared undeliverable. o The UA cannot control the delivery process. It is not possible to select which queued message should be delivered next nor to decline the delivery of an unwanted message. o The user cannot access his message database from a remote location. Messages stored on your office PC's disc are not accessible in an 'open system' sense. The MS has solved these specific problems. Where it falls down (in my opinion) is in its limited scope. This is to act as a temporary 'in-tray' rather than a longer-term store for messages. Hence it does not support basic services such as the storage of messages upon their submission, and message folders. Proposals for extending the functionality of the MS (to support folders, storage on submission, auto-filing, auto-correlation, auto-purge etc.) are under active consideration within the standards organizations at present. However, in a recent ISO ballot seeking approval for proceeding with the work on these extensions the USA and Germany cast negative votes. The reasons given were that a separate document storage facility such as DFR should be used for the long-term storage of messages. This is superficially attractive, but leads to a whole new set of problems for the UA: o The UA must employ two access protocols to reach all its stored messages. o The UA cannot invoke the same operations on both the MS and DFR-store as the access protocols of each supply different operations. The operations which can be applied to a given message depend on which store it resides in. o The UA cannot present the user with a single information model of the message database since two applications are involved which employ different models. o The MS provides facilities which recognize the dynamic nature of messages (notable the auto-actions) whereas DFR treats documents as static objects. The proposed extensions for auto-filing and auto-deletion cannot be grafted on to DFR. Any supplier who wants to base a UA product on a combined MS-access/DFR-store access model is free to do so. But preventing the development of the MS extensions outlined, looks to me like a death sentence for the MS. I dont see it surviving where it requires an additional DFR-server to satisfy quite modest user requirements. After all, there are other ways of supplying UA services which dont depend on the use of the MS. Since this is still an active issue within ISO, anyone with an interest in this topic should raise it within their national standards organization. A final meeting to decide whether to go forward with MS extensions is due on the 6th December and written contributions from ISO member bodies would help in reaching a decision. Sandy Shaw Edinburgh University Computing Service
pays@mars.emse.fr (Paul-Andre Pays) (08/08/90)
I regret (for Sandy SHAW) to state that I support the US and german position...
ie. to limit the MS to its present scope
The MS is not meant to be the storage for an advanced user mailbox, but just to
serve as you mentionned it as an "in-tray".
There is no reason to define and limit all the facilities that a specific
user mailbox will offer; it depends greatly on the context eg. office automation
research environment, more formal commercial environment...
Thus le P7 MS is NOT the mailbox, just a temporary storage
for messages to be delivered to a user.
We must stop consider it for what it was not meant to be
and concentrate at defining the features of a nice mailbox... for which
it could be wise to use a commonly accepted FR protocol, such as DFR
if (and only if) suitable and appropriate...
- pap