Re: Gen-ART IETF Last Call review of draft-ietf-justfont-toplevel-03

[Chris Lilley <[e-mail]>]

On 2016-10-30 18:17, Dale R. Worley wrote:
> The current RFC Editor preference seems to be that section titles
> should capitalize the first and "important" words.  Some of the
> section titles adhere to this format but the following ones do not:
>
>      1.  Specification development
>      4.  Security considerations
>      6.  Definition and encoding
>      7.  Defined subtypes
>      7.1.  Generic SFNT font type
>      7.2.  TTF font type
>      7.3.  OTF font type
>      7.4.  Collection font type
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/15dc1b1eb6227cbb88a8e5e719ef55586474c946 

> 1.  Specification development
>
> If this section is only relevant to the Internet-Draft, this section
> should have a note to the RFC Editor to remove it upon publication.
> If it is intended for ongoing development after the Internet-Draft
> becomes an RFC, the wording should be revised since, e.g., once an RFC
> is published, it is fixed, so "this specification" cannot be
> "maintained".
Note to RFC Editor added by
https://github.com/svgeesus/ietf-justfont/commit/106cadf7ba71d6db6bda2c740e31ba7680f6b0be
> 2.  Introduction
>
> The first two paragraphs of this section do not connect easily.  It
> seems that second paragraph should start like this:
>
>      Over time, a number of standard formats for recording font
>      descriptions have evolved.  This document defines a new top-level
>      Internet media type "font" according to Section 4.2.7 of
>      [RFC6838].  The subtypes under under this top-level type specify
>      different representation formats for fonts (e.g. bitmap or outline
>      formats).
Connecting sentence added
> However, "bitmap" and "outline" are just general properties or styles,
> not font representation standards, so really those words should be
> replaced by the names of specific font representations, say "(e.g.,
> bitmap formats like ABC and outline formats like XYZ)".
and parenthetical example removed.
https://github.com/svgeesus/ietf-justfont/commit/23d2944778b3f6b308b8575a092f3bd9e9a9a78c

> 3.  Background and Justification
>
> The names
>
>      application/x-font-ttf
>      application/font-woff
>      application/font-sfnt
>
> are mentioned in the text as being in current use, but only
> application/font-woff is listed as a deprecated alias of a registered
> type.  The other two should also be listed as deprecated aliases of
> the proper new types.
Agreed for application/font-sfnt. I had forgotten that this registration 
was in fact completed.
https://github.com/svgeesus/ietf-justfont/commit/76dfc5377a91442b861f47aa9b8273fd010a7728

Not clear what to do for an x- type, which cannot be registered (but is 
in use anyway). Is it helpful to formally deprecate it?

> The use of application/vns.ms-fontobject should be discussed.  It
> seems like you'd want it to be a deprecated alias as well, but the
> politics of deprecating that name might be complex.
Yes, it should be discussed. This registration is for Embedded OpenType 
(EOT).

I created an issue for this
https://github.com/svgeesus/ietf-justfont/issues/22

 From the standpoint of regularity, it would seem clear that a font/eot 
should be defined.

This internet draft largely formalizes existing practice, where for 
example font/ttf is in widespread use. Given that, and given that a) 
application/vns.ms-fontobject is already in widespread use, b) the 
current Microsoft Edge browser no longer supports EOT; the only use for 
this type is legacy Microsoft Internet Explorer browsers, which (being 
legacy) will not update to use the new type.

It seems better therefore, to me, to leave application/vns.ms-fontobject 
to die quietly in a corner and neither deprecate it nor attempt to 
provide a new media type for it.

Discussion welcome.
>     registered as MIME subtypes under the "application" top-level type
>
> That should be "media subtypes".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/96d94a0b3efe4e0bd10009d70a4b2c396842424e 

>    Secondly, the lack of a top-level type means that there is no
>     opportunity to have a common set of optional attributes, such as are
>     specified here.
>
> Media types use the term "parameter" rather than "attribute".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/46243cc5991cac5a2128c9ce34857528b51ec275 

