idnits 2.17.1 draft-ietf-justfont-toplevel-03.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 458 has weird spacing: '...tifiers none....' -- The document date (October 25, 2016) is 2738 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 744 -- Looks like a reference, but probably isn't: '2' on line 746 -- Looks like a reference, but probably isn't: '3' on line 748 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 October 25, 2016 5 Expires: April 28, 2017 7 The font Top Level Type 8 draft-ietf-justfont-toplevel-03 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 April 28, 2017. 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 new top-level Internet Media Type "font" 72 according to Section 4.2.7 of [RFC6838]. This top-level type 73 indicates that the content specifies font data. Under this top-level 74 type, different representation formats of fonts may be registered 75 (e.g. bitmap or outline formats). 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 3. Background and Justification 83 Historically there has not been a registration of formats for fonts. 84 More recently, there have been several representation formats 85 registered as MIME subtypes under the "application" top-level type 86 (for example, application/font-woff). However, with the rapid 87 adoption of web fonts (based on the data from HTTP Archive 88 [HTTP-Archive-Trends] showing a huge increase in web font usage from 89 1% in the end of 2010 to 50% across all sites in the beginning of 90 2015) custom fonts on the web have become a core web resource. As 91 the in-depth analysis [Font-Media-Type-Analysis] shows, the lack of 92 the intuitive top-level font type is causing significant confusion 93 among developers - while currently defined font subtypes are severely 94 under-utilized there are many more sites that already use non- 95 existent (but highly intuitive) media types such as "font/woff", 96 "font/ttf" and "font/truetype". At the same time, the majority of 97 sites resort to using generic types such as "application/octet- 98 stream", "text/plain" and "text/html"; or use unregistrable types 99 such as "application/x-font-ttf". 101 Contrary to the expectations of the W3C WebFonts Working Group which 102 developed WOFF, the officially defined IANA subtypes such as 103 "application/font-woff" and "application/font-sfnt" see a very 104 limited use - their adoption rates trail far behind as the actual use 105 of web fonts continues to increase. The members of the W3C WebFonts 106 WG concluded that the use of "application" top-level type is not 107 ideal. First, the "application" sub-tree is treated (correctly) with 108 great caution with respect to viruses and other active code. 109 Secondly, the lack of a top-level type means that there is no 110 opportunity to have a common set of optional attributes, such as are 111 specified here. Third, fonts have a unique set of licensing and 112 usage restrictions, which makes it worthwhile to identify this 113 general category with a unique top-level type. 115 The W3C WebFonts WG decided that the situation can be significantly 116 improved if a set of font media types is registered using "font" as a 117 dedicated top-level type. Based on the data analysis presented 118 above, we conclude that it is the presence of simple and highly 119 intuitive media types for images that caused the widespread adoption 120 of IANA's recommendations, where the correct usage of existing media 121 types reaches over 97% for all subtypes in the "image" tree. The WG 122 considers that, considering a rapid adoption of fonts on the web, the 123 registration of the top-level media type for fonts along with the 124 intuitive set of subtypes that reflect popular and widely used data 125 formats would further stimulate the adoption of web fonts, 126 significantly simplify web server configuration process and 127 facilitate the proper use of IANA media type recommendations. 129 4. Security considerations 131 Fonts are interpreted data structures that represent collections of 132 different tables containing data that represent different types of 133 information, including glyph outlines in various formats, hinting 134 instructions, metrics and layout information for multiple languages 135 and writing systems, rules for glyph substitution and positioning, 136 etc. Depending on the format used to represent the glyph data the 137 font may contain TrueType [truetype-wiki], PostScript 138 [postscript-wiki] or SVG [svg-wiki] outlines and their respective 139 hint instructions, where applicable. There are many existing, 140 already standardized font table tags and formats that allow an 141 unspecified number of entries containing predefined data fields for 142 storage of variable length binary data. Many existing (TrueType, 143 OpenType [opentype-wiki] and OFF, SIL Graphite, WOFF, etc.) font 144 formats are based on the table-based SFNT (scalable font) format 145 which is extremely flexible, highly extensible and offers an 146 opportunity to introduce additional table structures when needed, in 147 a way that would not affect existing font rendering engines and text 148 layout implementations. However, this very extensibility may present 149 specific security concerns - the flexibility and ease of adding new 150 data structures makes it easy for any arbitrary data to be hidden 151 inside a font file. There is a significant risk that the flexibility 152 of font data structures may be exploited to hide malicious binary 153 content disguised as a font data component. 155 Fonts may contain 'hints', which are programmatic instructions that 156 are executed by the font engine for the alignment of graphical 157 elements of glyph outlines with the target display pixel grid. 158 Depending on the font technology utilized in the creation of a font 159 these hints may represent active code interpreted and executed by the 160 font rasterizer. Even though hints operate within the confines of 161 the glyph outline conversion system and have no access outside the 162 font rendering engine, hint instructions can be, however, quite 163 complex, and a maliciously designed complex font could cause undue 164 resource consumption (e.g. memory or CPU cycles) on a machine 165 interpreting it. Indeed, fonts are sufficiently complex, and most 166 (if not all) interpreters cannot be completely protected from 167 malicious fonts without undue performance penalties. 169 Widespread use of fonts as necessary components of visual content 170 presentation warrants that careful attention should be given to 171 security considerations whenever a font is either embedded into an 172 electronic document or transmitted alongside media content as a 173 linked resource. While many existing font formats provide certain 174 levels of protection of data integrity (such mechanisms include e.g. 175 checksums and digital signatures), font data formats provide neither 176 privacy nor confidentiality protection internally; if needed, such 177 protection should be provided externally. 179 5. IANA Considerations 181 This specification requires IANA to modify the rules for the existing 182 Internet Media Types registry by adding a new font top-level type in 183 the standards tree, updating the media types registration form 184 [Media-Type-Registration], and registering several subtypes. 186 6. Definition and encoding 188 The "font" as the primary media content type indicates that the 189 content identified by it requires certain graphic subsystem such as 190 font rendering engine (and, in some cases, text layout and shaping 191 engine) to process font data, which in turn may require certain level 192 of hardware capabilities such as certain levels of CPU performance 193 and available memory. The "font" media type does not provide any 194 specific information about the underlying data format and how the 195 font information should be interpreted - the subtypes defined within 196 a "font" tree will name the specific font formats. Unrecognized sub- 197 types of "font" should be treated as "application/octet-stream". 198 Implementations may pass unrecognized subtypes to a common font- 199 handling system, if such a system is available. 201 7. Defined subtypes 203 In this section the initial entries under the top-level 'font' MIME 204 type are documented. They also serve as examples for future 205 registrations. 207 For each subtype, an @font-face format identifer is defined. This is 208 for use with the @font-face src descriptor, defined by the CSS3 Fonts 209 specification [W3C.CR-css-fonts-3-20131003]. 211 7.1. Generic SFNT font type 213 Type name: font 215 Subtype name: sfnt 217 Required parameters: None. 219 Optional parameters: 221 1) Name: Outlines Value: TTF, CFF, SVG 223 This parameter can be used to specify the type of outlines 224 supported by the font. Value "TTF" shall be used when a font 225 resource contains glyph outlines in TrueType format, value 226 "CFF" shall be used to identify fonts containing PostScript/CFF 227 outlines, and value SVG shall be used to identify fonts that 228 include SVG outlines. TTF, CFF or SVG outlines can be present 229 in various combinations in the same font file, therefore, this 230 optional parameter is a list containing one or more items, 231 separated by commas, with optional whitespace. Order in the 232 list is not significant. 234 2) Name: Layout 236 Value: OTL, AAT, SIL 238 This parameter identifies the type of implemented support for 239 advanced text layout features. The predefined values "OTL", 240 "AAT" and "SIL" respectively indicate support for OpenType text 241 layout, Apple Advanced Typography or Graphite SIL. More than 242 one shaping and layout mechanism may be supported by the same 243 font file, therefore, this optional parameter is a list 244 containing one or more items, separated by commas, with 245 optional whitespace. Order in the list is not significant. 247 Encoding considerations: Binary. 249 Interoperability considerations: As it was noted in the first 250 paragraph of the "Security considerations" section, the same font 251 format wrapper can be used to encode fonts with different types of 252 glyph data represented as either TrueType or PostScript (CFF) 253 outlines. Existing font rendering engines may not be able to 254 process some of the particular outline formats, and downloading a 255 font resource that contains unsupported glyph data format would 256 result in inability of application to render and display text. 257 Therefore, it would be extremely useful to clearly identify the 258 format of the glyph outline data within a font using an optional 259 parameter, and allow applications to make decisions about 260 downloading a particular font resource sooner. Similar, another 261 optional parameter is suggested to identify the type of text 262 shaping and layout mechanism that is supported by a font. Please 263 note that as new outline formats and text shaping mechanisms may 264 be defined in the future, the set of allowed values for two 265 optional parameters defined by this section may be extended. 267 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 268 specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ 269 WG11. 271 Applications that use this media type: Any and all applications that 272 are able to create, edit or display textual media content. 274 Additional information: 276 Magic number(s): The TrueType fonts and OFF / OpenType fonts 277 containing TrueType outlines should use 0x00010000 as the 278 'sfnt' version number. 280 The OFF / OpenType fonts containing CFF data should use the tag 281 'OTTO' as 'sfnt' version number. 283 File extension(s): Font file extensions used for OFF / OpenType 284 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 381 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 382 product of the ISO/IEC JTC1 SC29/WG11. 384 Change controller: The ISO/IEC has change control over this 385 specification. 387 7.3. OTF font type 389 Type name: font 391 Subtype name: otf 393 Required parameters: None. 395 Optional parameters 397 Name: Outlines Value: TTF, CFF, SVG 399 This parameter can be used to specify the type of outlines 400 supported by the font. Value "TTF" shall be used when a font 401 resource contains glyph outlines in TrueType format, value 402 "CFF" shall be used to identify fonts containing PostScript/CFF 403 outlines, and value SVG shall be used to identify fonts that 404 include SVG outlines. TTF, CFF or SVG outlines can be present 405 in various combinations in the same font file, therefore, this 406 optional parameter is a list containing one or more items, 407 separated by commas, with optional whitespace. Order in the 408 list is not significant. 410 Encoding considerations: Binary. 412 Interoperability considerations: As it was noted in the first 413 paragraph of the "Security considerations" section, the same font 414 format can be used to encode fonts with different types of glyph 415 data represented as either TrueType, PostScript (CFF) or SVG 416 outlines. Existing font rendering engines may not be able to 417 process some of the particular outline formats, and downloading a 418 font resource that contains unsupported glyph data format would 419 result in inability of application to render and display text. 420 Therefore, it would be extremely useful to clearly identify the 421 format of the glyph outline data within a font using an optional 422 parameter, and allow applications to make decisions about 423 downloading a particular font resource sooner. Please note that 424 as new outline formats may be defined in the future, the set of 425 allowed values for the optional parameter defined in this section 426 may be extended. 428 Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) 429 specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ 430 WG11. 432 Applications that use this media type: Any and all applications that 433 are able to create, edit or display textual media content. 435 Additional information: 437 Magic number(s): The TrueType fonts and OFF / OpenType fonts 438 containing TrueType outlines should use 0x00010000 as the 439 'sfnt' version number. 441 The OFF / OpenType fonts containing CFF outlines should use the 442 tag 'OTTO' as 'sfnt' version number. There is no magic number 443 for SVG outlines; these are always accompanied by either 444 TrueType or CFF outlines and thus use the corresponding magic 445 number. 447 File extension(s): Font file extensions used for OFF / OpenType 448 fonts: .ttf, .otf 450 Typically, .ttf extension is only used for fonts containing 451 TrueType outlines, while .otf extension can be used for any 452 OpenType/OFF font, either with TrueType, CFF or SVG outlines. 454 Macintosh file type code(s): (no code specified) 456 @font-face Format: opentype 458 Fragment Identifiers none. 460 Person & email address to contact for further information: Vladimir 461 Levantovsky (vladimir.levantovsky@monotype.com). 463 Intended usage: COMMON 465 Restrictions on usage: None 467 Author: The ISO/IEC 14496-22 "Open Font Format" specification is a 468 product of the ISO/IEC JTC1 SC29/WG11. 470 Change controller: The ISO/IEC has change control over this 471 specification. 473 7.4. Collection font type 475 Type name: font 477 Subtype name: collection 479 Required parameters: None. 481 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 ('wOFF') 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 Deprecated Alias: The existing registration application/font-woff 593 is deprecated in favor of font/woff. 595 Person & email address to contact for further information: Chris 596 Lilley (www-font@w3.org). 598 Intended usage: COMMON 600 Restrictions on usage: None 602 Author: The WOFF specification is a work product of the World Wide 603 Web Consortium's WebFonts Working Group. 605 Change controller: The W3C has change control over this 606 specification. 608 7.6. WOFF 2.0 610 Type name: font 612 Subtype name: woff2 614 Required parameters: None. 616 Optional parameters: None. 618 Encoding considerations: Binary. 620 Interoperability considerations: WOFF 2.0 is an improvement on WOFF 621 1.0. The two formats have different Internet Media Types, 622 different @font-face formats, and may be used in parallel. 624 Published specification: This media type registration is extracted 625 from the WOFF 2.0 specification [W3C.WD-WOFF2-20150414] at W3C. 627 Applications that use this media type: WOFF 2.0 is used by Web 628 browsers, often in conjunction with HTML and CSS. 630 Additional information: 632 Magic number(s): The signature field in the WOFF header MUST 633 contain the "magic number" 0x774F4632 ('wOF2') 635 File extension(s): woff2 637 Macintosh file type code(s): (no code specified) 639 Macintosh Universal Type Identifier code: "org.w3c.woff2" 641 @font-face Format: woff2 643 Fragment Identifiers Optional, for collections encoded as WOFF 644 2.0. A positive integer. For example, #2 refers to the second 645 font in the collection. If a fragment is not specified, it is 646 the same as #1 i.e. the first font in the collection (or the 647 only font, if it is not a collection). If a fragment is 648 specified, and the WOFF does not encode a collection, the 649 fragment is ignored. 651 Person & email address to contact for further information: Chris 652 Lilley (www-font@w3.org). 654 Intended usage: COMMON 656 Restrictions on usage: None 658 Author: The WOFF2 specification is a work product of the World Wide 659 Web Consortium's WebFonts Working Group. 661 Change controller: The W3C has change control over this 662 specification. 664 8. New Registrations 666 New font formats should be registered using the online form 667 [Media-Type-Registration]. RFC 6838 [RFC6838] should be consulted on 668 registration procedures. In particular the font specification must 669 be freely available and the ABNF must be followed. Also, an @font- 670 face format should be supplied and, if used, a definition of the 671 fragment identifier syntax for the new type. 673 9. References 675 9.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 683 Specifications and Registration Procedures", BCP 13, 684 RFC 6838, DOI 10.17487/RFC6838, January 2013, 685 . 687 [W3C.CR-css-fonts-3-20131003] 688 Daggett, J., "CSS Fonts Module Level 3", World Wide Web 689 Consortium CR CR-css-fonts-3-20131003, October 2013, 690 . 692 [ISO.14496-22.2015] 693 International Organization for Standardization, "Coding of 694 audio-visual objects Part 22: Open Font Format", 695 ISO Standard 14496-22, 10 2015, 696 . 699 [W3C.REC-WOFF-20121213] 700 Kew, J., Leming, T., and E. Blokland, "WOFF File Format 701 1.0", World Wide Web Consortium Recommendation REC-WOFF- 702 20121213, December 2012, 703 . 705 [W3C.WD-WOFF2-20150414] 706 Levantovsky, V. and R. Levien, "WOFF File Format 2.0", 707 World Wide Web Consortium WD WD-WOFF2-20150414, March 708 2016, . 710 9.2. Informative References 712 [cff-wiki] 713 "CFF", . 716 [opentype-wiki] 717 "OpenType", . 719 [postscript-wiki] 720 "PostScript". 722 [truetype-wiki] 723 "TrueType", . 725 [svg-wiki] 726 "SVG", . 729 [HTTP-Archive-Trends] 730 Kuetell, D., "HTTP Archive trend analysis", March 2015, 731 . 734 [Font-Media-Type-Analysis] 735 Kuetell, D., "Web Font Media Type (mime type) Analysis 736 2015", 2015, . 738 [Media-Type-Registration] 739 IANA, "Application for a Media Type", 740 . 742 9.3. URIs 744 [1] https://github.com/svgeesus/ietf-justfont 746 [2] https://github.com/svgeesus/ietf-justfont/issues 748 [3] mailto:justfont@ietf.org 750 Author's Address 752 Chris Lilley 753 W3C 754 2004 Route des Lucioles 755 Sophia Antipolis 06902 756 France 758 Email: chris@w3.org