Re: [apps-discuss] font/*

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Tue, 08 November 2011 06:49 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 8086511E80F4 for <apps-discuss@ietfa.amsl.com>; Mon, 7 Nov 2011 22:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.252
X-Spam-Level:
X-Spam-Status: No, score=-99.252 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_83=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 IWBd8jp1-DBW for <apps-discuss@ietfa.amsl.com>; Mon, 7 Nov 2011 22:49:55 -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 73E3911E80F0 for <apps-discuss@ietf.org>; Mon, 7 Nov 2011 22:49:55 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id pA86neZr000480 for <apps-discuss@ietf.org>; Tue, 8 Nov 2011 15:49:41 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2206_18d8_d4ea43e0_09d5_11e1_9457_001d096c5782; Tue, 08 Nov 2011 15:49:40 +0900
Received: from [IPv6:::1] ([133.2.210.1]:59653) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S156A630> for <apps-discuss@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 8 Nov 2011 15:49:44 +0900
Message-ID: <4EB8D0F4.9020907@it.aoyama.ac.jp>
Date: Tue, 08 Nov 2011 15:49:24 +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: John C Klensin <john-ietf@jck.com>
References: <4EB86078.8070904@stpeter.im> <BDC0F178EEB88CC4B3D24020@PST.JCK.COM>
In-Reply-To: <BDC0F178EEB88CC4B3D24020@PST.JCK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] font/*
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: Tue, 08 Nov 2011 06:49:56 -0000

Hello John,

On 2011/11/08 8:32, John C Klensin wrote:
>
>
> --On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre
> <stpeter@stpeter.im>  wrote:
>
>> In talking with folks at the W3C meeting last week, I heard
>> yet again of interest in defining a Content Type for fonts.
>> Would anyone active in the IETF Applications Area want to work
>> on such a spec? And do folks here think a new top-level
>> content type is needed for fonts?
>
> Well, I think that a top-level would be in order -- these are
> really different from the existing types.  Things may have
> changed, but my recollection from when I had some exposure to
> them in the early 90s is that there are a bunch of font
> definition languages out there.  Unless all but one has
> atrophied or one could pick one to go with the top-level type,
> there is going to be a messy problem in which one either needs
> to have
>    font/DefinitionLanguage fonttype=Foo
> or another round of
>    font/Foo+DefinitionLanguage
> I'd hope we could avoid the latter, especially since some of
> those languages and definitional methods don't scale over a very
> broad range, s.t. one might actually need a tuple of Definition
> Language, Typeface, Style, and applicable range of sizes.
>
> Happy to try to help with this, but there better be some real
> typographic experts involved.  We do not want to create a
> top-level type only to find ourselves locked into one particular
> kind of solution (even if it is open source rather than
> vendor-specific).  I might still be able to carry on a useful
> conversation with such an expert, but it has been a very long
> time since I've had to do that, things have changed, and I've
> forgotten a lot of what I once knew.

There is no need to overengineer this stuff. Like all other types, it's 
simply a top level type, and a subtype. A very rough approximation of 
what could end up in the subtype can be found here: 
http://en.wikipedia.org/wiki/Category:Font_formats.

If some kind of 'Definition Language' is used inside a font format, then 
that's just something under the hood. My understanding is that some 
popular formats such as OpenType essentially are mergers resulting from 
the "Definition Language" wars in the early 1990. Also, typeface, style, 
and applicable range of sizes shouldn't be necessary as part of the mime 
type because it's part of the content.

Some such parameters were proposed in 
http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be 
necessary, but not as much as 7 years ago, when you apparently shot down 
the proposal (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if 
the font experts say they really need a parameter, we'll keep it, but we 
don't have to make thing more complicated than necessary in advance.

The only RFC that defined a new top-level type is RFC 2077 
(http://tools.ietf.org/html/rfc2077). It's rather short, and I expect 
the font/ RFC to be even shorter unless it also includes some 
registrations for actual subtypes (I'd probably do it in two separate 
documents, one for the top-level type and another for some low hanging 
subtypes, but I'll leave the decision to whoever does the actual work.)


Regards,   Martin.