ietf-822
[Top] [All Lists]

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

2000-03-13 15:17:34
In 
<4(_dot_)3(_dot_)2(_dot_)20000311134222(_dot_)00b27410(_at_)mail(_dot_)imc(_dot_)org>
 Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> writes:

I propose to leave the type application/iotp and to drop this discussion
until there is a request for a real-world application where thre would be
some advantage to the end user for application/foo-xml to be handed to an
XML viewer directly instead of being written to disk.

Just stumbled on this discussion. I know zilch about iotp, and no more
than epsilon about xml. So let me recap and see if I understand the
problem.

Something arrives described as application/iotp (or is it text/iotp - who
cares).

If you were expecting such things, and are in the business of handling
iotp objects (whatever they are), you presumably possess an iotp engine,
and have configured your mailer to use it when it sees application/iotp.

So far so good. But if you are not expecting such messages, you might like
to try to understand it to find out what is going on. If the best your
mailer can do is put it in a file and tell you it as recevied an
application/octet-stream, that leaves you on your own to figure it out.

But (so I gather) help is at hand. Iotp can also be understood by an XML
engine, which, even if it doesn't understand iotp fully, can at least
print out the structure of the document, so you know where to start
looking in order to figure it out.

So, what the message needs to say is "if you have an iotp engine, then
that should be the first choice for interpreting this document; but if
not, give it to your XML engine, which will at least have an intelligent
try". Is that correct?

If so, then surely the correct MIME way to do it is something like:

Content-Type: application/iotp; alternative-format=xml

Surely not! This has a bunch of problems:

(1) It effectively defines a content-type parameter that spans multiple
    top-level content types. This is against the rules.
(2) It encodes information in a parameter that is immutable -- that is,
    every instance of application/iotp is XML. Such information is supposed
    to be part of the name; it is not what parameter are intended for.
(3) It tends to discourage proper content-type labelling -- why bother when
    the XML flag is all you need? 

FYI, Keith already proposed approximately this, but as a content-disposition
parameter, which avoids (1) and (2) but makes (3) even more of a problem.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>