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

[Bjoern Hoehrmann]

* Bruce Lilly wrote:
>There are no "reserved parameters"; there are required parameters and
>optional parameters.  If you believe that version information may be
>useful in one or more of the types that you seek to register, you
>might define an optional version parameter (and specify how content
>is to be handled when lacking that parameter), or if it is critical
>to interoperability, make the parameter mandatory.

I would like to hear what other ietf-types participants think about
this. I do not think there is real consensus in the IETF on how to do
versioning on the media type level, as the draft notes, implementers
have attempted to deal with this by appending version numbers to the
subtype name as in text/javascript1.1, some types use parameters to
indicate the "version" (or codec, etc) and other types, as you point
out, did not really consider this issue, for example, for the XML
media types it is not clear whether those can be used for XML 1.1,
RFC 3023 only refers to XML 1.0. An update to RFC 3023 might allow
using e.g. application/xml for XML 1.1 but that would yield in a
situation similar to that of the media type for PowerPoint content.

I do not know how the formats relevant to the draft evolve, so I do
not know at the moment whether updating the document to consider new
formats at a later point is the best way forward, or whether such a
new format should use a new media type. In response to the first draft
in 2001, ECMA TC 39 (the technical committee responsible for the
ECMAScript specification) suggested a application/ecmascript4 media
type for ECMA-262 Edition 4; my understanding is that Edition 4 is 
still not final so it lacks a public specification and such a media
type can thus not be registered in the standards tree at the moment.

I do not want to ignore this issue, hence the reserved version para-
meter. It's not meant to be an optional parameter, it is rather meant
as an anchor for error handling requirements, implementations unaware
of the parameter must not consider content that uses the parameter
supported. This would enable use of the media type for content that
would not interoperate with older implementations that do not support
the new format. There seem to be two alternate approaches to the
problem, either require implementations to consider all parameters
(but charset) as indicating unsupported content or list the parameter
as optional parameter; the former would hinder introduction of other
parameters with different semantics and implementations to implement
common error recovery behavior (i.e., ignore unknown parameters).

The latter does not make significantly more sense to me than the
current approach; as I do not know how the formats evolve, it would
be difficult to specify the lexical space of the parameter value; I
could say it must be empty or can be anything that is allowed for
parameter values, and regardless of the value, the content must be
considered unsupported. I anticipate objections to that approach.
If I specify something else, it could conflict with yet unknown
versioning policies of the format specifications. OTOH, updates of
the document could change the lexical space of the parameter value...

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

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?
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/