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

Barry Leiba <> Thu, 10 November 2011 06:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49F1F11E80A4 for <>; Wed, 9 Nov 2011 22:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.939
X-Spam-Status: No, score=-102.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ota6YcJL3t5W for <>; Wed, 9 Nov 2011 22:07:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9D4AD11E8097 for <>; Wed, 9 Nov 2011 22:07:50 -0800 (PST)
Received: by yenl7 with SMTP id l7so1873301yen.31 for <>; Wed, 09 Nov 2011 22:07:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rg/spooqxvQ8IgEjrhkBai+JKIyb3GpA35F6mZ0F4gI=; b=l/W0v6mFiQlZCYzqeS+MluOcHFe9JMT0K6TUwXnvwL8dX1ZtJAN3QDJt2QSm2rlF8F oKqjGKy0Ht6YJUAlzBPLeUtdQV3/kRshx/zLvFZDjLOSLYgG9YD5lMfH8oA0KQxc0F/Q dyxlBTBGSqM5rlBs31E+s94LEmGEd9co6QjRs=
MIME-Version: 1.0
Received: by with SMTP id qi7mr1553308obc.43.1320904925311; Wed, 09 Nov 2011 22:02:05 -0800 (PST)
Received: by with HTTP; Wed, 9 Nov 2011 22:02:05 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 10 Nov 2011 01:02:05 -0500
X-Google-Sender-Auth: IE-w-oTz21lX-Sq_ZgqSmS4J8XY
Message-ID: <>
From: Barry Leiba <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: Apps Discuss <>
Subject: Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Nov 2011 06:07:51 -0000

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

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