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