Dale R. Worley
2016-10-30 22:17:51 UTC
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-justfont-toplevel-03
Reviewer: Dale R. Worley
Review Date: 2016-10-30
IETF LC End Date: 2016-11-09
IESG Telechat date: "Not yet"
Summary: This draft is on the right track but has open issues,
described in the review.
These issues are editorial, except:
whether the types font/ttf, font/otf, and font/collection are just
subsets of font/sntf
allowing whitespace in parameter values
whether these type names should be deprecated:
application/x-font-ttf
application/font-sfnt
application/vns.ms-fontobject
--
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
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".
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).
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)".
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.
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.
registered as MIME subtypes under the "application" top-level type
That should be "media subtypes".
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".
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..
the widespread adoption of IANA's recommendations
What "recommendations" are these?
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".
Many existing (TrueType,
OpenType [opentype-wiki] and OFF, SIL Graphite, WOFF, etc.) font
formats [...]
This reads awkwardly. Better "Many existing font formats (TrueType
[...]) [...]".
in a way that would not affect existing font rendering engines and
text layout implementations.
Better "in an upward-compatible way".
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 ..."?
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.
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".
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".
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".
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.
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".
Similarly for other uses of "supported".
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.
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.
Parameter definitions seem to need specification of registration
procedures. (See the sub-type-parameter registry mentioned above;
each parameter has a listed registration procedure.)
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".
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.
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".
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".
(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?)
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. 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.
--
Applications that use this media type: Any and all applications that
"Any and all" sounds rhetorical. Better to say just "All".
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?
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?
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?)
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.
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.
Of course, this assumes that the collection has an implicit order, but
I assume that you know that is true.
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. 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.
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.
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.
Dale
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-justfont-toplevel-03
Reviewer: Dale R. Worley
Review Date: 2016-10-30
IETF LC End Date: 2016-11-09
IESG Telechat date: "Not yet"
Summary: This draft is on the right track but has open issues,
described in the review.
These issues are editorial, except:
whether the types font/ttf, font/otf, and font/collection are just
subsets of font/sntf
allowing whitespace in parameter values
whether these type names should be deprecated:
application/x-font-ttf
application/font-sfnt
application/vns.ms-fontobject
--
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
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".
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).
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)".
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.
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.
registered as MIME subtypes under the "application" top-level type
That should be "media subtypes".
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".
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..
the widespread adoption of IANA's recommendations
What "recommendations" are these?
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".
Many existing (TrueType,
OpenType [opentype-wiki] and OFF, SIL Graphite, WOFF, etc.) font
formats [...]
This reads awkwardly. Better "Many existing font formats (TrueType
[...]) [...]".
in a way that would not affect existing font rendering engines and
text layout implementations.
Better "in an upward-compatible way".
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 ..."?
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.
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".
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".
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".
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.
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".
Similarly for other uses of "supported".
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.
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.
Parameter definitions seem to need specification of registration
procedures. (See the sub-type-parameter registry mentioned above;
each parameter has a listed registration procedure.)
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".
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.
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".
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".
(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?)
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. 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.
--
Applications that use this media type: Any and all applications that
"Any and all" sounds rhetorical. Better to say just "All".
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?
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?
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?)
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.
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.
Of course, this assumes that the collection has an implicit order, but
I assume that you know that is true.
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. 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.
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.
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.
Dale