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

[Eric Burger]

Oooh -- I really don't like this one.

True, there may be situations (specific MIME types) where this makes sense.
However, if my UA *knows* how to handle different versions, why would I ever
present a selection to the user?

Scenario:
Joe Random goes to a porn web site.  The web site has a Java applet that
displays the movies.  On hitting the web site, a dialog box pops up saying,
"Hey - this is an ECMAscript4 application: is that OK?"  Joe Random freaks
out, because he thought he was getting a movie, not a cup of coffee.

> -----Original Message-----
> From: ietf-types-bounces at alvestrand.no
> [mailto:ietf-types-bounces at alvestrand.no]On Behalf Of Bruce Lilly
> Sent: Friday, February 11, 2005 12:21 AM
> To: ietf-types at alvestrand.no
> Cc: Bjoern Hoehrmann
> Subject: Re: Media type versioning (was: Re: Scripting Media Types)
> 
> 
> 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.
>