Network Working Group Ned Freed, Innosoft
Internet Draft John Klensin, MCI
<draft-ietf-822ext-mime-reg-03.txt> John Postel, ISI
Multipurpose Internet Mail Extensions
(MIME) Part Four:
Registration Procedures
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 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.
This fourth document, RFC MIME-REG, specifies various IANA
registration procedures for the following MIME facilities:
(1) media types,
(2) external body access types,
(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 September 1996 [Page 2]
Internet Draft MIME Registration Procedures March 1996
2. Table of Contents
1 Abstract .............................................. 1
2 Table of Contents ..................................... 3
3 Introduction .......................................... 5
4 Media Type Registration ............................... 5
4.1 Registration Trees and Subtype Names ................ 5
4.1.1 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 ............................... 8
4.2.3 Parameter Requirements ............................ 9
4.2.4 Canonicalization and Format Requirements .......... 10
4.2.5 Interchange Recommendations ....................... 10
4.2.6 Security Requirements ............................. 11
4.2.7 Usage and Implementation Non-requirements ......... 12
4.2.8 Publication Requirements .......................... 12
4.2.9 Additional Information ............................ 13
4.3 Registration Procedure .............................. 14
4.3.1 Present the Media Type to the Community for Re-
view ............................................... 14
4.3.2 IESG Approval ..................................... 14
4.3.3 IANA Registration ................................. 15
4.4 Comments on Media Type Registrations ................ 15
4.5 Location of Registered Media Type List .............. 15
4.6 IANA Procedures for Registering Media Types ......... 15
4.7 Change Control ...................................... 16
4.8 Registration Template ............................... 17
5 External Body Access Types ............................ 18
5.1 Registration Requirements ........................... 18
5.1.1 Naming Requirements ............................... 18
5.1.2 Mechanism Specification Requirements .............. 18
5.1.3 Publication Requirements .......................... 19
5.1.4 Security Requirements ............................. 19
5.2 Registration Procedure .............................. 19
5.2.1 Present the Access Type to the Community .......... 19
5.2.2 Access Type Reviewer .............................. 19
5.2.3 IANA Registration ................................. 20
5.3 Location of Registered Access Type List ............. 20
5.4 IANA Procedures for Registering Access Types ........ 20
Expires September 1996 [Page 3]
Internet Draft MIME Registration Procedures March 1996
6 Transfer Encodings .................................... 20
6.1 Transfer Encoding Requirements ...................... 21
6.1.1 Naming Requirements ............................... 21
6.1.2 Algorithm Specification Requirements .............. 21
6.1.3 Input Domain Requirements ......................... 22
6.1.4 Output Range Requirements ......................... 22
6.1.5 Data Integrity and Generality Requirements ........ 22
6.1.6 New Functionality Requirements .................... 22
6.2 Transfer Encoding Definition Procedure .............. 23
6.3 IANA Procedures for Transfer Encoding Registration
.................................................... 23
6.4 Location of Registered Transfer Encodings List ...... 23
7 Authors' Addresses .................................... 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. Registration may
occur in several different registration trees, which have
different requirements as discussed below. In general, the
new registration proposal is circulated and 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 used for
each of the different registration trees.
4.1. Registration Trees and Subtype Names
In order to increase the efficiency and flexibility of the
registration process, different structures of subtype names
may be registered to accomodate the different natural
requirements for, e.g., a subtype that will be recommended for
Expires September 1996 [Page 5]
Internet Draft MIME Registration Procedures March 1996
wide support and implementation by the Internet Community or a
subtype that is used to move files associated with proprietary
software. The following subsections define registration
"trees", distinguished by the use of faceted names (e.g.,
names of the form "tree.subtree...type"). Note that some
media types defined prior to this specification do not conform
to the naming conventions described below. See Appendix A for
a discussion of them.
4.1.1. IETF Tree
The IETF tree is intended for types of general interest to the
Internet Community. Registration in the IETF tree requires
approval by the IESG and publication of the media type
registration as some form of RFC.
Media types in the IETF tree are normally denoted by names
that are not explicitly faceted, i.e., do not contain period
(".", full stop) characters.
The "owner" of a media type registration in the IETF tree is
assumed to 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 for media types associated with
commercially available products. "Vendor" or "producer" are
construed as equivalent and very broadly in this context.
A registration may be placed in the vendor tree by anyone who
has need to interchange files associated with the particular
product. However, the registration formally belongs to the
vendor or organization producing the software or file format.
Changes to the specification will be made at their request, as
discussed in subsequent sections.
Registrations in the vendor tree will be distinguished by the
leading facet "vnd.". That may be followed, at the discretion
of the registration, by either a media type name from a well-
known producer (e.g., "vnd.mudpie") or by an IANA-approved
designation of the 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 review of media types to be
registered in the vendor tree is not required, using the
ietf-types list for review is strongly encouraged to improve
the quality of those specifications. Registrations in the
vendor tree may be submitted directly to the IANA.
4.1.3. Personal or Vanity Tree
Registrations for media types created experimentally or as
part of products that are not distributed commercially may be
registered in the personal or vanity tree. The registrations
are distinguished by the leading facet "prs.".
The owner of "personal" registrations and associated
specifications is the person or entity making the
registration, or one to whom responsibility has been
transferred as described below.
While public exposure and review of media types to be
registered in the personal tree is not required, using the
ietf-types list for review is strongly encouraged to improve
the quality of those specifications. Registrations in the
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 "x." as the first facet may be used for
the same purposes for which names starting in "x-" are
normally used. These types are unregistered, experimental,
and should be used only with the active agreement of the
parties exchanging them.
However, with the simplified registration procedures described
above for vendor and personal trees, it should rarely, if
ever, be necessary to use unregistered experimental types, and
as such use of both "x-" and "x." forms is discouraged.
Expires September 1996 [Page 7]
Internet Draft MIME Registration Procedures March 1996
4.1.5. Additional Registration Trees
From time to time and as required by the community, the IANA
may, with the advice and consent of the IESG, create new top-
level registration trees. It is explicitly assumed that these
trees may be created for external registration and management
by well-known permanent bodies, such as scientific societies
for media types specific to the sciences they cover. In
general, the quality of review of specifications for one of
these additional registration trees is expected to be
equivalent to that which IETF would give to registrations in
its own tree. Establishment of these new trees will be
announced through RFC publication approved by the IESG.
4.2. Registration Requirements
Media type registration proposals are all expected to conform
to various requirements laid out in the following sections.
Note that requirement specifics sometimes vary depending on
the registration tree, again as detailed in the following
sections.
4.2.1. Functionality Requirement
Media types must function as an actual media format:
Registration 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 be 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 and
subtype names. The combination of these names then serves to
uniquely identify the media type and the format of the subtype
name identifies the registration tree.
Expires September 1996 [Page 8]
Internet Draft MIME Registration Procedures March 1996
The choice of top-level type name must take the nature of
media type involved into account. For example, media normally
used for 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-IMT for additional information on the basic set of
top-level 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 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
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 of its subtypes. In either case, the names, values, and
meanings of any parameters must be fully specified when a
media type is registered in the IETF tree, and should be
specified as completely as possible when media types are
registered in the vendor or personal trees.
New parameters must not be defined as a way to introduce new
functionality in types registered in the IETF tree, although
new parameters may be added to convey additional information
that does not otherwise change existing functionality. An
example of this would be a "revision" parameter to indicate a
revision level of 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 September 1996 [Page 9]
Internet Draft MIME Registration Procedures March 1996
4.2.4. Canonicalization and Format Requirements
All registered media types must employ a single, canonical
data format, regardless of registration tree.
A precise and openly available specification of the format of
each media type is required for all types registered in the
IETF tree and must at a minimum be referenced by, if it isn't
actually included in, the media type registration proposal
itself.
The specifications of format and processing particulars may or
may not be publically available for media types registered in
the vendor tree, and such registration proposals are
explicitly permitted to include only a specification of which
software and version produce or process such media types.
References to or inclusion of format specifications in
registration proposals is encouraged but not required.
Format specifications are still required for registration in
the personal tree, but may be either published as RFCs or
otherwise deposited with IANA. The deposited specifications
will meet the same criteria as those required to register a
well-known TCP port and, in particular, need not be made
public.
Some media types involve the use of patented technology. The
registration of media types involving patented technology is
specifically permitted. However, the restrictions set forth
in RFC 1602 on the use of patented technology in standards-
track protocols must be respected when the specification of a
media type is part of a standards-track protocol.
4.2.5. Interchange Recommendations
Media types should, whenever possible, interoperate across as
many systems and applications as possible. However, some media
types will inevitably have problems interoperating across
different platforms. Problems with different versions, byte
ordering, and specifics of gateway handling can and will
arise.
Universal interoperability of media types is not required, but
known interoperability issues should be identified whenever
Expires September 1996 [Page 10]
Internet Draft MIME Registration Procedures March 1996
possible. Publication of a media type 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 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
have not been assessed".
There is absolutely no requirement that media types registered
in any tree be secure or completely free from risks.
Nevertheless, all known security risks must be identified in
the registration of a media type, again regardless of
registration tree.
The security considerations section of all registrations is
subject to continuing evaluation and modification, and in
particular may be extended by use of the "comments on media
types" mechanism described in subsequent sections.
Some of the issues that should be looked at in a security
analysis of a media type are:
(1) Complex media types may include provisions for
directives that institute actions on a recipient's
files or other resources. In many cases provision is
made for originators to specify arbitrary actions in an
unrestricted fashion which may then have devastating
effects. See the registration of the
application/postscript media type in RFC MIME-IMT for
an example of such directives and how to handle them.
Expires September 1996 [Page 11]
Internet Draft MIME Registration Procedures March 1996
(2) Complex media types may include provisions for
directives that institute actions which, while not
directly harmful to the recipient, may result in
disclosure of information that either facilitates a
subsequent attack or else violates a recipient's
privacy in some way. Again, the registration of the
application/postscript media type illustrates how such
directives can be 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 could be 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
capabilities of the remote mail agent is frequently 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.
However, the 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 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.
4.2.8. Publication Requirements
Proposals for media types registered in the IETF tree must be
published as RFCs. RFC publication of vendor and personal
Expires September 1996 [Page 12]
Internet Draft MIME Registration Procedures March 1996
media type proposals is encouraged but not required. In all
cases IANA will retain copies of all media type proposals and
"publish" them as part of 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 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
type registered directly by submitting the template and an
explanation directly to IANA (at iana@isi.edu). However,
authors of vendor or personal media type specifications are
encouraged to seek community review and comment whenever that
is feasible.
4.3.1. Present the Media Type to the Community for Review
Send a proposed media type registration to the "ietf-
types@cs.utk.edu" mailing list for a two week review period.
This mailing list has been established for the purpose of
reviewing proposed media and access 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 type/subtype name, the unambiguity
of the references with respect to versions and external
profiling information, and a review of any interoperability or
security considerations. The submitter may submit a revised
registration, or withdraw the registration completely, at any
time.
4.3.2. IESG Approval
Media types registered in the IETF tree must be submitted to
the IESG for approval.
Expires September 1996 [Page 14]
Internet Draft MIME Registration Procedures March 1996
4.3.3. IANA Registration
Provided that the media type meets the requirements for media
types and has obtained whateveer approval is necessary, the
author may submit the registration request to the IANA, which
will register the media type and make the media type
registration available to the community.
4.4. Comments on Media Type Registrations
Comments on registered media types may be submitted by members
of the community to IANA. These comments will be passed on to
the "owner" of the media type if possible. Submitters of
comments may request that their comment be attached to the
media type registration itself, and if IANA approves of this
the comment will be made accessible in conjunction with the
type registration itself.
4.5. Location of Registered Media Type List
Media type registrations will be posted in the anonymous FTP
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-
types/" and all registered media types will be listed in the
periodically issued "Assigned Numbers" RFC [currently RFC-
1700]. The media type description and other supporting
material may also be published as an Informational RFC by
sending it to "rfc-editor@isi.edu" (please follow the
instructions to RFC authors [RFC-1543]).
4.6. IANA Procedures for Registering Media Types
The IANA will only register media types in the IETF tree in
response to a communication from the IESG stating that a given
registration has been approved. Vendor and personal types will
be registered by the 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 and transfer encodings
may not 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 be defined by a
standards-track RFC. All subtype names must be unique,
must conform to the MIME grammar for such names, and
must contain the proper tree prefix.
(3) Types registered in the personal tree must either
provide a format specification or a pointer to one.
(4) Any security considerations given must not be obviously
bogus. (It is neither possible nor necessary for the
IANA to conduct a comprehensive security review of
media type registrations. Nevertheless, IANA has the
authority to identify obviously incompetent material
and exclude it.)
4.7. Change Control
Once a content type has been published by IANA, the author may
request a change to its definition. The descriptions of the
different registration trees above designate the "owners" of
each type of registration. The change request follows the same
procedure as the registration request:
(1) Publish the revised template on the 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 errors in the published specification. When review
is required, a change request may be denied if it renders
entities that were valid under the previous definition invalid
under the new definition.
The owner of a content type may pass responsibility for the
content type to another person or agency by informing IANA and
the 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 this will be to enable changes to be made
to types where the author of the registration has died, moved
Expires September 1996 [Page 16]
Internet Draft MIME Registration Procedures March 1996
out of contact or is otherwise unable to make changes that are
important to the community.
Media type registrations may not be deleted; media types which
are no longer believed appropriate for use can be declared
OBSOLETE by a change to their "intended use" field; such media
types will be clearly marked in the lists published by IANA.
4.8. Registration Template
To: ietf-types@cs.utk.edu
Subject: Registration of MIME media type XXX/YYY
MIME media type name:
MIME subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations:
Published 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:
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
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.
5.1. Registration Requirements
New access type specifications must conform to a number of
requirements as described below.
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.
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.
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.
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.
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.
5.2. Registration Procedure
Registration of a new access type starts with the construction
of a draft of an RFC.
5.2.1. Present the Access Type to the Community
Send a proposed access type specification to the "ietf-
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.
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, 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.
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]).
5.3. Location of Registered Access Type List
Access type registrations will be posted in the anonymous FTP
directory "ftp://ftp.isi.edu/in-
notes/iana/assignments/access-types/" and all registered
access types will be listed in the periodically issued
"Assigned Numbers" RFC [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.
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.
6.1. Transfer Encoding Requirements
Transfer encoding specifications must conform to a number of
requirements as described below.
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.
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.
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.
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.
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.
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.
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
(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.
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 September 1996 [Page 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]
