Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?

[Barry Leiba <[e-mail]>]

I agree with Martin's comments, and especially with this one:

>> I am not seeing how a TLCT vs. sub-type distinction affects this issue.
>> That is, it seems to me that
>>
>> C-T: major/minor
>>
>> has equal software utility as
>>
>> C-T:application/major-minor
>>
>> Any useful difference seems to be to fall under #1, above, rather than
>> under a software behavior distinction. What am I missing?
...
>> The 'model' document talks about a benefit of grouping sub-types, but I
>> do not understand what the software benefit is, in terms of MIME
>> Content-type. That is, the benefit seems to be a local benefit within
>> the model world, rather than more generally within the MIME world.
>> Again, what am I missing?
>
> You may not be missing too much. It's easy to imagine a world with a flat
> type system, or with a type system that didn't have image/, audio/, and
> video/.
>
> But the fact is that we have a major/minor type system. We can as well make
> reasonable use of it.

As I said in the other thread (on font/*), we already have the concept
of saying "This is text," "This is an image," and "This is audio," and
I see only negative points in insisting that everything other than the
few TLMTs that we're already defined have to be "application".  We
should do some filtering and apply some judgment, of course, but
making everything the equivalent to "application/image-jpeg" is silly
and non-useful.

The point of "image/xxx" was to allow a program to say "I do/don't
handle images," and have it send the media content over to its image
processing, or to shortcut things because it just doesn't do images at
all.  The same thinking applies to other things, and it's not just
application or administrative "convenience".  Of course, the problem
with "application/xxx-yyy" is that unless we define a hierarchy for
the subtype field, the processing I described above that could apply
to "image/jpeg" can't apply to "application/image-jpeg".

For what it's worth, I think it was a mistake to put office document
stuff into "application"; we should have made a TLMT for "document",
so we could have, say, "document/spreadsheet" or "document/MS-excel"
or "document/ODS", "document/PDF", "document/presentation", and so on.
 (For that matter, "text/html" seems a bit silly these days, and
"document/html" might be more appropriate, but I digress.)

I do understand that we don't want to have TLMTs proliferating out of
control.  On the other hand, I think we're being *way* too restrictive
about defining them when there's a reasonable argument why they make
sense.

And I'm happy to participate in a document that talks about this.

Barry