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

From: Larry Masinter <[email-masked]>
Date: Sat, 12 Nov 2011 12:25:30 -0800

I see no use case for why having font/opentype is any better than application/opentype

The only use case I can imagine from looking at
http://tools.ietf.org/html/draft-singer-font-mime-00
is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).

But there isn't really any common processing proposed that one could do knowing that you have font/x... so I agree with Graham that there isn't a case for font/.

The arguments in favor seem to be of the form "well, we allow for new top level types, so why not use it?"

I also recall a number of years ago an attempt to define "chemical/*" as a new top level type for use in defining file formats?

My conclusion from this discussion is that we should declare the MIME hierarchy closed to new top level types; we've only gotten very limited use and value out of the hierarchy, compared to the pain and difficulty (text/xml vs application/xml).

To be specific: in http://tools.ietf.org/html/draft-freed-media-type-regs
 I would propose changing 

OLD:
   In some cases a new media type may not "fit" under any currently
   defined top-level content type.  Such cases are expected to be quite
   rare.  However, if such a case does arise a new top-level type can be
   defined to accommodate it.  Such a definition MUST be done via
   standards-track RFC; no other mechanism can be used to define
   additional top-level content types.

NEW:

   Originally, it was believed that there might be rare cases where new media types might not "fit" under the currently defined top level types. However, the benefit of introducing a new top level type is likely to be low compared to the additional cost and confusion.  While a new top-level type can be defined by a standards-track RFC, it is likely that additional applications can be satisfied by using the "application/" top-level type.

