Sigh. I thought that my last message on this subject covered the material
adequately, but I guess not. Responses since then have included comments like:
"this content-type is not very useful, why include it", to "the mapping
to/from X.400 should be specified in a companion RFC", to "in order to keep
things simple, let's do this work elsewhere". (These are not exact quotes, but
if I'm requested to back these up with actual messages I'll do so.)
So I'll have to go over the rationale for including the full set of X.400
bodypart content-types in an RFC. So this won't be too boring for the folks
that read my previous posting, I'll also address the issue of why I think this
material should be in RFC-XXXX.
As I said before, arguments that "so and so is not immediately useful" do
not impress me. There are two reasons to specify a given content-type:
(1) It is specified because of a clear and obvious need. The multipart
content-type is certainly in this category. We need a way to specify
that a message contains more than one part, and multipart is how we're
approaching it.
(2) It is specified because people might possibly want to send such a thing,
and if two people decide to send it, they should do it in the same way.
All of the X.400 bodypart content-types fall into this category.
I never ever claimed that (1) applies to the X.400 bodypart content-types. It
certainly does not apply to the IA5TEXT bodypart, or the MESSAGE content-types.
There is no clear evidence that an X.400 mapping would ever use these
content-types.
However, there is no clear evidence that it would not. If people insist on
an application to justify such a content-type, here's one: Suppose that I
want to use Internet-standard multimedia multipart mail as a transport. Not
as a mail system, with its associated user agents and other paraphenalia,
but as a transport. And I want to transport X.400 material. Now, it may seem
stupid to regard Internet mail as a tranport, but a compelling argument can
be built on grounds of connectivity. Nothing else comes even close -- the
underlying TCP and IP transports only extend to a fraction of the sites that
have Internet mail connectivity. Thus, I think the notion of using Internet
mail as a transport is a very valid one. Now, given this, I'd probably want
the binding of X.400 bodyparts to be as shallow as possible. This argues
directly for a representation of _all_ bodyparts as content-types.
I don't claim that the preceeding scenario is likely (since it is not one I'm
likely to approve of in any case, I don't propose to develop it further). The
point is that it is possible. Someone, somewhere, may have a reason for using
any or all of the X.400 content-types. It would be nice if more than one
person does this, it gets done in the same way so interoperability can
result.
In addition, it is precisely because RFC-XXXX is _NOT_ an X.400 mapping
RFC that I don't want to get into fine distinctions about what X.400
bodyparts are useful and what X.400 bodyparts are not. This is not RFC-XXXX's
purpose in life! Steve Kille has indicated that he's going to update RFC987
and RFC1148, merging them and building on top of RFC-XXXX to make a new
X.400 mapping RFC. He'll probably use some of the X.400 bodypart
content-types we've specified. I seriously doubt if he'll use them all, and
he may well say that the use of some of them is strongly discouraged. I really
hope he does this -- there are some that I don't want my RFC-compliant X.400
gateway to have to deal with.
The notion that just because a content-type is there you should use them (or
have to support them) is fallacious. It is in keeping with the entire RFC
process that this is fallacious. If you want examples look at RFC821 and
RFC822. They both specify a lot of stuff that nobody uses. (If you want
examples, take a look at the # form for specifying Internet addresses in
RFC821, and tell me that's widely used today.) Was specifying such material
wrong? Of course not! When you write an RFC, you want to cover as much
ground within your target area as possible. If some of that turns out to be
useless later, well, you've learned something, haven't you? But the one thing
you haven't learned is not to specify things cleanly the next time around.
Finally, there's a lot to be said for orthogonality. If I leave out a
given X.400 bodypart, I need a good reason for doing so. I included them
all because I'm not sufficiently arrogant to want to specify which ones are
useful and which ones aren't. That's someone else's job. It might even get
to the point where it is partially my job, but even so, that's not Ned
"coauthor of RFC-XXXX", it's some other Ned "coauthor of something else".
Now, people may disagree with my philosophy here. That's fine, and if so,
we should debate it. But we have to get this philosophy straight before
I'm willing to listen to "such and such a content-type is not useful to me,
so why is it there".
What I'd really like to hear, instead of criticism of what bodyparts are
wanted and what ones aren't, is criticism of the mechanism specified for
their inclusion. This is far more important than which bodyparts we support.
The specification of bodyparts that you don't propose to use SHOULD NOT
CONCERN YOU. The specification of bodyparts that you DO intend to use
should concern you greatly, and if I've done it wrong, you'd better correct
it NOW rather than later. I am forced to consider "no objections" at this
level to be tacit approval of the mechanism, and that may be a very bad thing
to do.
Now that I've dealt with why the complete set of X.400 bodyparts are in the
RFC, I'd like to get into why they're in this particular RFC. I have
several reasons for this:
(1) It was requested. I originally wasn't going to include them, but people
seemed to want them, and they wanted them in this RFC and not elsewhere.
(2) I think that it is important that a reasonable number of examples of
content-type definitions be included in RFC-XXXX. One of the problems with
the original content-type RFC is that it did not include enough
bodypart definitions of its own. The clean, spare approach is to just
define it and let others use it, and that's fine. But people don't
necessarily work this way, and a document without obvious implementation
advantages is not likely to get implemented. The X.400 bodypart group
seems like an obvious and useful candidate for inclusion.
(3) It seems like there would be no problem putting them in a separate RFC,
except history makes me doubt this. Look at the facts -- the original
e-mail RFCs, RFC821 and RFC822, were both written some time back. One would
have expected them to undergo the usual process of revision and amendment.
The mechanisms were included to do this -- RFC822 specifies an open-ended
framework for the addition of new headers and associated semantics
(RFC821's command model is harder to extend for a variety of reasons,
including the failure to specify precisely how unknown commands are
handled, failure to specify batching mechanism that would make groups
of commands more efficient on the network, and so on, but this is not
relevant here.). But these mechanisms have been largely unused -- the
privacy enhanced mail RFCs and the Host Requirements RFC are the only
examples I know of standards-track RFCs that have affected e-mail. And
even if you include experimental e-mail RFCs, the number of RFCs is
utterly disproportional to the number of extensions actually in common use
today. It seems that in order to get an e-mail RFC done, you have to
do it all the first time.
I realize that this makes me sound like a legislator hanging my
pork-barrel on some otherwise vitally needed legislation; I cannot help
that. (Non-Americans on the list who are unfamiliar with this analogy
should be thankful of their ignorance!) I may also be completely wrong;
I'm fairly new to this process, and I may have read the reasoning wrong,
or things may have changed, or both. But my perception remains.
I should also point out that by including these bodyparts in RFC-XXXX
we've at least gotten into discussing them. While we haven't tackled some
of the technical points yet, we probably will soon. And I for one welcome
this process; it needs to be done, and we're doing it.
This having been said, I'm not opposed to splitting the X.400 content-type
definitions out into a companion RFC. I'd like to continue the discussion
of this material on this list, however, since I think these bodyparts are
generally useful -- no matter how much you happen to hate X.400, there are some
bodyparts there that you may want to use (G3Fax, for instance). And if
the FAX people _don't_ want to use the G3Fax bodypart, we need to know that
too. Further than this I'm not willing to go, since I happen to think that
these bodyparts are IMPORTANT and NEED to be specified.
Ned