tree, and such registration proposals are explicitly permitted to
   include only a specification of which software and version produce or
   process such media types.  References to or inclusion of format
   specifications in registration proposals is encouraged but not
   required.

   Format specifications are still required for registration in the
   personal tree, but may be either published as RFCs or otherwise
   deposited with IANA. The deposited specifications will meet the same
   criteria as those required to register a well-known TCP port and, in
   particular, need not be made public.

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

2.2.5.  Interchange Recommendations

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

   Universal interoperability of media types is not required, but known
   interoperability issues should be identified whenever possible.
   Publication of a media type does not require an exhaustive review of
   interoperability, and the interoperability considerations section is
   subject to continuing evaluation.

   These recommendations apply regardless of the registration tree
   involved.

2.2.6.  Security Requirements

   An analysis of security issues is required for for all types
   registered in the IETF Tree.  (This is in accordance with the basic
   requirements for all IETF protocols.) A similar analysis for media
   types registered in the vendor or personal trees is encouraged but
   not required.  However, regardless of what security analysis has or
   has not been done, all descriptions of security issues must be as
   accurate as possible regardless of registration tree.  In particular,
   a statement that there are "no security issues associated with this




 
RFC 2048              MIME Registration Procedures         November 1996


   type" must not be confused with "the security issues associates with
   this type have not been assessed".

   There is absolutely no requirement that media types registered in any
   tree be secure or completely free from risks.  Nevertheless, all
   known security risks must be identified in the registration of a
   media type, again regardless of registration tree.

   The security considerations section of all registrations is subject
   to continuing evaluation and modification, and in particular may be
   extended by use of the "comments on media types" mechanism described
   in subsequent sections.

   Some of the issues that should be looked at in a security analysis of
   a media type are:

    (1)   Complex media types may include provisions for
          directives that institute actions on a recipient's
          files or other resources.  In many cases provision is
          made for originators to specify arbitrary actions in an
          unrestricted fashion which may then have devastating
          effects.  See the registration of the
          application/postscript media type in RFC 2046 for
          an example of such directives and how to handle them.

    (2)   Complex media types may include provisions for
          directives that institute actions which, while not
          directly harmful to the recipient, may result in
          disclosure of information that either facilitates a
          subsequent attack or else violates a recipient's
          privacy in some way.  Again, the registration of the
          application/postscript media type illustrates how such
          directives can be handled.

    (3)   A media type might be targeted for applications that
          require some sort of security assurance but not provide
          the necessary security mechanisms themselves. For
          example, a media type could be defined for storage of
          confidential medical information which in turn requires
          an external confidentiality service.

2.2.7.  Usage and Implementation Non-requirements

   In the asynchronous mail environment, where information on the
   capabilities of the remote mail agent is frequently not available to
   the sender, maximum interoperability is attained by restricting the