(Additional comments on draft-freed-media-type-regs in http://www.ietf.org/mail-archive/web/happiana/current/msg00187.html )

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of t.petch
Sent: Saturday, November 12, 2011 3:28 AM
To: Martin J. Dürst
Cc: [email-masked]
Subject: Re: [apps-discuss] font/*

----- Original Message -----
From: "Martin J. Dürst" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 10, 2011 11:47 AM

> On 2011/11/10 18:06, t.petch wrote:
> > Dave
> >
> > My bibles say
> >
> > Type(face) Family; Courier, Futura, Century Schoolbook,  ..
> > Typeface; one of the above with a defined
> >   - Style: Roman, Italic
> >   - Weight: Light, Semibold, Bold, ...
> >   - Width: Ultracondensed, Condensed, Expanded, ...
> > Type Font; one of the above with a defined Size
> >   - eg 12-point
>
> As I said before in a mail to Dave, the last point worked well for 
> lead type or bitmap fonts, but technology has moved beyond.

Martin

The concepts have not changed and remain useful, IMO, in any discussion on presentation.  What has changed is the implementation detail so when I download a new package to my PC, then it will apply to all Fonts, within a Typeface, as opposed to having a separate module for each Font.
(Incidentally, my bibles all relate to laser printing ie to modern technology and have nothing to do with lead:-).

But more significantly, as other posts have clarified for me, this thread is nothing to do with fonts but with type definition languages, so perhaps it should be 'type/*'.

Tom Petch

> Regards,    Martin.

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 13 Nov 2011 13:05:11 -0500

> My conclusion from this discussion is that we should declare the MIME hierarchy closed to new top level types; we've only gotten very limited use and value out of the hierarchy, compared to the pai…

I strongly disagree.  I always expected such difficulties, but I believe a new top level type continues to make sense for certain relatively rare cases, and that "font" (or "fontformat" as per Tony's helpful suggestion) may well be one of them.  I think it would be imprudent to completely rule out any new types in the future, because I don't think we have any real idea what kinds of media human beings will some day invent.   I, at least, always saw "application" as a catch-all for things that didn't fit in any broader media buckets, not also as a catch-all for new possible new buckets.

But I also recognize that since there are few functional differences between "fontformat/xyz" and "application/font; format=xyz" and any number of other alternatives, this question may not have a definitive engineering-level answer.  That's another reason I'd just as soon stick to a more intuitive human notion of top-level media-types:  it's the only level at which it *ever* made sense.  If it's clear to a random civilian why jpeg and gif are in the same category, then the 'image' TLMT makes at least some sense.

On Nov 13, 2011, at 5:11 AM, Julian Reschke wrote:

> Doesn't this also argue for "imageformat" and "videoformat"?

It probably would, if there had been anyone arguing for "image/cutebabies" or "image/dogsplayingpoker".  I think that people just more naturally assumed it was the format with "image," whereas there are two obvious ways to interpret "font" so a disambiguation might be helpful.  -- Nathaniel

---

From: Eric Burger <[email-masked]>
Date: Sun, 13 Nov 2011 13:06:40 -0500

Shockingly, +1

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Nov 2011 16:27:04 +0900

Hello Larry,

> I see no use case for why having font/opentype is any better than application/opentype

It's just fine if you, and some others, don't see it. Does that mean 
that you have to fight against it? You haven't shown, even less 
mentioned, any problem for font/opentype.

My guess is that we would have around 10 or so font types registered 
(and no font type sniffing) if a font/ top level type had been approved 
in a 1990'ish timeframe.

> But there isn't really any common processing proposed that one could do knowing that you have font/x... so I agree with Graham that there isn't a case for font/.

Well, actually, if an OS has a capability of "install that font 
[temporarily] for me", and the OS knows which formats it can handle, 
then that would be a good use case, isn't it?

Also, the use case of easier searching, and the use case of content 
negotiation (font/*) was mentioned.

> The arguments in favor seem to be of the form "well, we allow for new top level types, so why not use it?"

That's definitely an argument, in particular because for the people 
concerned, font/ looks very parallel to image/, video/, audio/,...

> I also recall a number of years ago an attempt to define "chemical/*" as a new top level type for use in defining file formats?

So what? Were there good reasons to reject it? Or was it rejected 
because some people believed that new top level types were "A BIG 
NO-NO"? Or because of some FUD?

> My conclusion from this discussion is that we should declare the MIME hierarchy closed to new top level types; we've only gotten very limited use and value out of the hierarchy, compared to the pai…

The problems between text/xml and application/xml are very specific. And 
they may be interpreted to say that tying particular processing rules to 
particular types, unless absolutely necessary (e.g. structured types), 
may be a bad idea. That doesn't mean that top-level types in general are 
a bad idea.

The reason that we have gotten very little value out of registering new 
top level types may be mostly that virtually no new types have been 
registered, because people are claiming that we get very little value 
out of them. It sounds funny, but it isn't.

Regards,   Martin.

---

From: David Singer <[email-masked]>
Date: Mon, 14 Nov 2011 10:35:12 -0800

> is the possibility of defining common parameters across font data types (in the same way that text/.. has a common charset parameter).

How serious is the first concern "First, the  "application" sub-tree is treated (correctly) with great caution with respect to viruses and other active code."?

(The reason I abandoned the draft was not the difficulty of getting it through, by the way, but because the W3C Timed Text group decided it didn't need it).

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 13:44:09 -0800 (PST)

> mentioned, any problem for font/opentype.

Good point. I have no skin in this particular game - aside from slightly
complicating the media review process I have no personal need for font/*. But
if there's a constituency this type helps, I'm all for it.

> (and no font type sniffing) if a font/ top level type had been approved

And we may or may not have any luck rectifying this at this late date. But I'm
not  seeing a reason not to try.

> ...

> > I also recall a number of years ago an attempt to define "chemical/*" as a
> > new top level type for use in defining file formats?

> NO-NO"? Or because of some FUD?

Didn't chemical kind of morph into model? Or am I getting the history confused?

> > My conclusion from this discussion is that we should declare the MIME
> > hierarchy closed to new top level types; we've only gotten very limited use and
> > value out of the hierarchy, compared to the pain and difficulty (text/xml vs
> > application/xml).

> may be a bad idea. That doesn't mean that top-level types in general are

Agreed.

> out of them. It sounds funny, but it isn't.

No, it really isn't funny, is it?

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 06:10:17 +0800

> if there's a constituency this type helps, I'm all for it.

I think the ball is now in the court of those who think they might want 
to register font/ -- any volunteers? I will also ping our W3C friends to 
see if someone active there has energy to work on this.

Peter

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

---

From: David Singer <[email-masked]>
Date: Mon, 14 Nov 2011 15:50:06 -0800

I probably shouldn't volunteer people, but I know Vladimir Levantovsky has expressed interest in this question in the past.  I am sure he'd want to be aware of this discussion.  In fact, I am cc'ing him here….

David Singer

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Nov 2011 10:15:05 +0900

> How serious is the first concern "First, the  "application" sub-tree is treated (correctly) with great caution with respect to viruses and other active code."?

I very much think that having a  font/ top level type is actually a good 
idea. But I hinted at this before: a type shouldn't be treated as "more 
safe" just because it says font/, rather than application/. Many font 
formats contain active code that is executed by the font engine. Several 
security holes have been found in this area. So I'd actually 
de-emphasize or remove this point. draft-singer-font-mime-00 also 
doesn't have a security section, and it of course needs one.

> (The reason I abandoned the draft was not the difficulty of getting it through, by the way, but because the W3C Timed Text group decided it didn't need it).

Can you be more specific? E.g., does Timed Text only use one font 
format? Or does it not contain any field that indicates the format, 
which makes this "somebody else's problem"? Or some other reason?

Regards,    Martin.

---

From: David Singer <[email-masked]>
Date: Mon, 14 Nov 2011 17:59:30 -0800

On Nov 14, 2011, at 17:15 , Martin J. Dürst wrote:

> I very much think that having a  font/ top level type is actually a good idea. But I hinted at this before: a type shouldn't be treated as "more safe" just because it says font/, rather than application/. Many font formats contain active code that is executed by the font engine. Several security holes have been found in this area. So I'd actually de-emphasize or remove this point. draft-singer-font-mime-00 also doesn't have a security section, and it of course needs one.
> 

It's very old.  I did it in a way I used to do I-Ds -- matching Word layout with nroff commands embedded as hidden text, so it could be saved as plain text, piped through nroff, and then through that old tool that fiddled with nroff output to make an I-D.

Here it is, it's all yours!

> Can you be more specific? E.g., does Timed Text only use one font format? Or does it not contain any field that indicates the format, which makes this "somebody else's problem"?

I think that was it.

> Or some other reason?

David Singer

---

From: Nathaniel Borenstein <[email-masked]>
Date: Tue, 15 Nov 2011 10:52:24 -0500

On Nov 14, 2011, at 8:15 PM, Martin J. Dürst wrote:

> I very much think that having a  font/ top level type is actually a good idea. But I hinted at this before: a type shouldn't be treated as "more safe" just because it says font/, rather than application/. Many font formats contain active code that is executed by the font engine.

Not more safe, but possibly more cost-effective to screen.  If something is labeled as a font, you might be able to reject all non-font content much faster than you can reject application/octet-stream.   (Obviously you'd still have to look through any active code in the stuff that is accepted.)  -- Nathaniel

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Tue, 15 Nov 2011 18:22:10 -0500

Hi all,

First of all, thank you David. This is probably one of those times when I don't mind having been volunteered.

I did express a good deal of interest in the past in registering "font" as a new top-level type, and the preliminary exploration work done few years ago had shown that we would've had about two dozens of subtype entries eligible for font/* tree.

However, the sentiments expressed at the time were very similar to this discussion; I was told that applying for a new top-level type was "A BIG NO-NO", that prior attempts to register font/* failed, and that unless I am willing to dedicate significant part of my life to this activity (i.e. applying and lobbying for a new top-level "font" type) the effort would most likely get us nowhere. 

As far as "application/*" is concerned, aside from being heavily overloaded with various unrelated subtypes and, therefore, utterly confusing IMHO - I am not in a position to argue why font/* is better than application/* - it [font/*] just makes sense. However, since font/* was (and still is) not an option, there are already a number of font types registered either as vendor-specific or as part of the application/* tree - both "ancient" (tdpfr) and very recent (woff) come to mind. 

In fact, SC29/WG11 is in the process of finalizing a new application (as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to apply for a new "application/font-sfnt" type using additional optional parameters to specify types of outlines and advanced layout mechanisms supported by a font. Doing so allows creating a flexible and extensible (albeit slightly cumbersome) mechanism to identify any SFNT-based font using same MIME type definition for a number of font flavors combining either TTF or CFF outlines with any currently known layout engine support (e.g. OpenType, AAT or SIL). Under the circumstances, this seemed to be a pragmatic way to compensate for the lack of "font" type.

I am sure that having a top-level "font/*" type would have made lives easier for many people, but having lived through the times where application/* was the only usable option to register font types (and having few of them already defined as such) - I have even less of an incentive to argue about it now. I would be happy to have font/* type defined, but I am not willing to spend my (and other people) valuable time to fight for it.

Thank you,
Vladimir

> From: David Singer [mailto:[email-masked]]
> Sent: Monday, November 14, 2011 6:50 PM
> To: Ned Freed
> Cc: "Martin J. Dürst"; Larry Masinter; [email-masked];
> [email-masked] Adams; Levantovsky, Vladimir
> Subject: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)
> 
> I probably shouldn't volunteer people, but I know Vladimir Levantovsky
> has expressed interest in this question in the past.  I am sure he'd
> want to be aware of this discussion.  In fact, I am cc'ing him here..
> 
>

---

From: David Singer <[email-masked]>
Date: Tue, 15 Nov 2011 16:20:16 -0800

Thanks Vlad

I think a valid question to ask is whether "application/", being a grab-bag for everything not-image-video-or-audio, is a good idea.  Perhaps that horse has already bolted, but the idea of a top-level type its, in my mind, to give the recipient some clues as to what the thing claims to offer, what use it might be, how it might be screened, and so on.  image/ tells you it's an image, that will need rendering space;  video and audio need timing, and video also needs rendering space, and audio needs audio presentation capability.

But application/ tells you nothing at all; it's the wild west, anything goes.  it might need rendering, it might make sound, it might need timing, it might be an unpresented resource (like a font), it might be… anything!

David Singer

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 10:17:01 +0800

On 11/16/11 7:22 AM, Levantovsky, Vladimir wrote:

> However, the sentiments expressed at the time were very similar to
> this discussion; I was told that applying for a new top-level type
> was "A BIG NO-NO", that prior attempts to register font/* failed, and
> that unless I am willing to dedicate significant part of my life to
> this activity (i.e. applying and lobbying for a new top-level "font"
> type) the effort would most likely get us nowhere.

Perhaps I am mistaken, but I read the discussion differently: I see an
openness to registering font/* now.

Peter

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

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Wed, 16 Nov 2011 15:01:20 -0500

Adding Chris Lilley from W3C

> openness to registering font/* now.

Yes. I guess I should've been more specific and should have said that the sentiments expressed few years ago were similar to what was mentioned as part of this discussion (or as quoted from prior discussions). I do see a much more open-minded position to registering font/* now - the question is whether there is still a utility value left in doing this (since we already have quite a few font-* subtypes registered under the application/* tree.

My personal opinion is that registering font/* type still makes a lot of sense and this is something we need to do, even if it involves re-registering some of the existing subtypes under the new font/* tree. 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.

Thank you,
Vlad

---

From: "t.petch" <[email-masked]>
Date: Thu, 17 Nov 2011 12:55:34 +0100

----- Original Message -----
From: "Levantovsky, Vladimir" <[email-masked]>
To: "Peter Saint-Andre" <[email-masked]>
Cc: "Chris Lilley" <[email-masked]>; "Ned Freed" <[email-masked]>; "David
Singer" <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, November 16, 2011 9:01 PM
> > My personal opinion is that registering font/* type still makes a lot of
sense and this is something we need to do, even if it involves re-registering
some of the existing subtypes under the new font/* tree. 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.
Vlad

Just to be clear, what meaning does WebFonts attach to 'font', were it an object
class, how would it be characterised?  This thread has shown a number of
different meanings of the term and I am not familiar with the work of W3C.

Tom Petch

---

From: TianLinyi <[email-masked]>
Date: Thu, 17 Nov 2011 14:06:59 +0000

Hi, All

Since there is no clear advantage for both ways, is there any guidance on how to make a decision? I think we don't need to spend too much time on this. Maybe it is the time to make a choice now based on rough consensus, right? Or if there is an alternative way to get guidance from somewhere in IETF first regarding how to create a top level registry?

Cheers,
Linyi

________________________________________
发件人: [email-masked] [[email-masked]] 代表 t.petch [[email-masked]]
发送时间: 2011年11月17日 19:55
到: Levantovsky, Vladimir
Cc: Chris Lilley; David Singer; [email-masked]; [email-masked]
主题: Re: [apps-discuss] font/* (and draft-freed-media-type-regs)

----- Original Message -----
From: "Levantovsky, Vladimir" <[email-masked]>
To: "Peter Saint-Andre" <[email-masked]>
Cc: "Chris Lilley" <[email-masked]>; "Ned Freed" <[email-masked]>; "David
Vlad

Tom Petch

---

From: David Singer <[email-masked]>
Date: Thu, 17 Nov 2011 09:15:06 -0800

> Since there is no clear advantage for both ways, is there any guidance on how to make a decision? I think we don't need to spend too much time on this. Maybe it is the time to make a choice now bas…

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.

David Singer

---

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

Hello Vlad,

> Yes. I guess I should've been more specific and should have said that the sentiments expressed few years ago were similar to what was mentioned as part of this discussion (or as quoted from prior d…

You mention that there are quite a few font types already registered 
under application/. Earlier discussion only brought up 
application/font-tdpfr (http://tools.ietf.org/html/rfc3073), a format 
that as far as I was able to conclude from a quick web search, is no 
longer much in fashion (you may know better).

Can you tell us what the other font types under application/ are?

Regards,    Martin.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 18 Nov 2011 08:16:23 +0100

>Can you tell us what the other font types under application/ are?

There are application/vnd.ms-fontobject for Microsoft's "EOT" format and
application/vnd.font-fontforge-sfd for Fontforge's "SFD" format.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

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

> application/vnd.font-fontforge-sfd for Fontforge's "SFD" format.

Okay. That would be altogether 3 out of e.g. the 24 on 
http://en.wikipedia.org/wiki/Category:Font_formats. Not too late to 
introduce font/, I'd say.

Regards,    Martin.

---

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

Hello Vlad,

> In fact, SC29/WG11 is in the process of finalizing a new application (as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to apply for a new "application/font-sfnt" type using additio…

I have no idea about the details involved, but what you say here about 
optional parameters sounds rather dangerous to me.

Setting parameters correctly on Web servers, while in theory not too 
complicated, turns out to be quite brittle and impractical in many 
scenarios. Even the base media type often isn't correct.

What you call a "flexible and extensible (albeit slightly cumbersome) 
mechanism" may turn out, in actual practice, to be highly cumbersome, 
confusing, and rarely used.

Again, I have to admit that I'm not familiar with the details, so if for 
example these parameters are only advisory and in practice things work 
perfectly well even if they are not used, then it might be less big of a 
deal.

Can you give use a bit more information to help understand the 
trade-offs involved?

Regards,   Martin.

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Fri, 18 Nov 2011 09:35:15 -0500

Hello Marin, all,

Besides vendor-specific types, the only registered font type that I am aware of is 'application/font-woff'. W3C WebFonts WG has submitted a registration for this subtype about a year ago, and the text of the registration is available as Annex B of the WOFF specification: http://dev.w3.org/webfonts/WOFF/spec/#appendix-b

ISO SC29/WG11 has prepared the draft to register application/font-sfnt but it wasn't submitted yet. 

Thank you,
Vlad

> From: "Martin J. Dürst" [mailto:[email-masked]]
> Sent: Friday, November 18, 2011 2:03 AM
> To: Levantovsky, Vladimir
> Cc: Peter Saint-Andre; Chris Lilley; Ned Freed; David Singer; apps-
> [email-masked]; [email-masked] Adams
> > Yes. I guess I should've been more specific and should have said that
> the sentiments expressed few years ago were similar to what was
> mentioned as part of this discussion (or as quoted from prior
> discussions). I do see a much more open-minded position to registering
> font/* now - the question is whether there is still a utility value
> left in doing this (since we already have quite a few font-* subtypes
> registered under the application/* tree.
>

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Fri, 18 Nov 2011 10:17:04 -0500

On Friday, November 18, 2011 2:52 AM Martin J. Dürst wrote:
> > In fact, SC29/WG11 is in the process of finalizing a new application
> (as part of the ISO/IEC 14496-22:2009/Amd.2 work) where we decided to
> apply for a new "application/font-sfnt" type using additional optional
> parameters to specify types of outlines and advanced layout mechanisms
> supported by a font. Doing so allows creating a flexible and extensible
> (albeit slightly cumbersome) mechanism to identify any SFNT-based font
> using same MIME type definition for a number of font flavors combining
> either TTF or CFF outlines with any currently known layout engine
> support (e.g. OpenType, AAT or SIL). Under the circumstances, this
> seemed to be a pragmatic way to compensate for the lack of "font" type.
> 
> perfectly well even if they are not used, then it might be less big of
> a deal.
> 

The SC29/WG11 planned to register the "application/font-sfnt" type with the following two optional parameters:
1) 	Name: 	Outlines
	Value: 	TTF, CFF
2) 	Name: 	Layout
	Value: 	OTF, AAT, SIL 

This would allow to identify fonts of multiple flavors, e.g.:
TrueType - application/font-sfnt (Outlines=TTF);
OpenType with TTF outlines - application/font-sfnt (Outlines=TTF, Layout=OTF);
OpenType with CFF outlines - application/font-sfnt (Outlines=CFF, Layout=OTF);
AAT fonts - application/font-sfnt (Outlines=TTF, Layout=AAT); etc.

I understand that the alternative would be to register a number of separate subtypes for each font flavor, and it would probably be the way we will go if font/* is available.

Thank you,
Vlad

---

From: Ned Freed <[email-masked]>
Date: Fri, 18 Nov 2011 11:50:51 -0800 (PST)

> Besides vendor-specific types, the only registered font type that I am aware
> of is 'application/font-woff'. W3C WebFonts WG has submitted a registration for
> this subtype about a year ago, and the text of the registration is available as
> Annex B of the WOFF specification:

> http://dev.w3.org/webfonts/WOFF/spec/#appendix-b

Submitted to whom? It isn't on the IANA page so it hasn't been approved unless
approval was very recent.

It's one thing if this registration is still bouncing around inside of the W3C
process - that's entirely the W3C's baliwick. But if this was submitted to the
IESG for approval, having an outstanding request for "about a year" is
COMPLETELY UNACCEPTABLE. And this is very much the main problem this entire
effort was intended to address, and which we seem to have great difficulty
focusing on.

> ISO SC29/WG11 has prepared the draft to register application/font-sfnt but it

FWIW, there are presently four registered font-ish types:

application/font-tdpfr (RFC 3073)
application/vnd.font-fontforge-sfd
application/vnd.ms-fontobject
application/vnd.openxmlformats-officedocument.wordprocessingml.fontTable+xml

				Ned

---

From: "t.petch" <[email-masked]>
Date: Sat, 19 Nov 2011 12:29:40 +0100

----- Original Message -----
From: "Levantovsky, Vladimir" <[email-masked]>
To: "Martin J. Dürst" <[email-masked]>
Cc: "Ned Freed" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "Chris Lilley" <[email-masked]>; "David Singer"
<[email-masked]>
Sent: Friday, November 18, 2011 3:35 PM

Looking at this URI I found at least a partial answer to my earlier question as
to what W3C mean by font, namely
"This document specifies a simple compressed file format for fonts, designed
primarily for use on the Web and known as WOFF (Web Open Font Format). Despite
this name, WOFF should be regarded as a container format or "wrapper" for font
data in already-existing formats rather than an actual font format in its own
right."
which, to me, broadens the scope yet more, not that it should not be registered
but just what branch of the tree it should be in.

Tom Petch

---

From: Chris Lilley <[email-masked]>
Date: Mon, 21 Nov 2011 13:22:15 +0100

(Catching upon this thread)

>> http://dev.w3.org/webfonts/WOFF/spec/#appendix-b

NF> Submitted to whom? It isn't on the IANA page so it hasn't been approved unless
NF> approval was very recent.

In accordance with the usual W3C process for media type registrations
- the registration template is an appendix in the technical specification
- at last call, it gets sent to ietf-types to start discussion
- at proposed rec (ie one the spec is fixed) W3C will ask for IESG approval. This has not happened yet; the spec is in Candidate  Recommendation phase.

NF> It's one thing if this registration is still bouncing around inside of the W3C
NF> process - that's entirely the W3C's baliwick.

Its bouncing around the early stages of both W3C and IETF/IANA processes.

NF>  But if this was submitted to the IESG for approval,

No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.

>> ISO SC29/WG11 has prepared the draft to register application/font-sfnt but it

It has neither been sent to ietf-types not has it been sent to IESG to request approval.

NF> FWIW, there are presently four registered font-ish types:

NF> application/font-tdpfr (RFC 3073)

Yes, Bitstream TrueDoc portable font resource (as used in Netscape 4.x). 

NF> application/vnd.font-fontforge-sfd

Right, the fontforge source file format. Hmm,so UFO format is not yet registered.

NF> application/vnd.ms-fontobject
NF> application/vnd.openxmlformats-officedocument.wordprocessingml.fontTable+xml

I was unaware of those, thanks for the pointer. of course, had all these been registered in a font/* tree then discovery would be so much easier.

-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Nov 2011 20:54:36 +0100

> No, not yet, since that requires a stable document to reference,and changes are still possible as a result of Candidate Recommendation implementation experience.

Well, the (dated) CR is also stable, right?

I believe it would be better overall to register early, and then to 
update the registration later on.

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Mon, 21 Nov 2011 12:09:17 -0800 (PST)

> update the registration later on.

+1

And there is no need to change any rules to allow this. The decision of when to
register a type is entirely up to the standards body doing the the registering.

The word "stable" appears nowhere in RFC 4288.

				Ned

---

From: Julian Reschke <[email-masked]>
Date: Tue, 22 Nov 2011 13:32:23 +0100

On 2011-11-22 13:06, Chris Lilley wrote:
> On Monday, November 21, 2011, 8:54:36 PM, Julian wrote:
>
> JR>  On 2011-11-21 13:22, Chris Lilley wrote:
>>> ...
> JR>  Well, the (dated) CR is also stable, right?
>
> All dated /TR documents are stable, in that sense.
>
> My understanding was that the IESG wanted a document that was final and would serve as a reference for some time. A CR might (hopefully,would be) be superceeded in 6 months.
> ...

Well, if it's 6 months that would be ok. However I have the impression 
that the time between implementations coming out an full rec usually is 
something taking many years; in which case not having the media type 
registered isn't helping anybody...

Best regards, Julian

---

From: Chris Lilley <[email-masked]>
Date: Tue, 22 Nov 2011 13:06:13 +0100

JR> I believe it would be better overall to register early, and then to 
JR> update the registration later on.

Ah, yes, I hadn't thought of updating the registration. I tend to agree that earlier is better than later. I will take this back to W3C team and suggest a modification to our media type registration policy.

---

From: Chris Lilley <[email-masked]>
Date: Tue, 22 Nov 2011 13:08:18 +0100

On Monday, November 21, 2011, 9:09:17 PM, Ned wrote:

>> Julian wrote:

NF> +1

NF> And there is no need to change any rules to allow this. The decision of when to
NF> register a type is entirely up to the standards body doing the the registering.

NF> The word "stable" appears nowhere in RFC 4288.

Thanks for the confirmation, Ned, that there is nothing in the RFC that would prevent W3C registering media types at the W3C Candidate Recommendation stage.