jdr@sloth.mlb.semi.harris.COM (Jim Ray) (12/10/90)
I noticed a paragraph in a recent "NETWORK WORLD" ( September 3, 1990),
which stated "The 1984 version (X.400), however, didn't provide a workable
mechanism for remote US access to an MTA ("X.400 standards only need
crowning touch," NW, June 12 1989)."
Does this imply that I must have an MTA on each user platform ( say like
PC's ) barring some sort of mail gateway existing on the MTA platform.
I realize that this problem is repaired with the 88 version.
--
Jim Ray Harris Semiconductor
Internet: jdr@semi.harris.com PO Box 883 MS 62B-022
Phone: (407) 729-5059 Melbourne, FL 32901JPALME@qz.qz.se (Jacob Palme QZ) (12/11/90)
> From: Jerry Sweet <mailmod@ICS.UCI.EDU> > I noticed a paragraph in a recent "NETWORK WORLD" ( September 3, 1990), > which stated "The 1984 version (X.400), however, didn't provide a workable > mechanism for remote US access to an MTA ("X.400 standards only need > ncrowning touch," NW, June 12 1989)." > Does this imply that I must have an MTA on each user platform ( say like > PC's ) barring some sort of mail gateway existing on the MTA platform. > I realize that this problem is repaired with the 88 version. They are probably thinking of the P3 and the P7 protocol. 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. I know that many people claim that the P3 protocol does not work, but I do not understand why. Perhaps because P3 works best if the UA is able to handle parallel processes (for downloading and for doing other things at the same time) and most personal computer operating systems are not so good at this. But if the UA is implemented in a computer which can handle parallel processes, like a Unix workstation or a minicomputer, P3 seems to be a very reasonable protocol. But unless the connection between the UA and the MTA is very fast, also P7 would work best if parallel processes are possible in the UA computer, so that the user does not have to sit waiting while messages are downloaded. Many existing X.400 implementations do not support P3. But the main reason for this is not that P3 is unworkable, but that these systems integrate several UA-s and one MTA in one system, with proprietary protocols between the UA-s and the MTA, and use X.400 only for connection with other mail systems.
eskovgaa@uvcw.uvic.ca (Erik Skovgaard) (12/11/90)
The main problem with P3 is that you have no control over what you
want to take delivery of. If you are using a UA with (only) P3 on
a PC you must take everything the MTA is spewing at you.
This may not be a problem in most cases, but consider the following
scenario:
Mr X has a large PC at work. This PC has 100MB storage and can render
ISO 6937 text, voice (bilatteral agreement) and G3Fax.
At home he has a small PC with only a single 720K floppy drive and
this PC can only render and generate standard IA5 text.
If Mr. X is at work and connects up to his local friendly MTA he
will get all the messages queued up for delivery to him. That is
all fine, because he has registered his UAs capabilities with his
MTA and his MTA will not deliver (e.g.) G4Fax which Mr. X's UA
cannot handle.
Now, however, Mr. X decides to work at home one day. He establishes
a connection to his friendly MTA and the MTA dumps all the messages
queued up for Mr. X. Unfortunately, he runs out of disk space
before he can take delivery of all messages. His UA then aborts
the connection. This leaves some messages queued up at the MTA.
Sofar, no problem. He can always re-establish the connection
when he has a clean disk.
Alas, he has been delivered a G3Fax message which he cannot display
on his screen. He has no way of transferring this message to his
PC at work, since they use different file formats. The message is
effectively lost.
There are some other problems in the 1984 P3, but the main point is
that it restricts you. That is why they defined P7 (and incidently,
also fixed P3 up). With P7 you can selectively retrieve messages of
any type you want and you can also specify size limits and priority
limits.
....Erik.S.Shaw@edinburgh.ac.UK (12/14/90)
Apologies to those who have already seen this. I have been advised that the original redistribution was not complete. > 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
S.Shaw@edinburgh.ac.UK (12/14/90)
> 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