Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures
This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Replaces RFC 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1342: Representation of Non-ASCII Text in Internet Message Headers, RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, RFC 1522: MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text, RFC 1590: Media Type Registration Procedure, RFC 2048: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 21 must, 3 should, 0 may.
2.1 Registration Requirements
- MUSTNew access type specifications MUST conform to the requirements described below.
2.1.1 Naming Requirements
- MUSTEach access type MUST have a unique name.
- MUSTThis 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.
2.1.2 Mechanism Specification Requirements
- MUSTAll 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.
2.1.3 Publication Requirements
- MUSTAll access types MUST be described by an RFC.
2.1.4 Security Requirements
- MUSTAny known security issues that arise from the use of the access type MUST be completely and fully described.
- SHOULDAdditional security considerations SHOULD be addressed by publishing revised versions of the access type specification.
3.1 Transfer Encoding Requirements
- MUSTTransfer encoding specifications MUST conform to the requirements described below.
3.1.1 Naming Requirements
- MUSTEach transfer encoding MUST have a unique name.
- MUSTThis name appears in the Content-Transfer-Encoding header field and MUST conform to the syntax of that field.
3.1.2 Algorithm Specification Requirements
- MUSTAll 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.
- MUSTThe restrictions imposed by [RFC2026] on the standardization of patented algorithms MUST be respected as well.
3.1.3 Input Domain Requirements
- MUSTAll transfer encodings MUST be applicable to an arbitrary sequence of octets of any length.
3.1.4 Output Range Requirements
- MUSTHowever, the output format for each transfer encoding MUST be fully and completely documented.
- MUSTIn particular, each specification MUST clearly state whether the output format always lies within the confines of 7bit or 8bit or is simply pure binary data.
3.1.5 Data Integrity and Generality Requirements
- MUSTAll transfer encodings MUST be fully invertible on any platform; it MUST be possible for anyone to recover the original data by performing the corresponding decoding operation.
3.1.6 New Functionality Requirements
- MUSTAll transfer encodings MUST provide some sort of new functionality.
- MUSTSome 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.
3.1.7 Security Requirements
- SHOULD NOTTo the greatest extent possible, transfer encodings SHOULD NOT contain known security issues.
- MUSTRegardless, any known security issues that arise from the use of the transfer encoding MUST be completely and fully described.
- SHOULDIf additional security issues come to light after initial publication and registration, they SHOULD be addressed by publishing revised versions of the transfer encoding specification.
3.2 Transfer Encoding Definition Procedure
- MUSTThe draft MUST define the transfer encoding precisely and completely, and it MUST also provide substantial justification for defining and standardizing a new transfer encoding.
- MUSTThis specification MUST then be presented to the IESG for consideration.
3.3 IANA Procedures for Transfer Encoding Registration
- MUSTAll legitimate transfer encoding registrations MUST appear as a standards-track RFC, so it is the IESG's responsibility to notify the IANA when a new transfer encoding has been approved.