diff options
Diffstat (limited to 'doc/rfc/rfc8081.txt')
| -rw-r--r-- | doc/rfc/rfc8081.txt | 1011 |
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc8081.txt b/doc/rfc/rfc8081.txt new file mode 100644 index 0000000..be904d0 --- /dev/null +++ b/doc/rfc/rfc8081.txt @@ -0,0 +1,1011 @@ + + + + + + +Internet Engineering Task Force (IETF) C. Lilley +Request for Comments: 8081 W3C +Category: Standards Track February 2017 +ISSN: 2070-1721 + + + The "font" Top-Level Media Type + +Abstract + + This memo serves to register and document the "font" top-level media + type, under which subtypes for representation formats for fonts may + be registered. This document also serves as a registration + application for a set of intended subtypes, which are representative + of some existing subtypes already in use, and currently registered + under the "application" tree by their separate registrations. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8081. + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +Lilley Standards Track [Page 1] + +RFC 8081 The 'font' Top-Level Type February 2017 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Background and Justification . . . . . . . . . . . . . . . . 3 + 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Definition and Encoding . . . . . . . . . . . . . . . . . 5 + 4.2. Fragment Identifiers for Font Collections . . . . . . . . 5 + 4.3. Registration Procedure . . . . . . . . . . . . . . . . . 6 + 4.4. Subtype Registrations . . . . . . . . . . . . . . . . . . 6 + 4.4.1. Generic SFNT Font Type . . . . . . . . . . . . . . . 6 + 4.4.2. TTF Font Type . . . . . . . . . . . . . . . . . . . . 9 + 4.4.3. OpenType Layout (OTF) Font Type . . . . . . . . . . . 10 + 4.4.4. Collection Font Type . . . . . . . . . . . . . . . . 12 + 4.4.5. WOFF 1.0 . . . . . . . . . . . . . . . . . . . . . . 14 + 4.4.6. WOFF 2.0 . . . . . . . . . . . . . . . . . . . . . . 15 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 5.2. Informative References . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 + +1. Introduction + + The process of setting type in computer systems and other forms of + text presentation systems uses fonts in order to provide visual + representations of the glyphs. Just as with images, for example, + there are a number of ways to represent the visual information of the + glyphs. Early font formats often used bitmaps, as these could have + been carefully tuned for maximum readability at a given size on low- + resolution displays. More recently, scalable vector outline fonts + have come into widespread use. In these fonts, the outlines of the + glyphs are described, and the presentation system renders the outline + in the desired position and size. + + Over time, a number of standard formats for recording font + descriptions have evolved. Internet Media Types [RFC6838] are used + to label content carried over Internet protocols. This document + defines a new top-level type "font" according to Section 4.2.7 of + [RFC6838]. This top-level type indicates that the content specifies + font data. Under this top-level type, different representation + formats of fonts may be registered. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + + + + + +Lilley Standards Track [Page 2] + +RFC 8081 The 'font' Top-Level Type February 2017 + + +2. Background and Justification + + Historically, there has not been a registration of formats for fonts. + More recently, there have been several representation formats + registered as media subtypes under the "application" top-level type + (for example, "application/font-woff"). However, with the rapid + adoption of web fonts (based on the data from HTTP Archive + [HTTP-Archive-Trends] showing a huge increase in web font usage from + 1% in the end of 2010 to 50% across all sites in the beginning of + 2015), custom fonts on the web have become a core web resource. As + the in-depth analysis [Font-Media-Type-Analysis] shows, the lack of + the intuitive top-level font type is causing significant confusion + among developers -- while currently defined font subtypes are + severely under-utilized, there are many more sites that already use + nonexistent (but highly intuitive) media types such as "font/woff", + "font/ttf", and "font/truetype". At the same time, the majority of + sites resort to using generic types such as "application/octet- + stream", "text/plain", and "text/html", or use unregisterable types + such as "application/x-font-ttf". + + Contrary to the expectations of the W3C WebFonts WG, which developed + Web Open Font Format (WOFF), the officially defined media types such + as "application/font-woff" and "application/font-sfnt" see a very + limited use -- their adoption rates trail far behind as the actual + use of web fonts continues to increase. The members of the W3C + WebFonts WG concluded that the use of the "application" top-level + type is not ideal. First, the "application" sub-tree is treated + (correctly) with great caution with respect to viruses and other + active code. Secondly, the lack of a top-level type means that there + is no opportunity to have a common set of optional parameters, such + as are specified here. Third, fonts have a unique set of licensing + and usage restrictions, which makes it worthwhile to identify this + general category with a unique top-level type. + + The W3C WebFonts WG decided [WG-tlt] that the situation can be + significantly improved if a set of font media types is registered + using "font" as a dedicated top-level type. 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, where the correct usage of existing media types + reaches over 97% for all subtypes in the "image" tree. The WG + considers that, keeping in mind a rapid adoption of fonts on the web, + the registration of the top-level media type for fonts along with the + intuitive set of subtypes that reflect popular and widely used data + formats would further stimulate the adoption of web fonts, + significantly simplify web server configuration process, and + facilitate the proper use of media types for fonts. + + + + +Lilley Standards Track [Page 3] + +RFC 8081 The 'font' Top-Level Type February 2017 + + +3. Security Considerations + + Fonts are interpreted data structures that represent collections of + different tables containing data that represent different types of + information, including glyph outlines in various formats, hinting + instructions, metrics and layout information for multiple languages + and writing systems, rules for glyph substitution and positioning, + etc. In particular, the hinting instructions for TrueType glyphs + represent executable code that has the potential to be maliciously + constructed (for example, intended to hang the interpreter). There + are many existing, already standardized font table tags and formats + that allow an unspecified number of entries containing predefined + data fields for storage of variable-length binary data. Many + existing font formats (TrueType [truetype-wiki], OpenType and OFF + [opentype-wiki], SIL Graphite, WOFF, etc.) are based on the table- + based SFNT (scalable font) format, which is extremely flexible, + highly extensible, and offers an opportunity to introduce additional + table structures when needed, in an upward-compatible way that would + not affect existing font rendering engines and text layout + implementations. However, this very extensibility may present + specific security concerns -- the flexibility and ease of adding new + data structures makes it easy for any arbitrary data to be hidden + inside a font file. There is a significant risk that the flexibility + of font data structures may be exploited to hide malicious binary + content disguised as a font data component. + + Fonts may contain 'hints', which are programmatic instructions that + are executed by the font engine for the alignment of graphical + elements of glyph outlines with the target display pixel grid. + Depending on the font technology utilized in the creation of a font, + these hints may represent active code interpreted and executed by the + font rasterizer. Even though hints operate within the confines of + the glyph outline conversion system and have no access outside the + font rendering engine, hint instructions can be quite complex, and a + maliciously designed complex font could cause undue resource + consumption (e.g., memory or CPU cycles) on a machine interpreting + it. Indeed, fonts are sufficiently complex that most (if not all) + interpreters cannot be completely protected from malicious fonts + without undue performance penalties. + + Widespread use of fonts as necessary components of visual content + presentation warrants that careful attention should be given to + security considerations whenever a font is either embedded into an + electronic document or transmitted alongside media content as a + linked resource. While many existing font formats provide certain + levels of protection of data integrity (such mechanisms include, + e.g., checksums and digital signatures), font data formats provide + + + + +Lilley Standards Track [Page 4] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + neither privacy nor confidentiality protection internally; if needed, + such protection should be provided externally. + +4. IANA Considerations + + 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. + +4.1. Definition and Encoding + + The "font" as the primary media content type indicates that the + content identified by it requires a certain graphic subsystem such as + a font rendering engine (and, in some cases, a text layout and a + shaping engine) to process it as font data, which in turn may require + a certain level of hardware capabilities such as certain levels of + CPU performance and available memory. The "font" media type does not + provide any specific information about the underlying data format and + how the font information should be interpreted -- the subtypes + defined within a "font" tree name the specific font formats. + Unrecognized subtypes of "font" should be treated as "application/ + octet-stream". Implementations may pass unrecognized subtypes to a + common font-handling system, if such a system is available. + +4.2. Fragment Identifiers for Font Collections + + Fragment identifiers for font collections identify one font in the + collection by the PostScript name (name ID=6) [ISO.14496-22.2015]. + This is a string, no longer than 63 characters and restricted to the + printable ASCII subset, codes 33 ? 126, except for the 10 characters + '[', ']', '(', ')', '{', '}', '<', '>', '/', '%', which are forbidden + by [ISO.14496-22.2015]. + + In addition, the following 6 characters could occur in the PostScript + name but are forbidden in fragments by [RFC3986], and thus must be + escaped: '"', '#', '\', '^', '`', '|'. + + If (following un-escaping) this string matches one of the PostScript + names in the name table, that font is selected. For example, "#Foo- + Bold" refers to the font with PostScript name "Foo-Bold" and + "#Caret%5Estick" refers to the font with PostScript name + "Caret^stick". If the name does not match, or if a fragment is not + specified, the first font in the collection is matched. Note that + the order of fonts in collections may change as the font is revised, + so relying on a particular font in a collection always being first is + unwise. + + + + +Lilley Standards Track [Page 5] + +RFC 8081 The 'font' Top-Level Type February 2017 + + +4.3. Registration Procedure + + New font formats should be registered using the online form + [Media-Type-Registration]. [RFC6838] should be consulted on + registration procedures. In particular, the font specification + should preferably be freely available. If the font format can + contain multiple fonts, a fragment identifier syntax should also be + defined. + + Note that new parameter sub-values may be defined in the future. If + an implementation does not recognize a sub-value in the comma- + separated list, it should ignore the sub-value and continue + processing the other sub-values in the list. + +4.4. Subtype Registrations + + In this section, the initial entries under the top-level 'font' media + type are specified. They also serve as examples for future + registrations. + + For each subtype, an @font-face format identifier is listed. This is + for use with the @font-face src descriptor, defined by the Cascading + Style Sheets Level 3 (CSS3) Fonts specification + [W3C.CR-css-fonts-3-20131003]. That specification is normative; the + identifiers here are informative. + +4.4.1. Generic SFNT Font Type + + Type name: font + + Subtype name: sfnt + + Required parameters: None + + Optional parameters: + + 1) Name: outlines + + Values: a comma-separated subset of True Type Font (TTF), + Compact Font Format (CFF), and SVG + + This parameter can be used to specify the type of outlines + provided by the font. The value "TTF" shall be used when a + font resource contains glyph outlines in TrueType format, the + value "CFF" shall be used to identify fonts containing + PostScript/CFF outlines [cff-wiki], and the value SVG + [svg-wiki] shall be used to identify fonts that include SVG + outlines. TTF, CFF, or SVG outlines can be present in various + + + +Lilley Standards Track [Page 6] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + combinations in the same font file; therefore, this optional + parameter is a list containing one or more items, separated by + commas. Order in the list is not significant. + + 2) Name: layout + + Values: a comma-separated subset of OTL, Apple Advanced + Typography (AAT), and SIL + + This parameter identifies the type of implemented support for + advanced text layout features. The predefined values "OTL", + "AAT", and "SIL", respectively, indicate support for OpenType + text layout, Apple Advanced Typography, or Graphite SIL. More + than one shaping and layout mechanism may be provided by the + same font file; therefore, this optional parameter is a list + containing one or more items, separated by commas. Order in + the list is not significant. + + Encoding considerations: Binary + + Interoperability considerations: As it was noted in the first + paragraph of the Security Considerations section, a single font + file can contain encoding of the same glyphs using several + different representations, e.g., both TrueType and PostScript + (CFF) outlines. Existing font rendering engines may not be able + to process some of the particular outline formats, and downloading + a font resource that contains only an unsupported glyph data + format would be futile. Therefore, it is useful to clearly + identify the format of the glyph outline data within a font using + an optional parameter, and allow applications to make decisions + about downloading a particular font resource sooner. Similarly, + another optional parameter identifies the type of text shaping and + layout mechanism that is provided by a font. + + Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) + specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ + WG11. + + Applications that use this media type: All applications that are + able to create, edit, or display textual media content. + + Note that "font/sfnt" is 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: + + Uncommon combinations such as "font/sfnt; layout=sil" that do + not have a shorter type + + + +Lilley Standards Track [Page 7] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + Cases where a new parameter value is registered + + Test cases, experimentation, etc. + + Additional information: + + Magic number(s): The TrueType fonts and OFF / OpenType fonts + containing TrueType outlines should use 0x00010000 as the + 'sfnt' version number. + + The OFF / OpenType fonts containing CFF data should use the tag + 'OTTO' as the 'sfnt' version number. + + File extension(s): Font file extensions used for OFF / OpenType + fonts: .ttf and .otf + + Typically, the .ttf extension is only used for fonts containing + TrueType outlines, whereas the .otf extension can be used for + any OpenType/OFF font, and either can be used with the TrueType + or CFF outlines. + + Macintosh file type code(s): (no code specified) + + Macintosh Universal Type Identifier code: "public.font" + + @font-face Format: None + + Fragment Identifiers: None + + Deprecated Alias: The existing registration "application/font- + sfnt" is deprecated in favor of "font/sfnt". + + Person & email address to contact for further information: + Vladimir Levantovsky (vladimir.levantovsky@monotype.com). + + Intended usage: COMMON + + Restrictions on usage: None + + Author: The ISO/IEC 14496-22 "Open Font Format" specification is a + product of the ISO/IEC JTC1 SC29/WG11. + + Change controller: The ISO/IEC has change control over this + specification. + + + + + + + +Lilley Standards Track [Page 8] + +RFC 8081 The 'font' Top-Level Type February 2017 + + +4.4.2. TTF Font Type + + Type name: font + + Subtype name: ttf + + Required parameters: None + + Optional parameters: + + Name: layout + + Values: a comma-separated subset of OTL, AAT, and SIL + + This parameter identifies the type of support mechanism for + advanced text layout features. The predefined values "OTL", + "AAT", and "SIL" respectively indicate support for OpenType + text layout, Apple Advanced Typography, or Graphite SIL. More + than one shaping and layout mechanism may be provided by the + same font file; therefore, this optional parameter is a list + containing one or more items, separated by commas. Order in + the list is not significant. + + Encoding considerations: Binary + + Interoperability considerations: As it was noted in the first + paragraph of Section 3, a single font file can contain encoding of + the same glyphs using several different representations, e.g., + both TrueType and PostScript (CFF) outlines. Existing font + rendering engines may not be able to process some of the + particular outline formats, and downloading a font resource that + contains only an unsupported glyph data format would be futile. + Therefore, it is useful to clearly identify the format of the + glyph outline data within a font using an optional parameter, and + allow applications to make decisions about downloading a + particular font resource sooner. Similarly, another optional + parameter identifies the type of text shaping and layout mechanism + that is provided by a font. + + Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) + specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ + WG11. + + Applications that use this media type: All applications that are + able to create, edit, or display textual media content. + + + + + + +Lilley Standards Track [Page 9] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + Additional information: + + Magic number(s): The TrueType fonts and OFF / OpenType fonts + containing TrueType outlines should use 0x00010000 as the + 'sfnt' version number. + + File extension(s): Font file extensions used for TrueType / OFF / + OpenType fonts: .ttf and .otf + + Typically, the .ttf extension is only used for fonts containing + TrueType outlines, while the .otf extension may be used for any + OpenType/OFF font, either with TrueType or CFF outlines. + + Macintosh file type code(s): (no code specified) + + Macintosh Universal Type Identifier code: "public.truetype-font" + + @font-face Format: truetype + + Fragment Identifiers: None + + Person & email address to contact for further information: + Vladimir Levantovsky (vladimir.levantovsky@monotype.com). + + Intended usage: COMMON + + Restrictions on usage: None + + Author: The ISO/IEC 14496-22 "Open Font Format" specification is a + product of the ISO/IEC JTC1 SC29/WG11. + + Change controller: The ISO/IEC has change control over this + specification. + +4.4.3. OpenType Layout (OTF) Font Type + + Type name: font + + Subtype name: otf + + Required parameters: None + + Optional parameters + + Name: outlines + + + + + + +Lilley Standards Track [Page 10] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + Values: a comma-separated subset of TTF, CFF, and SVG + + This parameter can be used to specify the type of outlines + provided by the font. The value "TTF" shall be used when a + font resource contains glyph outlines in TrueType format, the + value "CFF" shall be used to identify fonts containing + PostScript/CFF outlines, and the value SVG shall be used to + identify fonts that include SVG outlines. TTF, CFF, or SVG + outlines can be present in various combinations in the same + font file; therefore, this optional parameter is a list + containing one or more items, separated by commas. Order in + the list is not significant. + + Encoding considerations: Binary + + Interoperability considerations: As it was noted in the first + paragraph of the Security Considerations section, a single font + file can contain encoding of the same glyphs using several + different representations, e.g., both TrueType and PostScript + (CFF) outlines. Existing font rendering engines may not be able + to process some of the particular outline formats, and downloading + a font resource that contains only unsupported glyph data format + would be futile. Therefore, it is useful to clearly identify the + format of the glyph outline data within a font using an optional + parameter, and allow applications to make decisions about + downloading a particular font resource sooner. Similarly, another + optional parameter identifies the type of text shaping and layout + mechanism that is provided by a font. + + Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) + specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ + WG11. + + Applications that use this media type: All applications that are + able to create, edit, or display textual media content. + + Additional information: + + Magic number(s): The TrueType fonts and OFF / OpenType fonts + containing TrueType outlines should use 0x00010000 as the + 'sfnt' version number. + + The OFF / OpenType fonts containing CFF outlines should use the + tag 'OTTO' as the 'sfnt' version number. There is no magic + number for SVG outlines; these are always accompanied by either + TrueType or CFF outlines, and thus use the corresponding magic + number. + + + + +Lilley Standards Track [Page 11] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + File extension(s): Font file extensions used for OFF / OpenType + fonts: .ttf and .otf + + Typically, the .ttf extension is only used for fonts containing + TrueType outlines, while the .otf extension can be used for any + OpenType/OFF font, either with TrueType, CFF, or SVG outlines. + + Macintosh file type code(s): (no code specified) + + Macintosh Universal Type Identifier code: "public.opentype-font" + + @font-face Format: opentype + + Fragment Identifiers: None + + Person & email address to contact for further information: + Vladimir Levantovsky (vladimir.levantovsky@monotype.com). + + Intended usage: COMMON + + Restrictions on usage: None + + Author: The ISO/IEC 14496-22 "Open Font Format" specification is a + product of the ISO/IEC JTC1 SC29/WG11. + + Change controller: The ISO/IEC has change control over this + specification. + +4.4.4. Collection Font Type + + Type name: font + + Subtype name: collection + + Required parameters: None + + Optional parameters + + Name: outlines + + Values: a comma-separated subset of TTF, CFF, and SVG + + This parameter can be used to specify the type of outlines + provided by the font. The value "TTF" shall be used when a + font resource contains glyph outlines in TrueType format, the + value "CFF" shall be used to identify fonts containing + PostScript/CFF outlines, and the value SVG shall be used to + identify fonts that include SVG outlines. TTF, CFF, or SVG + + + +Lilley Standards Track [Page 12] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + outlines can be present in various combinations in the same + font file; therefore, this optional parameter is a list + containing one or more items, separated by commas. Order in + the list is not significant. + + Encoding considerations: Binary + + Interoperability considerations: As it was noted in the first + paragraph of the Security Considerations section, a single font + file can contain encoding of the same glyphs using several + different representations, e.g., both TrueType and PostScript + (CFF) outlines. Existing font rendering engines may not be able + to process some of the particular outline formats, and downloading + a font resource that contains only unsupported glyph data format + would be futile. Therefore, it is useful to clearly identify the + format of the glyph outline data within a font using an optional + parameter, and allow applications to make decisions about + downloading a particular font resource sooner. Similarly, another + optional parameter identifies the type of text shaping and layout + mechanism that is provided by a font. + + Published specification: ISO/IEC 14496-22 "Open Font Format" (OFF) + specification [ISO.14496-22.2015] being developed by ISO/IEC SC29/ + WG11. + + Applications that use this media type: All applications that are + able to create, edit, or display textual media content. + + Additional information: + + Magic number(s): The TrueType fonts and OFF / OpenType fonts + containing TrueType outlines should use 0x00010000 as the + 'sfnt' version number. + + The OFF / OpenType fonts containing CFF outlines should use the + tag 'OTTO' as the 'sfnt' version number. There is no magic + number for SVG outlines; these are always accompanied by either + TrueType or CFF outlines, and thus use the corresponding magic + number. + + File extension(s): Font file extensions used for OFF / TrueType + and OpenType fonts: .ttc + + Macintosh file type code(s): (no code specified) + + Macintosh Universal Type Identifier code: "public.truetype- + collection-font" + + + + +Lilley Standards Track [Page 13] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + @font-face Format: collection + + Fragment Identifiers: See Section 4.2. + + Person & email address to contact for further information: + Vladimir Levantovsky (vladimir.levantovsky@monotype.com). + + Intended usage: COMMON + + Restrictions on usage: None + + Author: The ISO/IEC 14496-22 "Open Font Format" specification is a + product of the ISO/IEC JTC1 SC29/WG11. + + Change controller: The ISO/IEC has change control over this + specification. + +4.4.5. WOFF 1.0 + + Type name: font + + Subtype name: woff + + Required parameters: None + + Optional parameters: None + + Encoding considerations: Binary + + Interoperability considerations: None + + Published specification: This media type registration updates the + WOFF specification [W3C.REC-WOFF-20121213] at W3C. + + Applications that use this media type: WOFF is used by web browsers, + often in conjunction with HTML and CSS. + + Additional information: + + Magic number(s): The signature field in the WOFF header MUST + contain the "magic number" 0x774F4646 ('wOFF') + + File extension(s): woff + + Macintosh file type code(s): (no code specified) + + Macintosh Universal Type Identifier code: "org.w3.woff" + + + + +Lilley Standards Track [Page 14] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + @font-face Format: woff + + Fragment Identifiers: None + + Deprecated Alias: The existing registration "application/font- + woff" is deprecated in favor of "font/woff". + + Person & email address to contact for further information: + Chris Lilley (www-font@w3.org). + + Intended usage: COMMON + + Restrictions on usage: None + + Author: The WOFF specification is a work product of the World Wide + Web Consortium's WebFonts working group. + + Change controller: The W3C has change control over this + specification. + +4.4.6. WOFF 2.0 + + Type name: font + + Subtype name: woff2 + + Required parameters: None + + Optional parameters: None + + Encoding considerations: Binary + + Interoperability considerations: WOFF 2.0 is an improvement on WOFF + 1.0. The two formats have different Internet Media Types and + different @font-face formats, and they may be used in parallel. + + Published specification: This media type registration is extracted + from the WOFF 2.0 specification [W3C.CR-WOFF2-20150414] at W3C. + + Applications that use this media type: WOFF 2.0 is used by web + browsers, often in conjunction with HTML and CSS. + + Additional information: + + Magic number(s): The signature field in the WOFF header MUST + contain the "magic number" 0x774F4632 ('wOF2') + + File extension(s): woff2 + + + +Lilley Standards Track [Page 15] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + Macintosh file type code(s): (no code specified) + + Macintosh Universal Type Identifier code: "org.w3.woff2" + + @font-face Format: woff2 + + Fragment Identifiers: See Section 4.2. + + Person & email address to contact for further information: + Chris Lilley (www-font@w3.org). + + Intended usage: COMMON + + Restrictions on usage: None + + Author: The WOFF2 specification is a work product of the World Wide + Web Consortium's WebFonts working group. + + Change controller: The W3C has change control over this + specification. + +5. References + +5.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <http://www.rfc-editor.org/info/rfc3986>. + + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + <http://www.rfc-editor.org/info/rfc6838>. + + [W3C.CR-css-fonts-3-20131003] + Daggett, J., "CSS Fonts Module Level 3", World Wide Web + Consortium CR CR-css-fonts-3-20131003, October 2013, + <http://www.w3.org/TR/2013/CR-css-fonts-3-20131003>. + + + + + + + +Lilley Standards Track [Page 16] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + [ISO.14496-22.2015] + International Organization for Standardization, "Coding of + audio-visual objects Part 22: Open Font Format", + ISO Standard 14496-22, 10 2015, + <http://standards.iso.org/ittf/PubliclyAvailableStandards/ + c066391_ISO_IEC_14496-22_2015.zip>. + + [W3C.REC-WOFF-20121213] + Kew, J., Leming, T., and E. Blokland, "WOFF File Format + 1.0", World Wide Web Consortium Recommendation + REC-WOFF-20121213, December 2012, + <http://www.w3.org/TR/2012/REC-WOFF-20121213>. + + [W3C.CR-WOFF2-20150414] + Levantovsky, V. and R. Levien, "WOFF File Format 2.0", + World Wide Web Consortium WD CR-WOFF2-20150414, March + 2016, <https://www.w3.org/TR/2016/CR-WOFF2-20160315/>. + +5.2. Informative References + + [cff-wiki] Wikipedia, "Compact Font Format", November 2016, + <https://en.wikipedia.org/w/ + index.php?title=PostScript_fonts&oldid=747740863>. + + [opentype-wiki] + Wikipedia, "OpenType", February 2017, + <https://en.wikipedia.org/w/ + index.php?title=OpenType&oldid=763528773>. + + [truetype-wiki] + Wikipedia, "TrueType", January 2017, + <https://en.wikipedia.org/w/ + index.php?title=TrueType&oldid=759367886>. + + [svg-wiki] Wikipedia, "Scalable Vector Graphics", February 2017, + <https://en.wikipedia.org/w/ + index.php?title=Scalable_Vector_Graphics&oldid=763136508>. + + [HTTP-Archive-Trends] + Kuetell, D., "HTTP Archive trend analysis", March 2015, + <http://httparchive.org/trends.php?s=All&minlabel=Nov+15+2 + 010&maxlabel=Feb+15+2015#perFonts>. + + [Font-Media-Type-Analysis] + Kuetell, D., "Web Font Media Type (mime type) Analysis + 2015", 2015, <http://goo.gl/zbDhUN>. + + + + + +Lilley Standards Track [Page 17] + +RFC 8081 The 'font' Top-Level Type February 2017 + + + [WG-tlt] W3C, "ACTION-164: Bring widely used top-level type to + w3c-ietf liaison", 2015, + <https://www.w3.org/Fonts/WG/track/actions/164>. + + [Media-Type-Registration] + IANA, "Application for a Media Type", + <http://www.iana.org/form/media-types>. + +Author's Address + + Chris Lilley + W3C + 2004 Route des Lucioles + Sophia Antipolis 06902 + France + + Email: chris@w3.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Lilley Standards Track [Page 18] + |