Media type versioning (was: Re: Scripting Media Types)

[Bruce Lilly]

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.