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

[Dave CROCKER <[e-mail]>]

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?

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:

      http://www.iana.org/assignments/media-types/image/index.html

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?

d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net