I appreciate Pete's concern here, and agree that in an ideal world, this
could be handled under Content-Disposition or some new sort of
Content-Structure header. But my (perhaps mistaken) belief is that most
dispatching tools out there work off of MIME type, and do not necessarily
have access to arbitrary Content- headers.
To take just one example of the utility of putting the information in the
content type, think of web crawlers associated with search engines. Most
web crawlers look only for "text/*" documents for archiving. With the
"-xml" suffix rule, all existing web crawlers can be easily modified to
search for "*/*-xml" as well, opening up to search a huge quantity of data
that would otherwise be unavailable. (Obvious caveats apply, that if you
don't want your data searchable, use robot tags.
<http://www.fast.no/fast.php3?d=support_faqs&c=crawler&h=3>) These crawlers
would require significant changes to parse the rest of the HTTP headers as
well, and more important, most web authors have no way of adding arbitrary
MIME headers to their sites.
The point is that "-xml" has demonstratable benefit to a significant subset
of the community, while Pete and Keith have complained about the lack of
elegance of the solution.
Ned Freed has shown that a simple rule of "-xml" comes last will allow
extensibility. However, we haven't needed any extensibility of the last 10
years and the popularity and extensibility of XML itself will hopefully mean
that we won't need to have this debate again for a long time.
In lieu of a proposal for a more elegant solution that also provides
complete backward (and easy upward) compatibility, I think we should move
forward with Murata-san's draft.
- dan
--
Daniel Kohn <mailto:dan(_at_)dankohn(_dot_)com>
tel:+1-425-602-6222 fax:+1-425-602-6223
http://www.dankohn.com
-----Original Message-----
From: Pete Resnick [mailto:presnick(_at_)qualcomm(_dot_)com]
Sent: Saturday, 2000-03-11 12:01
To: Keith Moore
Cc: ned(_dot_)freed(_at_)innosoft(_dot_)com; Keith Moore; Dan Kohn;
ietf-types(_at_)iana(_dot_)org;
Martin J. Duerst; MURATA Makoto; Donald E. Eastlake 3rd;
ietf-822(_at_)imc(_dot_)org
Subject: Re: reason for application/iotp-xml (was RE: Registration of
MIME med ia type APPLICATION/IOTP)
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.
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.
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?
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102