idnits 2.17.1 draft-ietf-822ext-mime-reg-01.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-20) 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 (August 27, 1995) is 10464 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 140 looks like a reference -- Missing reference section? 'MIME-IMB' on line 181 looks like a reference -- Missing reference section? 'RFC-1700' on line 684 looks like a reference -- Missing reference section? 'RFC-1543' on line 677 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 August 27, 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 Security Requirements ............................. 6 92 4.1.6 Usage and Implementation Requirements ............. 7 93 4.1.7 Publication Requirements .......................... 7 94 4.2 Registration Procedure .............................. 8 95 4.2.1 Present the Media Type to the Community ........... 8 96 4.2.2 Media Type Reviewer ............................... 8 97 4.2.3 IANA Registration ................................. 9 98 4.3 Location of Registered Media Type List .............. 9 99 4.4 Change Control ...................................... 9 100 4.5 Registration Template ............................... 10 101 5 Character Set Registration ............................ 11 102 5.1 Registration Requirements ........................... 11 103 5.1.1 Required Characteristics .......................... 11 104 5.1.2 New Character Sets ................................ 11 105 5.1.3 Naming Requirements ............................... 12 106 5.1.4 Usage and Implementation Requirements ............. 12 107 5.1.5 Publication Requirements .......................... 12 108 5.2 Registration Procedure .............................. 13 109 5.2.1 Present the Character Set to the Community ........ 13 110 5.2.2 Character Set Reviewer ............................ 13 111 5.2.3 IANA Registration ................................. 14 112 5.3 Location of Registered Character Set List ........... 14 113 5.4 Registration Template ............................... 14 114 6 External Body Access Types ............................ 15 115 6.1 Registration Requirements ........................... 15 116 6.1.1 Naming Requirements ............................... 15 117 6.1.2 Mechanism Specification Requirements .............. 15 118 6.1.3 Publication Requirements .......................... 15 119 6.1.4 Security Requirements ............................. 16 120 6.2 Registration Procedure .............................. 16 121 6.2.1 Present the Access Type to the Community .......... 16 122 6.2.2 Access Type Reviewer .............................. 16 123 6.2.3 IANA Registration ................................. 17 124 6.3 Location of Registered Access Type List ............. 17 125 7 Transfer Encodings .................................... 17 126 7.1 Transfer Encoding Requirements ...................... 18 127 7.1.1 Naming Requirements ............................... 18 128 7.1.2 Algorithm Specification Requirements .............. 18 129 7.1.3 Input Domain Requirements ......................... 18 130 7.1.4 Output Range Requirements ......................... 18 131 7.1.5 Data Integrity Requirements ....................... 19 132 7.1.6 New Functionality Requirements .................... 19 133 7.2 Transfer Encoding Definition Procedure .............. 19 134 8 Authors' Addresses .................................... 20 136 3. Introduction 138 Recent Internet protocols have been carefully designed to be 139 easily extensible in certain areas. In particular, MIME 140 [RFC-MIME-IMB] is an open-ended framework and can accommodate 141 additional object types, character sets, and access methods 142 without any changes to the basic protocol. A registration 143 process is needed, however, to ensure that the set of such 144 values is developed in an orderly, well-specified, and public 145 manner. 147 This document defines registration procedures which use the 148 Internet Assigned Numbers Authority (IANA) as a central 149 registry for such values. 151 Historical Note: The registration process for media types was 152 initially defined in the context of the asynchronous Internet 153 mail environment. In this mail environment there is a need to 154 limit the number of possible media types to increase the 155 likelihood of interoperability when the capabilities of the 156 remote mail system are not known. As media types are used in 157 new environments, where the proliferation of media types is 158 not a hindrance to interoperability, the original procedure 159 was excessively restrictive and had to be generalized. 161 4. Media Type Registration 163 Registration of a new media type or types starts with the 164 construction of a registration proposal. This proposal is 165 then circulated and reviewed. The media type is then 166 registered if the proposal is acceptable. The following 167 sections describe requirements and procedures involved. 169 4.1. Registration Requirements 171 Media type registration proposals are expected to conform to a 172 number of requirements as described below. 174 4.1.1. Functionality Requirements 176 Media types must function as an actual media format; 177 registration of things that are better thought of as a 178 transfer encoding, as a character set, or as a collection of 179 separate objects of another type is not allowed. For example, 180 although applications exist to decode the base64 transfer 181 encoding [MIME-IMB], base64 cannot be registered as a subtype 182 of application. 184 4.1.2. Naming Requirements 186 All registered media types must be assigned MIME type and 187 subtype names. The combination of these names then serves to 188 uniquely identify the media type. 190 The choice of top-level type name must take the nature of 191 media type involved into account. For example, media capable 192 of representing still images should be a subtype of the image 193 content type, whereas media capable of representing audio 194 information belongs under the audio content type. See RFC 195 MIME-IMT for additional information on the basic set of top- 196 level types and their characteristics. 198 New subtypes of top-level types must conform to the 199 restrictions of the top-level type, if any. For example, all 200 subtypes of the multipart content type must use the same 201 encapsulation syntax. 203 In some cases a new media type may not "fit" under any 204 currently defined top-level content type. Such cases are 205 expected to be quite rare. However, if such a case arises a 206 new top-level type can be defined to accommodate it. Such a 207 definition must be done via standards-track RFC; no other 208 mechanism can be used to define additional top-level content 209 types. 211 4.1.3. Parameter Requirements 213 Media types may elect to use one or more MIME content type 214 parameters, or some parameters may be automatically made 215 available to the media type by virtue of being a subtype of a 216 content type that defines a set of parameters applicable to 217 any subtype. In either case, the names, values, and meanings 218 of any parameters must be fully specified. 220 4.1.4. Format and Canonicalization Requirements 222 All registered media types must employ a single, canonical 223 data format. A precise and openly available specification of 224 the format of each media type is preferred, and if such a 225 specification is available the media type registration must 226 reference it. 228 However, requiring such a specification for all media types 229 would block the registration of proprietary formats, and as 230 such is unduly restrictive. Therefore this format requirement 231 can be met by the specification of a particular version or 232 versions of a particular software package or packages that 233 understand the format. The appropriateness of using a media 234 type with an unavailable specification should not be an issue 235 in the registration process. 237 Some media types involve the use of patented technology. The 238 registration of such types is specifically allowed. However, 239 the restrictions set forth in RFC 1602 on the use of patented 240 technology in standards-track protocols must be respected when 241 the specification of a media type is part of a standards-track 242 protocol. 244 4.1.5. Security Requirements 246 Any known security issues that arise from the use of the media 247 type must be completely and fully described. See the 248 registration of the application/postscript media type in RFC 249 MIME-IMT for an example of what sort of security issues can 250 arise from the use of one particular media type. 252 It is not required that the media type be secure or that it be 253 free from risks, but that the known risks be identified. 254 Publication of a media type does not require an exhaustive 255 security review, and the security considerations section is 256 subject to continuing evaluation. 258 4.1.6. Usage and Implementation Requirements 260 In the asynchronous mail environment, where information on the 261 capabilities of the remote mail agent is not available to the 262 sender, maximum interoperability is attained by restricting 263 the number of media types used to those "common" formats 264 expected to be widely implemented. This was asserted in the 265 past as a reason to limit the number of possible media types 266 and resulted in a registration process with a significant 267 hurdle and delay for those registering media types. 269 However, the need for "common" media types does not require 270 limiting the registration of new media types. If a limited set 271 of media types is recommended for a particular application, 272 that should be asserted by a separate applicability statement 273 specific for the application and/or environment. 275 As such, universal support and implementation of a media type 276 is NOT a requirement for registration. If, however, a media 277 type is explicitly intended for limited use, this should be 278 noted in its registration. 280 4.1.7. Publication Requirements 282 Media type registrations can be published as RFCs, however, 283 RFC publication is not required to register a new media type. 285 The registration of a data type does not imply endorsement, 286 approval, or recommendation by IANA or IETF or even 287 certification that the specification is adequate. To become 288 Internet Standards, protocol, data objects, or whatever must 289 go through the IETF standards process. This is too difficult 290 and too lengthy a process for the convenient registration of 291 media types. It is expected that applicability statements for 292 particular applications will be published from time to time 293 that recommend implementation of, and support for, data types 294 that have proven particularly useful in those contexts. 296 As discussed above, registration of a top-level type requires 297 standards-track processing and, hence, RFC publication. 299 4.2. Registration Procedure 301 The following procedure has been implemented by the IANA for 302 review and approval of new media types. This is not a formal 303 standards process, but rather an administrative procedure 304 intended to allow community comment and sanity checking 305 without excessive time delay. 307 4.2.1. Present the Media Type to the Community 309 Send a proposed media type registration to the "ietf- 310 types@uninett.no" mailing list for a two week review period. 311 This mailing list has been established for the purpose of 312 reviewing proposed media and access types. Proposed media 313 types are not formally registered and must not be used; the 314 "x-" prefix specified in RFC MIME-IMB can be used until 315 registration is complete. 317 The intent of the public posting is to solicit comments and 318 feedback on the choice of type/subtype name, the unambiguity 319 of the references with respect to versions and external 320 profiling information, and a review of any security 321 considerations. The submitter may submit a revised 322 registration, or withdraw the registration completely, at any 323 time. 325 4.2.2. Media Type Reviewer 327 When the two week period has passed and the registration 328 proposer is convinced that consensus has been achieved, the 329 registration application should be submitted to IANA and the 330 Media Type Reviewer. The media type reviewer, who is appointed 331 by the IETF Applications Area Director(s), either approves the 332 request for registration or rejects it. Rejection may occur 333 because of significant objections raised on the list or 334 objections raised externally. If the media type reviewer 335 considers the registration sufficiently important and 336 controversial, a last call for comments may be issued to the 337 full IETF. The media type reviewer may also recommend 338 standards track processing (before or after registration) when 339 that appears appropriate and the level of specification of the 340 media type is adequate. 342 Decisions made by the reviewer may be appealed to the IESG. 344 4.2.3. IANA Registration 346 Provided that the media type has either passed review or has 347 been successfully appealed to the IESG, the IANA will register 348 the media type, and make the media type registration 349 available to the community. 351 4.3. Location of Registered Media Type List 353 Media type registrations will be posted in the anonymous FTP 354 directory "ftp.isi.edu:in-notes/iana/assignments/media-types" 355 and the media type will be listed in the periodically issued 356 "Assigned Numbers" RFC [RFC-1700]. The media type description 357 and other supporting material may also be published as an 358 Informational RFC by sending it to "rfc-editor@isi.edu" 359 (please follow the instructions to RFC authors [RFC-1543]). 361 4.4. Change Control 363 Once a content type has been published by IANA, the author may 364 request a change to its definition. The change request follows 365 the same procedure as the registration request: 367 (1) Publish a template on the ietf-types list. 369 (2) Leave at least two weeks for comments. 371 (3) Get acceptance from the type reviewer. 373 (4) Publish using IANA. 375 Changes should be requested only when there are serious 376 omission or errors in the published specification. The 377 reviewer has the right to declare a "serious objection" to a 378 requested change if it renders objects that were valid under 379 the previous definition invalid under the new definition, but 380 is not obliged to do so in all cases. 382 The author of a content type may pass responsibility for the 383 content type to another person or agency by informing IANA and 384 the ietf-types list; this can be done without discussion or 385 review. 387 The IESG may reassign responsibility for a media type. The 388 most common case of this will be to enable changes to be made 389 to types where the author of the registration has died, moved 390 out of contact or is otherwise unable to make changes that are 391 important to the community. 393 Media type registrations may not be deleted; media types which 394 are no longer believed appropriate for use can be declared 395 OBSOLETE by a change to their "intended use" field; such media 396 types will be clearly marked in the lists published by IANA. 398 4.5. Registration Template 400 To: ietf-types@uninett.no 401 Subject: Registration of MIME media type XXX/YYY 403 MIME media type name: 405 MIME subtype name: 407 Required parameters: 409 Optional parameters: 411 Encoding considerations: 413 Security considerations: 415 Published specification: 417 Person & email address to contact for further information: 419 Intended usage: 421 (One of COMMON, LIMITED USE or OBSOLETE) 423 Author/Change controller: 425 (Any other information that the author deems interesting may be 426 added below this line.) 428 5. Character Set Registration 430 MIME and other modern Internet protocols are capable of using 431 many different character sets. This in turn means that the 432 ability to label different character sets is essential. This 433 registration procedure exists solely to associate a specific 434 name or names with a given character set. 436 5.1. Registration Requirements 438 Registered character sets are expected to conform to a number 439 of requirements as described below. 441 5.1.1. Required Characteristics 443 Registered character sets must conform to the definition of a 444 "character set" given in RFC MIME-IMB. In addition, character 445 sets intended for use in content types under the "text" top- 446 level type must conform to the restrictions on that type 447 described in RFC MIME-IMB. All registered character sets must 448 note whether or not they are suitable for such usage. 450 All registered character sets must be specified in an openly 451 available specification. 453 NOTE: The definition of "character set" in this context is the 454 one given in RFC MIME-IMB. Other, incompatible definitions of 455 "character set" are in use in other communities; please read 456 the definition in MIME-IMB carefully before trying to decide 457 what to register as a character set. 459 5.1.2. New Character Sets 461 This registration mechanism is not intended to be a vehicle 462 for the definition of entirely new character sets. This is due 463 to the fact that the registration process does NOT contain 464 adequate review mechanisims for such undertakings. 466 As such, only character sets defined by other processes and 467 standards bodies, or specific profiles of such character sets, 468 are eligible for registration. 470 5.1.3. Naming Requirements 472 One or more names must be assigned to all registered character 473 sets. Multiple names for the same character set are permitted, 474 but if multiple names are assigned a single primary name must 475 be identified. All other names are considered to be aliases 476 for the primary name and use of the primary name is preferred 477 over use of any of the aliases. 479 Each name must uniquely identify a single character set. All 480 character set names must be suitable for use as the value of a 481 MIME content type charset parameter and hence must conform to 482 MIME parameter value syntax. This applies even if the specific 483 character set being registered is not suitable for use with 484 "text". 486 5.1.4. Usage and Implementation Requirements 488 Use of a large number of character sets hampers 489 interoperability. However, the use of a large number of 490 undocumented and/or unlabelled character sets hampers 491 interoperability even more. 493 A character set should therefore be registered ONLY if it adds 494 significant functionality that is valuable to a large 495 community, OR if it documents existing practice in a large 496 community. Note that character sets registered for the second 497 reason should be explicitly marked as being of limited or 498 specialized use. 500 5.1.5. Publication Requirements 502 Character set registrations can be published in RFCs, however, 503 RFC publication is not required to register a new character 504 set. 506 The registration of a character set does not imply 507 endorsement, approval, or recommendation by the IANA, IESG, or 508 IETF, or even certification that the specification is 509 adequate. It is expected that applicability statements for 510 particular applications will be published from time to time 511 that recommend implementation of, and support for, character 512 sets that have proven particularly useful in those contexts. 514 5.2. Registration Procedure 516 The following procedure has been implemented by the IANA for 517 review and approval of new character sets. This is not a 518 formal standards process, but rather an administrative 519 procedure intended to allow community comment and sanity 520 checking without excessive time delay. 522 5.2.1. Present the Character Set to the Community 524 Send the proposed character set registration to the "ietf- 525 charsets@innosoft.com" mailing list. This mailing list has 526 been established for the sole purpose of reviewing proposed 527 character set registrations. Proposed character sets are not 528 formally registered and must not be used; the "x-" prefix 529 specified in RFC MIME-IMB can be used until registration is 530 complete. 532 The intent of the public posting is to solicit comments and 533 feedback on the definition of the character set and the name 534 chosen for it over a four week period. 536 5.2.2. Character Set Reviewer 538 When the two week period has passed and the registration 539 proposer is convinced that consensus has been achieved, the 540 registration application should be submitted to IANA and the 541 Character Set Reviewer. The character set reviewer, who is 542 appointed by the IETF Applications Area Director(s), either 543 approves the request for registration or rejects it. 544 Rejection may occur because of significant objections raised 545 on the list or objections raised externally. If the character 546 set reviewer considers the registration sufficiently important 547 and controversial, a last call for comments may be issued to 548 the full IETF. The character set reviewer may also recommend 549 standards track processing (before or after registration) when 550 that appears appropriate and the level of specification of the 551 character set is adequate. 553 Decisions made by the reviewer may be appealed to the IESG. 555 5.2.3. IANA Registration 557 Provided that the character set registration has either passed 558 review or has been successfully appealed to the IESG, the IANA 559 will register the character set and make its registration 560 available to the community. 562 5.3. Location of Registered Character Set List 564 Character set registrations will be posted in the anonymous 565 FTP file "ftp.isi.edu:in-notes/iana/assignments/character- 566 sets" and the character set will be listed in the periodically 567 issued "Assigned Numbers" RFC [RFC-1700]. The description of 568 the character set may also be published as an Informational 569 RFC by sending it to "rfc-editor@isi.edu" (please follow the 570 instructions to RFC authors [RFC-1543]). 572 5.4. Registration Template 574 To: ietf-charsets@innosoft.com 575 Subject: Registration of new character set 577 Character set name(s): 579 (All names must be suitable for use as the value of a 580 MIME content-type parameter.) 582 Published specification(s): 584 (A specification for the character set must be 585 openly available that accurately describes what 586 is being registered.) 588 Person & email address to contact for further information: 590 6. External Body Access Types 592 RFC MIME-IMT defines the message/external-body media type, 593 whereby a MIME entity can act as pointer to the actual body 594 data in lieu of including the data in a body part. Each 595 message/external-body reference specifies an access type, 596 which determines the mechanism used to retrieve the actual 597 body data. RFC MIME-IMT defines an initial set of access 598 types, but allows for the registration of additional access 599 types to accommodate new retrieval mechanisms. 601 6.1. Registration Requirements 603 New access type specifications must conform to a number of 604 requirements as described below. 606 6.1.1. Naming Requirements 608 Each access type must have a unique name. This name appears 609 in the access-type parameter in the message/external-body 610 content-type header field, and must conform to MIME content 611 type parameter syntax. 613 6.1.2. Mechanism Specification Requirements 615 All of the protocols, transports, and procedures used by a 616 given access type must be described, either in the 617 specification of the access type itself or in some other 618 publicly available specification, in sufficient detail for the 619 access type to be implemented by any competent implementor. 620 Use of secret and/or proprietary methods in access types are 621 expressly prohibited. The restrictions imposed by RFC 1602 on 622 the standardization of patented algorithms must be respected 623 as well. 625 6.1.3. Publication Requirements 627 All access types must be described by an RFC. The RFC may be 628 informational rather than standards-track, although standard- 629 track review and approval are encouraged for all access types. 631 6.1.4. Security Requirements 633 Any known security issues that arise from the use of the 634 access type must be completely and fully described. It is not 635 required that the access type be secure or that it be free 636 from risks, but that the known risks be identified. 637 Publication of a new access type does not require an 638 exhaustive security review, and the security considerations 639 section is subject to continuing evaluation. Additional 640 security considerations should be addressed by publishing 641 revised versions of the access type specification. 643 6.2. Registration Procedure 645 Registration of a new access type starts with the construction 646 of a draft of an RFC. 648 6.2.1. Present the Access Type to the Community 650 Send a proposed access type specification to the "ietf- 651 types@uninett.no" mailing list for a two week review period. 652 This mailing list has been established for the purpose of 653 reviewing proposed access and media types. Proposed access 654 types are not formally registered and must not be used. 656 The intent of the public posting is to solicit comments and 657 feedback on the access type specification and a review of any 658 security considerations. 660 6.2.2. Access Type Reviewer 662 When the two week period has passed, the access type reviewer, 663 who is appointed by the IETF Applications Area Director, 664 either forwards the request to IANA@ISI.EDU, or rejects it 665 because of significant objections raised on the list. 667 Decisions made by the reviewer may be appealed to the IESG. 669 6.2.3. IANA Registration 671 Provided that the access type has either passed review or has 672 been successfully appealed to the IESG, the IANA will register 673 the access type and make the registration available to the 674 community. The specification of the access type must also be 675 published as an RFC. Informational RFCs are published by 676 sending them to "rfc-editor@isi.edu" (please follow the 677 instructions to RFC authors [RFC-1543]). 679 6.3. Location of Registered Access Type List 681 Media type registrations will be posted in the anonymous FTP 682 directory "ftp.isi.edu:in-notes/iana/assignments/access-types" 683 and the access type will be listed in the periodically issued 684 "Assigned Numbers" RFC [RFC-1700]. 686 7. Transfer Encodings 688 Transfer encodings are tranformations applied to MIME media 689 types after conversion to the media type's canonical form. 690 Transfer encodings are used for several purposes: 692 (1) Many transports, especially message transports, can 693 only handle data consisting of relatively short lines 694 of text. There can also be severe restrictions on what 695 characters can be used in these lines of text -- some 696 transports are restricted to a small subset of US-ASCII 697 and others cannot handle certain character sequences. 698 Transfer encodings are used to transform binary data 699 into textual form that can survive such transports. 700 Examples of this sort of transfer encoding include the 701 base64 and quoted-printable transfer encodings defined 702 in MIME-IMB. 704 (2) Image, audio, video, and even application objects are 705 sometimes quite large. Compression algorithms are often 706 quite effective in reducing the size of large objects. 707 Transfer encodings can be used to apply general-purpose 708 non-lossy compression algorithms to MIME objects. 710 (3) Transport encodings can be defined as a means of 711 representing existing encoding formats in a MIME 712 context. 714 IMPORTANT: The standardization of a large numbers of 715 different transfer encodings is seen as a significant barrier 716 to widespread interoperability and is expressely discouraged. 717 Nevertheless, the following procedure has been defined to 718 provide a means of defining additional transfer encodings, 719 should standardization actually be justified. 721 7.1. Transfer Encoding Requirements 723 Transfer encoding specifications must conform to a number of 724 requirements as described below. 726 7.1.1. Naming Requirements 728 Each transfer encoding must have a unique name. This name 729 appears in the Content-Transfer-Encoding header field and must 730 conform to the syntax of that field. 732 7.1.2. Algorithm Specification Requirements 734 All of the algorithms used in a transfer encoding (e.g. 735 conversion to printable form, compression) must be described 736 in their entirety in the transfer encoding specification. Use 737 of secret and/or proprietary algorithms in standardized 738 transfer encodings are expressly prohibited. The restrictions 739 imposed by RFC 1602 on the standardization of patented 740 algorithms must be respected as well. 742 7.1.3. Input Domain Requirements 744 All transfer encodings must be applicable to an arbitrary 745 sequence of octets of any length. Dependence on particular 746 input forms is not allowed. 748 7.1.4. Output Range Requirements 750 There is no requirement that a particular tranfer encoding 751 produce a particular form of encoded output. However, the 752 output format for each transfer encoding must be fully and 753 completely documented. In particular, each specification must 754 clearly state whether the output format always lies within the 755 confines of 7bit data, 8bit data, or is simply pure binary 756 data. 758 7.1.5. Data Integrity Requirements 760 All transfer encodings must be fully invertible on any 761 platform; it must be possible to recover the original data by 762 performing the corresponding decoding operation. Note that 763 this requirement effectively excludes all forms of lossy 764 compression from use as a transfer encoding. 766 7.1.6. New Functionality Requirements 768 All transfer encodings must provide some sort of new 769 functionality. Some degree of functionality overlap with 770 previously defined transfer encodings is acceptable, but any 771 new transfer encoding must also offer something no other 772 transfer encoding provides. 774 7.2. Transfer Encoding Definition Procedure 776 Definition of a new transfer encoding starts with the 777 construction of a draft of a standards-track RFC. The RFC 778 must define the transfer encoding precisely and completely, 779 and must also provide substantial justification for defining 780 and standardizing a new transfer encoding. This specification 781 must then be presented to the IESG for consideration. The 782 IESG can 784 (1) reject the specification outright as being 785 inappropriate for standardization, 787 (2) approve the formation of an IETF working group to work 788 on the specification in accordance with IETF 789 procedures, or, 791 (3) accept the specification as-is and put it directly on 792 the standards track. 794 Transfer encoding specifications on the standards track follow 795 normal IETF rules for standards track documents. A transfer 796 encoding is considered to be defined and available for use 797 once it is on the standards track. 799 8. Authors' Addresses 801 For more information, the authors of this document are best 802 contacted via Internet mail: 804 Ned Freed 805 Innosoft International, Inc. 806 1050 East Garvey Avenue South 807 West Covina, CA 91790 808 USA 810 Email: ned@innosoft.com 811 Phone: +1 818 919 3600 812 Fax: +1 818 919 3614 814 Jon Postel 815 USC/Information Sciences Institute 816 4676 Admiralty Way 817 Marina del Rey, CA 90292 818 USA 820 EMail: Postel@ISI.EDU 821 Phone: +1 310 822 1511 822 Fax: +1 310 823 6714