Network Working Group                      Ned Freed, Innosoft
Internet Draft                                John Postel, ISI
                           <draft-ietf-822ext-mime-reg-02.txt>

            Multipurpose Internet Mail Extensions
                      (MIME) Part Four:

                   Registration Procedures

                        December 1995



                     Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted
by other documents at any time.  It is not appropriate to use
Internet-Drafts as reference material or to cite them other
than as a "working draft" or "work in progress".

To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the
Internet-Drafts Shadow Directories on ds.internic.net (US East
Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast),
or munnari.oz.au (Pacific Rim).


1.  Abstract

STD 11, RFC 822, defines a message representation protocol
specifying considerable detail about US-ASCII message headers,
and leaves the message content, or message body, as flat US-
ASCII text.  This set of documents, collectively called the
Multipurpose Internet Mail Extensions, or MIME, redefines the
format of messages to allow for














Internet Draft   MIME Registration Procedures    December 1995


 (1)   textual message bodies in character sets other than
       US-ASCII,

 (2)   non-textual message bodies,

 (3)   multi-part message bodies, and

 (4)   textual header information in character sets other than
       US-ASCII.

These documents are based on earlier work documented in RFC
934, STD 11, and RFC 1049, but extends and revises them.
Because RFC 822 said so little about message bodies, these
documents are largely orthogonal to (rather than a revision
of) RFC 822.

In particular, these documents are designed to provide
facilities to include multiple parts in a single message, to
represent body and header text in character sets other than
US-ASCII, to represent formatted multi-font text messages, to
represent non-textual material such as images and audio 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)   content-transfer-encodings.

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 1996               [Page 2]


Internet Draft   MIME Registration Procedures    December 1995


2.  Table of Contents


1 Abstract ..............................................    1
2 Table of Contents .....................................    3
3 Introduction ..........................................    4
4 Media Type Registration ...............................    4
4.1 Registration Requirements ...........................    5
4.1.1 Functionality Requirements ........................    5
4.1.2 Naming Requirements ...............................    5
4.1.3 Parameter Requirements ............................    6
4.1.4 Format and Canonicalization Requirements ..........    6
4.1.5 Interchange Requirements ..........................    7
4.1.6 Security Requirements .............................    7
4.1.7 Usage and Implementation Requirements .............    7
4.1.8 Publication Requirements ..........................    8
4.2 Registration Procedure ..............................    8
4.2.1 Present the Media Type to the Community ...........    8
4.2.2 Media Type Reviewer ...............................    9
4.2.3 IANA Registration .................................    9
4.3 Location of Registered Media Type List ..............   10
4.4 Change Control ......................................   10
4.5 Registration Template ...............................   11
5 Character Set Registration ............................   12
5.1 Registration Requirements ...........................   12
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 Requirements .............   13
5.1.5 Publication Requirements ..........................   13
5.2 Registration Procedure ..............................   14
5.2.1 Present the Character Set to the Community ........   14
5.2.2 Character Set Reviewer ............................   14
5.2.3 IANA Registration .................................   15
5.3 Location of Registered Character Set List ...........   15
5.4 Registration Template ...............................   15
6 External Body 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





                      Expires June 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 Transfer Encodings ....................................   18
7.1 Transfer Encoding Requirements ......................   19
7.1.1 Naming Requirements ...............................   19
7.1.2 Algorithm Specification Requirements ..............   19
7.1.3 Input Domain Requirements .........................   20
7.1.4 Output Range Requirements .........................   20
7.1.5 Data Integrity Requirements .......................   20
7.1.6 New Functionality Requirements ....................   20
7.2 Transfer Encoding Definition Procedure ..............   20
8 Authors' Addresses ....................................   21


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 proposal is





                      Expires June 1996               [Page 4]


Internet Draft   MIME Registration Procedures    December 1995


then circulated and reviewed. The media type is then
registered if the proposal is acceptable. The following
sections describe requirements and procedures involved.


4.1.  Registration Requirements

Media type registration proposals are expected to conform to a
number of requirements as described below.


4.1.1.  Functionality Requirements

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
subtype of application.


4.1.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.

The choice of top-level type name must take the nature of
media type involved into account. For example, media capable
of representing still images should be a subtype of the image
content type, whereas media capable of representing audio
information belongs under the audio content type. See RFC
MIME-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





                      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 used to define additional top-level content
types.


4.1.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 subtype.  In either case, the names, values, and meanings
of any parameters must be fully specified when the content
type and subtype are defind.  New parameters should not be
defined as a way to introduce new functionality, although new
parameters may be defined to convey additional information
that does not otherwise change the functionality.  An example
of this would be a "revision" parameter to indicate a revision
level of an external specification such as JPEG or a character
set.


4.1.4.  Format and Canonicalization Requirements

All registered media types must employ a single, canonical
data format.  A precise and openly available specification of
the format of each media type is preferred, and if such a
specification is available the media type registration must
reference it.

