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

Dave CROCKER <dhc@dcrocker.net> Thu, 10 November 2011 02:55 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6CD21F86EE for <apps-discuss@ietfa.amsl.com>; Wed, 9 Nov 2011 18:55:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGwLYwn70LHW for <apps-discuss@ietfa.amsl.com>; Wed, 9 Nov 2011 18:55:18 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22FB121F8449 for <apps-discuss@ietf.org>; Wed, 9 Nov 2011 18:55:18 -0800 (PST)
Received: from [192.168.0.229] (61-31-89-133.static.tfn.net.tw [61.31.89.133]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pAA2sspr006330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Wed, 9 Nov 2011 18:55:07 -0800
Message-ID: <4EBB3CFC.5050608@dcrocker.net>
Date: Thu, 10 Nov 2011 10:54:52 +0800
From: Dave CROCKER <dhc@dcrocker.net>
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 <apps-discuss@ietf.org>
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 (sbh17.songbird.com [72.52.113.17]); Wed, 09 Nov 2011 18:55:17 -0800 (PST)
Subject: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2011 02:55:18 -0000

Folks,

The font thread has re-raised the issue of registering a Top-Level Content-Type 
(TLCT).  I haven't seen clear statements or documents of a theory or rationale 
that would guide accepting or rejecting a request for a TLCT, and I think we 
should (finally) remedy this deficiency.

In an earlier note I cited a recollection of resistance to new TLCTs.  But I 
don't remember the reasons, though I seem to recall both substance and vigor to 
the reasons.

We should try to resurrect or re-create a simple, pragmatic set of guidelines, 
and document them, so we don't have to go through the kind of vague exchanges 
happening now, with respect to arguing whether a new TLCT is appropriate.

The purpose of this thread is to press for a brief document that resolves this 
kind of debate and that can be used going forward in designing the "structure" 
of new registration groups.  This ought to be in terms of real pragmatics, 
rather than aesthetics or personal preference.

I can think of only two pragmatic issues in registering names like this:

    1.  Administrative convenience.  A hierarchy permits administrative grouping 
and possibly the convenience of delegating subsets of registration.  Obviously 
the DNS is the prime example.  At very large scale, this is essential.  At small 
scale, extra structure can be a hassle.

        I'm not seeing convenience as an issue for Content-Type, but perhaps 
others see the issue differently.  That is, my sense is that the entire data 
base of content-types is small enough to a) remain centralized, and b) not 
otherwise needing to benefit from sub-setting.

        This calls to question why there are /any/ sub-types, of course,  but 
I'd rather cast the issue in terms of going forward, rather than of history.


    2.  Code dispatching.  Different content-types invoke different software 
segments.  Parameters are input to the code but do invoke different "programs".

        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?


To take the 'font' discussion as an immediate, real-world exemplar, I think the 
above says that a logical hierarchy should have the representation engine be 
superior to the typeface or font specification, since it affects software 
dispatch.

Also, I don't see what the driving need for a TLCT is for font (or face...) 
It's aesthetically appealing, but I don't see the technical or administrative 
benefit.  Hence, here's one last:  what am I missing?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net