Re: [apps-discuss] font/*

[John C Klensin <[e-mail]>]

Hi Martin,

The links you gave to earlier messages don't work, but I don't
recall "killing" a font proposal.  See inline below.

--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.  As others have noted, it 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.  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.

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

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.

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.

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

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

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.  Of course, homogeneous subtypes are not a
requirement, but, if each subtype will have to establish its own
parameter model, it seems to me that the argument for just
sticking with "application/" becomes stronger.

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

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.

best,
   john