However, requiring such a specification for all media types
would block the registration of proprietary formats, and as
such is unduly restrictive. Therefore this format requirement
can be met by the specification of a particular version or
versions of a particular software package or packages that
understand the format.  The appropriateness of using a media
type with an unavailable specification should not be an issue
in the registration process.

Some media types involve the use of patented technology.  The
registration of such types is specifically allowed.  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.





                      Expires June 1996               [Page 6]


Internet Draft   MIME Registration Procedures    December 1995


4.1.5.  Interchange Requirements

Media type 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.

It is not required that the media type be universally
interoperable, but that the known interoperability issues be
identified.  Publication of a media type does not require an
exhaustive review of interoperability, and the
interoperability considerations section is subject to
continuing evaluation.


4.1.6.  Security Requirements

Any known security issues that arise from the use of the media
type must be completely and fully described.  See the
registration of the application/postscript media type in RFC
MIME-IMT for an example of what sort of security issues can
arise from the use of one particular media type.

It is not required that the media type be secure or that it be
free from risks, but that the known risks be identified.
Publication of a media type does not require an exhaustive
security review, and the security considerations section is
subject to continuing evaluation.


4.1.7.  Usage and Implementation Requirements

In the asynchronous mail environment, where information on the
capabilities of the remote mail agent is not available to the
sender, maximum interoperability is attained by restricting
the number of media types used to those "common" formats
expected to be widely implemented.  This was asserted in the
past as a reason to limit the number of possible media types
and resulted in a registration process with a significant
hurdle and delay for those registering media types.

However, the need for "common" media types does not require
limiting the registration of new media types. If a limited set





                      Expires June 1996               [Page 7]


Internet Draft   MIME Registration Procedures    December 1995


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.1.8.  Publication Requirements

Media type registrations can be published as RFCs, however,
RFC publication is not required to register a new media type.

The registration of a data type does not imply endorsement,
approval, or recommendation by IANA or IETF or even
certification that the specification is adequate.  To become
Internet Standards, protocol, data objects, or whatever must
go through the IETF standards process.  This is too difficult
and too lengthy a process for the convenient registration of
media types.  It is expected that applicability statements for
particular applications will be published from time to time
that recommend implementation of, and support for, data types
that have proven particularly useful in those contexts.

As discussed above, registration of a top-level type requires
standards-track processing and, hence, RFC publication.


4.2.  Registration Procedure

The following procedure has been implemented by the IANA for
review and approval of new media types.  This is not a formal
standards process, but rather an administrative procedure
intended to allow community comment and sanity checking
without excessive time delay.


4.2.1.  Present the Media Type to the Community

Send a proposed media type registration to the "ietf-
types@uninett.no" 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





                      Expires June 1996               [Page 8]


Internet Draft   MIME Registration Procedures    December 1995


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.2.2.  Media Type Reviewer

When the two week period has passed and the registration
proposer is convinced that consensus has been achieved, the
registration application should be submitted to IANA and the
Media Type Reviewer. The media type reviewer, who is appointed
by the IETF Applications Area Director(s), either approves the
request for registration or rejects it.  Rejection may occur
because of significant objections raised on the list or
objections raised externally.  If the media type reviewer
considers the registration sufficiently important and
controversial, a last call for comments may be issued to the
full IETF.  The media type reviewer may also recommend
standards track processing (before or after registration) when
that appears appropriate and the level of specification of the
media type is adequate.

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.


4.2.3.  IANA Registration

Provided that the media type has either passed review or has
been successfully appealed to the IESG, the IANA will register
the media type,  and make the media type registration
available to the community.









                      Expires June 1996               [Page 9]


Internet Draft   MIME Registration Procedures    December 1995


4.3.  Location of Registered Media Type List

Media type registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/media-types"
and the media type will be listed in the periodically issued
"Assigned Numbers" RFC [RFC-1700].  The media type description
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.4.  Change Control

Once a content type has been published by IANA, the author may
request a change to its definition. The change request follows
the same procedure as the registration request:

 (1)   Publish a template on the ietf-types list.

 (2)   Leave at least two weeks for comments.

 (3)   Get acceptance from the 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" to a
requested change if it renders entities that were valid under
the previous definition invalid under the new definition, but
is not obliged to do so in all cases.

The author 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
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





                      Expires June 1996              [Page 10]


Internet Draft   MIME Registration Procedures    December 1995


OBSOLETE by a change to their "intended use" field; such media
types will be clearly marked in the lists published by IANA.


4.5.  Registration Template

  To: ietf-types@uninett.no
  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:

  Additional information (optional):

    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:

  (Any other information that the author deems interesting may be
  added below this line.)









                      Expires June 1996              [Page 11]


Internet Draft   MIME Registration Procedures    December 1995


5.  Character Set Registration

MIME and other modern Internet protocols are capable of using
many different character sets. This in turn means that the
ability to label different character sets is essential. This
registration procedure exists solely to associate a specific
name or names with a given character set.


5.1.  Registration Requirements

Registered character sets are expected to conform to a number
of requirements as described below.


