Re: .webfont Proposal 2

On Thu, 2009-07-16 at 20:42 +0200, Bert Bos wrote:
> Thomas Lord wrote:
> > If the intention of the format is to be easily 
> > extended with new font file formats, there must be
> > some assignment of authority over that list to some
> > organization and an orderly process for managing the 
> > list -- so that people can register new format names,
> > avoid name collisions, ensure that an adequate definition
> > for each new format name is recorded, and so forth.
> > 
> > To what organization do you suggest that authority 
> > should be assigned and what process should be used 
> > to maintain it?
> There are at least four reasonable answers to that question:

Let's examine these.   I almost included that very list
myself but I'm glad you spoke up because I only three off
your list.  

If I may paraphrase:

Option 1) The list of font format names is to initially be 
part of the Recommendation created by a font WG.   Future
extensions to the list require revisions to the Recommendation.

Option 2) Use the IANA registry for MIME media types.

Option 3) Persuade W3C to start and run a new bespoke
registry for font format names.

Option 4) Use URIs and forgo the creation of an authority
list of font format names per se.

As you point out, there is little precedent for Option 3
and unless someone cares to stand up for it, I think we
can strike it immediately from the list as impractical.

The remaining three options break down into a pair
of choices:

What is the syntax of a font format name:
   a) arbitrary string   : compatible with option 1
   b) use URI            : compatible with options 1,4
   c) use MIME types     : compatible with options 1,2

What is the authority for registering font format name:
   x) W3C Web Font WG    : compatible with option 1
   y) IANA (media reg.)  : compatible with option 2
   z) none               : compatible with option 4

And so possible outcomes are:

  a-x b-x b-z c-x c-y

I would submit that all options *-x can be taken
off the table with this observation:

"New font formats" will sometimes be desirable as
formats which UAs "MUST" support, sometimes as "SHOULD",
and sometimes as "MAY".   I think that nobody disagrees
that for every new font format, UAs "MAY" support that
format.  It is "MUST" and "SHOULD" that require discussion
in a W3C WG.   Therefore, it would be wrong to ask a font WG
to revise the standard for every new font format that "MAY"
be supported - the WG process is too heavyweight and 
inappropriately political for that.

If we can agree that the Recommendation is only to be 
revised for a new font format when that format achieves
"SHOULD" or "MUST" status, then all options *-x are
off the table.   We are left with:

  b-z c-y

b-z: URIs and no authority over font format names
     other than those mentioned in MUST or SHOULD
     language in the font Recommendation.

c-y: MIME types and IANA media name authority, where
     a W3C font Recommendation can still designate a 
     subset as MUST or SHOULD (leaving "MAY" as free

That "consonance" thing that seems so obscure to some
applies here:  W3C standards typically use URIs
for XML namespaces and the URL subsets for routing
and use MIME types for media file format types.  The 
pattern is further reinforced by, well, other important
standards outside of W3C.  It would be kind of anti-social
here to use anything other than MIME types which at least
strongly suggests: c-y.

That doesn't immediately lead to "use MIME format, not
zip" but it gets a substantial part of the way there.

> There are currently no font formats in IANA's registry, as far as I
> know, but it makes sense to register some. Some operating systems
> already use pseudo-media types internally: e.g., KDE uses
> application/x-font-otf.

See?  Consonance!  Parsimony!

> W3C has a special liaison with the IETF and the procedure for
> registering new types in the context of a W3C Recommendation is
> relatively simple.


> But let's not run ahead of ourselves. Maybe it turns out to be easy to
> define and implement font-format agnostic Web fonts, but I wouldn't make
> it a requirement to support multiple formats. OpenType still has a
> couple of years of life in it, I think, and if we can get everybody to
> agree to support embedded fonts based on OpenType and only OpenType, I'd
> already be quite happy.

Best of luck with that. ;-)


Received on Friday, 17 July 2009 02:03:16 UTC