This is why I think and "xml." prefix (which would probably require an
XML registration tree) and some simple automated registration process (so
that people can have instant access to a name) is the most workable
solution: it seems to fit into MIME specs, works with existing
technology, and provides a nice convention for conveying its meaning to
humans. (People can still register XML media types under IETF,
experimetal or vendor trees, so a registration tree just adds convenience.)
I could support this, but I think that the process should
encourage the same kinds of considerations for XML types
as it does for media types in the "vnd" tree. It's very easy
for programmers and developers to forget about the simple
security considerations for receiving content that might
cause the recipient to make permanent and damaging
changes to the recipient's environment.
"This media type will only be generated by my own application"
is the typical thoughtless reaction. But this is
the stuff that viruses are made out of.
The problems exist with some extensions to existing media
types, too (for example, several trojan attacks were launched
using javascript extensions to html), but at least having
the considerations apply at type definition might encourage
_some_ thought.
In the privacy of your own application, you can do whatever
you want. It's only when you intend to send some data to
another recipient using a different or separate application
that you need a MIME type at all, and that's the time when
the MIME type considerations (security considerations, being
explicit about optional & required parameters) need to be
asked.
Larry
--
http://www.parc.xerox.com/masinter