Ned,
---- Included message:
There's isn't a single, solitary word abo
ut
registration overhead in the current draft.)
From the current draft:
"Rationale: ... Also, reduces the number of registered MIME
Content-types, since those which conform to this model need to register
only an Application sub-type and are not also required to register a
MULTIPART subtype."
Given that this didn't translate into "administrative overhead" when
you read it in the doc, I probably should beef up the words. It was
certainly what I had intended. Along with "user hassles" in tracking
the list. I have no idea what the long-term reduction would be in
absolute numbers, but for a variety of multipart-based definitions, it
would reduce the number by half.
On the matter of deciding whether this is really an issue, my previous
reference was to such concerns as registering each variant of a given
word processor format or to just register a single generic name for the
"class" of formats. I have taken this as a touchstone to the topic and
to suggest -- as has been said in various people's email over time --
that we should try to limit the number of subtypes defined.
My own, additional, feeling is that the specs I've seen are more
complicated when they have multiple content subtypes to define, so that
eliminating one sub-definition would clean them up some. All of this
is quite clearly in the fuzzy realms of "hassle" and preferences; no
doubt about it.
You have heard from at least three MIME implementors
that the unparameterized header-set scheme is an implementation
nightmare.
Ned, I'm afraid that I heard "preference" from the 3 you refer to;
yours is the only one I've seen that would seem to be summarized with
the vocabulary you've offerred, above. I've also seen notes from other
folks, including at least two implementors, saying they like the
scheme.
As to the question of whether a parameter should be present, I didn't
know that was a point of contention. My sense is that things started
leaning towards inclusion of a parameter a couple of days ago.
Dave