|
On 2016-10-30 18:17, Dale R. Worley
wrote:
Agreed, fixed by https://github.com/svgeesus/ietf-justfont/commit/15dc1b1eb6227cbb88a8e5e719ef55586474c946 Note to RFC Editor added by1. Specification development If this section is only relevant to the Internet-Draft, this section should have a note to the RFC Editor to remove it upon publication. If it is intended for ongoing development after the Internet-Draft becomes an RFC, the wording should be revised since, e.g., once an RFC is published, it is fixed, so "this specification" cannot be "maintained". https://github.com/svgeesus/ietf-justfont/commit/106cadf7ba71d6db6bda2c740e31ba7680f6b0be
Connecting sentence added
and parenthetical example removed.However, "bitmap" and "outline" are just general properties or styles, not font representation standards, so really those words should be replaced by the names of specific font representations, say "(e.g., bitmap formats like ABC and outline formats like XYZ)". https://github.com/svgeesus/ietf-justfont/commit/23d2944778b3f6b308b8575a092f3bd9e9a9a78c
Agreed for application/font-sfnt. I had forgotten that this
registration was in fact completed.https://github.com/svgeesus/ietf-justfont/commit/76dfc5377a91442b861f47aa9b8273fd010a7728 Not clear what to do for an x- type, which cannot be registered (but is in use anyway). Is it helpful to formally deprecate it? Yes, it should be discussed. This registration is for Embedded OpenType (EOT).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. 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. Discussion welcome. Agreed, fixed byregistered as MIME subtypes under the "application" top-level type That should be "media subtypes". https://github.com/svgeesus/ietf-justfont/commit/96d94a0b3efe4e0bd10009d70a4b2c396842424e Agreed, fixed bySecondly, the lack of a top-level type means that there is no opportunity to have a common set of optional attributes, such as are specified here. Media types use the term "parameter" rather than "attribute". https://github.com/svgeesus/ietf-justfont/commit/46243cc5991cac5a2128c9ce34857528b51ec275 Agreed, informative reference added byThe W3C WebFonts WG decided that the situation can be significantly improved [...] Is there a reference for this decision? It is a significant part of the justification for this registration, and so should be documented.. https://github.com/svgeesus/ietf-justfont/commit/bd0bf07ccb4e6bce9c4d86d7af67d37f2818fe5a changed tothe widespread adoption of IANA's recommendations What "recommendations" are these? "Based on the data analysis presented above, we conclude that it is the presence of simple and highly intuitive media types for images that caused their widespread adoption, " https://github.com/svgeesus/ietf-justfont/commit/fa298417406d991ab168d93bad6a3bc08cc56346 This is trying to say that TrueType outlines may be associated with imperative hinting instructions; PostScript outlines may be associated with declarative hinting instructions, and SVG outlines do not have hinting instructions. Imperative instructions are actual code, which has the potential to be maliciously constructed.4. Security considerations Depending on the format used to represent the glyph data the font may contain TrueType [truetype-wiki], PostScript [postscript-wiki] or SVG [svg-wiki] outlines and their respective hint instructions, where applicable. The construction "may contain ... where applicable" is awkward, as both parts indicate possible-but-not-mandatory. I suggest removing "where applicable". Reworded as: "In particular, the hinting instructions for TrueType glyphs represent executable code which has the potential to be maliciously constructed (for example, intended to hang the interpreter)." https://github.com/svgeesus/ietf-justfont/commit/3b2845a0cee88c7359571ff1fd58bdb0ab3546d1 Agreed, fixed byMany existing (TrueType, OpenType [opentype-wiki] and OFF, SIL Graphite, WOFF, etc.) font formats [...] This reads awkwardly. Better "Many existing font formats (TrueType [...]) [...]". https://github.com/svgeesus/ietf-justfont/commit/b132414a5668c5f9da6d6a002f74cb92e6fabb17 Agreed, fixed byin a way that would not affect existing font rendering engines and text layout implementations. Better "in an upward-compatible way". https://github.com/svgeesus/ietf-justfont/commit/fe90c1e256003cfbd26ab4d5e3346569a4701a48 Yes. Fixed byIndeed, fonts are sufficiently complex, and most (if not all) interpreters cannot be completely protected from malicious fonts without undue performance penalties. The significance of "are sufficiently complex" is unclear. Do you mean, "fonts are sufficiently complex that most ..."? https://github.com/svgeesus/ietf-justfont/commit/50118dc0cbaf4947f5dd12e5c4dd00b93618bf46 Agreed, and fixed by5. IANA Considerations This specification requires IANA to modify the rules for the existing Internet Media Types registry by adding a new font top-level type in the standards tree, updating the media types registration form [Media-Type-Registration], and registering several subtypes. This is better said: This specification registers a new top-level type, "font", in the standards tree; adds it as an alternative value of "Type Name" in the media types registration form [Media-Type-Registration]; and registers several subtypes for it. Also, it helps greatly if all of the IANA registration operations are within the section titled "IANA Considerations". See RFC 7322 section 4.8.3. So sections 6 and 7 should be demoted to sections 5.1 and 5.2. https://github.com/svgeesus/ietf-justfont/commit/e6a3210bf9e3aaf84b55fa5bf846f9605fd20597 Agreed, fixed by6. Definition and encoding The "font" as the primary media content type indicates that the content identified by it requires certain graphic subsystem such as font rendering engine (and, in some cases, text layout and shaping engine) to process font data [...] I think you want "to process it as font data". https://github.com/svgeesus/ietf-justfont/commit/67a2f2c325c1bb479f108761d0d1606d55315ba6 Agreed, fixed bythe subtypes defined within a "font" tree will name the specific font formats. Since this is, in fact, part of the specification of "font", I think you want to say it in the present tense, "the subtypes defined within the "font" tree name the specific font formats". https://github.com/svgeesus/ietf-justfont/commit/c725ff323517f41a20e50b6bc7c76eaaf60c332d All agreed; fixed by7. Defined subtypes Would "Subtype Registrations" be more correct? There really aren't any "undefined subtypes" that are considered to exist. In this section the initial entries under the top-level 'font' MIME type are documented. I think "specified" rather than "documented". Also, change "MIME type" to "media type". https://github.com/svgeesus/ietf-justfont/commit/c339a2cbd152f8c0493681a746ed21be907cade9 Parameter names changed to lowercase in current draft.Optional parameters: 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. https://github.com/svgeesus/ietf-justfont/commit/8bfb3e6c8958b6ce231677c394c3a8aea51230e2 Parameter values which are acronyms left as upper case - is that good practice? Should it be made clearer in the current document that these are case insensitive?
Agreed, and fixed byhttps://github.com/svgeesus/ietf-justfont/commit/2afdee1db67350f61bc6c97216a473a7b7d31119 I reviewed those, and disagree. The remaining uses of "supported" talk about code, and whether that code supports or does not support a particular thing (outline format, feature, etc).Similarly for other uses of "supported".
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).I can also see that people might expect to use spaces. I suspect this comment would benefit from some discussion, so have opened an issue for it: https://github.com/svgeesus/ietf-justfont/issues/24 I can see why a comma-separated list is necessary, but that means that "Values: TTF, CFF, SVG" is not strictly correct. Perhaps something like the following (and let IANA figure out how to express that in http://www.iana.org/assignments/media-type-sub-parameters/media-type-sub-parameters.xhtml): Values: a comma-separated subset of: TTF, CFF, SVG Similarly for other parameters which can take a comma-separated list of defined values. (Deferred until issue discussion has happened) Parameter definitions seem to need specification of registration procedures. (See the sub-type-parameter registry mentioned above; each parameter has a listed registration procedure.) I'm not quite clear on what is meant here. Registration of new parameters beyond those specified in this specification? Issue created: https://github.com/svgeesus/ietf-justfont/issues/25
Agreed, fixed byhttps://github.com/svgeesus/ietf-justfont/commit/bc11eae185f596dac69b447e994e7eb0d340b241
Good catch. Agreed.result in inability of application to render and display text. This seems unlikely; rather the engine would have to use some default font. So say "... would be futile". These two fixed by https://github.com/svgeesus/ietf-justfont/commit/43fe0fd57ddf6ddbb8e4eaf999d82052064bf89e
Agreed, fixed byhttps://github.com/svgeesus/ietf-justfont/commit/035cb04837c6c1b6367db5e4b916dc84791f54c4 In principle the Accept header could be used, for classic server-based content negotiation.(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 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..
Agreed, reworded as suggested and the "Please note" deletedhttps://github.com/svgeesus/ietf-justfont/commit/4b05417a335d1cf37f6483b293185fd14258b98e
Agreed, Registration procedures moved into section 5 and your
suggested wording added.https://github.com/svgeesus/ietf-justfont/commit/8ddc9105109c161df21a2ee8cc40bc79189d72cc Why should, rather than must? YesApplications that use this media type: Any and all applications that "Any and all" sounds rhetorical. Better to say just "All". https://github.com/svgeesus/ietf-justfont/commit/0678903b9f920e25eea7dc81f490e009db186fc4 It is a subtype, yes. In principle, the sfnt type could be used for TTF, OTF and Collection7.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 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 Same answers as above regarding subsets.7.3. OTF font type Similar comments as for section 7.1 Indeed, isn't 7.3 just a subset of 7.1? Why is it separately defined? 7.4. Collection font type Similar comments as for section 7.1 Indeed, isn't 7.3 just a subset of 7.1? Why is it separately defined? Same changes to interoperability considerations https://github.com/svgeesus/ietf-justfont/commit/49d768f1ee382b2279acc1803af149573d5c1317
If I recall correctly, this information was added during review on ietf-types list of the original applications/font-woff media type, in response to a comment that Macintosh File Type Codes (which we had in the original proposal, as part of "Additional Information") were being replaced by Macintosh Universal Type Identifier codes. The registration is here https://www.iana.org/assignments/media-types/application/font-woff I haven't seen any indication that this information is useful or necessary, and no of know way to check that the information is in fact correct, or used by macOS. I would be in favor of dropping it, unless it can be shown that is is needed and correct. I raised an issue https://github.com/svgeesus/ietf-justfont/issues/26
They are optional in an HTTP request. They may not be optional in a
url (if the file is a font collection and the font referred to is
not the first font in the collection.However, I removed the "Optional". https://github.com/svgeesus/ietf-justfont/commit/c5df61052d4e2058b8366ea38e22884304d6676d
Updated to use your suggested text: https://github.com/svgeesus/ietf-justfont/commit/c28057591b37c91a2c75e61d732324df7b24091b It is true for a particular revision of a font collection.Of course, this assumes that the collection has an implicit order, but I assume that you know that is true. 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. See the related issue: Fragment syntax for collections should be robust against inserting, as well as appending, new fonts to a collection https://github.com/svgeesus/ietf-justfont/issues/18 Done, see above.8. New Registrations New font formats should be registered using the online form [Media-Type-Registration]. RFC 6838 [RFC6838] should be consulted on registration procedures. In particular the font specification must be freely available and the ABNF must be followed. Also, an @font- face format should be supplied and, if used, a definition of the fragment identifier syntax for the new type. This is really the "registration procedures" for the "font" type. So I'd move this to section 5. Agreed, and that clause removed.I'm not sure what "the ABNF" is that must be followed, but that seems a redundant statement, as if there is a prescribed ABNF, then necessarily it must be followed. https://github.com/svgeesus/ietf-justfont/commit/16b59b33812ee490eb496439af0bb6df50cbd238
It should have, since the source is<reference anchor="postscript-wiki" target=""> <front> <title>PostScript</title> <author><organization/></author> <date/> <abstract><t>PostScript (PS) is a computer language for creating vector graphics. It is a dynamically typed, concatenative programming language and was created at Adobe Systems by John Warnock, Charles Geschke, Doug Brotz, Ed Taft and Bill Paxton from 1982 to 1984.</t></abstract> </front> </reference> Ah, I see what happened (both are links to the same wikipedia article, one to a specific section). I fixed this by referencing cff-wiki instead of postscript-wiki and deleting the latter. https://github.com/svgeesus/ietf-justfont/commit/eaa43e8c9bc26ffecaf8f75f26dbf8d5e5c27ee4 This section is autogenerated by xml2rfc. However, all three come from the "Specification development" section, which now contains a note to the RFC Editor to delete it. Thus, the final RFC should not have this URIs section.9.3. URIs If these are intended to be in the final RFC, they should be changed into proper references. If they aren't intended to be in the final RFC, this section should have a note to the RFC Editor to delete it. Many thanks for your thorough review! To make review easier, I posted an updated draft-04 just now which contains all the edits made above. -- Chris Lilley @svgeesus Technical Director, W3C Interaction Domain |