2.3.2 IESG Approval .....................................   12
   2.3.3 IANA Registration .................................   12
   2.4 Comments on Media Type Registrations ................   12
   2.5 Location of Registered Media Type List ..............   12
   2.6 IANA Procedures for Registering Media Types .........   12
   2.7 Change Control ......................................   13
   2.8 Registration Template ...............................   14
   3. External Body Access Types ...........................   14
   3.1 Registration Requirements ...........................   15
   3.1.1 Naming Requirements ...............................   15




 
RFC 2048              MIME Registration Procedures         November 1996


   3.1.2 Mechanism Specification Requirements ..............   15
   3.1.3 Publication Requirements ..........................   15
   3.1.4 Security Requirements .............................   15
   3.2 Registration Procedure ..............................   15
   3.2.1 Present the Access Type to the Community ..........   16
   3.2.2 Access Type Reviewer ..............................   16
   3.2.3 IANA Registration .................................   16
   3.3 Location of Registered Access Type List .............   16
   3.4 IANA Procedures for Registering Access Types ........   16
   4. Transfer Encodings ...................................   17
   4.1 Transfer Encoding Requirements ......................   17
   4.1.1 Naming Requirements ...............................   17
   4.1.2 Algorithm Specification Requirements ..............   18
   4.1.3 Input Domain Requirements .........................   18
   4.1.4 Output Range Requirements .........................   18
   4.1.5 Data Integrity and Generality Requirements ........   18
   4.1.6 New Functionality Requirements ....................   18
   4.2 Transfer Encoding Definition Procedure ..............   19
   4.3 IANA Procedures for Transfer Encoding Registration...   19
   4.4 Location of Registered Transfer Encodings List ......   19
   5. Authors' Addresses ...................................   20
   A. Grandfathered Media Types ............................   21

1.  Introduction

   Recent Internet protocols have been carefully designed to be easily
   extensible in certain areas.  In particular, MIME [RFC 2045] 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.






 
RFC 2048              MIME Registration Procedures         November 1996


2.  Media Type Registration

   Registration of a new media type or types starts with the
   construction of a registration proposal.  Registration may occur in
   several different registration trees, which have different
   requirements as discussed below.  In general, the new registration
   proposal is circulated and reviewed in a fashion appropriate to the
   tree involved.  The media type is then registered if the proposal is
   acceptable.  The following sections describe the requirements and
   procedures used for each of the different registration trees.

2.1.  Registration Trees and Subtype Names

   In order to increase the efficiency and flexibility of the
   registration process, different structures of subtype names may be
   registered to accomodate the different natural requirements for,
   e.g., a subtype that will be recommended for wide support and
   implementation by the Internet Community or a subtype that is used to
   move files associated with proprietary software.  The following
   subsections define registration "trees", distinguished by the use of
   faceted names (e.g., names of the form "tree.subtree...type").  Note
   that some media types defined prior to this document do not conform
   to the naming conventions described below.  See Appendix A for a
   discussion of them.

2.1.1.  IETF Tree