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