>     The W3C WebFonts WG decided that the situation can be significantly
>     improved [...]
>
> Is there a reference for this decision?  It is a significant part of
> the justification for this registration, and so should be documented..
Agreed, informative reference added by
https://github.com/svgeesus/ietf-justfont/commit/bd0bf07ccb4e6bce9c4d86d7af67d37f2818fe5a

>     the widespread adoption of IANA's recommendations
>
> What "recommendations" are these?
changed to
     "Based on the data analysis
       presented above, we conclude that it is the presence of simple 
and highly intuitive media types
       for images that caused their widespread adoption, "
https://github.com/svgeesus/ietf-justfont/commit/fa298417406d991ab168d93bad6a3bc08cc56346
> 4.  Security considerations
>
>     Depending on the format used to represent the glyph data the
>     font may contain TrueType [truetype-wiki], PostScript
>     [postscript-wiki] or SVG [svg-wiki] outlines and their respective
>     hint instructions, where applicable.
>
> The construction "may contain ... where applicable" is awkward, as
> both parts indicate possible-but-not-mandatory.  I suggest removing
> "where applicable".
This is trying to say that TrueType outlines may be associated with 
imperative hinting instructions; PostScript outlines may be associated 
with declarative hinting instructions, and SVG outlines do not have 
hinting instructions. Imperative instructions are actual code, which has 
the potential to be maliciously constructed.

Reworded as:
     "In particular, the hinting instructions for TrueType glyphs 
represent executable code which has
       the potential to be maliciously constructed (for example, 
intended to hang the interpreter)."
https://github.com/svgeesus/ietf-justfont/commit/3b2845a0cee88c7359571ff1fd58bdb0ab3546d1
>     Many existing (TrueType,
>     OpenType [opentype-wiki] and OFF, SIL Graphite, WOFF, etc.) font
>     formats [...]
>
> This reads awkwardly.  Better "Many existing font formats (TrueType
> [...]) [...]".
>
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/b132414a5668c5f9da6d6a002f74cb92e6fabb17
>     in a way that would not affect existing font rendering engines and
>     text layout implementations.
>
> Better "in an upward-compatible way".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/fe90c1e256003cfbd26ab4d5e3346569a4701a48 

>     Indeed, fonts are sufficiently complex, and most
>     (if not all) interpreters cannot be completely protected from
>     malicious fonts without undue performance penalties.
>
> The significance of "are sufficiently complex" is unclear.  Do you
> mean, "fonts are sufficiently complex that most ..."?
Yes. Fixed by
https://github.com/svgeesus/ietf-justfont/commit/50118dc0cbaf4947f5dd12e5c4dd00b93618bf46
> 5.  IANA Considerations
>
>     This specification requires IANA to modify the rules for the existing
>     Internet Media Types registry by adding a new font top-level type in
>     the standards tree, updating the media types registration form
>     [Media-Type-Registration], and registering several subtypes.
>
> This is better said:
>
>     This specification registers a new top-level type, "font", in the
>     standards tree; adds it as an alternative value of "Type Name" in the
>     media types registration form [Media-Type-Registration]; and
>     registers several subtypes for it.
>
> Also, it helps greatly if all of the IANA registration operations are
> within the section titled "IANA Considerations".  See RFC 7322 section
> 4.8.3.  So sections 6 and 7 should be demoted to sections 5.1 and 5.2.
Agreed, and fixed by
https://github.com/svgeesus/ietf-justfont/commit/e6a3210bf9e3aaf84b55fa5bf846f9605fd20597
> 6.  Definition and encoding
>
>     The "font" as the primary media content type indicates that the
>     content identified by it requires certain graphic subsystem such as
>     font rendering engine (and, in some cases, text layout and shaping
>     engine) to process font data [...]
>
> I think you want "to process it as font data".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/67a2f2c325c1bb479f108761d0d1606d55315ba6 

