idnits 2.17.1 draft-freed-mime-p4-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances 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 (February 23, 2003) is 7733 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: '6' is defined on line 930, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2396 (ref. '4') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2048 (ref. '6') (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: August 24, 2003 February 23, 2003 7 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration 8 Procedures 9 draft-freed-mime-p4-00.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 August 24, 2003. 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 Registration of charsets for use in MIME is covered elsewhere and is 50 no longer addressed by this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions Used In This Document . . . . . . . . . . . . . 5 56 3. Media Type Registration . . . . . . . . . . . . . . . . . . 6 57 3.1 Registration Trees and Subtype Names . . . . . . . . . . . . 6 58 3.1.1 Standards Tree . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.1.2 Vendor Tree . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1.3 Personal or Vanity Tree . . . . . . . . . . . . . . . . . . 7 61 3.1.4 Special x. Tree . . . . . . . . . . . . . . . . . . . . . . 7 62 3.1.5 Additional Registration Trees . . . . . . . . . . . . . . . 8 63 3.2 Registration Requirements . . . . . . . . . . . . . . . . . 8 64 3.2.1 Functionality Requirement . . . . . . . . . . . . . . . . . 8 65 3.2.2 Naming Requirements . . . . . . . . . . . . . . . . . . . . 8 66 3.2.3 Parameter Requirements . . . . . . . . . . . . . . . . . . . 9 67 3.2.4 Canonicalization and Format Requirements . . . . . . . . . . 9 68 3.2.5 Interchange Recommendations . . . . . . . . . . . . . . . . 10 69 3.2.6 Security Requirements . . . . . . . . . . . . . . . . . . . 10 70 3.2.7 Usage and Implementation Non-requirements . . . . . . . . . 12 71 3.2.8 Publication Requirements . . . . . . . . . . . . . . . . . . 12 72 3.2.9 Additional Information . . . . . . . . . . . . . . . . . . . 13 73 3.3 Registration Procedure . . . . . . . . . . . . . . . . . . . 13 74 3.3.1 Preliminary Community Review . . . . . . . . . . . . . . . . 13 75 3.3.2 IESG Approval . . . . . . . . . . . . . . . . . . . . . . . 14 76 3.3.3 IANA Registration . . . . . . . . . . . . . . . . . . . . . 14 77 3.3.4 Media Types Reviewer . . . . . . . . . . . . . . . . . . . . 14 78 3.4 Comments on Media Type Registrations . . . . . . . . . . . . 14 79 3.5 Location of Registered Media Type List . . . . . . . . . . . 15 80 3.6 IANA Procedures for Registering Media Types . . . . . . . . 15 81 3.7 Change Procedures . . . . . . . . . . . . . . . . . . . . . 15 82 3.8 Registration Template . . . . . . . . . . . . . . . . . . . 16 83 4. External Body Access Types . . . . . . . . . . . . . . . . . 18 84 4.1 Registration Requirements . . . . . . . . . . . . . . . . . 18 85 4.1.1 Naming Requirements . . . . . . . . . . . . . . . . . . . . 18 86 4.1.2 Mechanism Specification Requirements . . . . . . . . . . . . 18 87 4.1.3 Publication Requirements . . . . . . . . . . . . . . . . . . 18 88 4.1.4 Security Requirements . . . . . . . . . . . . . . . . . . . 18 89 4.2 Registration Procedure . . . . . . . . . . . . . . . . . . . 19 90 4.2.1 Present the Access Type to the Community . . . . . . . . . . 19 91 4.2.2 Access Type Reviewer . . . . . . . . . . . . . . . . . . . . 19 92 4.2.3 IANA Registration . . . . . . . . . . . . . . . . . . . . . 19 93 4.3 Location of Registered Access Type List . . . . . . . . . . 19 94 4.4 IANA Procedures for Registering Access Types . . . . . . . . 19 95 5. Transfer Encodings . . . . . . . . . . . . . . . . . . . . . 21 96 5.1 Transfer Encoding Requirements . . . . . . . . . . . . . . . 21 97 5.1.1 Naming Requirements . . . . . . . . . . . . . . . . . . . . 21 98 5.1.2 Algorithm Specification Requirements . . . . . . . . . . . . 21 99 5.1.3 Input Domain Requirements . . . . . . . . . . . . . . . . . 22 100 5.1.4 Output Range Requirements . . . . . . . . . . . . . . . . . 22 101 5.1.5 Data Integrity and Generality Requirements . . . . . . . . . 22 102 5.1.6 New Functionality Requirements . . . . . . . . . . . . . . . 22 103 5.2 Transfer Encoding Definition Procedure . . . . . . . . . . . 22 104 5.3 IANA Procedures for Transfer Encoding Registration . . . . . 23 105 5.4 Location of Registered Transfer Encodings List . . . . . . . 23 106 Normative References . . . . . . . . . . . . . . . . . . . . 24 107 Informative References . . . . . . . . . . . . . . . . . . . 25 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 25 109 A. Grandfathered Media Types . . . . . . . . . . . . . . . . . 26 110 B. Changes made since RFC 2048 . . . . . . . . . . . . . . . . 27 111 Intellectual Property and Copyright Statements . . . . . . . 28 113 1. Introduction 115 Recent Internet protocols have been carefully designed to be easily 116 extensible in certain areas. In particular, MIME [1] is an 117 open-ended framework and can accommodate additional object types, 118 charsets, and access methods without any changes to the basic 119 protocol. A registration process is needed, however, to ensure that 120 the set of such values is developed in an orderly, well-specified, 121 and public manner. 123 This document defines registration procedures which use the Internet 124 Assigned Numbers Authority (IANA) as a central registry for such 125 values. Of particular interest is the registration procedure for 126 media types described in Section 3.3. 128 Historical Note 130 The media types registration process was initially defined for the 131 purpose of registering media types for use in the context of the 132 asynchronous Internet mail environment. In this mail environment 133 there is a need to limit the number of possible media types to 134 increase the likelihood of interoperability when the capabilities of 135 the remote mail system are not known. As media types are used in new 136 environments, where the proliferation of media types is not a 137 hindrance to interoperability, the original procedure was excessively 138 restrictive and had to be generalized. 140 2. Conventions Used In This Document 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [3]. 146 3. Media Type Registration 148 Registration of a new media type or types starts with the 149 construction of a registration proposal. Registration may occur in 150 several different registration trees, which have different 151 requirements as discussed below. In general, the new registration 152 proposal is circulated and reviewed in a fashion appropriate to the 153 tree involved. The media type is then registered if the proposal is 154 acceptable. The following sections describe the requirements and 155 procedures used for each of the different registration trees. 157 3.1 Registration Trees and Subtype Names 159 In order to increase the efficiency and flexibility of the 160 registration process, different structures of subtype names may be 161 registered to accomodate the different natural requirements for, 162 e.g., a subtype that will be recommended for wide support and 163 implementation by the Internet Community or a subtype that is used to 164 move files associated with proprietary software. The following 165 subsections define registration "trees", distinguished by the use of 166 faceted names (e.g., names of the form "tree.subtree...subtype"). 167 Note that some media types defined prior to this document do not 168 conform to the naming conventions described below. See Appendix A 169 for a discussion of them. 171 3.1.1 Standards Tree 173 The standards tree is intended for types of general interest to the 174 Internet Community. Registrations in the standards tree MUST be 175 approved by the IESG and MUST correspond to a formal publication by a 176 recognized standards body. In the case of registrations for the IETF 177 itself, the registration MUST be published as an RFC. 179 Media types in the standards tree are normally denoted by names that 180 are not explicitly faceted, i.e., do not contain period (".", full 181 stop) characters. 183 The "owner" of a media type registration in the standards tree is 184 assumed to be the standards body itself. Modification or alteration 185 of the specification requires the same level of processing (e.g., 186 standards track) required for the initial registration. 188 3.1.2 Vendor Tree 190 The vendor tree is used for media types associated with commercially 191 available products. "Vendor" or "producer" are construed as 192 equivalent and very broadly in this context. 194 A registration may be placed in the vendor tree by anyone who has 195 need to interchange files associated with the particular product. 196 However, the registration formally belongs to the vendor or 197 organization producing the software or file format. Changes to the 198 specification will be made at their request, as discussed in 199 subsequent sections. 201 Registrations in the vendor tree will be distinguished by the leading 202 facet "vnd.". That may be followed, at the discretion of the 203 registration, by either a media subtype name from a well-known 204 producer (e.g., "vnd.mudpie") or by an IANA-approved designation of 205 the producer's name which is then followed by a media type or product 206 designation (e.g., vnd.bigcompany.funnypictures). 208 While public exposure and review of media types to be registered in 209 the vendor tree is not required, using the ietf-types list for review 210 is strongly encouraged to improve the quality of those 211 specifications. Registrations in the vendor tree may be submitted 212 directly to the IANA. 214 3.1.3 Personal or Vanity Tree 216 Registrations for media types created experimentally or as part of 217 products that are not distributed commercially may be registered in 218 the personal or vanity tree. The registrations are distinguished by 219 the leading facet "prs.". 221 The owner of "personal" registrations and associated specifications 222 is the person or entity making the registration, or one to whom 223 responsibility has been transferred as described below. 225 While public exposure and review of media types to be registered in 226 the personal tree is not required, using the ietf-types list for 227 review is strongly encouraged to improve the quality of those 228 specifications. Registrations in the personal tree may be submitted 229 directly to the IANA. 231 3.1.4 Special x. Tree 233 For convenience and symmetry with this registration scheme, subtype 234 names with "x." as the first facet may be used for the same purposes 235 for which names starting in "x-" are normally used. These types are 236 unregistered, experimental, and should be used only with the active 237 agreement of the parties exchanging them. 239 However, with the simplified registration procedures described above 240 for vendor and personal trees, it should rarely, if ever, be 241 necessary to use unregistered experimental types, and as such use of 242 both "x-" and "x." forms is discouraged. 244 Types in this tree MUST NOT be registered. 246 3.1.5 Additional Registration Trees 248 From time to time and as required by the community, the IANA may, 249 with the advice and consent of the IESG, create new top-level 250 registration trees. It is explicitly assumed that these trees may be 251 created for external registration and management by well-known 252 permanent bodies, such as scientific societies for media types 253 specific to the sciences they cover. In general, the quality of 254 review of specifications for one of these additional registration 255 trees is expected to be equivalent to registrations in the standards 256 tree. Establishment of these new trees will be announced through RFC 257 publication approved by the IESG. 259 3.2 Registration Requirements 261 Media type registration proposals are all expected to conform to 262 various requirements laid out in the following sections. Note that 263 requirement specifics sometimes vary depending on the registration 264 tree, again as detailed in the following sections. 266 3.2.1 Functionality Requirement 268 Media types MUST function as an actual media format: Registration of 269 things that are better thought of as a transfer encoding, as a 270 charset, or as a collection of separate entities of another type, is 271 not allowed. For example, although applications exist to decode the 272 base64 transfer encoding [1], base64 cannot be registered as a media 273 type. 275 This requirement applies regardless of the registration tree 276 involved. 278 3.2.2 Naming Requirements 280 All registered media types MUST be assigned MIME type and subtype 281 names. The combination of these names then serves to uniquely 282 identify the media type and the format of the subtype name identifies 283 the registration tree. 285 Type and subtype names beginning with "X-" are reserved for 286 experimental use and MUST NOT be registered. 288 The choice of top-level type name MUST take the nature of media type 289 involved into account. For example, media normally used for 290 representing still images should be a subtype of the image content 291 type, whereas media capable of representing audio information should 292 be under the audio content type. See RFC 2046 [2] for additional 293 information on the basic set of top-level types and their 294 characteristics. 296 New subtypes of top-level types MUST conform to the restrictions of 297 the top-level type, if any. For example, all subtypes of the 298 multipart content type MUST use the same encapsulation syntax. 300 In some cases a new media type may not "fit" under any currently 301 defined top-level content type. Such cases are expected to be quite 302 rare. However, if such a case arises a new top-level type can be 303 defined to accommodate it. Such a definition MUST be done via 304 standards-track RFC; no other mechanism can be used to define 305 additional top-level content types. 307 These requirements apply regardless of the registration tree 308 involved. 310 3.2.3 Parameter Requirements 312 Media types MAY elect to use one or more MIME content type 313 parameters, or some parameters may be automatically made available to 314 the media type by virtue of being a subtype of a content type that 315 defines a set of parameters applicable to any of its subtypes. In 316 either case, the names, values, and meanings of any parameters MUST 317 be fully specified when a media type is registered in the standards 318 tree, and SHOULD be specified as completely as possible when media 319 types are registered in the vendor or personal trees. 321 New parameters SHOULD NOT be defined as a way to introduce new 322 functionality in types registered in the standards tree, although new 323 parameters MAY be added to convey additional information that does 324 not otherwise change existing functionality. An example of this 325 would be a "revision" parameter to indicate a revision level of an 326 external specification such as JPEG. Similar behavior is encouraged 327 for media types registered in the vendor or personal trees but is not 328 required. 330 3.2.4 Canonicalization and Format Requirements 332 All registered media types MUST employ a single, canonical data 333 format, regardless of registration tree. 335 A precise and openly available specification of the format of each 336 media type MUST exist for all types registered in the standards tree 337 and MUST at a minimum be referenced by, if it isn't actually included 338 in, the media type registration proposal itself. 340 The specifications of format and processing particulars may or may 341 not be publically available for media types registered in the vendor 342 tree, and such registration proposals are explicitly permitted to 343 include only a specification of which software and version produce or 344 process such media types. References to or inclusion of format 345 specifications in registration proposals is encouraged but not 346 required. 348 Format specifications are still required for registration in the 349 personal tree, but may be either published as RFCs or otherwise 350 deposited with the IANA. The deposited specifications will meet the 351 same criteria as those required to register a well-known TCP port 352 and, in particular, need not be made public. 354 Some media types involve the use of patented technology. The 355 registration of media types involving patented technology is 356 specifically permitted. However, the restrictions set forth in RFC 357 2026 [5] on the use of patented technology in IETF standards-track 358 protocols must be respected when the specification of a media type is 359 part of a standards-track protocol. In addition, other standards 360 bodies making use of the standards tree may have their own rules 361 regarding intellectual property that must be observed in their 362 registrations. 364 3.2.5 Interchange Recommendations 366 Media types SHOULD interoperate across as many systems and 367 applications as possible. However, some media types will inevitably 368 have problems interoperating across different platforms. Problems 369 with different versions, byte ordering, and specifics of gateway 370 handling can and will arise. 372 Universal interoperability of media types is not required, but known 373 interoperability issues SHOULD be identified whenever possible. 374 Publication of a media type does not require an exhaustive review of 375 interoperability, and the interoperability considerations section is 376 subject to continuing evaluation. 378 These recommendations apply regardless of the registration tree 379 involved. 381 3.2.6 Security Requirements 383 An analysis of security issues MUST be done for all types registered 384 in the standards Tree. A similar analysis for media types registered 385 in the vendor or personal trees is encouraged but not required. 387 However, regardless of what security analysis has or has not been 388 done, all descriptions of security issues MUST be as accurate as 389 possible regardless of registration tree. In particular, a statement 390 that there are "no security issues associated with this type" MUST 391 NOT be confused with "the security issues associates with this type 392 have not been assessed". 394 There is absolutely no requirement that media types registered in any 395 tree be secure or completely free from risks. Nevertheless, all 396 known security risks MUST be identified in the registration of a 397 media type, again regardless of registration tree. 399 The security considerations section of all registrations is subject 400 to continuing evaluation and modification, and in particular MAY be 401 extended by use of the "comments on media types" mechanism described 402 in a subsequent section of this document. 404 Some of the issues that should be looked at in a security analysis of 405 a media type are: 407 o Complex media types may include provisions for directives that 408 institute actions on a recipient's files or other resources. In 409 many cases provision is made for originators to specify arbitrary 410 actions in an unrestricted fashion which may then have devastating 411 effects. See the registration of the application/postscript media 412 type in RFC 2046 [2] for an example of such directives and how to 413 handle them. 415 o All registrations MUST state whether or not they employ such 416 "active content", and if they do, they MUST state what steps have 417 been taken to protect users of the media type from harm. 419 o Complex media types may include provisions for directives that 420 institute actions which, while not directly harmful to the 421 recipient, may result in disclosure of information that either 422 facilitates a subsequent attack or else violates a recipient's 423 privacy in some way. Again, the registration of the application/ 424 postscript media type illustrates how such directives can be 425 handled. 427 o A media type might be targeted for applications that require some 428 sort of security assurance but not provide the necessary security 429 mechanisms themselves. For example, a media type could be defined 430 for storage of confidential medical information which in turn 431 requires an external confidentiality service, or which is designed 432 for use only within a secure environment. 434 3.2.7 Usage and Implementation Non-requirements 436 In the asynchronous mail environment, where information on the 437 capabilities of the remote mail agent is frequently not available to 438 the sender, maximum interoperability is attained by restricting the 439 number of media types used to those "common" formats expected to be 440 widely implemented. This was asserted in the past as a reason to 441 limit the number of possible media types and resulted in a 442 registration process with a significant hurdle and delay for those 443 registering media types. 445 However, the need for "common" media types does not require limiting 446 the registration of new media types. If a limited set of media types 447 is recommended for a particular application, that should be asserted 448 by a separate applicability statement specific for the application 449 and/or environment. 451 As such, universal support and implementation of a media type is NOT 452 a requirement for registration. If, however, a media type is 453 explicitly intended for limited use, this SHOULD be noted in its 454 registration. 456 3.2.8 Publication Requirements 458 Proposals for media types registered in the standards tree by the 459 IETF itself MUST be published as RFCs. RFC publication of vendor and 460 personal media type proposals is encouraged but not required. In all 461 cases the IANA will retain copies of all media type proposals and 462 "publish" them as part of the media types registration tree itself. 464 As stated previously, standards tree registrations for media types 465 defined in documents produced by other standards bodies MUST be 466 described by a formal standards specification produced by that body. 468 Other than IETF registrations in the standards tree, the registration 469 of a data type does not imply endorsement, approval, or 470 recommendation by the IANA or the IETF or even certification that the 471 specification is adequate. To become Internet Standards, protocol, 472 data objects, or whatever must go through the IETF standards process. 473 This is too difficult and too lengthy a process for the convenient 474 registration of media types. 476 The stanards tree exists for media types that do require require a 477 substantive review and approval process in a recognized standards 478 body. The vendor and personal trees exist for those media types that 479 do not require such a process. It is expected that applicability 480 statements for particular applications will be published from time to 481 time in the IETF that recommend implementation of, and support for, 482 media types that have proven particularly useful in those contexts. 484 As discussed above, registration of a top-level type requires 485 standards-track processing in the IETF and, hence, RFC publication. 487 3.2.9 Additional Information 489 Various sorts of optional information SHOULD be included in the 490 specification of a media type if it is available: 492 o Magic number(s) (length, octet values). Magic numbers are byte 493 sequences that are always present and thus can be used to identify 494 entities as being of a given media type. 496 o File extension(s) commonly used on one or more platforms to 497 indicate that some file containing a given type of media. 499 o Macintosh File Type code(s) (4 octets) used to label files 500 containing a given type of media. 502 o Information about how fragment/anchor identifiers RFC 2396 [4] are 503 constructed for use in conjunction with this media type. 505 In the case of a registration in the standards tree this additional 506 information MAY be provided in the formal specification of the media 507 type. It is suggested that this be done by incorporating the IANA 508 media type registration form into the specification itself. 510 3.3 Registration Procedure 512 The following procedure has been implemented by the IANA for review 513 and approval of new media types. This is not a formal standards 514 process, but rather an administrative procedure intended to allow 515 community comment and sanity checking without excessive time delay. 517 The normal IETF processes should be followed for all registrations in 518 the standards tree, with the posting of an internet-draft being a 519 necessary first step. 521 Proposed registrations in the standards tree by other standards 522 bodies should be communicated to the IESG (at iesg@ietf.org). 524 Registrations in the vendor and personal tree may be submitted 525 directly to the IANA. 527 3.3.1 Preliminary Community Review 529 In all cases notice of a potential media type registration may be 530 sent to the "ietf-types@iana.org" mailing list for review. This 531 mailing list has been established for the purpose of reviewing 532 proposed media and access types. 534 The intent of the public posting is to solicit comments and feedback 535 on the choice of type/subtype name, the unambiguity of the references 536 with respect to versions and external profiling information, and a 537 review of any interoperability or security considerations. The 538 submitter may submit a revised registration, or abandon the 539 registration completely, at any time. 541 3.3.2 IESG Approval 543 Media types registered in the standards tree MUST be approved by the 544 IESG prior to registration. 546 3.3.3 IANA Registration 548 Provided that the media type meets all of the relevant requirements 549 and has obtained whateveer approval is necessary, the author may 550 submit the registration request to the IANA. Registration requests 551 must be sent to iana@iana.org. Sending to ietf-types@iana.org does 552 not constitute submitting the registration to the IANA. 554 When the registration is part of an RFC publication request, close 555 coordination between the IANA and the IESG means IESG approval in 556 effect submits the registration to the IANA. There is no need for an 557 additional registration request in such cases. 559 3.3.4 Media Types Reviewer 561 Registrations submitted to the IANA will be passed on to the media 562 types reviewer. The media types reviewer, who is appointed by the 563 IETF Applications Area Director(s), will review the registration to 564 make sure it meets the requirements set forth in this document. 565 Registrations which do not meet these requirements will be returned 566 to the submitter for revision. 568 Decisions made by the media types reviewer may be appealed to the 569 IESG. 571 Once a media type registration has passed review the IANA will 572 register the media type and make the media type registration 573 available to the community. 575 3.4 Comments on Media Type Registrations 577 Comments on registered media types may be submitted by members of the 578 community to the IANA. These comments will be reviewed by the media 579 types reviewer and then passed on to the "owner" of the media type if 580 possible. Submitters of comments may request that their comment be 581 attached to the media type registration itself, and if the IANA 582 approves of this the comment will be made accessible in conjunction 583 with the type registration itself. 585 3.5 Location of Registered Media Type List 587 Media type registrations are listed by the IANA at http:// 588 www.iana.org/assignments/media-types/index.html. 590 3.6 IANA Procedures for Registering Media Types 592 The IANA will only register media types in the standards tree in 593 response to a communication from the IESG stating that a given 594 registration has been approved. Vendor and personal types will be 595 registered by the IANA automatically and without any formal review as 596 long as the following minimal conditions are met: 598 o Media types MUST function as an actual media format. In 599 particular, charsets and transfer encodings MUST NOT be registered 600 as media types. 602 o All media types MUST have properly formed type and subtype names. 603 All type names MUST be defined by a standards-track RFC. All 604 subtype names MUST be unique, must conform to the MIME grammar for 605 such names, and MUST contain the proper tree prefix. 607 o Types registered in the personal tree MUST either provide a format 608 specification or a pointer to one. 610 o All media types MUST have a reasonable security considerations 611 section. (It is neither possible nor necessary for the IANA to 612 conduct a comprehensive security review of media type 613 registrations. Nevertheless, the IANA has the authority to 614 identify obviously incompetent material and exclude it.) 616 o Registrations in the standards tree MUST satisfy the additional 617 requirement that they originate from another standards body 618 recognized as such by the IETF. 620 3.7 Change Procedures 622 Once a content type has been published by the IANA, the owner may 623 request a change to its definition. The descriptions of the 624 different registration trees above designate the "owners" of each 625 type of registration. The same procedure as would be appropriate for 626 the original registration request is used to process a change 627 request. 629 Changes should be requested only when there are serious omissions or 630 errors in the published specification. When review is required, a 631 change request may be denied if it renders entities that were valid 632 under the previous definition invalid under the new definition. 634 The owner of a content type may pass responsibility for the content 635 type to another person or agency by informing the IANA and the 636 ietf-types list; this can be done without discussion or review. 638 The IESG may reassign responsibility for a media type. The most 639 common case of this will be to enable changes to be made to types 640 where the author of the registration has died, moved out of contact 641 or is otherwise unable to make changes that are important to the 642 community. 644 Media type registrations may not be deleted; media types which are no 645 longer believed appropriate for use can be declared OBSOLETE by a 646 change to their "intended use" field; such media types will be 647 clearly marked in the lists published by the IANA. 649 3.8 Registration Template 650 To: ietf-types@iana.org 651 Subject: Registration of MIME media type XXX/YYY 653 MIME media type name: 655 MIME subtype name: 657 Required parameters: 659 Optional parameters: 661 Encoding considerations: 663 Security considerations: 665 Interoperability considerations: 667 Published specification: 669 Applications which use this media type: 671 Additional information: 673 Magic number(s): 674 File extension(s): 675 Macintosh File Type Code(s): 677 Person & email address to contact for further information: 679 Intended usage: 681 (One of COMMON, LIMITED USE or OBSOLETE) 683 Author/Change controller: 685 (Any other information that the author deems interesting may be 686 added below this line.) 688 4. External Body Access Types 690 RFC 2046 [2] defines the message/external-body media type, whereby a 691 MIME entity can act as pointer to the actual body data in lieu of 692 including the data directly in the entity body. Each message/ 693 external-body reference specifies an access type, which determines 694 the mechanism used to retrieve the actual body data. RFC 2046 695 defines an initial set of access types, but allows for the 696 registration of additional access types to accommodate new retrieval 697 mechanisms. 699 4.1 Registration Requirements 701 New access type specifications MUST conform to a number of 702 requirements as described below. 704 4.1.1 Naming Requirements 706 Each access type MUST have a unique name. This name appears in the 707 access-type parameter in the message/external-body content-type 708 header field, and MUST conform to MIME content type parameter syntax. 710 4.1.2 Mechanism Specification Requirements 712 All of the protocols, transports, and procedures used by a given 713 access type MUST be described, either in the specification of the 714 access type itself or in some other publicly available specification, 715 in sufficient detail for the access type to be implemented by any 716 competent implementor. Use of secret and/or proprietary methods in 717 access types are expressly prohibited. The restrictions imposed by 718 RFC 2026 [5] on the standardization of patented algorithms must be 719 respected as well. 721 4.1.3 Publication Requirements 723 All access types MUST be described by an RFC. The RFC may be 724 informational rather than standards-track, although standard-track 725 review and approval are encouraged for all access types. 727 4.1.4 Security Requirements 729 Any known security issues that arise from the use of the access type 730 MUST be completely and fully described. It is not required that the 731 access type be secure or that it be free from risks, but that the 732 known risks be identified. Publication of a new access type does not 733 require an exhaustive security review, and the security 734 considerations section is subject to continuing evaluation. 735 Additional security considerations SHOULD be addressed by publishing 736 revised versions of the access type specification. 738 4.2 Registration Procedure 740 Registration of a new access type starts with the the publication of 741 the specification as an internet-draft. 743 4.2.1 Present the Access Type to the Community 745 Send a proposed access type specification to the 746 "ietf-types@iana.org" mailing list for a two week review period. 747 This mailing list has been established for the purpose of reviewing 748 proposed access and media types. Proposed access types are not 749 formally registered and must not be used. 751 The intent of the public posting is to solicit comments and feedback 752 on the access type specification and a review of any security 753 considerations. 755 4.2.2 Access Type Reviewer 757 When the two week period has passed, the access type reviewer, who is 758 appointed by the IETF Applications Area Director, either forwards the 759 request to iana@isi.edu, or rejects it because of significant 760 objections raised on the list. 762 Decisions made by the reviewer must be posted to the ietf-types 763 mailing list within 14 days. Decisions made by the reviewer may be 764 appealed to the IESG. 766 4.2.3 IANA Registration 768 Provided that the access type has either passed review or has been 769 successfully appealed to the IESG, the IANA will register the access 770 type and make the registration available to the community. The 771 specification of the access type must also be published as an RFC. 773 4.3 Location of Registered Access Type List 775 Access type registrations are listed by the IANA on the web page 776 http://www.iana.org/assignments/access-types 778 4.4 IANA Procedures for Registering Access Types 780 The identity of the access type reviewer is communicated to the IANA 781 by the IESG. The IANA then only acts in response to access type 782 definitions that either are approved by the access type reviewer and 783 forwarded by the reviewer to the IANA for registration, or in 784 response to a communication from the IESG that an access type 785 definition appeal has overturned the access type reviewer's ruling. 787 5. Transfer Encodings 789 Transfer encodings are tranformations applied to MIME media types 790 after conversion to the media type's canonical form. Transfer 791 encodings are used for several purposes: 793 o Many transports, especially message transports, can only handle 794 data consisting of relatively short lines of text. There can also 795 be severe restrictions on what characters can be used in these 796 lines of text -- some transports are restricted to a small subset 797 of US-ASCII and others cannot handle certain character sequences. 798 Transfer encodings are used to transform binary data into textual 799 form that can survive such transports. Examples of this sort of 800 transfer encoding include the base64 and quoted-printable transfer 801 encodings defined in RFC 2045 [1]. 803 o Image, audio, video, and even application entities are sometimes 804 quite large. Compression algorithms are often quite effective in 805 reducing the size of large entities. Transfer encodings can be 806 used to apply general-purpose non-lossy compression algorithms to 807 MIME entities. 809 o Transport encodings can be defined as a means of representing 810 existing encoding formats in a MIME context. 812 IMPORTANT: The standardization of a large numbers of different 813 transfer encodings is seen as a significant barrier to widespread 814 interoperability and is expressely discouraged. Nevertheless, the 815 following procedure has been defined to provide a means of defining 816 additional transfer encodings, should standardization actually be 817 justified. 819 5.1 Transfer Encoding Requirements 821 Transfer encoding specifications MUST conform to a number of 822 requirements as described below. 824 5.1.1 Naming Requirements 826 Each transfer encoding MUST have a unique name. This name appears in 827 the Content-Transfer-Encoding header field and MUST conform to the 828 syntax of that field. 830 5.1.2 Algorithm Specification Requirements 832 All of the algorithms used in a transfer encoding (e.g., conversion 833 to printable form, compression) MUST be described in their entirety 834 in the transfer encoding specification. Use of secret and/or 835 proprietary algorithms in standardized transfer encodings are 836 expressly prohibited. The restrictions imposed by RFC 2026 [5] on 837 the standardization of patented algorithms MUST be respected as well. 839 5.1.3 Input Domain Requirements 841 All transfer encodings MUST be applicable to an arbitrary sequence of 842 octets of any length. Dependence on particular input forms is not 843 allowed. 845 It should be noted that the 7bit and 8bit encodings do not conform to 846 this requirement. Aside from the undesireability of having 847 specialized encodings, the intent here is to forbid the addition of 848 additional encodings along the lines of 7bit and 8bit. 850 5.1.4 Output Range Requirements 852 There is no requirement that a particular tranfer encoding produce a 853 particular form of encoded output. However, the output format for 854 each transfer encoding MUST be fully and completely documented. In 855 particular, each specification MUST clearly state whether the output 856 format always lies within the confines of 7bit data, 8bit data, or is 857 simply pure binary data. 859 5.1.5 Data Integrity and Generality Requirements 861 All transfer encodings MUST be fully invertible on any platform; it 862 MUST be possible for anyone to recover the original data by 863 performing the corresponding decoding operation. Note that this 864 requirement effectively excludes all forms of lossy compression as 865 well as all forms of encryption from use as a transfer encoding. 867 5.1.6 New Functionality Requirements 869 All transfer encodings MUST provide some sort of new functionality. 870 Some degree of functionality overlap with previously defined transfer 871 encodings is acceptable, but any new transfer encoding MUST also 872 offer something no other transfer encoding provides. 874 5.2 Transfer Encoding Definition Procedure 876 Definition of a new transfer encoding starts with the the publication 877 of the specification as an internet-draft. The draft MUST define the 878 transfer encoding precisely and completely, and MUST also provide 879 substantial justification for defining and standardizing a new 880 transfer encoding. This specification MUST then be presented to the 881 IESG for consideration. The IESG can 882 o reject the specification outright as being inappropriate for 883 standardization, 885 o approve the formation of an IETF working group to work on the 886 specification in accordance with IETF procedures, or, 888 o accept the specification as-is and put it directly on the 889 standards track. 891 Transfer encoding specifications on the standards track follow normal 892 IETF rules for standards track documents. A transfer encoding is 893 considered to be defined and available for use once it is on the 894 standards track. 896 5.3 IANA Procedures for Transfer Encoding Registration 898 There is no need for a special procedure for registering Transfer 899 Encodings with the IANA. All legitimate transfer encoding 900 registrations MUST appear as a standards-track RFC, so it is the 901 IESG's responsibility to notify the IANA when a new transfer encoding 902 has been approved. 904 5.4 Location of Registered Transfer Encodings List 906 The list of transfer encoding registrations can be found at: http:// 907 www.iana.org/assignments/transfer-encodings 909 Normative References 911 [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 912 Extensions (MIME) Part One: Format of Internet Message Bodies", 913 RFC 2045, November 1996. 915 [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 916 Extensions (MIME) Part Two: Media Types", RFC 2046, November 917 1996. 919 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 920 Levels", BCP 14, RFC 2119, March 1997. 922 [4] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 923 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 925 Informative References 927 [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 928 9, RFC 2026, October 1996. 930 [6] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet 931 Mail Extensions (MIME) Part Four: Registration Procedures", BCP 932 13, RFC 2048, November 1996. 934 Authors' Addresses 936 Ned Freed 937 Sun Microsystems 938 1050 Lakes Drive 939 West Covina, CA 91790 940 USA 942 Phone: +1 626 850 4350 943 EMail: ned.freed@mrochek.com 945 John C Klensin 946 1770 Massachusetts Ave, #322 947 Cambridge, MA 02140 949 EMail: klensin@jck.com 951 Appendix A. Grandfathered Media Types 953 A number of media types, registered prior to 1996, would, if 954 registered under the guidelines in this document, be placed into 955 either the vendor or personal trees. Reregistration of those types 956 to reflect the appropriate trees is encouraged, but not required. 957 Ownership and change control principles outlined in this document 958 apply to those types as if they had been registered in the trees 959 described above. 961 Appendix B. Changes made since RFC 2048 963 o Much of the document has been clarified in the light of 964 operational experience with these procedures. 966 o The unfaceted IETF tree is now called the standards tree and the 967 registration rules for this tree have been relaxed to allow use by 968 other standards bodies. 970 o The text describing the media type registration procedure has 971 clarified. 973 o The rules and requirements for constructing security 974 considerations sections have been extended and clarified. 976 Intellectual Property Statement 978 The IETF takes no position regarding the validity or scope of any 979 intellectual property or other rights that might be claimed to 980 pertain to the implementation or use of the technology described in 981 this document or the extent to which any license under such rights 982 might or might not be available; neither does it represent that it 983 has made any effort to identify any such rights. Information on the 984 IETF's procedures with respect to rights in standards-track and 985 standards-related documentation can be found in BCP-11. Copies of 986 claims of rights made available for publication and any assurances of 987 licenses to be made available, or the result of an attempt made to 988 obtain a general license or permission for the use of such 989 proprietary rights by implementors or users of this specification can 990 be obtained from the IETF Secretariat. 992 The IETF invites any interested party to bring to its attention any 993 copyrights, patents or patent applications, or other proprietary 994 rights which may cover technology that may be required to practice 995 this standard. Please address the information to the IETF Executive 996 Director. 998 Full Copyright Statement 1000 Copyright (C) The Internet Society (2003). All Rights Reserved. 1002 This document and translations of it may be copied and furnished to 1003 others, and derivative works that comment on or otherwise explain it 1004 or assist in its implementation may be prepared, copied, published 1005 and distributed, in whole or in part, without restriction of any 1006 kind, provided that the above copyright notice and this paragraph are 1007 included on all such copies and derivative works. However, this 1008 document itself may not be modified in any way, such as by removing 1009 the copyright notice or references to the Internet Society or other 1010 Internet organizations, except as needed for the purpose of 1011 developing Internet standards in which case the procedures for 1012 copyrights defined in the Internet Standards process must be 1013 followed, or as required to translate it into languages other than 1014 English. 1016 The limited permissions granted above are perpetual and will not be 1017 revoked by the Internet Society or its successors or assignees. 1019 This document and the information contained herein is provided on an 1020 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1021 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1022 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1023 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1024 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1026 Acknowledgement 1028 Funding for the RFC Editor function is currently provided by the 1029 Internet Society.