Internet Engineering Task Force (IETF) D. Cridland
Request for Comments: 6075 Isode Limited
Updates: 2244 December 2010
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Cridland
Request for Comments: 6075 Isode Limited
Updates: 2244 December 2010
Category: Standards Track
ISSN: 2070-1721
The Internet Assigned Number Authority (IANA) Application Configuration Access Protocol (ACAP) Vendor Subtrees Registry
Internet分配号码管理局（IANA）应用程序配置访问协议（ACAP）供应商子树注册表
Abstract
摘要
The original Application Configuration Access Protocol (ACAP) specification included a vendor registry now used in other protocols. This document updates the description of this registry, removing the need for a direct normative reference to ACAP and removing ambiguity.
最初的应用程序配置访问协议（ACAP）规范包括一个现在用于其他协议的供应商注册中心。本文件更新了该注册中心的描述，消除了对ACAP的直接规范性引用的需要，并消除了歧义。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6075.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6075.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. The Vendor Subtree Registry . . . . . . . . . . . . . . . . . . 3
3.1. Internationalization . . . . . . . . . . . . . . . . . . . 3
3.2. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Changes from RFC 2244 . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Example Registration . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. The Vendor Subtree Registry . . . . . . . . . . . . . . . . . . 3
3.1. Internationalization . . . . . . . . . . . . . . . . . . . 3
3.2. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Changes from RFC 2244 . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Example Registration . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
The [ACAP] specification includes the specification and creation of the ACAP Vendor Registry, and this registry has subsequently been reused by several specifications, including both [ANNOTATE] and [METADATA], and is proving to be a useful mechanism for namespacing various names to within a specific vendor's scope.
[ACAP]规范包括ACAP供应商注册中心的规范和创建，该注册中心随后被多个规范（包括[ANNOTATE]和[METADATA]）重用，并被证明是在特定供应商范围内为各种名称命名的有用机制。
The use of textual rather than numeric identifiers for vendors benefits engineers and operators who are diagnosing protocol problems by allowing them some possibility of identifying the origin of a vendor attribute without having to look it up in a registry (although that remains a necessary fallback). As such, engineers and operators already have to be familiar with international technical English to diagnose textual protocol problems, the restriction to ASCII may help and is not believed to harm that intended use. Exposure of vendor attributes directly in end-user user interfaces was not an intended use of the registry.
对供应商使用文本标识符而不是数字标识符有利于诊断协议问题的工程师和操作员，因为他们可以在不必在注册表中查找的情况下识别供应商属性的来源（尽管这仍然是一种必要的回退）。因此，工程师和操作员必须熟悉国际技术英语，才能诊断文本协议问题，对ASCII的限制可能会有所帮助，而且据信不会损害预期用途。直接在最终用户界面中公开供应商属性不是登记册的预期用途。
This document merely updates the registry to reduce ambiguity in the original specification and dissociates it from the original document in all but name, allowing easier referencing. It replaces Section 7.4 and portions of Section 4, particularly Section 4.3, of [ACAP].
本文档仅更新注册表，以减少原始规范中的歧义，并将其与原始文档（名称除外）分离，以便于引用。它取代了[ACAP]第7.4节和第4节的部分内容，特别是第4.3节。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
The formal syntax is to be considered normative and is specified using [ABNF]. Where a formal syntax and the prose are in conflict, the formal syntax takes precedence.
形式语法应视为规范性语法，并使用[ABNF]指定。当形式语法和散文冲突时，形式语法优先。
A Vendor Token is a UTF-8 string that begins with "vendor." and that is followed by the name of the company or product. This name MUST NOT contain any slash character, period, or the percent and asterisk characters typically used as wildcards.
供应商令牌是以“供应商”开头的UTF-8字符串，后跟公司或产品的名称。此名称不得包含任何斜杠字符、句点或通常用作通配符的百分比和星号字符。
Following this may be names, separated from the Vendor Token by a period, which need not be registered, thus forming a complete Vendor Name.
在此之后可能是名称，与供应商令牌之间以句点分隔，不需要注册，从而形成完整的供应商名称。
Vendor Tokens are able to contain any valid Unicode codepoint, encoded as [UTF-8], except the special characters. Since the publication of [ACAP], however, concerns have been raised on the handling and comparison of full Unicode strings; therefore, this specification restricts the current registrations to the ASCII subset of UTF-8.
供应商令牌可以包含任何有效的Unicode代码点，编码为[UTF-8]，特殊字符除外。然而，自[ACAP]发布以来，人们对完整Unicode字符串的处理和比较提出了担忧；因此，本规范将当前注册限制为UTF-8的ASCII子集。
Furthermore, characters such as ASCII control characters, most whitespace, and quotes are likely to be confusing and have been similarly restricted.
此外，ASCII控制字符、大多数空格和引号等字符可能会混淆，并且受到类似的限制。
Therefore, this document allows only ASCII letters, digits, the hyphen, and space to be used in registrations (the <iana-vendor-tag> ABNF production in Section 3.2).
因此，本文件仅允许在注册中使用ASCII字母、数字、连字符和空格（第3.2节中的<iana供应商标签>ABNF生产）。
At the time of publication of this document, no existing registrations violate the new restricted syntax on characters allowed in registrations. [ACAP] required all Vendor Tokens to be registered with IANA, so the new restriction is not believed to introduce any interoperability issue.
在本文档发布时，没有任何现有注册违反注册中允许的字符的新限制语法。[ACAP]要求所有供应商代币都必须向IANA注册，因此新的限制不会带来任何互操作性问题。
Finally, note that this document does not change the requirement on processors to accept other non-ASCII Unicode codepoints in Vendor Tokens (the <possible-vendor-tag> ABNF production in Section 3.2).
最后，请注意，本文件并未改变处理器接受供应商令牌中其他非ASCII Unicode代码点的要求（第3.2节中的<可能的供应商标签>ABNF生产）。
This syntax draws upon productions found within [ABNF] and [UTF-8]. Productions replace those in Section 4.3 of [ACAP].
此语法利用[ABNF]和[UTF-8]中的产品。产品将取代[ACAP]第4.3节中的产品。
vendor-name = vendor-token *("." name-component)
供应商名称=供应商令牌*（“”名称组件）
name-component = *(name-char / UTF8-2 / UTF8-3 / UTF8-4)
name-component = *(name-char / UTF8-2 / UTF8-3 / UTF8-4)
name-char = %x01-24 / %x26-29 / %x2B-2D / %x30-7F
;; ASCII-range characters not including ".",
;; "/", "%", or "*".
name-char = %x01-24 / %x26-29 / %x2B-2D / %x30-7F
;; ASCII-range characters not including ".",
;; "/", "%", or "*".
vendor-token = "vendor." vendor-tag ;; MUST be registered with IANA
供应商令牌=“供应商。”供应商标签；；必须在IANA注册
vendor-tag = iana-vendor-tag / possible-vendor-tag
vendor-tag = iana-vendor-tag / possible-vendor-tag
iana-vendor-tag = 1*(ALPHA / DIGIT / SP / "-")
;; This production represents
;; allowed forms for registrations
;; under the rules specified in this
;; document.
iana-vendor-tag = 1*(ALPHA / DIGIT / SP / "-")
;; This production represents
;; allowed forms for registrations
;; under the rules specified in this
;; document.
possible-vendor-tag = name-component
;; This production represents what
;; applications and specifications
;; MUST be able to accept.
possible-vendor-tag = name-component
;; This production represents what
;; applications and specifications
;; MUST be able to accept.
A company Example, Ltd. might register the Subtree "vendor.example". This means it may use "vendor.example", or any name at all beginning "vendor.example.", such as "vendor.example.product".
例如，company Ltd.可能会注册子树“vendor.Example”。这意味着它可以使用“vendor.example”，或在“vendor.example”开头的任何名称，例如“vendor.example.product”。
These names might be used in several protocols, and are reserved in all the relevant protocols, so "vendor.example" might be an ACAP [ACAP] dataset class name, and "/vendor/vendor.example" might be a tree of IMAP ANNOTATE entries [ANNOTATE].
这些名称可能在多个协议中使用，并在所有相关协议中保留，因此“vendor.example”可能是一个ACAP[ACAP]数据集类名，“/vendor/vendor.example”可能是一个IMAP注释项树[ANNOTATE]。
Example, Ltd. is free to use either "vendor.example", and group specific products under it using the relevant protocol's hierarchy -- perhaps "/shared/vendor/vendor.example/product" annotation [ANNOTATE], or using more specific names, such as "/shared/vendor/ vendor.example.product" annotation.
Example，Ltd.可以自由使用“vendor.Example”和其下的特定于组的产品，使用相关协议的层次结构——可能是“/shared/vendor/vendor.Example/product”注释[ANNOTATE]，或者使用更具体的名称，例如“/shared/vendor/vendor.Example.product”注释。
Note that the solidus ("/") characters in the examples above are protocol delimiters that are themselves not part of the Vendor Token.
请注意，上面示例中的solidus（“/”）字符是协议分隔符，它们本身不是供应商令牌的一部分。
This non-normative section details changes from the original specification of the registry in RFC 2244.
本非规范性章节详细说明了RFC 2244中注册中心原始规范的变更。
o Vendor Tokens are restricted to ASCII for registration purposes.
o 出于注册目的，供应商令牌仅限于ASCII。
o Clarifications that "vendor.<company/product name>" means "vendor.company name" or "vendor.product name" - "vendor.company/ product" is and always has been illegal.
o 澄清“供应商。<company/product name>”是指“vendor.company name”或“vendor.product name”——“vendor.company/product”是并且一直是非法的。
o Made "vendor.company" a name in its own right - RFC 2244 only refers to a prefix of "vendor.company.".
o 将“vendor.company”单独作为一个名称-RFC 2244仅指“vendor.company”的前缀。
o Added example registration, in line with [EXAMPLES].
o 根据[EXAMPLES]添加了示例注册。
This specification updates the IANA registry named the ACAP "Vendor Subtrees" registry. IANA has updated the registry to point at this document.
本规范更新了IANA注册中心ACAP“供应商子树”注册中心。IANA已更新注册表，指向此文档。
Vendors may reserve a portion of the ACAP namespace, which is also used as the namespace for several other protocols, for private use. Vendor Names are reserved for use by that company or product, wherever used, once registered. Registration is on a first come, first served basis. Whenever possible, private attributes and classes should be eschewed in favour of improving interoperable protocols.
供应商可以保留ACAP名称空间的一部分，该名称空间也用作其他几种协议的名称空间，以供私人使用。供应商名称保留供该公司或产品（无论在何处使用）在注册后使用。报名以先到先得方式进行。只要有可能，就应该避免使用私有属性和类，以改进可互操作的协议。
Vendors may only use names conforming to iana-vendor-tag at the current time; future revisions of this specification may change this.
供应商目前只能使用符合iana供应商标签的名称；本规范的未来版本可能会改变这一点。
To: iana@iana.org Subject: Registration of ACAP Vendor Subtree
致：iana@iana.org主题：注册ACAP供应商子树
Private Prefix: vendor.name
私有前缀：vendor.name
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
(company names and addresses should be included where appropriate)
（如适用，应包括公司名称和地址）
IANA is requested to add the following registration, for use by specification authors in examples, similarly to the domains specified in [EXAMPLES]:
请IANA添加以下注册，以供规范作者在示例中使用，类似于[示例]中指定的域：
To: iana@iana.org Subject: Registration of ACAP Vendor Subtree
致：iana@iana.org主题：注册ACAP供应商子树
Private Prefix: vendor.example
私有前缀：vendor.example
Person and email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Dave Cridland <dave.cridland@isode.com>
Dave Cridland <dave.cridland@isode.com>
There are no known security issues with this registry. Individual protocols using Vendor Subtree names may have security issues, and the introduction of Unicode has, in itself, security implications -- the restriction of this is thought to mitigate these.
此注册表没有已知的安全问题。使用供应商子树名称的单个协议可能会有安全问题，而Unicode的引入本身就有安全隐患——对此的限制被认为可以缓解这些问题。
Thanks must go to Chris Newman, John Myers, and the other designers of ACAP for the initial creation of the registry. Thanks also to Alexey Melnikov for advice on this revision.
感谢Chris Newman、John Myers和ACAP的其他设计师对注册中心的初步创建。还感谢Alexey Melnikov对本次修订的建议。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[ANNOTATE] Daboo, C. and R. Gellens, "Internet Message Access Protocol - ANNOTATE Extension", RFC 5257, June 2008.
[注释]Daboo，C.和R.Gellens，“互联网消息访问协议-注释扩展”，RFC 5257，2008年6月。
[EXAMPLES] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[示例]Eastlake 3rd，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[元数据]Daboo，C.，“IMAP元数据扩展”，RFC 54642009年2月。
Author's Address
作者地址
Dave Cridland Isode Limited 5 Castle Business Village 36, Station Road Hampton, Middlesex TW12 2BX GB
戴夫·克里德兰·伊索德有限公司位于米德尔塞克斯郡汉普顿车站路36号城堡商业村5号，邮编：TW12 2BX GB
EMail: dave.cridland@isode.com
EMail: dave.cridland@isode.com