As per Relevance of the word procedure, we have this rfc below:
Network Working Group J.
Request for Comments: 1590
Updates: 1521 March 1994
Category:
Media Type Registration
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Several protocols allow the use of data representing
"media" such as text, images, audio, and video, and within such
different encoding styles, such as (in video) jpeg, gif, ief,
tiff. The Multimedia Internet Message Extensions (MIME) protocol [1]
defined several initial types of multimedia data objects, and
procedure for registering additional types with the Internet
Numbers Authority (IANA). Several questions have been raised
the requirements and administrative procedure for registering
content-type and subtypes, and the use of these Media Types for
applications. This document addresses these issues and specifies
procedure for the registration of new Media Types (content
type/subtypes). It also generalizes the scope of use of these
Types to make it appropriate to use the same registrations
specifications with other applications
1.
RFC 1521 [1] defines a procedure for the registration of new
types for use with the Multimedia Internet Message Extensions (MIME).
This registration mechanism was designed to make the identifiers
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
registration service for Internet Protocols. These types,
called "MIME Types", are now called "Media Types".
The registration process for Media Types (content-type/subtypes)
initially defined in the context of the asynchronous
environments. In this mail environment, there is a need to limit
number of possible Media Types to increase the likelihood
interoperability when the capabilities of the remote mail system
not known. As Media Types are used in new environments, where
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
generalized
This document addresses the specific questions raised and provides
administrative procedure for the registration of Media Types.
procedure also address the registration requirements needed for
mapping of Object Identifiers (OIDs) for X.400 MHS use to
Types
2. Media Type Registration
The following procedure has been implemented by the IANA for
and approval of new Media Types. This is not a formal
process, but rather an administrative procedure intended to
community comment and sanity checking without excessive time delay
2.1 Present the Request for Registration to the
Send a proposed Media Type (content-type/subtype) to the "ietf
types@cs.utk.edu" mailing list. This mailing list has
established for the sole purpose of reviewing proposed Media Types
Proposed content-types are not formally registered and must use
"x-" notation for the subtype name
The intent of the public posting is to solicit comments and
on the choice of content-type/subtype name, the unambiguity of
references with respect to versions and external
information, the choice of which OIDs to use, and a review of
security considerations section. It should be noted that
proposed Media Type does not need to make sense for every
application. If the Media Type is intended for a limited or
use, this should be noted in the submission
2.2 Submit the Content Type to the IANA for
After two weeks, submit the proposed Media Type to the IANA
registration. The request and supporting documentation should
sent to "iana@isi.edu". Provided a reasonable review period
elapsed, the IANA will register the Media Type, assign an OID
the IANA branch, and make the Media Type registration available
the community
IANA [Page 2]
RFC 1590 Media Type Registration Procedure March 1994
The Media Type registrations will be posted in the anonymous
directory "ftp.isi.edu:in-notes/media-types" and the Media Type
be listed in the periodically issued "Assigned Numbers" RFC [2].
Media Type description may be published as an Informational RFC
sending it to "rfc-editor@isi.edu" (please follow the instructions
RFC authors [3]).
3. Clarifications On Specific
3.1 MIME Requirements for a Limited Number of Content-
Issue: In the asynchronous mail environment, where information
the capabilities of the remote mail agent is not available to
sender, maximum interoperability is attained by restricting
number of content-types used to those "common" content-types
to be widely implemented. This was asserted as a reason to limit
number of possible content-types and resulted in a
process with a significant hurdle and delay for those
content-types
Comment: The need for "common" content-types formats does
require limiting the registration of new content-types.
restriction may, in fact, hinder interoperability by causing
registration authorities for specific applications which may
values in conflict with or otherwise incompatible with each other
If a limited set of content-types recommended for a
application, that should be asserted by a separate
statement specific for the application and/or environment
3.2 Requirements for a Published
Issue: Content-Type registration requires an RFC specifying the
format or a reference to a published specification of the
stream. This requirement may be overly restrictive for the use
content-type registration for file attachments and
because a public specification may not be available for a number
widely used and exchanged objects
Comment: MIME required the documentation of a specific content-
to allow the unambiguous identification of a defined type.
intent is met by the identification of a particular software
and version when registering the content-type and is allowed
registration. The appropriateness of using a Media Type with
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
Issue: The registration process requires the identification of
known security problems with the content-type
Comment: It is not required that the content-type be secure or
it be free from risks, but that the known risks be identified
Publication of a content-type does not require an exhaustive
review, and the security considerations section is subject
continuing evaluation. Additional security considerations should
periodically published in an RFC by IANA
3.4. Recommendations and Standards
Issue: The registration of a data type does not imply endorsement
approval, or recommendation by IANA or IETF or even
that the specification is adequate
Comment: To become Internet Standards, protocol, data objects,
whatever must go through the IETF standards process. This is
difficult and to lengthly a process for the convenient and
need to register Media Types. It is expected that
statements for particular applications will be published from time
time that recommend implementation of, and support for, data
that have proven particularly useful in those contexts
4. Security
This memo does not address specific security issues but outlines
security review process for Media Types
5.
Most of the words in this RFC were written by other people --
primarily John Klensin and Greg Vaudreuil -- and my contribution
been to slightly modify some sentences, delete some phrases, and
rearrange some paragraphs. This means that i am responsible for
the bad ideas and mangled English, and they deserve the credit (
rightly) all the good ideas
IANA [Page 4]
RFC 1590 Media Type Registration Procedure March 1994
6. Author's
Jon
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: 310-822-1511
Fax: 310-823-6714
EMail: Postel@ISI.
7.
[1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet
Extensions) Part One: Mechanisms for Specifying and
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
MIME has been carefully designed to have extensible mechanisms,
it is expected that the set of content-type/subtype pairs and
associated parameters will grow significantly with time.
other MIME fields, notably character set names, access-
parameters for the message/external-body type, and possibly
Content-Transfer-Encoding values, are likely to have new
defined over time
In general, parameters in the content-type header field are used
convey supplemental information for various content types, and
use is defined when the content-type and subtype are defined.
parameters should not be defined as a way to introduce
functionality
In order to ensure that the content-type and subtype (that is
Type) values are developed in an orderly, well-specified, and
manner, MIME and other applications use the registration process
Media Types defined in this RFC which uses the Internet
Numbers Authority (IANA) as a central registry for such values
In order to simplify and standardize this Media Type
process, this appendix gives templates for the registration of
values with IANA. Each of these is given in the form of an
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.
a new fundamental top-level type is needed, its specification must
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.
Subject: Registration of new Media Type content-type/
Media Type name
(If the above is not an existing top-level Media Type,
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-
if a new top-level type is being defined, and must be a
available specification in any case.)
Person & email address to contact for further information
==================================================================
IANA [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
