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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 18 November 2011 07:25 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 DCC321F0C56 for <apps-discuss@ietfa.amsl.com>; Thu, 17 Nov 2011 23:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.636
X-Spam-Level:
X-Spam-Status: No, score=-99.636 tagged_above=-999 required=5 tests=[AWL=0.154, 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 JmsmaYRTZCxC for <apps-discuss@ietfa.amsl.com>; Thu, 17 Nov 2011 23:25:44 -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 195B41F0C51 for <apps-discuss@ietf.org>; Thu, 17 Nov 2011 23:25:43 -0800 (PST)
Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id pAI7PhGa024808 for <apps-discuss@ietf.org>; Fri, 18 Nov 2011 16:25:43 +0900
Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 54e7_5247_86393a24_11b6_11e1_877a_001d096c566a; Fri, 18 Nov 2011 16:25:43 +0900
Received: from [IPv6:::1] ([133.2.210.1]:40923) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S156EF72> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 18 Nov 2011 16:25:45 +0900
Message-ID: <4EC60870.4080805@it.aoyama.ac.jp>
Date: Fri, 18 Nov 2011 16:25:36 +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: <C68CB012D9182D408CED7B884F441D4D0611DAC608@nambxv01a.corp.adobe.com>
In-Reply-To: <C68CB012D9182D408CED7B884F441D4D0611DAC608@nambxv01a.corp.adobe.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Ned Freed <ned.freed@mrochek.com>, "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "gadams@xfsi.com Adams" <gadams@xfsi.com>, Chris Lilley <chris@w3.org>, David Singer <singer@apple.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: Fri, 18 Nov 2011 07:25:49 -0000

Hello Larry,

On 2011/11/18 10:29, Larry Masinter wrote:
> I think any definition of a new top level type should come with some use cases, some protocol or operation, which is more functional, reliable, better, improved, useful,.

I don't see anything like this for image/, video/, or audio/ in the 
original documents. They just started with the assumption that these are 
not the same media, so they shouldn't be in the main top-level type. 
What's the problem with applying this same argument to font/? What will 
stop working, or otherwise produce undesired consequences, if we 
introduce font/?


> #  even if it involves re-registering some of the existing subtypes under the new font/* tree.
>
> Types with two names seem like more of a problem, and re-registering existing types with a potentially long tail of overlapping use problematic.

It's definitely not optimal. It would have been better to register these 
under font/ much earlier. We can still learn from that experience.


> #  I brought this up for discussion at today's conference call with W3C WebFonts WG, and the general opinion was that having font/* type registered would still be a good thing for the industry.
>
> I think we still need at least one concrete practical use case. Just asking in the abstract won't necessarily get you a good answer.

I don't think we need to continue to press for concrete, practical, 
fail-safe, everybody-will-be-satisfied use cases. At some point, not 
everybody will be convinced of the absolute need of font/. But that's 
fine. The main point is that those who think having font/ is useful can 
use it.


> David Singer:
> # I think that it's way overdue for us to work out whether everything [not [image | video | audio]] should be application, and if not, why not.
>
> Everything else should be "application" unless there's a good reason for it.   For text/*, we at least had some hope of common "charset" parameters having some meaning. For image/*, there's at least the use case of a HTTP "accept: image/*" header (although I'm not sure how useful that is, in practice.).
>
> But I'm having trouble imagining a use case for "font/*", even in the context of sniffing.

With "sniffing", do you mean content negotiation? "font/*" can indeed be 
as useful as "image/*". "image/*" expresses that the recipient can 
handle a wide range of images. "font/*" expresses that the recipient can 
handle a wide range of fonts. Why wouldn't this be useful?


Regards,    Martin.