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

[Bruce Lilly]

On Thu March 10 2005 03:26, Larry Masinter wrote:

> the specific proposal of using
> MIME type _parameters_ is a bad design choice for conveying
> information as slippery as _version_.

Please define "slippery" in this context, then please explain
precisely how your pet preference (Content-Features) is a more
suitable choice in that respect, including the specific registered
feature tag that you propose using.

> >> 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 think those are problems; aren't these forwarding bodies
> (that are looking at MIME types and parameters) also unwrapping
> transfer encodings and fetching external bodies? 

No (i.e. not necessarily).
 
> You're optimizing what I assume is mainly a failure case,
> anyway: you got sent something you can't read.

Bad assumption. One might have been sent one or more pointers
to external data.  One would like to be able to determine
ahead of time whether any of them can be read *before*
retrieving huge amounts of data, and that may depend on version
information.
 
> Using MIME parameters isn't the only place to put auxiliary
> information. If you need auxiliary information, put it somewhere
> else -- such as in a content-features header.

Version information is not a feature.  Your suggestion requires
registration of a feature tag (RFC 2506), waiting for that tag
to be recognized (i.e. replacement of deployed implementations
of feature tag parsers), generating an additional field (viz.
Content-Features) in addition to Content-Type, hoping that that
additional field isn't lost or mangled in transit, and extreme
optimism regarding whether a receiving implementation will pay
any attention at all to a Content-Features field, much less be
able to interpret that tag *and* its associated value.  That
rigamarole is certainly not as light-weight as simply using a
version parameter in the Content-Type field.

N.B. there is nothing resembling "version" registered as a
media feature tag
http://www.iana.org/assignments/media-feature-tags

> I meant "negotiation" in a more general way: describing content
> in a way that subsequent processors can make decisions about
> whether or how to process without opening the content itself.
> In this case, I recommend putting this auxiliary data somewhere
> where it won't just confuse and pollute the processing that
> is necessary for the content-type itself.
> 
> "Content-features" is useful in cases where there is no back-channel.

But not for version information.  Content-Type is similarly
useful (including for version information) in the absence of
a negotiation mechanism.

> Hardly. Pulling out redundant information and sticking it
> on the wrapper to facilitate processing is an optimization,

One might only have the wrapper (e.g. message/external-body),
in which case there is no redundancy, and provision for
appropriately dealing with the content consistent with the
Internet Architecture (RFC 1958, specifically section 3.1);
assuming that all recipients will have unlimited (electrical)
power, infinite communications bandwidth, gibibytes of local
storage, and every conceivable version of every type of
decoder is not consistent with that architecture.  It is not
an optimization; it is information which is essential to the
operator of a low-power, limited bandwidth, small-memory
device to be able to determine whether or not it is advisable
to download some content of a specific media type.

> >> 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)
> 
> Wrong. "Content-Features" can be used to carry version information
> as well as the parameters of "Content-Type". There is no
> situational difference.

See above re. no registered feature tag for version.
  
> > > that leaves parameters associated with the media type as an
> > > efficient mechanism for indicating version information.
> 
> I disagree -- it's extraneous information, unnecessary and often
> lost in processing pipelines.  

It's not extraneous or unnecessary (often essential).  And of
course Content-Features fields are *always* preserved and
considered, right?
 
> We haven't really talked much about the terrible deployment experience
> and prospects for *any* MIME parameters. They usually get lost;
> most of the operating systems that support MIME type mappings to
> files don't support parameters (Windows file associations, MacOS,
> mime.types, etc.).  

And that differs from Content-Features ... how?  Why should we
base design decisions on abysmally bad implementations of things
(e.g. OSes) unrelated to what is being specified (media types)?
 
> We could write standards about castles in the air all day, and
> I suppose it would be "free" in some sense of the word, but it
> is wrong, and detracts from the value of the standard. Don't
> specify things that either don't work or are undeployable. Otherwise,
> what's the point?

Ooh, that sounds like the sort of remarks that could come back
to haunt a fellow :-).