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

["Levantovsky, Vladimir" <[e-mail]>]

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,
Vladimir



> -----Original Message-----
> From: David Singer [mailto:[e-mail]]
> Sent: Monday, November 14, 2011 6:50 PM
> To: Ned Freed
> Cc: "Martin J. Dürst"; Larry Masinter; [e-mail];
> [e-mail] 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
> 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).
> >
> >> 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.