Re: [apps-discuss] seeking pragmatic guidelines for content-type 'structure': when to go top-level?
"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Thu, 10 November 2011 10:53 UTC
Return-Path: <duerst@it.aoyama.ac.jp>
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 48A6521F8A62 for <apps-discuss@ietfa.amsl.com>; Thu, 10 Nov 2011 02:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.279
X-Spam-Level:
X-Spam-Status: No, score=-99.279 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 7x3XXolbt+jt for <apps-discuss@ietfa.amsl.com>; Thu, 10 Nov 2011 02:53:49 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 946B421F8783 for <apps-discuss@ietf.org>; Thu, 10 Nov 2011 02:53:49 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAAArmcA018798 for <apps-discuss@ietf.org>; Thu, 10 Nov 2011 19:53:48 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5910_598d_4506078a_0b8a_11e1_bbef_001d096c5782; Thu, 10 Nov 2011 19:53:48 +0900
Received: from [IPv6:::1] ([133.2.210.1]:39132) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S156B7E0> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Thu, 10 Nov 2011 19:53:52 +0900
Message-ID: <4EBBAD2C.5000106@it.aoyama.ac.jp>
Date: Thu, 10 Nov 2011 19:53:32 +0900
From: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>
References: <4EBB3CFC.5050608@dcrocker.net> <4EBB5310.6080103@it.aoyama.ac.jp><CAC4RtVBNL_nTCwBsMQpEKS9kXUF7aj9yEstef7yrzwi8qYAQDg@mail.gmail.com> <4EBB7660.6040904@dcrocker.net> <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
In-Reply-To: <013101cc9f8b$2e1fac80$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: dcrocker@bbiw.net, Apps Discuss <apps-discuss@ietf.org>
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:53:50 -0000
On 2011/11/10 18:28, t.petch wrote: > ----- 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, It's nice for you to admit that your argument is based on FUD. But I think its a bad idea to use that for standards development. Ned has given some very good arguments for why most if not all software uses the full (i.e. major/minor) type for dispatching,... All the experience I have (which I have to admit is way less than Ned) points in the same direction. > 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)? If it will have taken the IETF more than 10 years to get around to finally approve the font/ top level type, we can't blame developers when it takes them 3-5 years to deploy that. And the deployment time is the same if we register new types under application/. Regards, Martin. > 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
- [apps-discuss] seeking pragmatic guidelines for c… Dave CROCKER
- Re: [apps-discuss] seeking pragmatic guidelines f… Martin J. Dürst
- Re: [apps-discuss] seeking pragmatic guidelines f… Barry Leiba
- Re: [apps-discuss] seeking pragmatic guidelines f… Dave CROCKER
- Re: [apps-discuss] seeking pragmatic guidelines f… Barry Leiba
- Re: [apps-discuss] seeking pragmatic guidelines f… t.petch
- Re: [apps-discuss] seeking pragmatic guidelines f… Ned Freed
- Re: [apps-discuss] seeking pragmatic guidelines f… Martin J. Dürst
- Re: [apps-discuss] seeking pragmatic guidelines f… Martin J. Dürst
- Re: [apps-discuss] seeking pragmatic guidelines f… Frank Ellermann
- Re: [apps-discuss] seeking pragmatic guidelines f… t.petch
- Re: [apps-discuss] seeking pragmatic guidelines f… Nathaniel Borenstein
- Re: [apps-discuss] seeking pragmatic guidelines f… Ned Freed
- Re: [apps-discuss] seeking pragmatic guidelines f… t.petch
- Re: [apps-discuss] seeking pragmatic guidelines f… Nico Williams
- Re: [apps-discuss] seeking pragmatic guidelines f… Larry Masinter