idnits 2.17.1 draft-ietf-justfont-toplevel-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 294 has weird spacing: '...tifiers none....' == Line 372 has weird spacing: '...tifiers none....' == Line 457 has weird spacing: '...tifiers none....' -- The document date (February 24, 2016) is 2981 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) -- Looks like a reference, but probably isn't: '1' on line 706 -- Looks like a reference, but probably isn't: '2' on line 708 -- Looks like a reference, but probably isn't: '3' on line 710 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 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 February 24, 2016 5 Expires: August 27, 2016 7 The font Top Level Type 8 draft-ietf-justfont-toplevel-01 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 in use, and 17 currently registered under the "application" tree by their separate 18 registrations. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 27, 2016. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Specification development 54 This section is non-normative. The source for this specification is 55 maintained on GitHub [1]. The issues list [2] is also on GitHub. 56 Discussion should be on the mailing list justfont@ietf.org [3]. 58 2. Introduction 60 The process of setting type in computer systems and other forms of 61 text presentation systems uses fonts in order to provide visual 62 representations of the glyphs. Just as with images, for example, 63 there are a number of ways to represent the visual information of the 64 glyphs. Early font formats often used bitmaps, as these could have 65 been carefully tuned for maximum readability at a given size on low- 66 resolution displays. More recently, scalable vector outline fonts 67 have come into widespread use: in these fonts, the outlines of the 68 glyphs are described, and the presentation system renders the outline 69 in the desired position and size. 71 This document defines a top-level Internet Media Type type "font" 72 under which different representation formats of fonts may be 73 registered (e.g. a bitmap or outline formats). It should be 74 emphasized that, just as under the "image" top-level type one does 75 not find registration for a specific image, for example, "The Night- 76 watch" (by Rembrandt) but instead "JPEG" (a compressed image data 77 representation format), so, under "font" one will not find "Courier" 78 (the name of a popular font) but perhaps "TTF", "OTF" or "SFNT" (the 79 names of commonly used TrueType and OpenType font formats as well as 80 their higher-level wrapper format). 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 3. Background and Justification 88 Historically there has not been a registration of formats for fonts. 89 Most recently, there have been several representation formats 90 registered as MIME subtypes under the "application" top-level type. 91 However, with the rapid adoption of web fonts (based on the data from 92 HTTP Archive [HTTP-Archive-Trends] showing a huge increase in web 93 font usage from 1% in the end of 2010 to 50% across all sites in the 94 beginning of 2015) custom fonts on the web have become a core web 95 resource. As the in-depth analysis [Font-Media-Type-Analysis] shows, 96 the lack of the intuitive top-level font type is causing significant 97 confusion among developers - while currently defined font subtypes 98 are severely under-utilized there are many more sites that already 99 use non-existent (but highly intuitive) media types such as "font/ 100 woff", "font/ttf" and "font/truetype". At the same time, the 101 majority of sites resort to using generic types such as "application/ 102 octet-stream", "text/plain" and "text/html"; or use unregistrable 103 types such as "application/x-font-ttf". 105 Contrary to our expectations, the officially defined IANA subtypes 106 such as "application/font-woff" and "application/font-sfnt" see a 107 very limited use - their adoption rates trail far behind as the 108 actual use of web fonts continues to increase. The members of the 109 W3C WebFonts WG believe the use of "application" top-level type is 110 not ideal. First, the "application" sub-tree is treated (correctly) 111 with great caution with respect to viruses and other active code. 112 Secondly, the lack of a top-level type means that there is no 113 opportunity to have a common set of optional attributes, such as are 114 specified here. Third, fonts have a unique set of licensing and 115 usage restrictions, which makes it worthwhile to identify this 116 general category with a unique top-level type. 118 The W3C WebFonts WG believes that the situation can be significantly 119 improved if a set of font media types is registered using "font" as a 120 dedicated top-level type. Based on the data analysis presented 121 above, we believe that it is the presence of simple and highly 122 intuitive media types for images that caused the widespread adoption 123 of IANA's recommendations, where the correct usage of existing media 124 types reaches over 97% for all subtypes in the "image" tree. The WG 125 believes that, considering a rapid adoption of fonts on the web, the 126 registration of the top-level media type for fonts along with the 127 intuitive set of subtypes that reflect popular and widely used data 128 formats would further stimulate the adoption of web fonts, 129 significantly simplify web server configuration process and 130 facilitate the proper use of IANA media type recommendations. 132 4. Security considerations 134 Fonts are interpreted data structures that represent collections of 135 different tables containing data that represent different types of 136 information, including glyph outlines in various formats, hinting 137 instructions, metrics and layout information for multiple languages 138 and writing systems, rules for glyph substitution and positioning, 139 etc. Depending on the format used to represent the glyph data the 140 font may contain TrueType, PostScript or SVG outlines and their 141 respective hint instructions, where applicable. There are many 142 existing, already standardized font table tags and formats that allow 143 an unspecified number of entries containing predefined data fields 144 for storage of variable length binary data. Many existing (TrueType, 145 OpenType and OFF, SIL Graphite, WOFF, etc.) font formats are based on 146 the table-based SFNT (scalable font) format which is extremely 147 flexible, highly extensible and offers an opportunity to introduce 148 additional table structures when needed, in a way that would not 149 affect existing font rendering engines and text layout 150 implementations. However, this very extensibility may present 151 specific security concerns - the flexibility and ease of adding new 152 data structures makes it easy for any arbitrary data to be hidden 153 inside a font file. There is a significant risk that the flexibility 154 of font data structures may be exploited to hide malicious binary 155 content disguised as a font data component. 157 Fonts may contain 'hints', which are programmatic instructions that 158 are executed by the font engine for the alignment of graphical 159 elements of glyph outlines with the target display pixel grid. 160 Depending on the font technology utilized in the creation of a font 161 these hints may represent active code interpreted and executed by the 162 font rasterizer. Even though hints operate within the confines of 163 the glyph outline conversion system and have no access outside the 164 font rendering engine, hint instructions can be, however, quite 165 complex, and a maliciously designed complex font could cause undue 166 resource consumption (e.g. memory or CPU cycles) on a machine 167 interpreting it. Indeed, fonts are sufficiently complex, and most 168 (if not all) interpreters cannot be completely protected from 169 malicious fonts without undue performance penalties. 171 Widespread use of fonts as necessary component of visual content 172 presentation warrants that a careful attention should be given to 173 security considerations whenever a font is either embedded into an 174 electronic document or transmitted alongside media content as a 175 linked resource. While many existing font formats provide certain 176 levels of protection of data integrity (such mechanisms include e.g. 177 checksums and digital signatures), font data formats provide neither 178 privacy nor confidentiality protection internally; if needed, such 179 protection should be provided externally. 181 5. IANA Considerations 183 This specification requires IANA to modify the rules for the existing 184 Internet Media Types registry by adding a new font top-level type in 185 the standards tree, and registering several subtypes. 187 6. Definition and encoding 189 The "font" as the primary media content type indicates that the 190 content identified by it requires certain graphic subsystem such as 191 font rendering engine (and, in some cases, text layout and shaping 192 engine) to process font data, which in turn may require certain level 193 of hardware capabilities such as certain levels of CPU performance 194 and available memory. The "font" media type does not provide any 195 specific information about the underlying data format and how the 196 font information should be interpreted - the subtypes defined within 197 a "font" tree will name the specific font formats. Unrecognized sub- 198 types of "font" should be treated as "application/octet-stream". 199 Implementations may pass unrecognized subtypes to a common font- 200 handling system, if such system is available. 202 7. Defined subtypes 204 In this section the initial entries under the top-level 'font' MIME 205 type are documented. They also serve as examples for future 206 registrations. 208 For each subtype, an @font-face format identifer is defined. This 209 for use with the @font-face src descriptor, defined by the CSS3 Fonts 210 specification [W3C.CR-css-fonts-3-20131003]. 212 7.1. Generic SFNT font type 214 Type name: font 216 Subtype name: sfnt 218 Required parameters: None. 220 Optional parameters: 222 1) Name: Outlines Value: TTF, CFF, SVG 224 This parameter can be used to specify the type of outlines 225 supported by the font. Value "TTF" shall be used when a font 226 resource contains glyph outlines in TrueType format, value 227 "CFF" shall be used to identify fonts containing PostScript/CFF 228 outlines, and value SVG shall be used to identify fonts that 229 include SVG outlines. TTF, CFF or SVG outlines can be present 230 in various combinations in the same font file, therefore, this 231 optional parameter is a list containing one or more items, 232 separated by commas, with optional whitespace. Order in the 233 list is not significant. 235 2) Name: Layout 237 Value: OTL, AAT, SIL 239 This parameter identifies the type of implemented support for 240 advanced text layout features. The predefined values "OTL", 241 "AAT" and "SIL" respectively indicate support for OpenType text 242 layout, Apple Advanced Typography or Graphite SIL. More than 243 one shaping and layout mechanism may be supported by the same 244 font file, therefore, this optional parameter is a list 245 containing one or more items, separated by commas, with 246 optional whitespace. Order in the list is not significant. 248 Encoding considerations: Binary. 250 Interoperability considerations: As it was noted in the first 251 paragraph of the "Security considerations" section, the same font 252 format wrapper can be used to encode fonts with different types of 253 glyph data represented as either TrueType or PostScript (CFF) 254 outlines. Existing font rendering engines may not be able to 255 process some of the particular outline formats, and downloading a 256 font resource that contains unsupported glyph data format would 257 result in inability of application to render and display text. 258 Therefore, it would be extremely useful to clearly identify the 259 format of the glyph outline data within a font using an optional 260 parameter, and allow applications to make decisions about 261 downloading a particular font resource sooner. Similar, another 262 optional parameter is suggested to identify the type of text 263 shaping and layout mechanism that is supported by a font. Please 264 note that as new outline formats and text shaping mechanisms may 265 be defined in the future, the set of allowed values for two 266 optional parameters defined by this section may be extended. 268 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 269 specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ 270 WG11. 272 Applications that use this media type: Any and all applications that 273 are able to create, edit or display textual media content. 275 Additional information: 277 Magic number(s): The TrueType fonts and OFF / OpenType fonts 278 containing TrueType outlines should use 0x00010000 as the 279 'sfnt' version number. 281 The OFF / OpenType fonts containing CFF data should use the tag 282 'OTTO' as 'sfnt' version number. 284 File extension(s): Font file extensions used for OFF / OpenType 285 fonts: .ttf, .otf 286 Typically, .ttf extension is only used for fonts containing 287 TrueType outlines, while .otf extension can be used for any 288 OpenType/OFF font, either with TrueType or CFF outlines. 290 Macintosh file type code(s): (no code specified) 292 @font-face Format: none. 294 Fragment Identifiers none. 296 Person & email address to contact for further information: Vladimir 297 Levantovsky (vladimir.levantovsky@monotype.com). 299 Intended usage: COMMON 301 Restrictions on usage: None 303 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 304 product of the ISO/IEC JTC1 SC29/WG11. 306 Change controller: The ISO/IEC has change control over this 307 specification. 309 7.2. TTF font type 311 Type name: font 313 Subtype name: ttf 315 Required parameters: None. 317 Optional parameters: 319 Name: Layout Value: OTL, AAT, SIL 321 This parameter identifies the type of support mechanism for 322 advanced text layout features. The predefined values "OTL", 323 "AAT" and "SIL" respectively indicate support for OpenType text 324 layout, Apple Advanced Typography or Graphite SIL. More than 325 one shaping and layout mechanism may be supported by the same 326 font file, therefore, this optional parameter is a list 327 containing one or more items, separated by commas, with 328 optional whitespace. Order in the list is not significant. 330 Encoding considerations: Binary. 332 Interoperability considerations: As was noted in the first paragraph 333 of the "Security considerations" section, the same font format can 334 be used to encode fonts supporting different types of outlines 335 and/or text shaping and layout mechanisms. Existing font 336 rendering engine implementations may not be able to process some 337 of the particular layout table formats, and downloading a font 338 resource that contains unsupported text shaping mechanism would 339 result in inability of applications to display text properly. 340 Therefore, it would be extremely useful to clearly identify the 341 supported text shaping and layout data within a font using an 342 optional parameter, and allow applications to make decisions about 343 downloading a particular font resource sooner. Please note that 344 as new text shaping mechanisms may be defined in the future, the 345 set of allowed values for the optional parameter defined by this 346 section may be extended. 348 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 349 specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ 350 WG11. 352 Applications that use this media type: Any and all applications that 353 are able to create, edit or display textual media content. 355 Additional information: 357 Magic number(s): The TrueType fonts and OFF / OpenType fonts 358 containing TrueType outlines should use 0x00010000 as the 359 'sfnt' version number. 361 File extension(s): Font file extensions used for TrueType / OFF / 362 OpenType fonts: .ttf, .otf 364 Typically, .ttf extension is only used for fonts containing 365 TrueType outlines, while .otf extension may be used for any 366 OpenType/OFF font, either with TrueType or CFF outlines. 368 Macintosh file type code(s): (no code specified) 370 @font-face Format: truetype 372 Fragment Identifiers none. 374 Person & email address to contact for further information: Vladimir 375 Levantovsky (vladimir.levantovsky@monotype.com). 377 Intended usage: COMMON 379 Restrictions on usage: None 380 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 381 product of the ISO/IEC JTC1 SC29/WG11. 383 Change controller: The ISO/IEC has change control over this 384 specification. 386 7.3. OTF font type 388 Type name: font 390 Subtype name: otf 392 Required parameters: None. 394 Optional parameters 396 Name: Outlines Value: TTF, CFF, SVG 398 This parameter can be used to specify the type of outlines 399 supported by the font. Value "TTF" shall be used when a font 400 resource contains glyph outlines in TrueType format, value 401 "CFF" shall be used to identify fonts containing PostScript/CFF 402 outlines, and value SVG shall be used to identify fonts that 403 include SVG outlines. TTF, CFF or SVG outlines can be present 404 in various combinations in the same font file, therefore, this 405 optional parameter is a list containing one or more items, 406 separated by commas, with optional whitespace. Order in the 407 list is not significant. 409 Encoding considerations: Binary. 411 Interoperability considerations: As it was noted in the first 412 paragraph of the "Security considerations" section, the same font 413 format can be used to encode fonts with different types of glyph 414 data represented as either TrueType, PostScript (CFF) or SVG 415 outlines. Existing font rendering engines may not be able to 416 process some of the particular outline formats, and downloading a 417 font resource that contains unsupported glyph data format would 418 result in inability of application to render and display text. 419 Therefore, it would be extremely useful to clearly identify the 420 format of the glyph outline data within a font using an optional 421 parameter, and allow applications to make decisions about 422 downloading a particular font resource sooner. Please note that 423 as new outline formats may be defined in the future, the set of 424 allowed values for the optional parameter defined in this section 425 may be extended. 427 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 428 specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ 429 WG11. 431 Applications that use this media type: Any and all applications that 432 are able to create, edit or display textual media content. 434 Additional information: 436 Magic number(s): The TrueType fonts and OFF / OpenType fonts 437 containing TrueType outlines should use 0x00010000 as the 438 'sfnt' version number. 440 The OFF / OpenType fonts containing CFF outlines should use the 441 tag 'OTTO' as 'sfnt' version number. There is no magic number 442 for SVG outlines; these are always accompanied by either 443 TrueType or CFF outlines and thus use the corresponding magic 444 number. 446 File extension(s): Font file extensions used for OFF / OpenType 447 fonts: .ttf, .otf 449 Typically, .ttf extension is only used for fonts containing 450 TrueType outlines, while .otf extension can be used for any 451 OpenType/OFF font, either with TrueType, CFF or SVG outlines. 453 Macintosh file type code(s): (no code specified) 455 @font-face Format: opentype 457 Fragment Identifiers none. 459 Person & email address to contact for further information: Vladimir 460 Levantovsky (vladimir.levantovsky@monotype.com). 462 Intended usage: COMMON 464 Restrictions on usage: None 466 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 467 product of the ISO/IEC JTC1 SC29/WG11. 469 Change controller: The ISO/IEC has change control over this 470 specification. 472 7.4. Collection font type 474 Type name: font 476 Subtype name: collection 478 Required parameters: None. 480 Optional parameters 482 Name: Outlines Value: TTF, CFF, SVG 484 This parameter can be used to specify the type of outlines 485 supported by the font. Value "TTF" shall be used when a font 486 resource contains glyph outlines in TrueType format, value 487 "CFF" shall be used to identify fonts containing PostScript/CFF 488 outlines, and value SVG shall be used to identify fonts that 489 include SVG outlines. TTF, CFF or SVG outlines can be present 490 in various combinations in the same font file, therefore, this 491 optional parameter is a list containing one or more items, 492 separated by commas, with optional whitespace. Order in the 493 list is not significant. 495 Encoding considerations: Binary. 497 Interoperability considerations: As it was noted in the first 498 paragraph of the "Security considerations" section, the same font 499 format can be used to encode fonts with different types of glyph 500 data represented as either TrueType, PostScript (CFF) or SVG 501 outlines. Existing font rendering engines may not be able to 502 process some of the particular outline formats, and downloading a 503 font resource that contains unsupported glyph data format would 504 result in inability of application to render and display text. 505 Therefore, it would be extremely useful to clearly identify the 506 format of the glyph outline data within a font using an optional 507 parameter, and allow applications to make decisions about 508 downloading a particular font resource sooner. Please note that 509 as new outline formats may be defined in the future, the set of 510 allowed values for the optional parameter defined in this section 511 may be extended. 513 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 514 specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ 515 WG11. 517 Applications that use this media type: Any and all applications that 518 are able to create, edit or display textual media content. 520 Additional information: 522 Magic number(s): The TrueType fonts and OFF / OpenType fonts 523 containing TrueType outlines should use 0x00010000 as the 524 'sfnt' version number. 526 The OFF / OpenType fonts containing CFF outlines should use the 527 tag 'OTTO' as 'sfnt' version number. There is no magic number 528 for SVG outlines; these are always accompanied by either 529 TrueType or CFF outlines and thus use the corresponding magic 530 number. 532 File extension(s): Font file extensions used for OFF / TrueType 533 and OpenType fonts: .ttc 535 Macintosh file type code(s): (no code specified) 537 @font-face Format: collection 539 Fragment Identifiers A positive integer. For example, #2 refers 540 to the second font in the collection. If a fragment is not 541 specified, it is the same as #1 i.e. the first font in the 542 collection. 544 Person & email address to contact for further information: Vladimir 545 Levantovsky (vladimir.levantovsky@monotype.com). 547 Intended usage: COMMON 549 Restrictions on usage: None 551 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 552 product of the ISO/IEC JTC1 SC29/WG11. 554 Change controller: The ISO/IEC has change control over this 555 specification. 557 7.5. WOFF 1.0 559 Type name: font 561 Subtype name: woff 563 Required parameters: None. 565 Optional parameters: None. 567 Encoding considerations: Binary. 569 Interoperability considerations: None. 571 Published specification: This media type registration updates the 572 WOFF specification [W3C.REC-WOFF-20121213] at W3C. 574 Applications that use this media type: WOFF is used by Web browsers, 575 often in conjunction with HTML and CSS. 577 Additional information: 579 Magic number(s): The signature field in the WOFF header MUST 580 contain the "magic number" 0x774F4646 582 File extension(s): woff 584 Macintosh file type code(s): (no code specified) 586 Macintosh Universal Type Identifier code: "org.w3c.woff" 588 @font-face Format: woff 590 Fragment Identifiers: none. 592 Person & email address to contact for further information: Chris 593 Lilley (www-font@w3.org). 595 Intended usage: COMMON 597 Restrictions on usage: None 599 Author: The WOFF specification is a work product of the World Wide 600 Web Consortium's WebFonts Working Group. 602 Change controller: The W3C has change control over this 603 specification. 605 7.6. WOFF 2.0 607 Type name: font 609 Subtype name: woff2 611 Required parameters: None. 613 Optional parameters: None. 615 Encoding considerations: Binary. 617 Interoperability considerations: WOFF 2.0 is an improvement on WOFF 618 1.0. The two formats have different Internet Media Types, 619 different @font-face formats, and may be used in parallel. 621 Published specification: This media type registration is extracted 622 from the WOFF 2.0 specification [W3C.WD-WOFF2-20150414] at W3C. 624 Applications that use this media type: WOFF 2.0 is used by Web 625 browsers, often in conjunction with HTML and CSS. 627 Additional information: 629 Magic number(s): The signature field in the WOFF header MUST 630 contain the "magic number" 0x774F4632 ('wOF2') 632 File extension(s): woff2 634 Macintosh file type code(s): (no code specified) 636 Macintosh Universal Type Identifier code: "org.w3c.woff2" 638 @font-face Format: woff2 640 Fragment Identifiers Optional, for collections encoded as WOFF 641 2.0. A positive integer. For example, #2 refers to the second 642 font in the collection. If a fragment is not specified, it is 643 the same as #1 i.e. the first font in the collection (or the 644 only font, if it is not a collection). If a fragment is 645 specified, and the WOFF does not encode a collection, the 646 fragment is ignored. 648 Person & email address to contact for further information: Chris 649 Lilley (www-font@w3.org). 651 Intended usage: COMMON 653 Restrictions on usage: None 655 Author: The WOFF2 specification is a work product of the World Wide 656 Web Consortium's WebFonts Working Group. 658 Change controller: The W3C has change control over this 659 specification. 661 8. References 663 8.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, 667 DOI 10.17487/RFC2119, March 1997, 668 . 670 [W3C.CR-css-fonts-3-20131003] 671 Daggett, J., "CSS Fonts Module Level 3", World Wide Web 672 Consortium CR CR-css-fonts-3-20131003, October 2013, 673 . 675 [ISO.14496-22.2015] 676 International Organization for Standardization, "Coding of 677 audio-visual objects Part 22: Open Font Format", 678 ISO Standard 14496-22, 10 2015, 679 . 682 [W3C.REC-WOFF-20121213] 683 Kew, J., Leming, T., and E. Blokland, "WOFF File Format 684 1.0", World Wide Web Consortium Recommendation REC-WOFF- 685 20121213, December 2012, 686 . 688 [W3C.WD-WOFF2-20150414] 689 Levantovsky, V. and R. Levien, "WOFF File Format 2.0", 690 World Wide Web Consortium WD WD-WOFF2-20150414, April 691 2015, . 693 8.2. Informative References 695 [HTTP-Archive-Trends] 696 Kuetell, D., "HTTP Archive trend analysis", March 2015, 697 . 700 [Font-Media-Type-Analysis] 701 Kuetell, D., "Web Font Media Type (mime type) Analysis 702 2015", 2015, . 704 8.3. URIs 706 [1] https://github.com/svgeesus/ietf-justfont 708 [2] https://github.com/svgeesus/ietf-justfont/issues 710 [3] mailto:justfont@ietf.org 712 Author's Address 714 Chris Lilley 715 W3C 716 2004 Route des Lucioles 717 Sophia Antipolis 06902 718 France 720 Email: chris@w3.org