doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1590.txt b/doc/rfc/rfc1590.txt
new file mode 100644
index 0000000..02629b7
--- /dev/null
+++ b/doc/rfc/rfc1590.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
+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]
+
\ No newline at end of file