If it indicates the former, that
says that some composite format-types, such as Andrew, Interleaf, CDA,
etc., will show up in the sub-type field of several different types;
e.g., Interleaf would be perfectly eligible for either `text-plus' or
`image', depending on what it described.
The grouping is somewhat arbitrary for these composite entities. They
do _not_ appear in two places. Anything appearing in two places is bad.
And proposals to switch the order of things do not change this -- the
fact of the matter is that composite entities are difficult to deal with
no matter what.
The major problem is the arbitrary grouping. RFC-XXXX is not clear how
a subtype should be grouped and does not mention the motivation behind
the "type". I strongly suggest that RFC-XXXX should state the use of
the "type".
If the number of types is small and closed, it is possible to conceive
of gateways and converting relays doing their conversions one body part
at a time, understanding (at the "type" level) what they need to do.
From John's message, the gateway may do conversion depending on the type.
It implies that picking the "type" is not arbitrary. Am I missing
something here? If a new subtype is invented and picked a not-quite
proper type, what will happen to the gateway that does conversion? Is
the "type" for gateway, or for UA, or both?
You don't clean them up any by switching the order, and
you mess up interoperability considerably if you allow things to take on
more than one name.
I agree. RFC-XXXX should make "subtype" a mandatory field. Since I haven't
heard from anyone since Mark made his comment that "subtype" would be
mandatory, I assume that the suggestion was dropped.
Final comment before I shut up: if someone wants to implement RFC-XXXX,
it will be ridiculous to ask the person to read the last 6-month archives
to find out what the "type" is for.
-Vincent