Re: [apps-discuss] font/*

Eric Burger <eburger@standardstrack.com> Wed, 09 November 2011 21:00 UTC

Return-Path: <eburger@standardstrack.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 1CDB01F0C53 for <apps-discuss@ietfa.amsl.com>; Wed, 9 Nov 2011 13:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.641
X-Spam-Level:
X-Spam-Status: No, score=-102.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, 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 V2Zny7t9XlCv for <apps-discuss@ietfa.amsl.com>; Wed, 9 Nov 2011 13:00:39 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 90F3F1F0C4D for <apps-discuss@ietf.org>; Wed, 9 Nov 2011 13:00:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=hNduliC+zPBHhxNBo7aCboHeRaF6zTaLruKv4LPq9WtvDt+3lkJyl4BijzNnEvet1L4WX4tAoRocxK3K0fvZZru8MFiiYaqUPTCWMEPqprGTVd7RWYw4qmQ7hXRFQMdE;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:61740 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1ROFGA-00028C-54 for apps-discuss@ietf.org; Wed, 09 Nov 2011 13:00:38 -0800
From: Eric Burger <eburger@standardstrack.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/signed; boundary=Apple-Mail-227--1032149059; protocol="application/pkcs7-signature"; micalg=sha1
Date: Wed, 9 Nov 2011 16:00:34 -0500
In-Reply-To: <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
References: <4EB86078.8070904@stpeter.im> <BDC0F178EEB88CC4B3D24020@PST.JCK.COM> <4EB8D0F4.9020907@it.aoyama.ac.jp> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
Message-Id: <56B202FE-ED81-4C36-AB4C-0A809F51D009@standardstrack.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
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: Wed, 09 Nov 2011 21:00:41 -0000

Sounds like a call for a BOF.

On Nov 9, 2011, at 8:06 AM, John C Klensin wrote:

> Hi Martin,
> 
> The links you gave to earlier messages don't work, but I don't
> recall "killing" a font proposal.  See inline below.
> 
> --On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
> Dürst\"" <duerst@it.aoyama.ac.jp> wrote:
> 
>> ...
>>> 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
>> ...
>> 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.
> 
> I was, and remain, very hesitant about creating new top-level
> types.  As others have noted, it is a big deal.  There are
> several reasons for that but at least one important one is that
> the model for what an application is expected to do when it
> encounters an unknown top-level type is not, IMO, really well
> sorted out.  One cannot do much of anything (in that sense, it
> isn't much different from an application/ subtype), but it isn't
> clear how one should present that fact to a user who doesn't
> have much understanding or vocabulary about what is going on at
> the content-type level.
> 
> "Model/" (as described in RFC 2077) was not a problem because
> the request came from a particular community for a particular
> type of use, one on which there was little or no likelihood of
> interaction with other types, especially with multipart content.
> I assume that the community that wanted that type is using it,
> but confess to never having seen the type in the wild.  If
> others haven't either, that reinforces the claim that the
> "model/" type really is independent of the others.
> 
> If font/* is simply a "type and a subtype", then I'm inclined to
> agree with those who say "use application/".  Certainly it is
> feasible to say, e.g., "application/OpenType", specify it as
> being bound to the OpenType font definition model, say some
> things about encoding and parameters, and move on.  The fact
> that it and an equally hypothetical "application/TrueType" both
> encode/carry fonts creates no more of a requirement or
> justification for a top-level type than the observation that
> there application/ subtypes for Open Document and MSWord formats
> implies that we should have a top-level type for WordProcessor/
> or DocumentFormatter/.  And, as Graham and others have pointed
> out, we use "application/" (a lot) for subtypes that require
> processing or installation before something else can make use of
> them.
> 
> I think a font/ top-level type would be worth looking at
> carefully if there really were a use case for which some
> application/ subtypes would not be appropriate.  One of those
> might lie along the path of compound documents that I mentioned
> in the context of "image/".   Perhaps there might be others, or
> perhaps not.  "Distinct media type" doesn't do much for me
> because what is, and is not, is largely in the mind of the
> beholder.
> 
>> 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.
> 
> I used "Definition Language" to refer to what you are referring
> to as a "format" (which often means something else in this
> context).  I don't have enough contemporary knowledge to know
> what would be most accurate and consistent with current
> terminology -- another topic for Mark's wife or some other
> typographic expert.
> 
>> 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.
> 
> I don't know what that means in practice.  Having struggled
> several times with what needs to be a parameter on a media type
> and subtype, it isn't obvious that parameters are unnecessary
> even if the information can be deduced from content.   I am
> particularly concerned about transmission of files that contain
> parts of a typeface family, but not all of it, as well as about
> a type and subtype that don't even identify the type family and
> hence may require a lot of work before a system can decide
> whether to install it.
> 
> I also don't know whether all "Definition Languages" in use
> today contain the same descriptor information in reasonably
> compatible formats.   If some do and others require, e.g., the
> name of the font in supplemental information because only the
> glyph descriptions are stored in the file, then there is a lot
> of justification for parameters across the board if one is going
> to have a well-designed top-level type with homogeneous
> subtypes.  Of course, homogeneous subtypes are not a
> requirement, but, if each subtype will have to establish its own
> parameter model, it seems to me that the argument for just
> sticking with "application/" becomes stronger.
> 
>> 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.htm
>> l). 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.)
> 
> While the "model/" spec is rather short, it contains the
> elements I'm trying to advocate here: a clear description of why
> a top-level type is needed, a discussion of use cases, and
> definitions of enough subtypes to make the use cases clear, as
> well as the required templates and mechanisms for defining
> future subtypes.
> 
> Recommendation to those who want this:  Work on a few subtype
> definitions.  Sort the details, such as what parameters are
> needed, out with the typographic community.  Examine the use
> cases.   The would would need to be done --and would be almost
> the same-- for a subtype of application/ or a subtype of font/.
> With those tentative subtype descriptions in hand, the rest of
> us will be a lot more able to identify commonalities and to
> participate in an evaluation of whether a top-level type is
> really justified.
> 
> best,
>   john
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss