<?xml version="1.0"?>
<!--DOCTYPE rfc SYSTEM "rfc.dtd"-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc docName="draft-lilley-font-toplevel-00" category="std" ipr='trust200902'>
<front>
<title>The font Primary Content Type </title>
<author initials="C" surname="Lilley" fullname="Chris Lilley">
  <organization>W3C</organization>
  <address>
  <postal>
  	<street>2004 Route des Lucioles</street>
  	<city>Sophia Antipolis</city>
  	<code>06902</code>
  	<country>France</country>
  	</postal>
  	<email>chris@w3.org</email>
  </address>
</author>
<date day="16" month="October" year="2015"/>
<keyword>Internet Media Types</keyword>
<abstract>
 <t>
      This memo serves to register and document the <spanx style="verb"> font</spanx> Primary Content Type, 
      under which the Internet Media 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 registered under the "application" 
      tree by their separate registrations.
    </t>
</abstract>
</front>
<middle>

<section title="Introduction" anchor="intro">
    <t>
      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.</t>
    <t>
      This document defines a top-level Internet Media Type type "font" under which different 
      representation formats of fonts may be registered (e.g. a bitmap or outline formats). 
      <!-- not clear the rest of this paragraph is actually needed. -->
      It should be 
      emphasized that, just as under the "image" top-level type one does not find registration 
      for a specific image, for example, "The Night-watch" (by Rembrandt) but instead "JPEG" 
      (a compressed image data representation format), so, under "font" one will not find 
      "Courier" (the name of a popular font) but perhaps "TTF", "OTF" or "SFNT" (the names of 
      commonly used TrueType and OpenType font formats as well as their higher-level wrapper 
      format).</t>
