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

[Bruce Lilly]

On Wed February 9 2005 16:46, Bjoern Hoehrmann wrote:

> At least in the context of HTTP, use of such parameters where media
> types provide them is not common in my experience, using them would
> typically require access to the server configuration and users that
> know about the parameters and how to configure the server accordingly;
> RFC 2854 notes that this did not work in practise. The situation might
> be different when this would be relevant for the proposed types, but
> that seems unlikely...

2854 only mentions one parameter (charset) and it seems to encourage
its use; I see no mention of problems with use of (as opposed to
failure to use) that parameter.

> Could you make a suggestion for the draft that would address your
> concern? Would it be sufficient to refer to the version parameter
> as optional parameter with an unconstrained lexical space for its
> value and with the semantics that implementations must consider any
> use of the parameter to indicate that the content is unsupported?

One approach would be to recommend or require display to the user
and confirmation before executing the content.  Since we're dealing
with potentially dangerous executable content, user confirmation
should be required anyway; providing some version information to
the user with a request for confirmation provides the user with
information which may be useful in making a decision. Structured
version information could go further; it might provide applications
with the ability to determine that execution is not possible (due
to lack of availability of some resource, or due to some
incompatibility); that could replace a request for confirmation by
an informative message (possibly localized) which would explain the
problem to the user (as opposed to simply displaying unstructured
"human-readable" versioning content, which might in fact be unreadable
to some humans due to charset and/or language issues).

As to what specific sort of structured versioning information
might be appropriate, that really depends on how the (scripting)
language versions and related compatibility issues are structured.
I can, however, offer an observation about what hasn't worked well,
and how to avoid problems which have plagued other versioning
mechanisms.

MIME itself provides for versioning via a MIME-Version header field.
The field body is defined as two dot-separated integers.  However,
there are several problems:
1. the semantics are undefined; aside from the initial version
   of 1.0, we can't tell how a hypothetical version 1.1 would be
   partially compatible, or a hypothetical version 2.0, etc.
2. the syntax is silent about leading zeroes in the integer
   parts. That's a recipe for interoperability problems.