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

[[e-mail] (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 <[e-mail]> 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 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.

Dale