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

"Martin J. Dürst" <> Thu, 10 November 2011 11:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3090621F8AD8 for <>; Thu, 10 Nov 2011 03:04:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.576
X-Spam-Status: No, score=-99.576 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1CP2JHOzjgEf for <>; Thu, 10 Nov 2011 03:04:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4CB5E21F8A71 for <>; Thu, 10 Nov 2011 03:04:08 -0800 (PST)
Received: from ([]) by (secret/secret) with SMTP id pAAB47Bb016746 for <>; Thu, 10 Nov 2011 20:04:07 +0900
Received: from (unknown []) by with smtp id 6627_5e94_b595d88a_0b8b_11e1_89fb_001d096c566a; Thu, 10 Nov 2011 20:04:07 +0900
Received: from [IPv6:::1] ([]:48329) by with [XMail 1.22 ESMTP Server] id <S156B7EF> for <> from <>; Thu, 10 Nov 2011 20:04:10 +0900
Message-ID: <>
Date: Thu, 10 Nov 2011 20:03:50 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 11:04:09 -0000

On 2011/11/10 15:59, Dave CROCKER wrote:
> Folks,
> On 11/10/2011 2:02 PM, Barry Leiba wrote:
>>> 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.
> That states a basic direction/goal: To have a lower hurdle than perhaps
> was there before.
> Does it have any basic downsides?

In particular for the example now at hand, not that I know.

> My sense from the latest round of postings, including Ned's, is that
> there is no current reason to impose a high hurdle on TLCTs.
> Consensus check
> ===============
> Is there anyone out there who believes that it is extremely expensive or
> dangerous to introduce new, top-level Content-Type and that, therefore,
> the barrier to new TLCTs should be (kept) high?
> Assuming the answer and the consensus is no, that still leaves open what
> pragmatic guidance is to be used for accepting or rejecting a request
> for a TLCT. (We could take the ICANN approach and just filter based on
> huge gobs of money, but I doubt that model will transfer to the IETF.)

I hope it won't, too.

> So far, the most cogent guidance I've seen seems to be related to the
> justification in the model spec (RFC 2077):
> "The important fact is that these
> various subtypes can be converted between each other with less loss
> of information then to that of other primary types. This fact groups
> these subtypes together into the model primary type. All of the
> expected subtypes have several features in common and that are unique
> to this primary type."
> I had suggested a guideline in terms of "dispatching" to different
> applications. Ned's note offered a better framing, in terms of common
> code among a set of content sub-types. A particular form of such code,
> implied by the model document, is for translating among sub-types.

That would definitely apply to the font/ proposal.

> Martin pointed out an "administrative" issue quite different from the
> basic registration scaling or decentralization I cited, namely the
> search for related types by an implementer, where separate sub-tables
> would be helpful. He noted:
> as a good example.
> Consensus Check
> ===============
> So, I think this leaves guidance in favor of a new top-level
> content-type if one or more of the following apply:
> 1. Strong semantic relationship among the sub-types
> 2. Likelihood of some common code for the set of sub-types
> 3. Expectation that implementors will benefit from easily discovering
> the current set of sub-types in the registry.
> Does this summarize the guidance that should be offered for justifying a
> new TLCT?

I still think that past, present, and future examples of new top-level 
types were/are/will be so rare that having explicit guidelines doesn't 
make much sense.

But while we are at it, I'd suggest that we add some degree of 
parallelism with existing top level types (I think font/ fits in well 
with image/, audio/, and video/).

On the negative side, we could include:

- Expectation that there will only be a single subtype, or only a couple.

- Majority of existing types already registered under another type (e.g. 

Regards,   Martin.