rfc2048.txt

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

   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


   registration of additional access types to accommodate new retrieval
   mechanisms.

3.1.  Registration Requirements

   New access type specifications must conform to a number of
   requirements as described below.

3.1.1.  Naming Requirements

   Each access type must have a unique name.  This name appears in the
   access-type parameter in the message/external-body content-type
   header field, and must conform to MIME content type parameter syntax.

3.1.2.  Mechanism Specification Requirements

   All of the protocols, transports, and procedures used by a given
   access type must be described, either in the specification of the
   access type itself or in some other publicly available specification,
   in sufficient detail for the access type to be implemented by any
   competent implementor.  Use of secret and/or proprietary methods in
   access types are expressly prohibited. The restrictions imposed by
   RFC 1602 on the standardization of patented algorithms must be
   respected as well.

3.1.3.  Publication Requirements

   All access types must be described by an RFC. The RFC may be
   informational rather than standards-track, although standard-track
   review and approval are encouraged for all access types.

3.1.4.  Security Requirements

   Any known security issues that arise from the use of the access type
   must be completely and fully described. It is not required that the
   access type be secure or that it be free from risks, but that the
   known risks be identified.  Publication of a new access type does not
   require an exhaustive security review, and the security
   considerations section is subject to continuing evaluation.
   Additional security considerations should be addressed by publishing
   revised versions of the access type specification.

3.2.  Registration Procedure

   Registration of a new access type starts with the construction of a
   draft of an RFC.





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


3.2.1.  Present the Access Type to the Community

   Send a proposed access type specification to the "ietf-
   [e-mail]" mailing list for a two week review period.  This
   mailing list has been established for the purpose of reviewing
   proposed access and media types.  Proposed access types are not
   formally registered and must not be used.

   The intent of the public posting is to solicit comments and feedback
   on the access type specification and a review of any security
   considerations.

3.2.2.  Access Type Reviewer

   When the two week period has passed, the access type reviewer, who is
   appointed by the IETF Applications Area Director, either forwards the
   request to [e-mail], or rejects it because of significant
   objections raised on the list.

   Decisions made by the reviewer must be posted to the ietf-types
   mailing list within 14 days. Decisions made by the reviewer may be
   appealed to the IESG.

3.2.3.  IANA Registration

   Provided that the access type has either passed review or has been
   successfully appealed to the IESG, the IANA will register the access
   type and make the registration available to the community. The
   specification of the access type must also be published as an RFC.
   Informational RFCs are published by sending them to "rfc-
   [e-mail]" (please follow the instructions to RFC authors [RFC-
   1543]).

3.3.  Location of Registered Access Type List

   Access type registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/"
   and all registered access types will be listed in the periodically
   issued "Assigned Numbers" RFC [currently RFC-1700].

3.4.  IANA Procedures for Registering Access Types