It is unwise to associate the content-type with a specific program name.
Sometimes there will be more than one possible application that can deal
with a particular content-type. Other times there will be one program used
Keith,
I think that sometimes we get sloppy about language and confused about
what we are talking about. At least I hope that is what is happening
here. To pick on WordPerfect, since people have been using it in
examples, we could have
application/WordPerfect-the-application
or
application/the-file-format-WordPerfect-uses-by-default
we could call either "WordPerfect", although I agree that it is the
second we want to use/describe/register, not the first.
As soon as you add a version parameter you have to define what it means.
Sure. But you don't need the same answer for all application subtypes,
which is the problem with making a general rule.
Until then, we may well need content-types named
product-x-by-vendor-y-for-operating-system-z
Well,
file-format-produced/read-by-product-x-by-vendor-y-for-operating-system-z
But I think something is getting lost in trying to generalize. Let's
try a slightly different model of what is going on, then come back to
WordPerfect (real example this time). Assume that, in writing
Content-type: application/foo; baz-string
we are just trying to give sufficient information to an
applications-dispatcher (something that sends things *to* an application
or processor based on a file type) to:
o determine where to send the thing
or
o determine that it doesn't know what to do with it.
In this model, while we have provided some lexical structure to
"baz-string" for our general convenience, its semantics are strictly up
to the application or processor-- we would expect the dispatcher to just
pass that information along in some sort of structure, not, in general,
to try to interpret it usefully.
Now let's assume we have an application from Crock Company called
"Crock" and which uses "Crock files". Files for version 2 of Crock are
completely non-interoperable with version 1 and vice versa; nearly the
only thing they have in common is the Crock name. Interplatform
differences are as bad or worse. This situation is stupid, but not
uncommon at present.
Now, if someone wants to register (a) Crock type(s), they would be well
advised to register
application/Crock-file-version-1-DOS
application/Crock-file-version-2-DOS
application/Crock-file-version-1-UNIX
etc.
If they instead register
application/Crock-file; platform=... ; version=...
then the dispatcher is going to need to engage in a dialogue with
potential Crock-agents (dispatching targets) as to whether _this_ Crock
file is one that they can handle. In this case, the Crock-agents at
least have the platform and version info to help, assume that is
Crock-systematic (as you know, sometimes it isn't). If it were absent,
they would have to look at the file and just return "not me, try someone
else" as that dialogue.
But WordPerfect files (e.g.) are a different case. There is a canonic
rule about what major and minor versions mean. The application program
of the same name at a given version will read the files of all earlier
versions, and competent WordPerfect-to-something conversion programs do
this too (it isn't hard, and WP Corp nearly gives away the tools). So a
sensible person might want to register
application/WordPerfect-file; version=N.m; platform=xxx
Interestingly, file format versions for WordPerfect don't necessarily
correspond to product release versions: probably 99% of users don't have
a clue as to the file format versions they are using. And "platform"
may be completely unnecessary. The problem is that one would need more
information than is available to me as a sometime-developer to know
whether it is necessary to specify "platform" or whether version
information should be specified in terms of product versions or file
versions. I don't know how to get good advice on that without getting
the vendor involved in a major way.
We also have a conflict here between content-subtypes for exchange among
consenting adults using the same (or naturally interoperable) products
and content-subtypes for interoperability. For the latter, we should be
ignoring all of this platform- and implementor-specific stuff and
concentrating on formats that are implemented on many platforms and for
which stable public specifications are available.
--john