A key error with X.400 was not that it created a lot of silly functions,
it's that it didn't distinguish between core requirements for everyone,
versus highly optional functions for the few. This is a case of confusing
what MRose characterizes as core-vs-edges functionality.
I think this is very a valid criticism of X.400 when it comes to P1 service
elements and extension fields. There are an immense number of them where the
characterization of "silly" is far too kind, and the ones that make no sense
tend to obscure the ones that do.
I'm less sure that this applies to P2 service elements, however. The X.400
model is actually cleaner than the Internet model insofar as core-vs-edge
handling of these attributes goes -- it is *absolutely* forbidden in the X.400
context, whereas the minute you bring up one of these in the Internet context
there's considerable confusion as to where it should be handled. (The
discussion of Obsoletes: provides ample evidence of this, I think.)
The X.400 scheme falls down in a rather different way in this area, in that it
fails to specify any sort of useful end-to-end requirements. While transport
and message store support for all of the various P2 service elements is
required, there are no requirements that user agents be able to generate or
handle any of them *at* *all*. Amazing as it may seem, there is no requirement
that an originating user agent put any recipient, subject, date, or originator
identification into the header at all, nor is there any requirement that a
receiving user agent be able to display any of this information to a user. The
only thing that has to be there and has to be supported on reception is the
message-id, which happens to be a field the Internet doesn't require any
support for! (See A.10 in part 8 of the Dec 1992 Stable OIW Agreements for
details.)
Is this a problem in practice? Unfortunately the answer is a most emphatic
"yes". There are all sorts of creepy crawlers out there that generate all sorts
of nonsense that is very difficult to deal with. X.400 vendors end up having
to do all sorts of gory stuff to make things work. It isn't pretty.
I'll also note that a small comment from Jacob bothers the heck out of me.
He said that the behavior in the receiving UA wasn't specified. This makes
it sound as if the semantics of the function are not clear enough. Sure
hope that was just bad reading on my part.
Semantics is too broad a term then. The *meaning* of the various header fields
is specified precisely enough. The *actions* a user agent should take in
handling these fields is not specified at all. And if this still bothers the
heck out of you, well, you're not alone!
Ned
P.S. Dave, you may be interested to know that the support requirements for
X.435 (EDI) are quite different from those for X.420 (IPM). Support for a
fairly substantial list of heading fields is required, including originator,
receipient (no carbons in EDI), and, on the receiving side, obsoletes!