Re: [Gen-art] Gen-ART IETF Last Call review of draft-ietf-justfont-toplevel-03 (Dale R. Worley) Sat, 10 December 2016 02:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9C241295E8 for <>; Fri, 9 Dec 2016 18:42:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cKiqymhHxdtn for <>; Fri, 9 Dec 2016 18:42:25 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CE3DC12959B for <>; Fri, 9 Dec 2016 18:42:25 -0800 (PST)
Received: from ([]) by with SMTP id FXbycyhyv9XRkFXcHcjfYX; Sat, 10 Dec 2016 02:42:25 +0000
Received: from ([]) by with SMTP id FXcFcjSX16d0CFXcGc08pl; Sat, 10 Dec 2016 02:42:24 +0000
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id uBA2gNXL011242; Fri, 9 Dec 2016 21:42:23 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id uBA2gLss011234; Fri, 9 Dec 2016 21:42:21 -0500
X-Authentication-Warning: worley set sender to using -f
To: Chris Lilley <>
In-Reply-To: <> (
Date: Fri, 09 Dec 2016 21:42:21 -0500
Message-ID: <>
X-CMAE-Envelope: MS4wfNOABChmsLxEHvPquVuf39MKgGAN8cuOfm9PvBmTMlzfSm2kjZ+vF5jKJk/xwkGzfIHQnsMsITJfZdva3ix/+1aQRil1HPFsL0mrVu1+WlHujKQcvBJN hso75Wlk8J4VeZ8yIqQWgtHvAy8G5bZez1Ev+HWHOMOxiPDqd+c0muZQavvqqdskWvHYsRR7rnwQBb+Tz0EdZ/jtVHF/m9avLGyXRSX/FQ06N7nPbRh8z3m0 L0hZAChfiKZvl3PS3gYIPFo/X9ku3IDQHZnJQP3Io1g=
Archived-At: <>
Subject: Re: [Gen-art] Gen-ART IETF Last Call review of draft-ietf-justfont-toplevel-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Dec 2016 02:42:28 -0000

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

> 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

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

It might be useful to put this into the draft so that people use these
types like you expect them to.

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

And I see that you've made that change in the -05 version.