Re: [apps-discuss] font/*

[Ned Freed <[e-mail]>]

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

I have to agree with Martin here. In my experience whether or not a type is a
"big deal" has everything to do with whether or not it represents a new
structuring convention that needs to be handled (leaf versus non-leaf as far as
MIME is concerned) and nothing to do with whether or not a new top level is
involved.

So: Introduce some font/* types, and as long as I don't have to take it apart
to find other parts inside I'm fine. My media type tables (and all of the
tables in software I've encountered) deal in whole type names and let you
specify pretty much anything.

EAI's introduction of message/global, OTOH, *is* a big deal, even though it is
not a new top-level type. For such types I have to carefully consider in every
context where MIME processing is being done if I want to "go inside" or not,
and perhaps even provide options to control whether or an object of this type
is seen as a leaf or non-leaf. This is actually a bigger deal to me than
a new content-transfer-encoding.

New subtypes of text can also be a big deal, as can adding parameters to
existing text subtypes, because this stuff affects the basic rendering of
messages in user agents.

The only place I know where there might be a problem with a new top-level
font type is SDP. I confess to knowing next to nothing about SDP, but
it uses media types and has some really screwy constraints on on what it can
handle. I'm not seeing an application for font types in SDP, but if there
is someone more familiar with it sohuld be consulted on possible issues.

Anyway, my position on this is if there are behaviors that need to apply to
font parts in the aggregate then a new font top level type is in order to deal
with that. If, OTOH, there's no common behavior needed, a top-level font type
is still a nice-to-have.

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

I'm sorry, but this is clearly misreading the intent, and I think at least some
of the letter, of RFC 2046. There was a time when we thought it was good idea
to talk about processing top-level types as entities in their own right, but
this was early in the MIME effort. We later came to the conclusion that in the
case of leaf parts, unknown types should be treated like
application/octet-stream and unknown top-levels should be treated like
application (but with the subtypes in their own namespace, of course).

Again, the problem for processing agents of all types is really with non-leaf
objects, where clean defaulting rules really aren't possible.

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

Well, I wouldn't go quite that far - if there was a significant widely deployed
set of applications that would break then we need to take application set into
account. But no such issue exists in any application set I know of.

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

Exactly.

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

Agreed.

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

I actually have encountered objects with the model type. Then again, I did
quite a lot of mathematical modelling work before I got into email, so this may
be a holdover from that.

And they didn't cause any problems either. I had no trouble associating
handlers with them and as always there was the "extract to file" approach.

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

Well, this gets into whether or not there's an aggregrate handling approach
that makes sense for the type. Font seems to qualify in this regard.

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

Seems reasonable to me.

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

In practice the issue of what to register where has never been much of a
problem. Speaking now as media types reviewer, I have not infrequently  pushed
back on top-level type choices, usually successfully and always amicably.

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

Meta-information needs to either be part of the font or part of whatever
is using the font. Putting it in, say, content-type parameters strikes me
as a bad idea. Media features could be used if this is a real issue, but I
rather suspect it is not.

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

I don't think you're going to find as much variability amongst these things as 
people seem to be worried about here. I'll also point out that similar issues
exists for images and video, where we went to a lot of trouble to define a
fairly elaborate media features language, which AFAICT pretty much nobody uses.

> >> 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'm ambivalent about whether or not a bunch of subtypes are defined in the
base document.

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

Exactly!

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

+1

				Ned