HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 00:37:52 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 13 Dec 1995 23:00:00 GMT ETag: "2e9c57-955f-30cf5af0" Accept-Ranges: bytes Content-Length: 38239 Connection: close Content-Type: text/plain Network Working Group Ned Freed, Innosoft Internet Draft John Postel, ISI Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures December 1995 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 1. Abstract STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US- ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for Internet Draft MIME Registration Procedures December 1995 (1) textual message bodies in character sets other than US-ASCII, (2) non-textual message bodies, (3) multi-part message bodies, and (4) textual header information in character sets other than US-ASCII. These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. In particular, these documents are designed to provide facilities to include multiple parts in a single message, to represent body and header text in character sets other than US-ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio clips, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents. This fourth document, RFC MIME-REG, specifies various IANA registration procedures for the following MIME facilities: (1) media types, (2) character sets, (3) external body access types, (4) content-transfer-encodings. These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC MIME-CONF describes differences and changes from previous versions. Expires June 1996 [Page 2] Internet Draft MIME Registration Procedures December 1995 2. Table of Contents 1 Abstract .............................................. 1 2 Table of Contents ..................................... 3 3 Introduction .......................................... 4 4 Media Type Registration ............................... 4 4.1 Registration Requirements ........................... 5 4.1.1 Functionality Requirements ........................ 5 4.1.2 Naming Requirements ............................... 5 4.1.3 Parameter Requirements ............................ 6 4.1.4 Format and Canonicalization Requirements .......... 6 4.1.5 Interchange Requirements .......................... 7 4.1.6 Security Requirements ............................. 7 4.1.7 Usage and Implementation Requirements ............. 7 4.1.8 Publication Requirements .......................... 8 4.2 Registration Procedure .............................. 8 4.2.1 Present the Media Type to the Community ........... 8 4.2.2 Media Type Reviewer ............................... 9 4.2.3 IANA Registration ................................. 9 4.3 Location of Registered Media Type List .............. 10 4.4 Change Control ...................................... 10 4.5 Registration Template ............................... 11 5 Character Set Registration ............................ 12 5.1 Registration Requirements ........................... 12 5.1.1 Required Characteristics .......................... 12 5.1.2 New Character Sets ................................ 12 5.1.3 Naming Requirements ............................... 13 5.1.4 Usage and Implementation Requirements ............. 13 5.1.5 Publication Requirements .......................... 13 5.2 Registration Procedure .............................. 14 5.2.1 Present the Character Set to the Community ........ 14 5.2.2 Character Set Reviewer ............................ 14 5.2.3 IANA Registration ................................. 15 5.3 Location of Registered Character Set List ........... 15 5.4 Registration Template ............................... 15 6 External Body Access Types ............................ 15 6.1 Registration Requirements ........................... 16 6.1.1 Naming Requirements ............................... 16 6.1.2 Mechanism Specification Requirements .............. 16 6.1.3 Publication Requirements .......................... 16 6.1.4 Security Requirements ............................. 16 6.1.5 Additional Information ............................ 17 6.2 Registration Procedure .............................. 17 6.2.1 Present the Access Type to the Community .......... 17 Expires June 1996 [Page 3] Internet Draft MIME Registration Procedures December 1995 6.2.2 Access Type Reviewer .............................. 18 6.2.3 IANA Registration ................................. 18 6.3 Location of Registered Access Type List ............. 18 7 Transfer Encodings .................................... 18 7.1 Transfer Encoding Requirements ...................... 19 7.1.1 Naming Requirements ............................... 19 7.1.2 Algorithm Specification Requirements .............. 19 7.1.3 Input Domain Requirements ......................... 20 7.1.4 Output Range Requirements ......................... 20 7.1.5 Data Integrity Requirements ....................... 20 7.1.6 New Functionality Requirements .................... 20 7.2 Transfer Encoding Definition Procedure .............. 20 8 Authors' Addresses .................................... 21 3. Introduction Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, MIME [RFC-MIME-IMB] is an open-ended framework and can accommodate additional object types, character sets, and access methods without any changes to the basic protocol. A registration process is needed, however, to ensure that the set of such values is developed in an orderly, well-specified, and public manner. This document defines registration procedures which use the Internet Assigned Numbers Authority (IANA) as a central registry for such values. Historical Note: The registration process for media types was initially defined in the context of the asynchronous Internet mail environment. In this mail environment there is a need to limit the number of possible media types to increase the likelihood of interoperability when the capabilities of the remote mail system are not known. As media types are used in new environments, where the proliferation of media types is not a hindrance to interoperability, the original procedure was excessively restrictive and had to be generalized. 4. Media Type Registration Registration of a new media type or types starts with the construction of a registration proposal. This proposal is Expires June 1996 [Page 4] Internet Draft MIME Registration Procedures December 1995 then circulated and reviewed. The media type is then registered if the proposal is acceptable. The following sections describe requirements and procedures involved. 4.1. Registration Requirements Media type registration proposals are expected to conform to a number of requirements as described below. 4.1.1. Functionality Requirements Media types must function as an actual media format; registration of things that are better thought of as a transfer encoding, as a character set, or as a collection of separate entities of another type is not allowed. For example, although applications exist to decode the base64 transfer encoding [MIME-IMB], base64 cannot be registered as a subtype of application. 4.1.2. Naming Requirements All registered media types must be assigned MIME type and subtype names. The combination of these names then serves to uniquely identify the media type. The choice of top-level type name must take the nature of media type involved into account. For example, media capable of representing still images should be a subtype of the image content type, whereas media capable of representing audio information belongs under the audio content type. See RFC MIME-IMT for additional information on the basic set of top- level types and their characteristics. New subtypes of top-level types must conform to the restrictions of the top-level type, if any. For example, all subtypes of the multipart content type must use the same encapsulation syntax. In some cases a new media type may not "fit" under any currently defined top-level content type. Such cases are expected to be quite rare. However, if such a case arises a new top-level type can be defined to accommodate it. Such a Expires June 1996 [Page 5] Internet Draft MIME Registration Procedures December 1995 definition must be done via standards-track RFC; no other mechanism can be used to define additional top-level content types. 4.1.3. Parameter Requirements Media types may elect to use one or more MIME content type parameters, or some parameters may be automatically made available to the media type by virtue of being a subtype of a content type that defines a set of parameters applicable to any subtype. In either case, the names, values, and meanings of any parameters must be fully specified when the content type and subtype are defind. New parameters should not be defined as a way to introduce new functionality, although new parameters may be defined to convey additional information that does not otherwise change the functionality. An example of this would be a "revision" parameter to indicate a revision level of an external specification such as JPEG or a character set. 4.1.4. Format and Canonicalization Requirements All registered media types must employ a single, canonical data format. A precise and openly available specification of the format of each media type is preferred, and if such a specification is available the media type registration must reference it. However, requiring such a specification for all media types would block the registration of proprietary formats, and as such is unduly restrictive. Therefore this format requirement can be met by the specification of a particular version or versions of a particular software package or packages that understand the format. The appropriateness of using a media type with an unavailable specification should not be an issue in the registration process. Some media types involve the use of patented technology. The registration of such types is specifically allowed. However, the restrictions set forth in RFC 1602 on the use of patented technology in standards-track protocols must be respected when the specification of a media type is part of a standards-track protocol. Expires June 1996 [Page 6] Internet Draft MIME Registration Procedures December 1995 4.1.5. Interchange Requirements Media type should, whenever possible, interoperate across as many systems and applications as possible. However, some media types will inevitably have problems interoperating across different platforms. Problems with different versions, byte ordering, and specifics of gateway handling can and will arise. It is not required that the media type be universally interoperable, but that the known interoperability issues be identified. Publication of a media type does not require an exhaustive review of interoperability, and the interoperability considerations section is subject to continuing evaluation. 4.1.6. Security Requirements Any known security issues that arise from the use of the media type must be completely and fully described. See the registration of the application/postscript media type in RFC MIME-IMT for an example of what sort of security issues can arise from the use of one particular media type. It is not required that the media type be secure or that it be free from risks, but that the known risks be identified. Publication of a media type does not require an exhaustive security review, and the security considerations section is subject to continuing evaluation. 4.1.7. Usage and Implementation Requirements In the asynchronous mail environment, where information on the capabilities of the remote mail agent is not available to the sender, maximum interoperability is attained by restricting the number of media types used to those "common" formats expected to be widely implemented. This was asserted in the past as a reason to limit the number of possible media types and resulted in a registration process with a significant hurdle and delay for those registering media types. However, the need for "common" media types does not require limiting the registration of new media types. If a limited set Expires June 1996 [Page 7] Internet Draft MIME Registration Procedures December 1995 of media types is recommended for a particular application, that should be asserted by a separate applicability statement specific for the application and/or environment. As such, universal support and implementation of a media type is NOT a requirement for registration. If, however, a media type is explicitly intended for limited use, this should be noted in its registration. 4.1.8. Publication Requirements Media type registrations can be published as RFCs, however, RFC publication is not required to register a new media type. The registration of a data type does not imply endorsement, approval, or recommendation by IANA or IETF or even certification that the specification is adequate. To become Internet Standards, protocol, data objects, or whatever must go through the IETF standards process. This is too difficult and too lengthy a process for the convenient registration of media types. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, data types that have proven particularly useful in those contexts. As discussed above, registration of a top-level type requires standards-track processing and, hence, RFC publication. 4.2. Registration Procedure The following procedure has been implemented by the IANA for review and approval of new media types. This is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. 4.2.1. Present the Media Type to the Community Send a proposed media type registration to the "ietf- types@uninett.no" mailing list for a two week review period. This mailing list has been established for the purpose of reviewing proposed media and access types. Proposed media Expires June 1996 [Page 8] Internet Draft MIME Registration Procedures December 1995 types are not formally registered and must not be used; the "x-" prefix specified in RFC MIME-IMB can be used until registration is complete. The intent of the public posting is to solicit comments and feedback on the choice of type/subtype name, the unambiguity of the references with respect to versions and external profiling information, and a review of any interoperability or security considerations. The submitter may submit a revised registration, or withdraw the registration completely, at any time. 4.2.2. Media Type Reviewer When the two week period has passed and the registration proposer is convinced that consensus has been achieved, the registration application should be submitted to IANA and the Media Type Reviewer. The media type reviewer, who is appointed by the IETF Applications Area Director(s), either approves the request for registration or rejects it. Rejection may occur because of significant objections raised on the list or objections raised externally. If the media type reviewer considers the registration sufficiently important and controversial, a last call for comments may be issued to the full IETF. The media type reviewer may also recommend standards track processing (before or after registration) when that appears appropriate and the level of specification of the media type is adequate. Decisions made by the reviewer must be posted to the ietf- types mailing list within 14 days. Decisions made by the reviewer may be appealed to the IESG. 4.2.3. IANA Registration Provided that the media type has either passed review or has been successfully appealed to the IESG, the IANA will register the media type, and make the media type registration available to the community. Expires June 1996 [Page 9] Internet Draft MIME Registration Procedures December 1995 4.3. Location of Registered Media Type List Media type registrations will be posted in the anonymous FTP directory "ftp.isi.edu:in-notes/iana/assignments/media-types" and the media type will be listed in the periodically issued "Assigned Numbers" RFC [RFC-1700]. The media type description and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-1543]). 4.4. Change Control Once a content type has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request: (1) Publish a template on the ietf-types list. (2) Leave at least two weeks for comments. (3) Get acceptance from the type reviewer. (4) Publish using IANA. Changes should be requested only when there are serious omission or errors in the published specification. The reviewer has the right to declare a "serious objection" to a requested change if it renders entities that were valid under the previous definition invalid under the new definition, but is not obliged to do so in all cases. The author of a content type may pass responsibility for the content type to another person or agency by informing IANA and the ietf-types list; this can be done without discussion or review. The IESG may reassign responsibility for a media type. The most common case of this will be to enable changes to be made to types where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community. Media type registrations may not be deleted; media types which are no longer believed appropriate for use can be declared Expires June 1996 [Page 10] Internet Draft MIME Registration Procedures December 1995 OBSOLETE by a change to their "intended use" field; such media types will be clearly marked in the lists published by IANA. 4.5. Registration Template To: ietf-types@uninett.no Subject: Registration of MIME media type XXX/YYY MIME media type name: MIME subtype name: Required parameters: Optional parameters: Encoding considerations: Security considerations: Interoperability considerations: Published specification: Additional information (optional): Magic number(s): File extension(s): Macintosh File Type Code(s): Person & email address to contact for further information: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author/Change controller: (Any other information that the author deems interesting may be added below this line.) Expires June 1996 [Page 11] Internet Draft MIME Registration Procedures December 1995 5. Character Set Registration MIME and other modern Internet protocols are capable of using many different character sets. This in turn means that the ability to label different character sets is essential. This registration procedure exists solely to associate a specific name or names with a given character set. 5.1. Registration Requirements Registered character sets are expected to conform to a number of requirements as described below. 5.1.1. Required Characteristics Registered character sets must conform to the definition of a "character set" given in RFC MIME-IMB. In addition, character sets intended for use in content types under the "text" top- level type must conform to the restrictions on that type described in RFC MIME-IMB. All registered character sets must note whether or not they are suitable for such usage. All registered character sets must be specified in an openly available specification. NOTE: The definition of "character set" in this context is the one given in RFC MIME-IMB. Other, incompatible definitions of "character set" are in use in other communities; please read the definition in MIME-IMB carefully before trying to decide what to register as a character set. 5.1.2. New Character Sets This registration mechanism is not intended to be a vehicle for the definition of entirely new character sets. This is due to the fact that the registration process does NOT contain adequate review mechanisims for such undertakings. As such, only character sets defined by other processes and standards bodies, or specific profiles of such character sets, are eligible for registration. Expires June 1996 [Page 12] Internet Draft MIME Registration Procedures December 1995 5.1.3. Naming Requirements One or more names must be assigned to all registered character sets. Multiple names for the same character set are permitted, but if multiple names are assigned a single primary name for the character set must be identified. All other names are considered to be aliases for the primary name and use of the primary name is preferred over use of any of the aliases. Each name must uniquely identify a single character set. All character set names must be suitable for use as the value of a MIME content type charset parameter and hence must conform to MIME parameter value syntax. This applies even if the specific character set being registered is not suitable for use with "text". 5.1.4. Usage and Implementation Requirements Use of a large number of character sets hampers interoperability. However, the use of a large number of undocumented and/or unlabelled character sets hampers interoperability even more. A character set should therefore be registered ONLY if it adds significant functionality that is valuable to a large community, OR if it documents existing practice in a large community. Note that character sets registered for the second reason should be explicitly marked as being of limited or specialized use. 5.1.5. Publication Requirements Character set registrations can be published in RFCs, however, RFC publication is not required to register a new character set. The registration of a character set does not imply endorsement, approval, or recommendation by the IANA, IESG, or IETF, or even certification that the specification is adequate. It is expected that applicability statements for particular applications will be published from time to time that recommend implementation of, and support for, character sets that have proven particularly useful in those contexts. Expires June 1996 [Page 13] Internet Draft MIME Registration Procedures December 1995 5.2. Registration Procedure The following procedure has been implemented by the IANA for review and approval of new character sets. This is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. 5.2.1. Present the Character Set to the Community Send the proposed character set registration to the "ietf- charsets@innosoft.com" mailing list. This mailing list has been established for the sole purpose of reviewing proposed character set registrations. Proposed character sets are not formally registered and must not be used; the "x-" prefix specified in RFC MIME-IMB can be used until registration is complete. The intent of the public posting is to solicit comments and feedback on the definition of the character set and the name chosen for it over a four week period. 5.2.2. Character Set Reviewer When the two week period has passed and the registration proposer is convinced that consensus has been achieved, the registration application should be submitted to IANA and the Character Set Reviewer. The character set reviewer, who is appointed by the IETF Applications Area Director(s), either approves the request for registration or rejects it. Rejection may occur because of significant objections raised on the list or objections raised externally. If the character set reviewer considers the registration sufficiently important and controversial, a last call for comments may be issued to the full IETF. The character set reviewer may also recommend standards track processing (before or after registration) when that appears appropriate and the level of specification of the character set is adequate. Decisions made by the reviewer must be posted to the ietf- types mailing list within 14 days. Decisions made by the reviewer may be appealed to the IESG. Expires June 1996 [Page 14] Internet Draft MIME Registration Procedures December 1995 5.2.3. IANA Registration Provided that the character set registration has either passed review or has been successfully appealed to the IESG, the IANA will register the character set and make its registration available to the community. 5.3. Location of Registered Character Set List Character set registrations will be posted in the anonymous FTP file "ftp.isi.edu:in-notes/iana/assignments/character- sets" and the character set will be listed in the periodically issued "Assigned Numbers" RFC [RFC-1700]. The description of the character set may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-1543]). 5.4. Registration Template To: ietf-charsets@innosoft.com Subject: Registration of new character set Character set name(s): (All names must be suitable for use as the value of a MIME content-type parameter.) Published specification(s): (A specification for the character set must be openly available that accurately describes what is being registered.) Person & email address to contact for further information: 6. External Body Access Types RFC MIME-IMT defines the message/external-body media type, whereby a MIME entity can act as pointer to the actual body data in lieu of including the data directly in the entity body. Each message/external-body reference specifies an access type, which determines the mechanism used to retrieve the Expires June 1996 [Page 15] Internet Draft MIME Registration Procedures December 1995 actual body data. RFC MIME-IMT defines an initial set of access types, but allows for the registration of additional access types to accommodate new retrieval mechanisms. 6.1. Registration Requirements New access type specifications must conform to a number of requirements as described below. 6.1.1. Naming Requirements Each access type must have a unique name. This name appears in the access-type parameter in the message/external-body content-type header field, and must conform to MIME content type parameter syntax. 6.1.2. Mechanism Specification Requirements All of the protocols, transports, and procedures used by a given access type must be described, either in the specification of the access type itself or in some other publicly available specification, in sufficient detail for the access type to be implemented by any competent implementor. Use of secret and/or proprietary methods in access types are expressly prohibited. The restrictions imposed by RFC 1602 on the standardization of patented algorithms must be respected as well. 6.1.3. Publication Requirements All access types must be described by an RFC. The RFC may be informational rather than standards-track, although standard- track review and approval are encouraged for all access types. 6.1.4. Security Requirements Any known security issues that arise from the use of the access type must be completely and fully described. It is not required that the access type be secure or that it be free from risks, but that the known risks be identified. Expires June 1996 [Page 16] Internet Draft MIME Registration Procedures December 1995 Publication of a new access type does not require an exhaustive security review, and the security considerations section is subject to continuing evaluation. Additional security considerations should be addressed by publishing revised versions of the access type specification. 6.1.5. Additional Information Various sorts of optional information may be included in the specification of a media type if it is available: (1) Magic number(s) (length, octet values). Magic numbers are byte sequences that are always present and thus can be used to identify entities as being of a given media type. (2) File extension(s) commonly used on one or more platforms to indicate that some file containing a given type of media. (3) Macintosh File Type code(s) (4 octets) used to label files containing a given type of media. Such information is often quite useful to implementors and if available should be provided. 6.2. Registration Procedure Registration of a new access type starts with the construction of a draft of an RFC. 6.2.1. Present the Access Type to the Community Send a proposed access type specification to the "ietf- types@uninett.no" mailing list for a two week review period. This mailing list has been established for the purpose of reviewing proposed access and media types. Proposed access types are not formally registered and must not be used. The intent of the public posting is to solicit comments and feedback on the access type specification and a review of any security considerations. Expires June 1996 [Page 17] Internet Draft MIME Registration Procedures December 1995 6.2.2. Access Type Reviewer When the two week period has passed, the access type reviewer, who is appointed by the IETF Applications Area Director, either forwards the request to IANA@ISI.EDU, or rejects it because of significant objections raised on the list. Decisions made by the reviewer must be posted to the ietf- types mailing list within 14 days. Decisions made by the reviewer may be appealed to the IESG. 6.2.3. IANA Registration Provided that the access type has either passed review or has been successfully appealed to the IESG, the IANA will register the access type and make the registration available to the community. The specification of the access type must also be published as an RFC. Informational RFCs are published by sending them to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC-1543]). 6.3. Location of Registered Access Type List Media type registrations will be posted in the anonymous FTP directory "ftp.isi.edu:in-notes/iana/assignments/access-types" and the access type will be listed in the periodically issued "Assigned Numbers" RFC [RFC-1700]. 7. Transfer Encodings Transfer encodings are tranformations applied to MIME media types after conversion to the media type's canonical form. Transfer encodings are used for several purposes: (1) Many transports, especially message transports, can only handle data consisting of relatively short lines of text. There can also be severe restrictions on what characters can be used in these lines of text -- some transports are restricted to a small subset of US-ASCII and others cannot handle certain character sequences. Transfer encodings are used to transform binary data into textual form that can survive such transports. Expires June 1996 [Page 18] Internet Draft MIME Registration Procedures December 1995 Examples of this sort of transfer encoding include the base64 and quoted-printable transfer encodings defined in MIME-IMB. (2) Image, audio, video, and even application entities are sometimes quite large. Compression algorithms are often quite effective in reducing the size of large entities. Transfer encodings can be used to apply general-purpose non-lossy compression algorithms to MIME entities. (3) Transport encodings can be defined as a means of representing existing encoding formats in a MIME context. IMPORTANT: The standardization of a large numbers of different transfer encodings is seen as a significant barrier to widespread interoperability and is expressely discouraged. Nevertheless, the following procedure has been defined to provide a means of defining additional transfer encodings, should standardization actually be justified. 7.1. Transfer Encoding Requirements Transfer encoding specifications must conform to a number of requirements as described below. 7.1.1. Naming Requirements Each transfer encoding must have a unique name. This name appears in the Content-Transfer-Encoding header field and must conform to the syntax of that field. 7.1.2. Algorithm Specification Requirements All of the algorithms used in a transfer encoding (e.g. conversion to printable form, compression) must be described in their entirety in the transfer encoding specification. Use of secret and/or proprietary algorithms in standardized transfer encodings are expressly prohibited. The restrictions imposed by RFC 1602 on the standardization of patented algorithms must be respected as well. Expires June 1996 [Page 19] Internet Draft MIME Registration Procedures December 1995 7.1.3. Input Domain Requirements All transfer encodings must be applicable to an arbitrary sequence of octets of any length. Dependence on particular input forms is not allowed. 7.1.4. Output Range Requirements There is no requirement that a particular tranfer encoding produce a particular form of encoded output. However, the output format for each transfer encoding must be fully and completely documented. In particular, each specification must clearly state whether the output format always lies within the confines of 7bit data, 8bit data, or is simply pure binary data. 7.1.5. Data Integrity Requirements All transfer encodings must be fully invertible on any platform; it must be possible to recover the original data by performing the corresponding decoding operation. Note that this requirement effectively excludes all forms of lossy compression from use as a transfer encoding. 7.1.6. New Functionality Requirements All transfer encodings must provide some sort of new functionality. Some degree of functionality overlap with previously defined transfer encodings is acceptable, but any new transfer encoding must also offer something no other transfer encoding provides. 7.2. Transfer Encoding Definition Procedure Definition of a new transfer encoding starts with the construction of a draft of a standards-track RFC. The RFC must define the transfer encoding precisely and completely, and must also provide substantial justification for defining and standardizing a new transfer encoding. This specification must then be presented to the IESG for consideration. The IESG can Expires June 1996 [Page 20] Internet Draft MIME Registration Procedures December 1995 (1) reject the specification outright as being inappropriate for standardization, (2) approve the formation of an IETF working group to work on the specification in accordance with IETF procedures, or, (3) accept the specification as-is and put it directly on the standards track. Transfer encoding specifications on the standards track follow normal IETF rules for standards track documents. A transfer encoding is considered to be defined and available for use once it is on the standards track. 8. Authors' Addresses For more information, the authors of this document are best contacted via Internet mail: Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA Email: ned@innosoft.com Phone: +1 818 919 3600 Fax: +1 818 919 3614 Jon Postel USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292 USA EMail: Postel@ISI.EDU Phone: +1 310 822 1511 Fax: +1 310 823 6714 Expires June 1996 [Page 21]