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

"t.petch" <ietfc@btconnect.com> Thu, 10 November 2011 10:34 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3707521F8A96 for <apps-discuss@ietfa.amsl.com>; Thu, 10 Nov 2011 02:34:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.508
X-Spam-Level:
X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgUPNEIrNuUp for <apps-discuss@ietfa.amsl.com>; Thu, 10 Nov 2011 02:34:34 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr09.btconnect.com [213.123.26.187]) by ietfa.amsl.com (Postfix) with ESMTP id 63CCA21F8A80 for <apps-discuss@ietf.org>; Thu, 10 Nov 2011 02:34:33 -0800 (PST)
Received: from host86-177-208-97.range86-177.btcentralplus.com (HELO pc6) ([86.177.208.97]) by c2beaomr09.btconnect.com with SMTP id FCN83492; Thu, 10 Nov 2011 10:34:25 +0000 (GMT)
Message-ID: <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: <dcrocker@bbiw.net>, "Apps Discuss" <apps-discuss@ietf.org>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp><CAC4RtVBNL_nTCwBsMQpEKS9kXUF7aj9yEstef7yrzwi8qYAQDg@mail.gmail.com> <4EBB7660.6040904@dcrocker.net>
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-Premium-Raw: score=7/50, refid=2.7.2:2011.11.10.94215:17:7.586, ip=86.177.208.97, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_MEDIA_BODY, __CP_URI_IN_BODY, BODY_SIZE_4000_4999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2beaomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EBBA8B1.01B3, ss=1, fgs=0, ip=0.0.0.0, 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-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2011 10:34:36 -0000

----- Original Message -----
From: "Dave CROCKER" <dhc@dcrocker.net>
To: "Apps Discuss" <apps-discuss@ietf.org>
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
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?

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