ietf-822
[Top] [All Lists]

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

2000-03-10 17:52:27
Ned writes:

I expect to see heavy use of XML under model and image at least. I suspect
there will be some use even under audio, video, and message.

This is why I'm strongly opposed to an top-level content-type. Like it or
not, we chose the outermost facet of our typing space in such a way that
XML has mutiple overlaps. It isn't even close to the orthogonality that's
needed. And it is way too late to change our typing space choice.

This leaves us with suffixes as tne only option IMO. And while I'm not
enthusiastic about the suffix, I don't agree that it does the harm that
you seem to think it does.

the problem with adding this frob to the content-type is that it
(a) encourages other folks to add other frobs, and
(b) removes the "right side of a content-type" as a place where
anything else which is orthogonal to presentation encoding can be added.
and thus it limits the future extensibility of the content-type scheme.

But on the other hand, I don't see much value in labelling something with a
name that has a -xml suffix when te content isn't XML. Seems more than a bit
misleading, doesn't it?

maybe we need a frob to indicate that the content is
gzip-compressed?

No, because that's an encoding issue. If we want gzip to be labelled we
need to do a CTE for it. This is a red herring in this context.

surely that would be generally useful?

It isn't a content-type.

(so you could have application/foo and application/foo-gzip)?
maybe we need a frob to indicate that the content is (in somebody's view)
obscene?

No, because that's othogonal to most if not all content types. It calls for
a separate field.

how about a frob to indicate that the content is asn.1/ber?

No, because in general knowing that something is ASN.1 is pointless unless you
know the data definition. (For example, try decoding an X.400 P1 object to get
the bodypart content out without knowing ASN.1 structure. Can't be done, even
if you assume BER.)

I don't think that -xml is the last frob that people will want to
add to MIME typing.

Perhaps not, but its the first real one to come along in almost 10 years.
One of these every 10 years isn't a bad run rate.

and there are other places where this frob could be added and
do less harm.  maybe as a content-disposition parameter? e.g.

content-disposition: attachment; filename="foo.bar";
      default_interpretation="application/xml"

This would work, but I see it as far more dangerous, actually. Adding
information that is very much a part of the type definition elsewhere
encourages improper content-type labelling.

Again, I'm not especially supportive of the frob as I fail to see very much
utility in it. But I also don't oppose it. I see it as "mostly harmless".

                                Ned