Internet Engineering Task Force (IETF) A. Montville
Request for Comments: 7495 CIS
Category: Standards Track D. Black
ISSN: 2070-1721 EMC
March 2015
Internet Engineering Task Force (IETF) A. Montville
Request for Comments: 7495 CIS
Category: Standards Track D. Black
ISSN: 2070-1721 EMC
March 2015
Enumeration Reference Format for the Incident Object Description Exchange Format (IODEF)
事件对象描述交换格式（IODEF）的枚举参考格式
Abstract
摘要
The Incident Object Description Exchange Format (IODEF) is an XML data representation framework for sharing information about computer security incidents. In IODEF, the Reference class provides references to externally specified information such as a vulnerability, Intrusion Detection System (IDS) alert, malware sample, advisory, or attack technique. In practice, these references are based on external enumeration specifications that define both the enumeration format and the specific enumeration values, but the IODEF Reference class (as specified in IODEF v1 in RFC 5070) does not indicate how to include both of these important pieces of information.
事件对象描述交换格式（IODEF）是一种XML数据表示框架，用于共享有关计算机安全事件的信息。在IODEF中，引用类提供对外部指定信息的引用，例如漏洞、入侵检测系统（IDS）警报、恶意软件样本、建议或攻击技术。实际上，这些引用基于定义枚举格式和特定枚举值的外部枚举规范，但IODEF引用类（如RFC 5070中IODEF v1中所述）并未指示如何包含这两个重要信息。
This document establishes a stand-alone data format to include both the external specification and specific enumeration identification value, and establishes an IANA registry to manage external enumeration specifications. While this document does not update IODEF v1, this enumeration reference format is used in IODEF v2 and is applicable to other formats that support this class of enumeration references.
本文件建立了一个独立的数据格式，包括外部规范和特定枚举标识值，并建立了IANA注册中心来管理外部枚举规范。虽然本文档不更新IODEF v1，但IODEF v2中使用了此枚举引用格式，并适用于支持此类枚举引用的其他格式。
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/rfc7495.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7495.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 ....................................................3
1.1. Terminology ................................................3
2. Referencing External Enumerations ...............................3
2.1. Reference Name Format ......................................4
2.2. Reference Method Applicability .............................5
3. Security Considerations .........................................5
4. IANA Considerations .............................................6
5. The ReferenceName Schema ........................................8
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
1. Introduction ....................................................3
1.1. Terminology ................................................3
2. Referencing External Enumerations ...............................3
2.1. Reference Name Format ......................................4
2.2. Reference Method Applicability .............................5
3. Security Considerations .........................................5
4. IANA Considerations .............................................6
5. The ReferenceName Schema ........................................8
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
Acknowledgements ..................................................10
Authors' Addresses ................................................10
There is an identified need to specify a format to include relevant enumeration values from other data representation formats in an IODEF document. It is anticipated that this requirement will exist in other standardization efforts within several IETF Working Groups, but the scope of this document pertains solely to IODEF. This format is used in IODEF v2 [IODEFv2], which will replace the original IODEF v1 [IODEF] specification; this document does not specify use of this format in IODEF v1 [IODEF].
确定需要指定一种格式，以便在IODEF文档中包含来自其他数据表示格式的相关枚举值。预计该要求将存在于几个IETF工作组的其他标准化工作中，但本文件的范围仅适用于IODEF。IODEF v2[IODEFv2]中使用了此格式，它将取代原始的IODEF v1[IODEF]规范；本文档未指定在IODEF v1[IODEF]中使用此格式。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The need is to place enumeration identifiers and their enumeration format references in IODEF's Reference class. There are several ways to accomplish this goal, but the most appropriate at this point is to require a specific structure for the ReferenceName string of the IODEF Reference class, and use an IANA registry to manage references to specific enumeration reference formats.
需要将枚举标识符及其枚举格式引用放置在IODEF的引用类中。有几种方法可以实现这一目标，但此时最合适的方法是要求IODEF引用类的ReferenceName字符串具有特定的结构，并使用IANA注册表来管理对特定枚举引用格式的引用。
Per IODEF [IODEF], the ReferenceName is of type ML_STRING. This becomes problematic when specific references, especially enumeration formats such as Common Vulnerability Enumeration [CVE], Common Configuration Enumeration [CCE], Common Platform Enumeration [CPE], and so on, are referenced -- how is an implementer to know which type of reference this is, and thus how to parse it? One solution, presented here, is to require that ReferenceName follow a particular format.
根据IODEF[IODEF]，ReferenceName的类型为ML\u STRING。当引用特定引用时，尤其是引用诸如公共漏洞枚举[CVE]、公共配置枚举[CCE]、公共平台枚举[CPE]等枚举格式时，这就成了问题——实现者如何知道这是哪种类型的引用，从而如何解析它？这里介绍的一种解决方案是要求ReferenceName遵循特定的格式。
Inclusion of such enumeration values, especially those related to security automation, is important to incident communication and investigation. Typically, an enumeration identifier is simply an identifier with a specific format as defined by an external party. Further, that enumeration identifier is itself a reference to specific information associated with the identifier. Thus, the ReferenceName is an identifier that is formatted in a specific manner and that identifies some set of associated information.
包含此类枚举值，尤其是与安全自动化相关的枚举值，对于事件通信和调查非常重要。通常，枚举标识符只是具有外部方定义的特定格式的标识符。此外，该枚举标识符本身是对与该标识符相关联的特定信息的引用。因此，ReferenceName是一个标识符，它以特定的方式格式化，并标识一些相关信息集。
For example, a vulnerability identifier following the CVE [CVE] formatting specification may be CVE-2014-0001. That identifier is formatted in a specific manner and relates to information about a specific vulnerability. Communicating the format for the identifier is the subject of this document.
例如，遵循CVE[CVE]格式化规范的漏洞标识符可能是CVE-2014-0001。该标识符以特定方式格式化，并与特定漏洞的信息相关。传达标识符的格式是本文档的主题。
The ReferenceName class provides the XML representation for identifying an enumeration and specifying a value from it. A given enumeration is uniquely identified by the specIndex attribute. Each specIndex value corresponds to an entry in the "Enumeration Reference Type Identifiers" IANA registry (see Section 4). The child ID element represents a particular value from the corresponding enumeration identified by the specIndex attribute. The format of the ID element is described in the IANA registry entry of the enumeration.
ReferenceName类提供XML表示，用于标识枚举并从中指定值。给定的枚举由specIndex属性唯一标识。每个specIndex值对应于IANA注册表中的“枚举引用类型标识符”条目（见第4节）。子ID元素表示specIndex属性标识的相应枚举中的特定值。ID元素的格式在枚举的IANA注册表项中描述。
+-------------------------+
| ReferenceName |
+-------------------------+
| INTEGER specIndex |<>----------[ ID ]
+-------------------------+
+-------------------------+
| ReferenceName |
+-------------------------+
| INTEGER specIndex |<>----------[ ID ]
+-------------------------+
Figure 1: The ReferenceName Class
图1:ReferenceName类
The aggregate class that constitutes ReferenceName is:
构成ReferenceName的聚合类是：
ID One. The identifier assigned to represent the particular enumeration object being referenced.
我要一个。指定用于表示所引用的特定枚举对象的标识符。
The ReferenceName class has one attribute.
ReferenceName类有一个属性。
specIndex Required. INTEGER. Enumeration identifier. This value corresponds to an entry in the "Enumeration Reference Type Identifiers" IANA registry with an identical SpecIndex value.
需要指定索引。整数枚举标识符。该值对应于“枚举引用类型标识符”IANA注册表中具有相同SpecIndex值的条目。
An example of such a reference is as follows:
此类参考的示例如下所示：
<iodef:Reference>
<enum:ReferenceName specIndex="1">
<enum:ID>CXI-1234-XYZ</enum:ID>
</enum:ReferenceName>
<iodef:URL>http://cxi.example.com</iodef:URL>
<iodef:Description>Foo</iodef:Description>
</iodef:Reference>
<iodef:Reference>
<enum:ReferenceName specIndex="1">
<enum:ID>CXI-1234-XYZ</enum:ID>
</enum:ReferenceName>
<iodef:URL>http://cxi.example.com</iodef:URL>
<iodef:Description>Foo</iodef:Description>
</iodef:Reference>
Information in the IANA table (see Section 4) would include:
IANA表中的信息（见第4节）包括：
Full Name: Concept X Identifier
SpecIndex: 1
Version: any
Specification URI: http://cxi.example.com/spec_url
Full Name: Concept X Identifier
SpecIndex: 1
Version: any
Specification URI: http://cxi.example.com/spec_url
While the scope of this document pertains to IODEF, any standard needing to reference an enumeration identified by a specially formatted string can use this method of providing structure after the standard has been published. In effect, this method provides a standardized interface for enumeration formats, thus allowing a loose coupling between a given standard and the enumeration identifiers it needs to reference now and in the future.
虽然本文档的范围属于IODEF，但任何需要引用由特殊格式字符串标识的枚举的标准都可以在标准发布后使用这种提供结构的方法。实际上，该方法为枚举格式提供了一个标准化接口，从而允许给定标准和它现在和将来需要引用的枚举标识符之间存在松散耦合。
Ensuring a proper mapping of enumeration reference ID elements to the correct SpecIndex is important. Potential consequences of not mapping correctly include inaccurate information in references and similar distribution of misinformation.
确保枚举引用ID元素正确映射到正确的SpecIndex非常重要。未正确映射的潜在后果包括参考文献中的不准确信息和类似的错误信息分布。
Use of enumeration reference IDs from trusted sources is preferred to mitigate the risk of receiving and/or providing misinformation. Trust decisions with respect to enumeration reference providers are beyond the scope of this document. However, receiving an IODEF [IODEF] document containing an unknown ReferenceName (i.e., the SpecIndex does not exist in the IANA table) may indicate a misled or malicious source.
最好使用来自可信来源的枚举参考ID，以降低接收和/或提供错误信息的风险。有关枚举引用提供程序的信任决策超出了本文档的范围。但是，接收到包含未知ReferenceName的IODEF[IODEF]文档（即IANA表中不存在SpecIndex）可能表示错误或恶意源。
This document establishes a container for publicly available enumeration values to be included in an IODEF [IODEF] document, and it is important to note the distinction between the enumeration value's format and the information conveyed by the value itself. While the enumeration value may hold information deemed to be private by relying parties, the enumeration format is likely not subject to privacy concerns.
本文档为要包含在IODEF[IODEF]文档中的公共可用枚举值建立了一个容器，注意枚举值的格式和值本身传递的信息之间的区别非常重要。虽然枚举值可能包含依赖方认为是私有的信息，但枚举格式可能不受隐私问题的影响。
However, if the Reference class includes an enumeration value in combination with other data in an IODEF [IODEF] document, the resulting combination could expose information. An example might include attack vectors or system descriptions used in a privacy-related incident. As such, the reader is referred to the IODEF [IODEF] Security Considerations section, which explicitly covers protecting IODEF [IODEF] documents in transit and at rest, ensuring
但是，如果引用类在IODEF[IODEF]文档中包含与其他数据组合的枚举值，则生成的组合可能会公开信息。示例可能包括隐私相关事件中使用的攻击向量或系统描述。因此，读者可以参考IODEF[IODEF]安全注意事项部分，该部分明确介绍了在传输和静止时保护IODEF[IODEF]文档，以确保
proper recipient authentication, data confidence levels, underlying transport security characteristics, and proper use of IODEF's restriction attribute.
正确的收件人身份验证、数据置信度、基本传输安全特性以及IODEF限制属性的正确使用。
This document specifies an enumeration reference identifier format. All fields, including abbreviation, are mandatory.
本文档指定枚举引用标识符格式。所有字段（包括缩写）都是必填字段。
Per this document, IANA has created and maintains the following registry:
根据本文件，IANA创建并维护了以下注册表：
Name of the Registry: "Security External Enumeration Registry"
注册表名称：“安全外部枚举注册表”
Location of Registry: http://www.iana.org/assignments/sec-ext-enum
Location of Registry: http://www.iana.org/assignments/sec-ext-enum
Fields to record in the registry:
要在注册表中记录的字段：
Full Name: The full name of the enumeration (i.e., the referenced specification) as a string from the printable ASCII character set [RFC20] with individual embedded spaces allowed. The ABNF [RFC5234] syntax for this field is:
全名：枚举（即引用规范）的全名，作为可打印ASCII字符集[RFC20]中的字符串，允许使用单个嵌入空格。此字段的ABNF[RFC5234]语法为：
FULL-NAME = 1*VCHAR *(SP 1*VCHAR)
FULL-NAME = 1*VCHAR *(SP 1*VCHAR)
Abbreviation: An abbreviation may be an acronym -- it consists of uppercase characters (at least two). Uppercase is used to avoid mismatches due to case differences. It is specified by this ABNF [RFC5234] syntax:
缩写：缩写可以是首字母缩略词——它由大写字符（至少两个）组成。大写用于避免由于大小写差异而导致的不匹配。它由ABNF[RFC5234]语法指定：
ABBREVIATION = 2*UC-ALPHA ; At least two
UC-ALPHA = %x41-5A ; A-Z
ABBREVIATION = 2*UC-ALPHA ; At least two
UC-ALPHA = %x41-5A ; A-Z
Multiple registrations MAY use the same Abbreviation but MUST have different Versions.
多个注册可以使用相同的缩写，但必须有不同的版本。
SpecIndex: This is an IANA-assigned positive integer that identifies the registration. The first entry added to this registry uses the value 1, and this value is incremented for each subsequent entry added to the registry.
SpecIndex：这是一个IANA分配的正整数，用于标识注册。添加到此注册表的第一个条目使用值1，并且对于添加到此注册表的每个后续条目，该值都会递增。
Version: The version of the enumeration (i.e., the referenced specification) as a free-form string from the printable ASCII character set [RFC20] excepting white space, i.e., from VCHAR as defined in [RFC5234]. Some of the characters allowed in the version string are escaped when that string is used in XML
版本：枚举（即引用规范）的版本，作为可打印ASCII字符集[RFC20]中的自由格式字符串，空白除外，即[RFC5234]中定义的VCHAR中的自由格式字符串。在XML中使用版本字符串时，该字符串中允许的某些字符将被转义
documents (e.g., '<' is represented as <); the registered version string contains the unescaped ASCII character in all such cases.
文件（例如，“<”表示为<；）；在所有此类情况下，注册版本字符串都包含未转换的ASCII字符。
Specification URI/Reference: A list of one or more URIs [RFC3986] from which the registered specification can be obtained. The registered specification MUST be readily and publicly available from that URI. The URI SHOULD be a stable reference to a specific version of the specification. URIs that designate the latest version of a specification (which changes when a new version appears) SHOULD NOT be used.
规范URI/参考：一个或多个URI[RFC3986]的列表，从中可以获得注册的规范。注册的规范必须随时可从该URI公开获取。URI应该是对规范特定版本的稳定引用。不应使用指定规范最新版本（新版本出现时会发生更改）的URI。
Initial registry contents:
初始注册表内容：
Full Name: Common Vulnerabilities and Exposures
全称：常见漏洞和暴露
Abbreviation: CVE
缩写：CVE
SpecIndex: 1
指标：1
Version: 1.0
版本：1.0
Specification URI/Reference:
https://nvd.nist.gov/download.cfm#CVE_FEED
Specification URI/Reference:
https://nvd.nist.gov/download.cfm#CVE_FEED
Allocation Policy: Specification Required [RFC5226] (which implies Expert Review [RFC5226]).
分配政策：需要规范[RFC5226]（这意味着专家评审[RFC5226]）。
The Designated Expert is expected to consult with the MILE (Managed Incident Lightweight Exchange) working group or its successor if any such WG exists (e.g., via email to the working group's mailing list). The Designated Expert is expected to review the request and validate the appropriateness of the enumeration for the attribute. This review includes review of the specification associated with the request.
如果存在任何此类工作组，指定专家应咨询MILE（托管事件轻量交换）工作组或其继任者（例如，通过电子邮件发送至工作组的邮件列表）。指定专家应审查请求并验证属性枚举的适当性。该审查包括审查与请求相关的规范。
The Designated Expert is expected to ensure that the Full Name, Abbreviation, and Version are appropriate and that the information at the Specification URI is sufficient to unambiguously parse identifiers based on that specification. Additionally, the Designated Expert should prefer short Abbreviations over long ones.
指定专家应确保全名、缩写和版本适当，且规范URI中的信息足以明确解析基于该规范的标识符。此外，指定专家应优先选择短缩写而不是长缩写。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688].
本文档使用URN来描述符合[RFC3688]中描述的注册表机制的XML名称空间和XML模式。
Registration for the IODEF enumeration reference format namespace:
IODEF枚举引用格式命名空间的注册：
URI: urn:ietf:params:xml:ns:iodef-enum-1.0
URI: urn:ietf:params:xml:ns:iodef-enum-1.0
Registrant Contact: See the "Authors' Addresses" section of this document.
注册人联系人：请参阅本文件的“作者地址”部分。
XML: None.
XML：没有。
Registration for the IODEF enumeration reference format XML schema:
IODEF枚举引用格式XML架构的注册：
URI: urn:ietf:params:xml:schema:iodef-enum-1.0
URI: urn:ietf:params:xml:schema:iodef-enum-1.0
Registrant Contact: See the "Authors' Addresses" section of this document.
注册人联系人：请参阅本文件的“作者地址”部分。
XML: See Section 5, "The ReferenceName Schema", of this document.
XML：参见本文档第5节“ReferenceName模式”。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:iodef-enum-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:enum="urn:ietf:params:xml:ns:iodef-enum-1.0">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema attributeFormDefault="unqualified"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:iodef-enum-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:enum="urn:ietf:params:xml:ns:iodef-enum-1.0">
<!--
==========================================================
=== ReferenceName ===
==========================================================
-->
<xs:element name="ReferenceName">
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="xs:NCName"/>
</xs:sequence>
<xs:attribute name="specIndex"
type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
<!--
==========================================================
=== ReferenceName ===
==========================================================
-->
<xs:element name="ReferenceName">
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="xs:NCName"/>
</xs:sequence>
<xs:attribute name="specIndex"
type="xs:integer" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[IODEF] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007, <http://www.rfc-editor.org/info/rfc5070>.
[IODEF]Danyliw，R.，Meijer，J.，和Y.Demchenko，“事件对象描述交换格式”，RFC 50702007年12月<http://www.rfc-editor.org/info/rfc5070>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004, <http://www.rfc-editor.org/info/rfc3688>.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月<http://www.rfc-editor.org/info/rfc3688>.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[IODEFv2] Danyliw, R. and P. Stoecker, "The Incident Object Description Exchange Format v2", Work in Progress, draft-ietf-mile-rfc5070-bis-11, March 2015.
[IODEFv2]Danyliw，R.和P.Stoecker，“事故对象描述交换格式v2”，正在进行的工作，草案-ietf-mile-rfc5070-bis-11，2015年3月。
[CCE] The MITRE Corporation, "Common Configuration Enumeration (CCE): Unique Identifiers for Common System Configuration Issues", website in "Archive" status, <http://cce.mitre.org>.
[CCE]MITRE公司，“公共配置枚举（CCE）：公共系统配置问题的唯一标识符”，网站处于“存档”状态<http://cce.mitre.org>.
[CPE] The MITRE Corporation, "CPE - Common Platform Enumeration", website in "Archive" status, <http://cpe.mitre.org>.
[CPE]MITRE公司，“CPE-公共平台枚举”，网站处于“存档”状态<http://cpe.mitre.org>.
[CVE] The MITRE Corporation, "CVE - Common Vulnerabilities and Exposures", <http://cve.mitre.org>.
[CVE]MITRE公司，“CVE-常见漏洞和暴露”<http://cve.mitre.org>.
Acknowledgements
致谢
The authors would like to thank Eric Burger for the recommendation to rely on XML, Roman D. Danyliw for his schema contribution and insight, and Tim Bray, Panos Kampanakis, Barry Leiba, Ted Lemon, Alexey Melnikov, Kathleen Moriarty, Takeshi Takahashi, Henry S. Thompson, and David Waltermire for their contributions and reviews.
作者要感谢Eric Burger推荐使用XML，Roman D.Danyliw对模式的贡献和见解，以及Tim Bray、Panos Kampanakis、Barry Leiba、Ted Lemon、Alexey Melnikov、Kathleen Moriarty、Takeshi Takahashi、Henry S.Thompson和David Waltermier的贡献和评论。
Authors' Addresses
作者地址
Adam W. Montville
亚当·W·蒙特维尔
EMail: adam.w.montville@gmail.com
EMail: adam.w.montville@gmail.com
David Black EMC Corporation
大卫·布莱克EMC公司
EMail: david.black@emc.com
EMail: david.black@emc.com