I think I may have not made my proposal clear: take whatever it is
that the current proposal labels "GIF" and just label it "GIF;89a" or,
if you must, "GIF89a". Certainly, if you introduce a new,
not-backward-compatible format, say "GIF92b" that cannot be read by
GIF89a readers, you should give it a different name.
My only problem is releasing a protocol where there is a name "GIF"
when what you clearly intend to denote by it is "GIF as commonly used
by 1992".
The reference cited in the MIME document presumably defines the variants of
GIF that are expected to be supported by content-type image/gif. If future
variants are ever supported by MIME, there will be a new GIF-19XX spec and
a new content-type name.
Keith Moore writes:
Your point is well taken, and we would do well to put version numbers in
content-type headers. However I don't want to delay MIME going to proposed
standard for this reason, especially if we have to define a mechanism for
defining content-type versions before we can proceed. When MIME goes up for
draft standard status we can fix this and other problems that will
undoubtedly crop up. For instance, I think we could safely add a "version="
parameter to all body part types at a later date without breaking existing
MIME readers.
You already have a mechanism, if you think that after "ps" there will
be "ps2" and after "gif" there might be "gif92", why not just call it
"ps1" and "gif89a" to start with?
Because the MIME document has to be frozen sometime.
Changing the content-type name doesn't really change how things work, it
just makes it more apparent that there is a particular, dated, specification
associated with that content-type.
I also think you are correct that the PostScript spec as currently in MIME
is not sufficient to ensure interoperability. (other concerns have to
do with how ends of lines are represented (since we haven't defined an
end-of-line convention for application bodyparts) and line lengths (since
some systems can't store very long lines). However, it is probably good
enough for now. Some of these things can't be determined without some
operational experience. That's what proposed standard status is for.
My concern is that the problems that versionless formats entail are
not immediately evident with "operational experience": the problem is
a lack of compatibility OVER TIME. Certainly the initial experience
with mime is that the writers and readers will be more or less in
sync, since they all started at the same time. The problem -- that
formats tend to get out of sync over time -- will only show itself
years later. This kind of 'time-sensitive compatibility' issue is not
uncovered by testing; you actually have to plan for it.
I don't think that changing image/postscript to image/postscript-version-foo
will help the PostScript writers' problem a bit. For the case of
PostScript, we will certainly gain experience as to how to create messages
that are interoperable that we might want to document later, but it won't be
necessary to label the new messages any differently, since old postscript
interpreters will presumably read them just fine.
If a few years down the road I send out a document written in
PostScript-1998 and (mis-)label it application/postscript, then the
difference is that the recipient gets an error from his PostScript
interpreter that says it doesn't support 3-D animation, instead of getting
an error from his mail reader that says it doesn't understand content-type
application/postscript-1998. This may be less than ideal, but does it
create a real problem? (Of course, it might cause the mail reader to use
the wrong part of a multipart/alternative, but a good mail reader would
allow the user to view any part of a multipart/alternative anyway.)
One of the things the content-type field is going to be used for in
gateway products is deciding whether there exists a converter from the
specified format to another format in use on the other side of the
gateway. I hadn't expected gateways to also have to unpack the body in
order to read the header information in order to decide whether the
installed conversion routine is adequate, or whether some other kind
of encapsulation in the gateway is necessary. This reason alone would
dictate not relying on the content of the GIF to tell you that you had
a GIF89a and not a GIF93b, for which you had no converter.
I don't think we can get around the problem in general. Lots of body parts
will have internal labeling of some sort, and extracting such information
into parameters just requires that the sending UA be smarter about the
internal formats of each of those body parts. If I have a GIF file, it's
quite natural to want to be able just to stuff it into a mail message, label
it as image/gif, and send it on. I don't want to require my mail composer
to dive into GIF/PostScript/TIFF/JPEG/whatever file interals just to figure
out how to label the message. So I'd strongly recommend that we limit the
content-type header parameters to information that is required to interpret
the bodypart, but must be kept separately from the bits themselves. I think
that's pretty much the case with the current MIME document.
Keith