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 <chris(_at_)w3(_dot_)org> 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