On 3/10/00 at 7:57 PM -0500, Keith Moore wrote:
> > Again, I'm not especially supportive of the frob as I fail to see very much
>> utility in it. But I also don't oppose it. I see it as "mostly harmless".
>
>here's the question: say someone else wants to define another frob,
>and it's orthogonal to xml. does a type that uses both the new
>frob and the xml frob then become application/foo-xml-newfrob
>or application/foo-newfrob-xml?
Oy. The mind reels at what the MIME parsing code for this looks like.
Really. Funny, I see it as two lines of code, tops. All you have to do
is search for whatever tag you're interested in followed by a dash or
EOS. I have a route to do this sort of thing readily available. I suspect
most others do as well.
I've really got to agree with Keith here; this is a mess and I oppose
the direction it is taking. If XML-ishness needs to be called out as
a property of a body part, it should be separated out as a parameter
of some sort, or made a new field, not embedded as part of the name
of a content-type. I know where in our code I can dispatch off of a
parameter or a new field; that's easy. Dispatching off part of a name
would be grotesque.
All of these approaches were explored in depth already on the XML-MIME list.
All of them have major disadvantages over the tagging scheme presently
proposed. I ended up in strong opposition to all of them, whereas I could find
no good reason to oppose this approach.
There are mechanisms in MIME to call out properties like this. Why
are we trying to embed this particular one in the name instead of
using the mechanisms that MIME provides?
Because upon examination none of them seem even remotely correct for the task
at hand. My conclusion is that if you want to do this, this is right way.
Ned