rfc2048.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,181 行 · 第 1/3 页

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



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 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
   number of media types used to those "common" formats expected to be
   widely implemented.  This was asserted in the past as a reason to



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 a
   registration process with a significant hurdle and delay for those
   registering media types.

   However, the need for "common" media types does not require limiting
   the registration of new media types. If a limited set of media types
   is recommended for a particular application, that should be asserted
   by a separate applicability statement specific for the application
   and/or environment.

   As such, universal support and implementation of a media type is NOT
   a requirement for registration.  If, however, a media type is
   explicitly intended for limited use, this should be noted in its
   registration.

2.2.8.  Publication Requirements

   Proposals for media types registered in the IETF tree must be
   published as RFCs. RFC publication of vendor and personal media type
   proposals is encouraged but not required. In all cases IANA will
   retain copies of all media type proposals and "publish" them as part
   of the media types registration tree itself.

   Other than in the IETF tree, the registration of a data type does not
   imply endorsement, approval, or recommendation by IANA or IETF or
   even certification that the specification is adequate.  To become
   Internet Standards, protocol, data objects, or whatever must go
   through the IETF standards process.  This is too difficult and too
   lengthy a process for the convenient registration of media types.

   The IETF tree exists for media types that do require require a
   substantive review and approval process with the vendor and personal
   trees exist for those that do not. It is expected that applicability
   statements for particular applications will be published from time to
   time that recommend implementation of, and support for, media types
   that have proven particularly useful in those contexts.

   As discussed above, registration of a top-level type requires
   standards-track processing and, hence, RFC publication.

2.2.9.  Additional Information

   Various sorts of optional information may be included in the
   specification of a media type if it is available:

    (1)   Magic number(s) (length, octet values). Magic numbers
          are byte sequences that are always present and thus can
          be used to identify entities as being of a given media



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 more
          platforms to indicate that some file containing a given
          type of media.

    (3)   Macintosh File Type code(s) (4 octets) used to label
          files containing a given type of media.

   Such information is often quite useful to implementors and if
   available should be provided.

2.3.  Registration Procedure

   The following procedure has been implemented by the IANA for review
   and approval of new media types.  This is not a formal standards
   process, but rather an administrative procedure intended to allow
   community comment and sanity checking without excessive time delay.
   For registration in the IETF tree, the normal IETF processes should
   be followed, treating posting of an internet-draft and announcement
   on the ietf-types list (as described in the next subsection) as a
   first step.  For registrations in the vendor or personal tree, the
   initial review step described below may be omitted and the type
   registered directly by submitting the template and an explanation
   directly to IANA (at [e-mail]).  However, authors of vendor or
   personal media type specifications are encouraged to seek community
   review and comment whenever that is feasible.

2.3.1.  Present the Media Type to the Community for Review

   Send a proposed media type registration to the "[e-mail]"
   mailing list for a two week review period.  This mailing list has
   been established for the purpose of reviewing proposed media and
   access types. Proposed media types are not formally registered and
   must not be used; the "x-" prefix specified in RFC 2045 can be used
   until registration is complete.

   The intent of the public posting is to solicit comments and feedback
   on the choice of type/subtype name, the unambiguity of the references
   with respect to versions and external profiling information, and a
   review of any interoperability or security considerations. The
   submitter may submit a revised registration, or withdraw the
   registration completely, at any time.








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


2.3.2.  IESG Approval

   Media types registered in the IETF tree must be submitted to the IESG
   for approval.

2.3.3.  IANA Registration

   Provided that the media type meets the requirements for media types
   and has obtained approval that is necessary, the author may submit
   the registration request to the IANA, which will register the media
   type and make the media type registration available to the community.

2.4.  Comments on Media Type Registrations

   Comments on registered media types may be submitted by members of the
   community to IANA.  These comments will be passed on to the "owner"
   of the media type if possible.  Submitters of comments may request
   that their comment be attached to the media type registration itself,
   and if IANA approves of this the comment will be made accessible in
   conjunction with the type registration itself.

2.5.  Location of Registered Media Type List

   Media type registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/"
   and all registered media types will be listed in the periodically
   issued "Assigned Numbers" RFC [currently STD 2, RFC 1700].  The media
   type description and other supporting material may also be published
   as an Informational RFC by sending it to "[e-mail]" (please
   follow the instructions to RFC authors [RFC-1543]).

2.6.  IANA Procedures for Registering Media Types

   The IANA will only register media types in the IETF tree in response
   to a communication from the IESG stating that a given registration
   has been approved. Vendor and personal types will be registered by
   the IANA automatically and without any formal review as long as the
   following minimal conditions are met:

    (1)   Media types must function as an actual media format.
          In particular, character sets and transfer encodings
          may not be registered as media types.

    (2)   All media types must have properly formed type and
          subtype names. All type names must be defined by a
          standards-track RFC. All subtype names must be unique,
          must conform to the MIME grammar for such names, and
          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 either
          provide a format specification or a pointer to one.

    (4)   Any security considerations given must not be obviously
          bogus. (It is neither possible nor necessary for the
          IANA to conduct a comprehensive security review of
          media type registrations.  Nevertheless, IANA has the
          authority to identify obviously incompetent material
          and exclude it.)

2.7.  Change Control

   Once a media type has been published by IANA, the author may request
   a change to its definition. The descriptions of the different
   registration trees above designate the "owners" of each type of
   registration. The change request follows the same procedure as the
   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 or
   errors in the published specification. When review is required, a
   change request may be denied if it renders entities that were valid
   under the previous definition invalid under the new definition.

   The owner of a content type may pass responsibility for the content
   type to another person or agency by informing IANA and the ietf-types
   list; this can be done without discussion or review.

   The IESG may reassign responsibility for a media type. The most
   common case of this will be to enable changes to be made to types
   where the author of the registration has died, moved out of contact
   or is otherwise unable to make changes that are important to the
   community.

   Media type registrations may not be deleted; media types which are no
   longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such media types will be
   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 Template

     To: [e-mail]
     Subject: Registration of MIME media type XXX/YYY

     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 be
     added below this line.)

3.  External Body Access Types

   RFC 2046 defines the message/external-body media type, whereby a MIME
   entity can act as pointer to the actual body data in lieu of
   including the data directly in the entity body. Each
   message/external-body reference specifies an access type, which
   determines the mechanism used to retrieve the actual body data. RFC
   2046 defines an initial set of access types, but allows for the



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