idnits 2.17.1 draft-ietf-822ext-mime-reg-02.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-23) 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.) 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 (December 1995) is 10357 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 142 looks like a reference -- Missing reference section? 'MIME-IMB' on line 183 looks like a reference -- Missing reference section? 'RFC-1700' on line 744 looks like a reference -- Missing reference section? 'RFC-1543' on line 737 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 6 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 Postel, ISI 3 5 Multipurpose Internet Mail Extensions 6 (MIME) Part Four: 8 Registration Procedures 10 December 1995 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) non-textual message bodies, 45 (3) multi-part message bodies, and 47 (4) textual header information in character sets other than 48 US-ASCII. 50 These documents are based on earlier work documented in RFC 51 934, STD 11, and RFC 1049, but extends and revises them. 52 Because RFC 822 said so little about message bodies, these 53 documents are largely orthogonal to (rather than a revision 54 of) RFC 822. 56 In particular, these documents are designed to provide 57 facilities to include multiple parts in a single message, to 58 represent body and header text in character sets other than 59 US-ASCII, to represent formatted multi-font text messages, to 60 represent non-textual material such as images and audio clips, 61 and generally to facilitate later extensions defining new 62 types of Internet mail for use by cooperating mail agents. 64 This fourth document, RFC MIME-REG, specifies various IANA 65 registration procedures for the following MIME facilities: 67 (1) media types, 69 (2) character sets, 71 (3) external body access types, 73 (4) content-transfer-encodings. 75 These documents are revisions of RFCs 1521 and 1522, which 76 themselves were revisions of RFCs 1341 and 1342. An appendix 77 in RFC MIME-CONF describes differences and changes from 78 previous versions. 80 2. Table of Contents 82 1 Abstract .............................................. 1 83 2 Table of Contents ..................................... 3 84 3 Introduction .......................................... 4 85 4 Media Type Registration ............................... 4 86 4.1 Registration Requirements ........................... 5 87 4.1.1 Functionality Requirements ........................ 5 88 4.1.2 Naming Requirements ............................... 5 89 4.1.3 Parameter Requirements ............................ 6 90 4.1.4 Format and Canonicalization Requirements .......... 6 91 4.1.5 Interchange Requirements .......................... 7 92 4.1.6 Security Requirements ............................. 7 93 4.1.7 Usage and Implementation Requirements ............. 7 94 4.1.8 Publication Requirements .......................... 8 95 4.2 Registration Procedure .............................. 8 96 4.2.1 Present the Media Type to the Community ........... 8 97 4.2.2 Media Type Reviewer ............................... 9 98 4.2.3 IANA Registration ................................. 9 99 4.3 Location of Registered Media Type List .............. 10 100 4.4 Change Control ...................................... 10 101 4.5 Registration Template ............................... 11 102 5 Character Set Registration ............................ 12 103 5.1 Registration Requirements ........................... 12 104 5.1.1 Required Characteristics .......................... 12 105 5.1.2 New Character Sets ................................ 12 106 5.1.3 Naming Requirements ............................... 13 107 5.1.4 Usage and Implementation Requirements ............. 13 108 5.1.5 Publication Requirements .......................... 13 109 5.2 Registration Procedure .............................. 14 110 5.2.1 Present the Character Set to the Community ........ 14 111 5.2.2 Character Set Reviewer ............................ 14 112 5.2.3 IANA Registration ................................. 15 113 5.3 Location of Registered Character Set List ........... 15 114 5.4 Registration Template ............................... 15 115 6 External Body Access Types ............................ 15 116 6.1 Registration Requirements ........................... 16 117 6.1.1 Naming Requirements ............................... 16 118 6.1.2 Mechanism Specification Requirements .............. 16 119 6.1.3 Publication Requirements .......................... 16 120 6.1.4 Security Requirements ............................. 16 121 6.1.5 Additional Information ............................ 17 122 6.2 Registration Procedure .............................. 17 123 6.2.1 Present the Access Type to the Community .......... 17 124 6.2.2 Access Type Reviewer .............................. 18 125 6.2.3 IANA Registration ................................. 18 126 6.3 Location of Registered Access Type List ............. 18 127 7 Transfer Encodings .................................... 18 128 7.1 Transfer Encoding Requirements ...................... 19 129 7.1.1 Naming Requirements ............................... 19 130 7.1.2 Algorithm Specification Requirements .............. 19 131 7.1.3 Input Domain Requirements ......................... 20 132 7.1.4 Output Range Requirements ......................... 20 133 7.1.5 Data Integrity Requirements ....................... 20 134 7.1.6 New Functionality Requirements .................... 20 135 7.2 Transfer Encoding Definition Procedure .............. 20 136 8 Authors' Addresses .................................... 21 138 3. Introduction 140 Recent Internet protocols have been carefully designed to be 141 easily extensible in certain areas. In particular, MIME 142 [RFC-MIME-IMB] is an open-ended framework and can accommodate 143 additional object types, character sets, and access methods 144 without any changes to the basic protocol. A registration 145 process is needed, however, to ensure that the set of such 146 values is developed in an orderly, well-specified, and public 147 manner. 149 This document defines registration procedures which use the 150 Internet Assigned Numbers Authority (IANA) as a central 151 registry for such values. 153 Historical Note: The registration process for media types was 154 initially defined in the context of the asynchronous Internet 155 mail environment. In this mail environment there is a need to 156 limit the number of possible media types to increase the 157 likelihood of interoperability when the capabilities of the 158 remote mail system are not known. As media types are used in 159 new environments, where the proliferation of media types is 160 not a hindrance to interoperability, the original procedure 161 was excessively restrictive and had to be generalized. 163 4. Media Type Registration 165 Registration of a new media type or types starts with the 166 construction of a registration proposal. This proposal is 167 then circulated and reviewed. The media type is then 168 registered if the proposal is acceptable. The following 169 sections describe requirements and procedures involved. 171 4.1. Registration Requirements 173 Media type registration proposals are expected to conform to a 174 number of requirements as described below. 176 4.1.1. Functionality Requirements 178 Media types must function as an actual media format; 179 registration of things that are better thought of as a 180 transfer encoding, as a character set, or as a collection of 181 separate entities of another type is not allowed. For 182 example, although applications exist to decode the base64 183 transfer encoding [MIME-IMB], base64 cannot be registered as a 184 subtype of application. 186 4.1.2. Naming Requirements 188 All registered media types must be assigned MIME type and 189 subtype names. The combination of these names then serves to 190 uniquely identify the media type. 192 The choice of top-level type name must take the nature of 193 media type involved into account. For example, media capable 194 of representing still images should be a subtype of the image 195 content type, whereas media capable of representing audio 196 information belongs under the audio content type. See RFC 197 MIME-IMT for additional information on the basic set of top- 198 level types and their characteristics. 200 New subtypes of top-level types must conform to the 201 restrictions of the top-level type, if any. For example, all 202 subtypes of the multipart content type must use the same 203 encapsulation syntax. 205 In some cases a new media type may not "fit" under any 206 currently defined top-level content type. Such cases are 207 expected to be quite rare. However, if such a case arises a 208 new top-level type can be defined to accommodate it. Such a 209 definition must be done via standards-track RFC; no other 210 mechanism can be used to define additional top-level content 211 types. 213 4.1.3. Parameter Requirements 215 Media types may elect to use one or more MIME content type 216 parameters, or some parameters may be automatically made 217 available to the media type by virtue of being a subtype of a 218 content type that defines a set of parameters applicable to 219 any subtype. In either case, the names, values, and meanings 220 of any parameters must be fully specified when the content 221 type and subtype are defind. New parameters should not be 222 defined as a way to introduce new functionality, although new 223 parameters may be defined to convey additional information 224 that does not otherwise change the functionality. An example 225 of this would be a "revision" parameter to indicate a revision 226 level of an external specification such as JPEG or a character 227 set. 229 4.1.4. Format and Canonicalization Requirements 231 All registered media types must employ a single, canonical 232 data format. A precise and openly available specification of 233 the format of each media type is preferred, and if such a 234 specification is available the media type registration must 235 reference it. 237 However, requiring such a specification for all media types 238 would block the registration of proprietary formats, and as 239 such is unduly restrictive. Therefore this format requirement 240 can be met by the specification of a particular version or 241 versions of a particular software package or packages that 242 understand the format. The appropriateness of using a media 243 type with an unavailable specification should not be an issue 244 in the registration process. 246 Some media types involve the use of patented technology. The 247 registration of such types is specifically allowed. However, 248 the restrictions set forth in RFC 1602 on the use of patented 249 technology in standards-track protocols must be respected when 250 the specification of a media type is part of a standards-track 251 protocol. 253 4.1.5. Interchange Requirements 255 Media type should, whenever possible, interoperate across as 256 many systems and applications as possible. However, some media 257 types will inevitably have problems interoperating across 258 different platforms. Problems with different versions, byte 259 ordering, and specifics of gateway handling can and will 260 arise. 262 It is not required that the media type be universally 263 interoperable, but that the known interoperability issues be 264 identified. Publication of a media type does not require an 265 exhaustive review of interoperability, and the 266 interoperability considerations section is subject to 267 continuing evaluation. 269 4.1.6. Security Requirements 271 Any known security issues that arise from the use of the media 272 type must be completely and fully described. See the 273 registration of the application/postscript media type in RFC 274 MIME-IMT for an example of what sort of security issues can 275 arise from the use of one particular media type. 277 It is not required that the media type be secure or that it be 278 free from risks, but that the known risks be identified. 279 Publication of a media type does not require an exhaustive 280 security review, and the security considerations section is 281 subject to continuing evaluation. 283 4.1.7. Usage and Implementation Requirements 285 In the asynchronous mail environment, where information on the 286 capabilities of the remote mail agent is not available to the 287 sender, maximum interoperability is attained by restricting 288 the number of media types used to those "common" formats 289 expected to be widely implemented. This was asserted in the 290 past as a reason to limit the number of possible media types 291 and resulted in a registration process with a significant 292 hurdle and delay for those registering media types. 294 However, the need for "common" media types does not require 295 limiting the registration of new media types. If a limited set 296 of media types is recommended for a particular application, 297 that should be asserted by a separate applicability statement 298 specific for the application and/or environment. 300 As such, universal support and implementation of a media type 301 is NOT a requirement for registration. If, however, a media 302 type is explicitly intended for limited use, this should be 303 noted in its registration. 305 4.1.8. Publication Requirements 307 Media type registrations can be published as RFCs, however, 308 RFC publication is not required to register a new media type. 310 The registration of a data type does not imply endorsement, 311 approval, or recommendation by IANA or IETF or even 312 certification that the specification is adequate. To become 313 Internet Standards, protocol, data objects, or whatever must 314 go through the IETF standards process. This is too difficult 315 and too lengthy a process for the convenient registration of 316 media types. It is expected that applicability statements for 317 particular applications will be published from time to time 318 that recommend implementation of, and support for, data types 319 that have proven particularly useful in those contexts. 321 As discussed above, registration of a top-level type requires 322 standards-track processing and, hence, RFC publication. 324 4.2. Registration Procedure 326 The following procedure has been implemented by the IANA for 327 review and approval of new media types. This is not a formal 328 standards process, but rather an administrative procedure 329 intended to allow community comment and sanity checking 330 without excessive time delay. 332 4.2.1. Present the Media Type to the Community 334 Send a proposed media type registration to the "ietf- 335 types@uninett.no" mailing list for a two week review period. 336 This mailing list has been established for the purpose of 337 reviewing proposed media and access types. Proposed media 338 types are not formally registered and must not be used; the 339 "x-" prefix specified in RFC MIME-IMB can be used until 340 registration is complete. 342 The intent of the public posting is to solicit comments and 343 feedback on the choice of type/subtype name, the unambiguity 344 of the references with respect to versions and external 345 profiling information, and a review of any interoperability or 346 security considerations. The submitter may submit a revised 347 registration, or withdraw the registration completely, at any 348 time. 350 4.2.2. Media Type Reviewer 352 When the two week period has passed and the registration 353 proposer is convinced that consensus has been achieved, the 354 registration application should be submitted to IANA and the 355 Media Type Reviewer. The media type reviewer, who is appointed 356 by the IETF Applications Area Director(s), either approves the 357 request for registration or rejects it. Rejection may occur 358 because of significant objections raised on the list or 359 objections raised externally. If the media type reviewer 360 considers the registration sufficiently important and 361 controversial, a last call for comments may be issued to the 362 full IETF. The media type reviewer may also recommend 363 standards track processing (before or after registration) when 364 that appears appropriate and the level of specification of the 365 media type is adequate. 367 Decisions made by the reviewer must be posted to the ietf- 368 types mailing list within 14 days. Decisions made by the 369 reviewer may be appealed to the IESG. 371 4.2.3. IANA Registration 373 Provided that the media type has either passed review or has 374 been successfully appealed to the IESG, the IANA will register 375 the media type, and make the media type registration 376 available to the community. 378 4.3. Location of Registered Media Type List 380 Media type registrations will be posted in the anonymous FTP 381 directory "ftp.isi.edu:in-notes/iana/assignments/media-types" 382 and the media type will be listed in the periodically issued 383 "Assigned Numbers" RFC [RFC-1700]. The media type description 384 and other supporting material may also be published as an 385 Informational RFC by sending it to "rfc-editor@isi.edu" 386 (please follow the instructions to RFC authors [RFC-1543]). 388 4.4. Change Control 390 Once a content type has been published by IANA, the author may 391 request a change to its definition. The change request follows 392 the same procedure as the registration request: 394 (1) Publish a template on the ietf-types list. 396 (2) Leave at least two weeks for comments. 398 (3) Get acceptance from the type reviewer. 400 (4) Publish using IANA. 402 Changes should be requested only when there are serious 403 omission or errors in the published specification. The 404 reviewer has the right to declare a "serious objection" to a 405 requested change if it renders entities that were valid under 406 the previous definition invalid under the new definition, but 407 is not obliged to do so in all cases. 409 The author of a content type may pass responsibility for the 410 content type to another person or agency by informing IANA and 411 the ietf-types list; this can be done without discussion or 412 review. 414 The IESG may reassign responsibility for a media type. The 415 most common case of this will be to enable changes to be made 416 to types where the author of the registration has died, moved 417 out of contact or is otherwise unable to make changes that are 418 important to the community. 420 Media type registrations may not be deleted; media types which 421 are no longer believed appropriate for use can be declared 422 OBSOLETE by a change to their "intended use" field; such media 423 types will be clearly marked in the lists published by IANA. 425 4.5. Registration Template 427 To: ietf-types@uninett.no 428 Subject: Registration of MIME media type XXX/YYY 430 MIME media type name: 432 MIME subtype name: 434 Required parameters: 436 Optional parameters: 438 Encoding considerations: 440 Security considerations: 442 Interoperability considerations: 444 Published specification: 446 Additional information (optional): 448 Magic number(s): 449 File extension(s): 450 Macintosh File Type Code(s): 452 Person & email address to contact for further information: 454 Intended usage: 456 (One of COMMON, LIMITED USE or OBSOLETE) 458 Author/Change controller: 460 (Any other information that the author deems interesting may be 461 added below this line.) 463 5. Character Set Registration 465 MIME and other modern Internet protocols are capable of using 466 many different character sets. This in turn means that the 467 ability to label different character sets is essential. This 468 registration procedure exists solely to associate a specific 469 name or names with a given character set. 471 5.1. Registration Requirements 473 Registered character sets are expected to conform to a number 474 of requirements as described below. 476 5.1.1. Required Characteristics 478 Registered character sets must conform to the definition of a 479 "character set" given in RFC MIME-IMB. In addition, character 480 sets intended for use in content types under the "text" top- 481 level type must conform to the restrictions on that type 482 described in RFC MIME-IMB. All registered character sets must 483 note whether or not they are suitable for such usage. 485 All registered character sets must be specified in an openly 486 available specification. 488 NOTE: The definition of "character set" in this context is the 489 one given in RFC MIME-IMB. Other, incompatible definitions of 490 "character set" are in use in other communities; please read 491 the definition in MIME-IMB carefully before trying to decide 492 what to register as a character set. 494 5.1.2. New Character Sets 496 This registration mechanism is not intended to be a vehicle 497 for the definition of entirely new character sets. This is due 498 to the fact that the registration process does NOT contain 499 adequate review mechanisims for such undertakings. 501 As such, only character sets defined by other processes and 502 standards bodies, or specific profiles of such character sets, 503 are eligible for registration. 505 5.1.3. Naming Requirements 507 One or more names must be assigned to all registered character 508 sets. Multiple names for the same character set are permitted, 509 but if multiple names are assigned a single primary name for 510 the character set must be identified. All other names are 511 considered to be aliases for the primary name and use of the 512 primary name is preferred over use of any of the aliases. 514 Each name must uniquely identify a single character set. All 515 character set names must be suitable for use as the value of a 516 MIME content type charset parameter and hence must conform to 517 MIME parameter value syntax. This applies even if the specific 518 character set being registered is not suitable for use with 519 "text". 521 5.1.4. Usage and Implementation Requirements 523 Use of a large number of character sets hampers 524 interoperability. However, the use of a large number of 525 undocumented and/or unlabelled character sets hampers 526 interoperability even more. 528 A character set should therefore be registered ONLY if it adds 529 significant functionality that is valuable to a large 530 community, OR if it documents existing practice in a large 531 community. Note that character sets registered for the second 532 reason should be explicitly marked as being of limited or 533 specialized use. 535 5.1.5. Publication Requirements 537 Character set registrations can be published in RFCs, however, 538 RFC publication is not required to register a new character 539 set. 541 The registration of a character set does not imply 542 endorsement, approval, or recommendation by the IANA, IESG, or 543 IETF, or even certification that the specification is 544 adequate. It is expected that applicability statements for 545 particular applications will be published from time to time 546 that recommend implementation of, and support for, character 547 sets that have proven particularly useful in those contexts. 549 5.2. Registration Procedure 551 The following procedure has been implemented by the IANA for 552 review and approval of new character sets. This is not a 553 formal standards process, but rather an administrative 554 procedure intended to allow community comment and sanity 555 checking without excessive time delay. 557 5.2.1. Present the Character Set to the Community 559 Send the proposed character set registration to the "ietf- 560 charsets@innosoft.com" mailing list. This mailing list has 561 been established for the sole purpose of reviewing proposed 562 character set registrations. Proposed character sets are not 563 formally registered and must not be used; the "x-" prefix 564 specified in RFC MIME-IMB can be used until registration is 565 complete. 567 The intent of the public posting is to solicit comments and 568 feedback on the definition of the character set and the name 569 chosen for it over a four week period. 571 5.2.2. Character Set Reviewer 573 When the two week period has passed and the registration 574 proposer is convinced that consensus has been achieved, the 575 registration application should be submitted to IANA and the 576 Character Set Reviewer. The character set reviewer, who is 577 appointed by the IETF Applications Area Director(s), either 578 approves the request for registration or rejects it. 579 Rejection may occur because of significant objections raised 580 on the list or objections raised externally. If the character 581 set reviewer considers the registration sufficiently important 582 and controversial, a last call for comments may be issued to 583 the full IETF. The character set reviewer may also recommend 584 standards track processing (before or after registration) when 585 that appears appropriate and the level of specification of the 586 character set is adequate. 588 Decisions made by the reviewer must be posted to the ietf- 589 types mailing list within 14 days. Decisions made by the 590 reviewer may be appealed to the IESG. 592 5.2.3. IANA Registration 594 Provided that the character set registration has either passed 595 review or has been successfully appealed to the IESG, the IANA 596 will register the character set and make its registration 597 available to the community. 599 5.3. Location of Registered Character Set List 601 Character set registrations will be posted in the anonymous 602 FTP file "ftp.isi.edu:in-notes/iana/assignments/character- 603 sets" and the character set will be listed in the periodically 604 issued "Assigned Numbers" RFC [RFC-1700]. The description of 605 the character set may also be published as an Informational 606 RFC by sending it to "rfc-editor@isi.edu" (please follow the 607 instructions to RFC authors [RFC-1543]). 609 5.4. Registration Template 611 To: ietf-charsets@innosoft.com 612 Subject: Registration of new character set 614 Character set name(s): 616 (All names must be suitable for use as the value of a 617 MIME content-type parameter.) 619 Published specification(s): 621 (A specification for the character set must be 622 openly available that accurately describes what 623 is being registered.) 625 Person & email address to contact for further information: 627 6. External Body Access Types 629 RFC MIME-IMT defines the message/external-body media type, 630 whereby a MIME entity can act as pointer to the actual body 631 data in lieu of including the data directly in the entity 632 body. Each message/external-body reference specifies an access 633 type, which determines the mechanism used to retrieve the 634 actual body data. RFC MIME-IMT defines an initial set of 635 access types, but allows for the registration of additional 636 access types to accommodate new retrieval mechanisms. 638 6.1. Registration Requirements 640 New access type specifications must conform to a number of 641 requirements as described below. 643 6.1.1. Naming Requirements 645 Each access type must have a unique name. This name appears 646 in the access-type parameter in the message/external-body 647 content-type header field, and must conform to MIME content 648 type parameter syntax. 650 6.1.2. Mechanism Specification Requirements 652 All of the protocols, transports, and procedures used by a 653 given access type must be described, either in the 654 specification of the access type itself or in some other 655 publicly available specification, in sufficient detail for the 656 access type to be implemented by any competent implementor. 657 Use of secret and/or proprietary methods in access types are 658 expressly prohibited. The restrictions imposed by RFC 1602 on 659 the standardization of patented algorithms must be respected 660 as well. 662 6.1.3. Publication Requirements 664 All access types must be described by an RFC. The RFC may be 665 informational rather than standards-track, although standard- 666 track review and approval are encouraged for all access types. 668 6.1.4. Security Requirements 670 Any known security issues that arise from the use of the 671 access type must be completely and fully described. It is not 672 required that the access type be secure or that it be free 673 from risks, but that the known risks be identified. 675 Publication of a new access type does not require an 676 exhaustive security review, and the security considerations 677 section is subject to continuing evaluation. Additional 678 security considerations should be addressed by publishing 679 revised versions of the access type specification. 681 6.1.5. Additional Information 683 Various sorts of optional information may be included in the 684 specification of a media type if it is available: 686 (1) Magic number(s) (length, octet values). Magic numbers 687 are byte sequences that are always present and thus can 688 be used to identify entities as being of a given media 689 type. 691 (2) File extension(s) commonly used on one or more 692 platforms to indicate that some file containing a given 693 type of media. 695 (3) Macintosh File Type code(s) (4 octets) used to label 696 files containing a given type of media. 698 Such information is often quite useful to implementors and if 699 available should be provided. 701 6.2. Registration Procedure 703 Registration of a new access type starts with the construction 704 of a draft of an RFC. 706 6.2.1. Present the Access Type to the Community 708 Send a proposed access type specification to the "ietf- 709 types@uninett.no" mailing list for a two week review period. 710 This mailing list has been established for the purpose of 711 reviewing proposed access and media types. Proposed access 712 types are not formally registered and must not be used. 714 The intent of the public posting is to solicit comments and 715 feedback on the access type specification and a review of any 716 security considerations. 718 6.2.2. Access Type Reviewer 720 When the two week period has passed, the access type reviewer, 721 who is appointed by the IETF Applications Area Director, 722 either forwards the request to IANA@ISI.EDU, or rejects it 723 because of significant objections raised on the list. 725 Decisions made by the reviewer must be posted to the ietf- 726 types mailing list within 14 days. Decisions made by the 727 reviewer may be appealed to the IESG. 729 6.2.3. IANA Registration 731 Provided that the access type has either passed review or has 732 been successfully appealed to the IESG, the IANA will register 733 the access type and make the registration available to the 734 community. The specification of the access type must also be 735 published as an RFC. Informational RFCs are published by 736 sending them to "rfc-editor@isi.edu" (please follow the 737 instructions to RFC authors [RFC-1543]). 739 6.3. Location of Registered Access Type List 741 Media type registrations will be posted in the anonymous FTP 742 directory "ftp.isi.edu:in-notes/iana/assignments/access-types" 743 and the access type will be listed in the periodically issued 744 "Assigned Numbers" RFC [RFC-1700]. 746 7. Transfer Encodings 748 Transfer encodings are tranformations applied to MIME media 749 types after conversion to the media type's canonical form. 750 Transfer encodings are used for several purposes: 752 (1) Many transports, especially message transports, can 753 only handle data consisting of relatively short lines 754 of text. There can also be severe restrictions on what 755 characters can be used in these lines of text -- some 756 transports are restricted to a small subset of US-ASCII 757 and others cannot handle certain character sequences. 758 Transfer encodings are used to transform binary data 759 into textual form that can survive such transports. 761 Examples of this sort of transfer encoding include the 762 base64 and quoted-printable transfer encodings defined 763 in MIME-IMB. 765 (2) Image, audio, video, and even application entities are 766 sometimes quite large. Compression algorithms are often 767 quite effective in reducing the size of large entities. 768 Transfer encodings can be used to apply general-purpose 769 non-lossy compression algorithms to MIME entities. 771 (3) Transport encodings can be defined as a means of 772 representing existing encoding formats in a MIME 773 context. 775 IMPORTANT: The standardization of a large numbers of 776 different transfer encodings is seen as a significant barrier 777 to widespread interoperability and is expressely discouraged. 778 Nevertheless, the following procedure has been defined to 779 provide a means of defining additional transfer encodings, 780 should standardization actually be justified. 782 7.1. Transfer Encoding Requirements 784 Transfer encoding specifications must conform to a number of 785 requirements as described below. 787 7.1.1. Naming Requirements 789 Each transfer encoding must have a unique name. This name 790 appears in the Content-Transfer-Encoding header field and must 791 conform to the syntax of that field. 793 7.1.2. Algorithm Specification Requirements 795 All of the algorithms used in a transfer encoding (e.g. 796 conversion to printable form, compression) must be described 797 in their entirety in the transfer encoding specification. Use 798 of secret and/or proprietary algorithms in standardized 799 transfer encodings are expressly prohibited. The restrictions 800 imposed by RFC 1602 on the standardization of patented 801 algorithms must be respected as well. 803 7.1.3. Input Domain Requirements 805 All transfer encodings must be applicable to an arbitrary 806 sequence of octets of any length. Dependence on particular 807 input forms is not allowed. 809 7.1.4. Output Range Requirements 811 There is no requirement that a particular tranfer encoding 812 produce a particular form of encoded output. However, the 813 output format for each transfer encoding must be fully and 814 completely documented. In particular, each specification must 815 clearly state whether the output format always lies within the 816 confines of 7bit data, 8bit data, or is simply pure binary 817 data. 819 7.1.5. Data Integrity Requirements 821 All transfer encodings must be fully invertible on any 822 platform; it must be possible to recover the original data by 823 performing the corresponding decoding operation. Note that 824 this requirement effectively excludes all forms of lossy 825 compression from use as a transfer encoding. 827 7.1.6. New Functionality Requirements 829 All transfer encodings must provide some sort of new 830 functionality. Some degree of functionality overlap with 831 previously defined transfer encodings is acceptable, but any 832 new transfer encoding must also offer something no other 833 transfer encoding provides. 835 7.2. Transfer Encoding Definition Procedure 837 Definition of a new transfer encoding starts with the 838 construction of a draft of a standards-track RFC. The RFC 839 must define the transfer encoding precisely and completely, 840 and must also provide substantial justification for defining 841 and standardizing a new transfer encoding. This specification 842 must then be presented to the IESG for consideration. The 843 IESG can 844 (1) reject the specification outright as being 845 inappropriate for standardization, 847 (2) approve the formation of an IETF working group to work 848 on the specification in accordance with IETF 849 procedures, or, 851 (3) accept the specification as-is and put it directly on 852 the standards track. 854 Transfer encoding specifications on the standards track follow 855 normal IETF rules for standards track documents. A transfer 856 encoding is considered to be defined and available for use 857 once it is on the standards track. 859 8. Authors' Addresses 861 For more information, the authors of this document are best 862 contacted via Internet mail: 864 Ned Freed 865 Innosoft International, Inc. 866 1050 East Garvey Avenue South 867 West Covina, CA 91790 868 USA 870 Email: ned@innosoft.com 871 Phone: +1 818 919 3600 872 Fax: +1 818 919 3614 874 Jon Postel 875 USC/Information Sciences Institute 876 4676 Admiralty Way 877 Marina del Rey, CA 90292 878 USA 880 EMail: Postel@ISI.EDU 881 Phone: +1 310 822 1511 882 Fax: +1 310 823 6714