At 03:37 PM 3/11/00 -0800, Tim Bray wrote:
1. A web crawler building a full-text index
2. An XLink processor building a topological map a la Google
3. A rules-driven firewall filter deciding whether to let something
through
4. A schema-driven datatype-checker
Of these four, only (3) makes sense for IOTP. And, even then, a sender or
receiver of a IOTP object behind a firewall would have already talked to
the net admin for the firewall to allow application/iotp through. Also, see
below.
But, to stretch into the theoretical again, let's also look at calendar
objects in XML. In the case of (1) and (2) and (4), the process doing the
XML crawling and/or indexing *should* know about application/iotp. Even if
it doesn't, and it is making the assumption that "there's XML out there
that I don't know the MIME type of but I want to find it", it will likely
pull down or look at all objects with MIME types that it doesn't know about
(thereby skipping all the image/gif files) and then look in the file to see
"is this XML"? The first time that the process comes across application/foo
and discovers that it has XML in it, you can bet that the process would
start to specifically look for application/foo.
(3) is pretty psychedelic. Firewalls that look at MIME types but not the
content are so horribly insecure as to not need further discussion.
And, just to get back to specifics, the author of the IOTP draft said the
other day:
I'm polling the TRADE WG but it is my impression that there is enough
implementation that people would prefer not to change.
Not only can we wait for "the next one" on this topic, we have another
example of a group that doesn't feel much inclined towards the utility of
the application/foo-xml solution for their protocol.
--Paul Hoffman, Director
--Internet Mail Consortium