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

Ned Freed <> Fri, 11 November 2011 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE8F811E8087 for <>; Thu, 10 Nov 2011 17:48:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EcBk+XbCPEnL for <>; Thu, 10 Nov 2011 17:48:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 33A6A11E8089 for <>; Thu, 10 Nov 2011 17:48:16 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Thu, 10 Nov 2011 18:45:04 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Thu, 10 Nov 2011 18:44:59 -0800 (PST)
Message-id: <>
Date: Thu, 10 Nov 2011 18:29:36 -0800 (PST)
From: Ned Freed <>
In-reply-to: "Your message dated Thu, 10 Nov 2011 14:59:44 +0800" <>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <> <> <> <>
To: Dave CROCKER <>
Cc: Apps Discuss <>
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: Fri, 11 Nov 2011 01:48:19 -0000

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

I want to be very very clear here: It depends critically on whether or not it
has additional special semantics that MIME processors have to understand. New
leaf types generally do not have such semantics even when they are associated
with a new top-level type (text is a possible exception here).

However, a new top-level type with multipart semantics would be a *huge* deal,
especially if it had a different syntax than the existing multipart type.

New types with message semantics are a little better, but only a little.
message/global is something of a pain for two reasons: (1) The differing
syntax (CTE allowed) has to be accomodated, and (2) You have to know when has
to be decoded and when it must not be.

The only way a new leaf top-level type can have similar impact is if it
needs to be handled specially in some way when doing basic display actions.
Changes to text/plain are potentially problematic for this reason - adding
format=flowed support was actually a fair bit of work.

But I don't see how any of this applies to font/*.

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

Oh, I don't know. We always seem to be strapped for cash...

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

As others have pointed out, it is also potentially helpful in certain sorts of
negotiation activities.

>   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

Yes, this is the key.

>       2.  Likelihood of some common code for the set of sub-types

It's more like it's convenient to be able to treat them as a group. It doesn't
necessarily result in code sharing.

>       3.  Expectation that implementors will benefit from easily discovering the
> current set of sub-types in the registry.

Certainly a nice to have. I would also add:

        4.  It makes sense politically, socially, or both.

The [un]happiana discussion has just as much to do with perceptions as with
reality. If putting some stuff under a new top-level helps get stuff
registered and has no real cost, then I'm all for it.
> Does this summarize the guidance that should be offered for justifying a new

Pretty close.