In <01JMZJU6AN6Y0000EX(_at_)MAUVE(_dot_)INNOSOFT(_dot_)COM>
ned(_dot_)freed(_at_)innosoft(_dot_)com writes:
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.
But what if that is the way the real world operates? You can't say that,
just because MIME has such a rule, then the real world is constrained to
stick with data types that fit within that rule. The real world ain't
like that. So maybe the time has come to review the rule.
But it isn't the way the real world operates. The rule is there for a reason
and a lot of stuff depends on it. Indeed, it is precisely _because_ top
level types are used in the real world that the rule is important.
(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.
Well is it immutable (I don't know)? Is every IOTP object also an XML
object?
I believe so.
Or do the classes IOTP-but-not-XML and XML-but-not-iotp exist?
As far as I know they do not.
And
is it the case that all the other object types that might have XML
representations *always* have those representations?
In the case of something whose type ends in -xml as in this proposal, the
answer is yes.
In short, this is a specious argument.
(3) It tends to discourage proper content-type labelling -- why bother when
the XML flag is all you need?
Indeed. If it is the case that all these things you are talking about are
always best and most conveniently regarded as subtypes of XML, then fine.
But people seem to be saying that this is not so.
Again, there are two classes of applications here that we're trying
to satisfy. The -xml suffix seems to satisfy both and every other proposal
satisfies one at most.
Ned