idnits 2.17.1 draft-ietf-justfont-toplevel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 462: '...ignature field in the WOFF header MUST...' RFC 2119 keyword, line 512: '...ignature field in the WOFF header MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 269 has weird spacing: '...tifiers none....' == Line 345 has weird spacing: '...tifiers none....' == Line 425 has weird spacing: '...tifiers none....' == Line 522 has weird spacing: '...tifiers none....' -- The document date (January 29, 2016) is 3009 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 541 looks like a reference -- Missing reference section? '2' on line 544 looks like a reference -- Missing reference section? '3' on line 546 looks like a reference -- Missing reference section? '4' on line 548 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Lilley 3 Internet-Draft W3C 4 Intended status: Standards Track January 29, 2016 5 Expires: August 1, 2016 7 The font Top Level Type 8 draft-ietf-justfont-toplevel-00 10 Abstract 12 This memo serves to register and document the "font" Top Level Type, 13 under which the Internet Media subtypes for representation formats 14 for fonts may be registered. This document also serves as a 15 registration application for a set of intended subtypes, which are 16 representative of some existing subtypes already registered under the 17 "application" tree by their separate registrations. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 1, 2016. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 The process of setting type in computer systems and other forms of 54 text presentation systems uses fonts in order to provide visual 55 representations of the glyphs. Just as with images, for example, 56 there are a number of ways to represent the visual information of the 57 glyphs. Early font formats often used bitmaps, as these could have 58 been carefully tuned for maximum readability at a given size on low- 59 resolution displays. More recently, scalable vector outline fonts 60 have come into widespread use: in these fonts, the outlines of the 61 glyphs are described, and the presentation system renders the outline 62 in the desired position and size. 64 This document defines a top-level Internet Media Type type "font" 65 under which different representation formats of fonts may be 66 registered (e.g. a bitmap or outline formats). It should be 67 emphasized that, just as under the "image" top-level type one does 68 not find registration for a specific image, for example, "The Night- 69 watch" (by Rembrandt) but instead "JPEG" (a compressed image data 70 representation format), so, under "font" one will not find "Courier" 71 (the name of a popular font) but perhaps "TTF", "OTF" or "SFNT" (the 72 names of commonly used TrueType and OpenType font formats as well as 73 their higher-level wrapper format). 75 2. Background and Justification 77 Historically there has not been a registration of formats for fonts. 78 Most recently, there have been several representation formats 79 registered as MIME subtypes under the "application" top-level type. 80 However, with the rapid adoption of web fonts (based on the data from 81 HTTP Archive [1] showing a huge increase in web font usage from 1% in 82 the end of 2010 to 50% across all sites in the beginning of 2015) 83 custom fonts on the web have become a core web resource. As the in- 84 depth analysis [2] shows, the lack of the intuitive top-level font 85 type is causing significant confusion among developers - while 86 currently defined font subtypes are severely under-utilized there are 87 many more sites that already use non-existent (but highly intuitive) 88 media types such as "font/woff", "font/ttf" and "font/truetype". At 89 the same time, the majority of sites resort to using generic types 90 such as "application/octet-stream", "text/plain" and "text/html"; or 91 use unregistrable types such as "application/x-font-ttf". 93 Contrary to our expectations, the officially defined IANA subtypes 94 such as "application/font-woff" and "application/font-sfnt" see a 95 very limited use - their adoption rates trail far behind as the 96 actual use of web fonts continues to increase. The members of the 97 W3C WebFonts WG believe the use of "application" top-level type is 98 not ideal. First, the "application" sub-tree is treated (correctly) 99 with great caution with respect to viruses and other active code. 100 Secondly, the lack of a top-level type means that there is no 101 opportunity to have a common set of optional attributes, such as are 102 specified here. Third, fonts have a unique set of licensing and 103 usage restrictions, which makes it worthwhile to identify this 104 general category with a unique top-level type. 106 The W3C WebFonts WG believes that the situation can be significantly 107 improved if a set of font media types is registered using "font" as a 108 dedicated top-level type. Based on the data analysis presented 109 above, we believe that it is the presence of simple and highly 110 intuitive media types for images that caused the widespread adoption 111 of IANA's recommendations, where the correct usage of existing media 112 types reaches over 97% for all subtypes in the "image" tree. The WG 113 believes that, considering a rapid adoption of fonts on the web, the 114 registration of the top-level media type for fonts along with the 115 intuitive set of subtypes that reflect popular and widely used data 116 formats would further stimulate the adoption of web fonts, 117 significantly simplify web server configuration process and 118 facilitate the proper use of IANA media type recommendations. 120 3. Security considerations 122 Fonts are interpreted data structures that represent collections of 123 different tables containing data that represent different types of 124 information, including glyph outlines in various formats, hinting 125 instructions, metrics and layout information for multiple languages 126 and writing systems, rules for glyph substitution and positioning, 127 etc. Depending on the format used to represent the glyph data the 128 font may contain TrueType, PostScript or SVG outlines and their 129 respective hint instructions, where applicable. There are many 130 existing, already standardized font table tags and formats that allow 131 an unspecified number of entries containing predefined data fields 132 for storage of variable length binary data. Many existing (TrueType, 133 OpenType and OFF, SIL Graphite, WOFF, etc.) font formats are based on 134 the table-based SFNT (scalable font) format which is extremely 135 flexible, highly extensible and offers an opportunity to introduce 136 additional table structures when needed, in a way that would not 137 affect existing font rendering engines and text layout 138 implementations. However, this very extensibility may present 139 specific security concerns - the flexibility and ease of adding new 140 data structures makes it easy for any arbitrary data to be hidden 141 inside a font file. There is a significant risk that the flexibility 142 of font data structures may be exploited to hide malicious binary 143 content disguised as a font data component. 145 Fonts may contain 'hints', which are programmatic instructions that 146 are executed by the font engine for the alignment of graphical 147 elements of glyph outlines with the target display pixel grid. 148 Depending on the font technology utilized in the creation of a font 149 these hints may represent active code interpreted and executed by the 150 font rasterizer. Even though hints operate within the confines of 151 the glyph outline conversion system and have no access outside the 152 font rendering engine, hint instructions can be, however, quite 153 complex, and a maliciously designed complex font could cause undue 154 resource consumption (e.g. memory or CPU cycles) on a machine 155 interpreting it. Indeed, fonts are sufficiently complex, and most 156 (if not all) interpreters cannot be completely protected from 157 malicious fonts without undue performance penalties. 159 Widespread use of fonts as necessary component of visual content 160 presentation warrants that a careful attention should be given to 161 security considerations whenever a font is either embedded into an 162 electronic document or transmitted alongside media content as a 163 linked resource. While many existing font formats provide certain 164 levels of protection of data integrity (such mechanisms include e.g. 165 checksums and digital signatures), font data formats provide neither 166 privacy nor confidentiality protection internally; if needed, such 167 protection should be provided externally. 169 4. Definition and encoding 171 The "font" as the primary media content type indicates that the 172 content identified by it requires certain graphic subsystem such as 173 font rendering engine (and, in some cases, text layout and shaping 174 engine) to process font data, which in turn may require certain level 175 of hardware capabilities such as certain levels of CPU performance 176 and available memory. The "font" media type does not provide any 177 specific information about the underlying data format and how the 178 font information should be interpreted - the subtypes defined within 179 a "font" tree will name the specific font formats. Unrecognized sub- 180 types of "font" should be treated as "application/octet-stream". 181 Implementations may pass unrecognized subtypes to a common font- 182 handling system, if such system is available. 184 5. Defined subtypes 186 In this section the initial entries under the top-level 'font' MIME 187 type are documented. They also serve as examples for future 188 registrations. 190 5.1. Generic SFNT font type 192 Type name: font 194 Subtype name: sfnt 196 Required parameters: None. 198 Optional parameters: 200 1) Name: Outlines Value: TTF, CFF, SVG 202 This parameter can be used to specify the type of outlines 203 supported by the font. Value "TTF" shall be used when a font 204 resource contains glyph outlines in TrueType format, value 205 "CFF" shall be used to identify fonts containing PostScript/CFF 206 outlines, and value SVG shall be used to identify fonts that 207 include SVG outlines. TTF, CFF or SVG outlines can be present 208 in various combinations in the same font file, therefore, 209 multiple values for the same optional parameter may be defined. 211 2) Name: Layout 213 Value: OTF, AAT, SIL 215 This parameter identifies the type of implemented support for 216 advanced text layout features. The predefined values "OTF", 217 "AAT" and " SIL" respectively indicate support for OpenType 218 text layout, Apple Advanced Typography or Graphite SIL. More 219 than one shaping and layout mechanism may be supported by the 220 same font file, therefore, multiple values for the same 221 optional parameter may be defined. 223 Encoding considerations: Binary. 225 Interoperability considerations: As it was noted in the first 226 paragraph of the "Security considerations" section, the same font 227 format wrapper can be used to encode fonts with different types of 228 glyph data represented as either TrueType or PostScript (CFF) 229 outlines. Existing font rendering engines may not be able to 230 process some of the particular outline formats, and downloading a 231 font resource that contains unsupported glyph data format would 232 result in inability of application to render and display text. 233 Therefore, it would be extremely useful to clearly identify the 234 format of the glyph outline data within a font using an optional 235 parameter, and allow applications to make decisions about 236 downloading a particular font resource sooner. Similar, another 237 optional parameter is suggested to identify the type of text 238 shaping and layout mechanism that is supported by a font. Please 239 note that as new outline formats and text shaping mechanisms may 240 be defined in the future, the set of allowed values for two 241 optional parameters defined by this section may be extended. 243 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 244 specification being developed by ISO/IEC SC29/WG11. 246 Applications that use this media type: Any and all applications that 247 are able to create, edit or display textual media content. 249 Additional information: 251 Magic number(s): The TrueType fonts and OFF / OpenType fonts 252 containing TrueType outlines should use 0x00010000 as the 253 'sfnt' version number. 255 The OFF / OpenType fonts containing CFF data should use the tag 256 'OTTO' as 'sfnt' version number. 258 File extension(s): Font file extensions used for OFF / OpenType 259 fonts: .ttf, .otf 261 Typically, .ttf extension is only used for fonts containing 262 TrueType outlines, while .otf extension can be used for any 263 OpenType/OFF font, either with TrueType or CFF outlines. 265 Macintosh file type code(s): (no code specified) 267 @font-face Format: none. 269 Fragment Identifiers none. 271 Person & email address to contact for further information: Vladimir 272 Levantovsky (vladimir.levantovsky@monotype.com). 274 Intended usage: COMMON 276 Restrictions on usage: None 278 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 279 product of the ISO/IEC JTC1 SC29/WG11. 281 Change controller: The ISO/IEC has change control over this 282 specification. 284 5.2. TTF font type 286 Type name: font 288 Subtype name: ttf 290 Required parameters: None. 292 Optional parameters: 294 Name: Layout Value: OTF, AAT, SIL 296 This parameter identifies the type of support mechanism for 297 advanced text layout features. The predefined values "OTF", 298 "AAT" and " SIL" respectively indicate support for OpenType 299 text layout, Apple Advanced Typography or Graphite SIL. More 300 than one shaping and layout mechanism may be supported by the 301 same font file, therefore, multiple values for the same 302 optional parameter may be defined. 304 Encoding considerations: Binary. 306 Interoperability considerations: As was noted in the first paragraph 307 of the "Security considerations" section, the same font format can 308 be used to encode fonts supporting different types of outlines 309 and/or text shaping and layout mechanisms. Existing font 310 rendering engine implementations may not be able to process some 311 of the particular layout table formats, and downloading a font 312 resource that contains unsupported text shaping mechanism would 313 result in inability of applications to display text properly. 314 Therefore, it would be extremely useful to clearly identify the 315 supported text shaping and layout data within a font using an 316 optional parameter, and allow applications to make decisions about 317 downloading a particular font resource sooner. Please note that 318 as new text shaping mechanisms may be defined in the future, the 319 set of allowed values for the optional parameter defined by this 320 section may be extended. 322 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 323 specification being developed by ISO/IEC SC29/WG11. 325 Applications that use this media type: Any and all applications that 326 are able to create, edit or display textual media content. 328 Additional information: 330 Magic number(s): The TrueType fonts and OFF / OpenType fonts 331 containing TrueType outlines should use 0x00010000 as the 332 'sfnt' version number. 334 File extension(s): Font file extensions used for TrueType / OFF / 335 OpenType fonts: .ttf, .otf 337 Typically, .ttf extension is only used for fonts containing 338 TrueType outlines, while .otf extension may be used for any 339 OpenType/OFF font, either with TrueType or CFF outlines. 341 Macintosh file type code(s): (no code specified) 343 @font-face Format: truetype 345 Fragment Identifiers none. 347 Person & email address to contact for further information: Vladimir 348 Levantovsky (vladimir.levantovsky@monotype.com). 350 Intended usage: COMMON 352 Restrictions on usage: None 354 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 355 product of the ISO/IEC JTC1 SC29/WG11. 357 Change controller: The ISO/IEC has change control over this 358 specification. 360 5.3. OTF font type 362 Type name: font 364 Subtype name: otf 366 Required parameters: None. 368 Optional parameters 370 Name: Outlines Value: TTF, CFF, SVG 372 This parameter can be used to specify the type of outlines 373 supported by the font. Value "TTF" shall be used when a font 374 resource contains glyph outlines in TrueType format, value 375 "CFF" shall be used to identify fonts containing PostScript/CFF 376 outlines, and value SVG shall be used to identify fonts that 377 include SVG outlines. TTF, CFF or SVG outlines can be present 378 in various combinations in the same font file, therefore, 379 multiple values for the same optional parameter may be defined. 381 Encoding considerations: Binary. 383 Interoperability considerations: As it was noted in the first 384 paragraph of the "Security considerations" section, the same font 385 format can be used to encode fonts with different types of glyph 386 data represented as either TrueType, PostScript (CFF) or SVG 387 outlines. Existing font rendering engines may not be able to 388 process some of the particular outline formats, and downloading a 389 font resource that contains unsupported glyph data format would 390 result in inability of application to render and display text. 391 Therefore, it would be extremely useful to clearly identify the 392 format of the glyph outline data within a font using an optional 393 parameter, and allow applications to make decisions about 394 downloading a particular font resource sooner. Please note that 395 as new outline formats may be defined in the future, the set of 396 allowed values for the optional parameter defined in this section 397 may be extended. 399 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 400 specification being developed by ISO/IEC SC29/WG11. 402 Applications that use this media type: Any and all applications that 403 are able to create, edit or display textual media content. 405 Additional information: 407 Magic number(s): The TrueType fonts and OFF / OpenType fonts 408 containing TrueType outlines should use 0x00010000 as the 409 'sfnt' version number. 411 The OFF / OpenType fonts containing CFF data should use the tag 412 'OTTO' as 'sfnt' version number. 414 File extension(s): Font file extensions used for OFF / OpenType 415 fonts: .ttf, .otf 417 Typically, .ttf extension is only used for fonts containing 418 TrueType outlines, while .otf extension can be used for any 419 OpenType/OFF font, either with TrueType, CFF or SVG outlines. 421 Macintosh file type code(s): (no code specified) 423 @font-face Format: opentype 425 Fragment Identifiers none. 427 Person & email address to contact for further information: Vladimir 428 Levantovsky (vladimir.levantovsky@monotype.com). 430 Intended usage: COMMON 432 Restrictions on usage: None 434 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 435 product of the ISO/IEC JTC1 SC29/WG11. 437 Change controller: The ISO/IEC has change control over this 438 specification. 440 5.4. WOFF 1.0 442 Type name: font 444 Subtype name: woff 446 Required parameters: None. 448 Optional parameters: None. 450 Encoding considerations: Binary. 452 Interoperability considerations: None. 454 Published specification: This media type registration updates the 455 WOFF specification [3] at W3C. 457 Applications that use this media type: WOFF is used by Web browsers, 458 often in conjunction with HTML and CSS. 460 Additional information: 462 Magic number(s): The signature field in the WOFF header MUST 463 contain the "magic number" 0x774F4646 465 File extension(s): woff 467 Macintosh file type code(s): (no code specified) 469 Macintosh Universal Type Identifier code: "org.w3c.woff" 471 @font-face Format: woff 473 Fragment Identifiers: none. 475 Person & email address to contact for further information: Chris 476 Lilley (www-font@w3.org). 478 Intended usage: COMMON 480 Restrictions on usage: None 482 Author: The WOFF specification is a work product of the World Wide 483 Web Consortium's WebFonts Working Group. 485 Change controller: The W3C has change control over this 486 specification. 488 5.5. WOFF 2.0 490 Type name: font 492 Subtype name: woff2 494 Required parameters: None. 496 Optional parameters: None. 498 Encoding considerations: Binary. 500 Interoperability considerations: WOFF 2.0 is an improvement on WOFF 501 1.0. The two formats have different Internet Media Types, 502 different @font-face formats, and may be used in parallel. 504 Published specification: This media type registration is extracted 505 from the WOFF 2.0 specification [4] at W3C. 507 Applications that use this media type: WOFF 2.0 is used by Web 508 browsers, often in conjunction with HTML and CSS. 510 Additional information: 512 Magic number(s): The signature field in the WOFF header MUST 513 contain the "magic number" 0x774F4632 ('wOF2') 515 File extension(s): woff2 517 Macintosh file type code(s): (no code specified) 519 Macintosh Universal Type Identifier code: "org.w3c.woff2" 521 @font-face Format: woff2 522 Fragment Identifiers none. 524 Person & email address to contact for further information: Chris 525 Lilley (www-font@w3.org). 527 Intended usage: COMMON 529 Restrictions on usage: None 531 Author: The WOFF2 specification is a work product of the World Wide 532 Web Consortium's WebFonts Working Group. 534 Change controller: The W3C has change control over this 535 specification. 537 6. References 539 6.1. URIs 541 [1] http://httparchive.org/ 542 trends.php?s=All&minlabel=Nov+15+2010&maxlabel=Feb+15+2015 544 [2] http://goo.gl/zbDhUN 546 [3] http://www.w3.org/TR/WOFF 548 [4] http://www.w3.org/TR/WOFF2 550 Author's Address 552 Chris Lilley 553 W3C 554 2004 Route des Lucioles 555 Sophia Antipolis 06902 556 France 558 Email: chris@w3.org