>     the subtypes defined within a "font" tree will name the specific
>     font formats.
>
> Since this is, in fact, part of the specification of "font", I think
> you want to say it in the present tense, "the subtypes defined within
> the "font" tree name the specific font formats".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/c725ff323517f41a20e50b6bc7c76eaaf60c332d
> 7.  Defined subtypes
>
> Would "Subtype Registrations" be more correct?  There really aren't
> any "undefined subtypes" that are considered to exist.
>
>     In this section the initial entries under the top-level 'font' MIME
>     type are documented.
>
> I think "specified" rather than "documented".  Also, change "MIME
> type" to "media type".
All agreed; fixed by
https://github.com/svgeesus/ietf-justfont/commit/c339a2cbd152f8c0493681a746ed21be907cade9
>     Optional parameters:
>
> In general, parameter names seem to be specified using lower case,
> though they are case-insensitive, so you may want to lower-case your
> parameter name definitions.
Parameter names changed to lowercase in current draft.
https://github.com/svgeesus/ietf-justfont/commit/8bfb3e6c8958b6ce231677c394c3a8aea51230e2

Parameter values which are acronyms left as upper case - is that good 
practice?
Should it be made clearer in the current document that these are case 
insensitive?


> 7.1.  Generic SFNT font type
>
>           This parameter can be used to specify the type of outlines
>           supported by the font.
>
> I don't think "supported by" is the best here.  Perhaps "provided by".
Agreed, and fixed by
https://github.com/svgeesus/ietf-justfont/commit/2afdee1db67350f61bc6c97216a473a7b7d31119 

> Similarly for other uses of "supported".
I reviewed those, and disagree. The remaining uses of "supported" talk 
about code, and whether that code supports or does not support a 
particular thing (outline format, feature, etc).
>           this
>           optional parameter is a list containing one or more items,
>           separated by commas, with optional whitespace.
>
> I strongly recommend against allowing whitespace in parameter values.
> It seems to be allowed in principle (RFC 6838 section 4.3), but I
> expect many processors of media types to misbehave on parameter values
> containing whitespace.
Okay (I was not aware that processors were known to misbehave on spaces 
in parameter values, and would be interested to know more about that).

I can also see that people might expect to use spaces.

I suspect this comment would benefit from some discussion, so have 
opened an issue for it:
https://github.com/svgeesus/ietf-justfont/issues/24

