[Gen-art] 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
.

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.

Minor issue:

>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


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Dale R. Worley]

My apologies; I should have responded quicker on this.  But I don't
think there are any comments here that affect the draft.  The various
wording matters I've not reviewed carefully, as I've already pointed out
my questions and I'll defer to the authors on their resolution.

But I see a technical issue:  RFC 6838 section 4.3 seems to leave
parameter values to be case-sensitive, so if you want them to be
case-insensitive, you are going to have to put that in the draft.

Chris Lilley  writes:
>> 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.

That seems to provide as much benefit as can be obtained while not
requiring any additional work.

>> 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?

If the acronym is usually written in upper case in text usage, it seems
to me that it's a better choice to write it in upper case as a parameter
value.

> Should it be made clearer in the current document that these are case 
> insensitive?

As far as I can figure out from RFC 6838 section 4.3, parameter *values*
are case-sensitive, so if you want them to be case insensitive, you'll
need to specify that.

>> 7.1.  Generic SFNT font type

>> 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).

My experience is that basically any class of software will (taken on the
whole) mis-process whitespace that appears in a particular context
unless the functional requirements stated clearly how whitespace is to
be handled.  RFC 6838 doesn't discuss whitespace, hence code to process
media type names can be expected to mis-process whitespace.

Though now that I look at RFC 6838 section 4.3, I see that it gives the
syntax of a parameter value as "restricted-name", and that does not
admit whitespace characters.

>> (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..

Interesting to know that.

OTOH, as for determining the type, it seems that the processor could do
a HEAD request on the font URL and examine the returned Content-Type.
(I wonder why I didn't think of that before?  Am I overlooking
something?)

>> 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 conceptuall

[Gen-art] Review of draft-harkins-owe-05

[Lucy Yong]

Reviewer: Lucy Yong
Review result: Ready with Nits

The draft is nearly ready for the publication.
 
Minor comment: Suggest adding this in security considerations: OWE
provides encryption over the wireless medium, i.e., Wi-Fi without
authentication. Thus it does not provide security for end-to-end
traffic.  users should still use application level security such as
VPN for end-to-end security. In this case, use of OWE prevents VPN
authentication info. to be spoofed in open public Wi-Fi.
one question: Will a user notices if OWE is used or not?  This may be
important for some users. 

nit: r/encryption of the wireless medium/encryption over the wireless
medium/



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art