Here is an updated version of the MIME specification. This version reflects a
major technical change: In response to IESG concerns about document size and
flexibility, the MIME specification has been broken up into five documents:
(1) Internet message bodies.
(2) Media types.
(3) Conformance and examples.
(4) Character sets in headers.
(5) Registration procedures.
This message contains part five of the updated specification.
Note for Internet-Drafts: The file name used here reflects the working group
that developed this specification, ietf-822. This group is no longer active.
I don't know whether or not it is appropriate to change the group to mailext.
If so, please do so and let me know so I can update the documents accordingly.
Ned
Network Working Group John Postel, ISI
Internet Draft Ned Freed, Innosoft
<draft-ietf-822ext-mime-reg-00.txt>
Multipurpose Internet Mail Extensions
(MIME) Part Five:
Registration Procedures
April 3, 1995
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet-Drafts as reference material or to cite them other
than as a "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
or munnari.oz.au (Pacific Rim).
1. Abstract
STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message headers,
and leaves the message content, or message body, as flat US-
ASCII text. This set of documents, collectively called the
Multipurpose Internet Mail Extensions, or MIME, redefines the
format of messages to allow for
Internet Draft MIME Registration Procedures April 1995
(1) textual message bodies in character sets other than
US-ASCII,
(2) non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than
US-ASCII.
These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822.
In particular, these documents are designed to provide
facilities to include multiple parts in a single message, to
represent body and header text in character sets other than
US-ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio
fragments, and generally to facilitate later extensions
defining new types of Internet mail for use by cooperating
mail agents.
The initial document in this set, RFC MIME-IMB, specifies the
various headers used to describe the structure of MIME
messages. The second document, RFC MIME-IMT, defines the
general structure of the MIME media typing system and defines
an initial set of media types. The third document, RFC MIME-
CONF, describes MIME conformance criteria as well as providing
some illustrative examples of MIME message formats. The fourth
document, RFC MIME-HEADERS, describes extensions to RFC 822 to
allow non-US-ASCII text data in Internet mail header fields.
This fifth and final document, RFC MIME-REG, specifies various
IANA registration procedures for the following MIME entities:
(1) media types,
(2) character sets,
(3) external body access types,
(4) content-transfer-encodings.
Expires October 1995 [Page 2]
Internet Draft MIME Registration Procedures April 1995
These documents are revisions of RFCs 1521 and 1522, which
themselves were revisions of RFCs 1341 and 1342. An appendix
in RFC MIME-CONF describes differences and changes from
previous versions.
2. Introduction
Recent Internet protocols have been carefully designed to be
easily extensible in certain areas. In particular, MIME
[RFC-MIME-IMB] is an open-ended framework and can accomodate
additional object types, character sets, and access methods
without any changes to the basic protocol. A registration
process is needed, however, to ensure that the set of such
values is developed in an orderly, well-specified, and public
manner.
This document defines registration procedures which use the
Internet Assigned Numbers Authority (IANA) as a central
registry for such values. This procedures also addresses the
registration requirements needed for the mapping of Object
Identifiers (OIDs) for X.400 MHS use to media types.
Historical Note: The registration process for media types was
initially defined in the context of the asynchronous Internet
mail environment. 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 proliferation of media types is
not a hindrance to interoperability, the original procedure
was excessively restrictive and had to be generalized.
3. Media Type Registration
Registration of a new media type or types starts with the
construction of a registration proposal. This proposal is
then circulated and reviewed. The media type is then
registered if the proposal is acceptable. The following
sections describe requirements and procedures involved.
Expires October 1995 [Page 3]
Internet Draft MIME Registration Procedures April 1995
3.1. Registration Requirements
Media type registration proposals are expected to conform to a
number of requirements as described below.
3.1.1. Naming Requirements
All registered media types must be assigned MIME content
type/subtype. This name then serves to uniquely identify the
media type.
The choice of top-level type must take the nature of media
type involved into account. For example, media capable of
representing still images should be a subtype of the image
content type, whereas media capable of representing audio
information belongs under the audio content type. See RFC
MIME-IMB for additional information on the basic set of
content types and their characteristics.
New subtypes of top-level types must conform to the
restrictions of the top-level type, if any. For example, all
subtypes of the multipart content type must use the same
encapsulation syntax.
In some cases a new media type may not "fit" under any
currently defined top-level content type. Such cases are
expected to be quite rare. However, if such a case arises a
new top-level type can be defined to accomodate it. Such a
definition must be done via standards-track RFC; no other
mechanism can be used to define additional top-level content
types.
3.1.2. Parameter Requirements
Media types may elect to use one or more MIME content type
parameters, or some parameters may be automatically made
available to the media type by virtue of being a subtype of a
content type that defines a set of parameters applicable to
any subtype. In either case, the names, values, and meanings
of any parameters must be fully specified.
Expires October 1995 [Page 4]
Internet Draft MIME Registration Procedures April 1995
3.1.3. Format and Canonicalization Requirements
All registered media types must employ a single, canonical
data format. A precise and openly available specification of
the format is preferred, and if such a specification is
available the media type registration must reference it.
However, requiring such a specification for all media types
would block the registration of proprietary formats, and as
such is unduly restrictive. As such, this format requirement
can be met by the specification of a particular version or
versions of a particular software package or packages that
understand the format. The appropriateness of using a media
type with an unavailable specification should not be an issue
in the registration process.
3.1.4. Security Requirements
Any known security issues that arise from the use of the media
type must be completely and fully described. See the
registration of the application/postscript media type in RFC
MIME-IMB for an example of what sort of security issues can
arise from the use of one particular media type.
It is not required that the media type be secure or that it be
free from risks, but that the known risks be identified.
Publication of a media 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.1.5. Usage and Implementation Requirements
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 media types used to those "common" formats
expected to be widely implemented. This was asserted in the
past as a reason to limit the number of possible media types
and resulted in a registration process with a significant
hurdle and delay for those registering media types.
Expires October 1995 [Page 5]
Internet Draft MIME Registration Procedures April 1995
However, the need for "common" media types does not require
limiting the registration of new media 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 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.
3.1.6. Publication Requirements
Media type registrations can be published as RFCs, however,
RFC publication is not required to register a new media type.
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 to lengthy 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.
3.2. 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.
Expires October 1995 [Page 6]
Internet Draft MIME Registration Procedures April 1995
3.2.1. Present the Registration Proposal to the Community
Send a proposed media type registration to the "ietf-
types(_at_)uninett(_dot_)no" mailing list. This mailing list has been
established for the sole purpose of reviewing proposed media
types. Proposed media types are not formally registered and
must not be used; the "x-" prefix specified in RFC MIME-IMB
can be used until registration is complete.
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 any security considerations.
3.2.2. Submit Media 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(_at_)isi(_dot_)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.
3.3. Location of Registered Media Type List
Media type registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/media-types"
and the media type will be listed in the periodically issued
"Assigned Numbers" RFC [RFC-1700]. The media type description
may also be published as an Informational RFC by sending it to
"rfc-editor(_at_)isi(_dot_)edu" (please follow the instructions to RFC
authors [RFC-1543]).
3.4. Registration Template and Checklist
To: IANA(_at_)isi(_dot_)edu
Subject: Registration of new MIME media type
MIME type name:
(If the the above is not an existing top-level type
Expires October 1995 [Page 7]
Internet Draft MIME Registration Procedures April 1995
please explain why an existing type cannot or should
not be used.)
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Published specification:
(The published specification must be a standards-track RFC
if a new top-level type is being defined.)
Person & email address to contact for further information:
4. Character Set Registration
MIME and other modern Internet protocols are capable of using
many different character sets. This in turn means that the
ability to label different character sets is essential. This
registration procedure exists solely to associate a specific
name or names with a given character set.
4.1. Registration Requirements
Registered character set are expected to conform to a number
of requirements as described below.
4.1.1. Required Characteristics
Registered character sets must conform to the definition of a
"character set" given in RFC MIME-IMB. In addition, character
sets intended for use in content types under the "text" top-
level type must conform to the restrictions on that type
described in RFC MIME-IMB. All registered character sets must
note whether or not they are suitable for such usage.
Expires October 1995 [Page 8]
Internet Draft MIME Registration Procedures April 1995
All registered character sets must be specified in an openly
available specification.
4.1.2. New Character Sets
This registration mechanism is not intended to be a vehicle
for the definition of entirely new character sets. This is due
to the fact that the registration process does NOT contain
adequate review mechanisims for such undertakings.
As such, only character sets defined by other processes and
standards bodies, or specific profiles of such character sets,
are eligible for registration.
4.1.3. Naming Requirements
One or more names must be assigned to all registered character
sets. Multiple names for the same character set are permitted,
but each name must uniquely identify a single character set.
All character set names must be suitable for use as the value
of a MIME content type parameter, e.g. the charset parameter
of MIME's text type.
4.1.4. Usage and Implementation Requirements
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
character sets to a "common" set expected to be widely
implemented. This was asserted in the past as a reason to
limit the number of possible character sets and resulted in a
registration process with a significant hurdle and delay for
those registering character sets.
However, the need for "common" character sets does not require
limiting the registration of new character sets. 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 character
sets is recommended for a particular application, that should
Expires October 1995 [Page 9]
Internet Draft MIME Registration Procedures April 1995
be asserted by a separate applicability statement specific for
the application and/or environment.
As such, universal support and implementation of a character
set is NOT a requirement for registration. If, however, a
character set is explicitly intended for limited use, this
should be noted in its registration.
4.1.5. Publication Requirements
Character set registrations can be published as RFCs, however,
RFC publication is not required to register a new character
set.
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 to lengthy a process for the convenient and practical need
to register character sets. It is expected that applicability
statements for particular applications will be published from
time to time that recommend implementation of, and support
for, character sets that have proven particularly useful in
those contexts.
4.2. Registration Procedure
The following procedure has been implemented by the IANA for
review and approval of new character sets. This is not a
formal standards process, but rather an administrative
procedure intended to allow community comment and sanity
checking without excessive time delay.
4.2.1. Present the Registration Proposal to the Community
Send a proposed character set registration to the "ietf-
charsets(_at_)innosoft(_dot_)com" mailing list. This mailing list has
been established for the sole purpose of reviewing proposed
character set registrations. Proposed character sets are not
formally registered and must not be used; the "x-" prefix
specified in RFC MIME-IMB can be used until registration is
Expires October 1995 [Page 10]
Internet Draft MIME Registration Procedures April 1995
complete.
The intent of the public posting is to solicit comments and
feedback on the definition of the character set and the name
chosen for it.
4.2.2. Submit Character Set to the IANA for Registration
After two weeks, submit the proposed character set to the IANA
for registration. The request and supporting documentation
should be sent to "iana(_at_)isi(_dot_)edu". Provided a reasonable
review period has elapsed, the IANA will register the
character and make character set registration available to the
community.
4.3. Location of Registered Character Set List
Character set registrations will be posted in the anonymous
FTP file "ftp.isi.edu:in-notes/iana/assignments/character-
sets" and the character set will be listed in the periodically
issued "Assigned Numbers" RFC [RFC-1700]. The media type
description may also be published as an Informational RFC by
sending it to "rfc-editor(_at_)isi(_dot_)edu" (please follow the
instructions to RFC authors [RFC-1543]).
4.4. Registration Template and Checklist
To: IANA(_at_)isi(_dot_)edu
Subject: Registration of new character set
Character set name(s):
(All names must be suitable for use as the value of a
MIME content-type parameter.)
Published specification(s):
(A specification for the character set must be
openly available that accurately describes what
is being registered.)
Person & email address to contact for further information:
Expires October 1995 [Page 11]
Internet Draft MIME Registration Procedures April 1995
5. External Body Access Types
TBD.
6. Transfer Encodings
TBD.
7. Acknowledgements
Most of the words in this RFC were written by other people --
primarily John Klensin and Greg Vaudreuil -- and our
contribution has been to slightly modify some sentences,
delete some phrases, and to rearrange some paragraphs. This
means that we are responsible for all the bad ideas and
mangled English, and they deserve the credit (and rightly so)
for all the good ideas.
8. Authors' Addresses
For more information, the authors of this document are best
contacted via Internet mail:
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
USA
EMail: Postel(_at_)ISI(_dot_)EDU
Phone: +1 310 822 1511
Fax: +1 310 823 6714
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Email: ned(_at_)innosoft(_dot_)com
Phone: +1 818 919 3600
Fax: +1 818 919 3614
Expires October 1995 [Page 12]
Internet Draft MIME Registration Procedures April 1995
9. References
[RFC-1543]
Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[RFC-1700]
Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute, October
1994.
[RFC-MIME-IMB]
Borenstein, N. and Freed, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC MIME-IMB, Bellcore, Innosoft, April, 1995.
[RFC-MIME-IMT]
Borenstein, N. and Freed, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC MIME-IMT,
Bellcore, Innosoft, April, 1995.
[RFC-MIME-CONF]
Borenstein, N. and Freed, N., "Multipurpose Internet Mail
Extensions (MIME) Part Three: Conformance Criteria and
Examples", RFC MIME-IMT, Bellcore, Innosoft, April, 1995.
[RFC-MIME-HEADERS]
Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Four: Representation of Non-Ascii Text in Internet
Message Headers", RFC MIME-HEADERS, University of
Tennessee, ?.
[RFC-MIME-REG]
Postel, J., Freed, N., "Multipurpose Internet Mail
Extensions (MIME) Part Five: Media Type Registration
Procedure", RFC MIME-REG, ISI, Innosoft, April, 1995.
Expires October 1995 [Page 13]