From: Bruce Lilly Sent: Thursday, February 10, 2005 11:30 PM 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).
Is this really so bad? There are all of 93 application/foo's registered.
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.
I don't like the idea of embedded data being required to determine if the entity can accept the message. By that point in time, it is too late. If you need a data element to determine, at the protocol level, you can process a message, then you need that data element at the protocol level. E.g., a MIME parameter rather than an XML tag in a body part.
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).
Well, if you need negotiation, use a protocol that offers negotiation :)
Summary: o media content might contain version information, but reliance on that can result in wasted resources
And a layer violation and asking for hacked stacks.
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)
Agreed.
o proliferation of type/subtypes tags for the sole purpose of versioning is undesirable
I'm not sold on this one. If a new version of a media type is not backwards-compatible, I would offer that it is a different media type. As noted above, in 8 years of MIME types, we have all of 93 application/foo registered types.
that leaves parameters associated with the media type as an efficient mechanism for indicating version information.
After saying that this is not the only method, I also would offer that one is ALWAYS free, in the definition of the MIME type, list a parameter and describe normative behavior for processing that parameter. That could be something like "version". That said, I am really uneasy in saying that one MUST use a version tag. Some of the thread above suggested that one could generically use the combination of MIME type and "version" as an indicator of MIME type. For example, if the "version" is "bigger" than what I know, I know to generically barf on the message. Besides the issues that Ned pointed out (V1, V2, Vn vs. 1.2.3, 1.2.4, m.n.o vs. ...), some MIME types, like the PostScript example, still work on "older" processors, while others are completely different between versions. The result is the semantics and normative behavior for receivers for the "version" parameter is MIME type specific, and thus NOT subject to generic behavior specification.