Re: [apps-discuss] font/*

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

--On Thursday, November 10, 2011 10:40 +0900 "\"Martin J.
Dürst\"" <[e-mail]> wrote:

> 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

That did it, thanks.

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

No problem.  It does seem as if I'm consistent in wondering
whether a top-level type is actually necessary.   I am slightly
less concerned about the implications of a relatively small
number of subtypes than I was then.  But, as others have said
more emphatically than I have, a new top-level type should
require a lot of justification.

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

That note suggests that mine was the only comment.   If so, I'd
assume the proposal basically ran out of steam because not
enough people cared.   In that sense, more progress has already
been made this time because there has been a discussion.

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

I think others have made the same request wrt new top-level
types rather than application/.   Of course the existence of PFR
(which I assume is still in use) as an application/ subtype
doesn't strengthen the case that a separate top-level type is
needed.

And, yes, creating a new top level type for a half-dozen or
fewer subtypes does seem wasteful, but, again, I don't feel
quite as strongly about that as I did seven years ago (although
others may).

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

I think Dave Singer actually does know my writing style.  But,
more important (at least IMO), the lack of response should have
been scary for another reason: hard to propel something like
this through the IETF if very few people care.   The lack of
response might not have meant that, but...

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

I tried to outline this earlier but, again, others may have
different reasons.   I think a top-level type requires either
relatively strong justification that it is a necessary special
case or specification of what happens with unrecognized
subtypes, parameters, etc.  That is a lot of definitional work,
followed by significant implementation work... just not
something to be done lightly because some class of file formats
seems special.

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

I'll let Ned or Nathaniel speak to that, but my impression at
the time was that it allowed for additional types because not
doing so would represent a claim to really comprehensive
knowledge of the future.  It wasn't intended as license to go
out and create a bunch of them -- application/ was really
intended to be quite comprehensive wrt the things that need, as
someone else put it, to be processed and usually stored
somewhere, not rendered directly to the user.  We render text,
video, and images.  Fonts are used to build tables that are then
used with a list of characters and other information to create
something that is rendered.  The latter is either pretty close
to application/ or, as I suggested in 2004, represents a
different sort of creature that should be generalized.

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

If I were a user, I'd be pretty upset by either message.  They
both look like gibberish and I'd have no clue which action I
should take.

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

More so if one considered application/font-woff (as in
application/font-tdpfr).

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

Ok.  But, if you see the distinction in terms of the
interactions, make that case for fonts.  I'm actually much more
open to this idea than you seem to have concluded (and was open
to it in 2004) - I just think the questions I've asked (as
questions, not rebuttal) are appropriate and should be addressed
in a serious way... with a default if there aren't satisfactory
answers of "use application/".

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

Because of what I'm describing as the rendering issue.  And the
compound body/message ("multipart") issue.

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

To repeat what I said earlier, I'd like to see some I-Ds that
drill down into the subtypes.  The observation that Bitstream
thought that application/ was adequate for PFR (and did write a
document) is some evidence that "these people" are not unanimous
that a top-level type is needed.  Now, if someone came forward
and said "we tried using application/font-tdpfr and the fact
that 'font' wasn't a top level type caused the following
specific problems so we have learned that putting it into
application/ was a bad idea", I, at least, would find that
extremely persuasive.  

That isn't the only way to persuade me (and presumably, others
who have suggested using application/ subtypes).  But I think
somewhat more is needed than an assertion that "people involved
with fonts" want and/or need this.

>> 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/?

See above, plus the fact that image/ already exists as a basic
type and part of what you are arguing against is a principle
that we should not create a lot of top-level types... or any
more of them without considerable justification.

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

But, unless you propose to restrict the use of this type to the
web, the broader questions need to be addressed.  And I haven't
seen anything proposed yet that would result in a different
handling or definitional model for temporary versus more
permanent installations.  Again, an I-D that explored or
specified these things would be a big help here.

I said before that I've got a relatively open mind about this.
The one thing about which I don't have an open mind is the idea
of saying "ok, let's create a top-level 'font/' type and assume
that the subtype definitions and all of the other issues will
sort themselves out".  I think a top-level type needs an
architecture, not just a string of characters.  YMMD.

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

Sure.  Get someone to produce an I-D or three.  Don't expect
people to believe that they will figure it out because they are
font experts.

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

I don't think anyone has suggested that.  Certainly I haven't.

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

As far as I can tell, only one subtype definition has been tried
and it resulted in RFC 3073.  If "tried before" means "thought
about it but decided to not post drafts and open discussions"
then I sympathize but I don't know how to get unstuck (in this
area or others with which you are familiar) from vague claims
about obstructions and problems.

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

I agree.  So your help, and Peter's, and that of others, are
going to be needed to be sure that the message comes across
well.  But I don't think that either a top-level type, or even
an application/ subtype, are going to get very far unless there
are definitions that can be examined by others and shown to work
and to be sufficiently comprehensive.

regards,
    john