Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!ucivax!gateway
From: S.Shaw@edinburgh.ac.UK
Newsgroups: comp.protocols.iso.x400
Subject: Re: UA under '84 X.400
Message-ID: <13Dec9010:31:20gmt170984@EMAS-A>
Date: 14 Dec 90 08:30:03 GMT
Lines: 53
Approved: usenet@ICS.UCI.EDU
In-Reply-To: <554167*JPALME@QZ.qz.se>
Autoforwarded: true
Comments: Apologies to those wo have already seen this. I've been advised that
          the redistribution of the original message was incomplete.

>  The P3 protocol is a protocol where the MTA more or less
>  automatically downloads all new messages to the UA.
>
>  In the P7 protocol, new messages are stored in a database,
>  from which the UA has some control on in which order to
>  download new messages.
>
>  The 1984 version of X.400 only had P3, while the 1988 version
>  also has P7.

There were two main reasons behind the development of P7.  The first was the
implicit assumption in P3 that the UA would be available to take delivery of
messages as required.  The MTS was conceived as a transfer medium and offered
only limited services for spooling messages awaiting delivery (the
hold-for-delivery service).  If the UA was not available (powered-down or
running another application) then the MTS would be unable to deliver and would
declare non-delivery after a relatively short period (as little as 10 minutes).
The development of the Message Store solved this problem of UA-availability.

The second problem with P3 was the fact that the user had little control over
which messages were delivered, and in which order.  Again the MS provides
sophisticated selection and retrieval mechanisms which enable the UA to
exercise control over the information retrieved.

Unfortunately, while these problems have been solved, the requirements of the
end-user have still not been satisfied.  Essentially, there is no standardized
protocol which allows a UA to access a managed store of messages.  The
role of the 1988 MS is limited to that of a temporary in-tray, designed to
hold delivered messages and reports in an unstructured store.  This leaves the
problem of providing a longer-term/higher-volume store for submitted and
delivered messages as a local UA function.  Detailed proposals for satisfying
this requirement for standardized access to a managed store of messages are
currently before ISO and CCITT.  The general approach is to extend the MS to
act as a structured store and to allow for the storage of submitted messages.

These proposals have encountered stiff resistance from DIN, who argue that
there is no significant user requirement for the long-term storage of complete
messages.  Rather, it is argued that a requirement exists for the long-term
storage of documents which have been transmitted by means of MHS.  Under this
approach the UA retrieves a message from the MS, discards the envelope, and
stores the documents it contains elsewhere (e.g. in UA local storage or in a
Document Store such as DFR).  Envelope information may optionally be stored in
MS logs.  Since messages do not reside permanently in the MS there is no need
to provide facilities for their management.

While this document-oriented scenario has its place, it can also be argued that
the message-oriented model is at least as valid.  A typical message is a
coherent information object where envelope and heading is as important as
content.  It does seem surprising that there is controversy over the provision
of a standardized protocol to enable a UA to access a managed store of these
familiar information objects.

Sandy Shaw