rfc2048.txt

< VB高级网络编程技术>>随书源代码第2章,里面有很多有用的例程,希望对大家的开发工作有帮助!

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