</section>
<section title="Background and Justification">
    <t>Historically there has not been a registration of formats for fonts. Most recently, there 
      have been several representation formats registered as MIME subtypes under the "application" 
      top-level type.  However, with the rapid adoption of web fonts (based on the data 
      from <eref target="http://httparchive.org/trends.php?s=All&amp;minlabel=Nov+15+2010&amp;maxlabel=Feb+15+2015">
      HTTP Archive</eref> 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 <eref target="http://goo.gl/zbDhUN">the in-depth analysis</eref> 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 non-existent (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 unregistrable types
      such as "application/x-font-ttf".</t>

    <t>Contrary to our expectations, the officially defined IANA subtypes 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 believe 
      the use of "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 attributes, 
      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.</t>
      
    <t>The W3C WebFonts WG believes 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 believe that it is the presence of simple and highly intuitive media types 
      for images that caused the widespread adoption of IANA's recommendations, where the correct 
      usage of existing media types reaches over 97% for all subtypes in the "image" tree. The WG 
      believes that, considering 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 IANA media type recommendations.</t>
</section>
<section title="Security considerations">
    <t>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. Depending on the format used to represent the 
      glyph data the font may contain TrueType, PostScript or SVG outlines and their respective hint 
      instructions, where applicable. 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 (TrueType, OpenType and OFF, SIL Graphite, 
      WOFF, etc.) font formats 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 a 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.</t>

    <t>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, however, 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, and most (if not all) interpreters cannot be completely protected from 
      malicious fonts without undue performance penalties.</t>

    <t>Widespread use of fonts as necessary component of visual content presentation warrants that a 
      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 neither privacy nor 
      confidentiality protection internally; if needed, such protection should be provided externally.</t>
  </section>
<section title="Definition and encoding">
    <t>The "font" as the primary media content type indicates that the content identified by it requires 
      certain graphic subsystem such as font rendering engine (and, in some cases, text layout and shaping 
      engine) to process font data, which in turn may require 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 will name the specific font formats. 
      Unrecognized sub-types of "font" should be treated as "application/octet-stream". Implementations 
      may pass unrecognized subtypes to a common font-handling system, if such system is available.</t>
  </section>
<section title="Defined subtypes">
    <t>In this section the initial entries under the top-level 'font' MIME type are documented. They also 
      serve as examples for future registrations.</t>
  <section title="Generic SFNT font type">
  <t>
  <list style="hanging">
    <t hangText="Type name:">font</t>
    <t hangText="Subtype name:">sfnt</t>
    <t hangText="Required parameters:">None.</t>
    <t hangText="Optional parameters:">
      <list style="hanging">
    	<t hangText="1) Name: Outlines">Value: TTF, CFF, SVG <vspace blankLines="1" />
  	This parameter can be used to specify the type of outlines supported by the font. 
      Value "TTF" shall be used when a font resource contains glyph outlines in TrueType 
      format, value "CFF" shall be used to identify fonts containing PostScript/CFF outlines, 
      and 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,
      multiple values for the same optional parameter may be defined.</t>
  
    <t hangText="2) Name: Layout"></t>
    <t>Value: OTF, AAT, SIL <vspace blankLines="1" />
      This parameter identifies the type of implemented support for advanced text layout 
      features. The predefined values "OTF", "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 supported by the same font file, therefore,
      multiple values for the same optional parameter may be defined.</t>
   </list></t>
  
   <t hangText="Encoding considerations:">Binary.</t>
  
    <t hangText="Interoperability considerations:">As it was noted in the first paragraph of 
    the "Security considerations" section, the same font 
      format wrapper can be used to encode fonts with different types of glyph data represented as 
      either TrueType or 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 
      unsupported glyph data format would result in inability of application to render and display text. 
      Therefore, it would be extremely 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. Similar, another optional parameter is suggested 
      to identify the type of text shaping and layout mechanism that is supported by a font. Please 
      note that as new outline formats and text shaping mechanisms may be defined in the future, the 
      set of allowed values for two optional parameters defined by this section may be extended.</t>
  
    <t hangText="Published specification:">ISO/IEC 14496-22 "Open Font Format" (OFF) specification being developed by ISO/IEC SC29/WG11.</t>
  
    <t hangText="Applications that use this media type:">Any and all applications that are able to create, edit or display textual media content.</t>
  
  <t hangText="Additional information:">
  
  <list style="hanging">
    
      <t hangText="Magic number(s):">The TrueType fonts and OFF / OpenType fonts containing TrueType outlines should use 0x00010000 
        as the 'sfnt' version number.<vspace blankLines="1" />
      The OFF / OpenType fonts containing CFF data should use the tag 'OTTO' as 'sfnt' version number.</t>
    
      <t hangText="File extension(s):">Font file extensions used for OFF / OpenType fonts: .ttf, .otf<vspace blankLines="1" />
      Typically, .ttf extension is only used for fonts containing TrueType outlines, while .otf 
        extension can be used for any OpenType/OFF font, either with TrueType or CFF outlines.</t>
    
    <t hangText="Macintosh file type code(s):">(no code specified)</t>
    <t hangText="@font-face Format:">none.</t>
    <t hangText="Fragment Identifiers">none.</t>
  </list>
  </t>
  
    <t hangText="Person &amp; email address to contact for further information:">Vladimir Levantovsky (vladimir.levantovsky@monotype.com).</t>
  
    <t hangText="Intended usage:">COMMON</t>
  
    <t hangText="Restrictions on usage:">None</t>
  
    <t hangText="Author:">The ISO/IEC 14496-22 "Open Font Format" specification is a 
    product of the ISO/IEC JTC1 SC29/WG11.</t>
  
    <t hangText="Change controller:">The ISO/IEC has change control over this specification.</t>
  
  </list>
  </t>
  </section>      


  <section title="TTF font type">
  <t>
  <list style="hanging">
    <t hangText="Type name:">font</t>
    <t hangText="Subtype name:">ttf</t>
    <t hangText="Required parameters:">None.</t>
  
  <t hangText="Optional parameters:">
    <list style="hanging">
  
    <t hangText="Name: Layout">Value: OTF, AAT, SIL<vspace blankLines="1" />
  
      This parameter identifies the type of support mechanism for advanced text layout 
      features. The predefined values "OTF", "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 supported by the same font file, therefore,
      multiple values for the same optional parameter may be defined.</t>
      </list>
      </t>
  
   <t hangText="Encoding considerations:">Binary.</t>
  
    <t hangText="Interoperability considerations:">As was noted in the first paragraph 
    of the "Security considerations" section, the same font 
      format can be used to encode fonts supporting different types of outlines and/or text shaping and 
      layout mechanisms. Existing font rendering engine implementations may not be able to process some 
      of the particular layout table formats, and downloading a font resource that contains unsupported 
      text shaping mechanism would result in inability of applications to display text properly. 
      Therefore, it would be extremely useful to clearly identify the supported text shaping and layout 
      data within a font using an optional parameter, and allow applications to make decisions about 
      downloading a particular font resource sooner. 
      Please note that as new text shaping mechanisms may be defined in the future, the set of allowed 
      values for the optional parameter defined by this section may be extended.</t>
  
    <t hangText="Published specification:">ISO/IEC 14496-22 "Open Font Format" (OFF) 
    specification being developed by ISO/IEC SC29/WG11.</t>
  
    <t hangText="Applications that use this media type:">Any and all applications that are able to create, edit or display textual media content.</t>
  
  <t hangText="Additional information:">
  
  <list style="hanging">
    
      <t hangText="Magic number(s):">The TrueType fonts and OFF / OpenType fonts containing TrueType outlines should use 0x00010000 
        as the 'sfnt' version number.</t>
    
      <t hangText="File extension(s):">Font file extensions used for TrueType / OFF / 
      OpenType fonts: .ttf, .otf<vspace blankLines="1" />
      Typically, .ttf extension is only used for fonts containing TrueType outlines, while .otf 
        extension may be used for any OpenType/OFF font, either with TrueType or CFF outlines.</t>
    
    <t hangText="Macintosh file type code(s):">(no code specified)</t>
    <t hangText="@font-face Format:">truetype</t>
    <t hangText="Fragment Identifiers">none.</t>
  </list>
  </t>
  
    <t hangText="Person &amp; email address to contact for further information:">Vladimir Levantovsky (vladimir.levantovsky@monotype.com).</t>
  
    <t hangText="Intended usage:">COMMON</t>
  
    <t hangText="Restrictions on usage:">None</t>
  
    <t hangText="Author:">The ISO/IEC 14496-22 "Open Font Format" specification is a 
    product of the ISO/IEC JTC1 SC29/WG11.</t>
  
    <t hangText="Change controller:">The ISO/IEC has change control over this specification.</t>
  
  </list>
  </t>
  </section>
  
 

  <section title="OTF font type">
  <t>
  <list style="hanging">
    <t hangText="Type name:">font</t>
  
    <t hangText="Subtype name:">otf</t>
  
    <t hangText="Required parameters:">None.</t>
  
  <t hangText="Optional parameters">
  <list style="hanging">

    <t hangText="Name: Outlines">Value: TTF, CFF, SVG<vspace blankLines="1" />
  
    This parameter can be used to specify the type of outlines supported by the font. 
      Value "TTF" shall be used when a font resource contains glyph outlines in TrueType 
      format, value "CFF" shall be used to identify fonts containing PostScript/CFF outlines, 
      and 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,
      multiple values for the same optional parameter may be defined.</t>
      <!-- how? comma separated list? -->
   </list>
   </t>
  
   <t hangText="Encoding considerations:">Binary.</t>
  
    <t hangText="Interoperability considerations:">As it was noted in the first paragraph 
    of the "Security considerations" section, the 
      same font format can be used to encode fonts with different types of glyph data represented 
      as either TrueType, PostScript (CFF) or SVG outlines. Existing font rendering engines 
      may not be able to process some of the particular outline formats, and downloading a font 
      resource that contains unsupported glyph data format would result in inability of application 
      to render and display text. Therefore, it would be extremely 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. 
      Please note that as new outline formats may be defined in the future, the set of allowed 
      values for the optional parameter defined in this section may be extended.</t>
  
    <t hangText="Published specification:">ISO/IEC 14496-22 "Open Font Format" (OFF) 
    specification being developed by ISO/IEC SC29/WG11.</t>
  
    <t hangText="Applications that use this media type:">Any and all applications that are able 
    to create, edit or display textual media content.</t>
  
  <t hangText="Additional information:">
  
  <list style="hanging">
    
      <t hangText="Magic number(s):">The TrueType fonts and OFF / OpenType fonts containing 
      TrueType outlines should use 0x00010000 
        as the 'sfnt' version number.<vspace blankLines="1" />
      The OFF / OpenType fonts containing CFF data should use the tag 'OTTO' as 'sfnt' version number.</t>
      <!-- magic number for SVG outlines? More info on allowed combinations (or pointer to it)? -->
    
      <t hangText="File extension(s):">Font file extensions used for OFF / 
      OpenType fonts: .ttf, .otf<vspace blankLines="1" />
      Typically, .ttf extension is only used for fonts containing TrueType outlines, while .otf 
        extension can be used for any OpenType/OFF font, either with TrueType, CFF or SVG outlines.</t>
    
    <t hangText="Macintosh file type code(s):">(no code specified)</t>
    <t hangText="@font-face Format:">opentype</t>
    <!-- the @font-face format should be defined by reference to css3 fonts -->
    <t hangText="Fragment Identifiers">none.</t>
  </list>
  </t>
  
    <t hangText="Person &amp; email address to contact for further information:">Vladimir Levantovsky (vladimir.levantovsky@monotype.com).</t>
  
    <t hangText="Intended usage:">COMMON</t>
  
    <t hangText="Restrictions on usage:">None</t>
  
    <t hangText="Author:">The ISO/IEC 14496-22 "Open Font Format" specification is a product 
    of the ISO/IEC JTC1 SC29/WG11.</t>
  
    <t hangText="Change controller:">The ISO/IEC has change control over this specification.</t>
  
  </list>  
  </t>
  </section>    


  <section title="WOFF 1.0">
  <t>
  <list style="hanging">
  
    <t hangText="Type name:">font</t>
  
    <t hangText="Subtype name:">woff</t>
  
    <t hangText="Required parameters:">None.</t>
  
    <t hangText="Optional parameters:">None.</t>
  
   <t hangText="Encoding considerations:">Binary.</t>

    <t hangText="Interoperability considerations:">None. </t>
  
    <t hangText="Published specification:">This media type registration is extracted from the <eref target="http://www.w3.org/TR/WOFF">WOFF specification</eref> 
      at W3C.</t>
      <!-- except it is not, the WOFF 1.0 spec has the old application/font-woff registration. 
      Instead, this should say that it updates that document. Also, we should errata WOFF 1.0 
      to note that the registration has been changed. -->
  
    <t hangText="Applications that use this media type:">WOFF is used by Web browsers, often 
    in conjunction with HTML and CSS.</t>
  
  <t hangText="Additional information:">
  <list style="hanging">
    <t hangText="Magic number(s):">The signature field in the WOFF header MUST 
    contain the "magic number" 0x774F4646</t>
    <t hangText="File extension(s):">woff</t>
    <t hangText="Macintosh file type code(s):">(no code specified)</t>
    <t hangText="Macintosh Universal Type Identifier code:"><spanx style="verb">org.w3c.woff</spanx> </t>
    <t hangText="@font-face Format:">woff</t>
    <t hangText="Fragment Identifiers:">none.</t>
  </list>
  </t>
  
    <t hangText="Person &amp; email address to contact for further information:">Chris Lilley (www-font@w3.org).</t>
  
    <t hangText="Intended usage:">COMMON</t>
  
    <t hangText="Restrictions on usage:">None</t>
  
    <t hangText="Author:">The WOFF specification is a work product of the World Wide Web 
    Consortium's WebFonts Working Group.</t>
  
    <t hangText="Change controller:">The W3C has change control over this specification.</t>
  
  </list>      
  </t>
  </section>

<!-- what type for Collections, and do we define the fragment syntax to refer to individual fonts in the collection here? -->


  <section title="WOFF 2.0">
  <t>
  <list style="hanging">
    <t hangText="Type name:">font</t>
  
    <t hangText="Subtype name:">woff2</t>
  
    <t hangText="Required parameters:">None.</t>
  
    <t hangText="Optional parameters:">None.</t>
  
   <t hangText="Encoding considerations:">Binary.</t>
  
    <t hangText="Interoperability considerations:">WOFF 2.0 is an improvement on WOFF 1.0. The 
    two formats have different Internet Media Types, different @font-face formats, and may be 
    used in parallel. </t>
  
    <t hangText="Published specification:">This media type registration is extracted from the <eref target="http://www.w3.org/TR/WOFF2">WOFF 2.0 specification</eref> at W3C.</t>
  
    <t hangText="Applications that use this media type:">WOFF 2.0 is used by Web browsers, 
    often in conjunction with HTML and CSS.</t>
  
  <t hangText="Additional information:">
  
  <list style="hanging">
    <t hangText="Magic number(s):">The signature field in the WOFF header MUST contain the 
    "magic number" 0x774F4632 ('wOF2')</t>
    <t hangText="File extension(s):">woff2</t>
    <t hangText="Macintosh file type code(s):">(no code specified)</t>
    <t hangText="Macintosh Universal Type Identifier code:"><spanx style="verb">org.w3c.woff2</spanx> </t>
    <t hangText="@font-face Format:">woff2</t>
    <t hangText="Fragment Identifiers">none.</t>
  </list>
  </t>
  
    <t hangText="Person &amp; email address to contact for further information:">Chris Lilley (www-font@w3.org).</t>
  
    <t hangText="Intended usage:">COMMON</t>
  
    <t hangText="Restrictions on usage:">None</t>
  
    <t hangText="Author:">The WOFF2 specification is a work product of the World Wide Web 
    Consortium's WebFonts Working Group.</t>
  
    <t hangText="Change controller:">The W3C has change control over this specification.</t>
  
  </list>   
  </t>   

   </section>
   </section>
</middle>
    </rfc>