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

[Sean Leonard <[e-mail]>]

> On Nov 16, 2016, at 2:54 PM, Chris Lilley <[e-mail]> wrote:
> 
> 
> 
> On 2016-11-15 22:52, Sean Leonard wrote:
>> ***
>> 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”.
> 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.

> 
>>  “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.
>> 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 [e-mail] 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.
> 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

>> Other than these points, the document seems to be in pretty good shape.
> Thanks!
> 
> -- 
> Chris Lilley
> @svgeesus
> Technical Director, W3C Interaction Domain
>