Re: reason for application/iotp-xml (was RE: Registration of MIME med ia type APPLICATION/IOTP)

[Paul Hoffman / IMC <phoffman@xxxxxxx>]

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