doc: Add RFC documents

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]
+