idnits 2.17.1 draft-ietf-822ext-mime-reg-00.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-16) 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 (May 5, 1995) is 10574 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 141 looks like a reference -- Missing reference section? 'MIME-IMB' on line 184 looks like a reference -- Missing reference section? 'RFC-1700' on line 756 looks like a reference -- Missing reference section? 'RFC-1543' on line 628 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 May 5, 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 61 fragments, and generally to facilitate later extensions 62 defining new types of Internet mail for use by cooperating 63 mail agents. 65 This fourth document, RFC MIME-REG, specifies various IANA 66 registration procedures for the following MIME entities: 68 (1) media types, 70 (2) character sets, 72 (3) external body access types, 74 (4) content-transfer-encodings. 76 These documents are revisions of RFCs 1521 and 1522, which 77 themselves were revisions of RFCs 1341 and 1342. An appendix 78 in RFC MIME-CONF describes differences and changes from 79 previous versions. 81 2. Table of Contents 83 1 Abstract .............................................. 1 84 2 Table of Contents ..................................... 3 85 3 Introduction .......................................... 4 86 4 Media Type Registration ............................... 4 87 4.1 Registration Requirements ........................... 5 88 4.1.1 Functionality Requirements ........................ 5 89 4.1.2 Naming Requirements ............................... 5 90 4.1.3 Parameter Requirements ............................ 6 91 4.1.4 Format and Canonicalization Requirements .......... 6 92 4.1.5 Security Requirements ............................. 6 93 4.1.6 Usage and Implementation Requirements ............. 7 94 4.1.7 Publication Requirements .......................... 7 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 ............................... 8 98 4.2.3 IANA Registration ................................. 9 99 4.3 Location of Registered Media Type List .............. 9 100 4.4 Registration Template ............................... 9 101 5 Character Set Registration ............................ 10 102 5.1 Registration Requirements ........................... 10 103 5.1.1 Required Characteristics .......................... 10 104 5.1.2 New Character Sets ................................ 10 105 5.1.3 Naming Requirements ............................... 11 106 5.1.4 Usage and Implementation Requirements ............. 11 107 5.1.5 Publication Requirements .......................... 11 108 5.2 Registration Procedure .............................. 12 109 5.2.1 Present the Character Set to the Community ........ 12 110 5.2.2 Character Set Reviewer ............................ 12 111 5.2.3 IANA Registration ................................. 13 112 5.3 Location of Registered Character Set List ........... 13 113 5.4 Registration Template ............................... 13 114 6 External Body Access Types ............................ 13 115 6.1 Registration Requirements ........................... 14 116 6.1.1 Naming Requirements ............................... 14 117 6.1.2 Mechanism Specification Requirements .............. 14 118 6.1.3 Publication Requirements .......................... 14 119 6.1.4 Security Requirements ............................. 14 120 6.2 Registration Procedure .............................. 15 121 6.2.1 Present the Access Type to the Community .......... 15 122 6.2.2 Access Type Reviewer .............................. 15 123 6.2.3 IANA Registration ................................. 15 124 6.3 Location of Registered Access Type List ............. 16 125 7 Transfer Encodings .................................... 16 126 7.1 Registration Requirements ........................... 17 127 7.1.1 Naming Requirements ............................... 17 128 7.1.2 Algorithm Specification Requirements .............. 17 129 7.1.3 Input Domain Requirements ......................... 17 130 7.1.4 Output Range Requirements ......................... 17 131 7.1.5 Data Integrity Requirements ....................... 18 132 7.1.6 New Functionality Requirements .................... 18 133 7.2 Registration Procedure .............................. 18 134 7.3 Location of Registered Transfer Encoding List ....... 19 135 8 Authors' Addresses .................................... 19 137 3. Introduction 139 Recent Internet protocols have been carefully designed to be 140 easily extensible in certain areas. In particular, MIME 141 [RFC-MIME-IMB] is an open-ended framework and can accomodate 142 additional object types, character sets, and access methods 143 without any changes to the basic protocol. A registration 144 process is needed, however, to ensure that the set of such 145 values is developed in an orderly, well-specified, and public 146 manner. 148 This document defines registration procedures which use the 149 Internet Assigned Numbers Authority (IANA) as a central 150 registry for such values. This procedures also addresses the 151 registration requirements needed for the mapping of Object 152 Identifiers (OIDs) for X.400 MHS use to media types. 154 Historical Note: The registration process for media types was 155 initially defined in the context of the asynchronous Internet 156 mail environment. In this mail environment there is a need to 157 limit the number of possible media types to increase the 158 likelihood of interoperability when the capabilities of the 159 remote mail system are not known. As media types are used in 160 new environments, where the proliferation of media types is 161 not a hindrance to interoperability, the original procedure 162 was excessively restrictive and had to be generalized. 164 4. Media Type Registration 166 Registration of a new media type or types starts with the 167 construction of a registration proposal. This proposal is 168 then circulated and reviewed. The media type is then 169 registered if the proposal is acceptable. The following 170 sections describe requirements and procedures involved. 172 4.1. Registration Requirements 174 Media type registration proposals are expected to conform to a 175 number of requirements as described below. 177 4.1.1. Functionality Requirements 179 Media types must function as an actual media format; 180 registration of entities that are better thought of as a 181 transfer encoding, character set, or as a collection of 182 separate objects of another type is not allowed. For example, 183 although applications exist to decode the base64 transfer 184 encoding [MIME-IMB], base64 cannot be registered as a subtype 185 of application. 187 4.1.2. Naming Requirements 189 All registered media types must be assigned a MIME type and 190 subtype names. The combination of these names then serves to 191 uniquely identify the media type. 193 The choice of top-level type name must take the nature of 194 media type involved into account. For example, media capable 195 of representing still images should be a subtype of the image 196 content type, whereas media capable of representing audio 197 information belongs under the audio content type. See RFC 198 MIME-IMT for additional information on the basic set of top- 199 level types and their characteristics. 201 New subtypes of top-level types must conform to the 202 restrictions of the top-level type, if any. For example, all 203 subtypes of the multipart content type must use the same 204 encapsulation syntax. 206 In some cases a new media type may not "fit" under any 207 currently defined top-level content type. Such cases are 208 expected to be quite rare. However, if such a case arises a 209 new top-level type can be defined to accomodate it. Such a 210 definition must be done via standards-track RFC; no other 211 mechanism can be used to define additional top-level content 212 types. 214 4.1.3. Parameter Requirements 216 Media types may elect to use one or more MIME content type 217 parameters, or some parameters may be automatically made 218 available to the media type by virtue of being a subtype of a 219 content type that defines a set of parameters applicable to 220 any subtype. In either case, the names, values, and meanings 221 of any parameters must be fully specified. 223 4.1.4. Format and Canonicalization Requirements 225 All registered media types must employ a single, canonical 226 data format. A precise and openly available specification of 227 the format of each media type is preferred, and if such a 228 specification is available the media type registration must 229 reference it. 231 However, requiring such a specification for all media types 232 would block the registration of proprietary formats, and as 233 such is unduly restrictive. As such, this format requirement 234 can be met by the specification of a particular version or 235 versions of a particular software package or packages that 236 understand the format. The appropriateness of using a media 237 type with an unavailable specification should not be an issue 238 in the registration process. 240 Some media types involve the use of patented technology. The 241 registration of such types is specifically allowed. However, 242 the restrictions set forth in RFC 1602 on the use of patented 243 technology in standards-track protocols must be respected when 244 the specification of a media type is part of a standards-track 245 protocol. 247 4.1.5. Security Requirements 249 Any known security issues that arise from the use of the media 250 type must be completely and fully described. See the 251 registration of the application/postscript media type in RFC 252 MIME-IMT for an example of what sort of security issues can 253 arise from the use of one particular media type. 255 It is not required that the media type be secure or that it be 256 free from risks, but that the known risks be identified. 257 Publication of a media type does not require an exhaustive 258 security review, and the security considerations section is 259 subject to continuing evaluation. Additional security 260 considerations should be periodically published in an RFC by 261 IANA. 263 4.1.6. Usage and Implementation Requirements 265 In the asynchronous mail environment, where information on the 266 capabilities of the remote mail agent is not available to the 267 sender, maximum interoperability is attained by restricting 268 the number of media types used to those "common" formats 269 expected to be widely implemented. This was asserted in the 270 past as a reason to limit the number of possible media types 271 and resulted in a registration process with a significant 272 hurdle and delay for those registering media types. 274 However, the need for "common" media types does not require 275 limiting the registration of new media types. This 276 restriction may, in fact, hinder interoperability by causing 277 separate registration authorities for specific applications 278 which may register values in conflict with or otherwise 279 incompatible with each other. If a limited set of media types 280 is recommended for a particular application, that should be 281 asserted by a separate applicability statement specific for 282 the application and/or environment. 284 As such, universal support and implementation of a media type 285 is NOT a requirement for registration. If, however, a media 286 type is explicitly intended for limited use, this should be 287 noted in its registration. 289 4.1.7. Publication Requirements 291 Media type registrations can be published as RFCs, however, 292 RFC publication is not required to register a new media type. 294 The registration of a data type does not imply endorsement, 295 approval, or recommendation by IANA or IETF or even 296 certification that the specification is adequate. To become 297 Internet Standards, protocol, data objects, or whatever must 298 go through the IETF standards process. This is too difficult 299 and to lengthy a process for the convenient and practical need 300 to register media types. It is expected that applicability 301 statements for particular applications will be published from 302 time to time that recommend implementation of, and support 303 for, data types that have proven particularly useful in those 304 contexts. 306 4.2. Registration Procedure 308 The following procedure has been implemented by the IANA for 309 review and approval of new media types. This is not a formal 310 standards process, but rather an administrative procedure 311 intended to allow community comment and sanity checking 312 without excessive time delay. 314 4.2.1. Present the Media Type to the Community 316 Send a proposed media type registration to the "ietf- 317 types@uninett.no" mailing list for a two week review period. 318 This mailing list has been established for the purpose of 319 reviewing proposed media and access types. Proposed media 320 types are not formally registered and must not be used; the 321 "x-" prefix specified in RFC MIME-IMB can be used until 322 registration is complete. 324 The intent of the public posting is to solicit comments and 325 feedback on the choice of type/subtype name, the unambiguity 326 of the references with respect to versions and external 327 profiling information, the choice of which OIDs to use, and a 328 review of any security considerations. 330 4.2.2. Media Type Reviewer 332 When the two week period has passed, the media type reviewer, 333 who is appointed by the IETF Applications Area Director, 334 either forwards the request to IANA@ISI.EDU, or rejects it 335 because of significant objections raised on the list. 337 Decisions made by the reviewer may be appealed to the IESG. 339 4.2.3. IANA Registration 341 Provided that the media type has either passed review or has 342 been successfully appealed to the IESG, the IANA will register 343 the media type, assign an OID under the IANA branch, and make 344 the media type registration available to the community. 346 4.3. Location of Registered Media Type List 348 Media type registrations will be posted in the anonymous FTP 349 directory "ftp.isi.edu:in-notes/iana/assignments/media-types" 350 and the media type will be listed in the periodically issued 351 "Assigned Numbers" RFC [RFC-1700]. The media type description 352 may also be published as an Informational RFC by sending it to 353 "rfc-editor@isi.edu" (please follow the instructions to RFC 354 authors [RFC-1543]). 356 4.4. Registration Template 358 To: ietf-types@uninett.no 359 Subject: Registration of new MIME media type 361 MIME media type name: 363 (If the the above is not an existing top-level type 364 please explain why an existing type cannot or should 365 not be used.) 367 MIME subtype name: 369 Required parameters: 371 Optional parameters: 373 Encoding considerations: 375 Security considerations: 377 Published specification: 379 (The published specification must be a standards-track RFC 380 if a new top-level type is being defined.) 382 Person & email address to contact for further information: 384 5. Character Set Registration 386 MIME and other modern Internet protocols are capable of using 387 many different character sets. This in turn means that the 388 ability to label different character sets is essential. This 389 registration procedure exists solely to associate a specific 390 name or names with a given character set. 392 5.1. Registration Requirements 394 Registered character sets are expected to conform to a number 395 of requirements as described below. 397 5.1.1. Required Characteristics 399 Registered character sets must conform to the definition of a 400 "character set" given in RFC MIME-IMB. In addition, character 401 sets intended for use in content types under the "text" top- 402 level type must conform to the restrictions on that type 403 described in RFC MIME-IMB. All registered character sets must 404 note whether or not they are suitable for such usage. 406 All registered character sets must be specified in an openly 407 available specification. 409 5.1.2. New Character Sets 411 This registration mechanism is not intended to be a vehicle 412 for the definition of entirely new character sets. This is due 413 to the fact that the registration process does NOT contain 414 adequate review mechanisims for such undertakings. 416 As such, only character sets defined by other processes and 417 standards bodies, or specific profiles of such character sets, 418 are eligible for registration. 420 5.1.3. Naming Requirements 422 One or more names must be assigned to all registered character 423 sets. Multiple names for the same character set are permitted, 424 but each name must uniquely identify a single character set. 425 All character set names must be suitable for use as the value 426 of a MIME content type parameter, e.g. the charset parameter 427 of MIME's text type. 429 5.1.4. Usage and Implementation Requirements 431 In the asynchronous mail environment, where information on the 432 capabilities of the remote mail agent is not available to the 433 sender, maximum interoperability is attained by restricting 434 character sets to a "common" set expected to be widely 435 implemented. This was asserted in the past as a reason to 436 limit the number of possible character sets and resulted in a 437 registration process with a significant hurdle and delay for 438 those registering character sets. 440 However, the need for "common" character sets does not require 441 limiting the registration of new character sets. This 442 restriction may, in fact, hinder interoperability by causing 443 separate registration authorities for specific applications 444 which may register values in conflict with or otherwise 445 incompatible with each other. If a limited set of character 446 sets is recommended for a particular application, that should 447 be asserted by a separate applicability statement specific for 448 the application and/or environment. 450 As such, universal support and implementation of a character 451 set is NOT a requirement for registration. If, however, a 452 character set is explicitly intended for limited use, this 453 should be noted in its registration. 455 5.1.5. Publication Requirements 457 Character set registrations can be published as RFCs, however, 458 RFC publication is not required to register a new character 459 set. 461 The registration of a data type does not imply endorsement, 462 approval, or recommendation by the IANA, IESG, or IETF, or 463 even certification that the specification is adequate. To 464 become Internet Standards, protocol, data objects, or whatever 465 must go through the IETF standards process. This is too 466 difficult and to lengthy a process for the convenient and 467 practical need to register character sets. It is expected 468 that applicability statements for particular applications will 469 be published from time to time that recommend implementation 470 of, and support for, character sets that have proven 471 particularly useful in those contexts. 473 5.2. Registration Procedure 475 The following procedure has been implemented by the IANA for 476 review and approval of new character sets. This is not a 477 formal standards process, but rather an administrative 478 procedure intended to allow community comment and sanity 479 checking without excessive time delay. 481 5.2.1. Present the Character Set to the Community 483 Send the proposed character set registration to the "ietf- 484 charsets@innosoft.com" mailing list. This mailing list has 485 been established for the sole purpose of reviewing proposed 486 character set registrations. Proposed character sets are not 487 formally registered and must not be used; the "x-" prefix 488 specified in RFC MIME-IMB can be used until registration is 489 complete. 491 The intent of the public posting is to solicit comments and 492 feedback on the definition of the character set and the name 493 chosen for it over a four week period. 495 5.2.2. Character Set Reviewer 497 When the four week period has passed, the character set 498 reviewer, who is appointed by the IETF Applications Area 499 Director, either forwards the request to IANA@ISI.EDU, or 500 rejects it because of significant objections raised on the 501 list. 503 Decisions made by the reviewer may be appealed to the IESG. 505 5.2.3. IANA Registration 507 Provided that the character set registration has either passed 508 review or has been successfully appealed to the IESG, the IANA 509 will register the character set and make its registration 510 available to the community. 512 5.3. Location of Registered Character Set List 514 Character set registrations will be posted in the anonymous 515 FTP file "ftp.isi.edu:in-notes/iana/assignments/character- 516 sets" and the character set will be listed in the periodically 517 issued "Assigned Numbers" RFC [RFC-1700]. The description of 518 the character set may also be published as an Informational 519 RFC by sending it to "rfc-editor@isi.edu" (please follow the 520 instructions to RFC authors [RFC-1543]). 522 5.4. Registration Template 524 To: ietf-charsets@innosoft.com 525 Subject: Registration of new character set 527 Character set name(s): 529 (All names must be suitable for use as the value of a 530 MIME content-type parameter.) 532 Published specification(s): 534 (A specification for the character set must be 535 openly available that accurately describes what 536 is being registered.) 538 Person & email address to contact for further information: 540 6. External Body Access Types 542 RFC MIME-IMT defines the message/external-body media type, 543 whereby a body part in a MIME message can act as pointer to 544 the actual body data in lieu of including the data in the body 545 part. Each message/external-body reference specifies an access 546 type, which determines the mechanism used to retrieve the 547 actual body data. RFC MIME-IMT defines an initial set of 548 access types, but allows for the registration of additional 549 access types to accomodate new retrieval mechanisms. 551 6.1. Registration Requirements 553 New access type specifications must conform to a number of 554 requirements as described below. 556 6.1.1. Naming Requirements 558 Each access type must have a unique name. This name appears 559 in the access-type parameter in the message/external-body 560 content-type header field, and must conform to MIME content 561 type parameter syntax. 563 6.1.2. Mechanism Specification Requirements 565 All of the protocols, transports, and procedures used by a 566 given access type must be described, either in the 567 specification of the access type itself or in some other 568 publicly available specification, in sufficient detail for the 569 access type to be implemented by any competent implementor. 570 Use of secret and/or proprietary methods in access types are 571 expressly prohibited. The restrictions imposed by RFC 1602 on 572 the standardization of patented algorithms must be respected 573 as well. 575 6.1.3. Publication Requirements 577 All access types must be described by an RFC. The RFC may be 578 informational rather than standards-track, although standard- 579 track review and approval are encouraged for all access types. 581 6.1.4. Security Requirements 583 Any known security issues that arise from the use of the 584 access type must be completely and fully described. It is not 585 required that the access type be secure or that it be free 586 from risks, but that the known risks be identified. 588 Publication of a new access type does not require an 589 exhaustive security review, and the security considerations 590 section is subject to continuing evaluation. Additional 591 security considerations should be address by publishing 592 revised versions of the access type specification. 594 6.2. Registration Procedure 596 Registration of a new access type starts with the construction 597 of a draft of an RFC. 599 6.2.1. Present the Access Type to the Community 601 Send a proposed access type specification to the "ietf- 602 types@uninett.no" mailing list for a two week review period. 603 This mailing list has been established for the purpose of 604 reviewing proposed access and media types. Proposed access 605 types are not formally registered and must not be used. 607 The intent of the public posting is to solicit comments and 608 feedback on the access type specification and a review of any 609 security considerations. 611 6.2.2. Access Type Reviewer 613 When the two week period has passed, the access type reviewer, 614 who is appointed by the IETF Applications Area Director, 615 either forwards the request to IANA@ISI.EDU, or rejects it 616 because of significant objections raised on the list. 618 Decisions made by the reviewer may be appealed to the IESG. 620 6.2.3. IANA Registration 622 Provided that the access type has either passed review or has 623 been successfully appealed to the IESG, the IANA will register 624 the access type and make the registration available to the 625 community. The specification of the access type must also be 626 published as an RFC. Informational RFCs are published by 627 sending them to "rfc-editor@isi.edu" (please follow the 628 instructions to RFC authors [RFC-1543]). 630 6.3. Location of Registered Access Type List 632 Media type registrations will be posted in the anonymous FTP 633 directory "ftp.isi.edu:in-notes/iana/assignments/access-types" 634 and the access type will be listed in the periodically issued 635 "Assigned Numbers" RFC [RFC-1700]. 637 7. Transfer Encodings 639 Transfer encodings are tranformations applied to MIME media 640 types after conversion to the media type's canonical form. 641 Transfer encodings are used for several purposes: 643 (1) Many transports, especially message transports, can 644 only handle data consisting of relatively short lines 645 of text. There can also be severe restrictions on what 646 characters can be used in these liens of text -- some 647 transports are restricted to a small subset of US-ASCII 648 and others cannot handle certain character sequences. 649 Transfer encodings are used to transform binary data 650 into textual form that can survive such transports. 651 Examples of this sort of transfer encoding include the 652 base64 and quoted-printable transfer encodings defined 653 in MIME-IMB. 655 (2) Image, audio, video, and even application objects are 656 sometimes quite large. Compression algorithms are often 657 quite effective in reducing the size of large objects. 658 Transfer encodings can be used to apply general-purpose 659 non-lossy compression algorithms to MIME objects. 661 (3) Transport encodings can be defined as a means of 662 representing existing encoding formats in a MIME 663 context. 665 IMPORTANT NOTE: The registration of a large numbers of 666 different trnansfer encodings is seen as a significant barrier 667 to widespread interoperability and is expressely discouraged. 668 Nevertheless, the following registration procedure has been 669 defined to provide a means of registering additional transfer 670 encodings, should registration actually be justified. 672 7.1. Registration Requirements 674 Transfer encoding specifications must conform to a number of 675 requirements as described below. 677 7.1.1. Naming Requirements 679 Each transfer encoding must have a unique name. This name 680 appears in the Content-Transfer-Encoding header field and must 681 conform to the syntax of that field. 683 7.1.2. Algorithm Specification Requirements 685 All of the algorithms used in a transfer encoding (e.g. 686 conversion to printable form, compression) must be described 687 in their entirety in the transfer encoding specification. Use 688 of secret and/or proprietary algorithms in transfer encodings 689 are expressly prohibited. The restrictions imposed by RFC 690 1602 on the standardization of patented algorithms must be 691 respected as well. 693 7.1.3. Input Domain Requirements 695 All transfer encodings must be applicable to an arbitrary 696 sequence of octets of any length. Dependence on particular 697 input forms is not allowed. 699 7.1.4. Output Range Requirements 701 There is no requirement that a particular tranfer encoding 702 produce a particular form of encoded output. However, the 703 output format for each transfer encoding must be fully and 704 completely documented. In particular, each specification must 705 clearly state whether the output format is always lies within 706 the confines of 7bit text, 8bit text, or is simply pure binary 707 material. 709 7.1.5. Data Integrity Requirements 711 All transfer encodings must be invertible; it must be possible 712 to recover the original data by performing the corresponding 713 decoding operation. Note that this requirement effectively 714 excludes all forms of lossy compression from use as a transfer 715 encoding. 717 7.1.6. New Functionality Requirements 719 All transfer encodings must provide some sort of new 720 functionality. Some degree of functionality overlap with 721 previously registered transfer encodings is acceptable, but 722 any new transfer encoding must also offer something no other 723 transfer encoding provides. 725 7.2. Registration Procedure 727 Registration of a new transfer encoding starts with the 728 construction of a draft of a standards-track RFC. The RFC 729 must define the transfer encoding precisely and completely, 730 and must also provide substantial justification for defining 731 and standardizing a new transfer encoding. This specfication 732 must then be presented to the IESG for consideration. The 733 IESG can 735 (1) reject the specification outright as being 736 inappropriate for standardization, 738 (2) approve the formation of an IETF working group to work 739 on the specification in accordance with IETF 740 procedures, or, 742 (3) accept the specification as-is and puts it directly on 743 the standards track. 745 Transfer encoding specifications on the standards track follow 746 normal IETF rules for standards track documents. A transfer 747 encoding is considered to be registered once it is on the 748 standards track. 750 7.3. Location of Registered Transfer Encoding List 752 Transfer encoding registrations beyond the basic set defined 753 in MIME-IMB will be posted in the anonymous FTP file 754 "ftp.isi.edu:in-notes/iana/assignments/transfer-encodings" and 755 will be listed in the periodically issued "Assigned Numbers" 756 RFC [RFC-1700]. 758 8. Authors' Addresses 760 For more information, the authors of this document are best 761 contacted via Internet mail: 763 Ned Freed 764 Innosoft International, Inc. 765 1050 East Garvey Avenue South 766 West Covina, CA 91790 767 USA 769 Email: ned@innosoft.com 770 Phone: +1 818 919 3600 771 Fax: +1 818 919 3614 773 Jon Postel 774 USC/Information Sciences Institute 775 4676 Admiralty Way 776 Marina del Rey, CA 90292 777 USA 779 EMail: Postel@ISI.EDU 780 Phone: +1 310 822 1511 781 Fax: +1 310 823 6714