[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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