Re: [apps-discuss] font/*

Eric Burger <> Wed, 09 November 2011 21:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1CDB01F0C53 for <>; Wed, 9 Nov 2011 13:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.641
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V2Zny7t9XlCv for <>; Wed, 9 Nov 2011 13:00:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90F3F1F0C4D for <>; Wed, 9 Nov 2011 13:00:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; 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 ([]:61740 helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <>) id 1ROFGA-00028C-54 for; Wed, 09 Nov 2011 13:00:38 -0800
From: Eric Burger <>
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, 09 Nov 2011 16:00:34 -0500
In-Reply-To: <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
To: " Discuss" <>
References: <> <BDC0F178EEB88CC4B3D24020@PST.JCK.COM> <> <24FBF40353ABCC3A4F15E82B@PST.JCK.COM>
Message-Id: <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [apps-discuss] font/*
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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\"" <> 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:
> 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
>>, and may
>> still be necessary, but not as much as 7 years ago, when you
>> apparently shot down the proposal (see
>> 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
>> ( 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