Review of draft-ietf-justfont-toplevel-05

[Dale Worley]

Reviewer: Dale Worley
Review result: On the Right Track

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-justfont-toplevel-05
Reviewer: Dale R. Worley
Review Date: 2016-12-09
IETF LC End Date: 2016-11-09
IESG Telechat date: 2016-12-15

Summary:

This draft is on the right track but has open issues, described in the
review.

Major issue:

Section 5.3.4, Collection Font Type (font/collection)

Fragment Identifiers A string, no longer than 63 characters and
restricted to the printable ASCII subset, codes 33 - 126,
except for the 10 characters '[', ']', '(', ')', '{', '}',
'<',
'>', '/', '%'. If this string matches one of the PostScript
names (name ID=6) [ISO.14496-22.2015] in the name table, that
font is selected. For example, "#Foo-Bold" refers to the
font
with PostScript name Foo-Bold. If the name does not match,
or
if a fragment is not specified, the first font in the
collection is matched. Note that the order of fonts in
collections may change as the font is revised, so relying on
a
particular font in a collection always being first is unwise.

However, the characters '"', '#', '\', '^', '`', '|' are not
admissible in fragment identifiers, per RFC 3986.

It appears from ISO 14496-22 that those characters are allowed in font
PostScript names, so you probably want to enable the use of %-escapes
in fragment identifiers to represent those six characters.

From my correspondence with the author, I think his intention is that

the parameter values should be case-insensitive. It seems to me that
RFC 6838 section 4.3 makes the values case-sensitive by default, so if
they are intended to be case insensitive, that needs to be specified.

Dale

[Chris Lilley]

On 2016-12-09 22:10:14, Dale Worley <***@ariadne.com> wrote:
Major issue:

Section 5.3.4, Collection Font Type (font/collection)

Fragment Identifiers A string, no longer than 63 characters and
restricted to the printable ASCII subset, codes 33 - 126,
except for the 10 characters '[', ']', '(', ')', '{', '}',
'<',>
'>', '/', '%'. If this string matches one of the PostScript
names (name ID=6) [ISO.14496-22.2015] in the name table, that
font is selected. For example, "#Foo-Bold" refers to the
font
with PostScript name Foo-Bold. If the name does not match,
or
if a fragment is not specified, the first font in the
collection is matched. Note that the order of fonts in
collections may change as the font is revised, so relying on
a
particular font in a collection always being first is unwise.

However, the characters '"', '#', '\', '^', '`', '|' are not
admissible in fragment identifiers, per RFC 3986.

It appears from ISO 14496-22 that those characters are allowed in font
PostScript names, so you probably want to enable the use of %-escapes
in fragment identifiers to represent those six characters.
Chris Lilley: 
Thank you for spotting this. I examined the grammar in RFC 3986 and agree that these six characters, which are allowed in PostScript names, would need to be percent escaped.

Because this subsection was getting a bit long (and appeared in two places) I created a new section on fragments for font collections. I added a list of characters to escape and added a second example with an escaped character. i clarified that the fragment is un-escaped prior to comparing with name table entries.

I also added a normative reference to RFC 3986.

I have submitted a new draft -06 with this change.

From my correspondence with the author, I think his intention is that

the parameter values should be case-insensitive. It seems to me that
RFC 6838 section 4.3 makes the values case-sensitive by default, so if
they are intended to be case insensitive, that needs to be specified.
Chris Lilley: 

I left these as case-sensitive per RFC 6838.

--
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

[Jari Arkko]

Dale:

Thank you very much spotting these issues. And Chris, happy to see that the fix is already on the way!

Jari