RFC 4289: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures | RFC Editor

Skip to content Primary navigationThe RFC SeriesFor AuthorsAbout UsHomeRFC 4289 View as: Plain Text, Compact HTML Info RFC 4289: BCP 13: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration ProceduresMIMEDecember 2005. N. Freed, J. KlensinBest Current PracticeSubscribe5 subscribed Add to Set Read aloud Network Working Group N. Freed Request for Comments: 4289 Sun Microsystems BCP: 13 J. Klensin Obsoletes: 2048 December 2005 Category: Best Current Practice Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies IANA registration procedures for MIME external body access types and content-transfer-encodings. Freed & Klensin Best Current Practice [Page 1] RFC 4289 MIME Registration December 2005 Table of Contents 1. Introduction ....................................................2 2. External Body Access Types ......................................3 2.1. Registration Requirements ..................................3 2.1.1. Naming Requirements ...................................3 2.1.2. Mechanism Specification Requirements ..................3 2.1.3. Publication Requirements ..............................4 2.1.4. Security Requirements .................................4 2.2. Registration Procedure .....................................4 2.2.1. Present the Access Type to the Community ..............4 2.2.2. Access Type Reviewer ..................................4 2.2.3. IANA Registration .....................................5 2.3. Location of Registered Access Type List ....................5 2.4. IANA Procedures for Registering Access Types ...............5 3. Transfer Encodings ..............................................5 3.1. Transfer Encoding Requirements .............................6 3.1.1. Naming Requirements ...................................6 3.1.2. Algorithm Specification Requirements ..................6 3.1.3. Input Domain Requirements .............................6 3.1.4. Output Range Requirements .............................6 3.1.5. Data Integrity and Generality Requirements ............7 3.1.6. New Functionality Requirements ........................7 3.1.7. Security Requirements .................................7 3.2. Transfer Encoding Definition Procedure .....................7 3.3. IANA Procedures for Transfer Encoding Registration .........8 3.4. Location of Registered Transfer Encodings List .............8 4. Security Considerations .........................................8 5. IANA Considerations .............................................8 6. Acknowledgements ................................................8 7. References ......................................................9 A. Changes Since RFC 2048 .........................................9 1. Introduction Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, MIME [RFC2045] is an open-ended framework and can accommodate additional object types, charsets, 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 that use the Internet Assigned Numbers Authority (IANA) as a central registry for these values. Freed & Klensin Best Current Practice [Page 2] RFC 4289 MIME Registration December 2005 Note: Registration of media types and charsets for use in MIME are specified in separate documents [RFC4288] [RFC2978] and are not addressed here. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. External Body Access Types [RFC2046] 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 actual body data. RFC 2046 defines an initial set of access types but allows for the registration of additional access types to accommodate new retrieval mechanisms. 2.1. Registration Requirements New access type specifications MUST conform to the requirements described below. 2.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. 2.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 is expressly prohibited. The restrictions imposed by [RFC2026] on the standardization of patented algorithms must be respected as well. Freed & Klensin Best Current Practice [Page 3] RFC 4289 MIME Registration December 2005 2.1.3. Publication Requirements All access types MUST be described by an RFC. The RFC may be informational rather than standards-track, although standards-track review and approval are encouraged for all access types. 2.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 it is required that the