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

"Levantovsky, Vladimir" <> Tue, 15 November 2011 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9354011E80B3 for <>; Tue, 15 Nov 2011 15:22:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KavsHFtepHMS for <>; Tue, 15 Nov 2011 15:22:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 59FD311E8088 for <>; Tue, 15 Nov 2011 15:22:13 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKTsL0I7HnqXVXdzfpVCOJzyw44Q/; Tue, 15 Nov 2011 15:22:14 PST
Received: from ([]) by ([]) with mapi; Tue, 15 Nov 2011 18:22:10 -0500
From: "Levantovsky, Vladimir" <>
To: David Singer <>, Ned Freed <>
Date: Tue, 15 Nov 2011 18:22:10 -0500
Thread-Topic: [apps-discuss] font/* (and draft-freed-media-type-regs)
Thread-Index: AcyjKDWoX23OaD0kT12CW7nwptH5aQAulHRQ
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 15 Nov 2011 15:24:31 -0800
Cc: " Adams" <>, "" <>
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: Tue, 15 Nov 2011 23:23:31 -0000

Hi all,

First of all, thank you David. This is probably one of those times when I don't mind having been volunteered.

I did express a good deal of interest in the past in registering "font" as a new top-level type, and the preliminary exploration work done few years ago had shown that we would've had about two dozens of subtype entries eligible for font/* tree.

However, the sentiments expressed at the time were very similar to this discussion; I was told that applying for a new top-level type was "A BIG NO-NO", that prior attempts to register font/* failed, and that unless I am willing to dedicate significant part of my life to this activity (i.e. applying and lobbying for a new top-level "font" type) the effort would most likely get us nowhere. 

As far as "application/*" is concerned, aside from being heavily overloaded with various unrelated subtypes and, therefore, utterly confusing IMHO - I am not in a position to argue why font/* is better than application/* - it [font/*] just makes sense. However, since font/* was (and still is) not an option, there are already a number of font types registered either as vendor-specific or as part of the application/* tree - both "ancient" (tdpfr) and very recent (woff) come to mind. 

In fact, SC29/WG11 is in the process of finalizing a new application (as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to apply for a new "application/font-sfnt" type using additional optional parameters to specify types of outlines and advanced layout mechanisms supported by a font. Doing so allows creating a flexible and extensible (albeit slightly cumbersome) mechanism to identify any SFNT-based font using same MIME type definition for a number of font flavors combining either TTF or CFF outlines with any currently known layout engine support (e.g. OpenType, AAT or SIL). Under the circumstances, this seemed to be a pragmatic way to compensate for the lack of "font" type.

I am sure that having a top-level "font/*" type would have made lives easier for many people, but having lived through the times where application/* was the only usable option to register font types (and having few of them already defined as such) - I have even less of an incentive to argue about it now. I would be happy to have font/* type defined, but I am not willing to spend my (and other people) valuable time to fight for it.

Thank you,

> -----Original Message-----
> From: David Singer []
> Sent: Monday, November 14, 2011 6:50 PM
> To: Ned Freed
> Cc: "Martin J. Dürst"; Larry Masinter;;
> Adams; Levantovsky, Vladimir
> Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
> I probably shouldn't volunteer people, but I know Vladimir Levantovsky
> has expressed interest in this question in the past.  I am sure he'd
> want to be aware of this discussion.  In fact, I am cc'ing him here..
> On Nov 14, 2011, at 13:44 , Ned Freed wrote:
> >> On 2011/11/13 5:25, Larry Masinter wrote:
> >> > I see no use case for why having font/opentype is any better than
> application/opentype
> >
> >> It's just fine if you, and some others, don't see it. Does that mean
> >> that you have to fight against it? You haven't shown, even less
> >> mentioned, any problem for font/opentype.
> >
> > Good point. I have no skin in this particular game - aside from
> slightly
> > complicating the media review process I have no personal need for
> font/*. But
> > if there's a constituency this type helps, I'm all for it.
> >
> >> My guess is that we would have around 10 or so font types registered
> >> (and no font type sniffing) if a font/ top level type had been
> approved
> >> in a 1990'ish timeframe.
> >
> > And we may or may not have any luck rectifying this at this late
> date. But I'm
> > not  seeing a reason not to try.
> >
> >> ...
> >
> >> > 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?
> >
> >> So what? Were there good reasons to reject it? Or was it rejected
> >> because some people believed that new top level types were "A BIG
> >> NO-NO"? Or because of some FUD?
> >
> > Didn't chemical kind of morph into model? Or am I getting the history
> confused?
> >
> >> > My conclusion from this discussion is that we should declare the
> >> > 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).
> >
> >> The problems between text/xml and application/xml are very specific.
> And
> >> they may be interpreted to say that tying particular processing
> rules to
> >> particular types, unless absolutely necessary (e.g. structured
> types),
> >> may be a bad idea. That doesn't mean that top-level types in general
> are
> >> a bad idea.
> >
> > Agreed.
> >
> >> The reason that we have gotten very little value out of registering
> new
> >> top level types may be mostly that virtually no new types have been
> >> registered, because people are claiming that we get very little
> value
> >> out of them. It sounds funny, but it isn't.
> >
> > No, it really isn't funny, is it?
> >
> > 				Ned
> David Singer
> Multimedia and Software Standards, Apple Inc.