On Thu February 10 2005 15:31, Larry Masinter wrote:
My opinion is that content negotiation for versioning capability using MIME type parameters is unworkable.
Negotiation isn't always possible; sometimes it's a one-way street.
The use of the MIME type is to describe the payload sufficiently so that you know HOW to process it, but the content-type label cannot (and thus should not) be extended in an attempt to use it to determine WHETHER a given processor knows enough to be able to process it.
We're in agreement that the media type/subtype tag should not be used for versioning (that would result in an unnecessary proliferation of tags).
So whether version information should or should not be in a media type parameter depends pretty much on whether there is an embedded, easy-to-find version indicator in the data itself; if there isn't, and processors need to know the version to choose between different processing methods, then the version parameter should be mandatory. There is no strong use case for an optional version parameter, or in general for duplicating, in MIME parameters, information that is readily obtained from the content itself.
Maybe; if transfer encoding is applied, that would entail decoding and opening the media content to determine version information. If the media type is specified via message/external-body or a similar mechanism, additional steps are necessary to obtain the media in order to determine version information. If a particular instance of content is large, that may result in a substantial waste of resources if it turns out to have an incompatible version.
If you want to do content negotiation, then consider using media features and media feature negotiation; with media features you can negotiate not only version information, but other parameters that might also be necessary to know in order to determine interpretability, e.g., availability of compression modes, codecs, fonts, color capabilities, buffer size limitations, etc.
That's fine for protocols that support negotiation, but not all protocols do so (HTTP does, RFC 3297 layered on top of messaging can, but FTP does not). Summary: o media content might contain version information, but reliance on that can result in wasted resources o negotiation via content-features may be a viable mechanism where negotiation is possible, but it is not always possible (and some means of indicating version must be available to the content negotiation mechanism) o proliferation of type/subtypes tags for the sole purpose of versioning is undesirable that leaves parameters associated with the media type as an efficient mechanism for indicating version information.