The purpose of the type is to give the most general description of what the
contents are. By intent it is an extremely limited set, so that the complete
set can be itemized in a single document and all implementations everywhere
can be expected to know about all of them. If anything is to be done to the
set of types, it should be to further reduce their number, not add more.
[Obvious: fold TEXT-PLUS into TEXT, fold IMAGE, AUDIO, VIDEO into BINARY.]
For terminal-based mail reader, "TEXT" class and "BINARY" class are more
important than "type". But for sophiscated mail reader, the "class" does not
provide enough information. It is merely a hint. The real information is
provided by "type." Before the Altanta WG, Neil and I suggested to split the
original type/subtype into Content-Class and Content-Type. The primarly
reason of the splitting is for these two types of mail readers. I don't like
the type/subtype approach because it creates a complexity for user (or vendor)
to choose the proper type for a subtype and requires the uniqueness of
type/subtype combination. I am afraid that this approach may create
I think the present hierarchy is MUCH simpler for casual understanding than
what you're proposing here. Insofar as users are going to be creating their
specifications of this information manually, I think the present approach is
a MAJOR win over what you're proposing.
But let's not lose sight of the fact that if you let users specify this
information casually it does not matter how you structure it -- you are going
to see mistakes made and you are going to have interoperability problems. The
ONLY real solution is to have UAs that generate type/subtype information from
builtin rules and/or examination of their input. And this applies to UAs
regardless of their display capabilites. Now, for a UA with rules like this, it
doesn't matter much what the information looks like -- we could use 128-bit
binary IDs and a table can substitute them in effortlessly.
In other words, I think this proposal has no impact on cases where the UA can
be made smart, and has negative impact on cases where it cannot be made smart.
I really think your suggestion is more complex and more obscure than the
present scheme, and people are going to have more trouble using it, not less.
Let's break this down into two separate proposals:
(1) You want to split the information onto two separate headers. This has
(a) The type (now class) information becomes optional. This makes it, in
practical terms, uselss. You might as well drop it. And this is a
SHOW STOPPER for me as well as a bunch of other people.
(b) The type (now class) information remains mandatory. You have now
complicated the user's task on a manual UA greatly (two headers now
instead of one). You have not solved any problems with subtype/type
grouping, unless you now allow a subtype to appear under multiple
types, but this is (a) in disguise.
(2) You place the information on a single header, but in reverse order. This
has the same two subcases. (a) is the same as (1) (a) above.
(b) If the class information remains mandatory, once again you have done
nothing to change the subtype under what type problem, and now you're
presenting the information in what amounts to an unnatural order
(least general to most general). If you take the possibility of
sub-sub-types into account this can get VERY confusing and can be
a MAJOR interoperability problem.
The current nine is a result of a lot of compromising on the part of a number
of people, and changing them now (adding or removing) would create show-
stoppers among people who formerly were in agreement.
This expressly excludes POSTSCRIPT, INTERLEAF, and even PEM.
I didn't ask for adding or removing any class. My original message was
asking for the guideline how to pick the proper type for a subtype, and
reviewing the potential problem with the optional subtype. My original
question was triggered by the type/subtype confusion appeared to me while
I was implmenting a RFC-XXXX UA.
My implementation experience does not agree with this assessment. I like
being able to group things by types in my control files. It seems natural
and significantly smoothed out a lot of otherwise knotty implementation