RFC2048: (MIME) Part Four: Registration Procedures¶

Obsoleted by: rfc4288, rfc4289
Obsoletes: rfc1521, rfc1522, rfc1590
Updated by: rfc3023
Category: Standards Track
November 1996

1. Introduction¶

本文档定义了一种注册过程，使用Internet分配号码机构(IANA)作为这些值的中央注册表。

备注

对于普通公司/开发者，一般情况用不到。

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.

2.1. Registration Trees and Subtype Names¶

在MIME媒体类型注册中，注册树和子类型名称非常重要。
注册树指定了媒体类型的类别，并且在IANA（Internet Assigned Numbers Authority）维护的注册表中进行组织和管理。

注册树分别是:

1. IETF tree（标准树）
        Registration in the IETF tree requires approval by the IESG
                and publication of the media type registration as some form of RFC.
2. Vendor tree（厂商树）
        The vendor tree is used for media types associated with commercially available products.
        leading facet "vnd.":
                例:「vnd.mudpie」
                例: 「vnd.bigcompany.funnypictures」
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.".
4. Special `x.' Tree(特殊“x.”树)
5. Additional Registration Trees(其他注册树)

2.2 Registration Requirements¶

1. Functionality Requirement:
        Each header field must have a well-defined functionality and semantics.
2. Naming Requirements:
        Header field names must be composed of printable ASCII characters, and they must not contain any whitespace characters.
3. Parameter Requirements:
        Header fields that accept parameters must specify the syntax of the parameter values.
4. Canonicalization and Format Requirements:
        Header fields must follow a specific format and be in a canonical form to ensure interoperability.
5. Interchange Recommendations:
        Header fields should be formatted and ordered in a specific way to enable easy parsing by recipient systems.
6. Security Requirements:
        Header fields must not contain any security vulnerabilities or enable malicious activities.
7. Usage and Implementation Non-requirements:
        The registration process does not specify how the header fields should be used or implemented.
8. Publication Requirements:
        All registered header fields must be publicly available.
9. Additional Information:
        The registration process may require additional information to be provided, such as
                the intended use of the header field or any relevant standards.

2.3 Registration Procedure¶

介绍了IANA的媒体类型注册程序，其目的是允许社区评论和检查而不会过多地延迟时间。该过程包括以下步骤:

向"ietf-types@iana.org"邮件列表发送提议的媒体类型注册以进行两周的审查期。
IESG审批，对于在IETF树中注册的媒体类型必须提交给IESG进行批准。
IANA注册，媒体类型注册经过审批后，作者可以将注册请求提交给IANA，该机构将注册该媒体类型并使其对社区可用。

2.4 Comments on Media Type Registrations¶

Comments on registered media types may be submitted by members of the community to IANA.

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

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 minimal conditions are met.

2.7. Change Control¶

Once a media type has been published by IANA, the author may request a change to its definition.

2.8 Registration Template¶

注册模板

3. External Body Access Types¶

External body access types are used to refer to data that is stored outside of the message, such as in a separate file or on a remote server.
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.

4. Transfer Encodings¶

Transfer encodings are used to transform MIME media types after conversion to the media type’s canonical form for several purposes.
These include transforming binary data into textual form that can survive message transports, applying general-purpose non-lossy compression algorithms to MIME entities, and representing existing encoding formats in a MIME context.
Transfer encoding specifications must conform to several requirements, including having a unique name conforming to the syntax of the Content-Transfer-Encoding header field, describing all the algorithms used in a transfer encoding in their entirety, being applicable to an arbitrary sequence of octets of any length, fully documenting the output format for each transfer encoding, being fully invertible on any platform, and providing some sort of new functionality.
Transfer encoding registrations will be posted in the anonymous FTP directory “ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-encodings/” and all registered transfer encodings will be listed in the periodically issued “Assigned Numbers” RFC [currently RFC-170].