As per Relevance of the word registration, we have this rfc below:
Network Working Group N.
Request for Comments: 2048
BCP: 13 J.
Obsoletes: 1521, 1522, 1590
Category: Best Current Practice J.
November 1996
Multipurpose Internet Mail
(MIME) Part Four
Registration
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
STD 11, RFC 822, defines a message representation protocol
considerable detail about US-ASCII message headers, and leaves
message content, or message body, as flat US-ASCII text. This set
documents, collectively called the Multipurpose Internet
Extensions, or MIME, redefines the format of messages to allow
(1) textual message bodies in character sets other
US-ASCII
(2) an extensible set of different formats for non-
message bodies
(3) multi-part message bodies,
(4) textual header information in character sets other
US-ASCII
These documents are based on earlier work documented in RFC 934,
11, and RFC 1049, but extends and revises them. Because RFC 822
so little about message bodies, these documents are
orthogonal to (rather than a revision of) RFC 822.
Freed, et. al. Best Current Practice [Page 1]
RFC 2048 MIME Registration Procedures November 1996
This fourth document, RFC 2048, specifies various IANA
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
and is no longer addressed by this document
These documents are revisions of RFCs 1521 and 1522, which
were revisions of RFCs 1341 and 1342. An appendix in RFC 2049
describes differences and changes from previous versions
Table of
1. Introduction ......................................... 3
2. Media Type Registration .............................. 4
2.1 Registration Trees and Subtype Names ................ 4
2.1.1 IETF Tree ......................................... 4
2.1.2 Vendor Tree ....................................... 4
2.1.3 Personal or Vanity Tree ........................... 5
2.1.4 Special `x.' Tree ................................. 5
2.1.5 Additional Registration Trees ..................... 6
2.2 Registration Requirements ........................... 6
2.2.1 Functionality Requirement ......................... 6
2.2.2 Naming Requirements ............................... 6
2.2.3 Parameter Requirements ............................ 7
2.2.4 Canonicalization and Format Requirements .......... 7
2.2.5 Interchange Recommendations ....................... 8
2.2.6 Security Requirements ............................. 8
2.2.7 Usage and Implementation Non-requirements ......... 9
2.2.8 Publication Requirements .......................... 10
2.2.9 Additional Information ............................ 10
2.3 Registration Procedure .............................. 11
2.3.1 Present the Media Type to the Community for Review 11
2.3.2 IESG Approval ..................................... 12
2.3.3 IANA Registration ................................. 12
2.4 Comments on Media Type Registrations ................ 12
2.5 Location of Registered Media Type List .............. 12
2.6 IANA Procedures for Registering Media Types ......... 12
2.7 Change Control ...................................... 13
2.8 Registration Template ............................... 14
3. External Body Access Types ........................... 14
3.1 Registration Requirements ........................... 15
3.1.1 Naming Requirements ............................... 15
Freed, et. al. Best Current Practice [Page 2]
RFC 2048 MIME Registration Procedures November 1996
3.1.2 Mechanism Specification Requirements .............. 15
3.1.3 Publication Requirements .......................... 15
3.1.4 Security Requirements ............................. 15
3.2 Registration Procedure .............................. 15
3.2.1 Present the Access Type to the Community .......... 16
3.2.2 Access Type Reviewer .............................. 16
3.2.3 IANA Registration ................................. 16
3.3 Location of Registered Access Type List ............. 16
3.4 IANA Procedures for Registering Access Types ........ 16
4. Transfer Encodings ................................... 17
4.1 Transfer Encoding Requirements ...................... 17
4.1.1 Naming Requirements ............................... 17
4.1.2 Algorithm Specification Requirements .............. 18
4.1.3 Input Domain Requirements ......................... 18
4.1.4 Output Range Requirements ......................... 18
4.1.5 Data Integrity and Generality Requirements ........ 18
4.1.6 New Functionality Requirements .................... 18
4.2 Transfer Encoding Definition Procedure .............. 19
4.3 IANA Procedures for Transfer Encoding Registration... 19
4.4 Location of Registered Transfer Encodings List ...... 19
5. Authors' Addresses ................................... 20
A. Grandfathered Media Types ............................ 21
1.
Recent Internet protocols have been carefully designed to be
extensible in certain areas. In particular, MIME [RFC 2045] is
open-ended framework and can accommodate additional object types
character sets, and access methods without any changes to the
protocol. A registration process is needed, however, to ensure
the set of such values is developed in an orderly, well-specified
and public manner
This document defines registration procedures which use the
Assigned Numbers Authority (IANA) as a central registry for
values
Historical Note: The registration process for media types
initially defined in the context of the asynchronous Internet
environment. In this mail environment there is a need to limit
number of possible media types to increase the likelihood
interoperability when the capabilities of the remote mail system
not known. As media types are used in new environments, where
proliferation of media types is not a hindrance to interoperability
the original procedure was excessively restrictive and had to
generalized
Freed, et. al. Best Current Practice [Page 3]
RFC 2048 MIME Registration Procedures November 1996
2. Media Type
Registration of a new media type or types starts with
construction of a registration proposal. Registration may occur
several different registration trees, which have
requirements as discussed below. In general, the new
proposal is circulated and reviewed in a fashion appropriate to
tree involved. The media type is then registered if the proposal
acceptable. The following sections describe the requirements
procedures used for each of the different registration trees
2.1. Registration Trees and Subtype
In order to increase the efficiency and flexibility of
registration process, different structures of subtype names may
registered to accomodate the different natural requirements for
e.g., a subtype that will be recommended for wide support
implementation by the Internet Community or a subtype that is used
move files associated with proprietary software. The
subsections define registration "trees", distinguished by the use
faceted names (e.g., names of the form "tree.subtree...type").
that some media types defined prior to this document do not
to the naming conventions described below. See Appendix A for
discussion of them
2.1.1. IETF
The IETF tree is intended for types of general interest to
Internet Community. Registration in the IETF tree requires
by the IESG and publication of the media type registration as
form of RFC
Media types in the IETF tree are normally denoted by names that
not explicitly faceted, i.e., do not contain period (".", full stop
characters
The "owner" of a media type registration in the IETF tree is
to be the IETF itself. Modification or alteration of
specification requires the same level of processing (e.g.
track) required for the initial registration
2.1.2. Vendor
The vendor tree is used for media types associated with
available products. "Vendor" or "producer" are construed
equivalent and very broadly in this context
Freed, et. al. Best Current Practice [Page 4]
RFC 2048 MIME Registration Procedures November 1996
A registration may be placed in the vendor tree by anyone who
need to interchange files associated with the particular product
However, the registration formally belongs to the vendor
organization producing the software or file format. Changes to
specification will be made at their request, as discussed
subsequent sections
Registrations in the vendor tree will be distinguished by the
facet "vnd.". That may be followed, at the discretion of
registration, by either a media type name from a well-known
(e.g., "vnd.mudpie") or by an IANA-approved designation of
producer's name which is then followed by a media type or
designation (e.g., vnd.bigcompany.funnypictures).
While public exposure and review of media types to be registered
the vendor tree is not required, using the ietf-types list for
is strongly encouraged to improve the quality of
specifications. Registrations in the vendor tree may be
directly to the IANA
2.1.3. Personal or Vanity
Registrations for media types created experimentally or as part
products that are not distributed commercially may be registered
the personal or vanity tree. The registrations are distinguished
the leading facet "prs.".
The owner of "personal" registrations and associated
is the person or entity making the registration, or one to
responsibility has been transferred as described below
While public exposure and review of media types to be registered
the personal tree is not required, using the ietf-types list
review is strongly encouraged to improve the quality of
specifications. Registrations in the personl tree may be
directly to the IANA
2.1.4. Special `x.'
For convenience and symmetry with this registration scheme,
type names with "x." as the first facet may be used for the
purposes for which names starting in "x-" are normally used.
types are unregistered, experimental, and should be used only
the active agreement of the parties exchanging them
Freed, et. al. Best Current Practice [Page 5]
RFC 2048 MIME Registration Procedures November 1996
However, with the simplified registration procedures described
for vendor and personal trees, it should rarely, if ever,
necessary to use unregistered experimental types, and as such use
both "x-" and "x." forms is discouraged
2.1.5. Additional Registration
From time to time and as required by the community, the IANA may
with the advice and consent of the IESG, create new top-
registration trees. It is explicitly assumed that these trees may
created for external registration and management by well-
permanent bodies, such as scientific societies for media
specific to the sciences they cover. In general, the quality
review of specifications for one of these additional
trees is expected to be equivalent to that which IETF would give
registrations in its own tree. Establishment of these new trees
be announced through RFC publication approved by the IESG
2.2. Registration
Media type registration proposals are all expected to conform
various requirements laid out in the following sections. Note
requirement specifics sometimes vary depending on the
tree, again as detailed in the following sections
2.2.1. Functionality
Media types must function as an actual media format: Registration
things that are better thought of as a transfer encoding, as
character set, or as a collection of separate entities of
type, is not allowed. For example, although applications exist
decode the base64 transfer encoding [RFC 2045], base64 cannot
registered as a media type
This requirement applies regardless of the registration
involved
2.2.2. Naming
All registered media types must be assigned MIME type and
names. The combination of these names then serves to
identify the media type and the format of the subtype name
the registration tree
The choice of top-level type name must take the nature of media
involved into account. For example, media normally used
representing still images should be a subtype of the image
type, whereas media capable of representing audio information
Freed, et. al. Best Current Practice [Page 6]
RFC 2048 MIME Registration Procedures November 1996
under the audio content type. See RFC 2046 for additional
on the basic set of top-level types and their characteristics
New subtypes of top-level types must conform to the restrictions
the top-level type, if any. For example, all subtypes of
multipart content type must use the same encapsulation syntax
In some cases a new media type may not "fit" under any
defined top-level content type. Such cases are expected to be
rare. However, if such a case arises a new top-level type can
defined to accommodate it. Such a definition must be done
standards-track RFC; no other mechanism can be used to
additional top-level content types
These requirements apply regardless of the registration
involved
2.2.3. Parameter
Media types may elect to use one or more MIME content
parameters, or some parameters may be automatically made available
the media type by virtue of being a subtype of a content type
defines a set of parameters applicable to any of its subtypes.
either case, the names, values, and meanings of any parameters
be fully specified when a media type is registered in the IETF tree
and should be specified as completely as possible when media
are registered in the vendor or personal trees
New parameters must not be defined as a way to introduce
functionality in types registered in the IETF tree, although
parameters may be added to convey additional information that
not otherwise change existing functionality. An example of
would be a "revision" parameter to indicate a revision level of
external specification such as JPEG. Similar behavior is
for media types registered in the vendor or personal trees but is
required
2.2.4. Canonicalization and Format
All registered media types must employ a single, canonical
format, regardless of registration tree
A precise and openly available specification of the format of
media type is required for all types registered in the IETF tree
must at a minimum be referenced by, if it isn't actually included in
the media type registration proposal itself
Freed, et. al. Best Current Practice [Page 7]
RFC 2048 MIME Registration Procedures November 1996
The specifications of format and processing particulars may or
not be publically available for media types registered in the
tree, and such registration proposals are explicitly permitted
include only a specification of which software and version produce
process such media types. References to or inclusion of
specifications in registration proposals is encouraged but
required
Format specifications are still required for registration in
personal tree, but may be either published as RFCs or
deposited with IANA. The deposited specifications will meet the
criteria as those required to register a well-known TCP port and,
particular, need not be made public
Some media types involve the use of patented technology.
registration of media types involving patented technology
specifically permitted. However, the restrictions set forth in
1602 on the use of patented technology in standards-track
must be respected when the specification of a media type is part of
standards-track protocol
2.2.5. Interchange
Media types should, whenever possible, interoperate across as
systems and applications as possible. However, some media types
inevitably have problems interoperating across different platforms
Problems with different versions, byte ordering, and specifics
gateway handling can and will arise
Universal interoperability of media types is not required, but
interoperability issues should be identified whenever possible
Publication of a media type does not require an exhaustive review
interoperability, and the interoperability considerations section
subject to continuing evaluation
These recommendations apply regardless of the registration
involved
2.2.6. Security
An analysis of security issues is required for for all
registered in the IETF Tree. (This is in accordance with the
requirements for all IETF protocols.) A similar analysis for
types registered in the vendor or personal trees is encouraged
not required. However, regardless of what security analysis has
has not been done, all descriptions of security issues must be
accurate as possible regardless of registration tree. In particular
a statement that there are "no security issues associated with
Freed, et. al. Best Current Practice [Page 8]
RFC 2048 MIME Registration Procedures November 1996
type" must not be confused with "the security issues associates
this type have not been assessed".
There is absolutely no requirement that media types registered in
tree be secure or completely free from risks. Nevertheless,
known security risks must be identified in the registration of
media type, again regardless of registration tree
The security considerations section of all registrations is
to continuing evaluation and modification, and in particular may
extended by use of the "comments on media types" mechanism
in subsequent sections
Some of the issues that should be looked at in a security analysis
a media type are
(1) Complex media types may include provisions
directives that institute actions on a recipient'
files or other resources. In many cases provision
made for originators to specify arbitrary actions in
unrestricted fashion which may then have
effects. See the registration of
application/postscript media type in RFC 2046
an example of such directives and how to handle them
(2) Complex media types may include provisions
directives that institute actions which, while
directly harmful to the recipient, may result
disclosure of information that either facilitates
subsequent attack or else violates a recipient'
privacy in some way. Again, the registration of
application/postscript media type illustrates how
directives can be handled
(3) A media type might be targeted for applications
require some sort of security assurance but not
the necessary security mechanisms themselves.
example, a media type could be defined for storage
confidential medical information which in turn
an external confidentiality service
2.2.7. Usage and Implementation Non-
In the asynchronous mail environment, where information on
capabilities of the remote mail agent is frequently not available
the sender, maximum interoperability is attained by restricting
number of media types used to those "common" formats expected to
widely implemented. This was asserted in the past as a reason
Freed, et. al. Best Current Practice [Page 9]
RFC 2048 MIME Registration Procedures November 1996
limit the number of possible media types and resulted in
registration process with a significant hurdle and delay for
registering media types
However, the need for "common" media types does not require
the registration of new media types. If a limited set of media
is recommended for a particular application, that should be
by a separate applicability statement specific for the
and/or environment
As such, universal support and implementation of a media type is
a requirement for registration. If, however, a media type
explicitly intended for limited use, this should be noted in
registration
2.2.8. Publication
Proposals for media types registered in the IETF tree must
published as RFCs. RFC publication of vendor and personal media
proposals is encouraged but not required. In all cases IANA
retain copies of all media type proposals and "publish" them as
of the media types registration tree itself
Other than in the IETF tree, the registration of a data type does
imply endorsement, approval, or recommendation by IANA or IETF
even certification that the specification is adequate. To
Internet Standards, protocol, data objects, or whatever must
through the IETF standards process. This is too difficult and
lengthy a process for the convenient registration of media types
The IETF tree exists for media types that do require require
substantive review and approval process with the vendor and
trees exist for those that do not. It is expected that
statements for particular applications will be published from time
time that recommend implementation of, and support for, media
that have proven particularly useful in those contexts
As discussed above, registration of a top-level type
standards-track processing and, hence, RFC publication
2.2.9. Additional
Various sorts of optional information may be included in
specification of a media type if it is available
(1) Magic number(s) (length, octet values). Magic
are byte sequences that are always present and thus
be used to identify entities as being of a given
Freed, et. al. Best Current Practice [Page 10]
RFC 2048 MIME Registration Procedures November 1996
type
(2) File extension(s) commonly used on one or
platforms to indicate that some file containing a
type of media
(3) Macintosh File Type code(s) (4 octets) used to
files containing a given type of media
Such information is often quite useful to implementors and
available should be provided
2.3. Registration
The following procedure has been implemented by the IANA for
and approval of new media types. This is not a formal
process, but rather an administrative procedure intended to
community comment and sanity checking without excessive time delay
For registration in the IETF tree, the normal IETF processes
be followed, treating posting of an internet-draft and
on the ietf-types list (as described in the next subsection) as
first step. For registrations in the vendor or personal tree,
initial review step described below may be omitted and the
registered directly by submitting the template and an
directly to IANA (at iana@iana.org). However, authors of vendor
personal media type specifications are encouraged to seek
review and comment whenever that is feasible
2.3.1. Present the Media Type to the Community for
Send a proposed media type registration to the "ietf-types@iana.org
mailing list for a two week review period. This mailing list
been established for the purpose of reviewing proposed media
access types. Proposed media types are not formally registered
must not be used; the "x-" prefix specified in RFC 2045 can be
until registration is complete
The intent of the public posting is to solicit comments and
on the choice of type/subtype name, the unambiguity of the
with respect to versions and external profiling information, and
review of any interoperability or security considerations.
submitter may submit a revised registration, or withdraw
registration completely, at any time
Freed, et. al. Best Current Practice [Page 11]
RFC 2048 MIME Registration Procedures November 1996
2.3.2. IESG
Media types registered in the IETF tree must be submitted to the
for approval
2.3.3. IANA
Provided that the media type meets the requirements for media
and has obtained approval that is necessary, the author may
the registration request to the IANA, which will register the
type and make the media type registration available to the community
2.4. Comments on Media Type
Comments on registered media types may be submitted by members of
community to IANA. These comments will be passed on to the "owner
of the media type if possible. Submitters of comments may
that their comment be attached to the media type registration itself
and if IANA approves of this the comment will be made accessible
conjunction with the type registration itself
2.5. Location of Registered Media Type
Media type registrations will be posted in the anonymous
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/"
and all registered media types will be listed in the
issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The
type description and other supporting material may also be
as an Informational RFC by sending it to "rfc-editor@isi.edu" (
follow the instructions to RFC authors [RFC-1543]).
2.6. IANA Procedures for Registering Media
The IANA will only register media types in the IETF tree in
to a communication from the IESG stating that a given
has been approved. Vendor and personal types will be registered
the IANA automatically and without any formal review as long as
following minimal conditions are met
(1) Media types must function as an actual media format
In particular, character sets and transfer
may not be registered as media types
(2) All media types must have properly formed type
subtype names. All type names must be defined by
standards-track RFC. All subtype names must be unique
must conform to the MIME grammar for such names,
must contain the proper tree prefix
Freed, et. al. Best Current Practice [Page 12]
RFC 2048 MIME Registration Procedures November 1996
(3) Types registered in the personal tree must
provide a format specification or a pointer to one
(4) Any security considerations given must not be
bogus. (It is neither possible nor necessary for
IANA to conduct a comprehensive security review
media type registrations. Nevertheless, IANA has
authority to identify obviously incompetent
and exclude it.)
2.7. Change
Once a media type has been published by IANA, the author may
a change to its definition. The descriptions of the
registration trees above designate the "owners" of each type
registration. The change request follows the same procedure as
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
errors in the published specification. When review is required,
change request may be denied if it renders entities that were
under the previous definition invalid under the new definition
The owner of a content type may pass responsibility for the
type to another person or agency by informing IANA and the ietf-
list; this can be done without discussion or review
The IESG may reassign responsibility for a media type. The
common case of this will be to enable changes to be made to
where the author of the registration has died, moved out of
or is otherwise unable to make changes that are important to
community
Media type registrations may not be deleted; media types which are
longer believed appropriate for use can be declared OBSOLETE by
change to their "intended use" field; such media types will
clearly marked in the lists published by IANA
Freed, et. al. Best Current Practice [Page 13]
RFC 2048 MIME Registration Procedures November 1996
2.8. Registration
To: ietf-types@iana.
Subject: Registration of MIME media type XXX/
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
(Any other information that the author deems interesting may
added below this line.)
3. External Body Access
RFC 2046 defines the message/external-body media type, whereby a
entity can act as pointer to the actual body data in lieu
including the data directly in the entity body.
message/external-body reference specifies an access type,
determines the mechanism used to retrieve the actual body data.
2046 defines an initial set of access types, but allows for
Freed, et. al. Best Current Practice [Page 14]
RFC 2048 MIME Registration Procedures November 1996
registration of additional access types to accommodate new
mechanisms
3.1. Registration
New access type specifications must conform to a number
requirements as described below
3.1.1. Naming
Each access type must have a unique name. This name appears in
access-type parameter in the message/external-body content-
header field, and must conform to MIME content type parameter syntax
3.1.2. Mechanism Specification
All of the protocols, transports, and procedures used by a
access type must be described, either in the specification of
access type itself or in some other publicly available specification
in sufficient detail for the access type to be implemented by
competent implementor. Use of secret and/or proprietary methods
access types are expressly prohibited. The restrictions imposed
RFC 1602 on the standardization of patented algorithms must
respected as well
3.1.3. Publication
All access types must be described by an RFC. The RFC may
informational rather than standards-track, although standard-
review and approval are encouraged for all access types
3.1.4. Security
Any known security issues that arise from the use of the access
must be completely and fully described. It is not required that
access type be secure or that it be free from risks, but that
known risks be identified. Publication of a new access type does
require an exhaustive security review, and the
considerations section is subject to continuing evaluation
Additional security considerations should be addressed by
revised versions of the access type specification
3.2. Registration
Registration of a new access type starts with the construction of
draft of an RFC
Freed, et. al. Best Current Practice [Page 15]
RFC 2048 MIME Registration Procedures November 1996
3.2.1. Present the Access Type to the
Send a proposed access type specification to the "ietf
types@iana.org" mailing list for a two week review period.
mailing list has been established for the purpose of
proposed access and media types. Proposed access types are
formally registered and must not be used
The intent of the public posting is to solicit comments and
on the access type specification and a review of any
considerations
3.2.2. Access Type
When the two week period has passed, the access type reviewer, who
appointed by the IETF Applications Area Director, either forwards
request to iana@isi.edu, or rejects it because of
objections raised on the list
Decisions made by the reviewer must be posted to the ietf-
mailing list within 14 days. Decisions made by the reviewer may
appealed to the IESG
3.2.3. IANA
Provided that the access type has either passed review or has
successfully appealed to the IESG, the IANA will register the
type and make the registration available to the community.
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]).
3.3. Location of Registered Access Type
Access type registrations will be posted in the anonymous
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/"
and all registered access types will be listed in the
issued "Assigned Numbers" RFC [currently RFC-1700].
3.4. IANA Procedures for Registering Access
The identity of the access type reviewer is communicated to the
by the IESG. The IANA then only acts in response to access
definitions that either are approved by the access type reviewer
forwarded by the reviewer to the IANA for registration, or
response to a communication from the IESG that an access
definition appeal has overturned the access type reviewer's ruling
Freed, et. al. Best Current Practice [Page 16]
RFC 2048 MIME Registration Procedures November 1996
4. Transfer
Transfer encodings are tranformations applied to MIME media
after conversion to the media type's canonical form.
encodings are used for several purposes
(1) Many transports, especially message transports,
only handle data consisting of relatively short
of text. There can also be severe restrictions on
characters can be used in these lines of text --
transports are restricted to a small subset of US-
and others cannot handle certain character sequences
Transfer encodings are used to transform binary
into textual form that can survive such transports
Examples of this sort of transfer encoding include
base64 and quoted-printable transfer encodings
in RFC 2045.
(2) Image, audio, video, and even application entities
sometimes quite large. Compression algorithms are
quite effective in reducing the size of large entities
Transfer encodings can be used to apply general-
non-lossy compression algorithms to MIME entities
(3) Transport encodings can be defined as a means
representing existing encoding formats in a
context
IMPORTANT: The standardization of a large numbers of
transfer encodings is seen as a significant barrier to
interoperability and is expressely discouraged. Nevertheless,
following procedure has been defined to provide a means of
additional transfer encodings, should standardization actually
justified
4.1. Transfer Encoding
Transfer encoding specifications must conform to a number
requirements as described below
4.1.1. Naming
Each transfer encoding must have a unique name. This name appears
the Content-Transfer-Encoding header field and must conform to
syntax of that field
Freed, et. al. Best Current Practice [Page 17]
RFC 2048 MIME Registration Procedures November 1996
4.1.2. Algorithm Specification
All of the algorithms used in a transfer encoding (e.g.
to printable form, compression) must be described in their
in the transfer encoding specification. Use of secret and/
proprietary algorithms in standardized transfer encodings
expressly prohibited. The restrictions imposed by RFC 1602 on
standardization of patented algorithms must be respected as well
4.1.3. Input Domain
All transfer encodings must be applicable to an arbitrary sequence
octets of any length. Dependence on particular input forms is
allowed
It should be noted that the 7bit and 8bit encodings do not conform
this requirement. Aside from the undesireability of
specialized encodings, the intent here is to forbid the addition
additional encodings along the lines of 7bit and 8bit
4.1.4. Output Range
There is no requirement that a particular tranfer encoding produce
particular form of encoded output. However, the output format
each transfer encoding must be fully and completely documented.
particular, each specification must clearly state whether the
format always lies within the confines of 7bit data, 8bit data, or
simply pure binary data
4.1.5. Data Integrity and Generality
All transfer encodings must be fully invertible on any platform;
must be possible for anyone to recover the original data
performing the corresponding decoding operation. Note that
requirement effectively excludes all forms of lossy compression
well as all forms of encryption from use as a transfer encoding
4.1.6. New Functionality
All transfer encodings must provide some sort of new functionality
Some degree of functionality overlap with previously defined
encodings is acceptable, but any new transfer encoding must
offer something no other transfer encoding provides
Freed, et. al. Best Current Practice [Page 18]
RFC 2048 MIME Registration Procedures November 1996
4.2. Transfer Encoding Definition
Definition of a new transfer encoding starts with the construction
a draft of a standards-track RFC. The RFC must define the
encoding precisely and completely, and must also provide
justification for defining and standardizing a new transfer encoding
This specification must then be presented to the IESG
consideration. The IESG
(1) reject the specification outright as
inappropriate for standardization
(2) approve the formation of an IETF working group to
on the specification in accordance with
procedures, or
(3) accept the specification as-is and put it directly
the standards track
Transfer encoding specifications on the standards track follow
IETF rules for standards track documents. A transfer encoding
considered to be defined and available for use once it is on
standards track
4.3. IANA Procedures for Transfer Encoding
There is no need for a special procedure for registering
Encodings with the IANA. All legitimate transfer
registrations must appear as a standards-track RFC, so it is
IESG's responsibility to notify the IANA when a new transfer
has been approved
4.4. Location of Registered Transfer Encodings
Transfer encoding registrations will be posted in the anonymous
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer
encodings/" and all registered transfer encodings will be listed
the periodically issued "Assigned Numbers" RFC [currently RFC-1700].
Freed, et. al. Best Current Practice [Page 19]
RFC 2048 MIME Registration Procedures November 1996
5. Authors'
For more information, the authors of this document are
contacted via Internet mail
Ned
Innosoft International, Inc
1050 East Garvey Avenue
West Covina, CA 91790
Phone: +1 818 919 3600
Fax: +1 818 919 3614
EMail: ned@innosoft.
John
2100 Reston
Reston, VA 22091
Phone: +1 703 715-7361
Fax: +1 703 715-7436
EMail: klensin@mci.
Jon
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: +1 310 822 1511
Fax: +1 310 823 6714
EMail: Postel@ISI.
Freed, et. al. Best Current Practice [Page 20]
RFC 2048 MIME Registration Procedures November 1996
Appendix A -- Grandfathered Media
A number of media types, registered prior to 1996, would,
registered under the guidelines in this document, be placed
either the vendor or personal trees. Reregistration of those
to reflect the appropriate trees is encouraged, but not required
Ownership and change control principles outlined in this
apply to those types as if they had been registered in the
described above
Freed, et. al. Best Current Practice [Page 21]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
