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

[David Singer <[e-mail]>]

Thanks Vlad

I think a valid question to ask is whether "application/", being a grab-bag for everything not-image-video-or-audio, is a good idea.  Perhaps that horse has already bolted, but the idea of a top-level type its, in my mind, to give the recipient some clues as to what the thing claims to offer, what use it might be, how it might be screened, and so on.  image/ tells you it's an image, that will need rendering space;  video and audio need timing, and video also needs rendering space, and audio needs audio presentation capability.

But application/ tells you nothing at all; it's the wild west, anything goes.  it might need rendering, it might make sound, it might need timing, it might be an unpresented resource (like a font), it might be… anything!

On Nov 15, 2011, at 15:22 , Levantovsky, Vladimir wrote:

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

David Singer
Multimedia and Software Standards, Apple Inc.