Rex,
First and foremost, many thanks for the detailed response. (I'd have
answered sooner but my email machine was down...) I've seen some of the
follow-on mail but thought I'd add a couple of comments.
At 10:20 PM 7/6/94, Rex Buddenberg wrote:
My own understanding is that the security functionality
could be implemented equally on X.400 or SMTP. The spec
recognizes FIPS 146 in that it requires X.400. However,
(from memory) an RFC 1006 solution over TCP/IP is OK.
Both of these, of course, are X.400 solutions, rather than using SMTP at all.
Now if we could just get SMTP and X.400 to converge and
co-opt each other ...
Periodically, there is great pressure to try to create "convergence" among
competing technologies. My own experience says that the way things
converge is that one side wins and the other goes away. The only exception
might be if there were great dissatisfaction with BOTH alternatives. To
date, the case of email doesn't quite seem to match, although one could
argue that the dominant email service is the set of proprietary ones, so
that both SMTP and X.400 come up short. To pursue that thought further
would almost certainly distract things even more than the pem-dev world
would be willing to tolerate...
Probably the biggest functional difference between the
envisioned DMS applications and conventional e-mail is
that DMS is intended for organizational as well as personal
messaging. Consider the scale-up problems of, say, CentCom
during Desert Shield where command(_at_)centcom(_dot_)mil might be getting
several tens of thousands of messages a day. Few user agents
The follow-on debate about user-vs-transport agent, I think, misses the
point. First, I would hope that something more clever than simply
'command' would be used for the string, so that additional routing could be
done easily. In any event, the job you describe is simply a routing job
and the fact that it's done by a user agent, rather than a formal MTA,
ought not to affect the technical issues. Since most user agents don't do
routing, your statement is certainly true, but probably not as helpful as
you intended. A different line of concern is the extent to which the DMS
work might be characterized as requiring services that are considerably
beyond the state of common practise. I recall that the rate of message
processing required for the Military Message System Experiment on Oahu, in
1975, also was a challenge...
These days, I suspect that the dispatching problems has more to do with
human processing limits than with email store-and-forward technology.
Dave
+1 408 246 8253 (fax: +1 408 249 6205)