idnits 2.17.1 draft-freed-mime-p4-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 (September 20, 2003) is 7518 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) == Unused Reference: 'RFC2048' is defined on line 1014, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) -- Obsolete informational reference (is this intentional?): RFC 2048 (Obsoleted by RFC 4288, RFC 4289) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: March 20, 2004 September 20, 2003 7 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration 8 Procedures 9 draft-freed-mime-p4-03.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 20, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 This document specifies various IANA registration procedures for the 41 following MIME facilities: 43 o media types, 45 o external body access types, and 47 o content-transfer-encodings. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 52 2. Conventions Used In This Document . . . . . . . . . . . . 5 53 3. Media Type Registration . . . . . . . . . . . . . . . . . 6 54 3.1 Registration Trees and Subtype Names . . . . . . . . . . . 6 55 3.1.1 Standards Tree . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1.2 Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1.3 Personal or Vanity Tree . . . . . . . . . . . . . . . . . 7 58 3.1.4 Special x. Tree . . . . . . . . . . . . . . . . . . . . . 7 59 3.1.5 Additional Registration Trees . . . . . . . . . . . . . . 8 60 3.2 Registration Requirements . . . . . . . . . . . . . . . . 8 61 3.2.1 Functionality Requirement . . . . . . . . . . . . . . . . 8 62 3.2.2 Naming Requirements . . . . . . . . . . . . . . . . . . . 8 63 3.2.3 Parameter Requirements . . . . . . . . . . . . . . . . . . 9 64 3.2.4 Canonicalization and Format Requirements . . . . . . . . . 10 65 3.2.5 Interchange Recommendations . . . . . . . . . . . . . . . 10 66 3.2.6 Security Requirements . . . . . . . . . . . . . . . . . . 11 67 3.2.7 Requirements specific to XML media types . . . . . . . . . 12 68 3.2.8 Usage and Implementation Non-requirements . . . . . . . . 12 69 3.2.9 Publication Requirements . . . . . . . . . . . . . . . . . 12 70 3.2.10 Additional Information . . . . . . . . . . . . . . . . . . 13 71 3.3 Registration Procedure . . . . . . . . . . . . . . . . . . 14 72 3.3.1 Preliminary Community Review . . . . . . . . . . . . . . . 14 73 3.3.2 IESG Approval . . . . . . . . . . . . . . . . . . . . . . 14 74 3.3.3 IANA Registration . . . . . . . . . . . . . . . . . . . . 14 75 3.3.4 Media Types Reviewer . . . . . . . . . . . . . . . . . . . 15 76 3.4 Comments on Media Type Registrations . . . . . . . . . . . 15 77 3.5 Location of Registered Media Type List . . . . . . . . . . 15 78 3.6 IANA Procedures for Registering Media Types . . . . . . . 15 79 3.7 Change Procedures . . . . . . . . . . . . . . . . . . . . 16 80 3.8 Registration Template . . . . . . . . . . . . . . . . . . 17 81 4. External Body Access Types . . . . . . . . . . . . . . . . 18 82 4.1 Registration Requirements . . . . . . . . . . . . . . . . 18 83 4.1.1 Naming Requirements . . . . . . . . . . . . . . . . . . . 18 84 4.1.2 Mechanism Specification Requirements . . . . . . . . . . . 18 85 4.1.3 Publication Requirements . . . . . . . . . . . . . . . . . 18 86 4.1.4 Security Requirements . . . . . . . . . . . . . . . . . . 18 87 4.2 Registration Procedure . . . . . . . . . . . . . . . . . . 19 88 4.2.1 Present the Access Type to the Community . . . . . . . . . 19 89 4.2.2 Access Type Reviewer . . . . . . . . . . . . . . . . . . . 19 90 4.2.3 IANA Registration . . . . . . . . . . . . . . . . . . . . 19 91 4.3 Location of Registered Access Type List . . . . . . . . . 19 92 4.4 IANA Procedures for Registering Access Types . . . . . . . 19 93 5. Transfer Encodings . . . . . . . . . . . . . . . . . . . . 21 94 5.1 Transfer Encoding Requirements . . . . . . . . . . . . . . 21 95 5.1.1 Naming Requirements . . . . . . . . . . . . . . . . . . . 21 96 5.1.2 Algorithm Specification Requirements . . . . . . . . . . . 21 97 5.1.3 Input Domain Requirements . . . . . . . . . . . . . . . . 22 98 5.1.4 Output Range Requirements . . . . . . . . . . . . . . . . 22 99 5.1.5 Data Integrity and Generality Requirements . . . . . . . . 22 100 5.1.6 New Functionality Requirements . . . . . . . . . . . . . . 22 101 5.1.7 Security Requirements . . . . . . . . . . . . . . . . . . 22 102 5.2 Transfer Encoding Definition Procedure . . . . . . . . . . 23 103 5.3 IANA Procedures for Transfer Encoding Registration . . . . 23 104 5.4 Location of Registered Transfer Encodings List . . . . . . 23 105 6. Security Considerations . . . . . . . . . . . . . . . . . 24 106 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 25 107 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 26 108 Normative References . . . . . . . . . . . . . . . . . . . 27 109 Informative References . . . . . . . . . . . . . . . . . . 28 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 28 111 A. Grandfathered Media Types . . . . . . . . . . . . . . . . 29 112 B. Changes made since RFC 2048 . . . . . . . . . . . . . . . 30 113 Intellectual Property and Copyright Statements . . . . . . 31 115 1. Introduction 117 Recent Internet protocols have been carefully designed to be easily 118 extensible in certain areas. In particular, MIME [RFC2045] is an 119 open-ended framework and can accommodate additional object types, 120 charsets, and access methods without any changes to the basic 121 protocol. A registration process is needed, however, to ensure that 122 the set of such values is developed in an orderly, well-specified, 123 and public manner. 125 This document defines registration procedures which use the Internet 126 Assigned Numbers Authority (IANA) as a central registry for such 127 values. Of particular interest is the registration procedure for 128 media types described in Section 3.3. 130 Note 132 Registration of charsets for use in MIME is specified in [RFC2798] 133 and is no longer addressed by this document. 135 Historical Note 137 The media types registration process was initially defined for the 138 purpose of registering media types for use in the context of the 139 asynchronous Internet mail environment. In this mail environment 140 there is a need to limit the number of possible media types to 141 increase the likelihood of interoperability when the capabilities of 142 the remote mail system are not known. As media types are used in new 143 environments, where the proliferation of media types is not a 144 hindrance to interoperability, the original procedure was excessively 145 restrictive and had to be generalized. 147 It may still be desirable to restrict for some environmens besides 148 mail. Such restrictions are not within the scope of this document. 149 See Section 3.2.8 for additional discussion. 151 2. Conventions Used In This Document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 3. Media Type Registration 159 Registration of a new media type or types starts with the 160 construction of a registration proposal. Registration may occur in 161 several different registration trees, which have different 162 requirements as discussed below. In general, the new registration 163 proposal is circulated and reviewed in a fashion appropriate to the 164 tree involved. The media type is then registered if the proposal is 165 acceptable. The following sections describe the requirements and 166 procedures used for each of the different registration trees. 168 3.1 Registration Trees and Subtype Names 170 In order to increase the efficiency and flexibility of the 171 registration process, different structures of subtype names may be 172 registered to accomodate the different natural requirements for, 173 e.g., a subtype that will be recommended for wide support and 174 implementation by the Internet Community or a subtype that is used to 175 move files associated with proprietary software. The following 176 subsections define registration "trees", distinguished by the use of 177 faceted names (e.g., names of the form "tree.subtree...subtype"). 178 Note that some media types defined prior to this document do not 179 conform to the naming conventions described below. See Appendix A 180 for a discussion of them. 182 3.1.1 Standards Tree 184 The standards tree is intended for types of general interest to the 185 Internet Community. Registrations in the standards tree MUST be 186 approved by the IESG and MUST correspond to a formal publication by a 187 recognized standards body. In the case of registrations for the IETF 188 itself, the registration MUST be published as an RFC. 190 Media types in the standards tree are normally denoted by names that 191 are not explicitly faceted, i.e., do not contain period (".", full 192 stop) characters. 194 The "owner" of a media type registration in the standards tree is 195 assumed to be the standards body itself. Modification or alteration 196 of the specification requires the same level of processing (e.g., 197 standards track) required for the initial registration. 199 3.1.2 Vendor Tree 201 The vendor tree is used for media types associated with commercially 202 available products. "Vendor" or "producer" are construed as 203 equivalent and very broadly in this context. 205 A registration may be placed in the vendor tree by anyone who has 206 need to interchange files associated with the particular product. 207 However, the registration formally belongs to the vendor or 208 organization producing the software or file format. Changes to the 209 specification will be made at their request, as discussed in 210 subsequent sections. 212 Registrations in the vendor tree will be distinguished by the leading 213 facet "vnd.". That may be followed, at the discretion of the 214 registration, by either a media subtype name from a well-known 215 producer (e.g., "vnd.mudpie") or by an IANA-approved designation of 216 the producer's name which is then followed by a media type or product 217 designation (e.g., vnd.bigcompany.funnypictures). 219 While public exposure and review of media types to be registered in 220 the vendor tree is not required, using the ietf-types@iana.org 221 mailing list for review is strongly encouraged to improve the quality 222 of those specifications. Registrations in the vendor tree may be 223 submitted directly to the IANA. 225 3.1.3 Personal or Vanity Tree 227 Registrations for media types created experimentally or as part of 228 products that are not distributed commercially may be registered in 229 the personal or vanity tree. The registrations are distinguished by 230 the leading facet "prs.". 232 The owner of "personal" registrations and associated specifications 233 is the person or entity making the registration, or one to whom 234 responsibility has been transferred as described below. 236 While public exposure and review of media types to be registered in 237 the personal tree is not required, using the ietf-types list for 238 review is strongly encouraged to improve the quality of those 239 specifications. Registrations in the personal tree may be submitted 240 directly to the IANA. 242 3.1.4 Special x. Tree 244 For convenience and symmetry with this registration scheme, subtype 245 names with "x." as the first facet may be used for the same purposes 246 for which names starting in "x-" are normally used. These types are 247 unregistered, experimental, and should be used only with the active 248 agreement of the parties exchanging them. 250 However, with the simplified registration procedures described above 251 for vendor and personal trees, it should rarely, if ever, be 252 necessary to use unregistered experimental types, and as such use of 253 both "x-" and "x." forms is discouraged. 255 Types in this tree MUST NOT be registered. 257 3.1.5 Additional Registration Trees 259 From time to time and as required by the community, the IANA may, by 260 and with the advice and consent of the IESG, create new top-level 261 registration trees. It is explicitly assumed that these trees may be 262 created for external registration and management by well-known 263 permanent bodies, such as scientific societies for media types 264 specific to the sciences they cover. In general, the quality of 265 review of specifications for one of these additional registration 266 trees is expected to be equivalent to registrations in the standards 267 tree. Establishment of these new trees will be announced through RFC 268 publication approved by the IESG. 270 3.2 Registration Requirements 272 Media type registration proposals are all expected to conform to 273 various requirements laid out in the following sections. Note that 274 requirement specifics sometimes vary depending on the registration 275 tree, again as detailed in the following sections. 277 3.2.1 Functionality Requirement 279 Media types MUST function as an actual media format: Registration of 280 things that are better thought of as a transfer encoding, as a 281 charset, or as a collection of separate entities of another type, is 282 not allowed. For example, although applications exist to decode the 283 base64 transfer encoding [RFC2045], base64 cannot be registered as a 284 media type. 286 This requirement applies regardless of the registration tree 287 involved. 289 3.2.2 Naming Requirements 291 All registered media types MUST be assigned MIME type and subtype 292 names. The combination of these names then serves to uniquely 293 identify the media type and the format of the subtype name identifies 294 the registration tree. 296 Type and subtype names beginning with "X-" are reserved for 297 experimental use and MUST NOT be registered. 299 The choice of top-level type name MUST take the nature of media type 300 involved into account. For example, media normally used for 301 representing still images should be a subtype of the image content 302 type, whereas media capable of representing audio information should 303 be under the audio content type. See [RFC2046] for additional 304 information on the basic set of top-level types and their 305 characteristics. 307 New subtypes of top-level types MUST conform to the restrictions of 308 the top-level type, if any. For example, all subtypes of the 309 multipart content type MUST use the same encapsulation syntax. 311 In some cases a new media type may not "fit" under any currently 312 defined top-level content type. Such cases are expected to be quite 313 rare. However, if such a case does arise a new top-level type can be 314 defined to accommodate it. Such a definition MUST be done via 315 standards-track RFC; no other mechanism can be used to define 316 additional top-level content types. 318 In accordance with the rules specified in [RFC3023], media subtypes 319 that do not represent XML MIME entities MUST NOT be given a name that 320 ends with the "+xml" suffix. 322 While it is possible for a given media type to be assigned additional 323 names, the use of different names to identify the same media type is 324 discouraged. 326 These requirements apply regardless of the registration tree 327 involved. 329 3.2.3 Parameter Requirements 331 Media types MAY elect to use one or more MIME content type 332 parameters, or some parameters may be automatically made available to 333 the media type by virtue of being a subtype of a content type that 334 defines a set of parameters applicable to any of its subtypes. In 335 either case, the names, values, and meanings of any parameters MUST 336 be fully specified when a media type is registered in the standards 337 tree, and SHOULD be specified as completely as possible when media 338 types are registered in the vendor or personal trees. 340 New parameters SHOULD NOT be defined as a way to introduce new 341 functionality in types registered in the standards tree, although new 342 parameters MAY be added to convey additional information that does 343 not otherwise change existing functionality. An example of this 344 would be a "revision" parameter to indicate a revision level of an 345 external specification such as JPEG. Similar behavior is encouraged 346 for media types registered in the vendor or personal trees but is not 347 required. 349 3.2.4 Canonicalization and Format Requirements 351 All registered media types MUST employ a single, canonical data 352 format, regardless of registration tree. 354 A precise and openly available specification of the format of each 355 media type MUST exist for all types registered in the standards tree 356 and MUST at a minimum be referenced by, if it isn't actually included 357 in, the media type registration proposal itself. 359 The specifications of format and processing particulars may or may 360 not be publically available for media types registered in the vendor 361 tree, and such registration proposals are explicitly permitted to 362 limit specification to which software and version produce or process 363 such media types. References to or inclusion of format 364 specifications in registration proposals is encouraged but not 365 required. 367 Format specifications are still required for registration in the 368 personal tree, but may be either published as RFCs or otherwise 369 deposited with the IANA. The deposited specifications will meet the 370 same criteria as those required to register a well-known TCP port 371 and, in particular, need not be made public. 373 Some media types involve the use of patented technology. The 374 registration of media types involving patented technology is 375 specifically permitted. However, the restrictions set forth in 376 [RFC2026] on the use of patented technology in IETF standards-track 377 protocols must be respected when the specification of a media type is 378 part of a standards-track protocol. In addition, other standards 379 bodies making use of the standards tree may have their own rules 380 regarding intellectual property that must be observed in their 381 registrations. 383 3.2.5 Interchange Recommendations 385 Media types SHOULD interoperate across as many systems and 386 applications as possible. However, some media types will inevitably 387 have problems interoperating across different platforms. Problems 388 with different versions, byte ordering, and specifics of gateway 389 handling can and will arise. 391 Universal interoperability of media types is not required, but known 392 interoperability issues SHOULD be identified whenever possible. 393 Publication of a media type does not require an exhaustive review of 394 interoperability, and the interoperability considerations section is 395 subject to continuing evaluation. 397 These recommendations apply regardless of the registration tree 398 involved. 400 3.2.6 Security Requirements 402 An analysis of security issues MUST be done for all types registered 403 in the standards Tree. A similar analysis for media types registered 404 in the vendor or personal trees is encouraged but not required. 405 However, regardless of what security analysis has or has not been 406 done, all descriptions of security issues MUST be as accurate as 407 possible regardless of registration tree. In particular, a statement 408 that there are "no security issues associated with this type" MUST 409 NOT be confused with "the security issues associates with this type 410 have not been assessed". 412 There is absolutely no requirement that media types registered in any 413 tree be secure or completely free from risks. Nevertheless, all 414 known security risks MUST be identified in the registration of a 415 media type, again regardless of registration tree. 417 The security considerations section of all registrations is subject 418 to continuing evaluation and modification, and in particular MAY be 419 extended by use of the "comments on media types" mechanism described 420 in Section 3.4 below. 422 Some of the issues that should be looked at in a security analysis of 423 a media type are: 425 o Complex media types may include provisions for directives that 426 institute actions on a recipient's files or other resources. In 427 many cases provision is made for originators to specify arbitrary 428 actions in an unrestricted fashion which may then have devastating 429 effects. See the registration of the application/postscript media 430 type in [RFC2046] for an example of such directives and how they 431 should be described in a media type registration. 433 o All registrations MUST state whether or not they employ such 434 "active content", and if they do, they MUST state what steps have 435 been taken to protect users of the media type from harm. 437 o Complex media types may include provisions for directives that 438 institute actions which, while not directly harmful to the 439 recipient, may result in disclosure of information that either 440 facilitates a subsequent attack or else violates a recipient's 441 privacy in some way. Again, the registration of the application/ 442 postscript media type illustrates how such directives can be 443 handled. 445 o A media type which employs compression may provide an opportunity 446 for sending a small amount of data which, when received and 447 evaluated, expands enormously to consume all of the recipient's 448 resources. All media types SHOULD state whether or not they 449 employ compression, and if they do they should discuss what steps 450 need to be taken to avoid such attacks. 452 o A media type might be targeted for applications that require some 453 sort of security assurance but not provide the necessary security 454 mechanisms themselves. For example, a media type could be defined 455 for storage of confidential medical information which in turn 456 requires an external confidentiality service, or which is designed 457 for use only within a secure environment. 459 3.2.7 Requirements specific to XML media types 461 There are a number of additional requirements specific to the 462 registration of XML media types. These requirements are specified in 463 [RFC3023]. 465 3.2.8 Usage and Implementation Non-requirements 467 In the asynchronous mail environment, where information on the 468 capabilities of the remote mail agent is frequently not available to 469 the sender, maximum interoperability is attained by restricting the 470 number of media types used to those "common" formats expected to be 471 widely implemented. This was asserted in the past as a reason to 472 limit the number of possible media types and resulted in a 473 registration process with a significant hurdle and delay for those 474 registering media types. 476 However, the need for "common" media types does not require limiting 477 the registration of new media types. If a limited set of media types 478 is recommended for a particular application, that should be asserted 479 by a separate applicability statement specific for the application 480 and/or environment. 482 As such, universal support and implementation of a media type is NOT 483 a requirement for registration. If, however, a media type is 484 explicitly intended for limited use, this SHOULD be noted in its 485 registration. 487 3.2.9 Publication Requirements 489 Proposals for media types registered in the standards tree by the 490 IETF itself MUST be published as RFCs. RFC publication of vendor and 491 personal media type proposals is encouraged but not required. In all 492 cases the IANA will retain copies of all media type proposals and 493 "publish" them as part of the media types registration tree itself. 495 As stated previously, standards tree registrations for media types 496 defined in documents produced by other standards bodies MUST be 497 described by a formal standards specification produced by that body. 498 Such specifications MUST contain an appropriate media type 499 registration template. Additionally, the copyright on the 500 registration template MUST allow the IANA to copy it into the IANA 501 registry. 503 Other than IETF registrations in the standards tree, the registration 504 of a data type does not imply endorsement, approval, or 505 recommendation by the IANA or the IETF or even certification that the 506 specification is adequate. To become Internet Standards, protocol, 507 data objects, or whatever must go through the IETF standards process. 508 This is too difficult and too lengthy a process for the convenient 509 registration of media types. 511 The stanards tree exists for media types that do require require a 512 substantive review and approval process in a recognized standards 513 body. The vendor and personal trees exist for those media types that 514 do not require such a process. It is expected that applicability 515 statements for particular applications will be published from time to 516 time in the IETF that recommend implementation of, and support for, 517 media types that have proven particularly useful in those contexts. 519 As discussed above, registration of a top-level type requires 520 standards-track processing in the IETF and, hence, RFC publication. 522 3.2.10 Additional Information 524 Various sorts of optional information SHOULD be included in the 525 specification of a media type if it is available: 527 o Magic number(s) (length, octet values). Magic numbers are byte 528 sequences that are always present and thus can be used to identify 529 entities as being of a given media type. 531 o File extension(s) commonly used on one or more platforms to 532 indicate that some file containing a given type of media. 534 o Macintosh File Type code(s) (4 octets) used to label files 535 containing a given type of media. 537 o Information about how fragment/anchor identifiers [RFC2396] are 538 constructed for use in conjunction with this media type. 540 In the case of a registration in the standards tree this additional 541 information MAY be provided in the formal specification of the media 542 type. It is suggested that this be done by incorporating the IANA 543 media type registration form into the specification itself. 545 3.3 Registration Procedure 547 The following procedure has been implemented by the IANA for review 548 and approval of new media types. This is not a formal standards 549 process, but rather an administrative procedure intended to allow 550 community comment and sanity checking without excessive time delay. 552 The normal IETF processes should be followed for all IETF 553 registrations in the standards tree, with the posting of an 554 internet-draft being a necessary first step. 556 Proposed registrations in the standards tree by other standards 557 bodies should be communicated to the IESG (at iesg@ietf.org). 559 Registrations in the vendor and personal tree should be submitted 560 directly to the IANA. 562 3.3.1 Preliminary Community Review 564 In all cases notice of a potential media type registration MAY be 565 sent to the "ietf-types@iana.org" mailing list for review. This 566 mailing list has been established for the purpose of reviewing 567 proposed media and access types. 569 The intent of the public posting is to solicit comments and feedback 570 on the choice of type/subtype name, the unambiguity of the references 571 with respect to versions and external profiling information, and a 572 review of any interoperability or security considerations. The 573 submitter may submit a revised registration, or abandon the 574 registration completely, at any time. 576 3.3.2 IESG Approval 578 Media types registered in the standards tree MUST be approved by the 579 IESG prior to registration. 581 3.3.3 IANA Registration 583 Provided that the media type meets all of the relevant requirements 584 and has obtained whateveer approval is necessary, the author may 585 submit the registration request to the IANA. Registration requests 586 can be sent to iana@iana.org. A web form for registration requests 587 is also available: 589 http://www.iana.org/cgi-bin/mediatypes.pl 591 Sending to ietf-types@iana.org does not constitute submitting the 592 registration to the IANA. 594 When the registration is part of an RFC publication request, close 595 coordination between the IANA and the IESG means IESG approval in 596 effect submits the registration to the IANA. There is no need for an 597 additional registration request in such cases. 599 3.3.4 Media Types Reviewer 601 Registrations submitted to the IANA will be passed on to the media 602 types reviewer. The media types reviewer, who is appointed by the 603 IETF Applications Area Director(s), will review the registration to 604 make sure it meets the requirements set forth in this document. 605 Registrations which do not meet these requirements will be returned 606 to the submitter for revision. 608 Decisions made by the media types reviewer may be appealed to the 609 IESG as specified in [RFC2026]. 611 Once a media type registration has passed review the IANA will 612 register the media type and make the media type registration 613 available to the community. 615 3.4 Comments on Media Type Registrations 617 Comments on registered media types may be submitted by members of the 618 community to the IANA. These comments will be reviewed by the media 619 types reviewer and then passed on to the "owner" of the media type if 620 possible. Submitters of comments may request that their comment be 621 attached to the media type registration itself, and if the IANA 622 approves of this the comment will be made accessible in conjunction 623 with the type registration itself. 625 3.5 Location of Registered Media Type List 627 Media type registrations are listed by the IANA at: 629 http://www.iana.org/assignments/media-types/index.html 631 3.6 IANA Procedures for Registering Media Types 633 The IANA will only register media types in the standards tree in 634 response to a communication from the IESG stating that a given 635 registration has been approved. Vendor and personal types will be 636 registered by the IANA automatically and without any formal review as 637 long as the following minimal conditions are met: 639 o Media types MUST function as an actual media format. In 640 particular, charsets and transfer encodings MUST NOT be registered 641 as media types. 643 o All media types MUST have properly formed type and subtype names. 644 All type names MUST be defined by a standards-track RFC. All 645 subtype names MUST be unique, must conform to the MIME grammar for 646 such names, and MUST contain the proper tree prefix. 648 o Types registered in the personal tree MUST either provide a format 649 specification or a pointer to one. 651 o All media types MUST have a reasonable security considerations 652 section. (It is neither possible nor necessary for the IANA to 653 conduct a comprehensive security review of media type 654 registrations. Nevertheless, the IANA has the authority to 655 identify obviously incompetent material and exclude it.) 657 o Registrations in the standards tree MUST satisfy the additional 658 requirement that they originate from another standards body 659 recognized as such by the IETF. 661 3.7 Change Procedures 663 Once a media type has been published by the IANA, the owner may 664 request a change to its definition. The descriptions of the 665 different registration trees above designate the "owners" of each 666 type of registration. The same procedure as would be appropriate for 667 the original registration request is used to process a change 668 request. 670 Changes should be requested only when there are serious omissions or 671 errors in the published specification. When review is required, a 672 change request may be denied if it renders entities that were valid 673 under the previous definition invalid under the new definition. 675 The owner of a media type may pass responsibility to another person 676 or agency by informing the IANA and the ietf-types list; this can be 677 done without discussion or review. 679 The IESG may reassign responsibility for a media type. The most 680 common case of this will be to enable changes to be made to types 681 where the author of the registration has died, moved out of contact 682 or is otherwise unable to make changes that are important to the 683 community. 685 Media type registrations may not be deleted; media types which are no 686 longer believed appropriate for use can be declared OBSOLETE by a 687 change to their "intended use" field; such media types will be 688 clearly marked in the lists published by the IANA. 690 3.8 Registration Template 692 To: ietf-types@iana.org 693 Subject: Registration of MIME media type XXX/YYY 695 MIME media type name: 697 MIME subtype name: 699 Required parameters: 701 Optional parameters: 703 Encoding considerations: 705 Security considerations: 707 Interoperability considerations: 709 Published specification: 711 Applications which use this media type: 713 Additional information: 715 Magic number(s): 716 File extension(s): 717 Macintosh File Type Code(s): 719 Person & email address to contact for further information: 721 Intended usage: 723 (One of COMMON, LIMITED USE or OBSOLETE) 725 Author/Change controller: 727 (Any other information that the author deems interesting may be 728 added below this line.) 730 4. External Body Access Types 732 [RFC2046] defines the message/external-body media type, whereby a 733 MIME entity can act as pointer to the actual body data in lieu of 734 including the data directly in the entity body. Each message/ 735 external-body reference specifies an access type, which determines 736 the mechanism used to retrieve the actual body data. RFC 2046 737 defines an initial set of access types, but allows for the 738 registration of additional access types to accommodate new retrieval 739 mechanisms. 741 4.1 Registration Requirements 743 New access type specifications MUST conform to a number of 744 requirements as described below. 746 4.1.1 Naming Requirements 748 Each access type MUST have a unique name. This name appears in the 749 access-type parameter in the message/external-body content-type 750 header field, and MUST conform to MIME content type parameter syntax. 752 4.1.2 Mechanism Specification Requirements 754 All of the protocols, transports, and procedures used by a given 755 access type MUST be described, either in the specification of the 756 access type itself or in some other publicly available specification, 757 in sufficient detail for the access type to be implemented by any 758 competent implementor. Use of secret and/or proprietary methods in 759 access types is expressly prohibited. The restrictions imposed by 760 [RFC2026] on the standardization of patented algorithms must be 761 respected as well. 763 4.1.3 Publication Requirements 765 All access types MUST be described by an RFC. The RFC may be 766 informational rather than standards-track, although standard-track 767 review and approval are encouraged for all access types. 769 4.1.4 Security Requirements 771 Any known security issues that arise from the use of the access type 772 MUST be completely and fully described. It is not required that the 773 access type be secure or that it be free from risks, but that the 774 known risks be identified. Publication of a new access type does not 775 require an exhaustive security review, and the security 776 considerations section is subject to continuing evaluation. 777 Additional security considerations SHOULD be addressed by publishing 778 revised versions of the access type specification. 780 4.2 Registration Procedure 782 Registration of a new access type starts with the the publication of 783 the specification as an internet-draft. 785 4.2.1 Present the Access Type to the Community 787 Send a proposed access type specification to the 788 "ietf-types@iana.org" mailing list for a two week review period. 789 This mailing list has been established for the purpose of reviewing 790 proposed access and media types. Proposed access types are not 791 formally registered and must not be used. 793 The intent of the public posting is to solicit comments and feedback 794 on the access type specification and a review of any security 795 considerations. 797 4.2.2 Access Type Reviewer 799 When the two week period has passed, the access type reviewer, who is 800 appointed by the IETF Applications Area Director(s), either forwards 801 the request to iana@iana.org, or rejects it because of significant 802 objections raised on the list. 804 Decisions made by the reviewer must be posted to the ietf-types 805 mailing list within 14 days. Decisions made by the reviewer may be 806 appealed to the IESG as specified in [RFC2026]. 808 4.2.3 IANA Registration 810 Provided that the access type has either passed review or has been 811 successfully appealed to the IESG, the IANA will register the access 812 type and make the registration available to the community. The 813 specification of the access type must also be published as an RFC. 815 4.3 Location of Registered Access Type List 817 Access type registrations are listed by the IANA on the web page: 819 http://www.iana.org/assignments/access-types 821 4.4 IANA Procedures for Registering Access Types 823 The identity of the access type reviewer is communicated to the IANA 824 by the IESG. The IANA then only acts in response to access type 825 definitions that either are approved by the access type reviewer and 826 forwarded by the reviewer to the IANA for registration, or in 827 response to a communication from the IESG that an access type 828 definition appeal has overturned the access type reviewer's ruling. 830 5. Transfer Encodings 832 Transfer encodings are tranformations applied to MIME media types 833 after conversion to the media type's canonical form. Transfer 834 encodings are used for several purposes: 836 o Many transports, especially message transports, can only handle 837 data consisting of relatively short lines of text. There can also 838 be severe restrictions on what characters can be used in these 839 lines of text -- some transports are restricted to a small subset 840 of US-ASCII and others cannot handle certain character sequences. 841 Transfer encodings are used to transform binary data into textual 842 form that can survive such transports. Examples of this sort of 843 transfer encoding include the base64 and quoted-printable transfer 844 encodings defined in [RFC2045]. 846 o Image, audio, video, and even application entities are sometimes 847 quite large. Compression algorithms are often quite effective in 848 reducing the size of large entities. Transfer encodings can be 849 used to apply general-purpose non-lossy compression algorithms to 850 MIME entities. 852 o Transport encodings can be defined as a means of representing 853 existing encoding formats in a MIME context. 855 IMPORTANT: The standardization of a large numbers of different 856 transfer encodings is seen as a significant barrier to widespread 857 interoperability and is expressely discouraged. Nevertheless, the 858 following procedure has been defined to provide a means of defining 859 additional transfer encodings, should standardization actually be 860 justified. 862 5.1 Transfer Encoding Requirements 864 Transfer encoding specifications MUST conform to a number of 865 requirements as described below. 867 5.1.1 Naming Requirements 869 Each transfer encoding MUST have a unique name. This name appears in 870 the Content-Transfer-Encoding header field and MUST conform to the 871 syntax of that field. 873 5.1.2 Algorithm Specification Requirements 875 All of the algorithms used in a transfer encoding (e.g., conversion 876 to printable form, compression) MUST be described in their entirety 877 in the transfer encoding specification. Use of secret and/or 878 proprietary algorithms in standardized transfer encodings is 879 expressly prohibited. The restrictions imposed by [RFC2026] on the 880 standardization of patented algorithms MUST be respected as well. 882 5.1.3 Input Domain Requirements 884 All transfer encodings MUST be applicable to an arbitrary sequence of 885 octets of any length. Dependence on particular input forms is not 886 allowed. 888 It should be noted that the 7bit and 8bit encodings do not conform to 889 this requirement. Aside from the undesireability of having 890 specialized encodings, the intent here is to forbid the addition of 891 additional encodings similar to or redundant with 7bit and 8bit. 893 5.1.4 Output Range Requirements 895 There is no requirement that a particular tranfer encoding produce a 896 particular form of encoded output. However, the output format for 897 each transfer encoding MUST be fully and completely documented. In 898 particular, each specification MUST clearly state whether the output 899 format always lies within the confines of 7bit data, 8bit data, or is 900 simply pure binary data. 902 5.1.5 Data Integrity and Generality Requirements 904 All transfer encodings MUST be fully invertible on any platform; it 905 MUST be possible for anyone to recover the original data by 906 performing the corresponding decoding operation. Note that this 907 requirement effectively excludes all forms of lossy compression as 908 well as all forms of encryption from use as a transfer encoding. 910 5.1.6 New Functionality Requirements 912 All transfer encodings MUST provide some sort of new functionality. 913 Some degree of functionality overlap with previously defined transfer 914 encodings is acceptable, but any new transfer encoding MUST also 915 offer something no other transfer encoding provides. 917 5.1.7 Security Requirements 919 To the greatest extent possible transfer encodings SHOULD NOT contain 920 known security issues. Regardless, any known security issues that 921 arise from the use of the transfer encoding MUST be completely and 922 fully described. If additional security issues come to light after 923 initial publication and registration they SHOULD be addressed by 924 publishing revised versions of the transfer encoding pecification. 926 5.2 Transfer Encoding Definition Procedure 928 Definition of a new transfer encoding starts with the the publication 929 of the specification as an internet-draft. The draft MUST define the 930 transfer encoding precisely and completely, and MUST also provide 931 substantial justification for defining and standardizing a new 932 transfer encoding. This specification MUST then be presented to the 933 IESG for consideration. The IESG can 935 o reject the specification outright as being inappropriate for 936 standardization, 938 o assign the specification to an existing IETF working group for 939 further work, 941 o approve the formation of an IETF working group to work on the 942 specification in accordance with IETF procedures, or, 944 o accept the specification as-is for processing as an individual 945 standards track submission. 947 Transfer encoding specifications on the standards track follow normal 948 IETF rules for standards track documents. A transfer encoding is 949 considered to be defined and available for use once it is on the 950 standards track. 952 5.3 IANA Procedures for Transfer Encoding Registration 954 There is no need for a special procedure for registering Transfer 955 Encodings with the IANA. All legitimate transfer encoding 956 registrations MUST appear as a standards-track RFC, so it is the 957 IESG's responsibility to notify the IANA when a new transfer encoding 958 has been approved. 960 5.4 Location of Registered Transfer Encodings List 962 The list of transfer encoding registrations can be found at: 964 http://www.iana.org/assignments/transfer-encodings 966 6. Security Considerations 968 Security requirements for media type registrations are discussed in 969 Section 3.2.6. Security requirements for access types are discussed 970 in Section 4.1.4. Security requirements for transfer encodings are 971 discussed in Section 5.1.7 973 7. IANA Considerations 975 The sole purpose of this document is to define IANA registries for 976 media types, access types, and transfer encodings. The IANA 977 procedures for these registries are specified in Section 3.6, Section 978 4.4, and Section 5.3 respectively. 980 8. Acknowledgements 982 The current authors would like to acknowledge their debt to the late 983 Dr. Jon Postel, whose general model of IANA registration procedures 984 and specific contributions shaped the predecessors of this document. 985 We hope that the current version is one with which he would have 986 agreed but, since it is impossible to verify that agreement, we have 987 regretfully removed his name as a co-author. 989 Normative References 991 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 992 Extensions (MIME) Part One: Format of Internet Message 993 Bodies", RFC 2045, November 1996. 995 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 996 Extensions (MIME) Part Two: Media Types", RFC 2046, 997 November 1996. 999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1000 Requirement Levels", BCP 14, RFC 2119, March 1997. 1002 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1003 Resource Identifiers (URI): Generic Syntax", RFC 2396, 1004 August 1998. 1006 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 1007 Types", RFC 3023, January 2001. 1009 Informative References 1011 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1012 3", BCP 9, RFC 2026, October 1996. 1014 [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose 1015 Internet Mail Extensions (MIME) Part Four: Registration 1016 Procedures", BCP 13, RFC 2048, November 1996. 1018 [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object 1019 Class", RFC 2798, April 2000. 1021 Authors' Addresses 1023 Ned Freed 1024 Sun Microsystems 1025 1050 Lakes Drive 1026 West Covina, CA 91790 1027 USA 1029 Phone: +1 626 850 4350 1030 EMail: ned.freed@mrochek.com 1032 John C Klensin 1033 1770 Massachusetts Ave, #322 1034 Cambridge, MA 02140 1036 EMail: klensin@jck.com 1038 Appendix A. Grandfathered Media Types 1040 A number of media types, registered prior to 1996, would, if 1041 registered under the guidelines in this document, be placed into 1042 either the vendor or personal trees. Reregistration of those types 1043 to reflect the appropriate trees is encouraged, but not required. 1044 Ownership and change control principles outlined in this document 1045 apply to those types as if they had been registered in the trees 1046 described above. 1048 Appendix B. Changes made since RFC 2048 1050 o Much of the document has been clarified in the light of 1051 operational experience with these procedures. 1053 o The unfaceted IETF tree is now called the standards tree and the 1054 registration rules for this tree have been relaxed to allow use by 1055 other standards bodies. 1057 o The text describing the media type registration procedure has 1058 clarified. 1060 o The rules and requirements for constructing security 1061 considerations sections have been extended and clarified. 1063 o RFC 3023 is now referenced as the source of additional information 1064 concerning the registration of XML media types. 1066 o Several of the references in this document have been updated to 1067 refer to current versions of the relevant specifications. 1069 o The option of assigning the task of working on a new transfer 1070 encoding to an existing working group has been added to the list 1071 of possible actions the IESG can take. 1073 o A note has been added discouraging the assignment of multiple 1074 names to a single media type. 1076 o Security considerations and IANA considerations sections have been 1077 added. 1079 o Concerns regarding copyrights on media type registration templates 1080 produced by other standards bodies have been dealt with by 1081 requiring that the IANA be allowed to copy the registration 1082 template into the registry. 1084 Intellectual Property Statement 1086 The IETF takes no position regarding the validity or scope of any 1087 intellectual property or other rights that might be claimed to 1088 pertain to the implementation or use of the technology described in 1089 this document or the extent to which any license under such rights 1090 might or might not be available; neither does it represent that it 1091 has made any effort to identify any such rights. Information on the 1092 IETF's procedures with respect to rights in standards-track and 1093 standards-related documentation can be found in BCP-11. Copies of 1094 claims of rights made available for publication and any assurances of 1095 licenses to be made available, or the result of an attempt made to 1096 obtain a general license or permission for the use of such 1097 proprietary rights by implementors or users of this specification can 1098 be obtained from the IETF Secretariat. 1100 The IETF invites any interested party to bring to its attention any 1101 copyrights, patents or patent applications, or other proprietary 1102 rights which may cover technology that may be required to practice 1103 this standard. Please address the information to the IETF Executive 1104 Director. 1106 Full Copyright Statement 1108 Copyright (C) The Internet Society (2003). All Rights Reserved. 1110 This document and translations of it may be copied and furnished to 1111 others, and derivative works that comment on or otherwise explain it 1112 or assist in its implementation may be prepared, copied, published 1113 and distributed, in whole or in part, without restriction of any 1114 kind, provided that the above copyright notice and this paragraph are 1115 included on all such copies and derivative works. However, this 1116 document itself may not be modified in any way, such as by removing 1117 the copyright notice or references to the Internet Society or other 1118 Internet organizations, except as needed for the purpose of 1119 developing Internet standards in which case the procedures for 1120 copyrights defined in the Internet Standards process must be 1121 followed, or as required to translate it into languages other than 1122 English. 1124 The limited permissions granted above are perpetual and will not be 1125 revoked by the Internet Society or its successors or assignees. 1127 This document and the information contained herein is provided on an 1128 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1129 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1130 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1131 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1132 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1134 Acknowledgement 1136 Funding for the RFC Editor function is currently provided by the 1137 Internet Society.