Mark & /mtr
I see /mtr's point about nesting subtypes making the whole thing a
harder. I might disagree about the difficulty this creates, however I
haven't yet tried implementation so I shouldn't comment about perceived
difficulty.
I have a problem with this regardless. Namely this might not be enough
levels for a direction I am intending to take.
Suppose I want to create a kazillion things which live under, say,
"application". I run a humongous company and want to use e-mail to
replace a lot of the paper forms which float about. Stores
requisitions and the like.
Now.. where do these different forms `fit'? They should each have
their own identifier so that the UA can recognize them cleanly.
If I work through the IANA for each and every one of them, IANA will be
overloaded. Now, maybe they are all unique to my company and I can use
the X- format. Maybe not.
If, instead, I register with IANA an arc under "application" and am
allowed to use the third level as I see fit then a lot of potential
load is taken off IANA. That is
Content-Type: application/Davids-Widgets-Inc/ xxx; parameter=value
Another example.
I run a software company making a kazillion different application
programs. Each of which has >= 1 unique type of data file.
Each of the data files will naturally fit into some part of the
existing tree of Content-Types. Davids Widget's paint program produces
DWIFF files while our word processor makes ASCII files with proprietary
markings which are Superior to every other markup method.
Again I run the risk of overloading IANA with registration requests.
Another example.
Some existing file formats naturally have subtypes of their own.
Examples which I know of are:
Electronic Arts' IFF: Used widely on Amiga and other platforms. Is
a file format which can hold many `chunks' within a single
file. Each `chunk' has a type labeling it and a length.
Types tend to be those used in multimedia presentations.
Things like audio, pictures, animations, music scores,
MIDI event lists, etc.
TIFF (designed by someone): Appears to be similar.
G3FAX: has T.1, T.4 and likely other T.x's.
The examples used in RFC-XXXX imply the subtype for each
of these would be
Audio/IFF-8SVX
Image/TIFF-B-NetFax
Image/G3FAX-T.4
...etc...
In other words we'd describe subtyping for this in the
type-subtype-subtype fashion. We again run potential problems with
overloading IANA.
Summary.
The lesson I take from the development of the domain name system
is that a limited amount of hierarchilization will eventually
be a problem. The above examples attempt to show ways that
problem might actually come into being.
Obviously to an extent I am grasping after straws. If it does
turn out to be a problem then there is an obvious syntax to
use for extending the subtyping to arbitrary levels.
David