number of media types used to those "common" formats expected to be
   widely implemented.  This was asserted in the past as a reason to




 
RFC 2048              MIME Registration Procedures         November 1996


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

2.2.8.  Publication Requirements

   Proposals for media types registered in the IETF tree must be
   published as RFCs. RFC publication of vendor and personal media type
   proposals is encouraged but not required. In all cases IANA will
   retain copies of all media type proposals and "publish" them as part
   of the media types registration tree itself.

   Other than in the IETF tree, 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.

   The IETF tree exists for media types that do require require a
   substantive review and approval process with the vendor and personal
   trees exist for those that do not. It is expected that applicability
   statements for particular applications will be published from time to
   time that recommend implementation of, and support for, media 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.

2.2.9.  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




 
RFC 2048              MIME Registration Procedures         November 1996


          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.

2.3.  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.
   For registration in the IETF tree, the normal IETF processes should
   be followed, treating posting of an internet-draft and announcement
   on the ietf-types list (as described in the next subsection) as a
   first step.  For registrations in the vendor or personal tree, the
   initial review step described below may be omitted and the type
   registered directly by submitting the template and an explanation
   directly to IANA (at iana@iana.org).  However, authors of vendor or
   personal media type specifications are encouraged to seek community
   review and comment whenever that is feasible.

2.3.1.  Present the Media Type to the Community for Review

   Send a proposed media type registration to the "ietf-types@iana.org"
   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 types are not formally registered and