Path: utzoo!attcan!uunet!samsung!usc!orion.oac.uci.edu!ucivax!gateway From: S.Shaw@edinburgh.ac.UK Newsgroups: comp.protocols.iso.x400 Subject: Re: P7 question Message-ID: <07Aug9014:47:46bst170322@EMAS-A> Date: 7 Aug 90 17:10:26 GMT Lines: 85 Approved: usenet@ICS.UCI.EDU In-Reply-To: Your message x-attn: jns > Subject: P7 question > From: Laurence Lundblade > .... 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