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

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Nov 2011 17:29:58 -0800

# My personal opinion is that registering font/* type still makes a lot of sense and this is something we need to do

I think any definition of a new top level type should come with some use cases, some protocol or operation, which is more functional, reliable, better, improved, useful,.

#  even if it involves re-registering some of the existing subtypes under the new font/* tree.

Types with two names seem like more of a problem, and re-registering existing types with a potentially long tail of overlapping use problematic.

#  I brought this up for discussion at today's conference call with W3C WebFonts WG, and the general opinion was that having font/* type registered would still be a good thing for the industry.

I think we still need at least one concrete practical use case. Just asking in the abstract won't necessarily get you a good answer.

David Singer:
# I think that it's way overdue for us to work out whether everything [not [image | video | audio]] should be application, and if not, why not.

Everything else should be "application" unless there's a good reason for it.   For text/*, we at least had some hope of common "charset" parameters having some meaning. For image/*, there's at least the use case of a HTTP "accept: image/*" header (although I'm not sure how useful that is, in practice.).

But I'm having trouble imagining a use case for "font/*", even in the context of sniffing.

Larry
--
http://larry.masinter.net

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 18 Nov 2011 16:25:36 +0900

Hello Larry,

> I think any definition of a new top level type should come with some use cases, some protocol or operation, which is more functional, reliable, better, improved, useful,.

I don't see anything like this for image/, video/, or audio/ in the 
original documents. They just started with the assumption that these are 
not the same media, so they shouldn't be in the main top-level type. 
What's the problem with applying this same argument to font/? What will 
stop working, or otherwise produce undesired consequences, if we 
introduce font/?

> Types with two names seem like more of a problem, and re-registering existing types with a potentially long tail of overlapping use problematic.

It's definitely not optimal. It would have been better to register these 
under font/ much earlier. We can still learn from that experience.

> I think we still need at least one concrete practical use case. Just asking in the abstract won't necessarily get you a good answer.

I don't think we need to continue to press for concrete, practical, 
fail-safe, everybody-will-be-satisfied use cases. At some point, not 
everybody will be convinced of the absolute need of font/. But that's 
fine. The main point is that those who think having font/ is useful can 
use it.

> But I'm having trouble imagining a use case for "font/*", even in the context of sniffing.

With "sniffing", do you mean content negotiation? "font/*" can indeed be 
as useful as "image/*". "image/*" expresses that the recipient can 
handle a wide range of images. "font/*" expresses that the recipient can 
handle a wide range of fonts. Why wouldn't this be useful?

Regards,    Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 19 Nov 2011 16:44:20 +0900

On 11/18/11 4:25 PM, "Martin J. Dürst" wrote:
>> I think any definition of a new top level type should come with some
>> use cases, some protocol or operation, which is more functional,
>> reliable, better, improved, useful,.
> 
>> Types with two names seem like more of a problem, and re-registering
>> existing types with a potentially long tail of overlapping use
>> problematic.
> 
>> #  I brought this up for discussion at today's conference call with
>> W3C WebFonts WG, and the general opinion was that having font/* type
>> registered would still be a good thing for the industry.
>>
>> I think we still need at least one concrete practical use case. Just
>> asking in the abstract won't necessarily get you a good answer.
> 

Agreed. So, who holds the pen on writing an I-D?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/