Network Working Group K. Holtman
Request for Comments: 2506 TUE
BCP: 31 A. Mutz
Category: Best Current Practice Hewlett-Packard
T. Hardie
Equinix
March 1999
Network Working Group K. Holtman
Request for Comments: 2506 TUE
BCP: 31 A. Mutz
Category: Best Current Practice Hewlett-Packard
T. Hardie
Equinix
March 1999
Media Feature Tag Registration Procedure
媒体功能标签注册程序
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
ABSTRACT
摘要
Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved.
最近的互联网应用程序，如万维网，将数据格式、客户机和服务器平台以及社区的多样性结合在一起。这就需要媒体功能描述和协商机制，以便确定信息的形式并使其与有关各方的能力和偏好相协调。
Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration.
可扩展媒体特征识别和协商机制需要一个通用词汇表，以便积极识别媒体特征。定义媒体功能的注册过程和权限的目的是在通信各方之间共享该词汇表。此外，还定义了一个URI树，以便在不进行注册的情况下共享媒体功能定义。
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.
本文档定义了一个注册程序，该程序使用互联网分配号码管理局（IANA）作为媒体功能词汇表的中央注册表。
Please send comments to the CONNEG working group at <ietf-medfree@imc.org>. Discussions of the working group are archived at <URL: http://www.imc.org/ietf-medfree/>.
请将意见发送至CONNEG工作组<ietf-medfree@imc.org>. 工作组的讨论存档在<URL:http://www.imc.org/ietf-medfree/>.
TABLE OF CONTENTS
目录
1 Introduction ................................................. 2
2 Media feature tag definitions ................................ 3
2.1 Media feature tag purpose ................................. 3
2.2 Media feature tag syntax .................................. 4
2.3 Media feature tag values .................................. 4
2.4 ASN.1 identifiers for media feature tags ................. 5
3 Media feature tag registration ............................... 5
3.1 Registration trees ........................................ 6
3.1.1 IETF tree ............................................... 6
3.1.2 Global tree ............................................. 6
3.1.3 URL tree ................................................ 6
3.1.4 Additional registration trees ........................... 7
3.2 Location of registered media feature tag list ............. 7
3.3 IANA procedures for registering media feature tags ........ 7
3.4 Registration template ..................................... 7
4 Security Considerations ...................................... 10
5 Acknowledgments .............................................. 10
6 References ................................................... 10
7 Authors' Addresses ........................................... 11
8 Full Copyright Statement ..................................... 12
1 Introduction ................................................. 2
2 Media feature tag definitions ................................ 3
2.1 Media feature tag purpose ................................. 3
2.2 Media feature tag syntax .................................. 4
2.3 Media feature tag values .................................. 4
2.4 ASN.1 identifiers for media feature tags ................. 5
3 Media feature tag registration ............................... 5
3.1 Registration trees ........................................ 6
3.1.1 IETF tree ............................................... 6
3.1.2 Global tree ............................................. 6
3.1.3 URL tree ................................................ 6
3.1.4 Additional registration trees ........................... 7
3.2 Location of registered media feature tag list ............. 7
3.3 IANA procedures for registering media feature tags ........ 7
3.4 Registration template ..................................... 7
4 Security Considerations ...................................... 10
5 Acknowledgments .............................................. 10
6 References ................................................... 10
7 Authors' Addresses ........................................... 11
8 Full Copyright Statement ..................................... 12
1 Introduction
1导言
Recent Internet applications, such as the World Wide Web, tie together a great diversity in data formats, client and server platforms, and communities. This has created a need for media feature descriptions and negotiation mechanisms in order to identify and reconcile the form of information to the capabilities and preferences of the parties involved.
最近的互联网应用程序，如万维网，将数据格式、客户机和服务器平台以及社区的多样性结合在一起。这就需要媒体功能描述和协商机制，以便确定信息的形式并使其与有关各方的能力和偏好相协调。
Extensible media feature identification and negotiation mechanisms require a common vocabulary in order to positively identify media features. A registration process and authority for media features is defined with the intent of sharing this vocabulary between communicating parties. In addition, a URI tree is defined to enable sharing of media feature definitions without registration.
可扩展媒体特征识别和协商机制需要一个通用词汇表，以便积极识别媒体特征。定义媒体功能的注册过程和权限的目的是在通信各方之间共享该词汇表。此外，还定义了一个URI树，以便在不进行注册的情况下共享媒体功能定义。
This document defines a registration procedure which uses the Internet Assigned Numbers Authority (IANA) as a central registry for the media feature vocabulary.
本文档定义了一个注册程序，该程序使用互联网分配号码管理局（IANA）作为媒体功能词汇表的中央注册表。
This document uses the terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY according to usage described in [8].
根据[8]中描述的用法，本文件使用了术语“必须”、“不得”、“应该”、“不应该”和“可以”。
2 Media feature tag definitions
2媒体功能标签定义
Media feature tags represent individual and simple characteristics related to media capabilities or properties associated with the resource to which they are applied. Examples of such features are:
媒体功能标签表示与媒体功能或与应用它们的资源相关的属性相关的单个简单特征。这些特征的示例包括：
* the color depth of the screen on which something is to be displayed * the type of paper available in a printer * the support of the `floating 5 dimensional tables' feature * the fonts which are available to the recipient * the capability to display graphical content
* 屏幕上显示内容的颜色深度*打印机中可用的纸张类型*支持“浮动5维表”功能*收件人可用的字体*显示图形内容的能力
Each media feature tag identifies a single characteristic. Values associated with a specific tag must use the data type defined for that tag. The list of allowed data types is presented below, in section 2.3.
每个媒体功能标签标识一个特征。与特定标记关联的值必须使用为该标记定义的数据类型。下面第2.3节列出了允许的数据类型列表。
Examples of media feature tags with values are:
具有值的媒体功能标签示例如下：
* the width of a display in pixels per centimeter represented as an integer value. * a font available to a recipient, selected from an enumerated list. * the version of a protocol composed of integers "i.j.k", defined as either a value in an enumerated list or with a defined mapping to make the value isomorphic to a subset of integers (e.g. i*100 + j*10 +k, assuming j<=9 and k<=9).
* 显示器的宽度，单位为每厘米像素，表示为整数值。*收件人可用的字体，从枚举列表中选择。*由整数“i.j.k”组成的协议版本，定义为枚举列表中的一个值或具有定义的映射以使该值同构于整数子集（例如i*100+j*10+k，假设j<=9和k<=9）。
Further examples of media feature tags are defined in detail elsewhere [4].
其他地方详细定义了媒体特征标签的其他示例[4]。
Feature collections may be composed using a number of individual feature tags [2]. Composition of feature collections is described elsewhere [2]. Examples of feature collections requiring multiple media feature tags are:
特征集合可以使用多个单独的特征标记组成[2]。特征集合的组成在其他地方进行了描述[2]。需要多个媒体功能标签的功能集合示例如下：
* the set of all fonts used by a document * the width and height of a display * the combination of color depth and resolution a display can support
* 文档使用的所有字体集*显示器的宽度和高度*显示器可以支持的颜色深度和分辨率的组合
This registry presumes the availability of the MIME media type registry, and MIME media types MUST NOT be re-registered as media feature tags. Media feature tags which are currently in use by individual protocols or applications MAY be registered with this registry if they might be applied outside of their current domain.
此注册表假定MIME媒体类型注册表可用，并且MIME媒体类型不得重新注册为媒体功能标签。单个协议或应用程序当前正在使用的媒体功能标签，如果可能在其当前域之外应用，则可以在此注册表中注册。
The media feature tag namespace is not bound to a particular transport protocol or capability exchange mechanism. The registry is limited, however, to feature tags which express a capability or preference related to how content is presented. Feature tags related to other axes of negotiation are not appropriate for this registry. Capability exchange mechanisms may, of course, be used to express a variety of capabilities or preferences.
媒体功能标记命名空间未绑定到特定的传输协议或功能交换机制。然而，注册表仅限于表示与内容呈现方式相关的功能或偏好的功能标签。与其他协商轴相关的特征标记不适用于此注册表。当然，能力交换机制可用于表示各种能力或偏好。
A media feature tag is a string consisting of one or more of the following US-ASCII characters: uppercase letters, lowercase letters, digits, colon (":"), slash ("/"), dot (".") percent ("%"), and dash ("-"). Feature tags are case-insensitive. Dots are understood to potentially imply hierarchy; a feature can be subtyped by describing it as tree.feature.subfeature and by indicating this in the registration. Tags should begin with an alphabetic character.
媒体功能标签是由以下一个或多个US-ASCII字符组成的字符串：大写字母、小写字母、数字、冒号（“：”）、斜杠（“/”）、点（“.”）百分比（“%”）和短划线（“-”）。功能标记不区分大小写。点被理解为潜在地暗示层次；可以通过将特征描述为tree.feature.subfeature并在注册中指明该特征来对其进行子类型化。标记应以字母字符开头。
In ABNF [6], this may be represented as:
在ABNF[6]中，这可以表示为：
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )
Feature-tag = ALPHA *( ALPHA / DIGIT / ":" / "/" / "." / "-" /"%" )
Registrants should take care to avoid creating tags which might conflict with the creation of new registration trees; in general this means avoiding tags which begin with an alphabetic character followed by a dot. The current registration trees are described in section 3 below.
注册人应注意避免创建可能与创建新注册树冲突的标签；一般来说，这意味着避免使用以字母字符开头，后跟点的标签。下面第3节介绍了当前的注册树。
The registry will initially support the use of the following data types as tag values:
注册表最初将支持使用以下数据类型作为标记值：
- signed integers - rational numbers - tokens, with equality relationship - tokens, with defined ordering relationship - strings, with standard (octet-by-octet) equality relationship - strings, with defined equality and/or comparison relationship
- 有符号整数-有理数-令牌，具有相等关系-令牌，具有定义的排序关系-字符串，具有标准（八位字节对八位字节）相等关系-字符串，具有定义的相等和/或比较关系
"Token" here means the token data type as defined by [7], which may be summarized as:
“令牌”在此指[7]定义的令牌数据类型，可概括为：
token = 1*<any CHAR except CTLs or tspecials>
token = 1*<any CHAR except CTLs or tspecials>
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / <">
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
At the time of registration, each tag must be associated with a single data type. If that data type implies a defined comparison or an ordering, the registrant must define the ordering or comparison. For ordered tokens, this may be by full enumeration of the tokens and their order or by reference to an ordering mechanism. For defined comparisons, a full description of the rules for comparison must be provided or included by reference.
注册时，每个标记必须与单个数据类型相关联。如果该数据类型意味着定义的比较或排序，则注册人必须定义排序或比较。对于有序令牌，这可以通过对令牌及其顺序的完全枚举或通过引用一种排序机制来实现。对于定义的比较，必须提供或通过引用包含比较规则的完整描述。
Media feature tags related to spatial or temporal characteristics must be registered with a single canonical unit. It is strongly preferred that units be in the SI system; where current practice has defined units in other systems (such as pixels per inch), a conversion method to SI units must be provided. Conversion methods should include a defined rounding practice.
与空间或时间特征相关的媒体特征标签必须注册到单个规范单元。强烈建议单位采用国际单位制；如果当前实践已在其他系统中定义了单位（如每英寸像素），则必须提供到SI单位的转换方法。转换方法应包括定义的舍入实践。
Certain protocols use ASN.1 identifiers rather than human-readable representations for capability exchange. In order to allow both systems to interoperate, registrants may provide an ASN.1 identifier or ask that IANA assign an ASN.1 identifier during registration. These identifiers are not required for registration, but may provide assistance to those building gateways or other cross-protocol systems. Note that ASN.1 identifiers assigned by IANA will be treated as tokens, not as elements from which sub-delegated identifiers may be created or derived.
某些协议使用ASN.1标识符而不是人类可读的表示来进行能力交换。为了允许两个系统互操作，注册人可以提供ASN.1标识符，或者要求IANA在注册期间分配ASN.1标识符。注册不需要这些标识符，但可以为构建网关或其他跨协议系统提供帮助。请注意，IANA分配的ASN.1标识符将被视为令牌，而不是创建或派生子委托标识符的元素。
3 Media feature tag registration
3媒体功能标签注册
Media feature tags can be registered in several different registration trees, with different requirements as discussed below. The vocabulary for these requirements is taken from [5]. In general, a feature tag registration proposal is circulated and reviewed in a fashion appropriate to the tree involved. The feature tag is then registered if the proposal is accepted.
媒体功能标签可以在几个不同的注册树中注册，其要求如下所述。这些要求的词汇取自[5]。一般来说，特征标签注册建议以适合所涉及树的方式进行分发和审查。如果建议被接受，那么功能标签将被注册。
Review of a feature tag in the URI tree is not required.
不需要查看URI树中的功能标记。
The following subsections define registration "trees", distinguished by the use of faceted names (e.g., names of the form "tree.feature-name").
以下小节定义了注册“树”，通过使用刻面名称（例如“tree.feature name”形式的名称）进行区分。
The IETF tree is intended for media feature tags of general interest to the Internet Community, and proposals for these tags must meet the "IETF Consensus" policies described in [5].
IETF树用于互联网社区普遍感兴趣的媒体功能标签，这些标签的提案必须符合[5]中描述的“IETF共识”政策。
Registration in the IETF tree requires approval by the IESG and publication of the feature tag specification as an RFC. Submissions for feature tag registration in the IETF tree can originate in any WG of the IETF or as an individual submission to the IESG.
在IETF树中注册需要获得IESG的批准，并将功能标签规范作为RFC发布。IETF树中功能标签注册的提交可以来自IETF的任何工作组，也可以作为个人提交给IESG。
Feature tags in the IETF tree normally have names that are not explicitly faceted, i.e., do not contain period (".", full stop) characters.
IETF树中的特征标记通常具有未显式刻面的名称，即不包含句点（“.”，句号）字符。
Tags in the global tree will be distinguished by the leading facet "g.". An organization may propose either a designation indicative of the feature, (e.g., "g.blinktags") or a faceted designation including the organization name (e.g., "g.organization.blinktags"). Organizations which have registered media types under the MIME vendor tree should use the same organizational name for media feature tags if they propose a faceted designation. The acceptance of the proposed designation is at the discretion of the IANA. If the IANA believes that a designation needs clarification it may request a new proposal from the proposing organization or otherwise coordinate the development of an appropriate designation.
全局树中的标记将通过前面的刻面“g”来区分。一个组织可以提出一个指示特征的名称（例如，“g.blinktags”）或一个包含组织名称的刻面名称（例如，“g.organization.blinktags”）。已在MIME供应商树下注册了媒体类型的组织，如果建议使用刻面指定，则应为媒体功能标签使用相同的组织名称。IANA可自行决定是否接受提议的指定。如果IANA认为某项指定需要澄清，则可要求提议组织提交新的提案，或以其他方式协调制定适当的指定。
Registrations of feature tags in the global tree must meet the "Expert Review" policies described in [5]. In this case, a designated area expert will review the proposed tag, consulting with the members of a related mailing list. A registration may be proposed for the global tree by anyone who has the need to allow for communication on a particular capability or preference.
全局树中功能标签的注册必须符合[5]中所述的“专家评审”政策。在这种情况下，指定的区域专家将与相关邮件列表的成员协商，审查提议的标签。需要允许就特定能力或偏好进行通信的任何人都可以提议对全局树进行注册。
A feature tag may be defined as a URI using the restricted character set defined above. Feature tags in the URI tree are identified by the leading facet "u.". The leading facet u. is followed by a URI [9] which conforms to the character limitations specified in this
可以使用上面定义的受限字符集将特征标记定义为URI。URI树中的特征标记由前面的方面“u”标识。主要方面是美国。后跟一个URI[9]，它符合本节中指定的字符限制
document. The author of the URI is assumed to be registration authority regarding features defined and described by the content of the URI. These tags are considered unregistered for the purpose of this document.
文件就URI内容定义和描述的特性而言，假定URI的作者是注册机构。就本文件而言，这些标签被视为未注册。
From time to time and as required by the community, the IANA may, with the advice and consent of the IESG, create new top-level registration trees. These trees may be created for external registration and management by (for example) well-known permanent bodies, such as scientific societies for media feature types specific to the sciences they cover. Establishment of these new trees will be announced through RFC publication approved by the IESG.
根据社区的要求，IANA可不时在IESG的建议和同意下创建新的顶级注册树。这些树可以由（例如）知名的常设机构创建，以便进行外部注册和管理，例如，科学协会针对其所涵盖的科学的媒体专题类型。这些新树木的建立将通过IESG批准的RFC出版物宣布。
Feature tag registrations will be posted in the anonymous FTP directory: "ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/" and all registered feature tags will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC-1700]. The feature tag description and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@rfc-editor.org".
功能标签注册将发布在匿名FTP目录中：ftp://ftp.isi.edu/in-notes/iana/assignments/media-feature-tags/所有注册的特征标签将列在定期发布的“分配编号”RFC[目前为STD 2，RFC-1700]中。功能标签说明和其他支持材料也可以通过发送给“RFC”作为信息RFC发布-editor@rfc-编辑网”。
The IANA will only register feature tags in the IETF tree in response to a communication from the IESG stating that a given registration has been approved.
IANA将仅在IETF树中注册功能标签，以响应IESG发出的说明已批准给定注册的通信。
Global tags will be registered by the IANA after review by a designated expert. That review will serve to ensure that the tag meets the technical requirements of this specification.
IANA将在指定专家审查后对全球标签进行注册。该审查将用于确保标签符合本规范的技术要求。
To: media-feature-tags@apps.ietf.org (Media feature tags mailing list) Subject: Registration of media feature tag XXXX
至：媒体功能-tags@apps.ietf.org（媒体功能标签邮件列表）主题：注册媒体功能标签XXXX
| Instructions are preceded by `|'. Some fields are optional.
|说明前加“|”。有些字段是可选的。
Media feature tag name:
媒体功能标签名称：
ASN.1 identifier associated with feature tag: [optional]
与功能标签关联的ASN.1标识符：[可选]
| To have IANA assign an ASN.1 identifier, | use the value "New assignment by IANA" here.
|要让IANA分配ASN.1标识符，请在此处使用值“New assignment by IANA”。
Summary of the media feature indicated by this feature tag:
此功能标签指示的媒体功能摘要：
| Include a short (no longer than 4 lines) description or summary
| Examples:
| `Use of the xyzzy feature is indicated by ...'
| `Support of color display is indicated by ...'
| `Number of colors in a palette which can be defined ...'
| Include a short (no longer than 4 lines) description or summary
| Examples:
| `Use of the xyzzy feature is indicated by ...'
| `Support of color display is indicated by ...'
| `Number of colors in a palette which can be defined ...'
Values appropriate for use with this feature tag:
适用于此功能标记的值：
[ ] 1. The feature tag is Boolean and may have values of TRUE or FALSE. A value of TRUE indicates an available capability. A value of FALSE indicates the capability is not available.
[ ] 1. 要素标记为布尔值，其值可能为TRUE或FALSE。值TRUE表示可用的功能。值FALSE表示该功能不可用。
| If you wish to indicate two mutually exclusive possibilities
| that cannot be expressed as the availability or lack of a
| capability, use a two-token list, rather than a Boolean value.
| If you wish to indicate two mutually exclusive possibilities
| that cannot be expressed as the availability or lack of a
| capability, use a two-token list, rather than a Boolean value.
[ ] 2. The feature has an associated numeric or enumerated value.
[ ] 2. 特征具有关联的数值或枚举值。
For case 2: Indicate the data type of the value:
对于情况2：指示值的数据类型：
[ ] 2a. Signed Integer
[ ] 2b. Rational number
[ ] 2c. Token (equality relationship)
[ ] 2d. Token (ordered)
[ ] 2e. String (equality relationship)
[ ] 2f. String (defined comparison)
[ ] 2a. Signed Integer
[ ] 2b. Rational number
[ ] 2c. Token (equality relationship)
[ ] 2d. Token (ordered)
[ ] 2e. String (equality relationship)
[ ] 2f. String (defined comparison)
|IMPORTANT: You may only chose one of the above data types.
|重要提示：您只能选择上述数据类型之一。
(Only for case 2) Detailed description of the feature value meaning, and of the format and meaning of the feature tag values for the alternative results.
（仅适用于情况2）特征值含义的详细说明，以及替代结果的特征标记值的格式和含义。
| If you have selected 2d you must provide the ordering mechanism
| or a full and ordered enumeration of possible values. If you
| have selected 2f, you must provide a definition of the comparison.
| Definitions by included reference must be to stable and readily
| available specifications:
|
| If the number of alternative results is small, you may
| enumerate the identifiers of the different results and describe
| their meaning.
|
| If there is a limited useful numeric range of result (2b, 2c),
| If you have selected 2d you must provide the ordering mechanism
| or a full and ordered enumeration of possible values. If you
| have selected 2f, you must provide a definition of the comparison.
| Definitions by included reference must be to stable and readily
| available specifications:
|
| If the number of alternative results is small, you may
| enumerate the identifiers of the different results and describe
| their meaning.
|
| If there is a limited useful numeric range of result (2b, 2c),
| indicate the range.
|
| The identifiers of the alternative results could also be
| described by referring to another IANA registry, for example
| the paper sizes enumerated by the Printer MIB.
| indicate the range.
|
| The identifiers of the alternative results could also be
| described by referring to another IANA registry, for example
| the paper sizes enumerated by the Printer MIB.
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: [optional]
功能标签主要用于以下应用程序、协议、服务或协商机制：[可选]
| For applications, also specify the number of the first version | which will use the tag, if applicable.
|对于应用，还应指定将使用标签的第一个版本的编号（如适用）。
Examples of typical use: [optional]
典型使用示例：[可选]
Related standards or documents: [optional]
相关标准或文件：[可选]
Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: [optional]
在单个应用程序、协议、服务或协商机制中使用的特殊注意事项：[可选]
Interoperability considerations: [optional]
互操作性注意事项：[可选]
Security considerations:
安全考虑：
Privacy concerns, related to exposure of personal information:
与个人信息披露相关的隐私问题：
Denial of service concerns related to consequences of specifying incorrect values:
与指定错误值的后果相关的拒绝服务问题：
Other:
其他：
Additional information: [optional]
附加信息：[可选]
Keywords: [optional]
关键词：[可选]
Related feature tags: [optional]
相关功能标签：[可选]
Related media types or data formats: [optional]
相关媒体类型或数据格式：[可选]
Related markup tags: [optional]
相关标记标记：[可选]
Name(s) & email address(es) of person(s) to contact for further information:
欲了解更多信息，请联系人员的姓名和电子邮件地址：
Intended usage:
预期用途：
| one of COMMON, LIMITED USE or OBSOLETE
|通用的、有限使用的或过时的
Author/Change controller:
作者/变更控制员：
Requested IANA publication delay: [optional]
请求的IANA发布延迟：[可选]
| A delay may only be requested for final placement in the global
| or IETF trees, with a maximum of two months. Organizations
| requesting a registration with a publication delay should note
| that this delays only the official publication of the tag
| and does not prevent information on it from being disseminated
| by the members of the relevant mailing list.
| A delay may only be requested for final placement in the global
| or IETF trees, with a maximum of two months. Organizations
| requesting a registration with a publication delay should note
| that this delays only the official publication of the tag
| and does not prevent information on it from being disseminated
| by the members of the relevant mailing list.
Other information: [optional]
其他信息：[可选]
| Any other information that the author deems interesting may be | added here.
|作者认为有趣的任何其他信息可添加在此处。
4 Security Considerations
4安全考虑
Negotiation mechanisms reveal information about one party to other parties. This may raise privacy concerns, and may allow a malicious party to make better guesses about the presence of specific security holes.
谈判机制将一方的信息透露给另一方。这可能会引起隐私问题，并可能允许恶意方更好地猜测是否存在特定的安全漏洞。
5 Acknowledgments
5致谢
The details of the registration procedure in this document were directly adapted from [1]. Much of the text in section 3 was directly copied from this source.
本文件中的注册程序细节直接改编自[1]。第3节中的大部分文本都是直接从这个来源复制的。
The idea of creating a vocabulary of areas of media features, maintained in a central open registry, is due to discussions on extensible negotiation mechanisms [3] in the IETF HTTP working group.
创建媒体特性领域词汇表（保存在中央开放注册表中）的想法源于IETF HTTP工作组对可扩展协商机制[3]的讨论。
The authors wish to thank Larry Masinter, Graham Klyne, Al Gilman, Dan Wing, Jacob Palme, and Martin Duerst for their contributions to discussions about media feature tag registration.
作者要感谢拉里·马斯因特、格雷厄姆·克莱恩、阿尔·吉尔曼、丹·温、雅各布·帕尔姆和马丁·杜尔斯特，感谢他们对媒体专题标签注册讨论所作的贡献。
6 References
6参考文献
[1] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[1] Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[2] Klyne, G., "An algebra for describing media feature sets", Work in Progress.
[2] Klyne，G.“描述媒体功能集的代数”，正在进行中。
[3] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP. RFC 2295, March 1998.
[3] Holtman，K.和A.Mutz，“HTTP.RFC 2295中的透明内容协商”，1998年3月。
[4] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.
[4] Masinter，L.，Holtman，K.，Mutz，A.和D.Wing，“用于显示、打印和传真的媒体功能”，RFC 25341999年3月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Crocker, D., Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6] Crocker，D.，编辑，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[7] Fielding, R., Gettys, J., Mogul, J. Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[7] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[9] Berners-Lee, T., "Universal Resource Identifiers in WWW," RFC 1630, June 1994.
[9] Berners Lee，T.，“WWW中的通用资源标识符”，RFC1630，1994年6月。
7 Authors' Addresses
7作者地址
Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven The Netherlands
科恩霍尔曼技术大学埃因霍温邮政513卡默HG 6.57 5600 MB荷兰埃因霍温
EMail: koen@win.tue.nl
EMail: koen@win.tue.nl
Andrew H. Mutz Hewlett-Packard Company 11000 Wolfe Rd. 42UO Cupertino CA 95014 USA
美国加利福尼亚州库珀蒂诺42号沃尔夫路11000号安德鲁H.穆茨惠普公司95014
Fax +1 408 447 4439 EMail: andy_mutz@hp.com
传真+1408 447 4439电子邮件：andy_mutz@hp.com
Ted Hardie Equinix 901 Marshall Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市马歇尔街901号Ted Hardie Equinix 94063
EMail: hardie@equinix.com
EMail: hardie@equinix.com
8 Full Copyright Statement
8完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。