> I can see why a comma-separated list is necessary, but that means that
> "Values: TTF, CFF, SVG" is not strictly correct.  Perhaps something
> like the following (and let IANA figure out how to express that in
> http://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml)
>
>      Values: a comma-separated subset of: TTF, CFF, SVG
>
> Similarly for other parameters which can take a comma-separated list
> of defined values.

(Deferred until issue discussion has happened)

> Parameter definitions seem to need specification of registration
> procedures.  (See the sub-type-parameter registry mentioned above;
> each parameter has a listed registration procedure.)

I'm not quite clear on what is meant here. Registration of new 
parameters beyond those specified in this specification?

Issue created:
https://github.com/svgeesus/ietf-justfont/issues/25
>     Interoperability considerations:  As it was noted in the first
>        paragraph of the "Security considerations" section, the same font
>        format wrapper can be used to encode fonts with different types of
>        glyph data represented as either TrueType or PostScript (CFF)
>        outlines.
>
> This isn't phrased quite right.  Perhaps "a single font file can
> contain encoding of the same glyphs using several different
> representations, e.g., both TrueType and PostScript outlines".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/bc11eae185f596dac69b447e994e7eb0d340b241

>        Existing font rendering engines may not be able to
>        process some of the particular outline formats, and downloading a
>        font resource that contains unsupported glyph data format would
>
> Change "unsupported glyph data" to "only unsupported glyph data" -- as
> long as the font contains one format supported by the engine,
> downloading the font is useful.
Good catch.
>        result in inability of application to render and display text.
>
> This seems unlikely; rather the engine would have to use some default
> font.  So say "... would be futile".
Agreed.
These two fixed by
https://github.com/svgeesus/ietf-justfont/commit/43fe0fd57ddf6ddbb8e4eaf999d82052064bf89e

>        Therefore, it would be extremely useful to clearly identify the
>        format of the glyph outline data within a font using an optional
>        parameter, and allow applications to make decisions about
>        downloading a particular font resource sooner.
>
> Change "it would be" to "it is", or better, "it is useful to provide a
> way to identify the format".
Agreed, fixed by
https://github.com/svgeesus/ietf-justfont/commit/035cb04837c6c1b6367db5e4b916dc84791f54c4

> (Which begs the question of whether there is an efficient way for the
> browser to determine the media type parameter without downloading the
> font -- how does the browser get the media type of the font file without
> a GET?)
In principle the Accept header could be used, for classic server-based 
content negotiation.

In practice that does not seem to be used, at least by Web browsers; 
they send the same formulaic accept regardless of the type of resource 
being requested, and most HTTP servers are not set up to support content 
negotiation at all..
>
>        Similar, another
>        optional parameter is suggested to identify the type of text
>
> Better as "Similarly, another optional parameter identifies".
>
>        Please
>        note that as new outline formats and text shaping mechanisms may
>        be defined in the future, the set of allowed values for two
>        optional parameters defined by this section may be extended.
>
> This should probably be stated under the registration procedures for
> the values of these parameters.
Agreed, reworded as suggested and the "Please note" deleted
https://github.com/svgeesus/ietf-justfont/commit/4b05417a335d1cf37f6483b293185fd14258b98e

>    This possibility is subtly different
> from simply adding to a list of allowed values; it warns the
> implementation that the sub-values within the comma-separated list may
> be unknown and if so, only the known values should be processed.
> Indeed, that should probably be said more explicitly:
>
>      Registration procedures:
>
>        Expert Review (?)
>
>        Note that new sub-values may be defined in the future.  If an
>        implementation does not recognize a sub-value in the
>        comma-separated list, it should ignore the sub-value and continue
>        processing the other sub-values in the list.
Agreed, Registration procedures moved into section 5 and your suggested 
wording added.
https://github.com/svgeesus/ietf-justfont/commit/8ddc9105109c161df21a2ee8cc40bc79189d72cc

Why should, rather than must?

>     Applications that use this media type:  Any and all applications that
>
> "Any and all" sounds rhetorical.  Better to say just "All".
Yes
https://github.com/svgeesus/ietf-justfont/commit/0678903b9f920e25eea7dc81f490e009db186fc4

> 7.2.  TTF font type
>
> Similar comments as for section 7.1
>
> Indeed, isn't 7.2 just a subset of 7.1?  Why is it separately defined?
It is a subtype, yes. In principle, the sfnt type could be used for TTF, 
OTF and Collection

It is separately defined because

a) font/ttf is shorter than font/sfnt; outlines=ttf
b) font/ttf is already in widespread use (despite not yet being 
registered; see the data analysis in the informative references) and 
this specification is aligning with actual practice.
c) avoiding parameters unless absolutely needed makes server 
configuration easier, perhaps

In other words font/sfnt is more of an abstract type, from which the 
(widely used in practice) font/ttf and font/otf types are conceptually 
derived. Use of  font/sfnt is likely to be rare in practice, and might 
be confined to
a) uncommon combinations such as font/sfnt; outlines=sil which do not 
have a shorter type
b) cases where a new parameter values is registered
c) test cases, experimentation, etc
> 7.3.  OTF font type
>
> Similar comments as for section 7.1
>
> Indeed, isn't 7.3 just a subset of 7.1?  Why is it separately defined?
>
> 7.4.  Collection font type
>
> Similar comments as for section 7.1
>
> Indeed, isn't 7.3 just a subset of 7.1?  Why is it separately defined?
Same answers as above regarding subsets.

Same changes to interoperability considerations
https://github.com/svgeesus/ietf-justfont/commit/49d768f1ee382b2279acc1803af149573d5c1317
>
> 7.5.  WOFF 1.0
>
>        Macintosh Universal Type Identifier code:  "org.w3c.woff"
>
> Is this part of a media type registration?  (If so, is it required for
> all "font" subtypes?)

If I recall correctly, this information was added during review on 
ietf-types list of the original applications/font-woff media type, in 
response to a comment that Macintosh File Type Codes (which we had in 
the original proposal, as part of "Additional Information") were being 
replaced by Macintosh Universal Type Identifier codes.

The registration is here
https://www.iana.org/assignments/media-types/application/font-woff

I haven't seen any indication that this information is useful or 
necessary, and no of know way to check that the information is in fact 
correct, or used by macOS.

I would be in favor of dropping it, unless it can be shown that is is 
needed and correct.

