An important philosophical point needs to be made explicit here. There are
two reasons for standardizing a given content type:
(1) Functionality. Certain content-types clearly need to be supported by as
many UAs as possible (note that "support" of a content-type by an MTA
is something of a nonsequiter; even support in gateways for conversions
is somewhat problematic). Minimal interoperability is a requirement,
therefore support for some subset of all the content-types should also be
a requirement.
(2) Compatibility. A large class of content-types exist which, while universal
support cannot be provided, universal compatibility can be. In other words,
if I decide to send something produced by MicroSoft Word, it would be
nice if someone else with MicroSoft word could receive it and interpret
it correctly.
We're getting confused here about which of these reasons apply to what
content-types. This is our (Nathaniels and my) fault; we need to make this
much clearer in the RFC. However, our position (speaking for Nathaniel
here without his consent, I admit) is that if either one of these reasons
apply to a given content-type, it warrants inclusion (perhaps not in this
RFC, but in some RFC somewhere).
Thus, the conclusion that we're requiring support for all of the content-types
mentioned in the RFC is invalid. We aren't. What we are saying is "if you
export material of this type, do it this way". We do need to indicate
whether or not support for various content-types is required. What about
required/recommended/optional indicator?
I also need to tighten up the specification of how X.400 material gets
translated. I thought that since X.400 immediately implies a representation
format (via the Basic Encoding Rules), that it was obvious that the various
chunks of ASN.1 referenced in the RFC get encoded using the BER and then
treated as a byte stream to be further encoding in whatever printable
form the Content-encoding: headers says to use. (Incidentally, does anyone
have a feeling of how well varous compression schemes work on ASN.1?)
We've obviously restricted outselves to a very limited subset of the
possible content-types. There's a simple reason for doing this -- finite
time and finite expertise. I'm not going to standardize the encoding for
MicroSoft Word, for instance. For all I know there's a printable representation
of MicroSoft Word documents in some markup format that should be used here.
(I doubt it, but I'm not sure.) And is the represntation the same on PCs,
Macs, and whatever else can run it? I sure don't know.
This didn't stop us from including various content-types that we're
not real authorities on (at least I'm not an authority on X.400, although
I'm involved in the standards process and I've worked with X.400 fairly
heavily in various forms). There are certain types of data that we feel
really need to be in there, and we covered them as best we could. We're
working with the ODA gurus to figure out how ODA will fit into all this,
for example, since neither of us has any ODA expertise. And hopefully our
mistakes will get corrected as the document continues to evolve.
Ned
P.S. My use of MicroSoft Word is entirely an example; I don't have strong
feelings about this product one way or the other.