5.1.1.  Required Characteristics

Registered character sets must conform to the definition of a
"character set" given in RFC MIME-IMB. In addition, character
sets intended for use in content types under the "text" top-
level type must conform to the restrictions on that type
described in RFC MIME-IMB. All registered character sets must
note whether or not they are suitable for such usage.

All registered character sets must be specified in an openly
available specification.

NOTE: The definition of "character set" in this context is the
one given in RFC MIME-IMB. Other, incompatible definitions of
"character set" are in use in other communities; please read
the definition in MIME-IMB carefully before trying to decide
what to register as a character set.


5.1.2.  New Character Sets

This registration mechanism is not intended to be a vehicle
for the definition of entirely new character sets. This is due
to the fact that the registration process does NOT contain
adequate review mechanisims for such undertakings.

As such, only character sets defined by other processes and
standards bodies, or specific profiles of such character sets,
are eligible for registration.






                      Expires June 1996              [Page 12]


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 the same character set are permitted,
but if multiple names are assigned a single primary name for
the character set must be identified. All other names are
considered to be aliases for the primary name and use of the
primary name is preferred over use of any of the aliases.

Each name must uniquely identify a single character set. All
character set names must be suitable for use as the value of a
MIME content type charset parameter and hence must conform to
MIME parameter value syntax. This applies even if the specific
character set being registered is not suitable for use with
"text".


5.1.4.  Usage and Implementation Requirements

Use of a large number 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 be registered ONLY if it adds
significant functionality that is valuable 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 of limited or
specialized use.


5.1.5.  Publication Requirements

Character set registrations can be published in RFCs, however,
RFC publication is not required to register a new character
set.

The registration of a character set does not imply
endorsement, approval, or recommendation by the IANA, IESG, or
IETF, or even certification that the specification is
adequate. It is expected that applicability statements for
particular applications will be published from time to time
that recommend implementation of, and support for, character
sets that have proven particularly useful in those contexts.





                      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 and approval of new character sets.  This is not a
formal standards process, but rather an administrative
procedure intended to allow community comment and sanity
checking without excessive time delay.


5.2.1.  Present the Character Set to the Community

Send the proposed character set registration to the "ietf-
charsets@innosoft.com" mailing list.  This mailing list has
been established for the sole purpose of reviewing proposed
character set registrations. Proposed character sets are not
formally registered and must not be used; the "x-" prefix
specified in RFC MIME-IMB can be used until registration is
complete.

The intent of the public posting is to solicit comments and
feedback on the definition of the character set and the name
chosen for it over 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 has been achieved, the
registration application should be submitted to IANA and the
Character Set Reviewer. The character set reviewer, who is
appointed by the IETF Applications Area Director(s), either
approves the request for registration or rejects it.
Rejection may occur because of significant objections raised
on the list or objections raised externally.  If the character
set reviewer considers the registration sufficiently important
and controversial, a last call for comments may be issued to
the full IETF. The character set reviewer may also recommend
standards track processing (before or after registration) when
that appears appropriate and the level of specification of the
character set is adequate.

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.






                      Expires June 1996              [Page 14]


Internet Draft   MIME Registration Procedures    December 1995


5.2.3.  IANA Registration

Provided that the character set registration has either passed
review or has been successfully appealed to the IESG, the IANA
will register the character set and make its registration
available to the community.


5.3.  Location of Registered Character Set List

Character set registrations will be posted in the anonymous
FTP file "ftp.isi.edu:in-notes/iana/assignments/character-
sets" and the character set will be listed in the periodically
issued "Assigned Numbers" RFC [RFC-1700]. The description of
the character set 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]).


5.4.  Registration Template

  To: ietf-charsets@innosoft.com
  Subject: Registration of new character set

  Character set name(s):

  (All names must be suitable for use as the value of a
  MIME content-type parameter.)

  Published specification(s):

  (A specification for the character set must be
  openly available that accurately describes what
  is being registered.)

  Person & email address to contact for further information:


6.  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.  Registration Requirements

New access type specifications must conform to a number of
requirements as described below.


6.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.  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.  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.  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.  Registration Procedure

Registration of a new access type starts with the construction
of a draft of an RFC.


6.2.1.  Present the Access Type to the Community

Send a proposed access type specification to the "ietf-
types@uninett.no" 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.  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.

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.  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.  Location of Registered Access Type List

Media type registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/iana/assignments/access-types"
and the access type will be listed in the periodically issued
"Assigned Numbers" RFC [RFC-1700].


7.  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
       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.  Transfer Encoding Requirements

Transfer encoding specifications must conform to a number of
requirements as described below.


7.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.  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
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.  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.  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.  Data Integrity Requirements

All transfer encodings must be fully invertible on any
platform; it must be possible to recover the original data by
performing the corresponding decoding operation.  Note that
this requirement effectively excludes all forms of lossy
compression from use as a transfer encoding.


7.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
new transfer encoding must also offer something no other
transfer encoding provides.


7.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.  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

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 1996              [Page 21]