Subject: [apps-discuss] Proposed charter for justfont

From: Wendy Seltzer <[email-masked]>
Date: Mon, 9 Nov 2015 21:17:49 -0500

As discussed at the DISPATCH meeting last week, we propose this draft
charter for a WG with the sole purpose of defining the "font" top-level
media type, with input from the W3C WebFonts WG.

 http://datatracker.ietf.org/doc/charter-ietf-justfont/

Thanks,
--Wendy, proposed co-chair, with Mark Nottingham
-- 
Wendy Seltzer -- [email-masked] +1.617.715.4883 (office)
Policy Counsel and Domain Lead, World Wide Web Consortium (W3C)
http://wendy.seltzer.org/        +1.617.863.0613 (mobile)

---

From: "John Levine" <[email-masked]>
Date: 10 Nov 2015 08:25:04 -0000

>--Wendy, proposed co-chair, with Mark Nottingham

I realize it goes against the modern IETF way not to nitpick this, but
it's fine.  Ship it, and we can do the work.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Nov 2015 00:53:47 -0800 (PST)

>  http://datatracker.ietf.org/doc/charter-ietf-justfont/

What's there is fine, and given the high quality of the starting draft, it's
really all you need.

While I personally prefer charters that simply describe what a group is going
to do, experience has shown that justification for the activity needs to be
part of it. As such, I think it may be a good idea to copy some of the
justification for the top-level font type from draft-lilley-font-toplevel, or
maybe a pointer to that justification text is sufficient.

				Ned

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 10 Nov 2015 18:16:16 +0900

> maybe a pointer to that justification text is sufficient.

I agree with Ned on all points. For the record, I also plan to 
participate in this WG and to review the draft.

Regards,   Martin.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Nov 2015 07:14:49 -0500

> http://datatracker.ietf.org/doc/charter-ietf-justfont/

It seems to me like a lot of process overhead for a small effort, but if I take it as a given this needs a whole working group, what's written seems fine.

Scott K

---

From: Sean Leonard <[email-masked]>
Date: Tue, 10 Nov 2015 06:22:15 -0800

> It seems to me like a lot of process overhead for a small effort, but if I take it as a given this needs a whole working group, what's written seems fine.

For the purpose of defining a font top-level media type, it’s ok, but a bit too top-heavy.

I would also request that the archive top-level media type be included in the WG scope. I recall that the W3C web-packaging effort was interested in that as well. This will make the work more meaty while keeping it focused on the primary standardization effort.

Based on past experience, it is better to keep the initial work tightly focused on getting the top-level media type(s) registered. Areas of commonality, including:
* common parameters
* common fragment identifiers
* lots of subtypes

while interesting, risk a high degree of bike-shedding, and are best defined as follow-on topics. I would rather see “font” (and “archive”) RFCs published quickly and *then* the WG getting bogged down in minutiae, than the WG getting bogged down in minutiae that prevents these top-level types from making it through. For example, draft-lilley-font-toplevel-00 has a lot of registrations with optional parameters like “Layout” and “Outlines”, which I perceive to be rather superfluous (and unlikely to be supplied anyway).

The model type got through [RFC2077] but the meat of it is really short: just 7 pages (excluding references, appendices, and author matter).

By the way: draft-lilley-font-toplevel-00 uses the term “primary content type”, which appears to be outdated. [RFC6838] refers to that thing as “top-level media type”. I believe  we should stick to the right term.

Sean

---

From: Barry Leiba <[email-masked]>
Date: Tue, 10 Nov 2015 09:47:23 -0500

> I would also request that the archive top-level media type be included
> in the WG scope.

I have a very strong inclination NOT to do that (though I will accept
consensus, of course).  We tried that; there wasn't enough interest
and energy to get anywhere with it.  I do not want to saddle this work
with that, and I strongly prefer a tightly focused working group.

Barry, ART Director

---

From: John C Klensin <[email-masked]>
Date: Tue, 10 Nov 2015 09:53:56 -0500

FWIW, +1
    john

--On Tuesday, November 10, 2015 09:47 -0500 Barry Leiba
<[email-masked]> wrote:

>> I would also request that the archive top-level media type be
>> included in the WG scope.
> 
> I have a very strong inclination NOT to do that (though I will
> accept consensus, of course).  We tried that; there wasn't
> enough interest and energy to get anywhere with it.  I do not
> want to saddle this work with that, and I strongly prefer a
> tightly focused working group.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 10 Nov 2015 13:53:01 -0800

