idnits 2.17.1 draft-freed-media-type-reg-05.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1061. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1074. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC2048, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (July 26, 2005) is 6811 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 2048 (Obsoleted by RFC 4288, RFC 4289) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft Sun Microsystems 4 Obsoletes: 2048 (if approved) J. Klensin 5 Expires: January 27, 2006 July 26, 2005 7 Media Type Specifications and Registration Procedures 8 draft-freed-media-type-reg-05 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document defines procedures for the specification and 42 registration of media types for use in MIME and other Internet 43 protocols. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 1.1 Conventions Used In This Document . . . . . . . . . . . . 4 49 2. Media Type Registration Preliminaries . . . . . . . . . . . . 5 50 3. Registration Trees and Subtype Names . . . . . . . . . . . . . 5 51 3.1 Standards Tree . . . . . . . . . . . . . . . . . . . . . . 5 52 3.2 Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.3 Personal or Vanity Tree . . . . . . . . . . . . . . . . . 6 54 3.4 Special x. Tree . . . . . . . . . . . . . . . . . . . . . 6 55 3.5 Additional Registration Trees . . . . . . . . . . . . . . 7 56 4. Registration Requirements . . . . . . . . . . . . . . . . . . 7 57 4.1 Functionality Requirement . . . . . . . . . . . . . . . . 7 58 4.2 Naming Requirements . . . . . . . . . . . . . . . . . . . 7 59 4.2.1 Text Media Types . . . . . . . . . . . . . . . . . . . 8 60 4.2.2 Image Media Types . . . . . . . . . . . . . . . . . . 9 61 4.2.3 Audio Media Types . . . . . . . . . . . . . . . . . . 9 62 4.2.4 Video Media Types . . . . . . . . . . . . . . . . . . 9 63 4.2.5 Application Media Types . . . . . . . . . . . . . . . 9 64 4.2.6 Multipart and Message Media Types . . . . . . . . . . 10 65 4.2.7 Additional Top-level Types . . . . . . . . . . . . . . 10 66 4.3 Parameter Requirements . . . . . . . . . . . . . . . . . . 10 67 4.4 Canonicalization and Format Requirements . . . . . . . . . 11 68 4.5 Interchange Recommendations . . . . . . . . . . . . . . . 12 69 4.6 Security Requirements . . . . . . . . . . . . . . . . . . 12 70 4.7 Requirements specific to XML media types . . . . . . . . . 13 71 4.8 Encoding Requirements . . . . . . . . . . . . . . . . . . 14 72 4.9 Usage and Implementation Non-requirements . . . . . . . . 14 73 4.10 Publication Requirements . . . . . . . . . . . . . . . . . 15 74 4.11 Additional Information . . . . . . . . . . . . . . . . . . 15 75 5. Registration Procedure . . . . . . . . . . . . . . . . . . . . 16 76 5.1 Preliminary Community Review . . . . . . . . . . . . . . . 16 77 5.2 IESG Approval . . . . . . . . . . . . . . . . . . . . . . 17 78 5.3 IANA Registration . . . . . . . . . . . . . . . . . . . . 17 79 5.4 Media Types Reviewer . . . . . . . . . . . . . . . . . . . 17 80 6. Comments on Media Type Registrations . . . . . . . . . . . . . 18 81 7. Location of Registered Media Type List . . . . . . . . . . . . 18 82 8. IANA Procedures for Registering Media Types . . . . . . . . . 18 83 9. Change Procedures . . . . . . . . . . . . . . . . . . . . . . 19 84 10. Registration Template . . . . . . . . . . . . . . . . . . . 20 85 11. Security Considerations . . . . . . . . . . . . . . . . . . 21 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 88 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 14.1 Normative References . . . . . . . . . . . . . . . . . . . 21 90 14.2 Informative References . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 92 A. Grandfathered Media Types . . . . . . . . . . . . . . . . . . 22 93 B. Changes made since RFC 2048 . . . . . . . . . . . . . . . . . 23 94 Intellectual Property and Copyright Statements . . . . . . . . 25 96 1. Introduction 98 Recent Internet protocols have been carefully designed to be easily 99 extensible in certain areas. In particular, many protocols, 100 including but not limited to MIME [RFC2045], are capable of carrying 101 arbitrary labelled content. A mechanism is needed to label such 102 content and a registration process is needed for these labels to 103 ensure that the set of such values is developed in an orderly, well- 104 specified, and public manner. 106 This document defines media type specification and registration 107 procedures which use the Internet Assigned Numbers Authority (IANA) 108 as a central registry. 110 Historical Note 112 The media types registration process was initially defined for the 113 purpose of registering media types for use in the context of the 114 asynchronous Internet mail environment. In this mail environment 115 there is a need to limit the number of possible media types to 116 increase the likelihood of interoperability when the capabilities of 117 the remote mail system are not known. As media types are used in new 118 environments, where the proliferation of media types is not a 119 hindrance to interoperability, the original procedure was excessively 120 restrictive and had to be generalized. This was initially done in 121 [RFC2048], but the procedure was still part of the MIME document set. 122 In this revision the media type specification and registration 123 procedure has been moved to this separate document to make it clear 124 it is independent of MIME. 126 It may be desirable to restrict the use of media types to specific 127 environments or to prohibit their use in other environments. This 128 revision attempts for the first time to incorporate such restrictions 129 into media type registrations in a systematic way. See Section 4.9 130 for additional discussion. 132 1.1 Conventions Used In This Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 This specification makes use of the Augmented Backus-Naur Form (ABNF) 139 [I-D.crocker-abnf-rfc2234bis] notation including the core rules 140 defined in Appendix A. 142 2. Media Type Registration Preliminaries 144 Registration of a new media type or types starts with the 145 construction of a registration proposal. Registration may occur in 146 several different registration trees, which have different 147 requirements as discussed below. In general, the new registration 148 proposal is circulated and reviewed in a fashion appropriate to the 149 tree involved. The media type is then registered if the proposal is 150 acceptable. The following sections describe the requirements and 151 procedures used for each of the different registration trees. 153 3. Registration Trees and Subtype Names 155 In order to increase the efficiency and flexibility of the 156 registration process, different structures of subtype names may be 157 registered to accommodate the different natural requirements for, 158 e.g., a subtype that will be recommended for wide support and 159 implementation by the Internet Community or a subtype that is used to 160 move files associated with proprietary software. The following 161 subsections define registration "trees", distinguished by the use of 162 faceted names (e.g., names of the form "tree.subtree...subtype"). 163 Note that some media types defined prior to this document do not 164 conform to the naming conventions described below. See Appendix A 165 for a discussion of them. 167 3.1 Standards Tree 169 The standards tree is intended for types of general interest to the 170 Internet Community. Registrations in the standards tree MUST be 171 approved by the IESG and MUST correspond to a formal publication by a 172 recognized standards body. In the case of registrations for the IETF 173 itself, the registration MUST be published as an RFC. Standards tree 174 registrations in RFCs can either be a standalone "registration only" 175 RFC or they can be incorporated into a more general specification of 176 some sort. 178 Media types in the standards tree are normally denoted by names that 179 are not explicitly faceted, i.e., do not contain period (".", full 180 stop) characters. 182 The "owner" of a media type registration in the standards tree is 183 assumed to be the standards body itself. Modification or alteration 184 of the specification requires the same level of processing (e.g., 185 standards track) required for the initial registration. 187 3.2 Vendor Tree 189 The vendor tree is used for media types associated with commercially 190 available products. "Vendor" or "producer" are construed as 191 equivalent and very broadly in this context. 193 A registration may be placed in the vendor tree by anyone who has 194 need to interchange files associated with the particular product. 195 However, the registration formally belongs to the vendor or 196 organization producing the software or file format. Changes to the 197 specification will be made at their request, as discussed in 198 subsequent sections. 200 Registrations in the vendor tree will be distinguished by the leading 201 facet "vnd.". That may be followed, at the discretion of the 202 registration, by either a media subtype name from a well-known 203 producer (e.g., "vnd.mudpie") or by an IANA-approved designation of 204 the producer's name which is then followed by a media type or product 205 designation (e.g., vnd.bigcompany.funnypictures). 207 While public exposure and review of media types to be registered in 208 the vendor tree is not required, using the ietf-types@iana.org 209 mailing list for review is strongly encouraged to improve the quality 210 of those specifications. Registrations in the vendor tree may be 211 submitted directly to the IANA. 213 3.3 Personal or Vanity Tree 215 Registrations for media types created experimentally or as part of 216 products that are not distributed commercially may be registered in 217 the personal or vanity tree. The registrations are distinguished by 218 the leading facet "prs.". 220 The owner of "personal" registrations and associated specifications 221 is the person or entity making the registration, or one to whom 222 responsibility has been transferred as described below. 224 While public exposure and review of media types to be registered in 225 the personal tree is not required, using the ietf-types list for 226 review is strongly encouraged to improve the quality of those 227 specifications. Registrations in the personal tree may be submitted 228 directly to the IANA. 230 3.4 Special x. Tree 232 For convenience and symmetry with this registration scheme, subtype 233 names with "x." as the first facet may be used for the same purposes 234 for which names starting in "x-" are normally used. These types are 235 unregistered, experimental, and should be used only with the active 236 agreement of the parties exchanging them. 238 However, with the simplified registration procedures described above 239 for vendor and personal trees, it should rarely, if ever, be 240 necessary to use unregistered experimental types, and as such use of 241 both "x-" and "x." forms is discouraged. 243 Types in this tree MUST NOT be registered. 245 3.5 Additional Registration Trees 247 From time to time and as required by the community, the IANA may, by 248 and with the advice and consent of the IESG, create new top-level 249 registration trees. It is explicitly assumed that these trees may be 250 created for external registration and management by well-known 251 permanent bodies, such as scientific societies for media types 252 specific to the sciences they cover. In general, the quality of 253 review of specifications for one of these additional registration 254 trees is expected to be equivalent to registrations in the standards 255 tree. Establishment of these new trees will be announced through RFC 256 publication approved by the IESG. 258 4. Registration Requirements 260 Media type registration proposals are all expected to conform to 261 various requirements laid out in the following sections. Note that 262 requirement specifics sometimes vary depending on the registration 263 tree, again as detailed in the following sections. 265 4.1 Functionality Requirement 267 Media types MUST function as an actual media format: Registration of 268 things that are better thought of as a transfer encoding, as a 269 charset, or as a collection of separate entities of another type, is 270 not allowed. For example, although applications exist to decode the 271 base64 transfer encoding [RFC2045], base64 cannot be registered as a 272 media type. 274 This requirement applies regardless of the registration tree 275 involved. 277 4.2 Naming Requirements 279 All registered media types MUST be assigned type and subtype names. 280 The combination of these names then serves to uniquely identify the 281 media type and the format of the subtype name identifies the 282 registration tree. Both type and subtype names are case-insensitive. 284 Type and subtype names beginning with "X-" are reserved for 285 experimental use and MUST NOT be registered. 287 Type and subtype names MUST conform to the following ABNF: 289 type-name = reg-name 290 subtype-name = reg-name 292 reg-name = 1*127reg-name-chars 293 reg-name-chars = ALPHA / DIGIT / "!" / 294 "#" / "$" / "&" / "." / 295 "+" / "-" / "^" / "_" 297 Note that this syntax is somewhat more restrictive that what the ABNF 298 in [RFC2045] allows. 300 In accordance with the rules specified in [RFC3023], media subtypes 301 that do not represent XML entities MUST NOT be given a name that ends 302 with the "+xml" suffix. More generally, use of "+suffix" constructs 303 should be done with care given the possibility of conflicts with 304 future suffix definitions. 306 While it is possible for a given media type to be assigned additional 307 names, the use of different names to identify the same media type is 308 discouraged. 310 These requirements all apply regardless of the registration tree 311 involved. 313 The choice of top-level type name MUST take the nature of media type 314 involved into account. New subtypes of top-level types MUST conform 315 to the restrictions of the top-level type, if any. The following 316 sections describe each of the initial set of top-level types and 317 their associated restrictions. Additionally, various protocols, 318 including but not limited to MIME, MAY impose additional restrictions 319 on the media types they can transport. (See [RFC2046] for additional 320 information on the restrictions MIME imposes.) 322 4.2.1 Text Media Types 324 The "text" media type is intended for sending material which is 325 principally textual in form. A "charset" parameter MAY be used to 326 indicate the charset of the body text for "text" subtypes, notably 327 including the subtype "text/plain", which is a generic subtype for 328 plain text defined in [RFC2046]. If defined, a text "charset" 329 parameter MUST be used to specify a charset name defined in 330 accordance to the procedures laid out in [RFC2978]. 332 Plain text does not provide for or allow formatting commands, font 333 attribute specifications, processing instructions, interpretation 334 directives, or content markup. Plain text is seen simply as a linear 335 sequence of characters, possibly interrupted by line breaks or page 336 breaks. Plain text MAY allow the stacking of several characters in 337 the same position in the text. Plain text in scripts like Arabic and 338 Hebrew may also include facilities that allow the arbitrary mixing of 339 text segments with opposite writing directions. 341 Beyond plain text, there are many formats for representing what might 342 be known as "rich text". An interesting characteristic of many such 343 representations is that they are to some extent readable even without 344 the software that interprets them. It is useful, then, to 345 distinguish them, at the highest level, from such unreadable data as 346 images, audio, or text represented in an unreadable form. In the 347 absence of appropriate interpretation software, it is reasonable to 348 present subtypes of "text" to the user, while it is not reasonable to 349 do so with most non textual data. Such formatted textual data should 350 be represented using subtypes of "text". 352 4.2.2 Image Media Types 354 A media type of "image" indicates that the content specifies or more 355 separate images which require appropriate hardware to display. The 356 subtype names the specific image format. 358 4.2.3 Audio Media Types 360 A media type of "audio" indicates that the content contains audio 361 data. 363 4.2.4 Video Media Types 365 A media type of "video" indicates that the content specifies a time- 366 varying-picture image, possibly with color and coordinated sound. 367 The term 'video' is used in its most generic sense, rather than with 368 reference to any particular technology or format, and is not meant to 369 preclude subtypes such as animated drawings encoded compactly. 371 Note that although in general this document strongly discourages the 372 mixing of multiple media in a single body, it is recognized that many 373 so-called video formats include a representation for synchronized 374 audio and/or text, and this is explicitly permitted for subtypes of 375 "video". 377 4.2.5 Application Media Types 379 The "application" media type is to be used for discrete data which do 380 not fit in any of the media types, and particularly for data to be 381 processed by some type of application program. This is information 382 which must be processed by an application before it is viewable or 383 usable by a user. Expected uses for the "application" media type 384 include but are not limited to file transfer, spreadsheets, 385 presentations, scheduling data, and languages for "active" 386 (computational) material. (The latter, in particular, can pose 387 security problems which must be understood by implementors, and are 388 considered in detail in the discussion of the "application/ 389 PostScript" media type in [RFC2046].) 391 For example, a meeting scheduler might define a standard 392 representation for information about proposed meeting dates. An 393 intelligent user agent would use this information to conduct a dialog 394 with the user, and might then send additional material based on that 395 dialog. More generally, there have been several "active" languages 396 developed in which programs in a suitably specialized language are 397 transported to a remote location and automatically run in the 398 recipient's environment. Such applications may be defined as 399 subtypes of the "application" media type. 401 The subtype of "application" will often be either the name or include 402 part of the name of the application for which the data are intended. 403 This does not mean, however, that any application program name may be 404 used freely as a subtype of "application". 406 4.2.6 Multipart and Message Media Types 408 Multipart and message are composite types, that is, they provide a 409 means of encapsulating zero or more objects, each labelled with its 410 own media type. 412 All subtypes of multipart and message MUST conform to the syntax 413 rules and other requirements specified in [RFC2046]. 415 4.2.7 Additional Top-level Types 417 In some cases a new media type may not "fit" under any currently 418 defined top-level content type. Such cases are expected to be quite 419 rare. However, if such a case does arise a new top-level type can be 420 defined to accommodate it. Such a definition MUST be done via 421 standards-track RFC; no other mechanism can be used to define 422 additional top-level content types. 424 4.3 Parameter Requirements 426 Media types MAY elect to use one or more media type parameters, or 427 some parameters may be automatically made available to the media type 428 by virtue of being a subtype of a content type that defines a set of 429 parameters applicable to any of its subtypes. In either case, the 430 names, values, and meanings of any parameters MUST be fully specified 431 when a media type is registered in the standards tree, and SHOULD be 432 specified as completely as possible when media types are registered 433 in the vendor or personal trees. 435 Parameter names have the syntax as media type names and values: 437 parameter-name = reg-name 439 Note that this syntax is somewhat more restrictive that what the ABNF 440 in [RFC2045] and amended by [RFC2231] allows. 442 There is no defined syntax for parameter values. Therefore 443 registrations MUST specify parameter value syntax. Additionally, 444 some transports impose restrictions on parameter value syntax, so 445 care should be taken to limit the use of potentially problematic 446 syntaxes; e.g., pure binary valued parameters, while permitted in 447 some protocols, probably should be avoided. 449 New parameters SHOULD NOT be defined as a way to introduce new 450 functionality in types registered in the standards tree, although new 451 parameters MAY be added to convey additional information that does 452 not otherwise change existing functionality. An example of this 453 would be a "revision" parameter to indicate a revision level of an 454 external specification such as JPEG. Similar behavior is encouraged 455 for media types registered in the vendor or personal trees but is not 456 required. 458 4.4 Canonicalization and Format Requirements 460 All registered media types MUST employ a single, canonical data 461 format, regardless of registration tree. 463 A precise and openly available specification of the format of each 464 media type MUST exist for all types registered in the standards tree 465 and MUST at a minimum be referenced by, if it isn't actually included 466 in, the media type registration proposal itself. 468 The specifications of format and processing particulars may or may 469 not be publicly available for media types registered in the vendor 470 tree, and such registration proposals are explicitly permitted to 471 limit specification to which software and version produce or process 472 such media types. References to or inclusion of format 473 specifications in registration proposals is encouraged but not 474 required. 476 Format specifications are still required for registration in the 477 personal tree, but may be either published as RFCs or otherwise 478 deposited with the IANA. The deposited specifications will meet the 479 same criteria as those required to register a well-known TCP port 480 and, in particular, need not be made public. 482 Some media types involve the use of patented technology. The 483 registration of media types involving patented technology is 484 specifically permitted. However, the restrictions set forth in 485 [RFC2026] on the use of patented technology in IETF standards-track 486 protocols must be respected when the specification of a media type is 487 part of a standards-track protocol. In addition, other standards 488 bodies making use of the standards tree may have their own rules 489 regarding intellectual property that must be observed in their 490 registrations. 492 4.5 Interchange Recommendations 494 Media types SHOULD interoperate across as many systems and 495 applications as possible. However, some media types will inevitably 496 have problems interoperating across different platforms. Problems 497 with different versions, byte ordering, and specifics of gateway 498 handling can and will arise. 500 Universal interoperability of media types is not required, but known 501 interoperability issues SHOULD be identified whenever possible. 502 Publication of a media type does not require an exhaustive review of 503 interoperability, and the interoperability considerations section is 504 subject to continuing evaluation. 506 These recommendations apply regardless of the registration tree 507 involved. 509 4.6 Security Requirements 511 An analysis of security issues MUST be done for all types registered 512 in the standards Tree. A similar analysis for media types registered 513 in the vendor or personal trees is encouraged but not required. 514 However, regardless of what security analysis has or has not been 515 done, all descriptions of security issues MUST be as accurate as 516 possible regardless of registration tree. In particular, a statement 517 that there are "no security issues associated with this type" MUST 518 NOT be confused with "the security issues associates with this type 519 have not been assessed". 521 There is absolutely no requirement that media types registered in any 522 tree be secure or completely free from risks. Nevertheless, all 523 known security risks MUST be identified in the registration of a 524 media type, again regardless of registration tree. 526 The security considerations section of all registrations is subject 527 to continuing evaluation and modification, and in particular MAY be 528 extended by use of the "comments on media types" mechanism described 529 in Section 6 below. 531 Some of the issues that should be looked at in a security analysis of 532 a media type are: 534 o Complex media types may include provisions for directives that 535 institute actions on a recipient's files or other resources. In 536 many cases provision is made for originators to specify arbitrary 537 actions in an unrestricted fashion which may then have devastating 538 effects. See the registration of the application/postscript media 539 type in [RFC2046] for an example of such directives and how they 540 should be described in a media type registration. 542 o All registrations MUST state whether or not they employ such 543 "active content", and if they do, they MUST state what steps have 544 been taken to protect users of the media type from harm. 546 o Complex media types may include provisions for directives that 547 institute actions which, while not directly harmful to the 548 recipient, may result in disclosure of information that either 549 facilitates a subsequent attack or else violates a recipient's 550 privacy in some way. Again, the registration of the application/ 551 postscript media type illustrates how such directives can be 552 handled. 554 o A media type which employs compression may provide an opportunity 555 for sending a small amount of data which, when received and 556 evaluated, expands enormously to consume all of the recipient's 557 resources. All media types SHOULD state whether or not they 558 employ compression, and if they do they should discuss what steps 559 need to be taken to avoid such attacks. 561 o A media type might be targeted for applications that require some 562 sort of security assurance but not provide the necessary security 563 mechanisms themselves. For example, a media type could be defined 564 for storage of confidential medical information which in turn 565 requires an external confidentiality service, or which is designed 566 for use only within a secure environment. 568 4.7 Requirements specific to XML media types 570 There are a number of additional requirements specific to the 571 registration of XML media types. These requirements are specified in 572 [RFC3023]. 574 4.8 Encoding Requirements 576 Some transports impose restrictions on the type of data they can 577 carry. For example, Internet mail traditionally was limited to 7bit 578 US-ASCII text. Encoding schemes are often used to work around such 579 transport limitations. 581 It is therefore useful to note what sort of data a media type can 582 consist of as part of its registration. An "encoding considerations" 583 field is provided for this purpose. Possible values of this field 584 are: 586 7bit The content of the media type consists solely of CRLF delimited 587 7bit US-ASCII text. 589 8bit The content of the media type consists solely of CRLF delimited 590 8bit text. 592 binary The content consists of unrestricted sequence of octets. 594 framed The content consists of a series of frames or packets without 595 internal framing or alignment indicators. Additional out of band 596 information is needed to interpret the data properly, including 597 but not necessarily limited to knowledge of the boundaries between 598 successive frames and knowledge of the transport mechanism. Note 599 that media types of this sort cannot simply be stored in a file or 600 transported as a simple stream of octets, and therefore such media 601 types are unsuitable for use in many traditional protocols. A 602 commonly used transport with framed encoding is the Real-time 603 Transport Protocol, RTP. Additional rules for framed encodings 604 defined for transport using RTP are given in [RFC3555]. 606 Additional restrictions on 7bit and 8bit are given in [RFC2046]. 608 4.9 Usage and Implementation Non-requirements 610 In the asynchronous mail environment, where information on the 611 capabilities of the remote mail agent is frequently not available to 612 the sender, maximum interoperability is attained by restricting the 613 number of media types used to those "common" formats expected to be 614 widely implemented. This was asserted in the past as a reason to 615 limit the number of possible media types and resulted in a 616 registration process with a significant hurdle and delay for those 617 registering media types. 619 However, the need for "common" media types does not require limiting 620 the registration of new media types. If a limited set of media types 621 is recommended for a particular application, that should be asserted 622 by a separate applicability statement specific for the application 623 and/or environment. 625 As such, universal support and implementation of a media type is NOT 626 a requirement for registration. If, however, a media type is 627 explicitly intended for limited use, this MUST be noted in its 628 registration. The "Restrictions on Usage" field is provided for this 629 purpose. 631 4.10 Publication Requirements 633 Proposals for media types registered in the standards tree by the 634 IETF itself MUST be published as RFCs. RFC publication of vendor and 635 personal media type proposals is encouraged but not required. In all 636 cases the IANA will retain copies of all media type proposals and 637 "publish" them as part of the media types registration tree itself. 639 As stated previously, standards tree registrations for media types 640 defined in documents produced by other standards bodies MUST be 641 described by a formal standards specification produced by that body. 642 Such specifications MUST contain an appropriate media type 643 registration template taken from Section 10. Additionally, the 644 copyright on the registration template MUST allow the IANA to copy it 645 into the IANA registry. 647 Other than IETF registrations in the standards tree, the registration 648 of a data type does not imply endorsement, approval, or 649 recommendation by the IANA or the IETF or even certification that the 650 specification is adequate. To become Internet Standards, protocol, 651 data objects, or whatever must go through the IETF standards process. 652 This is too difficult and too lengthy a process for the convenient 653 registration of media types. 655 The standards tree exists for media types that do require a 656 substantive review and approval process in a recognized standards 657 body. The vendor and personal trees exist for those media types that 658 do not require such a process. It is expected that applicability 659 statements for particular applications will be published from time to 660 time in the IETF that recommend implementation of, and support for, 661 media types that have proven particularly useful in those contexts. 663 As discussed above, registration of a top-level type requires 664 standards-track processing in the IETF and, hence, RFC publication. 666 4.11 Additional Information 668 Various sorts of optional information SHOULD be included in the 669 specification of a media type if it is available: 671 o Magic number(s) (length, octet values). Magic numbers are byte 672 sequences that are always present at a given place in the file and 673 thus can be used to identify entities as being of a given media 674 type. 676 o File extension(s) commonly used on one or more platforms to 677 indicate that some file containing a given type of media. 679 o Mac OS File Type code(s) (4 octets) used to label files containing 680 a given type of media. 682 o Information about how fragment/anchor identifiers [RFC3986] are 683 constructed for use in conjunction with this media type. 685 In the case of a registration in the standards tree this additional 686 information MAY be provided in the formal specification of the media 687 type. It is suggested that this be done by incorporating the IANA 688 media type registration form into the specification itself. 690 5. Registration Procedure 692 The media type registration procedure is not a formal standards 693 process, but rather an administrative procedure intended to allow 694 community comment and sanity checking without excessive time delay. 696 The normal IETF processes should be followed for all IETF 697 registrations in the standards tree, with the posting of an internet- 698 draft being a necessary first step, followed by posting to the 699 ietf-types@iana.org list, as discussed below. 701 Registrations in the vendor and personal tree should be submitted 702 directly to the IANA, ideally after first posting to the 703 ietf-types@iana.org list for review. 705 Proposed registrations in the standards tree by other standards 706 bodies should be communicated to the IESG (at iesg@ietf.org) and to 707 the ietf-types list (at ietf-types@iana.org). Prior posting as an 708 internet-draft is not required for these registrations, but may be 709 helpful to the IESG and is encouraged. 711 5.1 Preliminary Community Review 713 Notice of a potential media type registration in the standards tree 714 MUST be sent to the "ietf-types@iana.org" mailing list for review. 715 This mailing list has been established for the purpose of reviewing 716 proposed media and access types. Registrations in other trees MAY be 717 sent to the list for review as well. 719 The intent of the public posting to this list is to solicit comments 720 and feedback on the choice of type/subtype name, the unambiguity of 721 the references with respect to versions and external profiling 722 information, and a review of any interoperability or security 723 considerations. The submitter may submit a revised registration, or 724 abandon the registration completely, at any time. 726 5.2 IESG Approval 728 Media types registered in the standards tree MUST be approved by the 729 IESG prior to registration. 731 5.3 IANA Registration 733 Provided that the media type meets all of the relevant requirements 734 and has obtained whatever approval is necessary, the author may 735 submit the registration request to the IANA. Registration requests 736 can be sent to iana@iana.org. A web form for registration requests 737 is also available: 739 http://www.iana.org/cgi-bin/mediatypes.pl 741 Sending to ietf-types@iana.org does not constitute submitting the 742 registration to the IANA. 744 When the registration is either part of an RFC publication request or 745 a registration in the standards tree submitted to the IESG, close 746 coordination between the IANA and the IESG means IESG approval in 747 effect submits the registration to the IANA. There is no need for an 748 additional registration request in such cases. 750 5.4 Media Types Reviewer 752 Registrations submitted to the IANA will be passed on to the media 753 types reviewer. The media types reviewer, who is appointed by the 754 IETF Applications Area Director(s), will review the registration to 755 make sure it meets the requirements set forth in this document. 756 Registrations which do not meet these requirements will be returned 757 to the submitter for revision. 759 Decisions made by the media types reviewer may be appealed to the 760 IESG using the procedure specified in [RFC2026] section 6.5.4. 762 Once a media type registration has passed review the IANA will 763 register the media type and make the media type registration 764 available to the community. 766 6. Comments on Media Type Registrations 768 Comments on registered media types may be submitted by members of the 769 community to the IANA. These comments will be reviewed by the media 770 types reviewer and then passed on to the "owner" of the media type if 771 possible. Submitters of comments may request that their comment be 772 attached to the media type registration itself, and if the IANA 773 approves of this the comment will be made accessible in conjunction 774 with the type registration itself. 776 7. Location of Registered Media Type List 778 Media type registrations are listed by the IANA at: 780 http://www.iana.org/assignments/media-types/ 782 8. IANA Procedures for Registering Media Types 784 The IANA will only register media types in the standards tree in 785 response to a communication from the IESG stating that a given 786 registration has been approved. Vendor and personal types will be 787 registered by the IANA automatically and without any formal approval 788 process as long as the following minimal conditions are met: 790 o Media types MUST function as an actual media format. In 791 particular, charsets and transfer encodings MUST NOT be registered 792 as media types. 794 o All media types MUST have properly formed type and subtype names. 795 All type names MUST be defined by a standards-track RFC. All 796 type/subtype name pairs MUST be unique and MUST contain the proper 797 tree prefix. 799 o Types registered in the personal tree MUST either provide a format 800 specification or a pointer to one. 802 o All media types MUST have a reasonable security considerations 803 section. (It is neither possible nor necessary for the IANA to 804 conduct a comprehensive security review of media type 805 registrations. Nevertheless, the IANA has the authority to 806 identify obviously incompetent material and return it to the 807 submitter for revision.) 809 Registrations in the standards tree MUST satisfy the additional 810 requirement that they originate from the IETF itself or from another 811 standards body recognized as such by the IETF. 813 9. Change Procedures 815 Once a media type has been published by the IANA, the owner may 816 request a change to its definition. The descriptions of the 817 different registration trees above designate the "owners" of each 818 type of registration. The same procedure as would be appropriate for 819 the original registration request is used to process a change 820 request. 822 Changes should be requested only when there are serious omissions or 823 errors in the published specification. When review is required, a 824 change request may be denied if it renders entities that were valid 825 under the previous definition invalid under the new definition. 827 The owner of a media type may pass responsibility to another person 828 or agency by informing the IANA and the ietf-types list; this can be 829 done without discussion or review. 831 The IESG may reassign responsibility for a media type. The most 832 common case of this will be to enable changes to be made to types 833 where the author of the registration has died, moved out of contact 834 or is otherwise unable to make changes that are important to the 835 community. 837 Media type registrations may not be deleted; media types which are no 838 longer believed appropriate for use can be declared OBSOLETE by a 839 change to their "intended use" field; such media types will be 840 clearly marked in the lists published by the IANA. 842 10. Registration Template 844 To: ietf-types@iana.org 845 Subject: Registration of media type XXX/YYY 847 Type name: 849 Subtype name: 851 Required parameters: 853 Optional parameters: 855 Encoding considerations: 857 Security considerations: 859 Interoperability considerations: 861 Published specification: 863 Applications which use this media type: 865 Additional information: 867 Magic number(s): 868 File extension(s): 869 Macintosh file type code(s): 871 Person & email address to contact for further information: 873 Intended usage: 875 (One of COMMON, LIMITED USE or OBSOLETE.) 877 Restrictions on usage: 879 (Any restrictions on where the media type can be used go here.) 881 Author: 883 Change controller: 885 (Any other information that the author deems interesting may be 886 added below this line.) 888 Some discussion of Macintosh file type codes, their purpose can be 889 found in [MacOSFileTypes]. Additionally, please refrain from writing 890 "none" or anything similar when no file extension or Macintosh file 891 type is specified, lest "none" be confused with an actual code value. 893 11. Security Considerations 895 Security requirements for media type registrations are discussed in 896 Section 4.6. 898 12. IANA Considerations 900 The purpose of this document is to define IANA registries for media 901 types. 903 13. Acknowledgments 905 The current authors would like to acknowledge their debt to the late 906 Dr. Jon Postel, whose general model of IANA registration procedures 907 and specific contributions shaped the predecessors of this document. 908 We hope that the current version is one with which he would have 909 agreed but, since it is impossible to verify that agreement, we have 910 regretfully removed his name as a co-author. 912 14. References 914 14.1 Normative References 916 [I-D.crocker-abnf-rfc2234bis] 917 Crocker, D. and P. Overell, "Augmented BNF for Syntax 918 Specifications: ABNF", draft-crocker-abnf-rfc2234bis-00 919 (work in progress), March 2005, . 922 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 923 Extensions (MIME) Part One: Format of Internet Message 924 Bodies", RFC 2045, November 1996. 926 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 927 Extensions (MIME) Part Two: Media Types", RFC 2046, 928 November 1996. 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, March 1997. 933 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 934 Procedures", BCP 19, RFC 2978, October 2000. 936 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 937 Types", RFC 3023, January 2001. 939 [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP 940 Payload Formats", RFC 3555, July 2003. 942 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 943 Resource Identifier (URI): Generic Syntax", STD 66, 944 RFC 3986, January 2005. 946 14.2 Informative References 948 [MacOSFileTypes] 949 Apple Computer, Inc., "Mac OS: File Type and Creator 950 Codes, and File Formats", Apple Knowledge Base Article 951 55381, June 1993, 952 . 954 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 955 3", BCP 9, RFC 2026, October 1996. 957 [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose 958 Internet Mail Extensions (MIME) Part Four: Registration 959 Procedures", BCP 13, RFC 2048, November 1996. 961 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 962 Word Extensions: Character Sets, Languages, and 963 Continuations", RFC 2231, November 1997. 965 Authors' Addresses 967 Ned Freed 968 Sun Microsystems 969 3401 Centrelake Drive, Suite 410 970 Ontario, CA 92761-1205 971 USA 973 Phone: +1 909 457 4293 974 Email: ned.freed@mrochek.com 976 John C Klensin 977 1770 Massachusetts Ave, #322 978 Cambridge, MA 02140 980 Email: klensin@jck.com 982 Appendix A. Grandfathered Media Types 984 A number of media types, registered prior to 1996, would, if 985 registered under the guidelines in this document, be placed into 986 either the vendor or personal trees. Reregistration of those types 987 to reflect the appropriate trees is encouraged, but not required. 988 Ownership and change control principles outlined in this document 989 apply to those types as if they had been registered in the trees 990 described above. 992 Appendix B. Changes made since RFC 2048 994 o Media type specification and registration procedures have been 995 moved out of the MIME document set to this separate specification. 997 o The various URLs and addresses in this document have been changed 998 so they all refer to iana.org rather than isi.edu. Additionally, 999 many of the URLs have been changed to use HTTP; formerly they used 1000 FTP. 1002 o Much of the document has been clarified in the light of 1003 operational experience with these procedures. 1005 o The unfaceted IETF tree is now called the standards tree and the 1006 registration rules for this tree have been relaxed to allow use by 1007 other standards bodies. 1009 o The text describing the media type registration procedure has 1010 clarified. 1012 o The rules and requirements for constructing security 1013 considerations sections have been extended and clarified. 1015 o RFC 3023 is now referenced as the source of additional information 1016 concerning the registration of XML media types. 1018 o Several of the references in this document have been updated to 1019 refer to current versions of the relevant specifications. 1021 o A note has been added discouraging the assignment of multiple 1022 names to a single media type. 1024 o Security considerations and IANA considerations sections have been 1025 added. 1027 o Concerns regarding copyrights on media type registration templates 1028 produced by other standards bodies have been dealt with by 1029 requiring that the IANA be allowed to copy the registration 1030 template into the registry. 1032 o The basic registration requirements for the various top-level 1033 types have been moved from RFC 2046 to this document. 1035 o A syntax is now specified for media type, subtype, and parameter 1036 names. 1038 o Imposed a maximum length of 127 on all media type and subtype 1039 names. 1041 o Added a note cautioning against excessive use of "+suffix" 1042 constructs in subtype names. 1044 o The encoding considerations field has been extended to allow the 1045 value "framed". 1047 o Added reference describing Macintosh Type codes. 1049 o Ietf-types list review of registrations in the standards tree is 1050 now required rather than just being recommended. 1052 Intellectual Property Statement 1054 The IETF takes no position regarding the validity or scope of any 1055 Intellectual Property Rights or other rights that might be claimed to 1056 pertain to the implementation or use of the technology described in 1057 this document or the extent to which any license under such rights 1058 might or might not be available; nor does it represent that it has 1059 made any independent effort to identify any such rights. Information 1060 on the procedures with respect to rights in RFC documents can be 1061 found in BCP 78 and BCP 79. 1063 Copies of IPR disclosures made to the IETF Secretariat and any 1064 assurances of licenses to be made available, or the result of an 1065 attempt made to obtain a general license or permission for the use of 1066 such proprietary rights by implementers or users of this 1067 specification can be obtained from the IETF on-line IPR repository at 1068 http://www.ietf.org/ipr. 1070 The IETF invites any interested party to bring to its attention any 1071 copyrights, patents or patent applications, or other proprietary 1072 rights that may cover technology that may be required to implement 1073 this standard. Please address the information to the IETF at 1074 ietf-ipr@ietf.org. 1076 Disclaimer of Validity 1078 This document and the information contained herein are provided on an 1079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1081 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1082 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1083 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1086 Copyright Statement 1088 Copyright (C) The Internet Society (2005). This document is subject 1089 to the rights, licenses and restrictions contained in BCP 78, and 1090 except as set forth therein, the authors retain all their rights. 1092 Acknowledgment 1094 Funding for the RFC Editor function is currently provided by the 1095 Internet Society.