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
`
`IANA [Page 1]
`
`Page 1 of 7
`
`AT&T EXHIBIT 1030
`
`

`

`RFC 1590 Media Type Registration Procedure March 1994
`
` 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.
`
`IANA [Page 2]
`
`Page 2 of 7
`
`

`

`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.
`
`IANA [Page 3]
`
`Page 3 of 7
`
`

`

`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.
`
`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.
`
`IANA [Page 4]
`
`Page 4 of 7
`
`

`

`RFC 1590 Media Type Registration Procedure March 1994
`
`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.
`
`IANA [Page 5]
`
`Page 5 of 7
`
`

`

`RFC 1590 Media Type Registration Procedure March 1994
`
`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.
`
`IANA [Page 6]
`
`Page 6 of 7
`
`

`

`RFC 1590 Media Type Registration Procedure March 1994
`
` ==================================================================
`
` 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:
`
` ==================================================================
`
`IANA [Page 7]
`
`Page 7 of 7
`
`