Re: [apps-discuss] font/*

["Martin J. Dürst" <[e-mail]>]

Hello John, others,

On 2011/11/09 22:06, John C Klensin wrote:
> Hi Martin,
>
> The links you gave to earlier messages don't work,

Please try again at
http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html

If it still doesn't work (it worked for me), please make sure to put all 
the pieces back together that have been split over more than one line. 
It seems that in my mail, the final "l" of the ".html" extension got 
split off to the next line.

> but I don't
> recall "killing" a font proposal.  See inline below.

I have to apologize for using the word "killing", I regretted it shortly 
after sending the mail.

It was after I looked at
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html,
which links to your mail.

Reading your mail, and David Singer's summary, it's not surprising that 
they gave up. You ask for very strong arguments of why a new top-level 
type is needed, and application/ isn't good enough. You also ask them to 
examine whether there's not a more general concept behind the top-level 
type of font.

For people e.g. on this list who now your writing style, such a mail 
wouldn't have been too much of a show-stopper. But for outsiders, and 
given that this was the only feedback they got (which isn't your fault), 
it must have sounded quite scary.

> --On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
> Dürst\""<[e-mail]>  wrote:
>
>> ...
>>> Well, I think that a top-level would be in order -- these are
>>> really different from the existing types.  Things may have
>>> changed, but my recollection from when I had some exposure to
>>> them in the early 90s is that there are a bunch of font
>> ...
>> There is no need to overengineer this stuff. Like all other
>> types, it's simply a top level type, and a subtype. A very
>> rough approximation of what could end up in the subtype can be
>> found here: http://en.wikipedia.org/wiki/Category:Font_formats.
>
> I was, and remain, very hesitant about creating new top-level
> types.

In general, that's a good idea.

> As others have noted, it is a big deal.

I think that it's a big deal mostly because some people think it's a big 
deal. I haven't seen any serious arguments about why it actually is a 
big deal.

> There are
> several reasons for that but at least one important one is that
> the model for what an application is expected to do when it
> encounters an unknown top-level type is not, IMO, really well
> sorted out.

RFC 2046 clearly envisions the creation of additional top-level types, 
and so if there are applications that aren't ready to deal with them, 
then that's their fault. But I don't think that in actual practice, this 
would be a problem (if you think it will, please show me a concrete case).

>  One cannot do much of anything (in that sense, it
> isn't much different from an application/ subtype), but it isn't
> clear how one should present that fact to a user who doesn't
> have much understanding or vocabulary about what is going on at
> the content-type level.

Do you think the user will be more confused by a message saying
     Downloading file, type: font/woff, Open or Save?
or by a message saying
     Downloading file, type: application/woff, Open or Save?

At least in the former, they might see the word "font" and get a clue. 
So I think this issue is essentially irrelevant.


> "Model/" (as described in RFC 2077) was not a problem because
> the request came from a particular community for a particular
> type of use, one on which there was little or no likelihood of
> interaction with other types, especially with multipart content.

I think this is wrong. There is lots of potential interaction between 3D 
models and text, audio, video, images, and other application data. The 
reason you aren't seeing any of this is because there are umpteen 
reasons (which I don't think we need to discuss here) for why 3D hasn't 
caught on (yet?) on the Web and the Internet.

> I assume that the community that wanted that type is using it,
> but confess to never having seen the type in the wild.  If
> others haven't either, that reinforces the claim that the
> "model/" type really is independent of the others.

See above.

> If font/* is simply a "type and a subtype", then I'm inclined to
> agree with those who say "use application/".  Certainly it is
> feasible to say, e.g., "application/OpenType", specify it as
> being bound to the OpenType font definition model, say some
> things about encoding and parameters, and move on.  The fact
> that it and an equally hypothetical "application/TrueType" both
> encode/carry fonts creates no more of a requirement or
> justification for a top-level type than the observation that
> there application/ subtypes for Open Document and MSWord formats
> implies that we should have a top-level type for WordProcessor/
> or DocumentFormatter/.  And, as Graham and others have pointed
> out, we use "application/" (a lot) for subtypes that require
> processing or installation before something else can make use of
> them.

We can always throw everything into application/. But then, why do we 
have image/, audio/, and video/ (and text/; I'm putting text/ in 
parentheses because there are very specific handling rules that don't 
apply to any of the other types) in the first place?

For people involved with fonts (and many others, as we have seen on this 
list), fonts are not images, they are not video, and they are not audio, 
but they are also not just application data. These people (including 
many typographers and other font experts, with lots of Web and Internet 
experience) think that font/ is the right thing to do. They have tried 
several times (see my mail to Peter).


> I think a font/ top-level type would be worth looking at
> carefully if there really were a use case for which some
> application/ subtypes would not be appropriate.  One of those
> might lie along the path of compound documents that I mentioned
> in the context of "image/".   Perhaps there might be others, or
> perhaps not.  "Distinct media type" doesn't do much for me
> because what is, and is not, is largely in the mind of the
> beholder.

So why don't we change policies so that new image types also have to be 
registered under application/?

>> If some kind of 'Definition Language' is used inside a font
>> format, then that's just something under the hood. My
>> understanding is that some popular formats such as OpenType
>> essentially are mergers resulting from the "Definition
>> Language" wars in the early 1990.
>
> I used "Definition Language" to refer to what you are referring
> to as a "format" (which often means something else in this
> context).  I don't have enough contemporary knowledge to know
> what would be most accurate and consistent with current
> terminology -- another topic for Mark's wife or some other
> typographic expert.

There are experts who have the knowledge. They have tried to register 
font/ previously. Why don't we trust them?


>> Also, typeface, style, and
>> applicable range of sizes shouldn't be necessary as part of
>> the mime type because it's part of the content.
>
> I don't know what that means in practice.  Having struggled
> several times with what needs to be a parameter on a media type
> and subtype, it isn't obvious that parameters are unnecessary
> even if the information can be deduced from content.   I am
> particularly concerned about transmission of files that contain
> parts of a typeface family, but not all of it, as well as about
> a type and subtype that don't even identify the type family and
> hence may require a lot of work before a system can decide
> whether to install it.

With Web fonts, or with fonts attached to other documents such as 
emails, partial fonts are indeed very important. But they will be 
installed temporarily. Also, for Web fonts, the main usage is via CSS, 
which makes sure there's enough meta-information.


> I also don't know whether all "Definition Languages" in use
> today contain the same descriptor information in reasonably
> compatible formats.   If some do and others require, e.g., the
> name of the font in supplemental information because only the
> glyph descriptions are stored in the file, then there is a lot
> of justification for parameters across the board if one is going
> to have a well-designed top-level type with homogeneous
> subtypes.

Would it be possible to let the font experts figure this out?


>> Some such parameters were proposed in
>> http://tools.ietf.org/html/draft-singer-font-mime-00, and may
>> still be necessary, but not as much as 7 years ago, when you
>> apparently shot down the proposal (see
>> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.htm
>> l). So if the font experts say they really need a parameter,
>> we'll keep it, but we don't have to make thing more
>> complicated than necessary in advance.
>
>> The only RFC that defined a new top-level type is RFC 2077
>> (http://tools.ietf.org/html/rfc2077). It's rather short, and I
>> expect the font/ RFC to be even shorter unless it also
>> includes some registrations for actual subtypes (I'd probably
>> do it in two separate documents, one for the top-level type
>> and another for some low hanging subtypes, but I'll leave the
>> decision to whoever does the actual work.)
>
> While the "model/" spec is rather short, it contains the
> elements I'm trying to advocate here: a clear description of why
> a top-level type is needed, a discussion of use cases, and
> definitions of enough subtypes to make the use cases clear, as
> well as the required templates and mechanisms for defining
> future subtypes.

I don't disagree here (except that RFC 2077 doesn't actually define 
subtypes, just gives some example of things that might be expected).

I agree that having a bit of text on why a new subtype was chosen can't 
hurt at all. But I think we have to be careful and not make this a 
sysiphean exercise by requiring something like a proof that a new 
top-level type was absolutely necessary because otherwise the world will 
go under.

> Recommendation to those who want this:  Work on a few subtype
> definitions.  Sort the details, such as what parameters are
> needed, out with the typographic community.  Examine the use
> cases.   The would would need to be done --and would be almost
> the same-- for a subtype of application/ or a subtype of font/.
> With those tentative subtype descriptions in hand, the rest of
> us will be a lot more able to identify commonalities and to
> participate in an evaluation of whether a top-level type is
> really justified.

Sorry, John, but they have tried before. They don't have much trust 
anymore. If we again tell them what sounds to them as "bring it on, and 
we'll do our best to shoot it down and make your life miserable",  then 
they won't do the work. They won't do it for font/, and they also won't 
do it for application/. I don't think that's what we want.

Regards,    Martin.