Vincent Lau writes:
You can continue to come up with all sorts of examples that don't fit
the hierarchy very well. Such examples may even lead us to change the
hierarchy. However, the presence of a hierarchy remains useful -- if I
get something of type image/foo, where I have never heard of foo
before, it is nice to know that it is an image, and that trying to
display it on my VT100 is probably not going to work, no matter how
much software I FTP from archives to deal with the format. And there
are (and will continue to be) lots of subtypes that do fit cleanly
under a single already defined type.
It seems to me that "subtype" is more important than "type". And the
"type" is just a hint. Does it make sense to have "type [ / class]"
where type is a unique identifier (equivalent to the current subtype),
and the class is optional (pretty much equivalent to the current type)?
This is almost a reverse of what is defined in current RFC-XXXX.
It depends on what you mean by important. The subtype of audio is not at all
important if I have no way of playing a recording of _any_ form on my machine.
In this case audio is more important than whatever subtype was specified.
Similarly, the subtypes of multipart are certainly less important than the
type, since the type is all you need to generally know how to parse. (In
analogy to audio, where you know you need a speaker, you need an encapsulation
boundary scanner for multipart.)
So I disagree. I think the general type is much more important. I think
the hierarchy should remain the same.
I believe that by defining "type/class" may close some holes in RFC-XXXX.
Since RFC-XXXX states that type is mandatory, but subtype is optional.
Given that "Content-Type: IMAGE" is completely legal, but meaningless.
In this case, the UA can only inform the user that there is an image
document. This information is too vague.
IMAGE without a subtype is not currently defined. We may eventually define
it, but presently it is NOT legal. This is not an example of any "hole"
in anything.
I fail to see how flipping two fields can close any holes anywhere, anyway.
If "type [ / class]" is used, the worst case scenario will be
"Content-Type: FOO". From the UI point of view, I would rather
to inform the user that he/she has a document whose type is FOO (unknown
to the UA), displaying it or not will be an optional action for the UA.
This is bogus! If you have a document of type FOO (using your terminology
for the moment), all I can say is that I don't know how to do whatever to
it. The user may have an application available that does know how to do
whatever do the object. You cannot tell. But you _can_ tell, if you get
an image and the user's equipment is not capable of dealing with a whole
class, that the user has to go somewhere else to do something meaningful
with the message.
I think this is a vital distinction. It is important to be able to say that
"you cannot do anything meaningful to that here without an X" versus saying
"you don't have the software to convert Y into a format that you can use on an
X".
At least, this UA provides a little concrete information. When the user
gets "Content-Type: FOO/IMAGE", the UA has more information about the
type FOO and may not display the image on VT100 terminal. This is same
as your example.
Defining Content-Type as "type [ / class]" has another benefit. The
RFC-XXXX compliant UA's can read all the existing RFC-1049 messages
because they are sharing the same meaning of types.
This was made a non-goal explicitly long ago. See the list archives for
the discussion.
For example,
Content-Type: PEM / MESSAGE (type is PEM, class is MESSAGE)
Content-Type: MESSAGE (MESSAGE can be a type without a class)
Content-Type: TEXT
Content-Type: MUTLIPART (MULTIPART type does not need a class)
Content-Type: POSTSCRIPT / TEXT-PLUS
Content-Type: POSTSCRIPT (compatible with RFC 1049)
Content-Type: INTERLEAF / BINARY (an Interleaf document in binary format)
Content-Type: INTERLEAF (an Interleaf document; let Interleaf
Frankly, I think this looks awful. (It is also incorrect; Multipart does have
classes: MIXED and DIGEST.)
Left to right --> Most general to least general is a bias of
the present scheme. It is totally intentional; it is easier to read, easier
to understand, and puts the more important information first. If we were using
right-to-left languages I'd want it the other way, but we are not (at least
most of us are not).
Would you like to have your chapter/section/subsection document numbers done
the other way, as subsection/section/chapter? I think this proposal
amounts to the same thing.
However, in one sense this is a cosmetic change -- you're just flipping
strings. That's fine, if you think this is a viable approach (I don't) you
can do it in your user agent. I don't want to do it in mine; I want to
use the types to group application definitions into broad categories. This is a
big win for me, and I think other people have found it to be a big win as well.
Mark Crispin writes:
No, no, no, no, no, no, no, no, no!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Please review the past messages on this group to find out why there is an
express limit on the number of types.
Mark is correct; this has all been discussed at length before.
The purpose of the type is to give the most general description of what the
contents are. By intent it is an extremely limited set, so that the complete
set can be itemized in a single document and all implementations everywhere
can be expected to know about all of them. If anything is to be done to the
set of types, it should be to further reduce their number, not add more.
[Obvious: fold TEXT-PLUS into TEXT, fold IMAGE, AUDIO, VIDEO into BINARY.]
The current nine is a result of a lot of compromising on the part of a number
of people, and changing them now (adding or removing) would create show-
stoppers among people who formerly were in agreement.
Mark is right about this too.
This expressly excludes POSTSCRIPT, INTERLEAF, and even PEM.
Yup.
Why is it, just as we finally crush one resurgence of an old bad idea from a
newcomer, that we get another one??? Conspiracy theorists would have a field
day...
Once again Mark is right. Vincent, I should have been rude and simply said
"resolved issue; we're not going to reopen it".
Vincent, I know you didn't realize what you stepped into, but please, for
everyone's sake, review the past 6 months' worth of IETF-822 messages before
you dive in and get lots of people teed off at you. Thanks!!
I concur.
Ned