> with that, and I strongly prefer a tightly focused working group.

I agree with Barry.  Keep the tight focus.  Then separately consider archive/*.

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 11 Nov 2015 09:22:41 +1000

> I agree with Barry.  Keep the tight focus.  Then separately consider
​*reconsider. We gave it a go, then all support evaporated. This
font/*
proposal seems to have more drive and more widespread support, so will
probably work better.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Nov 2015 12:03:09 +1100

+1

> On 11 Nov 2015, at 8:53 am, Martin Thomson <[email-masked]> wrote:
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   https://www.mnot.net/

---

From: Sean Leonard <[email-masked]>
Date: Tue, 10 Nov 2015 17:29:58 -0800

> I agree with Barry.  Keep the tight focus.  Then separately consider archive/*.

All right, fine. But when we say tight focus, just keep it as much as possible on the top-level media type registration.

I see “making initial registrations in "font"” to be a possible black hole. I also see defining common parameters (or ways to accommodate them) between "font" registrations, also to be a black hole. Black hole = likely to derail tight focus.

Part of this is because there is no common data format congruence within the proposed font types, so Section 4 of draft-00 says “Unrecognized sub-types of "font" should be treated as "application/octet-stream".” Then it says “Implementations may pass unrecognized subtypes to a common font-handling system, if such system is available.”

The idea of a top-level media type is that if TYPE/SUBTYPE handling is not available, TYPE handling should be done first. Sometimes TYPE => TYPE/defaultsubtype, i.e., text/plain. All text/* types can be read by a text/plain viewer, although you’ll get…raw text. The question is, is there a common format to font/* such as font/sfnt, such that all fonts can be treated as font/sfnt and not get total garbage? If you can open all fonts in a truly generic font viewer where you see tables of data (even if the data is inscrutable), then that is not garbage.

(I submit that there is no commonality. In the exemplary registrations, font/sfnt ~ font/otf ~ font/ttf but != font/woff. That is because WOFF is compressed. Maybe I don’t understand the commonality of the data formats. And what about PostScript Type 1 fonts such as .pfb?)

The sooner we can declare that there is no commonality in data format, the tighter we can make the scope and the sooner the WG can finish its work.

Sean

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Nov 2015 12:57:26 +1100

Hi Sean,

> On 11 Nov 2015, at 12:29 pm, Sean Leonard <[email-masked]> wrote:
> 
> 

Can you justify these statements, or are they just a "feeling"?

> The sooner we can declare that there is no commonality in data format, the tighter we can make the scope and the sooner the WG can finish its work.

Sure. So, why does that lead you to think that we should up-front constrain the charter to preclude initial registrations and common parameters?

I also want to push back on folks who seem to be saying "look, archive/* just failed; this faces the same risks." This is a completely different community and set of use cases; just because it shares of the trivial property of "being a top-level media type" does not mean that it's doomed to failure. 

Cheers,

---

From: Sean Leonard <[email-masked]>
Date: Tue, 10 Nov 2015 22:30:47 -0800

Hello Mark et. al.,

On Nov 10, 2015, at 5:57 PM, Mark Nottingham <[email-masked]> wrote:

> Can you justify these statements, or are they just a "feeling”?

Because that is where some of the effort for archive, and as I gather for prior top-level media types (looking from the e-mail history), got derailed. Aside from my personal inability to drive conversation at that time (not necessary to detail), a lot of ideas or things were proposed for archive such as common parameters and in particular common fragment identifier syntax, that required additional effort to survey the myriad of archive types out there. I started to do that survey but it’s a big job and wasn’t able to complete it in time for another draft.

I sort of assume that fragment identifier syntax is not needed for fonts. If so, explicitly declaring fragment identifiers as out-of-scope will help keep focus. One could naturally devise some kind of fragment syntax but that would be a great example of where we have agreement on focus before the WG starts; therefore, the effort won’t get sidetracked by that.

> Sure. So, why does that lead you to think that we should up-front constrain the charter to preclude initial registrations and common parameters?

I think that constraining the charter will make it more focused. I am not precluding initial registrations but I am asking for more precision.

Specifically right now the scope (based on draft-00) seems too Web-focused. Fonts apply to a lot more than the Web. For example, (e)mail interests and printing interests should be represented. A start would be to include PostScript Type 1 fonts (tip: there are actually a large number of PostScript types). Other types that come to mind include TeX font metric (TFM, .tfm), Spline Font Database (.sfd), Apple Advanced Typography (AAT), and Graphite (by SIL).

On the mail side, it would be very nice to use @font-face in HTML email: the status quo is to render text with nice fonts in graphics that are sliced into HTML4 table cells (which in turn promotes the pervasive use of “web bugs”, i.e., server-hosted images that leak exactly when and where a user opens an email). However, the security considerations loom large on that one.

Note that these types do not need to be registered--only acknowledged. And by comparing all of these types, it is hopefully clearer that it is hard to find any parameters that are in common between all of them.

On the other hand, the top-level media type could be “webfont” which more explicitly states the bias.

> I also want to push back on folks who seem to be saying "look, archive/* just failed; this faces the same risks." This is a completely different community and set of use cases; just because it shar…

For my part I would like to see font/* succeed. But you raise an important point because the WG ought to incorporate the needs of all font communities, not just this particular community that promoted this current draft. If you look at draft-singer-font-mime-00 from October 2004, you will note a distinct difference in focus, as evidenced in proposed parameters like “font-name”.

Sean

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 11 Nov 2015 17:53:09 +0900

> I sort of assume that fragment identifier syntax is not needed for fonts. If so, explicitly declaring fragment identifiers as out-of-scope will help keep focus. One could naturally devise some kind…

Agreed. I don't think it's needed in the charter, but it doesn't hurt to 
add it.

> Specifically right now the scope (based on draft-00) seems too Web-focused. Fonts apply to a lot more than the Web. For example, (e)mail interests and printing interests should be represented. A st…

I think one way to word it is that we want a few initial registrations 
because it wouldn't make sense to create a new top level empty. The 
initial registrations can also serve as examples for further 
registrations and as a proof of concept for the top level type.

But there's no need to be complete; registering a subtype isn't too 
difficult. Of course, if people provide additional registration 
templates, maybe these can also be added to the initial registration, 
but there is absolutely no need to try to be complete.

> On the mail side, it would be very nice to use @font-face in HTML email: the status quo is to render text with nice fonts in graphics that are sliced into HTML4 table cells (which in turn promotes…

Interesting point, but not at all relevant for the current effort.

> Note that these types do not need to be registered--only acknowledged. And by comparing all of these types, it is hopefully clearer that it is hard to find any parameters that are in common between…

Common parameters don't need to be universal across subtypes. An example 
is "charset", although fairly common for text/, it's not used on all 
subtypes.

> On the other hand, the top-level media type could be “webfont” which more explicitly states the bias.

The current 'bias' is, as far as I can guess, mostly due to the fact 
that the lack of a common top-level type is most severely felt by people 
involved in Web fonts, and that therefore they have started this effort.

It would be very strange to create a top-level type "webfont", because 
we also don't have top level types "webimage" or "webtext" and so on.

> But you raise an important point because the WG ought to incorporate the needs of all font communities, not just this particular community that promoted this current draft. If you look at draft-singer-font-mime-00 from October 2004, you will note a distinct difference in focus, as evidenced in proposed parameters like “font-name”.

I'm pretty sure these concerns can be addressed once the WG is formed. 
I'm also sure that the current community doesn't want to leave other 
font formats out, it just concentrated on what it needs and what it 
knows best.

As for draft-singer-font-mime-00, I agree that there's some good 
reusable stuff in there.

But on the other hand, there's also some hopeless overkill, for example 
the text that says that something like font/Courier is out of scope in 
the same way as image/MonaLisa is out of scope.

Regards,   Martin.

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Wed, 11 Nov 2015 15:32:44 +0000

Hi all,

(Sorry for duplication if you see this email twice - the original post has bounced since I used to be subscribed to the list with a different email address.)

As a brief introduction, I am Vladimir Levantovsky from Monotype and I also serve as a chair of the W3C WebFonts WG and as ISO project editor for ISO/IEC 14496-22 Open Font Format (OFF) spec.

On Tuesday, November 10, 2015 8:30 PM Sean Leonard wrote:

> All right, fine. But when we say tight focus, just keep it as much as 
> possible on the top-level media type registration.
>
> I see “making initial registrations in "font"” to be a possible black 
> hole. I also see defining common parameters (or ways to accommodate 
> them) between "font" registrations, also to be a black hole. Black hole = likely to derail tight focus.
>

The current proposal attempts to replicate the same structure of subtypes that were defined for font-related subtypes in the "application" tree, so what used to be defined as application/font-woff would now be simply font/woff.

> Part of this is because there is no common data format congruence 
> within the proposed font types, so Section 4 of draft-00 says 
> “Unrecognized sub-types of "font" should be treated as 
> "application/octet-stream".” Then it says “Implementations may pass unrecognized subtypes to a common font-handling system, if such system is available.”

I strongly disagree with the sentiment. The OpenType / OFF standard defines a common data format where TrueType, Adobe CFF, and now SVG outlines can peacefully coexist, and the list doesn’t stop there. At a higher level, all modern font data formats (OpenType/OFF, AAT, SIL) share the same SFNT data structure so considering that there are a number of officially standardized glyph outline formats (see above) and the differences between various SFNT-based font formats are specific to variations in supported text layout mechanisms - the subtypes and the optional parameters that are proposed as part of the font/* tree (and those that have been registered to date as part of the application tree) are all justified by pragmatic considerations of what is used these days.

> (I submit that there is no commonality. In the exemplary 
> registrations, font/sfnt ~ font/otf ~ font/ttf but != font/woff. That 
> is because WOFF is compressed. Maybe I don’t understand the 
> commonality of the data formats. And what about PostScript Type 1 
> fonts such as .pfb?)

Members of WebFonts WG have conducted extensive study of media types that are in use these days:
https://docs.google.com/document/d/1Tsju6EOP4LqJ1RcFJRpqxryggbWZYbq5jvsIhVYNoyU/edit
As much as it makes sense to make the new set of media types for fonts intuitive and easy to use, we are not at all interested in resurrecting all ancient font formats that had seen the light of day at some point of the last century - the proposal is rooted in observations of what the majority of folks use these days (i.e., more often than not they simply use a media type they _think_ would make sense to use, and don’t even bother checking if it's actually defined) and simple pragmatic considerations is what's driving our decisions and this proposal.

> The sooner we can declare that there is no commonality in data format, 
> the tighter we can make the scope and the sooner the WG can finish its work.

IMO, wishing something come true (or declaring something to not be the case even if it is) doesn’t work - the reality always prevails.

Thank you,
Vlad

---

From: Sean Leonard <[email-masked]>
Date: Wed, 11 Nov 2015 08:09:06 -0800

> As a brief introduction, I am Vladimir Levantovsky from Monotype and I also serve as a chair of the W3C WebFonts WG and as ISO project editor for ISO/IEC 14496-22 Open Font Format (OFF) spec.

Greetings; pleased to meet you.

> The current proposal attempts to replicate the same structure of subtypes that were defined for font-related subtypes in the "application" tree, so what used to be defined as application/font-woff…

Fine.

> I strongly disagree with the sentiment. The OpenType / OFF standard defines a common data format where TrueType, Adobe CFF, and now SVG outlines can peacefully coexist, and the list doesn’t stop th…

I suppose that this is analogous to the text & charset situation, in 
which charset is common across the vast majority of text types and has 
predefined semantics, but not all text subtypes need to use it (for 
historical reasons). With that said, it sounds like the default font 
type handling is going to be font/sfnt. Since the primary experts have 
already concluded this, I would rather see it in the charter as follows:

The working group will use draft-lilley-font-toplevel as a starting 
point. Default font handling will be defined by font/sfnt.

-Sean

---

From: "John Levine" <[email-masked]>
Date: 12 Nov 2015 01:06:33 -0000

>I would also request that the archive top-level media type be included in the WG scope. I recall that the W3C web-packaging effort was
>interested in that as well. This will make the work more meaty while keeping it focused on the primary standardization effort.

Please, no.  There is a specific significant community ready to implement font/whatever.

As far as I know, there is no such community for archive/*.  It failed
once due to lack of interest and I don't see anything different now.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 Nov 2015 13:23:37 -0500

> it sounds like the default font type handling is
> going to be font/sfnt. Since the primary experts have already concluded
> this, I would rather see it in the charter as follows:
>
> The working group will use draft-lilley-font-toplevel as a starting point.
> Default font handling will be defined by font/sfnt.

That's something the document should say, and the working group should
confirm consensus on.  It would be a bad idea to constrain a working
group by putting such a low-level detail into the charter, absent a
very strong reason for it.  I don't see a strong reason.

Barry

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Tue, 10 Nov 2015 15:01:47 +0000

+1!
For the record, I support the proposed charter and will participate in the work of this WG to address any questions that may arise (e.g. optional parameters and their purpose).

Thank you,
Vladimir

-----Original Message-----
From: apps-discuss [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Tuesday, November 10, 2015 9:47 AM
To: Sean Leonard
Cc: Scott Kitterman; IETF Apps Discuss
Subject: Re: [apps-discuss] Proposed charter for justfont

> I would also request that the archive top-level media type be included 

I have a very strong inclination NOT to do that (though I will accept consensus, of course).  We tried that; there wasn't enough interest and energy to get anywhere with it.  I do not want to saddle this work with that, and I strongly prefer a tightly focused working group.

Barry, ART Director

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Wed, 11 Nov 2015 15:23:43 +0000

Hi all,

On Tuesday, November 10, 2015 8:30 PM Sean Leonard wrote:

> I see “making initial registrations in "font"” to be a possible black hole. I also see defining 
> common parameters (or ways to accommodate them) between "font" registrations, also 
> to be a black hole. Black hole = likely to derail tight focus.
>

> Part of this is because there is no common data format congruence within the proposed 
> font types, so Section 4 of draft-00 says “Unrecognized sub-types of "font" should be treated 
> as "application/octet-stream".” Then it says “Implementations may pass unrecognized subtypes 
> to a common font-handling system, if such system is available.”

> (I submit that there is no commonality. In the exemplary registrations, font/sfnt ~ font/otf ~ 
> font/ttf but != font/woff. That is because WOFF is compressed. Maybe I don’t understand 
> the commonality of the data formats. And what about PostScript Type 1 fonts such as .pfb?)

> The sooner we can declare that there is no commonality in data format, the tighter we can 
> make the scope and the sooner the WG can finish its work.

Thank you,
Vlad

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 13 Nov 2015 16:52:49 +0900

Hello Vlad,

> As much as it makes sense to make the new set of media types for fonts intuitive and easy to use, we are not at all interested in resurrecting all ancient font formats that had seen the light of da…

I agree that the proposal should focus on what's most used these days, 
and what the proposers are most interested in.

> IMO, wishing something come true (or declaring something to not be the case even if it is) doesn’t work - the reality always prevails.

I think saying that there's no commonality between formats is wrong. But 
implying that all formats have the same commonalities (except obviously 
that they are fonts) is also wrong.

As an example, I'd never request the WG to register something like 
font/bdf, but I'd expect that we set up the top level type and the 
registration so that somebody could register font/bdf if they needed to.

[If all of what I said above seems obvious, please just ignore :-]

Regards,   Martin.

---

From: "Levantovsky, Vladimir" <[email-masked]>
Date: Fri, 13 Nov 2015 17:44:41 +0000

Hi Martin,

On Friday, November 13, 2015 2:53 AM Martin J. Dürst wrote:
To: Levantovsky, Vladimir; Sean Leonard; IETF Apps Discuss
Subject: Re: [apps-discuss] Proposed charter for justfont

>>> The sooner we can declare that there is no commonality in data 
>>> format, the tighter we can make the scope and the sooner the WG can finish its work.
>>
>I think saying that there's no commonality between formats is wrong. But implying that all 
> formats have the same commonalities (except obviously that they are fonts) is also wrong.

Agree. It just happens that most of the widely used font formats today (which is ultimately reflected in the current proposal) have a high degree of commonality but yes, historically, there have been significant differences between font formats. It's perfectly normal to have no commonality between e.g. scalable vector fonts and bitmap fonts.

> As an example, I'd never request the WG to register something like font/bdf, but I'd expect
> that we set up the top level type and the registration so that somebody could register font/bdf
> if they needed to.

Yes, absolutely. Once the top-level type is established, anyone can register the subtypes they need, and by "need" I mean anything that may be useful would be a good thing to register (old or new) if it's actually used.

Cheers,
Vlad