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

Larry Masinter <> Sat, 12 November 2011 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5632A21F84DF for <>; Sat, 12 Nov 2011 12:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.115
X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UJb+n0Di9WR8 for <>; Sat, 12 Nov 2011 12:25:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2630E21F8A80 for <>; Sat, 12 Nov 2011 12:25:53 -0800 (PST)
Received: from ([]) by ([]) with SMTP ID; Sat, 12 Nov 2011 12:25:56 PST
Received: from (inner-relay-4b []) by (8.12.10/8.12.10) with ESMTP id pACKPbQB001913; Sat, 12 Nov 2011 12:25:37 -0800 (PST)
Received: from ( []) by (8.12.10/8.12.9) with ESMTP id pACKPXLV025523; Sat, 12 Nov 2011 12:25:34 -0800 (PST)
Received: from ([]) by ([]) with mapi; Sat, 12 Nov 2011 12:25:33 -0800
From: Larry Masinter <>
To: "t.petch" <>, "Martin J. Dürst" <>
Date: Sat, 12 Nov 2011 12:25:30 -0800
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcyheTdYnPX+VrnbTTGaIgyaA9nG5g==
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: David Singer <>, "" <>, "" <>
Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
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: Sat, 12 Nov 2011 20:25:57 -0000

I see no use case for why having font/opentype is any better than application/opentype

The only use case I can imagine from looking at
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/.

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

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?

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).

To be specific: in
 I would propose changing 

   In some cases a new media type may not "fit" under any currently
   defined top-level content type.  Such cases are expected to be quite
   rare.  However, if such a case does arise a new top-level type can be
   defined to accommodate it.  Such a definition MUST be done via
   standards-track RFC; no other mechanism can be used to define
   additional top-level content types.


   Originally, it was believed that there might be rare cases where new media types might not "fit" under the currently defined top level types. However, the benefit of introducing a new top level type is likely to be low compared to the additional cost and confusion.  While a new top-level type can be defined by a standards-track RFC, it is likely that additional applications can be satisfied by using the "application/" top-level type.

(Additional comments on draft-freed-media-type-regs in )

-----Original Message-----
From: [] On Behalf Of t.petch
Sent: Saturday, November 12, 2011 3:28 AM
To: Martin J. Dürst
Subject: Re: [apps-discuss] font/*

----- Original Message -----
From: "Martin J. Dürst" <>
To: "t.petch" <>
Cc: <>; <>
Sent: Thursday, November 10, 2011 11:47 AM

> On 2011/11/10 18:06, t.petch wrote:
> > Dave
> >
> > My bibles say
> >
> > Type(face) Family; Courier, Futura, Century Schoolbook,  ..
> > Typeface; one of the above with a defined
> >   - Style: Roman, Italic
> >   - Weight: Light, Semibold, Bold, ...
> >   - Width: Ultracondensed, Condensed, Expanded, ...
> > Type Font; one of the above with a defined Size
> >   - eg 12-point
> As I said before in a mail to Dave, the last point worked well for 
> lead type or bitmap fonts, but technology has moved beyond.


The concepts have not changed and remain useful, IMO, in any discussion on presentation.  What has changed is the implementation detail so when I download a new package to my PC, then it will apply to all Fonts, within a Typeface, as opposed to having a separate module for each Font.
(Incidentally, my bibles all relate to laser printing ie to modern technology and have nothing to do with lead:-).

But more significantly, as other posts have clarified for me, this thread is nothing to do with fonts but with type definition languages, so perhaps it should be 'type/*'.

Tom Petch

> Regards,    Martin.

apps-discuss mailing list