Just to be clear, this was only an argument that 3D objects don't fit
into image/*. I'm not so sure whether 3D should have its own type.
> 2D viewers exist that handle multiple 2D formats; similarly
> for 3D viewers. Hence different default behaviour or separate
> mailcap entries for 2D/* and 3D/* make sense.
Given any set of file formats that have different magic numbers, you
can always write a viewer that deals with all of them. So it doesn't
mean much to say that a multi-format viewer *could* exist for foo/*.
On the other hand, there is a large common subset of functions that
you want in an image viewer, no matter what kind of images you're
displaying. So it makes sense to write a single tool that deals with
many different kinds of images. The same applies to each of audio,
video, and 3D objects.
This is not by itself a strong argument to classify each of these in
their own top-level MIME types. It is clearly useful to be able to
put a single rule for (say) image/* in your mailcap file, but being
able to do so was not the primary reason for the two-level type
system.
> The problem for me is that these arguements can be made for a
> "spreadsheet" type as well.
Why is that a problem? If there were enough different spreadsheet
formats out there, and especially if the hardware requirements for
spreadsheets were unusual, a top-level type for them might be
desirable.
> Perhaps this points to a fundamental problem with the MIME audio and
> image types, the justification for them being at the top level is
> not strong.
Again, the justification for audio and video is that you need
different hardware to deal with them. The justification for
application is that you have to have some place to put everything else
that doesn't fit, or for which there aren't enough subtypes to warrant
a separate category.
> Finally, I observe that there is an implicit identity, image == 2D.
> Does that need to be?
I think it is desirable. 2D image handling is significantly different
from handling 3D images, and you could argue that you need different
hardware (dialbox, 3d glasses, etc.) to adequtately use 3D images.
> Question. Does it make sense to register IGES as application/iges
> while the introduction of a 3D type moves through the IETF? The
> practical experience might shed light on these issues.
I think it depends on how pressing the need is. I would rather see
widespread use of application/iges (even if the 3D top-level type were
created later) than widespread use of an x- type.
Keith