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@alvestrand.no [mailto:ietf-types-bounces@alvestrand.no]On Behalf Of Bruce Lilly Sent: Friday, February 11, 2005 12:21 AM To: ietf-types@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.