idnits 2.17.1 draft-ietf-822ext-mime-reg-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1996) is 10269 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) -- Missing reference section? 'RFC-MIME-IMB' on line 137 looks like a reference -- Missing reference section? 'MIME-IMB' on line 289 looks like a reference -- Missing reference section? 'RFC-1543' on line 786 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ned Freed, Innosoft 2 Internet Draft John Klensin, MCI 3 John Postel, ISI 5 Multipurpose Internet Mail Extensions 6 (MIME) Part Four: 8 Registration Procedures 10 March 1996 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are 15 working documents of the Internet Engineering Task Force 16 (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet-Drafts as reference material or to cite them other 24 than as a "working draft" or "work in progress". 26 To learn the current status of any Internet-Draft, please 27 check the 1id-abstracts.txt listing contained in the 28 Internet-Drafts Shadow Directories on ds.internic.net (US East 29 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 30 or munnari.oz.au (Pacific Rim). 32 1. Abstract 34 STD 11, RFC 822, defines a message representation protocol 35 specifying considerable detail about US-ASCII message headers, 36 and leaves the message content, or message body, as flat US- 37 ASCII text. This set of documents, collectively called the 38 Multipurpose Internet Mail Extensions, or MIME, redefines the 39 format of messages to allow for 40 (1) textual message bodies in character sets other than 41 US-ASCII, 43 (2) an extensible set of different formats for non-textual 44 message bodies, 46 (3) multi-part message bodies, and 48 (4) textual header information in character sets other than 49 US-ASCII. 51 These documents are based on earlier work documented in RFC 52 934, STD 11, and RFC 1049, but extends and revises them. 53 Because RFC 822 said so little about message bodies, these 54 documents are largely orthogonal to (rather than a revision 55 of) RFC 822. 57 This fourth document, RFC MIME-REG, specifies various IANA 58 registration procedures for the following MIME facilities: 60 (1) media types, 62 (2) external body access types, 64 (3) content-transfer-encodings. 66 Registration of character sets for use in MIME is covered 67 elsewhere and is no longer addressed by this document. 69 These documents are revisions of RFCs 1521 and 1522, which 70 themselves were revisions of RFCs 1341 and 1342. An appendix 71 in RFC MIME-CONF describes differences and changes from 72 previous versions. 74 2. Table of Contents 76 1 Abstract .............................................. 1 77 2 Table of Contents ..................................... 3 78 3 Introduction .......................................... 5 79 4 Media Type Registration ............................... 5 80 4.1 Registration Trees and Subtype Names ................ 5 81 4.1.1 IETF Tree ......................................... 6 82 4.1.2 Vendor Tree ....................................... 6 83 4.1.3 Personal or Vanity Tree ........................... 7 84 4.1.4 Special `x.' Tree ................................. 7 85 4.1.5 Additional Registration Trees ..................... 8 86 4.2 Registration Requirements ........................... 8 87 4.2.1 Functionality Requirement ......................... 8 88 4.2.2 Naming Requirements ............................... 8 89 4.2.3 Parameter Requirements ............................ 9 90 4.2.4 Canonicalization and Format Requirements .......... 10 91 4.2.5 Interchange Recommendations ....................... 10 92 4.2.6 Security Requirements ............................. 11 93 4.2.7 Usage and Implementation Non-requirements ......... 12 94 4.2.8 Publication Requirements .......................... 12 95 4.2.9 Additional Information ............................ 13 96 4.3 Registration Procedure .............................. 14 97 4.3.1 Present the Media Type to the Community for Re- 98 view ............................................... 14 99 4.3.2 IESG Approval ..................................... 14 100 4.3.3 IANA Registration ................................. 15 101 4.4 Comments on Media Type Registrations ................ 15 102 4.5 Location of Registered Media Type List .............. 15 103 4.6 IANA Procedures for Registering Media Types ......... 15 104 4.7 Change Control ...................................... 16 105 4.8 Registration Template ............................... 17 106 5 External Body Access Types ............................ 18 107 5.1 Registration Requirements ........................... 18 108 5.1.1 Naming Requirements ............................... 18 109 5.1.2 Mechanism Specification Requirements .............. 18 110 5.1.3 Publication Requirements .......................... 19 111 5.1.4 Security Requirements ............................. 19 112 5.2 Registration Procedure .............................. 19 113 5.2.1 Present the Access Type to the Community .......... 19 114 5.2.2 Access Type Reviewer .............................. 19 115 5.2.3 IANA Registration ................................. 20 116 5.3 Location of Registered Access Type List ............. 20 117 5.4 IANA Procedures for Registering Access Types ........ 20 118 6 Transfer Encodings .................................... 20 119 6.1 Transfer Encoding Requirements ...................... 21 120 6.1.1 Naming Requirements ............................... 21 121 6.1.2 Algorithm Specification Requirements .............. 21 122 6.1.3 Input Domain Requirements ......................... 22 123 6.1.4 Output Range Requirements ......................... 22 124 6.1.5 Data Integrity and Generality Requirements ........ 22 125 6.1.6 New Functionality Requirements .................... 22 126 6.2 Transfer Encoding Definition Procedure .............. 23 127 6.3 IANA Procedures for Transfer Encoding Registration 128 .................................................... 23 129 6.4 Location of Registered Transfer Encodings List ...... 23 130 7 Authors' Addresses .................................... 24 131 A Grandfathered Media Types ............................. 25 132 B IANA and RFC Editor To-Do List ........................ 25 133 3. Introduction 135 Recent Internet protocols have been carefully designed to be 136 easily extensible in certain areas. In particular, MIME 137 [RFC-MIME-IMB] is an open-ended framework and can accommodate 138 additional object types, character sets, and access methods 139 without any changes to the basic protocol. A registration 140 process is needed, however, to ensure that the set of such 141 values is developed in an orderly, well-specified, and public 142 manner. 144 This document defines registration procedures which use the 145 Internet Assigned Numbers Authority (IANA) as a central 146 registry for such values. 148 Historical Note: The registration process for media types was 149 initially defined in the context of the asynchronous Internet 150 mail environment. In this mail environment there is a need to 151 limit the number of possible media types to increase the 152 likelihood of interoperability when the capabilities of the 153 remote mail system are not known. As media types are used in 154 new environments, where the proliferation of media types is 155 not a hindrance to interoperability, the original procedure 156 was excessively restrictive and had to be generalized. 158 4. Media Type Registration 160 Registration of a new media type or types starts with the 161 construction of a registration proposal. Registration may 162 occur in several different registration trees, which have 163 different requirements as discussed below. In general, the 164 new registration proposal is circulated and reviewed in a 165 fashion appropriate to the tree involved. The media type is 166 then registered if the proposal is acceptable. The following 167 sections describe the requirements and procedures used for 168 each of the different registration trees. 170 4.1. Registration Trees and Subtype Names 172 In order to increase the efficiency and flexibility of the 173 registration process, different structures of subtype names 174 may be registered to accomodate the different natural 175 requirements for, e.g., a subtype that will be recommended for 176 wide support and implementation by the Internet Community or a 177 subtype that is used to move files associated with proprietary 178 software. The following subsections define registration 179 "trees", distinguished by the use of faceted names (e.g., 180 names of the form "tree.subtree...type"). Note that some 181 media types defined prior to this specification do not conform 182 to the naming conventions described below. See Appendix A for 183 a discussion of them. 185 4.1.1. IETF Tree 187 The IETF tree is intended for types of general interest to the 188 Internet Community. Registration in the IETF tree requires 189 approval by the IESG and publication of the media type 190 registration as some form of RFC. 192 Media types in the IETF tree are normally denoted by names 193 that are not explicitly faceted, i.e., do not contain period 194 (".", full stop) characters. 196 The "owner" of a media type registration in the IETF tree is 197 assumed to be the IETF itself. Modification or alteration of 198 the specification requires the same level of processing (e.g. 199 standards track) required for the initial registration. 201 4.1.2. Vendor Tree 203 The vendor tree is used for media types associated with 204 commercially available products. "Vendor" or "producer" are 205 construed as equivalent and very broadly in this context. 207 A registration may be placed in the vendor tree by anyone who 208 has need to interchange files associated with the particular 209 product. However, the registration formally belongs to the 210 vendor or organization producing the software or file format. 211 Changes to the specification will be made at their request, as 212 discussed in subsequent sections. 214 Registrations in the vendor tree will be distinguished by the 215 leading facet "vnd.". That may be followed, at the discretion 216 of the registration, by either a media type name from a well- 217 known producer (e.g., "vnd.mudpie") or by an IANA-approved 218 designation of the producer's name which is then followed by a 219 media type or product designation (e.g., 220 vnd.bigcompany.funnypictures). 222 While public exposure and review of media types to be 223 registered in the vendor tree is not required, using the 224 ietf-types list for review is strongly encouraged to improve 225 the quality of those specifications. Registrations in the 226 vendor tree may be submitted directly to the IANA. 228 4.1.3. Personal or Vanity Tree 230 Registrations for media types created experimentally or as 231 part of products that are not distributed commercially may be 232 registered in the personal or vanity tree. The registrations 233 are distinguished by the leading facet "prs.". 235 The owner of "personal" registrations and associated 236 specifications is the person or entity making the 237 registration, or one to whom responsibility has been 238 transferred as described below. 240 While public exposure and review of media types to be 241 registered in the personal tree is not required, using the 242 ietf-types list for review is strongly encouraged to improve 243 the quality of those specifications. Registrations in the 244 personl tree may be submitted directly to the IANA. 246 4.1.4. Special `x.' Tree 248 For convenience and symmetry with this registration scheme, 249 media type names with "x." as the first facet may be used for 250 the same purposes for which names starting in "x-" are 251 normally used. These types are unregistered, experimental, 252 and should be used only with the active agreement of the 253 parties exchanging them. 255 However, with the simplified registration procedures described 256 above for vendor and personal trees, it should rarely, if 257 ever, be necessary to use unregistered experimental types, and 258 as such use of both "x-" and "x." forms is discouraged. 260 4.1.5. Additional Registration Trees 262 From time to time and as required by the community, the IANA 263 may, with the advice and consent of the IESG, create new top- 264 level registration trees. It is explicitly assumed that these 265 trees may be created for external registration and management 266 by well-known permanent bodies, such as scientific societies 267 for media types specific to the sciences they cover. In 268 general, the quality of review of specifications for one of 269 these additional registration trees is expected to be 270 equivalent to that which IETF would give to registrations in 271 its own tree. Establishment of these new trees will be 272 announced through RFC publication approved by the IESG. 274 4.2. Registration Requirements 276 Media type registration proposals are all expected to conform 277 to various requirements laid out in the following sections. 278 Note that requirement specifics sometimes vary depending on 279 the registration tree, again as detailed in the following 280 sections. 282 4.2.1. Functionality Requirement 284 Media types must function as an actual media format: 285 Registration of things that are better thought of as a 286 transfer encoding, as a character set, or as a collection of 287 separate entities of another type, is not allowed. For 288 example, although applications exist to decode the base64 289 transfer encoding [MIME-IMB], base64 cannot be registered as a 290 media type. 292 This requirement applies regardless of the registration tree 293 involved. 295 4.2.2. Naming Requirements 297 All registered media types must be assigned MIME type and 298 subtype names. The combination of these names then serves to 299 uniquely identify the media type and the format of the subtype 300 name identifies the registration tree. 302 The choice of top-level type name must take the nature of 303 media type involved into account. For example, media normally 304 used for representing still images should be a subtype of the 305 image content type, whereas media capable of representing 306 audio information belongs under the audio content type. See 307 RFC MIME-IMT for additional information on the basic set of 308 top-level types and their characteristics. 310 New subtypes of top-level types must conform to the 311 restrictions of the top-level type, if any. For example, all 312 subtypes of the multipart content type must use the same 313 encapsulation syntax. 315 In some cases a new media type may not "fit" under any 316 currently defined top-level content type. Such cases are 317 expected to be quite rare. However, if such a case arises a 318 new top-level type can be defined to accommodate it. Such a 319 definition must be done via standards-track RFC; no other 320 mechanism can be used to define additional top-level content 321 types. 323 These requirements apply regardless of the registration tree 324 involved. 326 4.2.3. Parameter Requirements 328 Media types may elect to use one or more MIME content type 329 parameters, or some parameters may be automatically made 330 available to the media type by virtue of being a subtype of a 331 content type that defines a set of parameters applicable to 332 any of its subtypes. In either case, the names, values, and 333 meanings of any parameters must be fully specified when a 334 media type is registered in the IETF tree, and should be 335 specified as completely as possible when media types are 336 registered in the vendor or personal trees. 338 New parameters must not be defined as a way to introduce new 339 functionality in types registered in the IETF tree, although 340 new parameters may be added to convey additional information 341 that does not otherwise change existing functionality. An 342 example of this would be a "revision" parameter to indicate a 343 revision level of an external specification such as JPEG. 344 Similar behavior is encouraged for media types registered in 345 the vendor or personal trees but is not required. 347 4.2.4. Canonicalization and Format Requirements 349 All registered media types must employ a single, canonical 350 data format, regardless of registration tree. 352 A precise and openly available specification of the format of 353 each media type is required for all types registered in the 354 IETF tree and must at a minimum be referenced by, if it isn't 355 actually included in, the media type registration proposal 356 itself. 358 The specifications of format and processing particulars may or 359 may not be publically available for media types registered in 360 the vendor tree, and such registration proposals are 361 explicitly permitted to include only a specification of which 362 software and version produce or process such media types. 363 References to or inclusion of format specifications in 364 registration proposals is encouraged but not required. 366 Format specifications are still required for registration in 367 the personal tree, but may be either published as RFCs or 368 otherwise deposited with IANA. The deposited specifications 369 will meet the same criteria as those required to register a 370 well-known TCP port and, in particular, need not be made 371 public. 373 Some media types involve the use of patented technology. The 374 registration of media types involving patented technology is 375 specifically permitted. However, the restrictions set forth 376 in RFC 1602 on the use of patented technology in standards- 377 track protocols must be respected when the specification of a 378 media type is part of a standards-track protocol. 380 4.2.5. Interchange Recommendations 382 Media types should, whenever possible, interoperate across as 383 many systems and applications as possible. However, some media 384 types will inevitably have problems interoperating across 385 different platforms. Problems with different versions, byte 386 ordering, and specifics of gateway handling can and will 387 arise. 389 Universal interoperability of media types is not required, but 390 known interoperability issues should be identified whenever 391 possible. Publication of a media type does not require an 392 exhaustive review of interoperability, and the 393 interoperability considerations section is subject to 394 continuing evaluation. 396 These recommendations apply regardless of the registration 397 tree involved. 399 4.2.6. Security Requirements 401 An analysis of security issues is required for for all types 402 registered in the IETF Tree. (This is in accordance with the 403 basic requirements for all IETF protocols.) A similar analysis 404 for media types registered in the vendor or personal trees is 405 encouraged but not required. However, regardless of what 406 security analysis has or has not been done, all descriptions 407 of security issues must be as accurate as possible regardless 408 of registration tree. In particular, a statement that there 409 are "no security issues associated with this type" must not be 410 confused with "the security issues associates with this type 411 have not been assessed". 413 There is absolutely no requirement that media types registered 414 in any tree be secure or completely free from risks. 415 Nevertheless, all known security risks must be identified in 416 the registration of a media type, again regardless of 417 registration tree. 419 The security considerations section of all registrations is 420 subject to continuing evaluation and modification, and in 421 particular may be extended by use of the "comments on media 422 types" mechanism described in subsequent sections. 424 Some of the issues that should be looked at in a security 425 analysis of a media type are: 427 (1) Complex media types may include provisions for 428 directives that institute actions on a recipient's 429 files or other resources. In many cases provision is 430 made for originators to specify arbitrary actions in an 431 unrestricted fashion which may then have devastating 432 effects. See the registration of the 433 application/postscript media type in RFC MIME-IMT for 434 an example of such directives and how to handle them. 436 (2) Complex media types may include provisions for 437 directives that institute actions which, while not 438 directly harmful to the recipient, may result in 439 disclosure of information that either facilitates a 440 subsequent attack or else violates a recipient's 441 privacy in some way. Again, the registration of the 442 application/postscript media type illustrates how such 443 directives can be handled. 445 (3) A media type might be targeted for applications that 446 require some sort of security assurance but not provide 447 the necessary security mechanisms themselves. For 448 example, a media type could be defined for storage of 449 confidential medical information which in turn requires 450 an external confidentiality service. 452 4.2.7. Usage and Implementation Non-requirements 454 In the asynchronous mail environment, where information on the 455 capabilities of the remote mail agent is frequently not 456 available to the sender, maximum interoperability is attained 457 by restricting the number of media types used to those 458 "common" formats expected to be widely implemented. This was 459 asserted in the past as a reason to limit the number of 460 possible media types and resulted in a registration process 461 with a significant hurdle and delay for those registering 462 media types. 464 However, the need for "common" media types does not require 465 limiting the registration of new media types. If a limited set 466 of media types is recommended for a particular application, 467 that should be asserted by a separate applicability statement 468 specific for the application and/or environment. 470 As such, universal support and implementation of a media type 471 is NOT a requirement for registration. If, however, a media 472 type is explicitly intended for limited use, this should be 473 noted in its registration. 475 4.2.8. Publication Requirements 477 Proposals for media types registered in the IETF tree must be 478 published as RFCs. RFC publication of vendor and personal 479 media type proposals is encouraged but not required. In all 480 cases IANA will retain copies of all media type proposals and 481 "publish" them as part of the media types registration tree 482 itself. 484 Other than in the IETF tree, the registration of a data type 485 does not imply endorsement, approval, or recommendation by 486 IANA or IETF or even certification that the specification is 487 adequate. To become Internet Standards, protocol, data 488 objects, or whatever must go through the IETF standards 489 process. This is too difficult and too lengthy a process for 490 the convenient registration of media types. 492 The IETF tree exists for media types that do require require a 493 substantive review and approval process with the vendor and 494 personal trees exist for those that do not. It is expected 495 that applicability statements for particular applications will 496 be published from time to time that recommend implementation 497 of, and support for, media types that have proven particularly 498 useful in those contexts. 500 As discussed above, registration of a top-level type requires 501 standards-track processing and, hence, RFC publication. 503 4.2.9. Additional Information 505 Various sorts of optional information may be included in the 506 specification of a media type if it is available: 508 (1) Magic number(s) (length, octet values). Magic numbers 509 are byte sequences that are always present and thus can 510 be used to identify entities as being of a given media 511 type. 513 (2) File extension(s) commonly used on one or more 514 platforms to indicate that some file containing a given 515 type of media. 517 (3) Macintosh File Type code(s) (4 octets) used to label 518 files containing a given type of media. 520 Such information is often quite useful to implementors and if 521 available should be provided. 523 4.3. Registration Procedure 525 The following procedure has been implemented by the IANA for 526 review and approval of new media types. This is not a formal 527 standards process, but rather an administrative procedure 528 intended to allow community comment and sanity checking 529 without excessive time delay. For registration in the IETF 530 tree, the normal IETF processes should be followed, treating 531 posting of an internet-draft and announcement on the ietf- 532 types list (as described in the next subsection) as a first 533 step. For registrations in the vendor or personal tree, the 534 initial review step described below may be omitted and the 535 type registered directly by submitting the template and an 536 explanation directly to IANA (at iana@isi.edu). However, 537 authors of vendor or personal media type specifications are 538 encouraged to seek community review and comment whenever that 539 is feasible. 541 4.3.1. Present the Media Type to the Community for Review 543 Send a proposed media type registration to the "ietf- 544 types@cs.utk.edu" mailing list for a two week review period. 545 This mailing list has been established for the purpose of 546 reviewing proposed media and access types. Proposed media 547 types are not formally registered and must not be used; the 548 "x-" prefix specified in RFC MIME-IMB can be used until 549 registration is complete. 551 The intent of the public posting is to solicit comments and 552 feedback on the choice of type/subtype name, the unambiguity 553 of the references with respect to versions and external 554 profiling information, and a review of any interoperability or 555 security considerations. The submitter may submit a revised 556 registration, or withdraw the registration completely, at any 557 time. 559 4.3.2. IESG Approval 561 Media types registered in the IETF tree must be submitted to 562 the IESG for approval. 564 4.3.3. IANA Registration 566 Provided that the media type meets the requirements for media 567 types and has obtained whateveer approval is necessary, the 568 author may submit the registration request to the IANA, which 569 will register the media type and make the media type 570 registration available to the community. 572 4.4. Comments on Media Type Registrations 574 Comments on registered media types may be submitted by members 575 of the community to IANA. These comments will be passed on to 576 the "owner" of the media type if possible. Submitters of 577 comments may request that their comment be attached to the 578 media type registration itself, and if IANA approves of this 579 the comment will be made accessible in conjunction with the 580 type registration itself. 582 4.5. Location of Registered Media Type List 584 Media type registrations will be posted in the anonymous FTP 585 directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media- 586 types/" and all registered media types will be listed in the 587 periodically issued "Assigned Numbers" RFC [currently RFC- 588 1700]. The media type description and other supporting 589 material may also be published as an Informational RFC by 590 sending it to "rfc-editor@isi.edu" (please follow the 591 instructions to RFC authors [RFC-1543]). 593 4.6. IANA Procedures for Registering Media Types 595 The IANA will only register media types in the IETF tree in 596 response to a communication from the IESG stating that a given 597 registration has been approved. Vendor and personal types will 598 be registered by the IANA automatically and without any formal 599 review as long as the following minimal conditions are met: 601 (1) Media types must function as an actual media format. 602 In particular, character sets and transfer encodings 603 may not be registered as media types. 605 (2) All media types must have properly formed type and 606 subtype names. All type names must be defined by a 607 standards-track RFC. All subtype names must be unique, 608 must conform to the MIME grammar for such names, and 609 must contain the proper tree prefix. 611 (3) Types registered in the personal tree must either 612 provide a format specification or a pointer to one. 614 (4) Any security considerations given must not be obviously 615 bogus. (It is neither possible nor necessary for the 616 IANA to conduct a comprehensive security review of 617 media type registrations. Nevertheless, IANA has the 618 authority to identify obviously incompetent material 619 and exclude it.) 621 4.7. Change Control 623 Once a content type has been published by IANA, the author may 624 request a change to its definition. The descriptions of the 625 different registration trees above designate the "owners" of 626 each type of registration. The change request follows the same 627 procedure as the registration request: 629 (1) Publish the revised template on the ietf-types list. 631 (2) Leave at least two weeks for comments. 633 (3) Publish using IANA after formal review if required. 635 Changes should be requested only when there are serious 636 omission or errors in the published specification. When review 637 is required, a change request may be denied if it renders 638 entities that were valid under the previous definition invalid 639 under the new definition. 641 The owner of a content type may pass responsibility for the 642 content type to another person or agency by informing IANA and 643 the ietf-types list; this can be done without discussion or 644 review. 646 The IESG may reassign responsibility for a media type. The 647 most common case of this will be to enable changes to be made 648 to types where the author of the registration has died, moved 649 out of contact or is otherwise unable to make changes that are 650 important to the community. 652 Media type registrations may not be deleted; media types which 653 are no longer believed appropriate for use can be declared 654 OBSOLETE by a change to their "intended use" field; such media 655 types will be clearly marked in the lists published by IANA. 657 4.8. Registration Template 659 To: ietf-types@cs.utk.edu 660 Subject: Registration of MIME media type XXX/YYY 662 MIME media type name: 664 MIME subtype name: 666 Required parameters: 668 Optional parameters: 670 Encoding considerations: 672 Security considerations: 674 Interoperability considerations: 676 Published specification: 678 Applications which use this media type: 680 Additional information: 682 Magic number(s): 683 File extension(s): 684 Macintosh File Type Code(s): 686 Person & email address to contact for further information: 688 Intended usage: 690 (One of COMMON, LIMITED USE or OBSOLETE) 692 Author/Change controller: 694 (Any other information that the author deems interesting may be 695 added below this line.) 697 5. External Body Access Types 699 RFC MIME-IMT defines the message/external-body media type, 700 whereby a MIME entity can act as pointer to the actual body 701 data in lieu of including the data directly in the entity 702 body. Each message/external-body reference specifies an access 703 type, which determines the mechanism used to retrieve the 704 actual body data. RFC MIME-IMT defines an initial set of 705 access types, but allows for the registration of additional 706 access types to accommodate new retrieval mechanisms. 708 5.1. Registration Requirements 710 New access type specifications must conform to a number of 711 requirements as described below. 713 5.1.1. Naming Requirements 715 Each access type must have a unique name. This name appears 716 in the access-type parameter in the message/external-body 717 content-type header field, and must conform to MIME content 718 type parameter syntax. 720 5.1.2. Mechanism Specification Requirements 722 All of the protocols, transports, and procedures used by a 723 given access type must be described, either in the 724 specification of the access type itself or in some other 725 publicly available specification, in sufficient detail for the 726 access type to be implemented by any competent implementor. 727 Use of secret and/or proprietary methods in access types are 728 expressly prohibited. The restrictions imposed by RFC 1602 on 729 the standardization of patented algorithms must be respected 730 as well. 732 5.1.3. Publication Requirements 734 All access types must be described by an RFC. The RFC may be 735 informational rather than standards-track, although standard- 736 track review and approval are encouraged for all access types. 738 5.1.4. Security Requirements 740 Any known security issues that arise from the use of the 741 access type must be completely and fully described. It is not 742 required that the access type be secure or that it be free 743 from risks, but that the known risks be identified. 744 Publication of a new access type does not require an 745 exhaustive security review, and the security considerations 746 section is subject to continuing evaluation. Additional 747 security considerations should be addressed by publishing 748 revised versions of the access type specification. 750 5.2. Registration Procedure 752 Registration of a new access type starts with the construction 753 of a draft of an RFC. 755 5.2.1. Present the Access Type to the Community 757 Send a proposed access type specification to the "ietf- 758 types@cs.utk.edu" mailing list for a two week review period. 759 This mailing list has been established for the purpose of 760 reviewing proposed access and media types. Proposed access 761 types are not formally registered and must not be used. 763 The intent of the public posting is to solicit comments and 764 feedback on the access type specification and a review of any 765 security considerations. 767 5.2.2. Access Type Reviewer 769 When the two week period has passed, the access type reviewer, 770 who is appointed by the IETF Applications Area Director, 771 either forwards the request to iana@isi.edu, or rejects it 772 because of significant objections raised on the list. 774 Decisions made by the reviewer must be posted to the ietf- 775 types mailing list within 14 days. Decisions made by the 776 reviewer may be appealed to the IESG. 778 5.2.3. IANA Registration 780 Provided that the access type has either passed review or has 781 been successfully appealed to the IESG, the IANA will register 782 the access type and make the registration available to the 783 community. The specification of the access type must also be 784 published as an RFC. Informational RFCs are published by 785 sending them to "rfc-editor@isi.edu" (please follow the 786 instructions to RFC authors [RFC-1543]). 788 5.3. Location of Registered Access Type List 790 Access type registrations will be posted in the anonymous FTP 791 directory "ftp://ftp.isi.edu/in- 792 notes/iana/assignments/access-types/" and all registered 793 access types will be listed in the periodically issued 794 "Assigned Numbers" RFC [currently RFC-1700]. 796 5.4. IANA Procedures for Registering Access Types 798 The identity of the access type reviewer is communicated to 799 the IANA by the IESG. The IANA then only acts in response to 800 access type definitions that either are approved by the access 801 type reviewer and forwarded by the reviewer to the IANA for 802 registration, or in response to a communication from the IESG 803 that an access type definition appeal has overturned the 804 access type reviewer's ruling. 806 6. Transfer Encodings 808 Transfer encodings are tranformations applied to MIME media 809 types after conversion to the media type's canonical form. 810 Transfer encodings are used for several purposes: 812 (1) Many transports, especially message transports, can 813 only handle data consisting of relatively short lines 814 of text. There can also be severe restrictions on what 815 characters can be used in these lines of text -- some 816 transports are restricted to a small subset of US-ASCII 817 and others cannot handle certain character sequences. 818 Transfer encodings are used to transform binary data 819 into textual form that can survive such transports. 820 Examples of this sort of transfer encoding include the 821 base64 and quoted-printable transfer encodings defined 822 in MIME-IMB. 824 (2) Image, audio, video, and even application entities are 825 sometimes quite large. Compression algorithms are often 826 quite effective in reducing the size of large entities. 827 Transfer encodings can be used to apply general-purpose 828 non-lossy compression algorithms to MIME entities. 830 (3) Transport encodings can be defined as a means of 831 representing existing encoding formats in a MIME 832 context. 834 IMPORTANT: The standardization of a large numbers of 835 different transfer encodings is seen as a significant barrier 836 to widespread interoperability and is expressely discouraged. 837 Nevertheless, the following procedure has been defined to 838 provide a means of defining additional transfer encodings, 839 should standardization actually be justified. 841 6.1. Transfer Encoding Requirements 843 Transfer encoding specifications must conform to a number of 844 requirements as described below. 846 6.1.1. Naming Requirements 848 Each transfer encoding must have a unique name. This name 849 appears in the Content-Transfer-Encoding header field and must 850 conform to the syntax of that field. 852 6.1.2. Algorithm Specification Requirements 854 All of the algorithms used in a transfer encoding (e.g. 855 conversion to printable form, compression) must be described 856 in their entirety in the transfer encoding specification. Use 857 of secret and/or proprietary algorithms in standardized 858 transfer encodings are expressly prohibited. The restrictions 859 imposed by RFC 1602 on the standardization of patented 860 algorithms must be respected as well. 862 6.1.3. Input Domain Requirements 864 All transfer encodings must be applicable to an arbitrary 865 sequence of octets of any length. Dependence on particular 866 input forms is not allowed. 868 It should be noted that the 7bit and 8bit encodings do not 869 conform to this requirement. Aside from the undesireability of 870 having specialized encodings, the intent here is to forbid the 871 addition of additional encodings along the lines of 7bit and 872 8bit. 874 6.1.4. Output Range Requirements 876 There is no requirement that a particular tranfer encoding 877 produce a particular form of encoded output. However, the 878 output format for each transfer encoding must be fully and 879 completely documented. In particular, each specification must 880 clearly state whether the output format always lies within the 881 confines of 7bit data, 8bit data, or is simply pure binary 882 data. 884 6.1.5. Data Integrity and Generality Requirements 886 All transfer encodings must be fully invertible on any 887 platform; it must be possible for anyone to recover the 888 original data by performing the corresponding decoding 889 operation. Note that this requirement effectively excludes 890 all forms of lossy compression as well as all forms of 891 encryption from use as a transfer encoding. 893 6.1.6. New Functionality Requirements 895 All transfer encodings must provide some sort of new 896 functionality. Some degree of functionality overlap with 897 previously defined transfer encodings is acceptable, but any 898 new transfer encoding must also offer something no other 899 transfer encoding provides. 901 6.2. Transfer Encoding Definition Procedure 903 Definition of a new transfer encoding starts with the 904 construction of a draft of a standards-track RFC. The RFC 905 must define the transfer encoding precisely and completely, 906 and must also provide substantial justification for defining 907 and standardizing a new transfer encoding. This specification 908 must then be presented to the IESG for consideration. The 909 IESG can 911 (1) reject the specification outright as being 912 inappropriate for standardization, 914 (2) approve the formation of an IETF working group to work 915 on the specification in accordance with IETF 916 procedures, or, 918 (3) accept the specification as-is and put it directly on 919 the standards track. 921 Transfer encoding specifications on the standards track follow 922 normal IETF rules for standards track documents. A transfer 923 encoding is considered to be defined and available for use 924 once it is on the standards track. 926 6.3. IANA Procedures for Transfer Encoding Registration 928 There is no need for a special procedure for registering 929 Transfer Encodings with the IANA. All legitimate transfer 930 encoding registrations must appear as a standards-track RFC, 931 so it is the IESG's responsibility to notify the IANA when a 932 new transfer encoding has been approved. 934 6.4. Location of Registered Transfer Encodings List 936 Transfer encoding registrations will be posted in the 937 anonymous FTP directory "ftp://ftp.isi.edu/in- 938 notes/iana/assignments/transfer-encodings/" and all registered 939 transfer encodings will be listed in the periodically issued 940 "Assigned Numbers" RFC [currently RFC-1700]. 942 7. Authors' Addresses 944 For more information, the authors of this document are best 945 contacted via Internet mail: 947 Ned Freed 948 Innosoft International, Inc. 949 1050 East Garvey Avenue South 950 West Covina, CA 91790 951 USA 953 Email: ned@innosoft.com 954 Phone: +1 818 919 3600 955 Fax: +1 818 919 3614 957 John Klensin, WG Chair 958 MCI 959 2100 Reston Parkway 960 Reston, VA 22091 962 Email: klensin@mci.net 963 Phone: +1 703 715-7361 964 Fax: +1 703 715-7436 966 Jon Postel 967 USC/Information Sciences Institute 968 4676 Admiralty Way 969 Marina del Rey, CA 90292 970 USA 972 EMail: Postel@ISI.EDU 973 Phone: +1 310 822 1511 974 Fax: +1 310 823 6714 975 Appendix A -- Grandfathered Media Types 977 A number of media types, registered prior to 1996, would, if 978 registered under the guidelines in this document, be placed 979 into either the vendor or personal trees. Reregistration of 980 those types to reflect the appropriate trees is encouraged, 981 but not required. Ownership and change control principles 982 outlined in this document apply to those types as if they had 983 been registered in the trees described above. 985 Appendix B -- IANA and RFC Editor To-Do List 987 VERY IMPORTANT NOTE: This appendix is intended to communicate 988 various editorial and procedural tasks the IANA and the RFC 989 Editor should undertake prior to publication of this document 990 as an RFC. This appendix should NOT appear in the actual RFC 991 version of this document! 993 This document refers to the media types mailing list ietf- 994 types@cs.utk.edu. There is no guarantee that cs.utk.edu will 995 continue to be able to accomodate this list throughout the 996 lifetime of this document. As such, this reference should be 997 replaced by an address of the general form ietf- 998 types@iana.org. The actual list can then either be moved to 999 this location or forwarders can be installed to redirect 1000 traffic to the host that currently maintains the list. 1002 The "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer- 1003 encodings/" area does not exist at the present time and needs 1004 to be created. At the time of this writing the only valid 1005 transfer-encodings are 1007 (1) 7bit 1009 (2) 8bit 1011 (3) binary 1013 (4) quoted-printable, and 1014 (5) base64, 1016 and all of them are defined by this set of documents. 1018 The "ftp://ftp.isi.edu/in-notes/iana/assignments/access- 1019 types/" area does not exist at the present time and needs to 1020 be created. At the time of this writing the only valid 1021 access-types are 1023 (1) ftp 1025 (2) anon-ftp 1027 (3) tftp 1029 (4) local-file, and 1031 (5) mail-server, 1033 and all of them are defined by this set of documents.