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

[Dave CROCKER <[e-mail]>]

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