* 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@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/