Network Working Group                                          J. Postel
Request for Comments: 1590                                           ISI
Updates: 1521                                                 March 1994
Category: Informational


                   Media Type Registration Procedure

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   Several protocols allow the use of data representing different
   "media" such as text, images, audio, and video, and within such media
   different encoding styles, such as (in video) jpeg, gif, ief, and
   tiff.  The Multimedia Internet Message Extensions (MIME) protocol [1]
   defined several initial types of multimedia data objects, and a
   procedure for registering additional types with the Internet Assigned
   Numbers Authority (IANA).  Several questions have been raised about
   the requirements and administrative procedure for registering MIME
   content-type and subtypes, and the use of these Media Types for other
   applications.  This document addresses these issues and specifies a
   procedure for the registration of new Media Types (content-
   type/subtypes).  It also generalizes the scope of use of these Media
   Types to make it appropriate to use the same registrations and
   specifications with other applications.

1. Introduction

   RFC 1521 [1] defines a procedure for the registration of new data
   types for use with the Multimedia Internet Message Extensions (MIME).
   This registration mechanism was designed to make the identifiers for
   a given data type available for use and to prevent naming conflicts.
   With the growth of new multi-media protocols and access mechanisms,
   this process has the promise of forming a unified general
   registration service for Internet Protocols.  These types, previously
   called "MIME Types", are now called "Media Types".

   The registration process for Media Types (content-type/subtypes) was
   initially defined in the context of the asynchronous mail
   environments.  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 is excessively restrictive and needs to be
   generalized.

   This document addresses the specific questions raised and provides an
   administrative procedure for the registration of Media Types.  This
   procedure also address the registration requirements needed for the
   mapping of Object Identifiers (OIDs) for X.400 MHS use to Media
   Types.

2. Media Type 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.

2.1 Present the Request for Registration to the Community

   Send a proposed Media Type (content-type/subtype) to the "ietf-
   types@cs.utk.edu" mailing list.  This mailing list has been
   established for the sole purpose of reviewing proposed Media Types.
   Proposed content-types are not formally registered and must use the
   "x-" notation for the subtype name.

   The intent of the public posting is to solicit comments and feedback
   on the choice of content-type/subtype name, the unambiguity of the
   references with respect to versions and external profiling
   information, the choice of which OIDs to use, and a review of the
   security considerations section.  It should be noted that the
   proposed Media Type does not need to make sense for every possible
   application.  If the Media Type is intended for a limited or specific
   use, this should be noted in the submission.

2.2 Submit the Content Type to the IANA for Registration

   After two weeks, submit the proposed Media Type to the IANA for
   registration.  The request and supporting documentation should be
   sent to "iana@isi.edu".  Provided a reasonable review period has
   elapsed, the IANA will register the Media Type, assign an OID under
   the IANA branch, and make the Media Type registration available to
   the community.

   The Media Type registrations will be posted in the anonymous FTP
   directory "ftp.isi.edu:in-notes/media-types" and the Media Type will
   be listed in the periodically issued "Assigned Numbers" RFC [2].  The
   Media Type description may be published as an Informational RFC by
   sending it to "rfc-editor@isi.edu" (please follow the instructions to
   RFC authors [3]).

3. Clarifications On Specific Issues

3.1 MIME Requirements for a Limited Number of Content-Types

   Issue:  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 content-types used to those "common" content-types expected
   to be widely implemented.  This was asserted as a reason to limit the
   number of possible content-types and resulted in a registration
   process with a significant hurdle and delay for those registering
   content-types.

   Comment:  The need for "common" content-types formats does not
   require limiting the registration of new content-types.  This
   restriction may, in fact, hinder interoperability by causing separate
   registration authorities for specific applications which may register
   values in conflict with or otherwise incompatible with each other.
   If a limited set of content-types recommended for a particular
   application, that should be asserted by a separate applicability
   statement specific for the application and/or environment.

