view Side-By-Side changes
Network Working Group Ned Freed, Innosoft
Internet Draft John Klensin, MCI
<draft-ietf-822ext-mime-reg-03.txt> John Postel, ISI
<draft-ietf-822ext-mime-reg-02.txt>
Multipurpose Internet Mail Extensions
(MIME) Part Four:
Registration Procedures
December 1995
March 1996
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 December 1995 March 1996
(1) textual message bodies in character sets other than
US-ASCII,
(2) an extensible set of different formats for 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 clips,
and generally to facilitate later extensions defining new
types of Internet mail for use by cooperating mail agents.
This fourth document, RFC MIME-REG, specifies various IANA
registration procedures for the following MIME facilities:
(1) media types,
(2) character sets,
(3) external body access types,
(4)
(3) content-transfer-encodings.
Registration of character sets for use in MIME is covered
elsewhere and is no longer addressed by this document.
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.
Expires June September 1996 [Page 2]
Internet Draft MIME Registration Procedures December 1995 March 1996
2. Table of Contents
1 Abstract .............................................. 1
2 Table of Contents ..................................... 3
3 Introduction .......................................... 4 5
4 Media Type Registration ............................... 4 5
4.1 Registration Requirements ........................... Trees and Subtype Names ................ 5
4.1.1 Functionality Requirements ........................ 5 IETF Tree ......................................... 6
4.1.2 Vendor Tree ....................................... 6
4.1.3 Personal or Vanity Tree ........................... 7
4.1.4 Special `x.' Tree ................................. 7
4.1.5 Additional Registration Trees ..................... 8
4.2 Registration Requirements ........................... 8
4.2.1 Functionality Requirement ......................... 8
4.2.2 Naming Requirements ............................... 5
4.1.3 8
4.2.3 Parameter Requirements ............................ 6
4.1.4 Format and 9
4.2.4 Canonicalization and Format Requirements .......... 6
4.1.5 10
4.2.5 Interchange Requirements .......................... 7
4.1.6 Recommendations ....................... 10
4.2.6 Security Requirements ............................. 7
4.1.7 11
4.2.7 Usage and Implementation Requirements ............. 7
4.1.8 Non-requirements ......... 12
4.2.8 Publication Requirements .......................... 8
4.2 12
4.2.9 Additional Information ............................ 13
4.3 Registration Procedure .............................. 8
4.2.1 14
4.3.1 Present the Media Type to the Community ........... 8
4.2.2 Media Type Reviewer ............................... 9
4.2.3 for Re-
view ............................................... 14
4.3.2 IESG Approval ..................................... 14
4.3.3 IANA Registration ................................. 9
4.3 15
4.4 Comments on Media Type Registrations ................ 15
4.5 Location of Registered Media Type List .............. 10
4.4 15
4.6 IANA Procedures for Registering Media Types ......... 15
4.7 Change Control ...................................... 10
4.5 16
4.8 Registration Template ............................... 11 17
5 Character Set Registration External Body Access Types ............................ 12 18
5.1 Registration Requirements ........................... 12 18
5.1.1 Required Characteristics .......................... 12
5.1.2 New Character Sets ................................ 12
5.1.3 Naming Requirements ............................... 13
5.1.4 Usage and Implementation 18
5.1.2 Mechanism Specification Requirements ............. 13
5.1.5 .............. 18
5.1.3 Publication Requirements .......................... 13 19
5.1.4 Security Requirements ............................. 19
5.2 Registration Procedure .............................. 14 19
5.2.1 Present the Character Set Access Type to the Community ........ 14 .......... 19
5.2.2 Character Set Access Type Reviewer ............................ 14 .............................. 19
5.2.3 IANA Registration ................................. 15 20
5.3 Location of Registered Character Set Access Type List ........... 15 ............. 20
5.4 Registration Template ............................... 15
6 External Body IANA Procedures for Registering Access Types ............................ 15
6.1 Registration Requirements ........................... 16
6.1.1 Naming Requirements ............................... 16
6.1.2 Mechanism Specification Requirements .............. 16
6.1.3 Publication Requirements .......................... 16
6.1.4 Security Requirements ............................. 16
6.1.5 Additional Information ............................ 17
6.2 Registration Procedure .............................. 17
6.2.1 Present the Access Type to the Community .......... 17 ........ 20
Expires June September 1996 [Page 3]
Internet Draft MIME Registration Procedures December 1995
6.2.2 Access Type Reviewer .............................. 18
6.2.3 IANA Registration ................................. 18
6.3 Location of Registered Access Type List ............. 18
7 March 1996
6 Transfer Encodings .................................... 18
7.1 20
6.1 Transfer Encoding Requirements ...................... 19
7.1.1 21
6.1.1 Naming Requirements ............................... 19
7.1.2 21
6.1.2 Algorithm Specification Requirements .............. 19
7.1.3 21
6.1.3 Input Domain Requirements ......................... 20
7.1.4 22
6.1.4 Output Range Requirements ......................... 20
7.1.5 22
6.1.5 Data Integrity and Generality Requirements ....................... 20
7.1.6 ........ 22
6.1.6 New Functionality Requirements .................... 20
7.2 22
6.2 Transfer Encoding Definition Procedure .............. 20
8 23
6.3 IANA Procedures for Transfer Encoding Registration
.................................................... 23
6.4 Location of Registered Transfer Encodings List ...... 23
7 Authors' Addresses .................................... 21 24
A Grandfathered Media Types ............................. 25
B IANA and RFC Editor To-Do List ........................ 25
Expires September 1996 [Page 4]
Internet Draft MIME Registration Procedures March 1996
3. 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 accommodate
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.
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.
4. Media Type Registration
Registration of a new media type or types starts with the
construction of a registration proposal. This Registration may
occur in several different registration trees, which have
different requirements as discussed below. In general, the
new registration proposal is
Expires June 1996 [Page 4]
Internet Draft MIME Registration Procedures December 1995
then circulated and reviewed. reviewed in a
fashion appropriate to the tree involved. The media type is
then registered if the proposal is acceptable. The following
sections describe the requirements and procedures involved. used for
each of the different registration trees.
4.1. Registration Requirements
Media type registration proposals are expected to conform Trees and Subtype Names
In order to a
number increase the efficiency and flexibility of requirements as described below.
4.1.1. Functionality Requirements
Media types must function as an actual media format; the
registration process, different structures of things that are better thought of as a
transfer encoding, as a character set, or as a collection of
separate entities of another type is not allowed. For
example, although applications exist to decode the base64
transfer encoding [MIME-IMB], base64 cannot subtype names
may be registered as to accomodate the different natural
requirements for, e.g., a subtype of application.
4.1.2. Naming Requirements
All registered media types must that will be assigned recommended for
Expires September 1996 [Page 5]
Internet Draft MIME type Registration Procedures March 1996
wide support and implementation by the Internet Community or a
subtype names. The combination of these names then serves that is used to
uniquely identify the media type. move files associated with proprietary
software. The choice of top-level type name must take following subsections define registration
"trees", distinguished by the nature of
media type involved into account. For example, media capable use of representing still images should be a subtype faceted names (e.g.,
names of the image
content type, whereas form "tree.subtree...type"). Note that some
media capable of representing audio
information belongs under types defined prior to this specification do not conform
to the audio content type. naming conventions described below. See RFC
MIME-IMT Appendix A for additional information on the basic set
a discussion of top-
level them.
4.1.1. IETF Tree
The IETF tree is intended for types and their characteristics.
New subtypes of top-level types must conform general interest to the
restrictions of
Internet Community. Registration in the top-level type, if any. For example, all
subtypes of IETF tree requires
approval by the multipart content type must use IESG and publication of the same
encapsulation syntax.
In some cases a new media type may not "fit" under any
currently defined top-level content type. Such cases
registration as some form of RFC.
Media types in the IETF tree are
expected to be quite rare. However, if such a case arises normally denoted by names
that are not explicitly faceted, i.e., do not contain period
(".", full stop) characters.
The "owner" of a
new top-level media type can be defined registration in the IETF tree is
assumed to accommodate it. Such a
Expires June 1996 [Page 5]
Internet Draft MIME Registration Procedures December 1995
definition must be done via standards-track RFC; no other
mechanism can be the IETF itself. Modification or alteration of
the specification requires the same level of processing (e.g.
standards track) required for the initial registration.
4.1.2. Vendor Tree
The vendor tree is used to define additional top-level content
types.
4.1.3. Parameter Requirements
Media for media types associated with
commercially available products. "Vendor" or "producer" are
construed as equivalent and very broadly in this context.
A registration may elect be placed in the vendor tree by anyone who
has need to use one interchange files associated with the particular
product. However, the registration formally belongs to the
vendor or more MIME content type
parameters, organization producing the software or some parameters may file format.
Changes to the specification will be automatically made
available to at their request, as
discussed in subsequent sections.
Registrations in the media type vendor tree will be distinguished by virtue of being a subtype the
leading facet "vnd.". That may be followed, at the discretion
of the registration, by either a
content media type that defines name from a set well-
known producer (e.g., "vnd.mudpie") or by an IANA-approved
designation of parameters applicable to
any subtype. In either case, the names, values, producer's name which is then followed by a
Expires September 1996 [Page 6]
Internet Draft MIME Registration Procedures March 1996
media type or product designation (e.g.,
vnd.bigcompany.funnypictures).
While public exposure and meanings review of any parameters must media types to be fully specified when
registered in the content
type and subtype are defind. New parameters should vendor tree is not be
defined as a way required, using the
ietf-types list for review is strongly encouraged to introduce new functionality, although new
parameters improve
the quality of those specifications. Registrations in the
vendor tree may be defined submitted directly to convey additional information
that does not otherwise change the functionality. An example IANA.
4.1.3. Personal or Vanity Tree
Registrations for media types created experimentally or as
part of this would products that are not distributed commercially may be a "revision" parameter to indicate a revision
level of an external specification such as JPEG
registered in the personal or a character
set.
4.1.4. Format vanity tree. The registrations
are distinguished by the leading facet "prs.".
The owner of "personal" registrations and Canonicalization Requirements
All registered media types must employ a single, canonical
data format. A precise and openly available specification of associated
specifications is the format person or entity making the
registration, or one to whom responsibility has been
transferred as described below.
While public exposure and review of each media type is preferred, and if such a
specification types to be
registered in the personal tree is available not required, using the media type registration must
reference it.
However, requiring such a specification
ietf-types list for all media types
would block the registration of proprietary formats, and as
such review is unduly restrictive. Therefore this format requirement
can be met by strongly encouraged to improve
the specification of a particular version or
versions quality of a particular software package or packages that
understand those specifications. Registrations in the format. The appropriateness of using a
personl tree may be submitted directly to the IANA.
4.1.4. Special `x.' Tree
For convenience and symmetry with this registration scheme,
media type names with an unavailable specification should not "x." as the first facet may be an issue
in used for
the registration process.
Some media same purposes for which names starting in "x-" are
normally used. These types involve are unregistered, experimental,
and should be used only with the use of patented technology. The
registration active agreement of such types is specifically allowed. However, the restrictions set forth in RFC 1602 on
parties exchanging them.
However, with the use of patented
technology in standards-track protocols must simplified registration procedures described
above for vendor and personal trees, it should rarely, if
ever, be respected when
the specification necessary to use unregistered experimental types, and
as such use of a media type both "x-" and "x." forms is part of a standards-track
protocol. discouraged.
Expires June September 1996 [Page 6] 7]
Internet Draft MIME Registration Procedures December 1995 March 1996
4.1.5. Interchange Requirements
Media type should, whenever possible, interoperate across as
many systems Additional Registration Trees
From time to time and applications as possible. However, some media
types will inevitably have problems interoperating across
different platforms. Problems required by the community, the IANA
may, with different versions, byte
ordering, the advice and specifics consent of gateway handling can and will
arise. the IESG, create new top-
level registration trees. It is not required explicitly assumed that the media type these
trees may be universally
interoperable, but that created for external registration and management
by well-known permanent bodies, such as scientific societies
for media types specific to the known interoperability issues be
identified. Publication sciences they cover. In
general, the quality of a media type does not require an
exhaustive review of interoperability, and the
interoperability considerations section specifications for one of
these additional registration trees is subject expected to be
equivalent to
continuing evaluation.
4.1.6. Security Requirements
Any known security issues that arise from the use which IETF would give to registrations in
its own tree. Establishment of the media
type must these new trees will be completely and fully described. See
announced through RFC publication approved by the IESG.
4.2. Registration Requirements
Media type registration of proposals are all expected to conform
to various requirements laid out in the application/postscript media type following sections.
Note that requirement specifics sometimes vary depending on
the registration tree, again as detailed in RFC
MIME-IMT for the following
sections.
4.2.1. Functionality Requirement
Media types must function as an example actual media format:
Registration of what sort things that are better thought of security issues can
arise from the use as a
transfer encoding, as a character set, or as a collection of one particular media type.
It
separate entities of another type, is not required that the media type be secure or that it be
free from risks, but that allowed. For
example, although applications exist to decode the known risks base64
transfer encoding [MIME-IMB], base64 cannot be identified.
Publication of registered as a
media type.
This requirement applies regardless of the registration tree
involved.
4.2.2. Naming Requirements
All registered media types must be assigned MIME type does not require an exhaustive
security review, and the security considerations section is
subject to continuing evaluation.
4.1.7. Usage and Implementation Requirements
In the asynchronous mail environment, where information on the
capabilities
subtype names. The combination of the remote mail agent is not available these names then serves to
uniquely identify 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 type and the number format of possible media types
and resulted in a registration process with a significant
hurdle and delay for those registering media types.
However, the need for "common" media types does not require
limiting subtype
name identifies the registration of new media types. If a limited set tree.
Expires June September 1996 [Page 7] 8]
Internet Draft MIME Registration Procedures December 1995 March 1996
The choice of top-level type name must take the nature of
media types is recommended type involved into account. For example, media normally
used for a particular application,
that representing still images should be asserted by a separate applicability statement
specific subtype of the
image content type, whereas media capable of representing
audio information belongs under the audio content type. See
RFC MIME-IMT for additional information on the application and/or environment.
As such, universal support basic set of
top-level types and implementation 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
is NOT may not "fit" under any
currently defined top-level content type. Such cases are
expected to be quite rare. However, if such a requirement for registration. If, however, case arises a media
new top-level type is explicitly intended for limited use, this should can be
noted in its registration.
4.1.8. Publication defined to accommodate it. Such a
definition must be done via standards-track RFC; no other
mechanism can be used to define additional top-level content
types.
These requirements apply regardless of the registration tree
involved.
4.2.3. Parameter Requirements
Media types may elect to use one or more MIME content type registrations can
parameters, or some parameters may be published as RFCs, however,
RFC publication is not required automatically made
available to register a new the media type.
The registration type by virtue of being a data subtype of a
content 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 too lengthy defines a process for the convenient registration set of
media types. It is expected that applicability statements for
particular applications will be published from time parameters applicable to time
that recommend implementation of,
any of its subtypes. In either case, the names, values, and support for, data types
that have proven particularly useful in those contexts.
As discussed above, registration
meanings of any parameters must be fully specified when a top-level
media type requires
standards-track processing and, hence, RFC publication.
4.2. Registration Procedure
The following procedure has been implemented by is registered in the IANA for
review IETF tree, and approval of new should be
specified as completely as possible when media types. This is types are
registered in the vendor or personal trees.
New parameters must not be defined as a formal
standards process, but rather an administrative procedure
intended way to allow community comment and sanity checking
without excessive time delay.
4.2.1. Present introduce new
functionality in types registered in the Media Type IETF tree, although
new parameters may be added to the Community
Send convey additional information
that does not otherwise change existing functionality. An
example of this would be a proposed media type registration "revision" parameter to the "ietf-
types@uninett.no" mailing list for indicate a two week review period.
This mailing list has been established for the purpose
revision level of
reviewing proposed media and access types. Proposed an external specification such as JPEG.
Similar behavior is encouraged for media types registered in
the vendor or personal trees but is not required.
Expires June September 1996 [Page 8] 9]
Internet Draft MIME Registration Procedures December 1995
types are not formally registered March 1996
4.2.4. Canonicalization and Format Requirements
All registered media types must not be used; the
"x-" prefix specified in RFC MIME-IMB can be used until
registration is complete.
The intent employ a single, canonical
data format, regardless of the public posting is to solicit comments registration tree.
A precise and
feedback on the choice openly available specification of type/subtype name, the unambiguity format of
each media type is required for all types registered in the references with respect to versions and external
profiling information,
IETF tree and must at a review of any interoperability or
security considerations. minimum be referenced by, if it isn't
actually included in, the media type registration proposal
itself.
The submitter specifications of format and processing particulars may submit a revised
registration, or withdraw the registration completely, at any
time.
4.2.2. Media Type Reviewer
When
may not be publically available for media types registered in
the two week period has passed vendor tree, and the registration
proposer is convinced that consensus has been achieved, the such registration application should be submitted proposals are
explicitly permitted to IANA and the
Media Type Reviewer. The include only a specification of which
software and version produce or process such media type reviewer, who types.
References to or inclusion of format specifications in
registration proposals is appointed
by the IETF Applications Area Director(s), either approves the
request encouraged but not required.
Format specifications are still required for registration or rejects it. Rejection may occur
because of significant objections raised on in
the list personal tree, but may be either published as RFCs or
objections raised externally. If the media type reviewer
considers
otherwise deposited with IANA. The deposited specifications
will meet the registration sufficiently important and
controversial, same criteria as those required to register a last call for comments may
well-known TCP port and, in particular, need not be issued to made
public.
Some media types involve the
full IETF. use of patented technology. The
registration of media type reviewer may also recommend
standards types involving patented technology is
specifically permitted. However, the restrictions set forth
in RFC 1602 on the use of patented technology in standards-
track processing (before or after registration) protocols must be respected when
that appears appropriate and the level of specification of the a
media type is adequate.
Decisions made by the reviewer must be posted to the ietf- part of a standards-track protocol.
4.2.5. Interchange Recommendations
Media types mailing list within 14 days. Decisions made by the
reviewer may be appealed to the IESG.
4.2.3. IANA Registration
Provided that the should, whenever possible, interoperate across as
many systems and applications as possible. However, some media type has either passed review or has
been successfully appealed to the IESG, the IANA
types will register
the media type, inevitably have problems interoperating across
different platforms. Problems with different versions, byte
ordering, and make the specifics of gateway handling can and will
arise.
Universal interoperability of media type registration
available to the community. types is not required, but
known interoperability issues should be identified whenever
Expires June September 1996 [Page 9] 10]
Internet Draft MIME Registration Procedures December 1995
4.3. Location March 1996
possible. Publication of Registered Media Type List
Media a media type registrations will be posted does not require an
exhaustive review of interoperability, and the
interoperability considerations section is subject to
continuing evaluation.
These recommendations apply regardless of the registration
tree involved.
4.2.6. Security Requirements
An analysis of security issues is required for for all types
registered in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/media-types"
and IETF Tree. (This is in accordance with the
basic requirements for all IETF protocols.) A similar analysis
for media types registered in the vendor or personal trees is
encouraged but not required. However, regardless of what
security analysis has or has not been done, all descriptions
of security issues must be as accurate as possible regardless
of registration tree. In particular, a statement that there
are "no security issues associated with this type" must not be
confused with "the security issues associates with this type will
have not been assessed".
There is absolutely no requirement that media types registered
in any tree be listed secure or completely free from risks.
Nevertheless, all known security risks must be identified in
the periodically issued
"Assigned Numbers" RFC [RFC-1700]. The registration of a media type description type, again regardless of
registration tree.
The security considerations section of all registrations is
subject to continuing evaluation and other supporting material modification, and in
particular may also be published as an
Informational RFC extended by sending it to "rfc-editor@isi.edu"
(please follow use of the instructions to RFC authors [RFC-1543]).
4.4. Change Control
Once "comments on media
types" mechanism described in subsequent sections.
Some of the issues that should be looked at in a content security
analysis of a media type has been published by IANA, the author are:
(1) Complex media types may
request include provisions for
directives that institute actions on a change recipient's
files or other resources. In many cases provision is
made for originators to its definition. The change request follows
the same procedure as specify arbitrary actions in an
unrestricted fashion which may then have devastating
effects. See the registration request:
(1) Publish a template on the ietf-types list.
(2) Leave at least two weeks for comments.
(3) Get acceptance from of the
application/postscript media type reviewer.
(4) Publish using IANA.
Changes should be requested only when there are serious
omission or errors in the published specification. The
reviewer has the right to declare a "serious objection" RFC MIME-IMT for
an example of such directives and how to a
requested change if it renders entities handle them.
Expires September 1996 [Page 11]
Internet Draft MIME Registration Procedures March 1996
(2) Complex media types may include provisions for
directives that were valid under
the previous definition invalid under the new definition, but
is institute actions which, while not obliged
directly harmful to do so the recipient, may result in all cases.
The author
disclosure of information that either facilitates a content type may pass responsibility for the
content type to another person
subsequent attack or agency by informing IANA and else violates a recipient's
privacy in some way. Again, the ietf-types list; this registration of the
application/postscript media type illustrates how such
directives can be done without discussion or
review.
The IESG may reassign responsibility handled.
(3) A media type might be targeted for applications that
require some sort of security assurance but not provide
the necessary security mechanisms themselves. For
example, a media type. The
most common case of this will be to enable changes to type could be made
to types defined for storage of
confidential medical information which in turn requires
an external confidentiality service.
4.2.7. Usage and Implementation Non-requirements
In the asynchronous mail environment, where information on the author
capabilities of the registration has died, moved
out of contact or remote mail agent is otherwise unable to make changes that are
important frequently not
available to the community.
Media type registrations may not be deleted; sender, maximum interoperability is attained
by restricting the number of media types which
are no longer believed appropriate for use can used to those
"common" formats expected to be declared
Expires June 1996 [Page 10]
Internet Draft MIME Registration Procedures December 1995
OBSOLETE by widely implemented. This was
asserted in the past as a change reason to their "intended use" field; such limit the number of
possible media types will be clearly marked and resulted in a registration process
with a significant hurdle and delay for those registering
media types.
However, the lists published need for "common" media types does not require
limiting the registration of new media types. If a limited set
of media types is recommended for a particular application,
that should be asserted by IANA.
4.5. Registration Template
To: ietf-types@uninett.no
Subject: Registration a separate applicability statement
specific for the application and/or environment.
As such, universal support and implementation of MIME a media type XXX/YYY
MIME
is NOT a requirement for registration. If, however, a media
type name:
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification:
Additional information (optional):
Magic number(s):
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact is explicitly intended for further information:
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Author/Change controller:
(Any other information that limited use, this should be
noted in its registration.
4.2.8. Publication Requirements
Proposals for media types registered in the author deems interesting may IETF tree must be
added below this line.)
published as RFCs. RFC publication of vendor and personal
Expires June September 1996 [Page 11] 12]
Internet Draft MIME Registration Procedures December 1995
5. Character Set Registration
MIME March 1996
media type proposals is encouraged but not required. In all
cases IANA will retain copies of all media type proposals and other modern Internet protocols are capable
"publish" them as part of using
many different character sets. the media types registration tree
itself.
Other than in the IETF tree, 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 too lengthy a process for
the convenient registration of media types.
The IETF tree exists for media types that do require require a
substantive review and approval process with the vendor and
personal trees exist for those that do not. It is expected
that applicability statements for particular applications will
be published from time to time that recommend implementation
of, and support for, media types that have proven particularly
useful in turn means those contexts.
As discussed above, registration of a top-level type requires
standards-track processing and, hence, RFC publication.
4.2.9. Additional Information
Various sorts of optional information may be included in the
specification of a media type if it is available:
(1) Magic number(s) (length, octet values). Magic numbers
are byte sequences that are always present and thus can
be used to identify entities as being of a given media
type.
(2) File extension(s) commonly used on one or more
platforms to indicate that some file containing a given
type of media.
(3) Macintosh File Type code(s) (4 octets) used to label
files containing a given type of media.
Such information is often quite useful to implementors and if
available should be provided.
Expires September 1996 [Page 13]
Internet Draft MIME Registration Procedures March 1996
4.3. 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. For registration in the IETF
tree, the normal IETF processes should be followed, treating
posting of an internet-draft and announcement on the ietf-
types list (as described in the next subsection) as a first
step. For registrations in the vendor or personal tree, the
initial review step described below may be omitted and the
ability to label different character sets is essential. This
registration procedure exists solely
type registered directly by submitting the template and an
explanation directly to associate a specific
name IANA (at iana@isi.edu). However,
authors of vendor or names with a given character set.
5.1. Registration Requirements
Registered character sets personal media type specifications are expected
encouraged to conform seek community review and comment whenever that
is feasible.
4.3.1. Present the Media Type to the Community for Review
Send a number
of requirements as described below.
5.1.1. Required Characteristics
Registered character sets must conform proposed media type registration to the definition of "ietf-
types@cs.utk.edu" mailing list for a
"character set" given in RFC MIME-IMB. In addition, character
sets intended two week review period.
This mailing list has been established 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 purpose of
reviewing proposed media and access types. Proposed media
types are suitable for such usage.
All not formally registered character sets and must not be used; the
"x-" prefix specified in an openly
available specification.
NOTE: RFC MIME-IMB can be used until
registration is complete.
The definition intent of "character set" in this context the public posting is to solicit comments and
feedback on the
one given in RFC MIME-IMB. Other, incompatible definitions choice of
"character set" are in use in other communities; please read type/subtype name, the definition in MIME-IMB carefully before trying to decide
what unambiguity
of the references with respect to register as versions and external
profiling information, and a character set.
5.1.2. New Character Sets
This registration mechanism is not intended to be review of any interoperability or
security considerations. The submitter may submit a vehicle
for revised
registration, or withdraw the definition of entirely new character sets. This is due
to registration completely, at any
time.
4.3.2. IESG Approval
Media types registered in the fact that IETF tree must be submitted to
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 IESG for registration. approval.
Expires June September 1996 [Page 12] 14]
Internet Draft MIME Registration Procedures December 1995
5.1.3. Naming Requirements
One or more names must be assigned to all registered character
sets. Multiple names for March 1996
4.3.3. IANA Registration
Provided that the same character set are permitted,
but if multiple names are assigned a single primary name for media type meets the character set must be identified. All other names are
considered to be aliases requirements for the primary name media
types and use of the
primary name has obtained whateveer approval is preferred over use of any of necessary, the aliases.
Each name must uniquely identify a single character set. All
character set names must be suitable for use as
author may submit the value of a
MIME content registration request to the IANA, which
will register the media type charset parameter and hence must conform make the media type
registration available to
MIME parameter value syntax. This applies even if the specific
character set being community.
4.4. Comments on Media Type Registrations
Comments on registered is not suitable for use with
"text".
5.1.4. Usage and Implementation Requirements
Use of a large number media types may be submitted by members
of character sets hampers
interoperability. However, the use of a large number of
undocumented and/or unlabelled character sets hampers
interoperability even more.
A character set should therefore community to IANA. These comments will be registered ONLY if it adds
significant functionality that is valuable passed on to a large
community, OR if it documents existing practice in a large
community. Note that character sets registered for
the second
reason should be explicitly marked as being "owner" of limited or
specialized use.
5.1.5. Publication Requirements
Character set registrations can the media type if possible. Submitters of
comments may request that their comment be published in RFCs, however,
RFC publication is not required attached to register a new character
set.
The the
media type registration itself, and if IANA approves of a character set does not imply
endorsement, approval, or recommendation by this
the IANA, IESG, or
IETF, or even certification that comment will be made accessible in conjunction with the specification is
adequate. It is expected that applicability statements for
particular applications
type registration itself.
4.5. Location of Registered Media Type List
Media type registrations will be published from time to time
that recommend implementation of, posted in the anonymous FTP
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-
types/" and support for, character
sets that have proven particularly useful all registered media types will be listed in those contexts.
Expires June 1996 [Page 13]
Internet Draft MIME Registration Procedures December 1995
5.2. Registration Procedure
The following procedure has been implemented by the IANA for
review
periodically issued "Assigned Numbers" RFC [currently RFC-
1700]. The media type description and approval of new character sets. This is not a
formal standards process, but rather other supporting
material may also be published as an administrative
procedure intended Informational RFC by
sending it to allow community comment and sanity
checking without excessive time delay.
5.2.1. Present "rfc-editor@isi.edu" (please follow the Character Set
instructions to RFC authors [RFC-1543]).
4.6. IANA Procedures for Registering Media Types
The IANA will only register media types in the Community
Send the proposed character set registration IETF tree in
response to a communication from the "ietf-
charsets@innosoft.com" mailing list. This mailing list IESG stating that a given
registration has been established for approved. Vendor and personal types will
be registered by the sole purpose of reviewing proposed
character set registrations. Proposed IANA automatically and without any formal
review as long as the following minimal conditions are met:
(1) Media types must function as an actual media format.
In particular, character sets are and transfer encodings
may not
formally be registered as media types.
Expires September 1996 [Page 15]
Internet Draft MIME Registration Procedures March 1996
(2) All media types must have properly formed type and
subtype names. All type names must not be used; defined by a
standards-track RFC. All subtype names must be unique,
must conform to the "x-" prefix
specified MIME grammar for such names, and
must contain the proper tree prefix.
(3) Types registered in RFC MIME-IMB can the personal tree must either
provide a format specification or a pointer to one.
(4) Any security considerations given must not be used until registration obviously
bogus. (It is
complete.
The intent of neither possible nor necessary for the public posting is
IANA to solicit comments and
feedback on the definition conduct a comprehensive security review of
media type registrations. Nevertheless, IANA has the character set
authority to identify obviously incompetent material
and the name
chosen for it over exclude it.)
4.7. Change Control
Once a four week period.
5.2.2. Character Set Reviewer
When the two week period has passed and the registration
proposer is convinced that consensus content type has been achieved, published by IANA, the
registration application should be submitted author may
request a change to IANA and the
Character Set Reviewer. its definition. The character set reviewer, who is
appointed by descriptions of the IETF Applications Area Director(s), either
approves
different registration trees above designate the "owners" of
each type of registration. The change request for follows the same
procedure as the registration or rejects it.
Rejection may occur because of significant objections raised request:
(1) Publish the revised template on the list ietf-types list.
(2) Leave at least two weeks for comments.
(3) Publish using IANA after formal review if required.
Changes should be requested only when there are serious
omission or objections raised externally. If the character
set reviewer considers errors in the registration sufficiently important
and controversial, published specification. When review
is required, a last call for comments change request may be issued to denied if it renders
entities that were valid under the full IETF. previous definition invalid
under the new definition.
The character set reviewer owner of a content type may also recommend
standards track processing (before pass responsibility for the
content type to another person or after registration) when
that appears appropriate agency by informing IANA and
the level of specification ietf-types list; this can be done without discussion or
review.
The IESG may reassign responsibility for a media type. The
most common case of the
character set is adequate.
Decisions made by the reviewer must this will be posted to the ietf-
types mailing list within 14 days. Decisions made by the
reviewer may enable changes to be appealed made
to types where the IESG. author of the registration has died, moved
Expires June September 1996 [Page 14] 16]
Internet Draft MIME Registration Procedures December 1995
5.2.3. IANA Registration
Provided that the character set registration has either passed
review March 1996
out of contact or has been successfully appealed is otherwise unable to the IESG, the IANA
will register the character set and make its registration
available changes that are
important to the community.
5.3. Location of Registered Character Set List
Character set
Media type 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 description of
the character set may also not be published as an Informational
RFC deleted; media types which
are no longer believed appropriate for use can be declared
OBSOLETE by sending it to "rfc-editor@isi.edu" (please follow the
instructions a change to RFC authors [RFC-1543]).
5.4. Registration Template
To: ietf-charsets@innosoft.com
Subject: Registration of new character set
Character set name(s):
(All names must their "intended use" field; such media
types will be suitable for use as clearly marked in the value lists published by IANA.
4.8. Registration Template
To: ietf-types@cs.utk.edu
Subject: Registration of a MIME content-type parameter.) media type XXX/YYY
MIME media type name:
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published specification(s):
(A specification for the character set must be
openly available that accurately describes what
is being registered.) specification:
Applications which use this media type:
Additional information:
Magic number(s):
File extension(s):
Macintosh File Type Code(s):
Person & email address to contact for further information:
6.
Intended usage:
(One of COMMON, LIMITED USE or OBSOLETE)
Author/Change controller:
Expires September 1996 [Page 17]
Internet Draft MIME Registration Procedures March 1996
(Any other information that the author deems interesting may be
added below this line.)
5. External Body Access Types
RFC MIME-IMT defines the message/external-body media type,
whereby a MIME entity can act as pointer to the actual body
data in lieu of including the data directly in the entity
body. Each message/external-body reference specifies an access
type, which determines the mechanism used to retrieve the
Expires June 1996 [Page 15]
Internet Draft MIME Registration Procedures December 1995
actual body data. RFC MIME-IMT defines an initial set of
access types, but allows for the registration of additional
access types to accommodate new retrieval mechanisms.
6.1.
5.1. Registration Requirements
New access type specifications must conform to a number of
requirements as described below.
6.1.1.
5.1.1. Naming Requirements
Each access type must have a unique name. This name appears
in the access-type parameter in the message/external-body
content-type header field, and must conform to MIME content
type parameter syntax.
6.1.2.
5.1.2. Mechanism Specification Requirements
All of the protocols, transports, and procedures used by a
given access type must be described, either in the
specification of the access type itself or in some other
publicly available specification, in sufficient detail for the
access type to be implemented by any competent implementor.
Use of secret and/or proprietary methods in access types are
expressly prohibited. The restrictions imposed by RFC 1602 on
the standardization of patented algorithms must be respected
as well.
6.1.3.
Expires September 1996 [Page 18]
Internet Draft MIME Registration Procedures March 1996
5.1.3. Publication Requirements
All access types must be described by an RFC. The RFC may be
informational rather than standards-track, although standard-
track review and approval are encouraged for all access types.
6.1.4.
5.1.4. Security Requirements
Any known security issues that arise from the use of the
access type must be completely and fully described. It is not
required that the access type be secure or that it be free
from risks, but that the known risks be identified.
Expires June 1996 [Page 16]
Internet Draft MIME Registration Procedures December 1995
Publication of a new access type does not require an
exhaustive security review, and the security considerations
section is subject to continuing evaluation. Additional
security considerations should be addressed by publishing
revised versions of the access type specification.
6.1.5. Additional Information
Various sorts of optional information may be included in the
specification of a media type if it is available:
(1) Magic number(s) (length, octet values). Magic numbers
are byte sequences that are always present and thus can
be used to identify entities as being of a given media
type.
(2) File extension(s) commonly used on one or more
platforms to indicate that some file containing a given
type of media.
(3) Macintosh File Type code(s) (4 octets) used to label
files containing a given type of media.
Such information is often quite useful to implementors and if
available should be provided.
6.2.
5.2. Registration Procedure
Registration of a new access type starts with the construction
of a draft of an RFC.
6.2.1.
5.2.1. Present the Access Type to the Community
Send a proposed access type specification to the "ietf-
types@uninett.no"
types@cs.utk.edu" mailing list for a two week review period.
This mailing list has been established for the purpose of
reviewing proposed access and media types. Proposed access
types are not formally registered and must not be used.
The intent of the public posting is to solicit comments and
feedback on the access type specification and a review of any
security considerations.
Expires June 1996 [Page 17]
Internet Draft MIME Registration Procedures December 1995
6.2.2.
5.2.2. Access Type Reviewer
When the two week period has passed, the access type reviewer,
who is appointed by the IETF Applications Area Director,
either forwards the request to IANA@ISI.EDU, iana@isi.edu, or rejects it
because of significant objections raised on the list.
Expires September 1996 [Page 19]
Internet Draft MIME Registration Procedures March 1996
Decisions made by the reviewer must be posted to the ietf-
types mailing list within 14 days. Decisions made by the
reviewer may be appealed to the IESG.
6.2.3.
5.2.3. IANA Registration
Provided that the access type has either passed review or has
been successfully appealed to the IESG, the IANA will register
the access type and make the registration available to the
community. The specification of the access type must also be
published as an RFC. Informational RFCs are published by
sending them to "rfc-editor@isi.edu" (please follow the
instructions to RFC authors [RFC-1543]).
6.3.
5.3. Location of Registered Access Type List
Media
Access type registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/access-types" "ftp://ftp.isi.edu/in-
notes/iana/assignments/access-types/" and the all registered
access type types will be listed in the periodically issued
"Assigned Numbers" RFC [RFC-1700].
7. [currently RFC-1700].
5.4. IANA Procedures for Registering Access Types
The identity of the access type reviewer is communicated to
the IANA by the IESG. The IANA then only acts in response to
access type definitions that either are approved by the access
type reviewer and forwarded by the reviewer to the IANA for
registration, or in response to a communication from the IESG
that an access type definition appeal has overturned the
access type reviewer's ruling.
6. Transfer Encodings
Transfer encodings are tranformations applied to MIME media
types after conversion to the media type's canonical form.
Transfer encodings are used for several purposes:
(1) Many transports, especially message transports, can
only handle data consisting of relatively short lines
of text. There can also be severe restrictions on what
Expires September 1996 [Page 20]
Internet Draft MIME Registration Procedures March 1996
characters can be used in these lines of text -- some
transports are restricted to a small subset of US-ASCII
and others cannot handle certain character sequences.
Transfer encodings are used to transform binary data
into textual form that can survive such transports.
Expires June 1996 [Page 18]
Internet Draft MIME Registration Procedures December 1995
Examples of this sort of transfer encoding include the
base64 and quoted-printable transfer encodings defined
in MIME-IMB.
(2) Image, audio, video, and even application entities are
sometimes quite large. Compression algorithms are often
quite effective in reducing the size of large entities.
Transfer encodings can be used to apply general-purpose
non-lossy compression algorithms to MIME entities.
(3) Transport encodings can be defined as a means of
representing existing encoding formats in a MIME
context.
IMPORTANT: The standardization of a large numbers of
different transfer encodings is seen as a significant barrier
to widespread interoperability and is expressely discouraged.
Nevertheless, the following procedure has been defined to
provide a means of defining additional transfer encodings,
should standardization actually be justified.
7.1.
6.1. Transfer Encoding Requirements
Transfer encoding specifications must conform to a number of
requirements as described below.
7.1.1.
6.1.1. Naming Requirements
Each transfer encoding must have a unique name. This name
appears in the Content-Transfer-Encoding header field and must
conform to the syntax of that field.
7.1.2.
6.1.2. Algorithm Specification Requirements
All of the algorithms used in a transfer encoding (e.g.
conversion to printable form, compression) must be described
in their entirety in the transfer encoding specification. Use
Expires September 1996 [Page 21]
Internet Draft MIME Registration Procedures March 1996
of secret and/or proprietary algorithms in standardized
transfer encodings are expressly prohibited. The restrictions
imposed by RFC 1602 on the standardization of patented
algorithms must be respected as well.
Expires June 1996 [Page 19]
Internet Draft MIME Registration Procedures December 1995
7.1.3.
6.1.3. Input Domain Requirements
All transfer encodings must be applicable to an arbitrary
sequence of octets of any length. Dependence on particular
input forms is not allowed.
7.1.4.
It should be noted that the 7bit and 8bit encodings do not
conform to this requirement. Aside from the undesireability of
having specialized encodings, the intent here is to forbid the
addition of additional encodings along the lines of 7bit and
8bit.
6.1.4. Output Range Requirements
There is no requirement that a particular tranfer encoding
produce a particular form of encoded output. However, the
output format for each transfer encoding must be fully and
completely documented. In particular, each specification must
clearly state whether the output format always lies within the
confines of 7bit data, 8bit data, or is simply pure binary
data.
7.1.5.
6.1.5. Data Integrity and Generality Requirements
All transfer encodings must be fully invertible on any
platform; it must be possible for anyone to recover the
original data by performing the corresponding decoding
operation. Note that this requirement effectively excludes
all forms of lossy compression as well as all forms of
encryption from use as a transfer encoding.
7.1.6.
6.1.6. New Functionality Requirements
All transfer encodings must provide some sort of new
functionality. Some degree of functionality overlap with
previously defined transfer encodings is acceptable, but any
Expires September 1996 [Page 22]
Internet Draft MIME Registration Procedures March 1996
new transfer encoding must also offer something no other
transfer encoding provides.
7.2.
6.2. Transfer Encoding Definition Procedure
Definition of a new transfer encoding starts with the
construction of a draft of a standards-track RFC. The RFC
must define the transfer encoding precisely and completely,
and must also provide substantial justification for defining
and standardizing a new transfer encoding. This specification
must then be presented to the IESG for consideration. The
IESG can
Expires June 1996 [Page 20]
Internet Draft MIME Registration Procedures December 1995
(1) reject the specification outright as being
inappropriate for standardization,
(2) approve the formation of an IETF working group to work
on the specification in accordance with IETF
procedures, or,
(3) accept the specification as-is and put it directly on
the standards track.
Transfer encoding specifications on the standards track follow
normal IETF rules for standards track documents. A transfer
encoding is considered to be defined and available for use
once it is on the standards track.
8.
6.3. IANA Procedures for Transfer Encoding Registration
There is no need for a special procedure for registering
Transfer Encodings with the IANA. All legitimate transfer
encoding registrations must appear as a standards-track RFC,
so it is the IESG's responsibility to notify the IANA when a
new transfer encoding has been approved.
6.4. Location of Registered Transfer Encodings List
Transfer encoding registrations will be posted in the
anonymous FTP directory "ftp://ftp.isi.edu/in-
notes/iana/assignments/transfer-encodings/" and all registered
transfer encodings will be listed in the periodically issued
Expires September 1996 [Page 23]
Internet Draft MIME Registration Procedures March 1996
"Assigned Numbers" RFC [currently RFC-1700].
7. Authors' Addresses
For more information, the authors of this document are best
contacted via Internet mail:
Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA
Email: ned@innosoft.com
Phone: +1 818 919 3600
Fax: +1 818 919 3614
John Klensin, WG Chair
MCI
2100 Reston Parkway
Reston, VA 22091
Email: klensin@mci.net
Phone: +1 703 715-7361
Fax: +1 703 715-7436
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
USA
EMail: Postel@ISI.EDU
Phone: +1 310 822 1511
Fax: +1 310 823 6714
Expires June September 1996 [Page 21] 24]
Internet Draft MIME Registration Procedures March 1996
Appendix A -- Grandfathered Media Types
A number of media types, registered prior to 1996, would, if
registered under the guidelines in this document, be placed
into either the vendor or personal trees. Reregistration of
those types to reflect the appropriate trees is encouraged,
but not required. Ownership and change control principles
outlined in this document apply to those types as if they had
been registered in the trees described above.
Appendix B -- IANA and RFC Editor To-Do List
VERY IMPORTANT NOTE: This appendix is intended to communicate
various editorial and procedural tasks the IANA and the RFC
Editor should undertake prior to publication of this document
as an RFC. This appendix should NOT appear in the actual RFC
version of this document!
This document refers to the media types mailing list ietf-
types@cs.utk.edu. There is no guarantee that cs.utk.edu will
continue to be able to accomodate this list throughout the
lifetime of this document. As such, this reference should be
replaced by an address of the general form ietf-
types@iana.org. The actual list can then either be moved to
this location or forwarders can be installed to redirect
traffic to the host that currently maintains the list.
The "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-
encodings/" area does not exist at the present time and needs
to be created. At the time of this writing the only valid
transfer-encodings are
(1) 7bit
(2) 8bit
(3) binary
(4) quoted-printable, and
Expires September 1996 [Page 25]
Internet Draft MIME Registration Procedures March 1996
(5) base64,
and all of them are defined by this set of documents.
The "ftp://ftp.isi.edu/in-notes/iana/assignments/access-
types/" area does not exist at the present time and needs to
be created. At the time of this writing the only valid
access-types are
(1) ftp
(2) anon-ftp
(3) tftp
(4) local-file, and
(5) mail-server,
and all of them are defined by this set of documents.
Expires September 1996 [Page 26]
----