To summarize:
Most of us are of the opinion that indiscriminate sniffing of objects
is a Bad Idea unless you're of the canine persuasion, and that some
form of tagging is a Good Idea. The question we seem to be hung up on
is whether we should:
a) Use application/xml with Content-Feature tagging. This would
require more work for some MIME dispatchers to implement up front, but
buys us automatic drop-back to generic XML if added support isn't
available.
It isn't just the dispatchers that have to be upgraded, but also the MIME
object label generators. That is, you have to upgrade both the sending and
receiving system for this to work, since a lot of existing labelling systems
don't have the ability to generate content parameters or a content-feature
field. And unless you upgrade the sender, you're stuck with either generic XML
handling or possibly even octet-stream handling.
This also doesn't make it clear how hard the dispatcher upgrade is in this
case. This isn't some simple tweak to the underlying code -- in many cases a
redesign of the user interface will be necessary to add the ability to specify
control-by-parameter or control-by-content-feature.
And there's also the issue of how you make this work in contexts where MIME
types are used but content parameters or content-feature expressions are not
allowed. (Such uses exist in various popular HTML hacks, for example.) While
you can argue that such usage is broken, it nevertheless exists and is widely
used. So now you are faced with having to redesign a bunch of protocol, much of
which we have no say over, and where way to do it in some cases isn't all that
obvious, and fix these implementations as well. Frankly, I don't think this is
ever going to happen. What will happen is that XML format developers will
continue to insist on registering specific media types, and there's absolutely
nothing in our rules that says they can't.
Non-upgraded clients would require (possibly) *one*
intervention to add 'application/xml' to their "how to dispatch THIS
one" tables to point at a generic XML application, but there's no
guarantee that added features would be usable, even if installed, if
their MIME handler doesn't do Content-Feature.
Experience with similar issues surrounding multipart/signed say it
won't be usable. (Unforunately with multipart/signed there was no
useful alternative.)
b) Use application/foobar-xml. This apparently requires less work for
some MIME dispatchers to support, at the expense of creating a "rule"
that *-xml is all xml if you don't want to drop back to octet-stream.
In addition, *non-upgraded* clients get to force hand-adding of this
week's foobar-xml to a table of "how to dispatch THIS one" (even if
it's Yet Another 'hand it to our XML application') if they want "better
than octet-stream" handling.
And the latter can be (and often is in practice) done with the assistance
of a "configuration wizard", making the process relatively painless even
for inexperienced users.
In *both* cases, client software that *has* been upgraded (for either
the *-xml rule or to correctly dispatch based on a content-feature tag)
will be able to hand it off to either a specific featureful XML application
if available, or to a generic XML application if the bells-and-whistles
aren't installed. However, we're not sure yet which track involves less
total aggrivation for upgrading.
We're talking about a process that requires fairly complex sender and receiver
upgrade, as opposed to one that requires a relatively simple receiver upgrade.
The comparison leaves me with little doubt as to which is easier.
Have I mis-stated any major points of the two camps?
Mis-stated, no, but stated incompletely, yes.
Ned