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.










 
RFC 1590           Media Type Registration Procedure          March 1994


   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.








 
RFC 1590           Media Type Registration Procedure          March 1994


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.