On Thu March 10 2005 03:26, Larry Masinter wrote:
the specific proposal of using MIME type _parameters_ is a bad design choice for conveying information as slippery as _version_.
Please define "slippery" in this context, then please explain precisely how your pet preference (Content-Features) is a more suitable choice in that respect, including the specific registered feature tag that you propose using.
Maybe; if transfer encoding is applied, that would entail decoding and opening the media content to determine version information. If the media type is specified via message/external-body or a similar mechanism, additional steps are necessary to obtain the media in order to determine version information. If a particular instance of content is large, that may result in a substantial waste of resources if it turns out to have an incompatible version.
I don't think those are problems; aren't these forwarding bodies (that are looking at MIME types and parameters) also unwrapping transfer encodings and fetching external bodies?
No (i.e. not necessarily).
You're optimizing what I assume is mainly a failure case, anyway: you got sent something you can't read.
Bad assumption. One might have been sent one or more pointers to external data. One would like to be able to determine ahead of time whether any of them can be read *before* retrieving huge amounts of data, and that may depend on version information.
Using MIME parameters isn't the only place to put auxiliary information. If you need auxiliary information, put it somewhere else -- such as in a content-features header.
Version information is not a feature. Your suggestion requires registration of a feature tag (RFC 2506), waiting for that tag to be recognized (i.e. replacement of deployed implementations of feature tag parsers), generating an additional field (viz. Content-Features) in addition to Content-Type, hoping that that additional field isn't lost or mangled in transit, and extreme optimism regarding whether a receiving implementation will pay any attention at all to a Content-Features field, much less be able to interpret that tag *and* its associated value. That rigamarole is certainly not as light-weight as simply using a version parameter in the Content-Type field. N.B. there is nothing resembling "version" registered as a media feature tag http://www.iana.org/assignments/media-feature-tags
I meant "negotiation" in a more general way: describing content in a way that subsequent processors can make decisions about whether or how to process without opening the content itself. In this case, I recommend putting this auxiliary data somewhere where it won't just confuse and pollute the processing that is necessary for the content-type itself.
"Content-features" is useful in cases where there is no back-channel.
But not for version information. Content-Type is similarly useful (including for version information) in the absence of a negotiation mechanism.
Hardly. Pulling out redundant information and sticking it on the wrapper to facilitate processing is an optimization,
One might only have the wrapper (e.g. message/external-body), in which case there is no redundancy, and provision for appropriately dealing with the content consistent with the Internet Architecture (RFC 1958, specifically section 3.1); assuming that all recipients will have unlimited (electrical) power, infinite communications bandwidth, gibibytes of local storage, and every conceivable version of every type of decoder is not consistent with that architecture. It is not an optimization; it is information which is essential to the operator of a low-power, limited bandwidth, small-memory device to be able to determine whether or not it is advisable to download some content of a specific media type.
o negotiation via content-features may be a viable mechanism where negotiation is possible, but it is not always possible (and some means of indicating version must be available to the content negotiation mechanism)
Wrong. "Content-Features" can be used to carry version information as well as the parameters of "Content-Type". There is no situational difference.
See above re. no registered feature tag for version.
that leaves parameters associated with the media type as an efficient mechanism for indicating version information.
I disagree -- it's extraneous information, unnecessary and often lost in processing pipelines.
It's not extraneous or unnecessary (often essential). And of course Content-Features fields are *always* preserved and considered, right?
We haven't really talked much about the terrible deployment experience and prospects for *any* MIME parameters. They usually get lost; most of the operating systems that support MIME type mappings to files don't support parameters (Windows file associations, MacOS, mime.types, etc.).
And that differs from Content-Features ... how? Why should we base design decisions on abysmally bad implementations of things (e.g. OSes) unrelated to what is being specified (media types)?
We could write standards about castles in the air all day, and I suppose it would be "free" in some sense of the word, but it is wrong, and detracts from the value of the standard. Don't specify things that either don't work or are undeployable. Otherwise, what's the point?
Ooh, that sounds like the sort of remarks that could come back to haunt a fellow :-).