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

[Nathaniel Borenstein <[e-mail]>]

One other pragmatic condition might indicate the desirability of a top-level type:  the possibility of defining a reasonable default behavior for unrecognized subtypes.

Thus, for text/*, it is sometimes reasonable to just show users the raw text.  For image/* with an unrecognized subtype, it is sometimes reasonable to invoke a "smarter" program like xv.  For multipart/* you can at least find the parts, even if you're not sure what to do with them.  For video/* you  might choose to reject or strip out the data in a resource-challenged environment.  And I suspect this argues in favor of "font" as a TLCT, as the mail code may often be able to pass the data on to a "smarter" font engine.

I believe this is related, but not identical, to #1 and #2 below.  -- Nathaniel


On Nov 10, 2011, at 1:59 AM, Dave CROCKER wrote:

>     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?