I raised an issue
https://github.com/svgeesus/ietf-justfont/issues/26

>
> 7.6.  WOFF 2.0
>
>        Fragment Identifiers  Optional, for collections encoded as WOFF
>
> Fragment identifiers are always optional, since an HTTP request never
> identifies the fragment.
They are optional in an HTTP request. They may not be optional in a url 
(if the file is a font collection and the font referred to is not the 
first font in the collection.

However, I removed the "Optional".
https://github.com/svgeesus/ietf-justfont/commit/c5df61052d4e2058b8366ea38e22884304d6676d

>        Fragment Identifiers  Optional, for collections encoded as WOFF
>           2.0.  A positive integer.  For example, #2 refers to the second
>           font in the collection.  If a fragment is not specified, it is
>           the same as #1 i.e. the first font in the collection (or the
>           only font, if it is not a collection).  If a fragment is
>           specified, and the WOFF does not encode a collection, the
>           fragment is ignored.
>
> This is awkward.  Maybe better:
>
>        Fragment Identifiers:  If the WOFF is not a collection, the only
>        fragment identifier is "1", which specifies the only font
>        contained in the object.  If the WOFF is a collection, an
>        integer (1-origin) specifying a font contained in the
>        collection.

Updated to use your suggested text:
https://github.com/svgeesus/ietf-justfont/commit/c28057591b37c91a2c75e61d732324df7b24091b
> Of course, this assumes that the collection has an implicit order, but
> I assume that you know that is true.
It is true for a particular revision of a font collection.

The order is not retained between revisions (new fonts may be, and are, 
inserted rather than appended when a collection is revised) , which 
makes these fragments fragile in certain cases. Use of the PostScript 
name, rather than an integer, has been suggested.

See the related issue:
*
**Fragment syntax for collections should be robust against inserting, as 
well as appending, new fonts to a collection*
https://github.com/svgeesus/ietf-justfont/issues/18
> 8.  New Registrations
>
>     New font formats should be registered using the online form
>     [Media-Type-Registration].  RFC 6838 [RFC6838] 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.
>
> This is really the "registration procedures" for the "font" type.  So
> I'd move this to section 5.
Done, see above.

>   I'm not sure what "the ABNF" is that must
> be followed, but that seems a redundant statement, as if there is a
> prescribed ABNF, then necessarily it must be followed.
Agreed, and that clause removed.
https://github.com/svgeesus/ietf-justfont/commit/16b59b33812ee490eb496439af0bb6df50cbd238 

> 9.2.  Informative References
>
>     [cff-wiki]
>                "CFF",<https://en.wikipedia.org/wiki/ PostScript_fonts#Compact_Font_Format>.

>
> This reference isn't referenced in the text.
>
>     [postscript-wiki]
>                "PostScript".
>
> This reference contains no bibliographic information.
It should have, since the source is

<reference anchor="postscript-wiki" target="">
         <front>
           <title>PostScript</title>
           <author><organization/></author>
           <date/>
           <abstract><t>PostScript (PS) is a computer language for 
creating vector
           graphics. It is a dynamically typed, concatenative 
programming language and
           was created at Adobe Systems by John Warnock, Charles 
Geschke, Doug Brotz,
           Ed Taft and Bill Paxton from 1982 to 1984.</t></abstract>
         </front>
       </reference>

Ah, I see what happened (both are links to the same wikipedia article, 
one to a specific section).

I fixed this by referencing cff-wiki instead of postscript-wiki and 
deleting the latter.
https://github.com/svgeesus/ietf-justfont/commit/eaa43e8c9bc26ffecaf8f75f26dbf8d5e5c27ee4
> 9.3.  URIs
>
> If these are intended to be in the final RFC, they should be changed
> into proper references.  If they aren't intended to be in the final
> RFC, this section should have a note to the RFC Editor to delete it.
This section is autogenerated by xml2rfc. However, all three come from 
the "Specification development" section, which now contains a note to 
the RFC Editor to delete it. Thus, the final RFC should not have this 
URIs section.

Many thanks for your thorough review!

To make review easier, I posted an updated draft-04 just now which 
contains all the edits made above.


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