Subject: [Justfont] Review of draft-ietf-justfont-toplevel-03.txt

From: Sean Leonard <[email-masked]>
Date: Wed, 16 Nov 2016 12:52:30 +0900

I have been meaning to review this draft and finally got around to it. Since it’s been submitted to the IESG I guess I should also cc IESG.

Other than the issues mentioned in the issue tracker, I noticed:

***
8.  New Registrations

   New font formats should be registered using the online form.  RFC 6838
   should be consulted on
   registration procedures.  In particular the font specification must
   be freely available and the ABNF must be followed.  Also, an @font-
   face format should be supplied and, if used, a definition of the
   fragment identifier syntax for the new type.

***

The third sentence may not (should not) always be true. Font specifications in the vnd. and prs. facets do not need to be “freely available”. “ABNF must be followed” is used without any references. What ABNF are you referring to? Of course “the ABNF” should be followed, but that is a consequence of RFC 6838 and others; this draft does not contain any ABNF.

It is not clear what the first two sentences really add to the text:

Of course new font formats should be registered using the online form. But, they should also be discussed on [email-masked] prior to attempting to register them formally. I do not see a reason to write this.

Of course RFC 6838 should be consulted on registration procedures...one could write that RFC 6838 MUST be consulted on registration procedures. But, unless this document changes something about RFC 6838 (which it does not), I do not see a reason to write this.

Other than these points, the document seems to be in pretty good shape.

Best regards,

Sean

---

From: Chris Lilley <[email-masked]>
Date: Wed, 16 Nov 2016 00:54:10 -0500

On 2016-11-15 22:52, Sean Leonard wrote:
> The third sentence may not (should not) always be true. Font specifications in the vnd. and prs. facets do not need to be “freely available”.
True; this section was thinking about new unfaceted registrations in the 
standards tree, as font/foo.

Perhaps "In particular (with the exception of new registrations in the 
vnd. and prs. facets) the font specification must ..."

>   “ABNF must be followed” is used without any references. What ABNF are you referring to? Of course “the ABNF” should be followed, but that is a consequence of RFC 6838 and others; this draft does not contain any ABNF.
Agreed, and already noted by Dale R. Worley; the clause has been removed.
> Of course RFC 6838 should be consulted on registration procedures...one could write that RFC 6838 MUST be consulted on registration procedures. But, unless this document changes something about RFC…
This document does not change anything about the registration procedures 
in general, but does require the form to be slightly updated (to allow 
the @font-face format to be supplied). The rest of that section is 
really just a reminder, rather than being normative. Do you consider 
that to be a bad idea? I do recall that people tend to forget to define 
fragment identifiers when registering new types, for example.
> Other than these points, the document seems to be in pretty good shape.
Thanks!

-- 
Chris Lilley
@svgeesus
Technical Director, W3C Interaction Domain

---

From: Sean Leonard <[email-masked]>
Date: Wed, 16 Nov 2016 18:55:51 +0900

> On Nov 16, 2016, at 2:54 PM, Chris Lilley <[email-masked]> wrote:
> 
> 
> 
> True; this section was thinking about new unfaceted registrations in the standards tree, as font/foo.

That is sort of what I gathered.

> Perhaps "In particular (with the exception of new registrations in the vnd. and prs. facets) the font specification must …"

As you just phrased, your concern is about the standards tree, not “all trees except for vendor and personal trees”. New trees (facets) could be made in the future with different requirements. The logic in the quote above is at odds with RFC 6838.

While making things “freely available” is always nice for implementers, that may not be possible or practical. I can certainly envision font registrations for legacy systems (Amiga? Commodore 64? NES?) where documentation is simply lost to time, or not available for free.

RFC 6838 strikes a specific balance on the availability of specifications (Note: it doesn’t actually require that any specifications are “free”--just that some are “available”.) Therefore, I would just drop these sentence(s). Put another way: if a registration that fits perfectly under the fonts/ primary type can’t meet this clause, it’s just going to be shunted to application/, and nobody really wants that.

> This document does not change anything about the registration procedures in general, but does require the form to be slightly updated (to allow the @font-face format to be supplied). The rest of that section is really just a reminder, rather than being normative. Do you consider that to be a bad idea? I do recall that people tend to forget to define fragment identifiers when registering new types, for example.

Yeah, IMO fragment identifiers are kind of a thorn in media types’ side overall: most media types don’t need them, and it tends to trip up registrations if and when they do (especially when fragment identifiers combine with structured syntax suffixes).

It is appropriate to point out @font-face. As for the rest of the points, I have said my point so it’s something for the rest of everyone else involved to consider. Reminders are okay for me (although they may be redundant and removable, that’s an editorial thing); it’s only when reminders raise potential conflicts with other texts that they become real problems.

About this @font-face thing: I note that all current registrations have the same subtype name. Have you/has the W3C considered simplifying this by having the @font-face src format registration converge with the subtype names? Hence registering font/woff automatically registers the @font-face format “woff” , and so on. I looked at <CR-css-fonts-3-20131003> and the only thing that raises an eyebrow is “svg”. Not sure how to handle that, perhaps registering font/svg has advantages and disadvantages, but that could be considered a corner case. If you are creating some NES emulator with NES fonts, font/nes (with @font-face format(nes)) or font/vnd.nintendo.nes (with @font-face format(vnd.nintendo.nes)) all make sense.

Regards,

Sean