rfc2048.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,181 行 · 第 1/3 页

Network Working Group                                           N. Freed
Request for Comments: 2048                                      Innosoft
BCP: 13                                                       J. Klensin
Obsoletes: 1521, 1522, 1590                                          MCI
Category: Best Current Practice                                J. Postel
                                                                     ISI
                                                           November 1996


                 Multipurpose Internet Mail Extensions
                           (MIME) Part Four:
                        Registration Procedures

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

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

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









Freed, et. al.           Best Current Practice                  [Page 1]

RFC 2048              MIME Registration Procedures         November 1996


   This fourth document, RFC 2048, 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 2049
   describes differences and changes from previous versions.

Table of Contents

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

   Recent Internet protocols have been carefully designed to be easily
   extensible in certain areas.  In particular, MIME [RFC 2045] 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.





Freed, et. al.           Best Current Practice                  [Page 3]

RFC 2048              MIME Registration Procedures         November 1996


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

2.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 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 document do not conform
   to the naming conventions described below.  See Appendix A for a
   discussion of them.

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

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





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

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

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







Freed, et. al.           Best Current Practice                  [Page 5]

RFC 2048              MIME Registration Procedures         November 1996


   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.

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

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

2.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 [RFC 2045], base64 cannot be
   registered as a media type.

   This requirement applies regardless of the registration tree
   involved.

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

   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



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

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

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





Freed, et. al.           Best Current Practice                  [Page 7]