Network Working Group N. Freed
Request for Comments: 4288 Sun Microsystems
BCP: 13 J. Klensin
Obsoletes: 2048 December 2005
Category: Best Current Practice
Network Working Group N. Freed
Request for Comments: 4288 Sun Microsystems
BCP: 13 J. Klensin
Obsoletes: 2048 December 2005
Category: Best Current Practice
Media Type Specifications and Registration Procedures
媒体类型规格和注册程序
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols.
本文档定义了用于MIME和其他Internet协议的媒体类型的规范和注册过程。
Table of Contents
目录
1. Introduction ....................................................3
2. Media Type Registration Preliminaries ...........................4
3. Registration Trees and Subtype Names ............................4
3.1. Standards Tree .............................................4
3.2. Vendor Tree ................................................5
3.3. Personal or Vanity Tree ....................................5
3.4. Special x. Tree ............................................5
3.5. Additional Registration Trees ..............................6
4. Registration Requirements .......................................6
4.1. Functionality Requirement ..................................6
4.2. Naming Requirements ........................................6
4.2.1. Text Media Types ......................................7
4.2.2. Image Media Types .....................................8
4.2.3. Audio Media Types .....................................8
4.2.4. Video Media Types .....................................8
4.2.5. Application Media Types ...............................9
4.2.6. Multipart and Message Media Types .....................9
4.2.7. Additional Top-level Types ............................9
4.3. Parameter Requirements ....................................10
4.4. Canonicalization and Format Requirements ..................10
4.5. Interchange Recommendations ...............................11
4.6. Security Requirements .....................................11
4.7. Requirements specific to XML media types ..................13
4.8. Encoding Requirements .....................................13
4.9. Usage and Implementation Non-requirements .................13
4.10. Publication Requirements .................................14
4.11. Additional Information ...................................15
5. Registration Procedure .........................................15
5.1. Preliminary Community Review ..............................16
5.2. IESG Approval .............................................16
5.3. IANA Registration .........................................16
5.4. Media Types Reviewer ......................................16
6. Comments on Media Type Registrations ...........................17
7. Location of Registered Media Type List .........................17
8. IANA Procedures for Registering Media Types ....................17
9. Change Procedures ..............................................18
10. Registration Template .........................................19
11. Security Considerations .......................................20
12. IANA Considerations ...........................................20
13. Acknowledgements ..............................................20
14. References ....................................................20
Appendix A. Grandfathered Media Types ............................22
Appendix B. Changes Since RFC 2048 ...............................22
1. Introduction ....................................................3
2. Media Type Registration Preliminaries ...........................4
3. Registration Trees and Subtype Names ............................4
3.1. Standards Tree .............................................4
3.2. Vendor Tree ................................................5
3.3. Personal or Vanity Tree ....................................5
3.4. Special x. Tree ............................................5
3.5. Additional Registration Trees ..............................6
4. Registration Requirements .......................................6
4.1. Functionality Requirement ..................................6
4.2. Naming Requirements ........................................6
4.2.1. Text Media Types ......................................7
4.2.2. Image Media Types .....................................8
4.2.3. Audio Media Types .....................................8
4.2.4. Video Media Types .....................................8
4.2.5. Application Media Types ...............................9
4.2.6. Multipart and Message Media Types .....................9
4.2.7. Additional Top-level Types ............................9
4.3. Parameter Requirements ....................................10
4.4. Canonicalization and Format Requirements ..................10
4.5. Interchange Recommendations ...............................11
4.6. Security Requirements .....................................11
4.7. Requirements specific to XML media types ..................13
4.8. Encoding Requirements .....................................13
4.9. Usage and Implementation Non-requirements .................13
4.10. Publication Requirements .................................14
4.11. Additional Information ...................................15
5. Registration Procedure .........................................15
5.1. Preliminary Community Review ..............................16
5.2. IESG Approval .............................................16
5.3. IANA Registration .........................................16
5.4. Media Types Reviewer ......................................16
6. Comments on Media Type Registrations ...........................17
7. Location of Registered Media Type List .........................17
8. IANA Procedures for Registering Media Types ....................17
9. Change Procedures ..............................................18
10. Registration Template .........................................19
11. Security Considerations .......................................20
12. IANA Considerations ...........................................20
13. Acknowledgements ..............................................20
14. References ....................................................20
Appendix A. Grandfathered Media Types ............................22
Appendix B. Changes Since RFC 2048 ...............................22
Recent Internet protocols have been carefully designed to be easily extensible in certain areas. In particular, many protocols, including but not limited to MIME [RFC2045], are capable of carrying arbitrary labeled content. A mechanism is needed to label such content and a registration process is needed for these labels, to ensure that the set of such values is developed in an orderly, well-specified, and public manner.
最近的互联网协议经过精心设计，在某些领域易于扩展。特别是，许多协议，包括但不限于MIME[RFC2045]，能够承载任意标记的内容。需要一种机制来标记这些内容，需要对这些标签进行注册，以确保以有序、明确和公开的方式开发这些值集。
This document defines media type specification and registration procedures that use the Internet Assigned Numbers Authority (IANA) as a central registry.
本文档定义了使用Internet分配号码管理局（IANA）作为中央注册表的媒体类型规范和注册程序。
Historical Note
历史笔记
The media type registration process was initially defined for registering media types for use in the context of the asynchronous Internet mail environment. In this mail environment there is a need to limit the number of possible media types, to increase the likelihood of interoperability when the capabilities of the remote mail system are not known. As media types are used in new environments in which the proliferation of media types is not a hindrance to interoperability, the original procedure proved excessively restrictive and had to be generalized. This was initially done in [RFC2048], but the procedure defined there was still part of the MIME document set. The media type specification and registration procedure has now been moved to this separate document, to make it clear that it is independent of MIME.
媒体类型注册过程最初定义为注册在异步Internet邮件环境中使用的媒体类型。在这种邮件环境中，需要限制可能的媒体类型的数量，以便在远程邮件系统的功能未知时增加互操作性的可能性。由于媒体类型在新环境中使用，在新环境中，媒体类型的扩散不会妨碍互操作性，因此，原来的过程被证明限制过多，必须加以推广。这最初是在[RFC2048]中完成的，但是在那里定义的过程仍然是MIME文档集的一部分。媒体类型规范和注册过程现在已经转移到这个单独的文档中，以明确它独立于MIME。
It may be desirable to restrict the use of media types to specific environments or to prohibit their use in other environments. This revision attempts for the first time to incorporate such restrictions into media type registrations in a systematic way. See Section 4.9 for additional discussion.
可能需要将媒体类型的使用限制在特定环境中，或禁止在其他环境中使用。本次修订首次尝试以系统的方式将此类限制纳入媒体类型注册。更多讨论见第4.9节。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This specification makes use of the Augmented Backus-Naur Form (ABNF) [RFC4234] notation, including the core rules defined in Appendix A of that document.
本规范使用了扩展的巴科斯诺尔表（ABNF）[RFC4234]符号，包括该文件附录A中定义的核心规则。
Registration of a new media type or types starts with the construction of a registration proposal. Registration may occur within several different registration trees that have different requirements, as discussed below. In general, a new registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The media type is then registered if the proposal is acceptable. The following sections describe the requirements and procedures used for each of the different registration trees.
一种或多种新媒体类型的注册从构建注册提案开始。注册可能发生在具有不同要求的几个不同的注册树中，如下所述。一般来说，新的登记提案以适合所涉树木的方式分发和审查。如果建议可接受，则注册媒体类型。以下各节描述了用于每个不同注册树的要求和程序。
In order to increase the efficiency and flexibility of the registration process, different structures of subtype names may be registered to accommodate the different natural requirements for, e.g., a subtype that will be recommended for wide support and implementation by the Internet community, or a subtype that is used to move files associated with proprietary software. The following subsections define registration "trees" that are distinguished by the use of faceted names, e.g., names of the form "tree.subtree...subtype". Note that some media types defined prior to this document do not conform to the naming conventions described below. See Appendix A for a discussion of them.
为了提高注册过程的效率和灵活性，可以注册不同的子类型名称结构，以适应不同的自然要求，例如，互联网社区将推荐广泛支持和实施的子类型，或用于移动与专有软件关联的文件的子类型。以下小节定义了通过使用刻面名称来区分的注册“树”，例如“tree.subtree…subtype”形式的名称。请注意，本文档之前定义的某些媒体类型不符合下面描述的命名约定。关于它们的讨论，见附录A。
The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be approved by the IESG and MUST correspond to a formal publication by a recognized standards body. In the case of registration for the IETF itself, the registration proposal MUST be published as an RFC. Standards-tree registration RFCs can either be standalone "registration only" RFCs, or they can be incorporated into a more general specification of some sort.
标准树用于互联网社区普遍感兴趣的类型。标准树中的注册必须得到IESG的批准，并且必须符合公认标准机构的正式出版物。对于IETF本身的注册，注册提案必须作为RFC发布。标准树注册RFC可以是独立的“仅注册”RFC，也可以合并到某种更通用的规范中。
Media types in the standards tree are normally denoted by names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters.
标准树中的媒体类型通常由未显式刻面的名称表示，即不包含句点（“.”，句号）字符。
The "owner" of a media type registration in the standards tree is assumed to be the standards body itself. Modification or alteration of the specification requires the same level of processing (e.g., standards track) required for the initial registration.
标准树中媒体类型注册的“所有者”被假定为标准主体本身。规范的修改或变更需要与初始注册相同的处理水平（如标准跟踪）。
The vendor tree is used for media types associated with commercially available products. "Vendor" or "producer" are construed as equivalent and very broadly in this context.
供应商树用于与商用产品相关的介质类型。“供应商”或“生产商”在本上下文中被解释为等效且非常广泛。
A registration may be placed in the vendor tree by anyone who needs to interchange files associated with the particular product. However, the registration formally belongs to the vendor or organization producing the software or file format being registered. Changes to the specification will be made at their request, as discussed in subsequent sections.
需要交换与特定产品相关的文件的任何人都可以在供应商树中进行注册。但是，注册正式属于生产正在注册的软件或文件格式的供应商或组织。如后续章节所述，将根据其要求对规范进行更改。
Registrations in the vendor tree will be distinguished by the leading facet "vnd.". That may be followed, at the discretion of the registrant, by either a media subtype name from a well-known producer (e.g., "vnd.mudpie") or by an IANA-approved designation of the producer's name that is followed by a media type or product designation (e.g., vnd.bigcompany.funnypictures).
供应商树中的注册将通过前面的方面“vnd”来区分。由注册人自行决定，可由知名制作人提供媒体子类型名称（如“vnd.mudpie”），或由IANA批准的制作人名称命名，后跟媒体类型或产品名称（如vnd.bigcompany.funnypictures）。
While public exposure and review of media types to be registered in the vendor tree is not required, using the ietf-types@iana.org mailing list for review is strongly encouraged to improve the quality of those specifications. Registrations in the vendor tree may be submitted directly to the IANA.
虽然不需要公开披露和审查要在供应商树中注册的媒体类型，但使用ietf-types@iana.org强烈鼓励审查邮件列表，以提高这些规范的质量。供应商树中的注册可直接提交给IANA。
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.".
对于实验性创建的媒体类型或作为非商业发行产品的一部分创建的媒体类型的注册可以在个人或虚荣树中注册。注册以“prs”为主要方面进行区分。
The owner of "personal" registrations and associated specifications is the person or entity making the registration, or one to whom responsibility has been transferred as described below.
“个人”注册和相关规范的所有人是进行注册的个人或实体，或已按照下文所述将责任转移给的个人或实体。
While public exposure and review of media types to be registered in the personal tree is not required, using the ietf-types list for review is strongly encouraged to improve the quality of those specifications. Registrations in the personal tree may be submitted directly to the IANA.
虽然不需要公开曝光和审查要在个人目录树中注册的媒体类型，但强烈鼓励使用ietf类型列表进行审查，以提高这些规范的质量。个人目录树中的注册可直接提交给IANA。
For convenience and symmetry with this registration scheme, subtype names with "x." as the first facet may be used for the same purposes for which names starting in "x-" are used. These types are
为了方便和与此注册方案对称，第一个方面为“x”的子类型名称可用于与使用以“x-”开头的名称相同的目的。这些类型是
unregistered, experimental, and for use only with the active agreement of the parties exchanging them.
未注册的、试验性的，仅在交换方积极同意的情况下使用。
However, with the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.
然而，由于上述供应商和个人树木的简化注册程序，很少（如果有）需要使用未注册的实验类型。因此，不鼓励同时使用“x-”和“x”形式。
Types in this tree MUST NOT be registered.
不能注册此树中的类型。
From time to time and as required by the community, the IANA may, by and with the advice and consent of the IESG, create new top-level registration trees. It is explicitly assumed that these trees may be created for external registration and management by well-known permanent bodies; for example, scientific societies may register media types specific to the sciences they cover. In general, the quality of review of specifications for one of these additional registration trees is expected to be equivalent to registrations in the standards tree. Establishment of these new trees will be announced through RFC publication approved by the IESG.
根据社区的要求，IANA可不时在IESG的建议和同意下创建新的顶级注册树。明确假设这些树木可由知名常设机构进行外部登记和管理；例如，科学协会可能会登记他们所涵盖的科学的特定媒体类型。一般来说，这些附加注册树之一的规范审查质量应等同于标准树中的注册。这些新树木的建立将通过IESG批准的RFC出版物宣布。
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.
媒体类型注册提案均应符合以下各节规定的各项要求。请注意，需求细节有时会因注册树的不同而有所不同，这一点在以下章节中也有详细说明。
Media types MUST function as an actual media format. Registration of things that are better thought of as a transfer encoding, as a charset, or as a collection of separate entities of another type, is not allowed. For example, although applications exist to decode the base64 transfer encoding [RFC2045], base64 cannot be registered as a media type.
介质类型必须作为实际介质格式使用。不允许注册更好地被认为是传输编码、字符集或其他类型的独立实体集合的内容。例如，尽管存在用于解码base64传输编码[RFC2045]的应用程序，但base64不能注册为媒体类型。
This requirement applies regardless of the registration tree involved.
这一要求适用于任何涉及的注册树。
All registered media types MUST be assigned type and subtype names. The combination of these names serves to uniquely identify the media type, and the format of the subtype name identifies the registration tree. Both type and subtype names are case-insensitive.
必须为所有注册的媒体类型分配类型和子类型名称。这些名称的组合用于唯一标识媒体类型，子类型名称的格式标识注册树。类型和子类型名称都不区分大小写。
Type and subtype names beginning with "X-" are reserved for experimental use and MUST NOT be registered. This parallels the restriction on the x. tree, as discussed in Section 3.4.
以“X-”开头的类型和子类型名称保留供实验使用，不得注册。这与x轴上的限制平行。树，如第3.4节所述。
Type and subtype names MUST conform to the following ABNF:
类型和子类型名称必须符合以下ABNF：
type-name = reg-name subtype-name = reg-name
类型名称=注册名称子类型名称=注册名称
reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" /
"#" / "$" / "&" / "." /
"+" / "-" / "^" / "_"
reg-name = 1*127reg-name-chars
reg-name-chars = ALPHA / DIGIT / "!" /
"#" / "$" / "&" / "." /
"+" / "-" / "^" / "_"
Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in [RFC2045].
注意，这种语法比[RFC2045]中ABNF所允许的限制性更强。
In accordance with the rules specified in [RFC3023], media subtypes that do not represent XML entities MUST NOT be given a name that ends with the "+xml" suffix. More generally, "+suffix" constructs should be used with care, given the possibility of conflicts with future suffix definitions.
根据[RFC3023]中规定的规则，不代表XML实体的媒体子类型的名称不得以“+XML”后缀结尾。更一般地说，“+后缀”构造应该谨慎使用，因为可能与将来的后缀定义发生冲突。
While it is possible for a given media type to be assigned additional names, the use of different names to identify the same media type is discouraged.
虽然可以为给定的媒体类型分配额外的名称，但不鼓励使用不同的名称来标识相同的媒体类型。
These requirements apply regardless of the registration tree involved.
这些要求适用于任何涉及的注册树。
The choice of top-level type name MUST take into account the nature of media type involved. New subtypes of top-level types MUST conform to the restrictions of the top-level type, if any. The following sections describe each of the initial set of top-level types and their associated restrictions. Additionally, various protocols, including but not limited to MIME, MAY impose additional restrictions on the media types they can transport. (See [RFC2046] for additional information on the restrictions MIME imposes.)
顶级类型名称的选择必须考虑所涉及媒体类型的性质。顶级类型的新子类型必须符合顶级类型（如果有）的限制。以下各节描述了每个顶级类型的初始集合及其相关限制。此外，各种协议（包括但不限于MIME）可能会对它们可以传输的媒体类型施加额外的限制。（有关MIME施加的限制的更多信息，请参见[RFC2046]）
The "text" media type is intended for sending material that is principally textual in form. A "charset" parameter MAY be used to indicate the charset of the body text for "text" subtypes, notably including the subtype "text/plain", which is a generic subtype for plain text defined in [RFC2046]. If defined, a text "charset"
“文本”媒体类型用于发送主要是文本形式的材料。“字符集”参数可用于指示“文本”子类型的正文字符集，尤其包括子类型“文本/纯文本”，这是[RFC2046]中定义的纯文本的通用子类型。如果已定义，则为文本“字符集”
parameter MUST be used to specify a charset name defined in accordance to the procedures laid out in [RFC2978].
参数必须用于指定根据[RFC2978]中规定的程序定义的字符集名称。
Plain text does not provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup. Plain text is seen simply as a linear
纯文本不提供或允许格式化命令、字体属性规范、处理指令、解释指令或内容标记。纯文本被简单地视为线性文本
sequence of characters, possibly interrupted by line breaks or page breaks. Plain text MAY allow the stacking of several characters in the same position in the text. Plain text in scripts like Arabic and Hebrew may also include facilities that allow the arbitrary mixing of text segments with opposite writing directions.
字符序列，可能被换行符或分页符打断。纯文本可以允许在文本中的同一位置堆叠多个字符。阿拉伯文和希伯来文等脚本中的纯文本也可能包含允许任意混合具有相反书写方向的文本段的功能。
Beyond plain text, there are many formats for representing what might be known as "rich text". An interesting characteristic of many such representations is that they are to some extent readable even without the software that interprets them. It is useful to distinguish them, at the highest level, from such unreadable data as images, audio, or text represented in an unreadable form. In the absence of appropriate interpretation software, it is reasonable to present subtypes of "text" to the user, while it is not reasonable to do so with most non-textual data. Such formatted textual data should be represented using subtypes of "text".
除了纯文本之外，还有许多格式可以表示所谓的“富文本”。许多这种表示法的一个有趣特征是，即使没有解释它们的软件，它们在某种程度上也是可读的。在最高层次上，将它们与图像、音频或以不可读形式表示的文本等不可读数据区分开来是很有用的。在没有合适的解释软件的情况下，向用户呈现“文本”的子类型是合理的，而对大多数非文本数据这样做是不合理的。此类格式化文本数据应使用“文本”的子类型表示。
A media type of "image" indicates that the content specifies or more separate images that require appropriate hardware to display. The subtype names the specific image format.
媒体类型的“图像”表示内容指定一个或多个需要适当硬件显示的单独图像。子类型命名特定的图像格式。
A media type of "audio" indicates that the content contains audio data.
“音频”的媒体类型表示内容包含音频数据。
A media type of "video" indicates that the content specifies a time-varying-picture image, possibly with color and coordinated sound. The term 'video' is used in its most generic sense, rather than with reference to any particular technology or format, and is not meant to preclude subtypes such as animated drawings encoded compactly.
媒体类型的“视频”表示内容指定了时变的图片图像，可能带有颜色和协调的声音。术语“视频”在其最一般的意义上使用，而不是指任何特定的技术或格式，并不意味着排除子类型，例如紧凑编码的动画图形。
Note that although in general this document strongly discourages the mixing of multiple media in a single body, it is recognized that many so-called video formats include a representation for synchronized audio and/or text, and this is explicitly permitted for subtypes of "video".
请注意，尽管本文件通常强烈反对在单个实体中混合多种媒体，但人们认识到，许多所谓的视频格式包括同步音频和/或文本的表示，这是明确允许的“视频”子类型。
The "application" media type is to be used for discrete data that do not fit in any of the media types, and particularly for data to be processed by some type of application program. This is information that must be processed by an application before it is viewable or usable by a user. Expected uses for the "application" media type include but are not limited to file transfer, spreadsheets, presentations, scheduling data, and languages for "active" (computational) material. (The latter, in particular, can pose security problems that must be understood by implementors, and are considered in detail in the discussion of the "application/ PostScript" media type in [RFC2046].)
“应用程序”介质类型用于不适合任何介质类型的离散数据，特别是用于由某些类型的应用程序处理的数据。这是应用程序必须处理的信息，用户才能查看或使用这些信息。“应用程序”媒体类型的预期用途包括但不限于文件传输、电子表格、演示文稿、计划数据和“活动”（计算）材料的语言。（尤其是后者可能会带来安全问题，实施者必须理解这些问题，并在[RFC2046]中对“应用程序/PostScript”媒体类型的讨论中详细考虑这些问题。）
For example, a meeting scheduler might define a standard representation for information about proposed meeting dates. An intelligent user agent would use this information to conduct a dialog with the user, and might then send additional material based on that dialog. More generally, there have been several "active" languages developed in which programs in a suitably specialized language are transported to a remote location and automatically run in the recipient's environment. Such applications may be defined as subtypes of the "application" media type.
例如，会议调度器可能会为有关建议会议日期的信息定义标准表示形式。智能用户代理将使用此信息与用户进行对话，然后根据该对话发送其他材料。更一般地说，已经开发了几种“主动”语言，其中使用适当专门语言的程序被传输到远程位置，并在接收者的环境中自动运行。此类应用可定义为“应用”媒体类型的子类型。
The subtype of "application" will often be either the name or include part of the name of the application for which the data are intended. This does not mean, however, that any application program name may be used freely as a subtype of "application".
“应用程序”的子类型通常是数据所针对的应用程序的名称或包含部分名称。然而，这并不意味着任何应用程序名称都可以作为“应用程序”的子类型自由使用。
Multipart and message are composite types, that is, they provide a means of encapsulating zero or more objects, each labeled with its own media type.
Multipart和message是复合类型，也就是说，它们提供了封装零个或多个对象的方法，每个对象都用自己的媒体类型标记。
All subtypes of multipart and message MUST conform to the syntax rules and other requirements specified in [RFC2046].
multipart和message的所有子类型必须符合[RFC2046]中规定的语法规则和其他要求。
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 does arise 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.
在某些情况下，新媒体类型可能不适合当前定义的任何顶级内容类型。这种情况预计相当罕见。但是，如果出现这种情况，可以定义一个新的顶级类型来适应它。此类定义必须通过标准跟踪RFC进行；没有其他机制可用于定义其他顶级内容类型。
Media types MAY elect to use one or more media 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 standards tree, and SHOULD be specified as completely as possible when media types are registered in the vendor or personal trees.
在标准树中注册介质类型时，应尽可能完整地指定介质类型（在供应商或个人树中注册介质类型时）。
Parameter names have the syntax as media type names and values:
参数名称的语法与媒体类型名称和值相同：
parameter-name = reg-name
parameter-name = reg-name
Note that this syntax is somewhat more restrictive than what is allowed by the ABNF in [RFC2045] and amended by [RFC2231].
请注意，该语法比[RFC2045]中ABNF所允许并由[RFC2231]修订的语法更具限制性。
There is no defined syntax for parameter values. Therefore registrations MUST specify parameter value syntax. Additionally, some transports impose restrictions on parameter value syntax, so care should be taken to limit the use of potentially problematic syntaxes; e.g., pure binary valued parameters, while permitted in some protocols, probably should be avoided.
没有为参数值定义语法。因此，注册必须指定参数值语法。此外，一些传输对参数值语法施加限制，因此应注意限制潜在问题语法的使用；e、 例如，虽然某些协议允许使用纯二进制值参数，但可能应该避免使用。
New parameters SHOULD NOT be defined as a way to introduce new functionality in types registered in the standards 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.
新参数不应定义为在“标准”树中注册的类型中引入新功能的方式，尽管可以添加新参数以传递不会改变现有功能的附加信息。例如，“修订”参数表示外部规范（如JPEG）的修订级别。对于在供应商或个人目录树中注册的媒体类型，鼓励采取类似的行为，但不是必需的。
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 MUST exist for all types registered in the standards tree and MUST at a minimum be referenced by, if it isn't actually included in, the media type registration proposal itself.
对于在标准树中注册的所有类型，必须存在每个媒体类型格式的精确且公开可用的规范，并且如果媒体类型注册提案中未包含该规范，则至少必须由媒体类型注册提案本身引用。
The specifications of format and processing particulars may or may not be publicly available for media types registered in the vendor tree, and such registration proposals are explicitly permitted to
格式和处理细节的规范可能公开，也可能不公开，用于在供应商目录树中注册的媒体类型，并且明确允许公开此类注册建议
limit specification to 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 the 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.
在个人目录树中注册仍然需要格式规范，但可以作为RFC发布或以其他方式存放在IANA。存放的规范将满足注册知名TCP端口所需的相同标准，特别是无需公开。
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 [RFC2026] on the use of patented technology in IETF standards-track protocols must be respected when the specification of a media type is part of a standards-track protocol. In addition, other standards bodies making use of the standards tree may have their own rules regarding intellectual property that must be observed in their registrations.
一些媒体类型涉及专利技术的使用。特别允许注册涉及专利技术的媒体类型。但是，当媒体类型规范是标准跟踪协议的一部分时，必须遵守[RFC2026]中规定的在IETF标准跟踪协议中使用专利技术的限制。此外，使用“标准树”的其他标准机构可能有自己的知识产权规则，必须在注册时遵守这些规则。
Media types SHOULD 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.
这些建议适用于任何涉及的注册树。
An analysis of security issues MUST be done for all types registered in the standards Tree. 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 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 Section 6 below.
所有注册的“安全注意事项”部分均需不断评估和修改，特别是可通过使用下文第6节所述的“媒体类型评论”机制进行扩展。
Some of the issues that should be looked at in a security analysis of a media type are:
在对媒体类型进行安全分析时，应注意以下问题：
o 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 that may then have devastating effects. See the registration of the application/postscript media type in [RFC2046] for an example of such directives and how they should be described in a media type registration.
o 复杂的媒体类型可能包括对收件人的文件或其他资源执行操作的指令的规定。在许多情况下，规定发起者以不受限制的方式指定可能产生毁灭性影响的任意行为。请参阅[RFC2046]中的应用程序/postscript媒体类型注册，以了解此类指令的示例以及在媒体类型注册中应如何描述这些指令。
o All registrations MUST state whether or not they employ such "active content", and if they do, they MUST state what steps have been taken to protect users of the media type from harm.
o 所有注册必须说明他们是否使用此类“活动内容”，如果使用，则必须说明采取了哪些措施保护媒体类型的用户免受伤害。
o Complex media types may include provisions for directives that institute actions that, 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.
o 复杂的媒体类型可能包括指令规定，这些指令虽然不会直接伤害接收者，但可能导致信息泄露，从而促进后续攻击或以某种方式侵犯接收者的隐私。同样，应用程序/postscript媒体类型的注册说明了如何处理此类指令。
o A media type that employs compression may provide an opportunity for sending a small amount of data that, when received and evaluated, expands enormously to consume all of the recipient's resources. All media types SHOULD state whether or not they employ compression, and if they do they should discuss what steps need to be taken to avoid such attacks.
o 采用压缩的媒体类型可能会提供发送少量数据的机会，这些数据在接收和评估时会极大地扩展以消耗接收者的所有资源。所有媒体类型都应说明是否使用压缩，如果使用压缩，则应讨论需要采取哪些步骤来避免此类攻击。
o 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 that in turn
o 媒体类型可能针对需要某种安全保证但本身不提供必要安全机制的应用程序。例如，可以定义媒体类型来存储机密医疗信息，而机密医疗信息反过来
requires an external confidentiality service, or which is designed for use only within a secure environment.
需要外部保密服务，或仅在安全环境中使用。
There are a number of additional requirements specific to the registration of XML media types. These requirements are specified in [RFC3023].
对于XML媒体类型的注册，还有许多特定的附加要求。[RFC3023]中规定了这些要求。
Some transports impose restrictions on the type of data they can carry. For example, Internet mail traditionally was limited to 7bit US-ASCII text. Encoding schemes are often used to work around such transport limitations.
一些传输对它们可以携带的数据类型施加限制。例如，互联网邮件传统上仅限于7位US-ASCII文本。编码方案通常用于解决此类传输限制。
It is therefore useful to note what sort of data a media type can consist of as part of its registration. An "encoding considerations" field is provided for this purpose. Possible values of this field are:
因此，注意作为注册的一部分，媒体类型可以包含哪些类型的数据是很有用的。为此提供了一个“编码注意事项”字段。此字段的可能值为：
7bit: The content of the media type consists solely of CRLF-delimited 7bit US-ASCII text.
7bit：媒体类型的内容仅由CRLF分隔的7bit US-ASCII文本组成。
8bit: The content of the media type consists solely of CRLF-delimited 8bit text.
8位：媒体类型的内容仅由CRLF分隔的8位文本组成。
binary: The content consists of unrestricted sequence of octets.
二进制：内容由不受限制的八位字节序列组成。
framed: The content consists of a series of frames or packets without internal framing or alignment indicators. Additional out-of-band information is needed to interpret the data properly, including but not necessarily limited to, knowledge of the boundaries between successive frames and knowledge of the transport mechanism. Note that media types of this sort cannot simply be stored in a file or transported as a simple stream of octets; therefore, such media types are unsuitable for use in many traditional protocols. A commonly used transport with framed encoding is the Real-time Transport Protocol, RTP. Additional rules for framed encodings defined for transport using RTP are given in [RFC3555].
框架：内容由一系列没有内部框架或对齐指示器的框架或数据包组成。需要额外的带外信息来正确解释数据，包括但不一定限于连续帧之间边界的知识和传输机制的知识。请注意，这类媒体类型不能简单地存储在文件中或作为简单的八位字节流传输；因此，这种媒体类型不适合在许多传统协议中使用。一种常用的帧编码传输协议是实时传输协议RTP。[RFC3555]中给出了为使用RTP传输定义的帧编码的其他规则。
Additional restrictions on 7bit and 8bit text are given in [RFC2046].
[RFC2046]中给出了7位和8位文本的附加限制。
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 media types used to those "common" formats expected to be widely implemented. This was asserted in the past as a reason to limit the number of possible media types, and it 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.
但是，对“通用”媒体类型的需求并不要求限制新媒体类型的注册。如果建议为特定应用程序提供一组有限的介质类型，则应通过针对该应用程序和/或环境的单独适用性声明来声明。
Therefore, universal support and implementation of a media type is NOT a requirement for registration. However, if a media type is explicitly intended for limited use, this MUST be noted in its registration. The "Restrictions on Usage" field is provided for this purpose.
因此，对媒体类型的普遍支持和实现不是注册的要求。但是，如果介质类型明确用于有限用途，则必须在其注册中注明。为此，提供了“使用限制”字段。
Proposals for media types registered in the standards tree by the IETF itself MUST be published as RFCs. RFC publication of vendor and personal media type proposals is encouraged but not required. In all cases the IANA will retain copies of all media type proposals and "publish" them as part of the media types registration tree itself.
IETF本身在标准树中注册的媒体类型提案必须作为RFC发布。鼓励但不要求RFC发布供应商和个人媒体类型的建议书。在所有情况下，IANA将保留所有媒体类型建议书的副本，并将其作为媒体类型注册树的一部分“发布”。
As stated previously, standards tree registrations for media types defined in documents produced by other standards bodies MUST be described by a formal standards specification produced by that body. Such specifications MUST contain an appropriate media type registration template taken from Section 10. Additionally, the copyright on the registration template MUST allow the IANA to copy it into the IANA registry.
如前所述，其他标准机构编制的文件中定义的媒体类型的标准树注册必须由该机构编制的正式标准规范描述。此类规范必须包含取自第10节的适当媒体类型注册模板。此外，注册模板的版权必须允许IANA将其复制到IANA注册中心。
Other than IETF registrations in the standards tree, the registration of a data type does not imply endorsement, approval, or recommendation by the IANA or the IETF or even certification that the specification is adequate. To become Internet Standards, a protocol or data object must go through the IETF standards process. This is too difficult and too lengthy a process for the convenient registration of media types.
除了标准树中的IETF注册外，数据类型的注册并不意味着IANA或IETF的认可、批准或建议，甚至也不意味着证明该规范是充分的。要成为互联网标准，协议或数据对象必须经过IETF标准过程。对于方便地注册媒体类型来说，这是一个太难、太长的过程。
The standards tree exists for media types that do require a substantive review and approval process in a recognized standards body. The vendor and personal trees exist for those media types that do not require such a process. It is expected that applicability statements for particular applications will be published from time to
标准树适用于需要在公认标准机构中进行实质性审查和批准流程的媒体类型。对于不需要此过程的媒体类型，存在供应商和个人树。预计将不时发布特定应用的适用性声明
time in the IETF, recommending implementation of, and support for, media types that have proven particularly useful in those contexts.
在IETF中的时间，建议实施和支持在这些环境中证明特别有用的媒体类型。
As discussed above, registration of a top-level type requires standards-track processing in the IETF and, hence, RFC publication.
如上所述，顶级类型的注册需要IETF中的标准跟踪处理，因此需要RFC发布。
Various sorts of optional information SHOULD be included in the specification of a media type if it is available:
媒体类型规范中应包含各种可选信息（如果可用）：
o Magic number(s) (length, octet values). Magic numbers are byte sequences that are always present at a given place in the file and thus can be used to identify entities as being of a given media type.
o 幻数（长度、八位字节值）。幻数是始终存在于文件中给定位置的字节序列，因此可用于将实体标识为给定媒体类型。
o File name extension(s) commonly used on one or more platforms to indicate that some file contains a given media type.
o 一个或多个平台上常用的文件扩展名，用于指示某些文件包含给定的媒体类型。
o Mac OS File Type code(s) (4 octets) used to label files containing a given media type.
o Mac OS文件类型代码（4个八位字节），用于标记包含给定媒体类型的文件。
o Information about how fragment/anchor identifiers [RFC3986] are constructed for use in conjunction with this media type.
o 有关如何构造片段/锚标识符[RFC3986]以与此媒体类型结合使用的信息。
In the case of a registration in the standards tree, this additional information MAY be provided in the formal specification of the media type. It is suggested that this be done by incorporating the IANA media type registration form into the specification itself.
在标准树中注册的情况下，可以在媒体类型的正式规范中提供此附加信息。建议通过将IANA媒体类型登记表纳入规范本身来实现这一点。
The media type registration procedure is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay.
媒体类型的注册程序不是一个正式的标准程序，而是一个行政程序，旨在允许社区评论和健全性检查，而无需过多的时间延迟。
The normal IETF processes should be followed for all IETF registrations in the standards tree. The posting of an Internet Draft is a necessary first step, followed by posting to the ietf-types@iana.org list as discussed below.
标准树中的所有IETF注册都应遵循正常的IETF流程。互联网草案的发布是必要的第一步，然后发布到ietf-types@iana.org列表如下所述。
Registrations in the vendor and personal tree should be submitted directly to the IANA, ideally after first posting to the ietf-types@iana.org list for review.
供应商和个人目录树中的注册应直接提交给IANA，最好在首次发布到ietf后提交-types@iana.org供审查的清单。
Proposed registrations in the standards tree by other standards bodies should be communicated to the IESG (at iesg@ietf.org) and to the ietf-types list (at ietf-types@iana.org). Prior posting as an
其他标准机构在标准树中提出的注册应通知IESG（在iesg@ietf.org)和ietf类型列表（在ietf-types@iana.org). 以前作为
Internet Draft is not required for these registrations, but may be helpful to the IESG and is encouraged.
这些注册不需要网络草稿，但可能有助于IESG，并鼓励使用。
Notice of a potential media type registration in the standards tree MUST be sent to the "ietf-types@iana.org" mailing list for review. This mailing list has been established for the purpose of reviewing proposed media and access types. Registrations in other trees MAY be sent to the list for review as well.
必须向“ietf”发送标准树中可能的媒体类型注册通知-types@iana.org“供审查的邮件列表。建立此邮件列表的目的是审查建议的媒体和访问类型。其他树中的注册也可以发送到列表进行审查。
The intent of the public posting to this list 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 abandon the registration completely and at any time.
公开发布到此列表的目的是就类型/子类型名称的选择、版本和外部分析信息引用的明确性以及任何互操作性或安全考虑事项的审查征求意见和反馈。提交人可随时提交修改后的注册或完全放弃注册。
Media types registered in the standards tree MUST be approved by the IESG prior to registration.
在标准树中注册的介质类型必须在注册前获得IESG的批准。
Provided that the media type meets all of the relevant requirements and has obtained whatever approval is necessary, the author may submit the registration request to the IANA. Registration requests can be sent to iana@iana.org. A web form for registration requests is also available:
如果媒体类型符合所有相关要求，并获得任何必要的批准，作者可以向IANA提交注册申请。注册申请可发送至iana@iana.org. 还提供了注册请求的web表单：
http://www.iana.org/cgi-bin/mediatypes.pl
http://www.iana.org/cgi-bin/mediatypes.pl
Sending to ietf-types@iana.org does not constitute submitting the registration to the IANA.
发送到ietf-types@iana.org不构成向IANA提交注册。
When the registration is either part of an RFC publication request or a registration in the standards tree submitted to the IESG, close coordination between the IANA and the IESG means IESG approval in effect submits the registration to the IANA. There is no need for an additional registration request in such cases.
当注册是RFC发布请求的一部分或提交给IESG的标准树中的注册时，IANA和IESG之间的密切协调意味着IESG批准实际上将注册提交给IANA。在这种情况下，不需要额外的注册请求。
Registrations submitted to the IANA will be passed on to the media types reviewer. The media types reviewer, who is appointed by the IETF Applications Area Director(s), will review the registration to make sure it meets the requirements set forth in this document.
提交给IANA的注册将转交给媒体类型审查员。由IETF应用领域总监任命的媒体类型审查员将审查注册，以确保其符合本文件规定的要求。
Registrations that do not meet these requirements will be returned to the submitter for revision.
不符合这些要求的注册将返回给提交人进行修订。
Decisions made by the media types reviewer may be appealed to the IESG using the procedure specified in [RFC2026] section 6.5.4.
可使用[RFC2026]第6.5.4节规定的程序，对媒体类型审查员做出的决定向IESG提出上诉。
Once a media type registration has passed review, the IANA will register the media type and make the media type registration available to the community.
一旦媒体类型注册通过审核，IANA将注册媒体类型，并向社区提供媒体类型注册。
Comments on registered media types may be submitted by members of the community to the IANA. These comments will be reviewed by the media types reviewer and then 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 the IANA approves of this, the comment will be made accessible in conjunction with the type registration.
社区成员可向IANA提交注册媒体类型的评论。这些评论将由媒体类型审阅者审阅，然后尽可能传递给媒体类型的“所有者”。评论提交人可要求将其评论附加到媒体类型注册本身，如果IANA批准，评论将与类型注册一起提供。
Media type registrations are listed by the IANA at:
IANA在以下位置列出了媒体类型注册：
http://www.iana.org/assignments/media-types/
http://www.iana.org/assignments/media-types/
The IANA will only register media types in the standards 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 approval process as long as the following minimal conditions are met:
IANA将仅在标准树中注册媒体类型，以响应IESG发出的说明已批准给定注册的通信。只要满足以下最低条件，IANA将自动注册供应商和个人类型，无需任何正式批准流程：
o Media types MUST function as an actual media format. In particular, charsets and transfer encodings MUST NOT be registered as media types.
o 介质类型必须作为实际介质格式使用。特别是，字符集和传输编码不能注册为媒体类型。
o All media types MUST have properly formed type and subtype names. All type names MUST be defined by a standards-track RFC. All type/subtype name pairs MUST be unique and MUST contain the proper tree prefix.
o 所有媒体类型必须具有格式正确的类型和子类型名称。所有类型名称必须由标准跟踪RFC定义。所有类型/子类型名称对必须是唯一的，并且必须包含正确的树前缀。
o Types registered in the personal tree MUST either provide a format specification or a pointer to one.
o 在个人树中注册的类型必须提供格式规范或指向格式规范的指针。
o All media types MUST have a reasonable security considerations section. (It is neither possible nor necessary for the IANA to conduct a comprehensive security review of media type registrations. Nevertheless, the IANA has the authority to identify obviously incompetent material and return it to the submitter for revision.)
o 所有媒体类型都必须有一个合理的安全注意事项部分。（IANA既不可能也没有必要对媒体类型注册进行全面的安全审查。然而，IANA有权确定明显不合格的材料，并将其返回给提交人进行修订。）
Registrations in the standards tree MUST satisfy the additional requirement that they originate from the IETF itself or from another standards body recognized as such by the IETF.
标准树中的注册必须满足来自IETF本身或IETF认可的其他标准机构的附加要求。
Once a media type has been published by the IANA, the owner may request a change to its definition. The descriptions of the different registration trees above designate the "owners" of each type of registration. The same procedure that would be appropriate for the original registration request is used to process a change request.
IANA发布媒体类型后，所有者可以请求更改其定义。上述不同注册树的描述指定了每种注册类型的“所有者”。适用于原始注册申请的相同程序用于处理变更申请。
Changes should be requested only when there are serious omissions 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 media type may pass responsibility to another person or agency by informing the IANA and the ietf-types list; this can be done without discussion or review.
媒体类型的所有者可以通过通知IANA和ietf类型列表将责任转移给另一个人或机构；这可以在不进行讨论或审查的情况下完成。
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.
IESG可以重新分配媒体类型的责任。最常见的情况是，当注册作者去世、失去联系或无法进行对社区重要的更改时，可以对类型进行更改。
Media type registrations may not be deleted; media types that 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 the IANA.
不能删除媒体类型注册；通过更改“预期用途”字段，可以宣布不再适合使用的媒体类型为过时；IANA发布的列表中将明确标记此类媒体类型。
To: ietf-types@iana.org
Subject: Registration of media type XXX/YYY
To: ietf-types@iana.org
Subject: Registration of media type XXX/YYY
Type name:
类型名称：
Subtype name:
子类型名称：
Required parameters:
所需参数：
Optional parameters:
可选参数：
Encoding considerations:
编码注意事项：
Security considerations:
安全考虑：
Interoperability considerations:
互操作性注意事项：
Published specification:
已发布的规范：
Applications that use this media type:
使用此媒体类型的应用程序：
Additional information:
其他信息：
Magic number(s): File extension(s): Macintosh file type code(s):
幻数：文件扩展名：Macintosh文件类型代码：
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Intended usage:
预期用途：
(One of COMMON, LIMITED USE or OBSOLETE.)
（常用的、有限使用的或过时的。）
Restrictions on usage:
使用限制：
(Any restrictions on where the media type can be used go here.)
（有关媒体类型可使用位置的任何限制，请转到此处。）
Author:
作者：
Change controller:
更改控制器：
(Any other information that the author deems interesting may be added below this line.)
（作者认为有趣的任何其他信息可添加在此行下方。）
Some discussion of Macintosh file type codes and their purpose can be found in [MacOSFileTypes]. Additionally, please refrain from writing
有关Macintosh文件类型代码及其用途的一些讨论，请参见[MacOSFileTypes]。此外，请不要写信
"none" or anything similar when no file extension or Macintosh file type is specified, lest "none" be confused with an actual code value.
如果未指定文件扩展名或Macintosh文件类型，则为“无”或任何类似项，以免将“无”与实际代码值混淆。
Security requirements for media type registrations are discussed in Section 4.6.
第4.6节讨论了媒体类型注册的安全要求。
The purpose of this document is to define IANA registries for media types.
本文档的目的是为媒体类型定义IANA注册表。
The current authors would like to acknowledge their debt to the late Dr. Jon Postel, whose general model of IANA registration procedures and specific contributions shaped the predecessors of this document [RFC2048]. We hope that the current version is one with which he would have agreed but, as it is impossible to verify that agreement, we have regretfully removed his name as a co-author.
目前的作者要感谢已故的Jon Postel博士，他的IANA注册程序的一般模型和具体贡献形成了本文件的前身[RFC2048]。我们希望目前的版本是他本会同意的版本，但由于无法核实这一协议，我们遗憾地删除了他作为合著者的姓名。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.
[RFC2978]Freed，N.和J.Postel，“IANA字符集注册程序”，BCP 19，RFC 2978，2000年10月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[RFC3555]Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 35552003年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4234] Crocker, D. Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator Codes, and File Formats", Apple Knowledge Base Article 55381, June 1993, <http://www.info.apple.com/kbnum/n55381>.
[MacOSFileTypes]Apple Computer，Inc.，“Mac OS:文件类型和创建者代码以及文件格式”，苹果知识库文章553811993年6月<http://www.info.apple.com/kbnum/n55381>.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[RFC2048]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
A number of media types, registered prior to 1996, would, if registered under the guidelines in this document, be placed into either the vendor or personal trees. Reregistration of those types to reflect the appropriate trees is encouraged but not required. Ownership and change control principles outlined in this document apply to those types as if they had been registered in the trees described above.
1996年之前注册的许多媒体类型，如果根据本文件中的指南注册，将被放入供应商或个人目录树中。鼓励重新登记这些类型，以反映适当的树木，但不是必需的。本文件中概述的所有权和变更控制原则适用于这些类型，如同它们已在上述树木中注册一样。
o Media type specification and registration procedures have been moved out of the MIME document set to this separate specification.
o 媒体类型规范和注册程序已从MIME文档集中移到这个单独的规范中。
o The various URLs and addresses in this document have been changed so they all refer to iana.org rather than isi.edu. Additionally, many of the URLs have been changed to use HTTP; formerly they used FTP.
o 本文档中的各种URL和地址已更改，因此它们都指向iana.org而不是isi.edu。此外，许多URL已更改为使用HTTP；以前他们使用FTP。
o Much of the document has been clarified in the light of operational experience with these procedures.
o 根据这些程序的运行经验，文件的大部分内容已得到澄清。
o The unfaceted IETF tree is now called the standards tree, and the registration rules for this tree have been relaxed to allow use by other standards bodies.
o 未经认证的IETF树现在称为标准树，该树的注册规则已经放宽，允许其他标准机构使用。
o The text describing the media type registration procedure has clarified.
o 描述介质类型注册程序的文本已澄清。
o The rules and requirements for constructing security considerations sections have been extended and clarified.
o 构建安全注意事项部分的规则和要求已经扩展和澄清。
o RFC 3023 is now referenced as the source of additional information concerning the registration of XML media types.
o RFC3023现在被引用为有关XML媒体类型注册的附加信息源。
o Several of the references in this document have been updated to refer to current versions of the relevant specifications.
o 本文件中的几个参考文件已更新，以参考相关规范的当前版本。
o A note has been added discouraging the assignment of multiple names to a single media type.
o 添加了一条注释，禁止将多个名称分配给单个媒体类型。
o Security considerations and IANA considerations sections have been added.
o 增加了安全注意事项和IANA注意事项部分。
o Concerns regarding copyrights on media type registration templates produced by other standards bodies have been dealt with by requiring that the IANA be allowed to copy the registration template into the registry.
o 对于其他标准机构制作的媒体类型注册模板的版权问题，已通过要求允许IANA将注册模板复制到注册中心来解决。
o The basic registration requirements for the various top-level types have been moved from RFC 2046 to this document.
o 各种顶级类型的基本注册要求已从RFC 2046移至本文件。
o A syntax is now specified for media type, subtype, and parameter names.
o 现在为媒体类型、子类型和参数名指定了语法。
o Imposed a maximum length of 127 on all media type and subtype names.
o 对所有媒体类型和子类型名称施加的最大长度为127。
o A note has been added to caution against excessive use of "+suffix" constructs in subtype names.
o 添加了一个注释，以警告不要在子类型名称中过度使用“+后缀”构造。
o The encoding considerations field has been extended to allow the value "framed".
o 编码注意事项字段已扩展为允许值“framed”。
o A reference describing Macintosh Type codes has been added.
o 已添加描述Macintosh类型代码的参考。
o Ietf-types list review of registrations in the standards tree is now required rather than just recommended.
o 现在需要对标准树中的注册进行Ietf类型列表审查，而不仅仅是推荐。
Authors' Addresses
作者地址
Ned Freed Sun Microsystems 3401 Centrelake Drive, Suite 410 Ontario, CA 92761-1205 USA
Ned Freed Sun Microsystems 3401 Centrelake Drive，美国加利福尼亚州安大略省410号套房92761-1205
Phone: +1 909 457 4293
EMail: ned.freed@mrochek.com
Phone: +1 909 457 4293
EMail: ned.freed@mrochek.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140
马萨诸塞州剑桥322号马萨诸塞大道1770号约翰·C·克伦辛，邮编：02140
EMail: klensin+ietf@jck.com
EMail: klensin+ietf@jck.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。