Re: [apps-discuss] font/* (and draft-freed-media-type-regs)

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Mon, 14 November 2011 07:27 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 AA42021F8CA4 for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 23:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.607
X-Spam-Level:
X-Spam-Status: No, score=-99.607 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 0Y9XhPZuAXPh for <apps-discuss@ietfa.amsl.com>; Sun, 13 Nov 2011 23:27:08 -0800 (PST)
Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E805721F8CA3 for <apps-discuss@ietf.org>; Sun, 13 Nov 2011 23:27:06 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAE7R63W019668 for <apps-discuss@ietf.org>; Mon, 14 Nov 2011 16:27:06 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 73a4_0656_0df60280_0e92_11e1_aa25_001d096c566a; Mon, 14 Nov 2011 16:27:06 +0900
Received: from [IPv6:::1] ([133.2.210.1]:38530) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S156CFF9> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Mon, 14 Nov 2011 16:27:05 +0900
Message-ID: <4EC0C2C8.2010500@it.aoyama.ac.jp>
Date: Mon, 14 Nov 2011 16:27:04 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <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: Larry Masinter <masinter@adobe.com>
References: <C68CB012D9182D408CED7B884F441D4D0611DABF0F@nambxv01a.corp.adobe.com>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D0611DABF0F@nambxv01a.corp.adobe.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: David Singer <singer@apple.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "gadams@xfsi.com" <gadams@xfsi.com>
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
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: Mon, 14 Nov 2011 07:27:08 -0000

Hello Larry,

On 2011/11/13 5:25, Larry Masinter wrote:
> I see no use case for why having font/opentype is any better than application/opentype

It's just fine if you, and some others, don't see it. Does that mean 
that you have to fight against it? You haven't shown, even less 
mentioned, any problem for font/opentype.

My guess is that we would have around 10 or so font types registered 
(and no font type sniffing) if a font/ top level type had been approved 
in a 1990'ish timeframe.

> The only use case I can imagine from looking at
> http://tools.ietf.org/html/draft-singer-font-mime-00
> is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).
>
> But there isn't really any common processing proposed that one could do knowing that you have font/x... so I agree with Graham that there isn't a case for font/.

Well, actually, if an OS has a capability of "install that font 
[temporarily] for me", and the OS knows which formats it can handle, 
then that would be a good use case, isn't it?

Also, the use case of easier searching, and the use case of content 
negotiation (font/*) was mentioned.


> The arguments in favor seem to be of the form "well, we allow for new top level types, so why not use it?"

That's definitely an argument, in particular because for the people 
concerned, font/ looks very parallel to image/, video/, audio/,...


> I also recall a number of years ago an attempt to define "chemical/*" as a new top level type for use in defining file formats?

So what? Were there good reasons to reject it? Or was it rejected 
because some people believed that new top level types were "A BIG 
NO-NO"? Or because of some FUD?

> My conclusion from this discussion is that we should declare the MIME hierarchy closed to new top level types; we've only gotten very limited use and value out of the hierarchy, compared to the pain and difficulty (text/xml vs application/xml).

The problems between text/xml and application/xml are very specific. And 
they may be interpreted to say that tying particular processing rules to 
particular types, unless absolutely necessary (e.g. structured types), 
may be a bad idea. That doesn't mean that top-level types in general are 
a bad idea.

The reason that we have gotten very little value out of registering new 
top level types may be mostly that virtually no new types have been 
registered, because people are claiming that we get very little value 
out of them. It sounds funny, but it isn't.


Regards,   Martin.