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

"t.petch" <> Thu, 10 November 2011 10:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3707521F8A96 for <>; Thu, 10 Nov 2011 02:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GgUPNEIrNuUp for <>; Thu, 10 Nov 2011 02:34:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 63CCA21F8A80 for <>; Thu, 10 Nov 2011 02:34:33 -0800 (PST)
Received: from (HELO pc6) ([]) by with SMTP id FCN83492; Thu, 10 Nov 2011 10:34:25 +0000 (GMT)
Message-ID: <013101cc9f8b$2e1fac80$>
From: "t.petch" <>
To: <>, "Apps Discuss" <>
References: <> <><> <>
Date: Thu, 10 Nov 2011 10:28:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4EBBA8B0.0040, actions=tag
X-Junkmail-Status: score=10/50,
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EBBA8B1.01B3, ss=1, fgs=0, ip=, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
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: Thu, 10 Nov 2011 10:34:36 -0000

----- Original Message -----
From: "Dave CROCKER" <>
To: "Apps Discuss" <>
Sent: Thursday, November 10, 2011 7:59 AM
> 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
> 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?

Yes.  Based on FUD rather than concrete information, but what will all the
deployed software do when face with a new top-level Content-Type?  And how long
will it take for the makers of commercial software to incorporate this in their
products (1-2years) and how long will it take for that software to be widely
deployed(3-5 years)?

I just received an (antisocial) e-mail with .gif's attached, so I edited the
Content-Type to be font/various things, and my MUA took no notice, just
processed them as .gif.

I modified the Content-Description in the same way, same result.

Only when I modified the filename (eg to .ttf) did the MUA take any notice and
complain that the attachment was not a font, pdf etc.

I think we need to know this for commonly deployed platforms before we can say
it is not dangerous.

Tom Petch

> 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
>   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
> types by an implementer, where separate sub-tables would be helpful.  He
> as a good example.
>       Consensus Check
>       ===============
>       So, I think this leaves guidance in favor of a new top-level
> 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
> current set of sub-types in the registry.
> Does this summarize the guidance that should be offered for justifying a new
> d/
> --
>    Dave Crocker
>    Brandenburg InternetWorking