I'm pretty confused by the suggestion, by you and Ned Freed, that
recipients rely on content-based version fields, since that suggestion
seems to be counter to how I interpreted what the document said.
...
I'm going to have a go at this, since I think there is some
miscommunication going on. In the process of doing that, we will find
out if I'm confused to.
(1) My reading of Nataniel's position/statement is that, if there is
"version" or parameter or qualification information in the file, we
should in general use it, rather than selectively duplicating it as
content type parameters. That seems like a rational engineering choice,
since the implications of having different values in the two places by
some unfortunate accident may boggle the mind.
By implication, if specifications (versions, parameters, etc.) are
needed and they don't appear in the natural format of the file, then
they need to go somewhere else. The G3FAX parameters are a perfect
example, I think.
(2) My reading of Marshall's position is that one should, insofar as
possible, avoid "version" issues as as sort of sub-sub-type entirely,
since they just cause too many compatibility problems as implementations
try to figure out what is real and what isn't. This is consistent with
many of Dave Crocker's arguments, and a few of mine, that profiles are
to be avoided as much as possible as prerequisites to interoperability.
(3) The question of when something is foo-version-2 versus when it turns
into new-foo is always going to be a judgement call. Part of the
decision rule has to do with upward compatability--can a version 2
reader process a version 1 file without difficulty. If that test fails,
then I think it is clearly new-foo. Downward compatability -- the
ability of a version 1 reader to process a version 2 file with some loss
of information or functionality but no self-destruction or serious loss
of information -- is always going to be an interesting question, since
the seriousness of information loss is always debatable.
I'd like to see our documents be clear enough about some of these
considerations that they provide guidance. For example, if "foo" equals
"ps", one could sensibly write a rule that says that it says "ps"
through internally changing versions as long as the internal mechanism
for identifying versions and requirements remains the same and the
upward compatability criterion is met for all versions. If either of
those tests fails, then it is "new-ps", or "ps2". A different type
might have a different set of rules, or those might not be the right
rules for Postscript. In particular, the conventions for Postscript
might not apply to GIF.
(4) By deduction from some of the above, should we go off and define a
"network interchange Postscript" which we expect everyone to support,
then it is a new critter, "net-ps" or something. It would have the
property that virtually everything that could handle "ps" could handle
it, but not vice versa. That isn't as elegant as some sort of canonical
hierarchy might be, but it is lots better than an attempt at a canonical
hierarchy that does not work, and Ned and others have made a powerful
case that "doesn't work" is a likely outcome of trying to define nested
Postscript subsets for interchange purposes.
This implies that we do have a problem here, and a very hard one at
that. It has to do with writing the registration rules or style manual
for registering a new type, what "versions" might mean if anything, when
a variation causes a new type, and just how specific one has to be. But
that is really one of a family of IANA problems as we start registering
objects significantly more complex than port numbers or reserved (but
ultimately meaningless) character strings. And it is a wordsmithing
problem, and a standards problem which does not appear to need solution
in detail for us to get on with MIME.
Larry, the present document is not *nearly* specific enough in these
areas to suit my taste in the matter, but the key term is "taste",
not "broken". I hope someone is keeping track of these discussions
because I think they will be very valuable when, in several months, we
sit down and try to combine proposed-standard-MIME with experience and
these discussions to make draft-standard-MIME. But trying to do that
writing at this stage is likely to result in putting too much stress on
things that are unimportant and too little on things that are. To get
the balance right, we need use-experience, not just implementation-
experience. And all of that is quite separate from the unfortunate
consequences of further delaying things.
john
Now I think all of this is