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

[Eric Burger]

> 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.