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




 
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.






 
RFC 2048              MIME Registration Procedures         November 1996


   The specifications of format and processing particulars may or may
   not be publically available for media types registered in the vendor