3.2 Requirements for a Published Specification

   Issue:  Content-Type registration requires an RFC specifying the data
   format or a reference to a published specification of the data
   stream.  This requirement may be overly restrictive for the use of
   content-type registration for file attachments and distribution
   because a public specification may not be available for a number of
   widely used and exchanged objects.

   Comment:  MIME required the documentation of a specific content-type
   to allow the unambiguous identification of a defined type.  This
   intent is met by the identification of a particular software package
   and version when registering the content-type and is allowed for
   registration.  The appropriateness of using a Media Type with an
   unavailable specification should not be an issue in the registration.

3.3 Identification of Security Considerations

   Issue:  The registration process requires the identification of any
   known security problems with the content-type.

   Comment:  It is not required that the content-type be secure or that
   it be free from risks, but that the known risks be identified.
   Publication of a content-type does not require an exhaustive security
   review, and the security considerations section is subject to
   continuing evaluation.  Additional security considerations should be
   periodically published in an RFC by IANA.

3.4. Recommendations and Standards Status

   Issue:  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.

   Comment: To become Internet Standards, protocol, data objects, or
   whatever must go through the IETF standards process.  This is too
   difficult and to lengthly a process for the convenient and practical
   need to register 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.

4. Security Considerations

   This memo does not address specific security issues but outlines a
   security review process for Media Types.

5. Acknowledgements

   Most of the words in this RFC were written by other people --
   primarily John Klensin and Greg Vaudreuil -- and my contribution has
   been to slightly modify some sentences, delete some phrases, and to
   rearrange some paragraphs.  This means that i am responsible for all
   the bad ideas and mangled English, and they deserve the credit (and
   rightly) all the good ideas.

6. Author's Address

   Jon Postel
   USC/Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA  90292

   Phone: 310-822-1511
   Fax:   310-823-6714
   EMail: Postel@ISI.EDU

7. References

   [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
       Extensions) Part One:  Mechanisms for Specifying and Describing
       the Format of Internet Message Bodies", RFC 1521, Bellcore,
       Innosoft, September 1993.

   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
       USC/Information Sciences Institute, July 1992.

   [3] Postel,J., "Instructions to RFC Authors", RFC 1543,
       USC/Information Sciences Institute, October 1993.

Appendix A -- IANA Registration Procedures for Media Types

   MIME has been carefully designed to have extensible mechanisms, and
   it is expected that the set of content-type/subtype pairs and their
   associated parameters will grow significantly with time.  Several
   other MIME fields, notably character set names, access-type
   parameters for the message/external-body type, and possibly even
   Content-Transfer-Encoding values, are likely to have new values
   defined over time.

   In general, parameters in the content-type header field are used to
   convey supplemental information for various content types, and their
   use is defined when the content-type and subtype are defined.  New
   parameters should not be defined as a way to introduce new
   functionality.

   In order to ensure that the content-type and subtype (that is Media
   Type) values are developed in an orderly, well-specified, and public
   manner, MIME and other applications use the registration process for
   Media Types defined in this RFC which uses the Internet Assigned
   Numbers Authority (IANA) as a central registry for such values.

   In order to simplify and standardize this Media Type registration
   process, this appendix gives templates for the registration of new
   values with IANA.  Each of these is given in the form of an email
   message template, to be filled in by the registering party.

   Registration of New Content-type/subtype Values:

   Note that MIME is generally expected to be extended by subtypes.  If
   a new fundamental top-level type is needed, its specification must be
   published as an RFC or submitted in a form suitable to become an RFC,
   and be subject to the Internet standards process.

      ==================================================================

      To:  IANA@isi.edu
      Subject:  Registration of new Media Type content-type/subtype

      Media Type name:

      (If the above is not an existing top-level Media Type, please
      explain why an existing type cannot be used.)

      Media subtype name:

      Required parameters:

      Optional parameters:

      Encoding considerations:

      Security considerations:

      Published specification:

      (The published specification must be an Internet RFC or RFC-to-be
      if a new top-level type is being defined, and must be a publicly
      available specification in any case.)

      Person & email address to contact for further information:

      ==================================================================