idnits 2.17.1 draft-singer-font-mime-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 314. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 306), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 51. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 186 has weird spacing: '... values or Un...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ISO-JPEG2000-1' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'MIME1' is defined on line 367, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-JPEG2000-1' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 INTERNET-DRAFT D. Singer 4 draft-singer-font-mime-00.doc Apple Computer 6 G. Adams 7 XFSI 9 Oct 14 2004 10 Expires: Apr 14 2005 12 The Font Primary Content Type for 13 Multipurpose Internet Mail Extensions 15 IPR Notice 17 By submitting this Internet-Draft, I certify that any applicable patent 18 or other IPR claims of which I am aware have been disclosed, or will be 19 disclosed, and any of which I become aware will be disclosed, in 20 accordance with RFC 3668. 22 Status of This Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than a "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119. 47 Distribution of this document is unlimited. 49 Copyright Notice 51 Copyright (C) The Internet Society (2004). All Rights Reserved. 53 PostScript, OpenType, and TrueType are registered trademarks of Adobe 54 Systems. Inc., Microsoft Corp., and Apple Computer Inc., 55 respectively. 57 Abstract 59 This document serves to register and document the top-level MIME type 60 for fonts, under which the representation formats for fonts may be 61 registered. It also registers some specific font types under that 62 top-level type. 64 1 Introduction 66 The process of setting type in computer systems and other forms of 67 text presentation systems uses fonts in order to provide visual 68 representations of the glyphs. Just as with images, for example, 69 there are a number of ways to represent the visual information of the 70 glyphs. Early formats often used bitmaps, as these could be 71 carefully tuned for maximum readability at a given size, and the 72 displays were often 1-bit deep only. More recently, outline fonts 73 have come into use: in these fonts, the outlines of the glyphs are 74 described, and the presentation system renders the outline in the 75 desired position and size. 77 This document defines a top-level MIME type "font" under which 78 differing representation formats of fonts may be registered (e.g. a 79 bitmap or outline format). It should be emphasized that, just as 80 under the "image" top-level type one does not find registration for, 81 for example, "The Night-watch" (by Rembrandt) but instead "JPEG" (an 82 image representation system), so, under "font" one will not find 83 "Courier" (the name of a popular font) but perhaps "BDF" (the name of 84 a commonly used bitmap font format). 86 Historically there has not been a registration of formats for fonts. 87 Currently there is only one font representation format registered in 88 MIME, and that is under the "application" top-level type. However, 89 the use of this top-level type is not ideal. First, the 90 "application" sub-tree is treated (correctly) with great caution with 91 respect to viruses and other active code. Secondly, the lack of a 92 top-level type means that there is no opportunity to have a common 93 set of optional attributes, such as are specified here. Third, fonts 94 have a unique set of licensing and usage restrictions, which makes it 95 worthwhile to identify this general category with a unique top-level 96 type. 98 2 Security Considerations 100 Fonts are interpreted data structures. 102 Fonts may contain 'hints' for the alignment of visual aspects of the 103 glyphs with the display, and these hints may appear to be active 104 code. However, they operate within the confines of the glyph outline 105 conversion system and have no access outside the font rendering 106 machinery. 108 Fonts can be, however, quite complex, and a maliciously designed 109 complex font could cause undue resource consumption (e.g. memory or 110 CPU cycles) on a machine interpreting it. This is the case for many 111 formats however. Indeed, fonts are sufficiently complex that most if 112 not all interpreters cannot be completely protected from malicious 113 fonts without undue performance penalties. 115 Fonts are often licensed and that license may place restrictions on 116 the transmission of all or part of the font. It is outside the scope 117 of this specification to mandate any particular behavior, but the 118 authors of MIME registrations under the 'font' top-level type SHOULD 119 at the very least also mention the licensing considerations for the 120 transmission of fonts. 122 3 Definition 124 3.1 Encoding 126 Unrecognized sub-types of "font" should be treated as 127 "application/octet-stream". Implementations may pass unrecognized 128 sub-types to a common font-handling system, if any. 130 Different subtypes of font may be encoded as textual representations 131 or as binary data. Unless noted in the subtype registration, subtypes 132 of font should be assumed to contain binary data, implying a content 133 encoding of base64 for email and binary transfer for ftp and http. 135 3.1 Common Parameters 137 The following two parameters may be supplied for any registration 138 under the "font" top-level type unless specifically disallowed by the 139 registration of that format. 141 It might be thought desirable to have a sub-parameter for the glyph 142 coverage of a font, but there is no known method that gives an 143 adequate summary of the coverage in an exact enough form to be 144 useful. This specification does not, therefore, define any such 145 parameter. However, the authors are investigating whether the 146 Unicode sets as defined at < 147 http://www.unicode.org/reports/tr35/#Unicode_Sets> could meet this 148 need. 150 These parameters are informative and typically duplicate information 151 found in the font itself. For interpreting the font file, the 152 information within the file is definitive and over-rides any of these 153 parameters. These parameters can be used to determine whether a font 154 can or should be opened, for example. The parameters SHOULD 155 correspond to what is in the file. 157 font-name="string" 159 This is the reference name for the font; a non-localized name that 160 is used to refer to it. In many fonts (even those not using 161 PostScript), this is the called "the postscript name". (e.g. 162 "Courier"). 164 font-size="integer" 166 If a font is designed for use at a particular size (e.g. a bitmap 167 font), then this parameter is used to indicate the intended display 168 size. The value of the parameter is the nominal 'design size' of the 169 font, in pixels (e.g. a font designed for a nominal display size of 170 10 points on a display with 1 pixel per point would report the value 171 "10" here). This parameter is normally only used for fonts such as a 172 single-size bitmap font, designed for use at one size only. 174 subformat="string" 176 For font containers that allow multiple representations, and 177 therefore could require different font machinery, this identifies the 178 format needed, from an enumerated set defined in this specification 179 or specifications of specific formats under the "font/" node. This 180 specification defines "truetype" and "postscript" as possible values 181 for this parameter. 183 unicode="boolean" 185 The value of this parameter indicates whether the font supports a 186 mapping from Unicode scalar values or Unicode encoding form to 187 specific glyph(s); it takes the value "true" or "false". 189 4 Defined and Expected Sub-types 190 In this section the initial entries under the top-level 'font' MIME 191 type are documented. They also serve as examples for future 192 registrations. 194 Note that Macintosh operating systems are not particular about the 195 file-type code used for fonts, and that it is correct that the two 196 overlapping formats registered here use the same file type. 198 4.1 OpenType 200 The font/opentype content-type refers fonts that conform to the 201 OpenType specification. OpenType fonts are a special case of SFNT 202 fonts, which have a separate MIME type. The specific OpenType MIME 203 type is preferred when the fact that it is an OpenType font is 204 salient to the application or usage, and when the originating system 205 can reasonably determine that a font is a valid OpenType font. 207 To: ietf-types@iana.org 208 Subject: Registration of Standard MIME media type font/opentype 210 MIME media type name: font 211 MIME subtype name: opentype 212 Required parameters: none 213 Optional parameters: any of the common parameters for 214 'font' may be used, as documented in 215 RFC XXXX 216 Encoding considerations: files are binary and should be 217 transmitted in a suitable encoding 218 without CR/LF conversion, 7-bit 219 stripping etc.; base64 is a suitable 220 encoding; 221 Security considerations: see the security considerations 222 section in RFC XXXX 223 Interoperability considerations: OpenType fonts should ... 224 Published specification: 225 http://www.microsoft.com/typography/otspec/default.htm 226 Applications which use this media type: Messaging and multi-media 227 Additional information: 228 Magic number(s): no true magic number, but currently 229 files start with a 32-bit field, 230 which contains either 0x00010000 or 231 'OTTO' 232 File extension(s): "otf" is the common extension used; 233 "ttf" may be used for OpenType fonts 234 containing TrueType outlines, "ttc" 235 is used for TrueType Collections 236 fonts 237 Macintosh File Type Code(s): sfnt may be used but is not required 238 Person & email address to contact for further information: 239 ???: ???@???.com 240 Intended usage: COMMON 241 Change controller: ???: ???@???.com 243 4.2 Sfnt 245 The font/sfnt content-type refers fonts that are contained within an 246 'sfnt' (scalable font) container, but that are not necessarily 247 OpenType. (OpenType fonts also use this container format, but there 248 is a substantial body of fonts using the container format that are 249 not OpenType fonts). 251 To: ietf-types@iana.org 252 Subject: Registration of Standard MIME media type font/sfnt 254 MIME media type name: font 255 MIME subtype name: sfnt 256 Required parameters: none 257 Optional parameters: any of the common parameters for 258 'font' may be used, as documented in 259 RFC XXXX 260 Encoding considerations: files are binary and should be 261 transmitted in a suitable encoding 262 without CR/LF conversion, 7-bit 263 stripping etc.; base64 is a suitable 264 encoding; 265 Security considerations: see the security considerations 266 section in RFC XXXX 267 Interoperability considerations: Sfnt fonts may contain a variety of 268 tables, some or all of which may be 269 vendor-specific or otherwise non- 270 standard. The SFNT structure does 271 not require any specific set of 272 tables, though there are tables in 273 common use. Interoperability is not 274 assured. 275 Published specification: 276 http://developer.apple.com/fonts/TTRefMan/ 277 Applications which use this media type: Messaging and multi-media 278 Additional information: 279 Magic number(s): no true magic number, but currently 280 files start with a 32-bit field, 281 which contains either 0x00010000, or 282 'OTTO', or 'true' or 'typ1' 283 File extension(s): "ttf" is a common extension used, for 284 sfnt-housed TrueType fonts 286 Macintosh File Type Code(s): sfnt may be used but is not required 287 Person & email address to contact for further information: 288 ???: ???@???.com 289 Intended usage: COMMON 290 Change controller: ???: ???@???.com 292 5 IANA Considerations 294 This document registers the top-level MIME type "font", and the 295 "opentype" font type under "font". 297 6 RFC Editor Considerations 299 The references to RFC XXXX in the MIME registrations need to be 300 replaced with the actual RFC number when it is issued. 302 7 Full Copyright Statement 304 Copyright (C) The Internet Society (2004). This document is subject 305 to the rights, licenses and restrictions contained in BCP 78, and 306 except as set forth therein, the authors retain all their rights. 308 This document and the information contained herein are provided on an 309 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 310 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 311 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 312 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 313 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 314 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 316 8 Intellectual Property Notice 318 The IETF takes no position regarding the validity or scope of any 319 intellectual property or other rights that might be claimed to 320 pertain to the implementation or use of the technology described in 321 this document or the extent to which any license under such rights 322 might or might not be available; neither does it represent that it 323 has made any effort to identify any such rights. Information on the 324 IETF's procedures with respect to rights in standards-track and 325 standards-related documentation can be found in BCP-11. Copies of 326 claims of rights made available for publication and any assurances of 327 licenses to be made available, or the result of an attempt made to 328 obtain a general license or permission for the use of such 329 proprietary rights by implementers or users of this specification can 330 be obtained from the IETF Secretariat. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary 334 rights which may cover technology that may be required to practice 335 this standard. Please address the information to the IETF Executive 336 Director. 338 Acknowledgments 340 The initial review by the W3C Timed Text group, and type experts, is 341 gratefully acknowledged. 343 Authors' Contact Information 344 David Singer 345 Apple Computer, Inc. 346 One Infinite Loop, MS:302-3MT 347 Cupertino CA 95014 348 USA 349 Email: singer@apple.com 350 Tel: +1 408 974 3162 352 Glenn Adams 353 Extensible Formatting Systems, Inc. (XFSI) 354 114 Mount Auburn St, 4th Floor 355 Cambridge, MA 02138 356 USA 357 Tel: +1 617 864-0005 358 Fax: +1 617 864-0006 359 Email: gadams@xfsi.com 361 6. References 362 [ISO-JPEG2000-1] 363 ITU-T Recommendation T.800 | ISO/IEC 15444-1. International 364 Organization for Standardization, "JPEG 2000 Image Coding System: 365 Core Coding System". 367 [MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 368 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 369 2045, November 1996. 371 Dates 372 Written: Oct 14 2004 373 Expires: Apr 14 2005