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