On 3/13/00 at 2:13 PM -0800, ned(_dot_)freed(_at_)innosoft(_dot_)com wrote:
>(3) It tends to discourage proper content-type labelling -- why
>bother when the XML flag is all you need?
If this were actually true, then why not have the defined
Content-Type be "application/xml" with a parameter of
"xml-content=iotp"?
I'd actually have no problem with this if the majority of applications
could dispatch this way. Unfortunately they cannot. In fact it is even
worse: We now have places where MIME types appear that don't allow
for *any* parameters. Yes, it is broken, but it is reality. (We're just
lucky that plain text, multiparts, or any of the various other MIME
content types where parameters are vital aren't used in these places.)
If the XML is all you need to know,
"application/xml" would let you know that you can act on this part;
if you want to dispatch to a particular XML program (like an IOTP
application), then the parameter will be enough for you to do that.
The fallacy here is that there are supposedly two groups of applications being
talked about and you are mixing them up. Specifically, there are ones that need
to know that something is XML, and ones that need to know the more specific
label. And neither of them are likely to be able to dispatch on a parameter
value.
My guess is that the IOTP people will say, "No, we need to know from
the Content-Type that it's IOTP so we can dispatch to IOTP
applications easily with existing code." If their argument is
correct, then proper Content-Type labelling will be forced to
continue.
For IOTP perhaps. But likely not for other XML-derived types.
Basically my objection here can be rephrased to say that you are adding
gratuitous silly states to the protocol. And I'm opposed to silly states
because experience says that if you allow them they will happen. You now have a
parameter which had better appear on *every* object of this type or else some
things will break.
Argument #3, BTW, perfectly well applies to "application/iotp-xml":
If it really is true that "the XML flag is all you need", then we can
expect to see "application/octet-stream-xml" for everything that even
remotely smells like XML before long.
No, because we already have it: We call it application/xml.
I think this argument against labeling outside of type/subtype (be it
a parameter, a Content-Disposition, or some other Content-* field)
just doesn't hold water.
I disagree. I think this sort of labelling will wreak all sorts of
havoc, whereas a proper subtype naming will not.
The idea of parsing subtype names makes me
think of parsing Subject fields for content; it's the wrong place to
embed real information.
The two cases could not be more different; about the only thing they have in
common is that they both can appear in email.
Ned