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

Dave CROCKER <> Thu, 10 November 2011 06:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A80111E8088 for <>; Wed, 9 Nov 2011 22:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.788
X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_IP_061228=0.895, SARE_RECV_SPAM_DOMN0b=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wick9oAbbTGg for <>; Wed, 9 Nov 2011 22:59:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 283B911E80B4 for <>; Wed, 9 Nov 2011 22:59:56 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id pAA6xlGE011605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <>; Wed, 9 Nov 2011 22:59:55 -0800
Message-ID: <>
Date: Thu, 10 Nov 2011 14:59:44 +0800
From: Dave CROCKER <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Apps Discuss <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Wed, 09 Nov 2011 22:59:56 -0800 (PST)
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:59:57 -0000


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?

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.)

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.

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?



   Dave Crocker
   Brandenburg InternetWorking