TIFF is basically just a wrapper for various different types of image
representations. It contains a header, no that much unlike a mail header.
These fields are standardized, but since there are just so many different
possible combinations possible, there have been TIFF classes identified to
aid developers in producing output that can be used between applications.
This makes it possible for you to say that you can deal with a certain type
of TIFF class. The two that come to mind are class B and F. The later
class is the one that defines which combination of header fields are
required
for dealing with FAX data.
The class information is useful, especially since TIFF classes are actually
supersets of their "parent" class. That is, TIFF-F adds functionality that
does not exist in TIFF-B. So a TIFF-F reader must read any TIFF-B file, but
a TIFF-B reader cannot be expected to read all TIFF-F. Unfortunately, I
can't find any internal mechanism for specifying the class of the file.
This would indicate that it might be a good idea to have a "Class=n"
parameter. Alternatively, we can register TIFF-B, TIFF-F, and so on.
This is in fact the approach taken by the Netfax group in labelling their
file format TIFF-B-Netfax. If we go with a parameter, TIFF-B-Netfax should
then be registered with Aldus as TIFF-?.
Just a quick point: there is no need to go and write a specification, a
formal industry recognized standard exists. In addition, several classes
exist that define different types of conformance with the standard. My
recollection is that the NETFAX group was using class F, an existing
standard.
The Netfax file format, while based on TIFF-F, differs substantially, and
is largely incompatible. It is actually a sub-class (superset) of TIFF-F.
TIFF-F is a G3 file format; Netfax allows G3 (T.4 encoding) but strongly
recommends G4 (T.6 encoding). These extensions are the major source of
incompatibility.
My personal feeling is that it would be nice to have some kind of mechanism
where not only TIFF but the conformance class could be indicated in MIME.
If however it would at all slow down the progress of MIME at this point, it
is not worth it - I assume it can be added at a later data through the IANA.
Actually, it will have to be added through IANA since the MIME spec doesn't
discuss TIFF at all. I would guess that many of the versioning arguments
apply to the "Class=n" parameter as well. I'm not sure we can reach
consensus, but some kind of MIME-group guidelines regarding when to create
a new label vs. a new parameter would certainly add consistency to the
coming proliferation of sub-types.
Jim