Internet Engineering Task Force (IETF) C. Schmidt
Request for Comments: 8412 D. Haynes
Category: Standards Track C. Coffin
ISSN: 2070-1721 The MITRE Corporation
D. Waltermire
National Institute of Standards and Technology
J. Fitzgerald-McKay
United States National Security Agency
July 2018
Internet Engineering Task Force (IETF) C. Schmidt
Request for Comments: 8412 D. Haynes
Category: Standards Track C. Coffin
ISSN: 2070-1721 The MITRE Corporation
D. Waltermire
National Institute of Standards and Technology
J. Fitzgerald-McKay
United States National Security Agency
July 2018
Software Inventory Message and Attributes (SWIMA) for PA-TNC
PA-TNC的软件清单消息和属性（SWIMA）
Abstract
摘要
This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).
本文档扩展了“PA-TNC：与可信网络连接（TNC）兼容的姿态属性（PA）协议”（RFC 5792），提供了特定属性和消息交换，允许端点向NEA服务器报告其安装的软件清单信息，如“网络端点评估（NEA）：概述和要求”中所定义（RFC 5209）。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8412.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8412.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Network Endpoint Assessment (NEA) ..........................6
1.2. Conventions Used in This Document ..........................7
1.3. Definitions ................................................7
2. Background ......................................................8
2.1. Supported Use Cases ........................................8
2.1.1. Use Software Inventory as an Access Control Factor ..8
2.1.2. Central Stores of Up-to-Date Endpoint
Software Inventory Data .............................9
2.1.3. PA-TNC Use Cases ....................................9
2.2. Use Cases That Are Not Supported ...........................9
2.3. SWIMA Requirements ........................................10
2.4. Non-SWIMA Requirements ....................................11
2.5. Assumptions ...............................................12
2.6. Assumptions Not Made ......................................12
3. System Requirements ............................................12
3.1. Data Sources ..............................................13
3.2. Data Models ...............................................14
3.3. Basic Attribute Exchange ..................................16
3.4. Core Software-Reporting Information .......................17
3.4.1. Software Identifiers ...............................17
3.4.2. Data Model Type ....................................19
3.4.3. Record Identifiers .................................19
3.4.4. Software Locators ..................................20
3.4.5. Source Identifiers .................................21
3.4.6. Using Software and Record Identifiers in
SWIMA Attributes ...................................22
3.5. Targeted Requests .........................................22
3.6. Monitoring Changes in an Endpoint's Software
Inventory Evidence Collection .............................23
1. Introduction ....................................................4
1.1. Network Endpoint Assessment (NEA) ..........................6
1.2. Conventions Used in This Document ..........................7
1.3. Definitions ................................................7
2. Background ......................................................8
2.1. Supported Use Cases ........................................8
2.1.1. Use Software Inventory as an Access Control Factor ..8
2.1.2. Central Stores of Up-to-Date Endpoint
Software Inventory Data .............................9
2.1.3. PA-TNC Use Cases ....................................9
2.2. Use Cases That Are Not Supported ...........................9
2.3. SWIMA Requirements ........................................10
2.4. Non-SWIMA Requirements ....................................11
2.5. Assumptions ...............................................12
2.6. Assumptions Not Made ......................................12
3. System Requirements ............................................12
3.1. Data Sources ..............................................13
3.2. Data Models ...............................................14
3.3. Basic Attribute Exchange ..................................16
3.4. Core Software-Reporting Information .......................17
3.4.1. Software Identifiers ...............................17
3.4.2. Data Model Type ....................................19
3.4.3. Record Identifiers .................................19
3.4.4. Software Locators ..................................20
3.4.5. Source Identifiers .................................21
3.4.6. Using Software and Record Identifiers in
SWIMA Attributes ...................................22
3.5. Targeted Requests .........................................22
3.6. Monitoring Changes in an Endpoint's Software
Inventory Evidence Collection .............................23
3.7. Reporting Change Events ...................................26
3.7.1. Event Identifiers ..................................27
3.7.2. Core Event-Tracking Information ....................28
3.7.3. Updating Inventory Knowledge Based on Events .......29
3.7.4. Using Event Records in SWIMA Attributes ............29
3.7.5. Partial and Complete Lists of Event Records
in SWIMA Attributes ................................30
3.7.6. Synchronizing Event Identifiers and Epochs .........32
3.8. Subscriptions .............................................33
3.8.1. Establishing Subscriptions .........................34
3.8.2. Managing Subscriptions .............................35
3.8.3. Terminating Subscriptions ..........................36
3.8.4. Subscription Status ................................36
3.8.5. Fulfilling Subscriptions ...........................37
3.8.5.1. Subscriptions That Report Inventories .....38
3.8.5.2. Subscriptions That Report Events ..........38
3.8.5.3. Targeted Subscriptions ....................40
3.8.5.4. No Subscription Consolidation .............40
3.8.5.5. Delayed Subscription Fulfillment ..........41
3.9. Error Handling ............................................41
4. Protocol .......................................................43
4.1. Direct Response to a SWIMA Request ........................44
4.2. Subscription-Based Response ...............................45
4.3. Required Exchanges ........................................45
5. Software Inventory Messages and Attributes .....................46
5.1. PA Subtype (aka PA-TNC Component Type) ....................46
5.2. SWIMA Attribute Overview ..................................46
5.3. Message Diagram Syntax ....................................48
5.4. Normalization of Text Encoding ............................49
5.5. Request IDs ...............................................49
5.6. SWIMA Request .............................................50
5.7. Software Identifier Inventory .............................54
5.8. Software Identifier Events ................................58
5.9. Software Inventory ........................................64
5.10. Software Events ..........................................67
5.11. Subscription Status Request ..............................72
5.12. Subscription Status Response .............................73
5.13. Source Metadata Request ..................................75
5.14. Source Metadata Response .................................76
5.15. PA-TNC Error as Used by SWIMA ............................78
5.15.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and
SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information .....81
5.15.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information ........83
5.15.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information ..85
3.7. Reporting Change Events ...................................26
3.7.1. Event Identifiers ..................................27
3.7.2. Core Event-Tracking Information ....................28
3.7.3. Updating Inventory Knowledge Based on Events .......29
3.7.4. Using Event Records in SWIMA Attributes ............29
3.7.5. Partial and Complete Lists of Event Records
in SWIMA Attributes ................................30
3.7.6. Synchronizing Event Identifiers and Epochs .........32
3.8. Subscriptions .............................................33
3.8.1. Establishing Subscriptions .........................34
3.8.2. Managing Subscriptions .............................35
3.8.3. Terminating Subscriptions ..........................36
3.8.4. Subscription Status ................................36
3.8.5. Fulfilling Subscriptions ...........................37
3.8.5.1. Subscriptions That Report Inventories .....38
3.8.5.2. Subscriptions That Report Events ..........38
3.8.5.3. Targeted Subscriptions ....................40
3.8.5.4. No Subscription Consolidation .............40
3.8.5.5. Delayed Subscription Fulfillment ..........41
3.9. Error Handling ............................................41
4. Protocol .......................................................43
4.1. Direct Response to a SWIMA Request ........................44
4.2. Subscription-Based Response ...............................45
4.3. Required Exchanges ........................................45
5. Software Inventory Messages and Attributes .....................46
5.1. PA Subtype (aka PA-TNC Component Type) ....................46
5.2. SWIMA Attribute Overview ..................................46
5.3. Message Diagram Syntax ....................................48
5.4. Normalization of Text Encoding ............................49
5.5. Request IDs ...............................................49
5.6. SWIMA Request .............................................50
5.7. Software Identifier Inventory .............................54
5.8. Software Identifier Events ................................58
5.9. Software Inventory ........................................64
5.10. Software Events ..........................................67
5.11. Subscription Status Request ..............................72
5.12. Subscription Status Response .............................73
5.13. Source Metadata Request ..................................75
5.14. Source Metadata Response .................................76
5.15. PA-TNC Error as Used by SWIMA ............................78
5.15.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and
SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information .....81
5.15.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information ........83
5.15.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information ..85
6. Supported Data Models ..........................................87
6.1. ISO 2015 SWID Tags Using XML ..............................87
6.1.1. Guidance on Normalizing Source Data to ISO 2015
SWID Tags Using XML ................................87
6.1.2. Guidance on Creation of Software Identifiers from
ISO 2015 SWID Tags .................................88
6.2. ISO 2009 SWID Tags Using XML ..............................88
6.2.1. Guidance on Normalizing Source Data to ISO 2009
SWID Tags Using XML ................................88
6.2.2. Guidance on Creation of Software Identifiers from
ISO 2009 SWID Tags .................................89
7. Relationship to Other Specifications ...........................89
8. Security Considerations ........................................90
8.1. Evidentiary Value of Software Inventory Evidence Records ..90
8.2. Sensitivity of Collected Records ..........................91
8.3. Integrity of Endpoint Records .............................92
8.4. SWIMA-PC Access Permissions ...............................92
8.5. Sanitization of Record Fields .............................93
8.6. PA-TNC Security Threats ...................................93
9. Privacy Considerations .........................................93
10. IANA Considerations ...........................................94
10.1. Guidance for the Designated Experts ......................94
10.2. PA Subtypes ..............................................95
10.3. PA-TNC Attribute Types ...................................96
10.4. PA-TNC Error Codes .......................................97
10.5. Software Data Model Types ................................97
11. References ....................................................98
11.1. Normative References .....................................98
11.2. Informative References ...................................99
Authors' Addresses ...............................................101
6. Supported Data Models ..........................................87
6.1. ISO 2015 SWID Tags Using XML ..............................87
6.1.1. Guidance on Normalizing Source Data to ISO 2015
SWID Tags Using XML ................................87
6.1.2. Guidance on Creation of Software Identifiers from
ISO 2015 SWID Tags .................................88
6.2. ISO 2009 SWID Tags Using XML ..............................88
6.2.1. Guidance on Normalizing Source Data to ISO 2009
SWID Tags Using XML ................................88
6.2.2. Guidance on Creation of Software Identifiers from
ISO 2009 SWID Tags .................................89
7. Relationship to Other Specifications ...........................89
8. Security Considerations ........................................90
8.1. Evidentiary Value of Software Inventory Evidence Records ..90
8.2. Sensitivity of Collected Records ..........................91
8.3. Integrity of Endpoint Records .............................92
8.4. SWIMA-PC Access Permissions ...............................92
8.5. Sanitization of Record Fields .............................93
8.6. PA-TNC Security Threats ...................................93
9. Privacy Considerations .........................................93
10. IANA Considerations ...........................................94
10.1. Guidance for the Designated Experts ......................94
10.2. PA Subtypes ..............................................95
10.3. PA-TNC Attribute Types ...................................96
10.4. PA-TNC Error Codes .......................................97
10.5. Software Data Model Types ................................97
11. References ....................................................98
11.1. Normative References .....................................98
11.2. Informative References ...................................99
Authors' Addresses ...............................................101
Knowing the list of software installed on endpoints is useful to understand and maintain the security state of a network. For example, if an enterprise policy requires the presence of certain software and prohibits the presence of other software, reported software installation information can be used to indicate compliance and non-compliance with these requirements. Endpoint software installation inventory lists (hereinafter "software inventories") can further be used to determine an endpoint's exposure to attack based on comparison of vulnerability or threat alerts against identified software's patch-level data. These are some of the highly useful management use cases supported by software inventory data.
了解端点上安装的软件列表有助于了解和维护网络的安全状态。例如，如果企业策略要求存在某些软件并禁止存在其他软件，则报告的软件安装信息可用于指示是否符合这些要求。端点软件安装清单（以下简称“软件清单”）还可用于根据漏洞或威胁警报与已识别软件补丁级别数据的比较，确定端点的攻击风险。这些是软件清单数据支持的一些非常有用的管理用例。
Software Inventory Message and Attributes (SWIMA) for PA-TNC (see "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" [RFC5792]) provides a standardized method for exchanging software inventory data that includes a unique Software Identifier associated with a specific version of a software product. SWIMA can also convey metadata about software products beyond this identifier. SWIMA enables software identification, installation, and characterization information to be transported to a central server from any endpoint that supports this specification. Such information can come from multiple sources, including tag files (such as ISO Software Identification (SWID) tags [SWID15]), reports from third-party inventory tools, output from package managers, and other sources. SWIMA does not standardize how software is detected, instead relying on a set of "data sources" to provide information about installed software. SWIMA provides a flexible transport capable of conveying this information, regardless of how it is expressed.
PA-TNC的软件资源清册消息和属性（SWIMA）（请参阅“PA-TNC:与可信网络连接（TNC）兼容的姿态属性（PA）协议”[RFC5792]）提供了一种标准化的方法，用于交换软件资源清册数据，其中包括与软件产品特定版本相关联的唯一软件标识符。SWIMA还可以传递超出此标识符的软件产品元数据。SWIMA支持将软件标识、安装和特征化信息从支持此规范的任何端点传输到中央服务器。此类信息可以来自多个来源，包括标记文件（如ISO软件标识（SWID）标记[SWID15]）、来自第三方库存工具的报告、包管理器的输出以及其他来源。SWIMA没有标准化软件的检测方式，而是依赖一组“数据源”来提供有关已安装软件的信息。SWIMA提供了一种灵活的传输方式，能够传输此信息，而不管其表达方式如何。
This specification is designed to only report software that is installed on a target endpoint. In particular, it does not monitor or report information about what software is running on the endpoint. Likewise, it is not intended to report individual files, libraries, installation packages, or similar artifacts. While all of this information has its uses, this information requires different metadata and monitoring methods. As a result, this specification focuses solely on software inventory information, leaving the reporting of other classes of endpoint information to other specifications.
此规范旨在仅报告安装在目标端点上的软件。特别是，它不监视或报告有关端点上运行的软件的信息。同样，它也不打算报告单个文件、库、安装包或类似工件。虽然所有这些信息都有其用途，但这些信息需要不同的元数据和监视方法。因此，本规范仅关注软件清单信息，将其他类别的端点信息的报告留给其他规范。
Note that while this specification focuses on "software inventory", the mechanisms it describes could also be used to convey information about firmware and operating systems associated with an endpoint. The focus on software throughout this document should not be read as excluding the use of SWIMA for these other purposes.
请注意，虽然本规范侧重于“软件清单”，但它所描述的机制也可用于传递与端点相关联的固件和操作系统的信息。本文件中对软件的关注不应被理解为排除了将SWIMA用于这些其他目的。
This specification defines a new set of PA-TNC attributes; these attributes are used to communicate requests for software inventory information and software installation change events. The exchange of these messages allows software inventory information to be sent to a Network Endpoint Assessment (NEA) Server, which can make this information available to other applications.
本规范定义了一组新的PA-TNC属性；这些属性用于传递对软件清单信息和软件安装更改事件的请求。这些消息的交换允许将软件清单信息发送到网络端点评估（NEA）服务器，该服务器可将此信息提供给其他应用程序。
Part of the motivation for the development of SWIMA was to support the IETF's Security Automation and Continuous Monitoring (SACM) architecture. More details about SWIMA's role in SACM appear in Section 7. However, SWIMA has no dependencies on any part of SACM and is usable wherever the NEA architecture is employed.
开发SWIMA的部分动机是支持IETF的安全自动化和连续监控（SACM）架构。有关SWIMA在SACM中的角色的更多详细信息，请参见第7节。然而，SWIMA对SACM的任何部分都没有依赖性，并且在采用NEA架构的任何地方都可用。
SWIMA defines extensions to the PA-TNC specification [RFC5792]; these extensions are part of the NEA architecture. The NEA specifications define an open solution architecture that enables network operators to collect and utilize information about endpoint configuration and state. This information can be used to enforce policies and monitor endpoint health, among many other activities. Information about the software present on an endpoint is an important consideration for such activities. The new PA-TNC attributes defined in this document are used to communicate software inventory evidence, collected from a range of possible sources, from the Posture Collector on the endpoint to the Posture Validator on a NEA Server using the PA-TNC interface, as shown in Figure 1 below.
SWIMA定义了PA-TNC规范[RFC5792]的扩展；这些扩展是NEA体系结构的一部分。NEA规范定义了一种开放式解决方案体系结构，使网络运营商能够收集和利用有关端点配置和状态的信息。此信息可用于执行策略和监视端点运行状况以及许多其他活动。有关端点上存在的软件的信息是此类活动的重要考虑因素。本文档中定义的新PA-TNC属性用于使用PA-TNC接口将从一系列可能来源收集的软件清单证据从端点上的姿态收集器传递到NEA服务器上的姿态验证器，如下图1所示。
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
Figure 1: NEA Reference Model
图1:NEA参考模型
To better understand this specification, the reader should review the NEA reference architecture as described in "Network Endpoint Assessment (NEA): Overview and Requirements" [RFC5209]. The reader should also review the PA-TNC interfaces as defined in RFC 5792 [RFC5792].
为了更好地理解本规范，读者应查阅“网络端点评估（NEA）：概述和要求”[RFC5209]中所述的NEA参考体系结构。读者还应查看RFC 5792[RFC5792]中定义的PA-TNC接口。
This document is based on standards published by the Trusted Computing Group's Trusted Network Communications (TNC) workgroup (see <https://trustedcomputinggroup.org/>). The TNC and NEA architectures are interoperable, and many components are equivalent.
本文档基于可信计算组的可信网络通信（TNC）工作组发布的标准（参见<https://trustedcomputinggroup.org/>). TNC和NEA体系结构是互操作的，许多组件是等效的。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This section defines terms that have special meaning within this document.
本节定义了本文件中具有特殊含义的术语。
o SWIMA-PC - A NEA Posture Collector (PC) that interprets SWIMA attributes sent by SWIMA-PVs and that conforms to this specification. Note that such a Posture Collector might also support other PA-TNC exchanges beyond those defined herein.
o SWIMA-PC-解释SWIMA PVs发送的SWIMA属性并符合本规范的NEA姿态采集器（PC）。注意，这种姿势收集器还可以支持本文定义的那些之外的其他PA-TNC交换。
o SWIMA-PV - A NEA Posture Validator (PV) that interprets SWIMA attributes sent by SWIMA-PCs and that conforms to this specification. Note that such a Posture Validator might also support other PA-TNC exchanges beyond those defined herein.
o SWIMA-PV-一种NEA姿态验证器（PV），用于解释SWIMA PC发送的SWIMA属性，并符合本规范。请注意，这种姿势验证器还可能支持本文定义之外的其他PA-TNC交换。
o SWIMA Attribute - A PA-TNC attribute (as defined in RFC 5792 [RFC5792]) whose structure and behavior is defined in this specification.
o SWIMA属性-PA-TNC属性（如RFC 5792[RFC5792]中定义），其结构和行为在本规范中定义。
o Endpoint's Software Inventory Evidence Collection - The set of information regarding the set of software installed on an endpoint. An endpoint's Software Inventory Evidence Collection might include information created by or derived from multiple sources, including but not limited to SWID tag files deposited on the filesystem during software installation, information generated by software discovery tools, and information dynamically generated by a software or package management system on an endpoint.
o Endpoint的软件清单证据收集—有关安装在端点上的软件集的信息集。端点的软件清单证据收集可能包括由多个来源创建或派生的信息，包括但不限于软件安装期间存放在文件系统上的SWID标记文件、软件发现工具生成的信息，以及由端点上的软件或包管理系统动态生成的信息。
o Software Inventory Evidence Record - Part of the endpoint's Software Inventory Evidence Collection (which is composed of "records"). Each record corresponds to one installed instance of a particular software product as reported by some data source. It is possible for a single installed instance to have multiple
o 软件清单证据记录-端点软件清单证据收集的一部分（由“记录”组成）。每个记录对应于某个数据源报告的特定软件产品的一个已安装实例。单个已安装实例可能有多个
Software Inventory Evidence Records in an endpoint's Software Inventory Evidence Collection -- this can happen if multiple sources all report the same software installation instance.
端点的软件清单证据收集中的软件清单证据记录——如果多个源都报告相同的软件安装实例，则可能发生这种情况。
o Software Identifier - A string associated with a specific version of a specific software product. These identifiers are derived from the records used to describe software products. SWIMA does not limit the formats of these records, nor does it enforce that all data sources populate records using the same format. As such, while each Software Identifier uniquely identifies a specific software product, the same software product might be associated with multiple Software Identifiers reflecting differences between different data sources and supported record formats.
o 软件标识符-与特定软件产品的特定版本关联的字符串。这些标识符来自用于描述软件产品的记录。SWIMA不限制这些记录的格式，也不强制所有数据源使用相同的格式填充记录。因此，虽然每个软件标识符唯一地标识特定的软件产品，但同一软件产品可能与反映不同数据源和支持的记录格式之间差异的多个软件标识符相关联。
This section describes the use cases supported by this specification. The primary use of exchanging software inventory information over the PA-TNC interface is to enable a challenger (e.g., a NEA Server) to obtain inventory evidence about some system in a way that conforms to NEA procedures. Collected software information can support a range of security activities, including determining whether an endpoint is permitted to connect to the enterprise, determining which endpoints contain software that requires patching, and similar activities.
本节描述本规范支持的用例。通过PA-TNC接口交换软件清单信息的主要用途是使挑战者（如NEA服务器）能够以符合NEA程序的方式获取有关某个系统的清单证据。收集的软件信息可以支持一系列安全活动，包括确定是否允许端点连接到企业，确定哪些端点包含需要修补的软件，以及类似的活动。
Some enterprises might define security policies that require connected endpoints to have certain pieces of security software installed. By contrast, some security policies might prevent access to resources by endpoints that have certain prohibited pieces of software installed, since such applications might pose a security risk. To support such policies, the NEA Server needs to collect software inventory evidence from a target endpoint that is seeking to initiate or continue connectivity to the enterprise resource.
一些企业可能会定义安全策略，要求连接的端点安装某些安全软件。相比之下，一些安全策略可能会阻止安装了某些禁止的软件的端点访问资源，因为这样的应用程序可能会带来安全风险。为了支持此类策略，NEA服务器需要从正在寻求启动或继续连接到企业资源的目标端点收集软件清单证据。
Based on this specification, the SWIMA-PC can provide a complete or partial inventory to the SWIMA-PV as required to determine policy compliance. The SWIMA-PV can then use this as evidence of compliance or non-compliance to make a policy-based access decision.
根据本规范，SWIMA-PC可根据需要向SWIMA-PV提供完整或部分清单，以确定政策合规性。然后，SWIMA-PV可以将其作为合规或不合规的证据，以做出基于策略的访问决策。
Many tools use information about an endpoint's software inventory to monitor and enforce the security of a network. For example, a software-patching tool needs to determine if there is out-of-date software installed that needs to be updated. A vulnerability management tool needs to identify endpoints with known vulnerable software installed (patched or otherwise) to gauge an endpoint's relative exposure to attack. A license management tool needs to verify that all installed software within the enterprise is accounted for. A central repository representing an up-to-date understanding of each endpoint's software inventory facilitates these activities. Multiple tools can share such a repository, ensuring that software inventory information is collected more frequently and efficiently, leading to a more complete and consistent understanding of installed software state as compared to each tool collecting the same inventory information from endpoints individually.
许多工具使用有关端点软件清单的信息来监视和加强网络的安全性。例如，软件修补工具需要确定是否安装了需要更新的过期软件。漏洞管理工具需要识别已安装（修补或其他）已知易受攻击软件的端点，以评估端点的相对攻击风险。许可证管理工具需要验证企业中所有已安装的软件是否已入账。中央存储库表示对每个端点的软件库存的最新理解，有助于这些活动。多个工具可以共享这样一个存储库，确保更频繁、更高效地收集软件资源清册信息，与每个工具分别从端点收集相同的资源清册信息相比，可以更完整、更一致地了解已安装软件的状态。
This specification supports these activities through a number of mechanisms. As noted above, a SWIMA-PC can provide a complete list of software present in an endpoint's Software Inventory Evidence Collection to the SWIMA-PV, which can then pass this information on to a central repository, such as a Configuration Management Database (CMDB) or similar application. In addition, SWIMA-PCs are required to be able to monitor for changes to an endpoint's Software Inventory Evidence Collection in near real time and can be requested to immediately push reports of detected changes to the SWIMA-PV. Thus, any central repository fed by a SWIMA-PV receiving inventory information can be updated quickly after a change occurs. Keeping a central repository synchronized with current software inventory information in this way allows tools to make efficient decisions based on up-to-date, consistent information.
本规范通过多种机制支持这些活动。如上所述，SWIMA-PC可以向SWIMA-PV提供端点软件清单证据收集中存在的软件的完整列表，然后SWIMA-PV可以将此信息传递到中央存储库，如配置管理数据库（CMDB）或类似应用程序。此外，SWIMA PC需要能够近实时地监控端点软件清单证据收集的更改，并且可以被要求立即将检测到的更改报告推送到SWIMA-PV。因此，由接收库存信息的SWIMA-PV提供的任何中央存储库都可以在发生更改后快速更新。以这种方式使中央存储库与当前软件库存信息保持同步，使工具能够基于最新、一致的信息做出有效的决策。
SWIMA is intended to operate over the PA-TNC interface and, as such, is intended to meet the use cases set out in the PA-TNC specification.
SWIMA计划在PA-TNC接口上运行，因此，计划满足PA-TNC规范中规定的用例。
Some use cases not covered by this specification include:
本规范未涵盖的一些用例包括：
o Addressing how the endpoint's Software Inventory Evidence Collection is populated. In particular, NEA components are not expected to perform software discovery activities beyond compiling information in an endpoint's Software Inventory Evidence Collection. This collection might come from multiple sources on
o 解决端点的软件清单证据收集是如何填充的。特别是，除了编译端点的软件清单证据收集中的信息外，NEA组件不需要执行软件发现活动。此集合可能来自上的多个源
the endpoint (e.g., information generated dynamically by package management tools or discovery tools, as well as SWID tag files discovered on the filesystem). While an enterprise might make use of software discovery capabilities to identify installed software, such capabilities are outside the scope of this specification.
端点（例如，由包管理工具或发现工具动态生成的信息，以及在文件系统上发现的SWID标记文件）。虽然企业可以使用软件发现功能来识别已安装的软件，但此类功能不在本规范的范围内。
o Converting inventory information expressed in a proprietary format into formats used in the attributes described in this specification. Instead, this specification focuses exclusively on defining interfaces for the transportation of software information, expecting that reporting tools will converge around some set of standardized formats for this information.
o 将以专有格式表示的库存信息转换为本规范所述属性中使用的格式。相反，本规范专门关注于定义软件信息传输的接口，期望报告工具将围绕该信息的一些标准化格式集合。
o Mechanisms for a Posture Validator to request a specific list of software information based on arbitrary software properties. For example, requesting only information about software from a particular vendor is not supported. After the endpoint's Software Inventory Evidence Collection has been copied to some central location, such as the CMDB, processes there can perform queries based on any criteria present in the collected information, but this specification does not address using such queries to constrain the initial collection of this information from the endpoint.
o 姿态验证器基于任意软件属性请求特定软件信息列表的机制。例如，不支持仅向特定供应商请求有关软件的信息。端点的软件资源清册证据收集复制到某个中心位置（如CMDB）后，该位置的进程可以根据收集的信息中存在的任何条件执行查询，但本规范不涉及使用此类查询来约束从端点收集此信息的初始条件。
o Use of properties of certain sources of software information that might facilitate local tests (i.e., on the endpoint) of endpoint state. For example, the optional package_footprint field of an ISO SWID tag can contain a list of files and hash values associated with the software indicated by the tag. Tools on the endpoint can use the values in this field to test for the presence of the indicated files. Successful evaluation of such tests leads to greater assurance that the indicated software is present on the endpoint. Currently, most SWID tag creators do not provide values for tag fields that support local testing. For this reason, the added complexity of supporting endpoint testing using these fields is out of scope for this specification, but this topic may be considered in a future version.
o 使用某些软件信息源的属性，可能有助于端点状态的本地测试（即在端点上）。例如，ISO SWID标记的可选package_footprint字段可以包含与标记指示的软件相关联的文件和哈希值列表。端点上的工具可以使用此字段中的值来测试指示文件的存在。对此类测试的成功评估可以更好地确保端点上存在指定的软件。目前，大多数SWID标记创建者不为支持本地测试的标记字段提供值。因此，使用这些字段支持端点测试的额外复杂性超出了本规范的范围，但在未来版本中可能会考虑此主题。
Below are the requirements that SWIMA must meet in order to successfully play its role in the NEA architecture.
以下是SWIMA必须满足的要求，以成功发挥其在NEA体系结构中的作用。
Efficient: The NEA architecture enables delay of network access until the endpoint is determined not to pose a security threat to the network, based on its asserted integrity information. To minimize user frustration, SWIMA ought to minimize overhead delays and make PA-TNC communications as rapid and efficient as possible.
高效：NEA体系结构允许延迟网络访问，直到根据其断言的完整性信息确定端点不会对网络构成安全威胁。为了最大限度地减少用户的挫折感，SWIMA应该最大限度地减少开销延迟，并使PA-TNC通信尽可能快速高效。
Scalable: SWIMA needs to be usable in enterprises that contain tens of thousands of endpoints or more. As such, it needs to allow security tools to make decisions based on up-to-date information about an endpoint's software inventory without creating an excessive burden on the enterprise's network.
可扩展：SWIMA需要在包含数万个或更多端点的企业中可用。因此，它需要允许安全工具根据有关端点软件库存的最新信息做出决策，而不会对企业网络造成过度负担。
Support precise and complete historical reporting: This specification outlines capabilities that support real-time understanding of the state of endpoints in a network in a way that can be used by other tools. One means of facilitating such an outcome is for a CMDB to be able to contain information about all endpoints connected to the enterprise for all points in time between the endpoint's first connection and the present. In such a scenario, it is necessary that any SWIMA-PC be able to report any changes to its Software Inventory Evidence Collection in near real time while connected and, upon reconnection to the enterprise, be able to update the NEA Server (and, through it, the CMDB) with regard to the state of its Software Inventory Evidence Collection throughout the entire interval when it was not connected.
支持精确完整的历史报告：本规范概述了支持以其他工具可以使用的方式实时了解网络中端点状态的功能。促进这种结果的一种方法是，CMDB能够在端点的第一次连接和当前连接之间的所有时间点包含有关连接到企业的所有端点的信息。在这种情况下，任何SWIMA-PC都必须能够在连接时近实时报告其软件清单证据收集的任何更改，并且在重新连接到企业时，能够更新NEA服务器（以及通过它更新CMDB）关于其未连接时整个时间间隔内的软件清单证据收集状态。
There are certain capabilities that users of SWIMA might require but that are beyond the scope of SWIMA itself and need to be addressed by other standards.
SWIMA用户可能需要某些功能，但这些功能超出了SWIMA本身的范围，需要通过其他标准加以解决。
Confidentiality: SWIMA does not define a mechanism for confidentiality, nor is confidentiality automatically provided by using the PA-TNC interface. In the NEA architecture, confidentiality is generally provided by the underlying transport protocols, such as the PT binding to TLS [RFC6876] or PT-EAP (Posture Transport for Tunneled Extensible Authentication Protocol (EAP) Methods) [RFC7171]; see Section 7 for more information on related standards. The information conveyed by SWIMA is often sensitive in nature for both security (Section 8) and privacy (Section 9) reasons. Those who implement SWIMA need to ensure that appropriate NEA transport mechanisms are employed to meet confidentiality requirements.
保密性：SWIMA没有定义保密机制，也没有使用PA-TNC接口自动提供保密性。在NEA体系结构中，机密性通常由底层传输协议提供，例如与TLS的PT绑定[RFC6876]或PT-EAP（隧道可扩展认证协议（EAP）方法的姿态传输）[RFC7171]；有关相关标准的更多信息，请参见第7节。出于安全（第8节）和隐私（第9节）的原因，SWIMA传达的信息通常是敏感的。实施SWIMA的人需要确保采用适当的NEA传输机制，以满足保密要求。
The Posture Broker Client and Posture Broker Server are assumed to provide reliable delivery for PA-TNC messages and attributes sent between the SWIMA-PCs and the SWIMA-PVs. "Reliable delivery" means that either a message is delivered or the sender is made aware of the delivery failure. In the event that reliable delivery cannot be provided, some SWIMA features, primarily subscriptions, might not behave as expected.
假定姿态代理客户端和姿态代理服务器为在SWIMA PC和SWIMA PVs之间发送的PA-TNC消息和属性提供可靠的传递。“可靠传递”是指传递消息或让发送方知道传递失败。如果无法提供可靠的交付，某些SWIMA功能（主要是订阅）可能无法按预期运行。
This specification explicitly does not assume that software inventory information exchanges reflect the software installation state of the endpoint. This specification does not attempt to detect when the endpoint is providing false information, either through malice or error, but instead focuses on correctly and reliably providing the reported Software Inventory Evidence Collection to the NEA Server. Tools that employ the SWIMA standard can include methods to help verify the accuracy of reports, but how those tools do so is beyond the scope of this specification.
本规范明确不假设软件清单信息交换反映端点的软件安装状态。本规范不试图检测端点何时通过恶意或错误提供虚假信息，而是侧重于正确可靠地向NEA服务器提供报告的软件清单证据收集。采用SWIMA标准的工具可以包括有助于验证报告准确性的方法，但这些工具如何做到这一点超出了本规范的范围。
Similarly, this specification makes no assumption about the completeness of the Software Inventory Evidence Collection's coverage of the total set of software installed on the endpoint. It is possible, and even likely, that some installed software is not represented by a record in an endpoint's Software Inventory Evidence Collection. Instead, SWIMA ensures that what does get reported is reported consistently and that the software products that are reported can be reliably tracked.
同样，本规范不假设软件清单证据收集覆盖端点上安装的整套软件的完整性。端点的软件资源清册证据收集中的记录不代表某些已安装的软件，这是可能的，甚至是可能的。相反，SWIMA确保报告内容的一致性，以及报告的软件产品能够可靠地跟踪。
See Section 8 for more on this security consideration.
有关此安全考虑的更多信息，请参见第8节。
SWIMA facilitates the exchange of software inventory and event information. Specifically, each application supporting SWIMA includes a component known as the SWIMA-PC that receives SWIMA attributes. The SWIMA-PC is also responsible for sending appropriate SWIMA attributes back to the SWIMA-PV in response. This section outlines what software inventories and events are and the requirements on SWIMA-PCs and SWIMA-PVs in order to support the stated use cases of this specification.
SWIMA促进了软件清单和事件信息的交换。具体而言，每个支持SWIMA的应用程序都包括一个名为SWIMA-PC的组件，该组件接收SWIMA属性。SWIMA-PC还负责将适当的SWIMA属性发送回SWIMA-PV作为响应。本节概述了什么是软件清单和事件，以及对SWIMA PC和SWIMA PVs的要求，以支持本规范规定的用例。
The records in an endpoint's Software Inventory Evidence Collection come from one or more "sources". A source represents one collection of software inventory information about the endpoint. Examples of sources include, but are not limited to, ISO SWID tags deposited on the filesystem and collected therefrom, information derived from package managers, and the output of software inventory-scanning tools.
端点的软件清单证据收集中的记录来自一个或多个“来源”。源表示有关端点的软件清单信息的一个集合。源的示例包括但不限于存放在文件系统上并从中收集的ISO SWID标记、来自包管理器的信息以及软件清单扫描工具的输出。
There is no expectation that any one source of inventory information will have either perfect or complete software inventory information. For this reason, this specification supports the simultaneous use of multiple sources of software inventory information. Each source might have its own "sphere of expertise" and report the software within that sphere. For example, a package manager would have an excellent understanding of the software that it managed but would not necessarily have any information about software installed via other means.
不期望任何一个库存信息源都会有完美或完整的软件库存信息。因此，本规范支持同时使用多个软件清单信息源。每个来源可能有自己的“专业领域”，并报告该领域内的软件。例如，软件包经理对其管理的软件有很好的理解，但不一定有任何关于通过其他方式安装的软件的信息。
A SWIMA-PC is not required to utilize every possible source of software information on its endpoint. Some SWIMA-PCs might be explicitly tied only to one or a handful of software inventory sources, or a given SWIMA-PC could be designed to dynamically accommodate new sources. For all software inventory evidence sources that a particular SWIMA-PC supports, it MUST completely support all requirements of this specification with regard to those sources. A potential source that cannot support some set of required functionality (e.g., it is unable to monitor the software it reports for change events, as discussed in Section 3.6) MUST NOT be used as a source of endpoint software inventory information, even if it could provide some information. In other words, a source either supports full functionality as described in this specification or cannot be used at all. In the event that a previously used source becomes unavailable, this would be treated as a discontinuity in the SWIMA-PC's reporting. Section 3.7.1 describes how to use changes in the Event Identifier (EID) Epoch value to indicate a reporting discontinuity.
SWIMA-PC不需要利用其端点上所有可能的软件信息源。一些SWIMA PC可能只与一个或几个软件库存源明确绑定，或者一个给定的SWIMA-PC可以设计为动态适应新的源。对于特定SWIMA-PC支持的所有软件清单证据源，其必须完全支持本规范关于这些源的所有要求。不能支持某些所需功能集的潜在源（例如，如第3.6节所述，它无法监控其报告的软件更改事件）不得用作端点软件清单信息源，即使它可以提供一些信息。换句话说，源要么支持本规范中描述的全部功能，要么根本不能使用。如果以前使用的源变得不可用，这将被视为SWIMA-PC报告中的不连续性。第3.7.1节描述了如何使用事件标识符（EID）历元值的变化来指示报告的不连续性。
When sending information about installed software, the SWIMA-PC MUST include the complete set of relevant data from all supported sources of software inventory evidence. In other words, sources need to be used consistently. This is because if a particular source is included in an initial inventory but excluded from a later inventory, the SWIMA-PV receiving this information might reasonably conclude that the software reported by that source was no longer installed on the endpoint. As such, it is important that all supported sources be used every time the SWIMA-PC provides information to a SWIMA-PV.
发送有关已安装软件的信息时，SWIMA-PC必须包含来自所有受支持的软件清单证据来源的完整相关数据。换句话说，需要始终如一地使用资源。这是因为，如果某个特定源包含在初始清单中，但从以后的清单中排除，则接收到该信息的SWIMA-PV可能会合理地得出结论，即该源报告的软件不再安装在端点上。因此，每次SWIMA-PC向SWIMA-PV提供信息时，必须使用所有支持的源。
Note that if a SWIMA-PC collects data from multiple sources, it is possible that some software products might be "double counted". This can happen if two or more sources of inventory evidence provide a record for a single installation of a software product. When a SWIMA-PC reports information or records events from multiple inventory evidence sources, it MUST use the information those sources provide, rather than attempt to perform some form of reduction. In other words, if multiple sources report records corresponding to a single installation of a software product, all such records from each source are required to be part of the SWIMA-PC's processing even if this might lead to multiple reporting, and the SWIMA-PC is not to ignore some records to avoid such multiple reporting.
请注意，如果SWIMA-PC从多个来源收集数据，则某些软件产品可能“重复计数”。如果两个或多个库存证据来源为软件产品的单个安装提供了记录，则可能发生这种情况。当SWIMA-PC报告来自多个库存证据来源的信息或记录事件时，它必须使用这些来源提供的信息，而不是试图执行某种形式的减少。换句话说，如果多个来源报告与软件产品的单个安装相对应的记录，则来自每个来源的所有此类记录都必须成为SWIMA-PC处理的一部分，即使这可能导致多个报告，并且SWIMA-PC不得忽略某些记录以避免此类多个报告。
All inventory records reported by a SWIMA-PC include a Source Identifier linking them to a particular source. Source Identifiers are discussed more in Section 3.4.5. As discussed in that section, Source Identifiers can help consumers of SWIMA data identify cases of multiple reporting.
SWIMA-PC报告的所有库存记录都包含一个源标识符，将其链接到特定的源。第3.4.5节详细讨论了源标识符。如该节所述，源标识符可以帮助SWIMA数据的使用者识别多个报告的情况。
SWIMA conveys records about software presence from a SWIMA-PC to a SWIMA-PV. SWIMA does not manage the actual generation or collection of such records on the endpoint. As a result, information available to SWIMA-PCs might come in a variety of formats, and a SWIMA-PC could have little control over the format of the data made available to it. Because of this, SWIMA places no constraints on the format of these generated records and supports an open set of record formats by which installed software instances can be described. The following terms are used in this document:
SWIMA将软件存在的记录从SWIMA-PC传送到SWIMA-PV。SWIMA不管理端点上此类记录的实际生成或收集。因此，可供SWIMA PC使用的信息可能有多种格式，而SWIMA-PC对可供其使用的数据格式几乎没有控制权。因此，SWIMA对这些生成的记录的格式没有任何限制，并且支持一组开放的记录格式，通过这些格式可以描述已安装的软件实例。本文件中使用了以下术语：
o Data model - The format used to structure data within a given record. SWIMA does not constrain the data models it conveys.
o 数据模型-用于在给定记录中构造数据的格式。SWIMA不约束它传递的数据模型。
o Record - A populated instance of some data model that describes a software product.
o 记录-描述软件产品的某个数据模型的填充实例。
Do not confuse the "data model" described here with the structure of the SWIMA messages and attributes used to convey information between SWIMA-PVs and SWIMA-PCs. The SWIMA standard dictates the structure of its messages and attributes. Some attributes, however, have specific fields used to convey inventory records, and those fields support an extensible list of data models for their values. In other words, SWIMA data models provide an extension point within SWIMA attributes that allows the structure of inventory records to evolve.
请勿将此处描述的“数据模型”与用于在SWIMA PV和SWIMA-PC之间传递信息的SWIMA消息和属性的结构混淆。SWIMA标准规定了其消息和属性的结构。但是，有些属性具有用于传递库存记录的特定字段，这些字段支持其值的可扩展数据模型列表。换句话说，SWIMA数据模型在SWIMA属性中提供了一个扩展点，使库存记录的结构得以发展。
The data model used to structure software inventory information has very little impact on the behavior of the components defined in this specification. The SWIMA-PV has no dependency on the data model of records conveyed in SWIMA messages. For this reason, it MUST NOT reject a message or respond with a PA-TNC Error due to the data model used to structure records in attributes it receives. Similarly, it MUST NOT reject a message or respond with a PA-TNC Error if a record fails to comply with a stated format, unless that failure prevents correct parsing of the attribute itself. In short, the record bodies are effectively treated as "black boxes" by the SWIMA-PV. (Note that the SWIMA-PV might serve as the "front end" of other functionality that does have a dependency on the data model used to structure software information, but any such dependency is beyond the scope of this specification and needs to be addressed outside the behaviors specified in this document. This specification is only concerned with the collection and delivery of software inventory information; components that consume and use this information are a separate concern.)
用于构造软件清单信息的数据模型对本规范中定义的组件的行为几乎没有影响。SWIMA-PV不依赖于SWIMA消息中传输的记录的数据模型。因此，由于用于在其接收的属性中构造记录的数据模型，它不得拒绝消息或响应PA-TNC错误。类似地，如果记录不符合规定的格式，则它不得拒绝消息或响应PA-TNC错误，除非该错误阻止正确解析属性本身。简言之，SWIMA-PV将记录主体有效地视为“黑匣子”。（请注意，SWIMA-PV可作为“前端”对用于构建软件信息的数据模型具有依赖性的其他功能，但任何此类依赖性都超出了本规范的范围，需要在本文档中指定的行为之外解决。本规范仅涉及软件清单信息的收集和交付信息；使用此信息的组件是一个单独的关注点。）
The SWIMA-PC does have one functional dependency on the data models used in the software records it delivers, but only insofar as it is required to deterministically create a Software Identifier (described in Section 3.4.1) based on each record it delivers. The SWIMA-PC MUST be able to generate a Software Identifier for each record it delivers, and if the SWIMA-PC cannot do so, it cannot deliver the record. All SWIMA-PCs MUST at least be able to generate Software Identifiers for the data model types specified in Section 6 of this document. A SWIMA-PC MAY include the ability to generate Software Identifiers for other data model types and thus be able to support them as well.
SWIMA-PC对其交付的软件记录中使用的数据模型有一个功能依赖性，但仅限于根据其交付的每个记录确定创建软件标识符（如第3.4.1节所述）。SWIMA-PC必须能够为其提供的每个记录生成软件标识符，如果SWIMA-PC不能这样做，则不能提供该记录。所有SWIMA PC必须至少能够为本文件第6节规定的数据模型类型生成软件标识符。SWIMA-PC可以包括为其他数据模型类型生成软件标识符的能力，因此也能够支持它们。
In the most basic exchange supported by this specification, a SWIMA-PV sends a request to the SWIMA-PC, requesting some type of information about the endpoint's software inventory. This simple exchange is shown in Figure 2.
在本规范支持的最基本的交换中，SWIMA-PV向SWIMA-PC发送请求，请求有关端点软件清单的某种类型的信息。这个简单的交换如图2所示。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<------------SWIMA Request---------------| |
| | |
|-------------SWIMA Response------------->| |
| | V
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<------------SWIMA Request---------------| |
| | |
|-------------SWIMA Response------------->| |
| | V
Figure 2: Basic SWIMA Attribute Exchange
图2：基本SWIMA属性交换
Upon receiving such a SWIMA Request from the SWIMA-PV, the SWIMA-PC is expected to collect all the relevant software inventory information from the endpoint's Software Inventory Evidence Collection and place it within its response attribute.
收到来自SWIMA-PV的此类SWIMA请求后，SWIMA-PC将从端点的软件清单证据收集中收集所有相关软件清单信息，并将其置于其响应属性中。
SWIMA-PVs MUST discard, without error, any SWIMA Response attributes that they receive for which they do not know the SWIMA Request parameters that led to this SWIMA Response. This is due to the fact that the SWIMA Request includes parameters that control the nature of the response (as will be described in the following sections); without knowing those parameters, the SWIMA Response cannot be reliably interpreted. Each SWIMA Request includes a Request ID, which is echoed in any SWIMA Response to that request and allows matching of responses to requests. See Section 5.5 for more on Request IDs. Receiving an unsolicited SWIMA Response attribute will most often happen when a NEA Server has multiple SWIMA-PVs; one SWIMA-PV sends a SWIMA Request, but unless exclusive delivery [RFC5793] is set by the sender and honored by the recipient, multiple SWIMA-PVs will receive copies of the resulting SWIMA Response. In this case, the SWIMA-PV that didn't send the SWIMA Request would lack the context necessary to correctly interpret the SWIMA Response it received and would simply discard it. Note, however, that proprietary measures might allow a SWIMA-PV to discover the SWIMA Request parameters for a SWIMA Response even if that SWIMA-PV did not send the given SWIMA Request. As such, there is no blanket requirement for a SWIMA-PV to discard all SWIMA Responses to SWIMA Requests that the SWIMA-PV did not generate itself -- only that SWIMA-PVs are required to discard SWIMA Responses for which they cannot get the necessary context to interpret.
SWIMA PV必须毫无错误地丢弃其接收的任何SWIMA响应属性，因为它们不知道导致此SWIMA响应的SWIMA请求参数。这是因为SWIMA请求包括控制响应性质的参数（将在以下章节中描述）；如果不知道这些参数，就无法可靠地解释SWIMA响应。每个SWIMA请求都包含一个请求ID，该ID在对该请求的任何SWIMA响应中都会回显，并允许对请求的响应进行匹配。有关请求ID的更多信息，请参见第5.5节。当NEA服务器具有多个SWIMA PV时，接收未经请求的SWIMA响应属性最常见；一个SWIMA-PV发送一个SWIMA请求，但除非发送方设置了独占传递[RFC5793]并由接收方遵守，否则多个SWIMA PV将接收结果SWIMA响应的副本。在这种情况下，未发送SWIMA请求的SWIMA-PV将缺少正确解释其接收到的SWIMA响应所需的上下文，并将直接丢弃它。然而，请注意，专有措施可能允许SWIMA-PV发现SWIMA响应的SWIMA请求参数，即使该SWIMA-PV未发送给定的SWIMA请求。因此，不要求SWIMA-PV放弃对SWIMA-PV自身未生成的SWIMA请求的所有SWIMA响应——只要求SWIMA PV放弃其无法获得必要上下文解释的SWIMA响应。
In the case that it is possible to do so, the SWIMA-PC SHOULD send its SWIMA Response attribute to the SWIMA-PV that requested it, using exclusive delivery as described in Section 4.5 of "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)" [RFC5793]. Exclusive delivery requests that only the sender of the SWIMA Request be the receiver of the resulting SWIMA Response. Note, however, that PB-TNC does not require the recipient to honor the exclusive delivery flag in messages that it receives, so setting the flag cannot be guaranteed to prevent a SWIMA-PV from receiving unsolicited SWIMA Responses.
在可能的情况下，SWIMA-PC应使用“PB-TNC：与可信网络连接（TNC）兼容的姿态代理（PB）协议”[RFC5793]第4.5节中所述的独家交付，将其SWIMA响应属性发送给请求它的SWIMA-PV。独占传递请求，即只有SWIMA请求的发送方是生成的SWIMA响应的接收方。但是，请注意，PB-TNC不要求收件人在其接收的邮件中遵守独占传递标志，因此无法保证设置该标志以防止SWIMA-PV接收未经请求的SWIMA响应。
Note that, in the case that a single endpoint hosts multiple SWIMA-PCs, a single SWIMA Request could result in multiple SWIMA Responses. SWIMA-PVs need to handle such an occurrence without error.
请注意，在单个端点承载多台SWIMA PC的情况下，单个SWIMA请求可能会导致多个SWIMA响应。SWIMA PV需要无误地处理此类事件。
All numeric values sent in SWIMA messages are sent in network (big endian) byte order.
SWIMA消息中发送的所有数值均以网络（大端）字节顺序发送。
Different parameters in the SWIMA Request can influence what information is returned in the SWIMA Response. However, while each SWIMA Response provides different additional information about this installed software, the responses all share a common set of fields that support reliable software identification on an endpoint. These fields include Software Identifiers, Data Model Type, Record Identifiers, Software Locators, and Source Identifiers. These fields are present for each reported piece of software in each type of SWIMA Response. The following sections examine these information types in more detail.
SWIMA请求中的不同参数会影响SWIMA响应中返回的信息。但是，尽管每个SWIMA响应提供了有关此已安装软件的不同附加信息，但所有响应都共享一组公共字段，这些字段支持端点上的可靠软件标识。这些字段包括软件标识符、数据模型类型、记录标识符、软件定位器和源标识符。在每种类型的SWIMA响应中，每个报告的软件都有这些字段。以下各节将更详细地研究这些信息类型。
A Software Identifier uniquely identifies a specific version of a specific software product. The SWIMA standard does not dictate the structure of a Software Identifier (beyond stating that it is a string) or define how it is created. Instead, each data model described in the "Software Data Model Types" registry (Section 10.5) includes its own rules for how a Software Identifier is created based on a record in the endpoint's Software Inventory Evidence Collection expressed in that data model. Other data models will have their own procedures for the creation of associated Software Identifiers. Within SWIMA, the Software Identifier is simply an opaque string, and there is never any need to unpack any information that might be part of that identifier.
软件标识符唯一标识特定软件产品的特定版本。SWIMA标准没有规定软件标识符的结构（除了说明它是字符串之外），也没有定义如何创建它。相反，“软件数据模型类型”注册表（第10.5节）中描述的每个数据模型都包含其自己的规则，用于根据端点的软件清单证据集合中的记录创建软件标识符，该记录在该数据模型中表示。其他数据模型将有自己的程序来创建相关的软件标识符。在SWIMA中，软件标识符只是一个不透明的字符串，不需要解压缩任何可能是该标识符一部分的信息。
A Software Identifier is a fraction of the size of the inventory record from which it is derived. For this reason, it is often more efficient to collect full inventories using Software Identifiers and only collect full records when necessary using targeted requests. For some combinations of data models and sources, the full record might never be necessary, as the identifier can be directly correlated to the contents of the full record. This is possible with authoritative SWID tags, since these tags always have the same contents and thus a Software Identifier derived from these tags can be used as a lookup to a local copy of the full tag. For other combinations of source and data model, a server might not be able to determine the specific software product and version associated with the identifier without requesting the delivery of the full record. However, even in those cases, downstream consumers of this information might never need the full record as long as the Software Identifiers they receive can be tracked reliably. A SWIMA-PV can use Software Identifiers to track the presence of specific software products on an endpoint over time in a bandwidth-efficient manner.
软件标识符是从中派生的库存记录大小的一小部分。因此，使用软件标识符收集完整的库存通常更有效，并且仅在必要时使用目标请求收集完整记录。对于数据模型和源的某些组合，可能永远不需要完整记录，因为标识符可以直接与完整记录的内容相关。这在权威SWID标记中是可能的，因为这些标记始终具有相同的内容，因此从这些标记派生的软件标识符可用于查找完整标记的本地副本。对于源和数据模型的其他组合，服务器可能无法在不请求交付完整记录的情况下确定与标识符关联的特定软件产品和版本。然而，即使在这些情况下，只要能够可靠地跟踪这些信息的下游消费者接收到的软件标识符，他们也可能永远不需要完整的记录。SWIMA-PV可以使用软件标识符以带宽效率高的方式跟踪端点上特定软件产品随时间的存在。
There are two important limitations of Software Identifiers to keep in mind:
要记住软件标识符的两个重要限制：
1. The identifiers do not necessarily change when the associated record changes. In some situations, a record in the endpoint's Software Inventory Evidence Collection will change due to new information becoming available or in order to correct prior errors in that information. Such changes might or might not result in changes to the Software Identifier, depending on the nature of the changes and the rules governing how Software Identifiers are derived from records of the appropriate data model.
1. 当相关记录更改时，标识符不一定会更改。在某些情况下，端点的软件清单证据收集中的记录将因新信息可用或为了更正该信息中以前的错误而更改。这些更改可能会或可能不会导致软件标识符的更改，这取决于更改的性质以及管理如何从适当数据模型的记录中派生软件标识符的规则。
2. It is possible that a single software product is installed on a single endpoint multiple times. If these multiple installation instances are reported by the same source using the same data format, then this can result in identical Software Identifiers for both installation instances. In other words, Software Identifiers might not uniquely identify installation instances; they are just intended to uniquely identify software products (which might have more than one installation instance). Instead, to reliably distinguish between multiple instances of a single software product, one needs to make use of Record Identifiers as described in Section 3.4.3.
2. 单个软件产品可能多次安装在单个端点上。如果同一源使用相同的数据格式报告这些多个安装实例，则这可能会导致两个安装实例的软件标识符相同。换句话说，软件标识符可能无法唯一标识安装实例；它们只是用于唯一标识软件产品（可能有多个安装实例）。相反，为了可靠地区分单个软件产品的多个实例，需要使用第3.4.3节中描述的记录标识符。
The Data Model Type consists of two fields: Data Model Type PEN and Data Model Type. ("PEN" stands for "Private Enterprise Number".) The combination of these fields is used to identify the type of data model of the associated software inventory record. The data model is significant not only because it informs the recipient of the data model of the associated record but also because the process for generating the Software Identifier for the record depends on the record's data model. Clearly identifying the type of data model from which the Software Identifier was derived thus provides useful context for that value.
数据模型类型包括两个字段：数据模型类型PEN和数据模型类型。（“PEN”代表“私有企业编号”。）这些字段的组合用于标识相关软件库存记录的数据模型类型。数据模型之所以重要，不仅因为它将相关记录的数据模型通知接收者，还因为为记录生成软件标识符的过程取决于记录的数据模型。因此，清楚地识别从中派生软件标识符的数据模型类型为该值提供了有用的上下文。
The PEN identifies the organization that assigns meaning to the Data Model Type field value. PENs are managed by IANA in the "Private Enterprise Numbers" registry. PENs allow vendors to designate their own set of data models for software inventory description. IANA reserves the PEN of 0x000000. Data Model Types associated with this PEN are defined in the "Software Data Model Types" registry; see Section 10.5 of this specification. Note that this IANA table reserves all values greater than or equal to 0xC0 (192) for local enterprise use. This means that local enterprises can use custom data formats and indicate them with the IANA PEN and a Data Model Type value between 0xC0 and 0xFF, inclusive. Those enterprises are responsible for configuring their SWIMA-PCs to correctly report those custom data models.
PEN标识为数据模型类型字段值赋予意义的组织。PEN由IANA在“私人企业编号”登记处管理。PENs允许供应商为软件清单描述指定自己的数据模型集。IANA保留0x000000的PEN。与此笔关联的数据模型类型在“软件数据模型类型”注册表中定义；见本规范第10.5节。请注意，此IANA表保留所有大于或等于0xC0（192）的值供本地企业使用。这意味着本地企业可以使用自定义数据格式，并使用IANA笔和介于0xC0和0xFF（包括0xC0和0xFF）之间的数据模型类型值来指示它们。这些企业负责配置其SWIMA PC以正确报告这些自定义数据模型。
A Record Identifier is a 4-byte unsigned integer that is generated by the SWIMA-PC and is uniquely associated with a specific record within the endpoint's Software Inventory Evidence Collection. The SWIMA-PC MUST assign a unique identifier to each record when it is added to the endpoint's Software Inventory Evidence Collection. The Record Identifier SHOULD remain unchanged if that record is modified. However, it is recognized that, in some circumstances, record modification might be hard to distinguish from record deletion followed by creation of a new record. For this reason, retaining a constant Record Identifier across a record modification is recommended but not required. Similarly, in the case that the software product associated with a record is moved, ideally the Record Identifier for the record of the moved software will remain unchanged, reflecting that it represents the same software product instance, albeit in a new location. However, this level of tracking could prove difficult to achieve and is not required. The SWIMA-PC might wish to assign Record Identifiers sequentially, but any scheme is acceptable, provided that no two records receive the same identifier.
记录标识符是由SWIMA-PC生成的4字节无符号整数，它与端点的软件清单证据集合中的特定记录唯一关联。在将每条记录添加到端点的软件清单证据收集时，SWIMA-PC必须为每条记录分配一个唯一标识符。如果记录被修改，记录标识符应保持不变。然而，人们认识到，在某些情况下，记录修改可能很难与随后创建新记录的记录删除区分开来。因此，建议在记录修改过程中保留一个常量记录标识符，但不是必需的。类似地，在与记录相关联的软件产品被移动的情况下，理想情况下，被移动软件的记录的记录标识符将保持不变，反映出它代表相同的软件产品实例，尽管在新的位置。然而，这一级别的跟踪可能很难实现，并且不是必需的。SWIMA-PC可能希望按顺序分配记录标识符，但任何方案都可以接受，前提是没有两个记录接收到相同的标识符。
Servers can use Record Identifiers to distinguish between multiple instances of a single software product installed on an endpoint. Since each installation instance of a software product is associated with a separate record, servers can use the Record Identifier to distinguish between instances. For example, if an event is reported (as described in Section 3.7), the Record Identifier will allow the server to discern which instance of a software product is involved.
服务器可以使用记录标识符来区分安装在端点上的单个软件产品的多个实例。由于软件产品的每个安装实例都与单独的记录相关联，服务器可以使用记录标识符来区分实例。例如，如果报告了一个事件（如第3.7节所述），记录标识符将允许服务器识别涉及软件产品的哪个实例。
In addition to the need to identify what software products are on an endpoint, some processes that use inventory information also need to know where software is located on the endpoint. This information might be needed to direct remediation actions or similar processes. For this reason, every reported software product also includes a Software Locator to identify where the software is installed on the endpoint.
除了需要识别端点上有哪些软件产品外，一些使用清单信息的流程还需要知道软件在端点上的位置。可能需要这些信息来指导补救行动或类似过程。因此，每个报告的软件产品还包括一个软件定位器，用于识别端点上软件的安装位置。
If the location is not provided directly by the data source, the SWIMA-PC is responsible for attempting to determine the location of the software product. The "location" of a product SHOULD be the directory in which the software product's executables are kept. The SWIMA-PC MUST be consistent in reporting the location of a software product. In other words, assuming that a software product has not moved, the SWIMA-PC cannot use one location in one report and a different location for the same software product in another. (If a software product has moved, the Software Locator needs to reflect the new location.)
如果数据源未直接提供位置，则SWIMA-PC负责尝试确定软件产品的位置。产品的“位置”应该是保存软件产品可执行文件的目录。SWIMA-PC在报告软件产品位置时必须保持一致。换句话说，假设软件产品未移动，SWIMA-PC不能在一个报告中使用一个位置，而在另一个报告中使用同一软件产品的不同位置。（如果软件产品已移动，则软件定位器需要反映新位置。）
The location is expressed as a URI string. The string MUST conform to URI syntax requirements [RFC3986]. The URI scheme describes the context of the described location. For example, in most cases the location of the installed software product will be expressed in terms of its path in the filesystem. For such locations, the location URI scheme MUST be "file", and the URI MUST conform to the "file" URI scheme standard [RFC8089], including the percent-encoding of whitespace and other special characters. It is possible that other schemes could be used to represent other location contexts. Apart from specifying the use of the "file" scheme, this specification does not identify other schemes or define their use. When representing software products in other location contexts, tools MUST be consistent in their use of schemes, but the exact schemes are not normatively defined here. SWIMA implementations are not limited to the IANA list of URI schemes <https://www.iana.org/assignments/ uri-schemes/> and can define new schemes to support other types of application locations.
位置表示为URI字符串。字符串必须符合URI语法要求[RFC3986]。URI方案描述所描述位置的上下文。例如，在大多数情况下，已安装软件产品的位置将以其在文件系统中的路径表示。对于这些位置，位置URI方案必须是“文件”，并且URI必须符合“文件”URI方案标准[RFC8089]，包括空格和其他特殊字符的百分比编码。有可能使用其他方案来表示其他位置上下文。除了指定“文件”方案的使用外，本规范不确定其他方案或定义其使用。当在其他位置上下文中表示软件产品时，工具在使用方案时必须保持一致，但此处未规范地定义确切的方案。SWIMA实现不限于URI方案的IANA列表<https://www.iana.org/assignments/ uri schemes/>并可以定义新的方案以支持其他类型的应用程序位置。
It is possible that a SWIMA-PC is unable to determine the location of a reported software product. In this case, the SWIMA-PC MUST provide a zero-length Software Locator.
SWIMA-PC可能无法确定报告的软件产品的位置。在这种情况下，SWIMA-PC必须提供零长度软件定位器。
All SWIMA-PCs MUST track the source of each piece of software information they report. Each time a SWIMA-PC gets information to send to a given SWIMA-PV from a new source (from the perspective of that SWIMA-PV), the SWIMA-PC MUST assign that source a Source Identifier, which is an 8-bit unsigned integer. Each item reported includes the number of the Source Identifier for the source that provided that information. All information that is provided by that source MUST be delivered with this same Source Identifier. This MUST be done for each source used. If the SWIMA-PC is ever unclear as to whether a given source is new or not, it MUST assume that this is a new source and assign it a new Source Identifier. Source Identifier numbers do not need to be assigned sequentially. SWIMA does not support the presence of more than 256 sources, as the chance that a single endpoint will have more than 256 methods of collecting inventory information is vanishingly small. All possible values between 0 and 255 are valid; there are no reserved Source Identifier numbers.
所有SWIMA PC必须跟踪其报告的每项软件信息的来源。每次SWIMA-PC从新源（从该SWIMA-PV的角度）获取要发送到给定SWIMA-PV的信息时，SWIMA-PC必须为该源分配一个源标识符，该标识符为8位无符号整数。报告的每个项目都包括提供该信息的源的源标识符的编号。该源提供的所有信息都必须使用相同的源标识符传递。必须对使用的每个源执行此操作。如果SWIMA-PC不清楚给定源是否为新源，则必须假定这是一个新源，并为其分配一个新源标识符。源标识符编号不需要按顺序分配。SWIMA不支持超过256个来源，因为单个端点收集库存信息的方法超过256种的可能性非常小。0到255之间的所有可能值均有效；没有保留的源标识符编号。
Source Identifiers can help with (although will not completely eliminate) the challenges posed by multiple reporting of a single software instance. If multiple sources each report the same type of software product once, there is most likely a single instance of that product installed on the endpoint, which each source has detected independently. On the other hand, if multiple instances are reported by a single source, this almost certainly means that there are actually multiple instances that are being reported.
源标识符可以帮助解决（尽管不能完全消除）单个软件实例的多个报告所带来的挑战。如果多个源都报告同一类型的软件产品一次，那么端点上很可能安装了该产品的单个实例，每个源都独立检测到了该实例。另一方面，如果一个源报告多个实例，这几乎肯定意味着实际上有多个实例正在报告。
The SWIMA-PC is responsible for tracking associations between Source Identifiers and the given data source. This association MUST remain consistent with regard to a given SWIMA-PV while there is an active PB-TNC session with that SWIMA-PV. The SWIMA-PC MAY have a different Source Identifier association for different SWIMA-PVs. Likewise, the SWIMA-PC MAY change the Source Identifier association for a given SWIMA-PV if the PB-TNC session terminates. However, implementers of SWIMA-PCs will probably find it easier to manage associations by maintaining the same association for all SWIMA-PVs and across multiple sessions.
SWIMA-PC负责跟踪源标识符和给定数据源之间的关联。该关联必须与给定的SWIMA-PV保持一致，同时与该SWIMA-PV有活动的PB-TNC会话。对于不同的SWIMA PV，SWIMA-PC可能具有不同的源标识符关联。同样，如果PB-TNC会话终止，则SWIMA-PC可以更改给定SWIMA-PV的源标识符关联。但是，SWIMA PC的实施者可能会发现，通过为所有SWIMA PV和多个会话维护相同的关联，管理关联会更容易。
Of special note, event records reported from the SWIMA-PC's event log (discussed in Section 3.7) also need to be sent with their associated data source. The Source Identifier reported with events MUST be the current (i.e., at the time the event is sent) Source Identifier
特别值得注意的是，从SWIMA-PC的事件日志（在第3.7节中讨论）报告的事件记录也需要与其相关数据源一起发送。与事件一起报告的源标识符必须是当前（即，在发送事件时）源标识符
associated with the data source that produced the event, regardless of how long ago that event occurred. Event logs are likely to persist far longer than a single PB-TNC session. SWIMA-PCs MUST ensure that each event can be linked to the appropriate data source, even if the Source Identifiers used when the event was created have since been reassigned. In other words, when sending an event, it needs to be sent with the Source Identifier currently linked to the data source that produced it, regardless of whether a different Source Identifier would have been associated with the event when the event was first created.
与生成事件的数据源关联，无论该事件发生在多长时间之前。事件日志可能比单个PB-TNC会话的持续时间长得多。SWIMA PCs必须确保每个事件都可以链接到适当的数据源，即使创建事件时使用的源标识符已经重新分配。换句话说，在发送事件时，需要使用当前链接到生成该事件的数据源的源标识符发送该事件，而不管在首次创建该事件时是否有其他源标识符与该事件关联。
Note that the Source Identifier is primarily used to support recognition, rather than identification, of sources. That is to say, a Source Identifier can tell a recipient that two events were reported by the same source, but the number will not necessarily help that recipient determine which source was used. Moreover, different SWIMA-PCs will not necessarily use the same Source Identifiers for the same sources. SWIMA-PCs MUST track the assignment of Source Identifiers to ensure consistent application thereof. SWIMA-PCs MUST also track which Source Identifiers have been used with each SWIMA-PV with which they communicate.
请注意，源标识符主要用于支持源的识别，而不是识别。也就是说，源标识符可以告诉收件人同一个源报告了两个事件，但该数字不一定有助于收件人确定使用了哪个源。此外，不同的SWIMA PC不一定对相同的源使用相同的源标识符。SWIMA PC必须跟踪源标识符的分配，以确保一致应用。SWIMA PC还必须跟踪与其通信的每个SWIMA-PV使用了哪些源标识符。
A SWIMA attribute reporting an endpoint's Software Inventory Evidence Collection always contains the Software Identifiers associated with the identified software products. A SWIMA attribute might or might not also contain copies of Software Inventory Evidence Records. The attribute exchange is identical to the diagram shown in Figure 2, regardless of whether Software Inventory Evidence Records are included. The SWIMA Request attribute indicates whether the response is required to include Software Inventory Evidence Records. Excluding Software Inventory Evidence Records can reduce the attribute size of the response by multiple orders of magnitude when compared to sending the same inventory with full records.
报告端点的软件清单证据收集的SWIMA属性始终包含与已识别软件产品关联的软件标识符。SWIMA属性可能也可能不包含软件清单证据记录的副本。无论是否包含软件清单证据记录，属性交换都与图2所示的图表相同。SWIMA请求属性指示响应是否需要包括软件清单证据记录。与发送具有完整记录的相同清单相比，排除软件清单证据记录可以将响应的属性大小减少多个数量级。
Sometimes a SWIMA-PV does not require information about every piece of software on an endpoint but only needs to receive updates about certain software instances. For example, enterprise endpoints might be required to have certain software products installed and to keep these updated. Instead of requesting a complete inventory just to see if these products are present, the SWIMA-PV can make a "targeted request" for the software in question.
有时，SWIMA-PV不需要关于端点上每个软件的信息，只需要接收关于某些软件实例的更新。例如，企业端点可能需要安装某些软件产品并保持更新。SWIMA-PV可以对相关软件提出“有针对性的请求”，而不是仅仅为了查看这些产品是否存在而请求一份完整的清单。
Targeted requests follow the same attribute exchange as the exchange described in Figure 2. The SWIMA-PV targets its request by providing one or more Software Identifiers in its SWIMA Request attribute. The SWIMA-PC MUST then limit its response to contain only records that match the indicated Software Identifier(s). This allows the network exchange to exclude information that is not relevant to a given policy question, thus reducing unnecessary bandwidth consumption. The SWIMA-PC's response might or might not include Software Inventory Evidence Records, depending on the parameters of the SWIMA Request.
目标请求遵循与图2中描述的交换相同的属性交换。SWIMA-PV通过在其SWIMA请求属性中提供一个或多个软件标识符来确定其请求的目标。然后，SWIMA-PC必须将其响应限制为仅包含与指定软件标识符匹配的记录。这允许网络交换排除与给定策略问题无关的信息，从而减少不必要的带宽消耗。根据SWIMA请求的参数，SWIMA-PC的响应可能包括也可能不包括软件清单证据记录。
Note that targeted requests identify the software relevant to the request only through Software Identifiers. This specification does not support arbitrary, parameterized querying of records. For example, one cannot request all records from a certain software publisher or all records created by a particular data source. Targeted requests only allow a requester to request specific software (as identified by their Software Identifiers) and receive a response that is limited to the named software.
请注意，目标请求仅通过软件标识符标识与请求相关的软件。此规范不支持对记录的任意参数化查询。例如，不能从某个软件发布者请求所有记录，也不能请求由特定数据源创建的所有记录。目标请求仅允许请求者请求特定软件（由其软件标识符标识），并接收仅限于指定软件的响应。
There is no assumption that a SWIMA-PC will recognize "synonymous records" -- that is, records from different sources for the same software. Recall that different sources and data models may use different Software Identifier strings for the same software product. The SWIMA-PC returns only records that match the Software Identifiers in the SWIMA Request, even if there might be other records in the endpoint's Software Inventory Evidence Collection for the same software product. This is necessary because SWIMA-PCs might not have the ability to determine that two Software Identifiers refer to the same product.
没有假设SWIMA-PC会识别“同义记录”——即同一软件的不同来源的记录。回想一下，不同的源和数据模型可能会对同一软件产品使用不同的软件标识符字符串。SWIMA-PC仅返回与SWIMA请求中的软件标识符匹配的记录，即使端点的软件清单证据收集中可能存在相同软件产品的其他记录。这是必要的，因为SWIMA PC可能无法确定两个软件标识符是否指向同一产品。
A targeted SWIMA Request attribute does not specify Record Identifiers or Software Locators. The response to a targeted request MUST include all records associated with the named Software Identifiers, including the case where there are multiple records associated with a single Software Identifier.
目标SWIMA请求属性未指定记录标识符或软件定位器。对目标请求的响应必须包括与命名软件标识符关联的所有记录，包括存在与单个软件标识符关联的多个记录的情况。
SWIMA-PCs MUST accept targeted requests and process them correctly as described above. SWIMA-PVs MUST be capable of making targeted requests and processing the responses thereto.
SWIMA PC必须接受目标请求，并如上所述正确处理它们。SWIMA PVs必须能够提出目标请求并处理响应。
3.6. Monitoring Changes in an Endpoint's Software Inventory Evidence Collection
3.6. 监视端点的软件清单证据收集中的更改
The software collection on an endpoint is not static. As software is installed, uninstalled, patched, or updated, the Software Inventory Evidence Collection is expected to change to reflect the new software state on the endpoint. Different data sources might update the evidence collection at different rates. For example, a package
终结点上的软件集合不是静态的。随着软件的安装、卸载、修补或更新，软件资源清册证据收集预计将发生更改，以反映端点上的新软件状态。不同的数据源可能以不同的速率更新证据收集。例如，一个包
manager might update its records in the Software Inventory Evidence Collection immediately whenever it is used to add or remove a software product. By contrast, sources that perform periodic examination of the endpoint would likely only update their records in the Software Inventory Evidence Collection after each examination.
每当用于添加或删除软件产品时，经理可能会立即更新其在软件清单证据收集中的记录。相比之下，对端点执行定期检查的来源可能只会在每次检查后更新其在软件清单证据收集中的记录。
All SWIMA-PCs MUST be able to detect changes to the Software Inventory Evidence Collection. Specifically, SWIMA-PCs MUST be able to detect:
所有SWIMA PC必须能够检测到软件库存证据收集的更改。具体而言，SWIMA PC必须能够检测：
o The creation of records
o 记录的创建
o The deletion of records
o 删除记录
o The alteration of records
o 记录的更改
An "alteration" is anything that modifies the contents of a record (or would modify it, if the record is dynamically generated on demand) in any way, regardless of whether the change is functionally meaningful.
“更改”是指以任何方式修改记录内容（或者如果记录是按需动态生成的，则会对其进行修改）的任何内容，无论更改是否具有功能意义。
SWIMA-PCs MUST detect such changes to the endpoint's Software Inventory Evidence Collection in close to real time (i.e., within seconds) when the SWIMA-PC is operating. In addition, in the case where there is a period during which the SWIMA-PC is not operating, the SWIMA-PC MUST be able to determine the net change to the endpoint's Software Inventory Evidence Collection over the period it was not operational. Specifically, the "net change" represents the difference between (1) the state of the endpoint's Software Inventory Evidence Collection when the SWIMA-PC was last operational and monitoring its state and (2) the state of the endpoint's Software Inventory Evidence Collection when the SWIMA-PC resumed operation. Note that a net change might not reflect the total number of change events over this interval. For example, if a record was altered three times during a period when the SWIMA-PC was unable to monitor for changes, the net change of this interval might only note that there was an alteration to the record, but not how many individual alteration events occurred. It is sufficient for a SWIMA-PC's determination of a net change to note that there was a difference between the earlier and current state, rather than to enumerate all the individual events that allowed the current state to be reached.
当SWIMA-PC运行时，SWIMA-PC必须近实时（即在几秒钟内）检测端点软件清单证据收集的此类变化。此外，如果有一段时间SWIMA-PC不运行，则SWIMA-PC必须能够确定端点软件清单证据收集在其不运行期间的净变化。具体而言，“净变化”表示（1）SWIMA-PC上次运行并监控其状态时端点软件清单证据收集的状态与（2）SWIMA-PC恢复运行时端点软件清单证据收集的状态之间的差异。请注意，净更改可能不会反映此时间间隔内更改事件的总数。例如，如果一条记录在SWIMA-PC无法监控更改的时间段内更改了三次，则该时间段的净更改可能只会注意到记录发生了更改，而不会注意到发生了多少个单独的更改事件。SWIMA-PC在确定净变化时，只要注意到早期状态和当前状态之间存在差异，而不是列举允许达到当前状态的所有单个事件就足够了。
The SWIMA-PC MUST assign a time to each detected change in the endpoint's Software Inventory Evidence Collection. These timestamps correspond to the SWIMA-PC's best understanding as to when the detected change occurred. For changes to the endpoint's Software Inventory Evidence Collection that occur while the SWIMA-PC is operating, the SWIMA-PC ought to be able to assign a time to the
SWIMA-PC必须为端点的软件清单证据收集中检测到的每个更改分配一个时间。这些时间戳对应于SWIMA-PC对检测到的变化发生时间的最佳理解。对于在SWIMA-PC运行时对端点的软件清单证据收集进行的更改，SWIMA-PC应该能够为端点分配时间
event that is accurate to within a few seconds. For changes to the endpoint's Software Inventory Evidence Collection that occur while the SWIMA-PC is not operational, upon becoming operational the SWIMA-PC needs to make a best guess as to the time of the relevant events (possibly by looking at timestamps on files), but these values might be off. In the case of dynamically generated records, the time of change is the time at which the data from which the records are generated changes, not the time at which a changed record is generated. For example, if records are dynamically generated based on data in an RPM database (<http://rpm.org/>), the time of change would be when the RPM database changed.
事件，精确到几秒钟内。对于在SWIMA-PC不运行时发生的端点软件清单证据收集更改，在开始运行时，SWIMA-PC需要对相关事件的时间做出最佳猜测（可能通过查看文件上的时间戳），但这些值可能已关闭。对于动态生成的记录，更改时间是生成记录的数据更改的时间，而不是生成更改记录的时间。例如，如果记录是基于RPM数据库中的数据动态生成的(<http://rpm.org/>)，更改时间为RPM数据库更改时。
With regard to deletions of records, the SWIMA-PC needs to detect the deletion of a given record and MUST retain a copy of the full deleted record along with the associated Record Identifier and Software Locator so that the record and associated information can be provided to the SWIMA-PV upon request. This copy of the record MUST be retained for a reasonable amount of time. Vendors and administrators determine what "reasonable" means, but a copy of the record SHOULD be retained for as long as the event recording the deletion of the record remains in the SWIMA-PC's event log (as described in Section 3.7). This is recommended, because as long as the event is in the SWIMA-PC's event log the SWIMA-PC might send a change event attribute (described in Section 3.7) that references this record, and a copy of the record is needed if the SWIMA-PV wants a full copy of the relevant record. In the case that a SWIMA-PC is called upon to report a deletion event that is still in the event log but where the record itself is no longer available, the SWIMA-PC will still return an entry corresponding to the deletion event, but the field of that entry that would normally contain the full copy of the record SHOULD be zero-length.
关于记录的删除，SWIMA-PC需要检测给定记录的删除，并且必须保留完整删除记录的副本以及相关记录标识符和软件定位器，以便根据要求向SWIMA-PV提供记录和相关信息。此记录副本必须保留一段合理的时间。供应商和管理员确定“合理”的含义，但只要记录删除记录的事件保留在SWIMA-PC的事件日志中（如第3.7节所述），就应保留记录副本。建议这样做，因为只要事件在SWIMA-PC的事件日志中，SWIMA-PC可能会发送引用该记录的变更事件属性（如第3.7节所述），如果SWIMA-PV需要相关记录的完整副本，则需要该记录的副本。如果要求SWIMA-PC报告仍在事件日志中但记录本身不再可用的删除事件，则SWIMA-PC仍将返回与删除事件对应的条目，但通常包含记录完整副本的条目字段长度应为零。
With regard to alterations to a record, SWIMA-PCs MUST detect any alterations to the contents of a record. Alterations need to be detected even if they have no functional impact on the record. A good guideline is that any alteration to a record that might change the value of a hash taken on the record's contents needs to be detected by the SWIMA-PC. A SWIMA-PC might be unable to distinguish modifications to the contents of a record from modifications to the metadata that the filesystem associates with the record. For example, a SWIMA-PC might use the "last modification" timestamp as an indication of alteration to a given record, but a record's last modification time can change for reasons other than modifications to the record's contents. A SWIMA-PC is still considered compliant with this specification if it also reports metadata change events that do not change the record itself as alterations to the record. In other words, while SWIMA-PC implementers are encouraged to exclude modifications that do not affect the bytes within the record,
对于记录的更改，SWIMA PCs必须检测记录内容的任何更改。即使变更对记录没有功能影响，也需要进行检测。一个很好的指导原则是，SWIMA-PC需要检测对记录的任何更改，这些更改可能会改变记录内容上的哈希值。SWIMA-PC可能无法区分对记录内容的修改和对文件系统与记录关联的元数据的修改。例如，SWIMA-PC可能会使用“上次修改”时间戳作为对给定记录的更改指示，但记录的上次修改时间可能会因更改记录内容以外的原因而更改。如果SWIMA-PC还将不改变记录本身的元数据更改事件报告为对记录的更改，则仍视为符合本规范。换句话说，尽管鼓励SWIMA-PC实施者排除不影响记录中字节的修改，
discriminating between modifications to file contents and changes to file metadata can be difficult and time consuming on some systems. As such, as long as the alterations detected by a SWIMA-PC always cover all modifications to the contents of a record, the SWIMA-PC is considered compliant even if it also registers alterations that do not modify the contents of a record as well. When recording an alteration to a record, the SWIMA-PC is only required to note that an alteration occurred. The SWIMA-PC is not required to note or record how the record was altered, nor is it possible to include such details in SWIMA attributes reporting the change to a SWIMA-PV. There is no need to retain a copy of the original record prior to the alteration.
在某些系统上，区分对文件内容的修改和对文件元数据的更改可能很困难且耗时。因此，只要SWIMA-PC检测到的更改始终包括对记录内容的所有修改，则SWIMA-PC被视为符合要求，即使它也注册了不修改记录内容的更改。记录对记录的更改时，SWIMA-PC只需注意发生了更改。SWIMA-PC无需记录记录是如何更改的，也不可能在向SWIMA-PV报告更改的SWIMA属性中包含此类详细信息。更改前无需保留原始记录的副本。
When a record changes, it SHOULD retain the same Record Identifier. The Software Locator might or might not change, depending on whether the software changed locations during the changes that led to the record change. A record change MUST retain the same Software Identifier. This means that any action that changes a software product (e.g., application of a patch that results in a change to the product's version) MUST NOT be reflected by a record change but instead MUST result in the deletion of the old record and the creation of a new record. This reflects the requirement that a record in the endpoint's Software Inventory Evidence Collection correspond directly with an instance of a specific software product.
当记录更改时，它应该保留相同的记录标识符。软件定位器可能会更改，也可能不会更改，这取决于软件在导致记录更改的更改期间是否更改了位置。记录更改必须保留相同的软件标识符。这意味着更改软件产品的任何操作（例如，应用导致产品版本更改的修补程序）不得通过记录更改反映出来，而必须导致删除旧记录并创建新记录。这反映了端点的软件清单证据收集中的记录与特定软件产品的实例直接对应的要求。
As noted in Section 3.6, SWIMA-PCs are required to detect changes to the endpoint's Software Inventory Evidence Collection (creation, deletion, and alteration) in near real time while the SWIMA-PC is operational, and a given SWIMA-PC MUST be able to account for any net change to the endpoint's Software Inventory Evidence Collection that occurs when the SWIMA-PC is not operational. However, to be of use to the enterprise, the NEA Server needs to be able to receive these events and be able to understand how new changes relate to earlier changes. In SWIMA, this is facilitated by reporting change events. All SWIMA-PCs MUST be capable of receiving requests for change events and sending change event attributes. All SWIMA-PVs MUST be capable of requesting and receiving change event attributes.
如第3.6节所述，SWIMA-PC运行时，要求SWIMA-PC近实时检测端点软件清单证据收集（创建、删除和更改）的更改，给定的SWIMA-PC必须能够说明当SWIMA-PC不运行时端点的软件清单证据收集发生的任何净变化。但是，为了对企业有用，NEA服务器需要能够接收这些事件，并且能够理解新更改与早期更改之间的关系。在SWIMA中，这通过报告变更事件来实现。所有SWIMA PC必须能够接收变更事件请求并发送变更事件属性。所有SWIMA PV必须能够请求和接收变更事件属性。
To be useful, change events need to be correctly ordered. The ordering of events is facilitated by two pieces of information: an Event Identifier (EID) value and an EID Epoch value.
为了有用，更改事件需要正确排序。两条信息有助于事件的排序：事件标识符（EID）值和EID历元值。
An EID is a 4-byte unsigned integer that the SWIMA-PC assigns sequentially to each observed event (whether detected in real time or deduced by looking for net changes over a period of SWIMA-PC inactivity). All EIDs exist within the context of some "EID Epoch", which is also represented as a 4-byte unsigned integer. EID Epochs are used to ensure synchronization between the SWIMA-PC and any SWIMA-PVs with which it communicates. EID Epoch values MUST be generated in such a way as to minimize the chance that an EID Epoch will be reused, even in the case where the SWIMA-PC reverts to an earlier state. For this reason, sequential EID Epochs are discouraged, since loss of state could result in value reuse. There are multiple reasons that a SWIMA-PC might need to deliberately reset its EID counter, including exhaustion of available EID values, the need to purge entries from the event log to recover memory, or corruption of the event log. In all cases where a SWIMA-PC needs to reset its EID counter, a new EID Epoch MUST be selected.
EID是一个4字节的无符号整数，SWIMA-PC按顺序分配给每个观察到的事件（无论是实时检测到的事件，还是通过查找SWIMA-PC不活动期间的净变化推断的事件）。所有EID都存在于某个“EID历元”的上下文中，该历元也表示为一个4字节无符号整数。EID历元用于确保SWIMA-PC与其通信的任何SWIMA PV之间的同步。EID历元值的生成方式必须尽可能减少EID历元被重用的可能性，即使在SWIMA-PC恢复到早期状态的情况下也是如此。出于这个原因，不鼓励顺序EID时代，因为状态丢失可能导致价值重用。SWIMA-PC可能需要故意重置其EID计数器的原因有多种，包括可用EID值耗尽、需要清除事件日志中的条目以恢复内存或事件日志损坏。在SWIMA-PC需要重置其EID计数器的所有情况下，必须选择新的EID历元。
Within an Epoch, EIDs MUST be assigned sequentially, so that if a particular event is assigned an EID of N, the next observed event is given an EID of N+1. In some cases, events might occur simultaneously, or the SWIMA-PC might not otherwise be able to determine an ordering for events. In these cases, the SWIMA-PC creates an arbitrary ordering of the events and assigns EIDs according to this ordering. Two change events MUST NOT ever be assigned the same EID within the same EID Epoch. No meaningful comparison can be made between EID values of different Epochs.
在一个历元内，EID必须按顺序分配，因此，如果为某个特定事件分配了N的EID，则下一个观察到的事件将分配N+1的EID。在某些情况下，事件可能同时发生，或者SWIMA-PC可能无法确定事件的顺序。在这些情况下，SWIMA-PC创建事件的任意顺序，并根据该顺序分配EID。不得在同一EID纪元内为两个更改事件分配相同的EID。不同时期的EID值之间无法进行有意义的比较。
The EID value of 0 is reserved and MUST NOT be associated with any event. Specifically, an EID of 0 in a SWIMA Request attribute indicates that a SWIMA-PV wants an inventory response rather than an event response, while an EID of 0 in a SWIMA Response is used to indicate the initial state of the endpoint's Software Inventory Evidence Collection prior to the observation of any events. Thus, the very first recorded event in a SWIMA-PC's records within an EID Epoch MUST be assigned a value of 1. Note that EID and EID Epoch values are assigned by the SWIMA-PC without regard to whether events are being reported to one or more SWIMA-PVs. The SWIMA-PC records events and assigns EIDs during its operation. All SWIMA-PVs that request event information from the SWIMA-PC will have those requests served from the same event records and thus will see the same EIDs and EID Epochs for the same events.
EID值0是保留的，不能与任何事件关联。具体地说，SWIMA请求属性中的EID为0表示SWIMA-PV想要清单响应而不是事件响应，而SWIMA响应中的EID为0表示在观察任何事件之前端点的软件清单证据收集的初始状态。因此，必须为EID历元内SWIMA-PC记录中的第一个记录事件指定一个值1。请注意，EID和EID历元值由SWIMA-PC分配，而不考虑事件是否报告给一个或多个SWIMA PV。SWIMA-PC在其运行期间记录事件并分配EID。所有从SWIMA-PC请求事件信息的SWIMA PV将从相同的事件记录接收这些请求，因此将看到相同事件的相同EID和EID纪元。
If a SWIMA-PC uses multiple sources, a SWIMA-PC's assignment of EIDs MUST reflect the presence and order of all events on the endpoint (at least for supported sources), regardless of the source. This means that if source A experiences an event and then source B experiences two events, and then source A experiences another two events, the SWIMA-PC is required to capture five events with consecutive EID values reflecting the order in which the events occurred.
如果SWIMA-PC使用多个源，则SWIMA-PC对EID的分配必须反映端点上所有事件的存在和顺序（至少对于支持的源而言），而不管源是什么。这意味着，如果源A经历一个事件，然后源B经历两个事件，然后源A经历另外两个事件，则SWIMA-PC需要捕获五个事件，其中连续的EID值反映了事件发生的顺序。
The SWIMA-PC MUST ensure that there is no coverage gap (i.e., change events that are not recorded in the SWIMA-PC's records) in its change event records. This is necessary because a coverage gap might give a SWIMA-PV a false impression of the endpoint's state. For example, if a SWIMA-PV saw an event indicating that a particular record had been added to the endpoint's Software Inventory Evidence Collection but did not see any subsequent events indicating that the record in question had been deleted, it might reasonably assume that this record was still present and thus that the indicated software was still installed (assuming that the Epoch has not changed). If there is a coverage gap in the SWIMA-PC's event records, however, this assumption could be false. For this reason, the SWIMA-PC's event records MUST NOT contain gaps. In the case where there are periods where it is possible that changes occurred without the SWIMA-PC detecting or recording them, the SWIMA-PC MUST either (1) compute a net change and update its event records appropriately or (2) pick a new EID Epoch to indicate a discontinuity with previous event records.
SWIMA-PC必须确保其变更事件记录中没有覆盖范围差距（即未记录在SWIMA-PC记录中的变更事件）。这是必要的，因为覆盖间隙可能会给SWIMA-PV一个端点状态的错误印象。例如，如果SWIMA-PV看到一个事件，表明特定记录已添加到端点的软件清单证据收集中，但没有看到任何后续事件，表明相关记录已被删除，它可以合理地假设该记录仍然存在，因此指示的软件仍然安装（假设历元没有改变）。但是，如果SWIMA-PC的事件记录中存在覆盖率差距，则该假设可能是错误的。因此，SWIMA-PC的事件记录不得包含间隙。如果有可能在未经SWIMA-PC检测或记录的情况下发生变化的时段，SWIMA-PC必须（1）计算净变化并适当更新其事件记录，或（2）选择新的EID历元以指示与先前事件记录的不连续性。
Within a given Epoch, once a particular event has been assigned an EID, this association MUST NOT be changed. That is, within an Epoch, once an EID is assigned to an event, that EID cannot be reassigned to a different event, and the event cannot be assigned a different EID. When the SWIMA-PC's Epoch changes, all of these associations between EIDs and events are cancelled, and EID values once again become free for assignment.
在给定的历元内，一旦为特定事件分配了EID，则不得更改此关联。也就是说，在一个纪元内，一旦将EID分配给一个事件，该EID就不能重新分配给另一个事件，也不能为该事件分配另一个EID。当SWIMA-PC的历元发生变化时，EID和事件之间的所有这些关联将被取消，EID值将再次自由分配。
Whether reporting events or full inventories, it is important to know how the reported information fits into the overall timeline of change events. This is why all SWIMA Response attributes include fields to place that response within the sequence of detected events. Specifically, all SWIMA Responses include a Last EID field and an EID Epoch field. The EID Epoch field identifies the EID Epoch in which the SWIMA Response was sent. If the SWIMA Response is reporting events, all reported events occurred within the named EID Epoch. The Last EID (which is also always from the named EID Epoch) indicates the EID of the last recorded change event at the time that the SWIMA
无论是报告事件还是完整清单，了解报告的信息如何符合变更事件的总体时间表都很重要。这就是为什么所有SWIMA响应属性都包含将该响应置于检测到的事件序列中的字段。具体而言，所有SWIMA响应都包括最后一个EID字段和EID历元字段。EID Epoch字段标识发送SWIMA响应的EID Epoch。如果SWIMA响应报告事件，则所有报告的事件都发生在指定的EID历元内。最后一个EID（也始终来自命名的EID历元）表示SWIMA发生时最后记录的更改事件的EID
Response was sent. These two fields allow any response to be placed in the context of the complete set of detected change events within a given EID Epoch.
已发送响应。这两个字段允许将任何响应放置在给定EID纪元内检测到的完整更改事件集的上下文中。
Modern endpoints can have hundreds of software products installed, most of which are unlikely to change from one day to the next. As such, instead of exchanging a complete list of an endpoint's inventory on a regular basis, one might wish to only identify changes since some earlier known state of this inventory. This is readily facilitated by the use of EIDs to place change events in a context relative to the earlier state.
现代端点可以安装数百种软件产品，其中大多数不太可能从一天到下一天改变。因此，与其定期交换端点清单的完整列表，不如只识别自该清单的某些早期已知状态以来的更改。通过使用EID将更改事件放置在相对于早期状态的上下文中，这很容易实现。
As noted above, every SWIMA Response sent by a SWIMA-PC to a SWIMA-PV (as described in Sections 3.3 through 3.5) includes the EID Epoch and EID of the last event recorded prior to that response being compiled. This allows the SWIMA-PV to place all subsequently received event records in context relative to this SWIMA Response attribute (since the EIDs represent a total ordering of all changes to the endpoint's Software Inventory Evidence Collection). Specifically, a SWIMA-PV (or, more likely, a database that collects and records its findings) can record an endpoint's full inventory and also the EID and Epoch of the most recent event reflected at the time of that inventory. From that point on, if change events are observed, the attribute describing these events indicates the nature of the change, the affected records, and the order in which these events occurred (as indicated by the sequential EIDs). Using this information, any remote record of the endpoint's Software Inventory Evidence Collection can be updated appropriately.
如上所述，SWIMA-PC向SWIMA-PV发送的每个SWIMA响应（如第3.3节至第3.5节所述）包括编译该响应之前记录的最后一个事件的EID历元和EID。这允许SWIMA-PV将所有随后接收到的事件记录放置在与此SWIMA响应属性相关的上下文中（因为EID表示端点的软件清单证据收集的所有更改的总顺序）。具体而言，SWIMA-PV（或者更可能是一个收集和记录其调查结果的数据库）可以记录端点的完整清单，以及清单时反映的最近事件的EID和历元。从那时起，如果观察到更改事件，描述这些事件的属性将指示更改的性质、受影响的记录以及这些事件发生的顺序（如顺序EID所示）。使用此信息，可以适当地更新端点的软件清单证据收集的任何远程记录。
A SWIMA-PV MUST be able to request a list of event records instead of an inventory. The attribute flow in such an exchange looks the same as the basic flow shown in Figure 2. The only difference is that in the SWIMA Request attribute the SWIMA-PV provides an EID other than 0. (An EID value of 0 in a SWIMA Request represents a request for an inventory.) When the SWIMA-PC receives such a request, instead of identifying records from the endpoint's Software Inventory Evidence Collection, it consults its list of detected changes. The SWIMA-PC MUST add an event record to the SWIMA Response attribute for each recorded change event with an EID greater than or equal to the EID in the SWIMA Request attribute (although the targeting of requests, as described in the next paragraph, might limit this list). A list of event records MUST only contain events with EIDs that all come from the current Epoch.
SWIMA-PV必须能够请求事件记录列表，而不是清单。这种交换中的属性流看起来与图2中所示的基本流相同。唯一的区别是，在SWIMA请求属性中，SWIMA-PV提供的EID不是0。（SWIMA请求中的EID值为0表示对清单的请求。）当SWIMA-PC收到此类请求时，它不会从端点的软件清单证据收集中识别记录，而是参考其检测到的更改列表。对于EID大于或等于SWIMA请求属性中EID的每个记录的更改事件，SWIMA-PC必须在SWIMA响应属性中添加事件记录（尽管如下一段所述，请求的目标可能会限制此列表）。事件记录列表必须仅包含具有全部来自当前纪元的EID的事件。
SWIMA-PVs can target requests for event records by including one or more Software Identifiers, as described in Section 3.5, in the SWIMA Request that requests an event record list. A targeted request for event records is used to indicate that only events affecting software that matches one of the provided Software Identifiers are to be returned. Specifically, in response to a targeted request for event records, the SWIMA-PC MUST exclude any event records that are less than the indicated EID (within the current EID Epoch) and exclude any event records where the affected software does not match one of the provided Software Identifiers. This might mean that the resulting list of event records sent in the response attribute does not provide a continuous sequence of EIDs. Both SWIMA-PCs and SWIMA-PVs MUST support targeted requests for event records.
SWIMA PVs可以通过在请求事件记录列表的SWIMA请求中包括一个或多个软件标识符（如第3.5节所述）来确定事件记录请求的目标。事件记录的目标请求用于指示仅返回影响与所提供的软件标识符之一匹配的软件的事件。具体而言，为了响应事件记录的目标请求，SWIMA-PC必须排除小于指示EID的任何事件记录（在当前EID纪元内），并排除受影响软件与提供的软件标识符之一不匹配的任何事件记录。这可能意味着响应属性中发送的事件记录的结果列表不提供连续的EID序列。SWIMA PC和SWIMA PVs都必须支持事件记录的目标请求。
Over time, a SWIMA-PC might record a large number of change events. If a SWIMA-PV requests all change events covering a long period of time, the resulting SWIMA Response attribute might be extremely large, especially if the SWIMA-PV requests the inclusion of Software Inventory Evidence Records in the response. In the case that the resulting attribute is too large to send (because it exceeds either (1) the 4 GB attribute size limit imposed by the PA-TNC specification or (2) some smaller size limit imposed on the SWIMA-PC), the SWIMA-PC MAY send a partial list of event records back to the SWIMA-PV.
随着时间的推移，SWIMA-PC可能会记录大量更改事件。如果SWIMA-PV请求覆盖很长时间的所有变更事件，则生成的SWIMA响应属性可能非常大，特别是如果SWIMA-PV请求在响应中包含软件清单证据记录。如果结果属性太大而无法发送（因为它超过了（1）PA-TNC规范施加的4 GB属性大小限制或（2）对SWIMA-PC施加的一些较小的大小限制），则SWIMA-PC可以将部分事件记录列表发送回SWIMA-PV。
The generation of a partial list of events in a SWIMA Response attribute requires the SWIMA-PC to identify a "consulted range" of EIDs. A consulted range is the set of event records that are examined for inclusion in the SWIMA Response attribute and that are included in that attribute if applicable. Recall that if a SWIMA Request is targeted, only event records that involve the indicated software would be applicable. (See Section 3.5 for more on targeted requests.) If a request is not targeted, all event records in the consulted range are applicable and are included in the SWIMA Response attribute.
在SWIMA响应属性中生成部分事件列表需要SWIMA-PC识别EID的“参考范围”。参考范围是检查是否包含在SWIMA响应属性中并包含在该属性中（如果适用）的事件记录集。回想一下，如果针对SWIMA请求，则只有涉及指定软件的事件记录才适用。（有关目标请求的更多信息，请参见第3.5节。）如果请求没有目标，则参考范围内的所有事件记录都适用，并包含在SWIMA响应属性中。
The lower bound of the consulted range MUST be the EID provided in the SWIMA Request. (Recall that a SWIMA-PV indicates a request for event records by providing a non-zero EID value in the SWIMA Request. See Section 3.7.4.) The upper bound of the consulted range is the EID of the latest event record (as ordered by EID values) that is included in the SWIMA Response attribute if it is applicable to the request. The EID of this last event record is called the "Last Consulted EID". The SWIMA-PC chooses this Last Consulted EID based on the size of the event record list it is willing to provide to the SWIMA-PV.
参考范围的下限必须是SWIMA请求中提供的EID。（回想一下，SWIMA-PV通过在SWIMA请求中提供非零EID值来表示对事件记录的请求。请参见第3.7.4节。）参考范围的上限是最新事件记录的EID（按EID值排序），如果适用于请求，则包含在SWIMA响应属性中。最后一个事件记录的EID称为“最后一个参考EID”。SWIMA-PC根据其愿意提供给SWIMA-PV的事件记录列表的大小选择最后一次咨询的EID。
A partial result list MUST include all applicable event records within the consulted range. This means that for any applicable event record (i.e., any event record in a non-targeted request or any event record associated with software matching a requested Software Identifier in a targeted request) whose EID is greater than or equal to the EID provided in the SWIMA Request and whose EID is less than or equal to the Last Consulted EID, that event record MUST be included in the SWIMA Response conveying this partial list of event records. This ensures that every partial list of event records is always complete within its indicated range. Remember that for targeted requests, "complete" doesn't mean that all EIDs between the range endpoints are present -- only that every matching EID between the range endpoints is included.
部分结果列表必须包括咨询范围内的所有适用事件记录。这意味着对于EID大于或等于SWIMA请求中提供的EID且EID小于或等于上次参考EID的任何适用事件记录（即，非目标请求中的任何事件记录或与目标请求中与请求的软件标识符匹配的软件相关联的任何事件记录），该事件记录必须包含在传达该部分事件记录列表的SWIMA响应中。这确保事件记录的每个部分列表始终在其指定范围内完整。请记住，对于目标请求，“完成”并不意味着范围端点之间的所有EID都存在——只是包括范围端点之间的每个匹配EID。
In addition to the EID Epoch and Last EID fields that are present in all SWIMA Responses, all SWIMA Response attributes that convey event records include a Last Consulted EID field. Note that if responding to a targeted SWIMA Request, the SWIMA Response attribute might not contain the event record whose EID matches the Last Consulted EID value. For example, that record might have been deemed inapplicable because it did not match the specified list of Software Identifiers in the SWIMA Request.
除了所有SWIMA响应中存在的EID Epoch和Last EID字段外，所有传递事件记录的SWIMA响应属性还包括Last CONSURED EID字段。请注意，如果响应目标SWIMA请求，SWIMA响应属性可能不包含EID与上次参考的EID值匹配的事件记录。例如，该记录可能被认为不适用，因为它与SWIMA请求中指定的软件标识符列表不匹配。
If a SWIMA-PV receives a SWIMA Response attribute where the Last EID and Last Consulted EID fields are identical, the SWIMA-PV knows that it has received a result list that is complete, given the parameters of the request, up to the present time.
如果SWIMA-PV接收到一个SWIMA响应属性，其中最后一个EID和最后一个参考的EID字段相同，则SWIMA-PV知道，在给定请求参数的情况下，到目前为止，它已收到一个完整的结果列表。
On the other hand, if the Last EID is greater than the Last Consulted EID, the SWIMA-PV has received a partial result list. (The Last Consulted EID MUST NOT exceed the Last EID.) In this case, if the SWIMA-PV wishes to try to collect the rest of the partially delivered result list, it then sends a new SWIMA Request whose EID is one greater than the Last Consulted EID in the preceding response. Doing this causes the SWIMA-PC to generate another SWIMA Response attribute containing event records where the earliest reported event record is the one immediately after the event record with the Last Consulted EID (since EIDs are assigned sequentially). By repeating this process until it receives a SWIMA Response where the Last EID and Last Consulted EID are equal, the SWIMA-PV is able to collect all event records over a given range, even if the complete set of event records would be too large to deliver via a single attribute.
另一方面，如果上次EID大于上次咨询的EID，则SWIMA-PV已收到部分结果列表。（最后一次咨询的EID不得超过最后一次EID。）在这种情况下，如果SWIMA-PV希望尝试收集部分交付结果列表的其余部分，则它会发送一个新的SWIMA请求，其EID比前面响应中最后一次咨询的EID大一个。这样做会导致SWIMA-PC生成另一个包含事件记录的SWIMA响应属性，其中最早报告的事件记录是紧跟在具有最后一个参考EID的事件记录之后的事件记录（因为EID是按顺序分配的）。通过重复此过程直到收到最后一个EID和最后一个参考EID相等的SWIMA响应，SWIMA-PV能够收集给定范围内的所有事件记录，即使完整的事件记录集太大，无法通过单个属性传递。
Implementers need to be aware that a SWIMA Request might specify an EID that is greater than the EID of the last event recorded by a SWIMA-PC. In accordance with the behaviors described in Section 3.7.4, a SWIMA-PC MUST respond to such a request with a SWIMA Response attribute that contains zero event records. This is because
实施者需要知道，SWIMA请求可能指定的EID大于SWIMA-PC记录的最后一个事件的EID。根据第3.7.4节中描述的行为，SWIMA-PC必须使用包含零事件记录的SWIMA响应属性响应此类请求。这是因为
the SWIMA-PC has recorded no event records with EIDs greater than or equal to the EID in the SWIMA Request. In such a case, the Last Consulted EID field MUST be set to the same value as the Last EID field in this SWIMA Response attribute. This case is called out because the consulted range on a SWIMA-PC in such a situation is a negative range, where the "first" EID in the range (provided in the SWIMA Request) is greater than the "last" EID in the range (this being the EID of the last recorded event on the SWIMA-PC). Implementers need to ensure that SWIMA-PCs do not experience problems in such a circumstance.
SWIMA-PC未记录EID大于或等于SWIMA请求中EID的事件记录。在这种情况下，最后一个参考的EID字段必须设置为与此SWIMA响应属性中最后一个EID字段相同的值。之所以会出现这种情况，是因为在这种情况下，SWIMA-PC上的参考范围为负范围，其中范围内的“第一个”EID（在SWIMA请求中提供）大于范围内的“最后一个”EID（这是SWIMA-PC上最后记录的事件的EID）。实施者需要确保SWIMA PC在这种情况下不会出现问题。
Note that this specification only supports the returning of partial results when returning event records. There is no way to return a partial inventory list under this specification.
Note that this specification only supports the returning of partial results when returning event records. There is no way to return a partial inventory list under this specification.translate error, please retry
Since EIDs are sequential within an Epoch, if a SWIMA-PV's list of event records contains gaps in the EID values within a single Epoch, the SWIMA-PV knows that there are events that it has not accounted for. The SWIMA-PV can request either (1) a new event list to collect the missing events or (2) a full inventory to resync its understanding of the state of the endpoint's Software Inventory Evidence Collection. In either case, after the SWIMA-PV's record of the endpoint's Software Inventory Evidence Collection has been updated, the SWIMA-PV can record the new latest EID value and track events normally from that point on.
由于EID在一个历元内是连续的，如果SWIMA-PV的事件记录列表中包含单个历元内EID值的间隔，则SWIMA-PV知道存在其未考虑的事件。SWIMA-PV可以请求（1）一个新的事件列表来收集丢失的事件，或者（2）一个完整的清单来重新同步其对端点的软件清单证据收集状态的理解。在任何一种情况下，在更新SWIMA-PV端点的软件清单证据收集记录后，SWIMA-PV可以记录新的最新EID值，并从该点开始正常跟踪事件。
If the SWIMA-PV receives any attribute from a SWIMA-PC where the EID Epoch differs from the EID Epoch that was used previously, then the SWIMA-PV or any entity using this information to track the endpoint's Software Inventory Evidence Collection knows that there is a discontinuity in its understanding of the endpoint's state. To move past this discontinuity and reestablish a current understanding of the state of the endpoint's Software Inventory Evidence Collection, the SWIMA-PV needs to receive a full inventory from the endpoint. The SWIMA-PV cannot be brought in sync with the endpoint's state through the collection of any set of event records in this situation. This is because it is not possible to account for all events on the SWIMA-PC since the previous Epoch was used: there is no way to query for EIDs from a previous Epoch. Once the SWIMA-PV has received a full inventory for the new Epoch, the SWIMA-PV records the latest EID reported in this new Epoch and can track further events normally.
如果SWIMA-PV从SWIMA-PC接收到EID历元不同于先前使用的EID历元的任何属性，则SWIMA-PV或使用此信息跟踪端点的软件清单证据收集的任何实体都知道其对端点状态的理解存在中断。为了克服这种不连续性并重新建立对端点软件清单证据收集状态的当前理解，SWIMA-PV需要从端点接收完整清单。在这种情况下，不能通过收集任何一组事件记录使SWIMA-PV与端点的状态同步。这是因为，由于使用了上一个历元，因此无法解释SWIMA-PC上的所有事件：无法从上一个历元查询EID。一旦SWIMA-PV收到新纪元的完整库存，SWIMA-PV将记录此新纪元中报告的最新EID，并可正常跟踪其他事件。
A SWIMA-PC MUST NOT report events with EIDs from any Epoch other than the current EID Epoch. The SWIMA-PC MAY choose to purge all event records from a previous Epoch from memory after an Epoch change. Alternately, the SWIMA-PC MAY choose to retain some event records
SWIMA-PC不得报告来自除当前EID历元以外任何历元的EID事件。在历元更改后，SWIMA-PC可选择从内存中清除前一历元中的所有事件记录。或者，SWIMA-PC可以选择保留一些事件记录
from a previous EID Epoch and assign them new EIDs in the current Epoch. However, in the case where a SWIMA-PC chooses the latter option it MUST ensure that the order of events according to their EIDs is unchanged and that there is no coverage gap between the first retained event recorded during the previous Epoch (now reassigned with an EID in the current Epoch) and the first event recorded during the current Epoch. In particular, the SWIMA-PC MUST ensure that all change events that occurred after the last recorded event from the previous Epoch are known and recorded. (This might not be possible if the Epoch change is due to state corruption on the SWIMA-PC.) A SWIMA-PC might choose to reassign EIDs to records from a preceding Epoch to create a "sliding window" of events, where each Epoch change represents a shift in the window of available events.
从以前的EID历元中删除，并在当前历元中为其分配新的EID。但是，如果SWIMA-PC选择后一个选项，则必须确保事件根据其EID的顺序保持不变，并且在前一个历元期间记录的第一个保留事件（现在在当前历元中重新分配EID）和当前历元期间记录的第一个事件之间没有覆盖间隙。特别是，SWIMA-PC必须确保已知并记录上一历元上次记录事件之后发生的所有变更事件。（如果历元变化是由于SWIMA-PC上的状态损坏造成的，则这可能是不可能的。）SWIMA-PC可能会选择将EID重新分配给前一历元的记录，以创建事件的“滑动窗口”，其中每个历元变化代表可用事件窗口的移动。
In the case where a SWIMA-PC suffers a crash and loses track of its current EID Epoch or current EID, then it MUST generate a new EID Epoch value and begin assigning EIDs within that Epoch. In this case, the SWIMA-PC MUST purge all event records from before the crash, as it cannot ensure that there is not a gap between the last of those records and the next detected event. The process for generating a new EID Epoch MUST minimize the possibility that the newly generated EID Epoch is the same as a previously used EID Epoch.
如果SWIMA-PC发生崩溃并失去其当前EID历元或当前EID的跟踪，则必须生成新的EID历元值并开始在该历元内分配EID。在这种情况下，SWIMA-PC必须在崩溃前清除所有事件记录，因为它无法确保最后一个记录和下一个检测到的事件之间没有间隙。生成新EID历元的过程必须将新生成的EID历元与以前使用的EID历元相同的可能性降至最低。
The SWIMA-PV will normally never receive an attribute indicating that the latest EID is less than the latest EID reported in a previous attribute within the same EID Epoch. If this occurs, the SWIMA-PC has suffered an error of some kind, possibly indicative of at least partial corruption of its event log. In this case, the SWIMA-PV MUST treat the situation as if there was a change in Epoch and treat any local copy of the endpoint's Software Inventory Evidence Collection as being out of sync until a full inventory can be reported by the SWIMA-PC. The SWIMA-PV SHOULD log the occurrence so the SWIMA-PC can be examined to ensure that it is now operating properly.
SWIMA-PV通常不会收到指示最新EID小于同一EID历元内前一属性中报告的最新EID的属性。如果发生这种情况，则SWIMA-PC发生了某种错误，可能表明其事件日志至少部分损坏。在这种情况下,，SWIMA-PV必须将这种情况视为EPHO发生了变化，并将端点软件清单证据收集的任何本地副本视为不同步，直到SWIMA-PC可以报告完整的清单。SWIMA-PV应记录发生的情况，以便对SWIMA-PC进行检查，以确保其现在运行正常。
Thus far, all attribute exchanges discussed assume that a SWIMA-PV sent a SWIMA Request attribute and the SWIMA-PC is providing a direct response to that request. SWIMA also supports the ability of a SWIMA-PC to send a SWIMA Response to the SWIMA-PV in response to observed changes in the endpoint's Software Inventory Evidence Collection, instead of in direct response to a SWIMA Request. An agreement by a SWIMA-PC to send content when certain changes to the endpoint's Software Inventory Evidence Collection are detected is referred to in this specification as a "subscription", and the SWIMA-PV that receives this content is said to be "subscribed to" the given SWIMA-PC. All SWIMA-PCs and SWIMA-PVs MUST support the use of subscriptions.
到目前为止，所有讨论的属性交换都假设SWIMA-PV发送了一个SWIMA请求属性，并且SWIMA-PC提供了对该请求的直接响应。SWIMA还支持SWIMA-PC向SWIMA-PV发送SWIMA响应的能力，以响应端点软件清单证据收集中观察到的变化，而不是直接响应SWIMA请求。SWIMA-PC在检测到端点软件清单证据收集的某些更改时发送内容的协议在本规范中称为“订阅”，接收该内容的SWIMA-PV称为“订阅”给定的SWIMA-PC。所有SWIMA PC和SWIMA PV必须支持订阅的使用。
A SWIMA-PV establishes a subscription on a particular SWIMA-PC by sending a SWIMA Request attribute with the Subscribe flag set. The SWIMA Request attribute is otherwise identical to the SWIMA Requests discussed in previous sections. Specifically, such a SWIMA Request might or might not request the inclusion of Software Inventory Evidence Records, might or might not be targeted, and might request change event records or endpoint inventory. Assuming that no error is encountered, a SWIMA-PC MUST send a SWIMA Response attribute in direct response to this SWIMA Request attribute, just as if the Subscribe flag was not set. As such, the attribute exchange that establishes a new subscription in a SWIMA-PC has the same flow as the flow seen in the previous attribute exchanges, as depicted in Figure 2. If the SWIMA-PV does not receive a PA-TNC Error attribute (as described in Sections 3.9 and 5.15) in response to its subscription request, the subscription has been successfully established on the SWIMA-PC. The SWIMA Request attribute that establishes a new subscription is referred to as the "establishing request" for that subscription.
SWIMA-PV通过发送带有Subscribe标志集的SWIMA请求属性，在特定的SWIMA-PC上建立订阅。SWIMA请求属性在其他方面与前面章节中讨论的SWIMA请求相同。具体而言，此类SWIMA请求可能要求也可能不要求包含软件清单证据记录，可能是也可能不是目标，并且可能要求更改事件记录或端点清单。假设未遇到任何错误，SWIMA-PC必须发送SWIMA响应属性以直接响应此SWIMA请求属性，就像未设置Subscribe标志一样。因此，在SWIMA-PC中建立新订阅的属性交换具有与先前属性交换中看到的流相同的流，如图2所示。如果SWIMA-PV未收到PA-TNC错误属性（如第3.9节和第5.15节所述）以响应其订阅请求，则该订阅已在SWIMA-PC上成功建立。建立新订阅的SWIMA请求属性称为该订阅的“建立请求”。
When a subscription is established, it is assigned a Subscription ID value. The Subscription ID is equal to the value of the Request ID of the establishing request. (For more about Request IDs, see Section 5.5.)
建立订阅后，将为其分配订阅ID值。订阅ID等于建立请求的请求ID的值。（有关请求ID的更多信息，请参阅第5.5节。）
A SWIMA-PC MUST have the ability to record and support at least 8 simultaneous subscriptions and SHOULD have the ability to support more than this. These subscriptions might all come from a single SWIMA-PV, might all be from different SWIMA-PVs (residing on the same or different NEA Servers), or might be a mix. In the case that a SWIMA-PC receives a subscription request but is unable to support an additional subscription, it MUST respond to the request with a PA-TNC Error attribute with error code SWIMA_SUBSCRIPTION_DENIED_ERROR.
SWIMA-PC必须能够记录和支持至少8个同时订阅，并且应该能够支持更多。这些订阅可能全部来自单个SWIMA-PV，也可能全部来自不同的SWIMA PV（位于相同或不同的NEA服务器上），或者可能是混合订阅。如果SWIMA-PC接收到订阅请求但无法支持其他订阅，则必须使用PA-TNC错误属性响应请求，错误代码为SWIMA\u subscription\u DENIED\u Error。
A SWIMA-PV MUST have the ability to record and support at least 256 simultaneous subscriptions and SHOULD have the ability to support more than this. Any number of these subscriptions might be to the same SWIMA-PC, and any number of these subscriptions might be to different SWIMA-PCs. In the latter case, some of these SWIMA-PCs might share a single endpoint, while others might be on different endpoints.
SWIMA-PV必须能够记录和支持至少256个同时订阅，并且应该能够支持更多。这些订阅中的任意数量都可能指向同一个SWIMA-PC，而这些订阅中的任意数量都可能指向不同的SWIMA-PC。在后一种情况下，一些SWIMA-PC可能共享一个端点，而另一些可能位于不同的端点上。
The SWIMA-PC MUST record each accepted subscription along with the identity of the party to whom attributes are to be pushed. This identity includes two parts:
SWIMA-PC必须记录每个接受的订阅以及属性将被推送到的一方的身份。该标识包括两部分：
o An identifier for the PB-TNC session between the Posture Broker Server on a NEA Server and the Posture Broker Client on the endpoint. This identifier is called the "Connection ID"
o NEA服务器上的姿态代理服务器和端点上的姿态代理客户端之间PB-TNC会话的标识符。此标识符称为“连接ID”
o The Posture Validator Identifier for the SWIMA-PV that made the subscription request
o 发出订阅请求的SWIMA-PV的姿态验证程序标识符
The Posture Validator Identifier is provided in the field of the same name in the PB-PA message that encapsulates the subscription request attribute (Section 4.5 of [RFC5793]), and this information is passed along to NEA Posture Collectors (Section 3.3 of [RFC5792]). The Connection ID is a value local to a particular endpoint's Posture Broker Client that identifies an ongoing session between a specific Posture Broker Client and a specific Posture Broker Server. Posture Broker Clients and Posture Broker Servers need to be capable of supporting multiple simultaneous sessions, so they already need a way to locally distinguish each ongoing session. (See Section 3.1 of [RFC5793].) A Posture Broker Client needs to assign each session at a given time its own Connection ID that lasts for the life of that session. Connection IDs only need to be unique among the Connection IDs of simultaneously occurring sessions on that endpoint. This Connection ID needs to be exposed to the SWIMA-PC, and the SWIMA-PC needs to be informed when the Connection ID is unbound due to the closure of that connection.
姿态验证器标识符在封装订阅请求属性的PB-PA消息中的同名字段中提供（RFC5793的第4.5节），该信息将传递给NEA姿态采集器（RFC5792的第3.3节）。连接ID是特定端点的姿态代理客户端的本地值，用于标识特定姿态代理客户端和特定姿态代理服务器之间正在进行的会话。姿态代理客户端和姿态代理服务器需要能够支持多个同时会话，因此它们已经需要一种方法来本地区分每个正在进行的会话。（请参见[RFC5793]的第3.1节。）姿态代理客户端需要在给定时间为每个会话分配其自己的连接ID，该ID在该会话的生命周期内持续。连接ID只需要在该端点上同时发生的会话的连接ID中是唯一的。此连接ID需要向SWIMA-PC公开，并且当连接ID因该连接关闭而解除绑定时，需要通知SWIMA-PC。
Likewise, SWIMA-PVs MUST record each accepted subscription for which they are the subscribing party, including the parameters of the establishing request, along with the associated Subscription ID and the identity of the SWIMA-PC that will be fulfilling the subscription. The SWIMA-PV needs to retain this information in order to correctly interpret pushed SWIMA Response attributes sent in fulfillment of the subscription. The identity of the SWIMA-PC is given in the Posture Collector Identifier [RFC5793] of the PB-PA message header in all messages from that SWIMA-PC. The SWIMA-PV has no need to record the associated connection ID of the subscription as the SWIMA-PV is only receiving, not sending, attributes once a subscription is established.
同样，SWIMA PV必须记录其作为订阅方的每个接受订阅，包括建立请求的参数，以及相关订阅ID和将完成订阅的SWIMA-PC的标识。SWIMA-PV需要保留此信息，以便正确解释在履行订阅时发送的推送SWIMA响应属性。SWIMA-PC的标识在来自该SWIMA-PC的所有消息的PB-PA消息头的姿态收集器标识符[RFC5793]中给出。SWIMA-PV无需记录订阅的关联连接ID，因为一旦订阅建立，SWIMA-PV只接收而不发送属性。
Subscriptions MAY be terminated at any time by the subscribing SWIMA-PV by setting the Clear Subscriptions flag in a SWIMA Request. (See Section 5.6 for more on using this flag.) In the case that a SWIMA Request with the Clear Subscriptions flag set is received, the SWIMA-PC MUST only clear subscriptions that match both the NEA Server's Connection ID and the SWIMA-PV's Posture Validator Identifier for this SWIMA Request and MUST clear all such subscriptions.
通过在SWIMA请求中设置清除订阅标志，订阅SWIMA-PV可随时终止订阅。（有关使用此标志的更多信息，请参见第5.6节。）如果收到设置了清除订阅标志的SWIMA请求，则SWIMA-PC必须仅清除与此SWIMA请求的NEA服务器连接ID和SWIMA-PV姿态验证器标识符匹配的订阅，并且必须清除所有此类订阅。
This specification does not give the SWIMA-PV the ability to terminate subscriptions individually -- all subscriptions to the SWIMA-PV are cleared when the Clear Subscriptions flag is set.
本规范不允许SWIMA-PV单独终止订阅——设置清除订阅标志时，将清除对SWIMA-PV的所有订阅。
This specification does not give the SWIMA-PC the ability to unilaterally terminate a subscription. However, if the SWIMA-PC experiences a fatal error while fulfilling a subscription, resulting in sending a PA-TNC Error attribute with error code SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose fulfillment led to the error MUST be treated as terminated by both the SWIMA-PC and the SWIMA-PV. Only the subscription experiencing the error is cancelled; other subscriptions are unaffected. See Section 3.9 for more on this error condition.
本规范不允许SWIMA-PC单方面终止订阅。但是，如果SWIMA-PC在执行订阅时遇到致命错误，导致发送错误代码为SWIMA_subscription_FULFILLMENT_error的PA-TNC error属性，则其执行导致错误的订阅必须被SWIMA-PC和SWIMA-PV视为终止。只有遇到错误的订阅才会被取消；其他订阅不受影响。有关此错误情况的更多信息，请参见第3.9节。
Finally, a subscription is terminated if the connection between the SWIMA-PC and SWIMA-PV is closed. This occurs when the Connection ID used in the messages between the SWIMA-PC and the SWIMA-PV becomes unbound. Loss of this Connection ID would prevent the SWIMA-PC from sending messages in fulfillment of this subscription. As such, loss of the Connection ID necessarily forces subscription termination between the affected parties.
最后，如果SWIMA-PC和SWIMA-PV之间的连接关闭，则终止订阅。当SWIMA-PC和SWIMA-PV之间的消息中使用的连接ID解除绑定时，会发生这种情况。丢失此连接ID将阻止SWIMA-PC在履行此订阅时发送消息。因此，连接ID的丢失必然会导致受影响方之间的订阅终止。
A SWIMA-PV can request that a SWIMA-PC report the list of active subscriptions for which the SWIMA-PV is the subscriber. A SWIMA-PV can use this capability to recover lost information about active subscriptions. A SWIMA-PV can also use this capability to verify that a SWIMA-PC has not forgotten any of its subscriptions. The latter is especially useful in cases where a SWIMA-PC does not send any attributes in fulfillment of a given subscription for a long period of time. The SWIMA-PV can check the list of active subscriptions on the SWIMA-PC and verify whether the inactivity is due to (1) a lack of reportable events or (2) the SWIMA-PC forgetting its obligations to fulfill a given subscription.
SWIMA-PV可以请求SWIMA-PC报告SWIMA-PV是其订户的活动订阅列表。SWIMA-PV可以使用此功能恢复有关活动订阅的丢失信息。SWIMA-PV还可以使用此功能验证SWIMA-PC是否没有忘记任何订阅。后者在SWIMA-PC长时间不发送任何属性以实现给定订阅的情况下特别有用。SWIMA-PV可以检查SWIMA-PC上的活动订阅列表，并验证不活动是否是由于（1）缺少可报告事件或（2）SWIMA-PC忘记履行给定订阅的义务所致。
A SWIMA-PV requests a list of its subscriptions on a given SWIMA-PC by sending that SWIMA-PC a Subscription Status Request. The SWIMA-PC MUST then respond with a Subscription Status Response (or a PA-TNC Error if an error condition is experienced). The Subscription Status Response MUST contain one subscription record for each of the active subscriptions for which the SWIMA-PV is the subscribing party.
SWIMA-PV通过向给定的SWIMA-PC发送订阅状态请求来请求其在该SWIMA-PC上的订阅列表。然后，SWIMA-PC必须以订阅状态响应（如果遇到错误情况，则为PA-TNC错误）进行响应。订阅状态响应必须包含SWIMA-PV作为订阅方的每个活动订阅的一条订阅记录。
As noted in Section 3.6, SWIMA-PCs are required to automatically detect changes to an endpoint's Software Inventory Evidence Collection in near real time. For every active subscription, the SWIMA-PC MUST send an attribute to the subscribed SWIMA-PV whenever a change to relevant records is detected within the endpoint's Software Inventory Evidence Collection. Such an attribute is said to be sent "in fulfillment of" the given subscription, and any such attribute MUST include that subscription's Subscription ID. If the establishing request for that subscription was a targeted request, then only records that match the Software Identifiers provided in that establishing request are considered relevant. Otherwise (i.e., for non-targeted requests), any record is considered relevant for this purpose. Figure 3 shows a sample attribute exchange where a subscription is established and then attributes are sent from the SWIMA-PC in fulfillment of the established subscription.
如第3.6节所述，SWIMA PC需要近实时地自动检测端点软件清单证据收集的更改。对于每个活动订阅，只要在端点的软件清单证据收集中检测到相关记录的更改，SWIMA-PC必须向订阅的SWIMA-PV发送一个属性。这种属性被称为是在“履行”给定订阅时发送的，任何这种属性都必须包括该订阅的订阅ID。如果该订阅的建立请求是目标请求，则只有与该建立请求中提供的软件标识符匹配的记录才被视为相关。否则（即，对于非目标请求），任何记录都被视为与此目的相关。图3显示了一个示例属性交换，其中建立了订阅，然后从SWIMA-PC发送属性以实现已建立的订阅。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<----------SWIMA Request-----------| |
| | |
|-----------SWIMA Response--------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|----------SWIMA Response---------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|----------SWIMA Response---------->| |
| | V
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<----------SWIMA Request-----------| |
| | |
|-----------SWIMA Response--------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|----------SWIMA Response---------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|----------SWIMA Response---------->| |
| | V
Figure 3: Subscription Establishment and Fulfillment
图3：订阅建立和履行
The contents of an attribute sent in fulfillment of a subscription depend on the parameters provided in the establishing request for that subscription. Specifically, the attribute sent in fulfillment of a subscription has the same attribute type as would a direct response to the establishing request. For example, if the establishing request stipulated a response that contained an event record list that included Software Inventory Evidence Records, all attributes sent in fulfillment of this subscription will also consist of event record lists with Software Inventory Evidence Records. As such, all SWIMA Responses displayed in the exchange depicted in Figure 3 are the same attribute type. A SWIMA Response generated in fulfillment of an active subscription MUST be a valid SWIMA Response attribute according to all the rules outlined in the preceding sections. In other words, an attribute constructed in fulfillment of a subscription will look the same as an attribute sent in direct response to an explicit request from a SWIMA-PV that had the same request parameters and that arrived immediately after the given change event. There are a few special rules that expand on this guideline, as discussed in Sections 3.8.5.1 through 3.8.5.5.
为实现订阅而发送的属性的内容取决于该订阅的建立请求中提供的参数。具体地说，在履行订阅时发送的属性具有与直接响应建立请求相同的属性类型。例如，如果建立请求规定了一个响应，其中包含一个包含软件清单证据记录的事件记录列表，则在履行此订阅时发送的所有属性也将包含包含软件清单证据记录的事件记录列表。因此，图3所示的交换中显示的所有SWIMA响应都是相同的属性类型。根据前面章节中概述的所有规则，在执行活动订阅时生成的SWIMA响应必须是有效的SWIMA响应属性。换句话说，在完成订阅时构造的属性看起来与直接响应SWIMA-PV发出的显式请求时发送的属性相同，SWIMA-PV具有相同的请求参数，并且在给定更改事件之后立即到达。如第3.8.5.1节至第3.8.5.5节所述，本指南中有一些特殊规则。
In the case that a SWIMA-PV subscribes to a SWIMA-PC and requests an inventory attribute whenever changes are detected (i.e., the EID in the establishing request is 0), then the SWIMA-PC MUST send the requested inventory whenever a relevant change is detected. (A "relevant change" is any change for non-targeted requests or a change to an indicated record in a targeted request.) Upon detection of a relevant change for an active subscription, the SWIMA-PC sends the appropriate inventory information as if it had just received the establishing request. Inventory attributes sent in fulfillment of this subscription will probably have a large amount of redundancy, as the same records are likely to be present in each of these SWIMA attributes. The role of an inventory subscription is not to report records just for the items that changed -- that is the role of a subscription that reports events (see Section 3.8.5.2). A SWIMA-PC MUST NOT exclude a record from an attribute sent in fulfillment of an inventory subscription simply because that record was not involved in the triggering event (although a record might be excluded for other reasons, such as if the subscription is targeted; see Section 3.8.5.3).
如果SWIMA-PV订阅SWIMA-PC并在检测到更改时请求库存属性（即，建立请求中的EID为0），则SWIMA-PC必须在检测到相关更改时发送请求的库存。（相关变更是指非目标请求的任何变更或目标请求中指示记录的变更。）在检测到活动订阅的相关变更后，SWIMA-PC发送适当的库存信息，就好像它刚刚收到建立请求一样。为完成此订阅而发送的库存属性可能会有大量冗余，因为这些SWIMA属性中的每个属性中都可能存在相同的记录。库存订阅的作用不仅仅是报告已更改项目的记录，而是报告事件的订阅的作用（请参见第3.8.5.2节）。SWIMA-PC不得仅因为触发事件中未涉及记录而将记录从为完成库存订阅而发送的属性中排除（尽管记录可能因其他原因而被排除，例如如果订阅是针对性的；请参见第3.8.5.3节）。
A SWIMA-PV indicates that it wishes to establish a subscription requesting event records by providing a non-zero EID in the SWIMA Request establishing the subscription (see Section 3.7.1). However, when the SWIMA-PC constructs an attribute in fulfillment of the
SWIMA-PV表示其希望通过在建立订阅的SWIMA请求中提供非零EID来建立订阅请求事件记录（参见第3.7.1节）。但是，当SWIMA-PC构造属性以实现
subscription (other than the direct response to the establishing request), it MUST only include event records for the detected change(s) that precipitated this response attribute. In other words, it MUST NOT send a complete list of all changes starting with the establishing request's EID, up through the latest change, every time a new event is detected. In effect, the EID in the establishing request is treated as being updated every time an attribute is sent in fulfillment of this subscription, such that a single event is not reported twice in fulfillment of a single subscription. As such, every SWIMA-PC MUST track the EID of the last event that triggered an attribute for the given subscription. When the next event (or set of events) is detected, the SWIMA-PC MUST only report events with EIDs after the last reported event. In the case that the EID Epoch of the SWIMA-PC changes, the SWIMA-PC MUST reset this EID tracker to zero (if the event log is completely purged) or to the new EID of the last reported retained event (if the event log is partially purged to create a "sliding window"). Doing this ensures that the SWIMA-PC continues to only send events that have not been previously reported.
订阅（除了对建立请求的直接响应外），它必须仅包括促成此响应属性的检测到的更改的事件记录。换句话说，它不能在每次检测到新事件时发送从建立请求的EID开始到最新更改的所有更改的完整列表。实际上，建立请求中的EID被视为在每次执行此订阅时发送属性时都会更新，这样在执行单个订阅时不会报告两次单个事件。因此，每个SWIMA-PC必须跟踪触发给定订阅属性的最后一个事件的EID。当检测到下一个事件（或一组事件）时，SWIMA-PC必须仅在上次报告的事件之后使用EID报告事件。如果SWIMA-PC的EID历元发生变化，则SWIMA-PC必须将该EID跟踪器重置为零（如果事件日志被完全清除），或重置为上次报告的保留事件的新EID（如果事件日志被部分清除以创建“滑动窗口”）。这样做可确保SWIMA-PC继续只发送以前未报告的事件。
Note that while a subscription is active, the subscribing SWIMA-PV MAY make other requests for event records that overlap with events that are reported in fulfillment of a subscription. Such requests are not affected by the presence of the subscription, nor is the subscription affected by such requests. In other words, a given request will get the same results back whether or not there was a subscription. Likewise, an attribute sent in fulfillment of a subscription will contain the same information whether or not other requests had been received from the SWIMA-PV.
请注意，当订阅处于活动状态时，订阅SWIMA-PV可能会对与完成订阅时报告的事件重叠的事件记录发出其他请求。此类请求不受订阅存在的影响，订阅也不受此类请求的影响。换句话说，无论是否有订阅，给定的请求都将返回相同的结果。同样，无论是否收到来自SWIMA-PV的其他请求，在履行订阅时发送的属性都将包含相同的信息。
A SWIMA-PV needs to pay attention to the EID Epoch in these attributes, as changes in the Epoch might create discontinuities in the SWIMA-PV's understanding of the endpoint's Software Inventory Evidence Collection state, as discussed in Section 3.7.6. In particular, once the EID Epoch changes, a SWIMA-PV is unable to have confidence that it has a correct understanding of the state of an endpoint's Software Inventory Evidence Collection until after the SWIMA-PV collects a complete inventory.
SWIMA-PV需要注意这些属性中的EID历元，因为历元的变化可能会导致SWIMA-PV对端点软件清单证据收集状态的理解不连续，如第3.7.6节所述。特别是，一旦EID历元发生变化，SWIMA-PV在收集完整清单之前无法确信其正确了解端点软件清单证据收集的状态。
SWIMA-PCs MAY send partial lists of event records in fulfillment of a subscription. (See Section 3.7.5 for more on partial lists of event records.) In the case that a SWIMA-PC sends a partial list of event records in fulfillment of a subscription, it MUST immediately send the next consecutive partial list and continue doing so until it has sent the equivalent of the complete list of event records. In other words, if the SWIMA-PC sends a partial list, it does not wait for another change event to send another SWIMA Response; rather, it continues sending SWIMA Responses until it has sent all event records that would have been included in a complete fulfillment of the
SWIMA PC可发送部分事件记录列表以完成订阅。（有关部分事件记录列表的更多信息，请参见第3.7.5节。）如果SWIMA-PC发送了部分事件记录列表以完成订阅，则必须立即发送下一个连续部分列表，并继续发送，直到发送了与完整事件记录列表相当的内容。换句话说，如果SWIMA-PC发送部分列表，它不会等待另一个更改事件发送另一个SWIMA响应；相反，它会继续发送SWIMA响应，直到它发送了本应包含在完整完成任务中的所有事件记录
subscription. Note that the direct response to the establishing request is not considered to be sent in fulfillment of a subscription. However, in this case the SWIMA-PC MUST treat the presence of unreported events as a triggering event for pushing additional messages in fulfillment of the newly established subscription. As such, the net effect is that if the direct response to the establishing request (i.e., the Subscription Fulfillment flag is unset) is partial, the SWIMA-PC will immediately follow this with additional attributes (with the Subscription Fulfillment flag set) until the complete set of events has been sent to the SWIMA-PV.
订阅请注意，对建立请求的直接响应不被认为是在完成订阅时发送的。但是，在这种情况下，SWIMA-PC必须将未报告事件的存在视为触发事件，以推送额外消息以实现新建立的订阅。因此，净效果是，如果对建立请求的直接响应（即，订阅履行标志未设置）是部分的，则SWIMA-PC将立即使用附加属性（设置了订阅履行标志）来遵循此操作，直到将完整的事件集发送给SWIMA-PV。
Subscriptions MAY be targeted to only apply to records that match a given set of Software Identifiers. In the case where changes that affect multiple records are detected -- some matching the establishing request's Software Identifiers and some not -- the attribute sent in fulfillment of the subscription MUST only include inventory or events (as appropriate) for records that match the establishing request's Software Identifiers. The SWIMA-PC MUST NOT include non-matching records in the attribute, even if those non-matching records experienced change events that were simultaneous with change events on the matching records.
订阅的目标可能仅适用于与给定的一组软件标识符匹配的记录。在检测到影响多个记录的更改的情况下（有些与建立请求的软件标识符匹配，有些不匹配），在完成订阅时发送的属性必须仅包括与建立请求的软件标识符匹配的记录的清单或事件（视情况而定）。SWIMA-PC不得在属性中包含不匹配的记录，即使这些不匹配的记录经历了与匹配记录上的更改事件同时发生的更改事件。
In addition, a SWIMA-PC MUST send an attribute in fulfillment of a targeted subscription only when changes to the endpoint's Software Inventory Evidence Collection impact one or more records matching the subscription's establishing request's Software Identifiers. A SWIMA-PC MUST NOT send any attribute in fulfillment of a targeted subscription based on detected changes to the endpoint's Software Inventory Evidence Collection that did not involve any of the records targeted by that subscription.
此外，只有当对端点的软件清单证据收集的更改影响到与订阅的建立请求的软件标识符匹配的一个或多个记录时，SWIMA-PC才必须在实现目标订阅时发送属性。SWIMA-PC不得根据检测到的对端点软件清单证据收集的更改发送任何属性以实现目标订阅，该更改不涉及该订阅所针对的任何记录。
A SWIMA-PV MAY establish multiple subscriptions to a given SWIMA-PC. If this is the case, it is possible that a single change event on the endpoint might require fulfillment by multiple subscriptions and that the information included in attributes that fulfill each of these subscriptions might overlap. The SWIMA-PC MUST send separate attributes for each established subscription that requires a response due to the given event. Each of these attributes MUST contain all information required to fulfill that individual subscription, even if that information is also sent in other attributes sent in fulfillment of other subscriptions at the same time. In other words, SWIMA-PCs MUST NOT attempt to combine information when fulfilling multiple subscriptions simultaneously, even if this results in some redundancy in the attributes sent to the SWIMA-PV.
SWIMA-PV可以建立对给定SWIMA-PC的多个订阅。如果是这种情况，端点上的单个更改事件可能需要多个订阅来实现，并且实现每个订阅的属性中包含的信息可能重叠。由于给定事件，SWIMA-PC必须为每个需要响应的已建立订阅发送单独的属性。这些属性中的每一个都必须包含完成该单个订阅所需的所有信息，即使该信息也在同时执行其他订阅时发送的其他属性中发送。换句话说，在同时完成多个订阅时，SWIMA PC不得尝试合并信息，即使这会导致发送到SWIMA-PV的属性中存在冗余。
A SWIMA-PC MAY delay the fulfillment of a subscription following a change event in the interest of waiting to see if additional change events are forthcoming and, if so, conveying the relevant records back to the SWIMA-PV in a single SWIMA Response attribute. This can help reduce network bandwidth consumption between the SWIMA-PC and the SWIMA-PV. For example, consider a situation where 10 changes occur a tenth of a second apart. If the SWIMA-PC does not delay in assembling and sending SWIMA Response attributes, the SWIMA-PV will receive 10 separate SWIMA Response attributes over a period of 1 second. However, if the SWIMA-PC waits half a second after the initial event before assembling a SWIMA Response, the SWIMA-PV only receives two SWIMA Response attributes over the same period of time.
SWIMA-PC可能会在变更事件发生后延迟订阅的履行，以等待其他变更事件是否即将发生，如果是，则在单个SWIMA响应属性中将相关记录传送回SWIMA-PV。这有助于减少SWIMA-PC和SWIMA-PV之间的网络带宽消耗。例如，考虑10个变化发生在第十秒的情况下。如果SWIMA-PC没有延迟组装和发送SWIMA响应属性，则SWIMA-PV将在1秒的时间内接收10个单独的SWIMA响应属性。但是，如果在组装SWIMA响应之前，SWIMA-PC在初始事件后等待半秒钟，则SWIMA-PV在同一时间段内仅接收两个SWIMA响应属性。
Note that the ability to consolidate events for a single subscription over a given period of time does not contradict the rules in Section 3.8.5.4 prohibiting consolidation across multiple subscriptions. When delaying fulfillment of subscriptions, SWIMA-PCs are still required to fulfill each individual subscription separately. Moreover, in the case that change events within the delay window cancel each other out (e.g., a record is deleted and then re-added), the SWIMA-PC MUST still report each change event, rather than just report the net effect of changes over the delay period. In other words, delayed fulfillment can decrease the number of attributes sent by the SWIMA-PC, but it does not reduce the total number of change events reported.
请注意，在给定时间段内为单个订阅合并事件的能力与第3.8.5.4节中禁止跨多个订阅合并的规则并不矛盾。延迟完成订阅时，SWIMA PC仍然需要单独完成每个订阅。此外，如果延迟窗口内的变更事件相互抵消（例如，删除记录，然后重新添加），SWIMA-PC仍必须报告每个变更事件，而不仅仅是报告延迟期间变更的净影响。换句话说，延迟履行可以减少SWIMA-PC发送的属性数量，但不会减少报告的更改事件总数。
SWIMA-PCs are not required to support delayed fulfillment of subscriptions. However, in the case that the SWIMA-PC does support delayed subscription fulfillment, it MUST be possible to configure the SWIMA-PC to disable delayed fulfillment. In other words, parties deploying SWIMA-PCs need to be allowed to disable delayed subscription fulfillment in their SWIMA-PCs. The manner in which such configuration occurs is left to the discretion of implementers, although implementers MUST protect the configuration procedure from unauthorized tampering. In other words, there needs to be some assurance that unauthorized individuals are not able to introduce long delays in subscription fulfillment.
SWIMA PC不需要支持延迟完成订阅。但是，如果SWIMA-PC确实支持延迟订阅履行，则必须能够将SWIMA-PC配置为禁用延迟履行。换句话说，需要允许部署SWIMA PC的各方在其SWIMA-PC中禁用延迟订阅履行。此类配置的发生方式由实施者自行决定，尽管实施者必须保护配置过程免受未经授权的篡改。换句话说，需要确保未经授权的个人不会在订阅履行过程中造成长时间延迟。
In the case where the SWIMA-PC detects an error in a SWIMA Request attribute that it receives, it MUST respond with a PA-TNC Error attribute with an error code appropriate to the nature of the error. (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC Error attributes and error codes, and see Section 5.15 in this specification for error codes specific to SWIMA attributes.) In the
如果SWIMA-PC在其接收的SWIMA请求属性中检测到错误，则必须使用PA-TNC错误属性响应，并使用与错误性质相适应的错误代码。（有关PA-TNC错误属性和错误代码的更多详细信息，请参阅PA-TNC[RFC5792]第4.2.8节，有关特定于SWIMA属性的错误代码，请参阅本规范第5.15节。）
case that an error is detected in a SWIMA Request, the SWIMA-PC MUST NOT take any action requested by this SWIMA Request, even if partial completion of the request is possible. In other words, a SWIMA Request that contains an error will be completely ignored by the SWIMA-PC (beyond sending a PA-TNC Error attribute and possibly logging the error locally); no attempt at partial completion of the request will be made.
如果在SWIMA请求中检测到错误，则SWIMA-PC不得采取该SWIMA请求请求的任何行动，即使请求可能部分完成。换句话说，包含错误的SWIMA请求将被SWIMA-PC完全忽略（除了发送PA-TNC错误属性和可能在本地记录错误之外）；不会尝试部分完成请求。
In the case where the SWIMA-PC receives a valid SWIMA Request attribute but experiences an error during the process of responding to that attribute's instructions where that error prevents the SWIMA-PC from properly or completely fulfilling that request, the SWIMA-PC MUST send a PA-TNC Error attribute with an error code appropriate to the nature of the error. In the case where a PA-TNC Error attribute is sent, the SWIMA-PC MUST NOT take any of the actions requested by the SWIMA Request attribute that led to the detected error. This is the case even if some actions could have been completed successfully and might even require the SWIMA-PC to reverse some successful actions already taken before the error condition was detected. In other words, either (1) all aspects of a SWIMA Request complete fully and successfully (in which case the SWIMA-PC sends a SWIMA Response attribute) or (2) no aspects of the SWIMA Request occur (in which case the SWIMA-PC sends a PA-TNC Error attribute). In the case that a SWIMA-PC sends a PA-TNC Error attribute in response to a SWIMA Request, then the SWIMA-PC MUST NOT also send any SWIMA Response attribute in response to the same SWIMA Request. For this reason, the sending of a SWIMA Response attribute MUST be the last action taken by a SWIMA-PC in response to a SWIMA Request, to avoid the possibility of a processing error occurring after that SWIMA Response attribute is sent.
如果SWIMA-PC收到有效的SWIMA请求属性，但在响应该属性指令的过程中遇到错误，该错误会阻止SWIMA-PC正确或完全满足该请求，SWIMA-PC必须发送一个PA-TNC错误属性，该属性带有与错误性质相适应的错误代码。在发送PA-TNC错误属性的情况下，SWIMA-PC不得采取导致检测到错误的SWIMA请求属性所请求的任何操作。即使某些操作可能已成功完成，甚至可能要求SWIMA-PC撤销检测到错误条件之前已采取的某些成功操作，情况也是如此。换句话说，要么（1）SWIMA请求的所有方面完全且成功地完成（在这种情况下，SWIMA-PC发送SWIMA响应属性），要么（2）SWIMA请求的任何方面都没有发生（在这种情况下，SWIMA-PC发送PA-TNC错误属性）。如果SWIMA-PC发送PA-TNC错误属性以响应SWIMA请求，则SWIMA-PC也不得发送任何SWIMA响应属性以响应同一SWIMA请求。因此，SWIMA响应属性的发送必须是SWIMA-PC响应SWIMA请求时采取的最后一项操作，以避免在发送该SWIMA响应属性后发生处理错误的可能性。
In the case that the SWIMA-PC detects an error that prevents it from properly or completely fulfilling its obligations under an active subscription, the SWIMA-PC MUST send a PA-TNC Error attribute with error code SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR to the SWIMA-PV that established this subscription. This type of PA-TNC Error attribute identifies the specific subscription that cannot be adequately honored due to the error condition and also identifies an error "subtype". The error subtype indicates the error code of the error condition the SWIMA-PC experienced that prevented it from honoring the given subscription. In the case that the error condition cannot be identified or does not align with any of the defined error codes, the SWIMA_ERROR error code SHOULD be used in the subtype. In the case that a SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated subscription MUST be treated as cancelled by both the SWIMA-PC and the SWIMA-PV.
如果SWIMA-PC检测到错误，使其无法正确或完全履行活动订阅下的义务，则SWIMA-PC必须向建立此订阅的SWIMA-PV发送错误代码为SWIMA_subscription_FULFILLMENT_error的PA-TNC error属性。此类型的PA-TNC错误属性标识由于错误条件而无法充分遵守的特定订阅，并标识错误“子类型”。错误子类型表示SWIMA-PC遇到的错误条件的错误代码，该错误条件使其无法接受给定的订阅。如果无法识别错误条件或错误条件与任何已定义的错误代码不一致，则应在子类型中使用SWIMA_错误代码。如果发送了SWIMA_SUBSCRIPTION_FULFILLMENT_错误，则SWIMA-PC和SWIMA-PV必须将相关订阅视为已取消。
The SWIMA-PV MUST NOT send any PA-TNC Error attributes to SWIMA-PCs. In the case that a SWIMA-PV detects an error condition, it SHOULD log this error, but the SWIMA-PV does not inform any SWIMA-PCs of this event. Errors might include, but are not limited to, the detection of malformed SWIMA Response attributes sent from a given SWIMA-PC, as well as the detection of error conditions when the SWIMA-PV processes SWIMA Responses.
SWIMA-PV不得向SWIMA-PCs发送任何PA-TNC错误属性。如果SWIMA-PV检测到错误情况，则应记录此错误，但SWIMA-PV不会将此事件通知任何SWIMA-PCs。错误可能包括但不限于检测从给定SWIMA-PC发送的格式错误的SWIMA响应属性，以及检测SWIMA-PV处理SWIMA响应时的错误条件。
Both SWIMA-PCs and SWIMA-PVs SHOULD log errors so that administrators can trace the causes of errors. Log entries SHOULD include the code of the error, the time it was detected, and additional descriptive information to aid in understanding the nature and cause of the error. Logs are an important debugging tool, and implementers are strongly advised to include comprehensive logging capabilities in their products.
SWIMA PC和SWIMA PVs都应记录错误，以便管理员可以跟踪错误的原因。日志条目应包括错误代码、检测到错误的时间以及其他描述性信息，以帮助理解错误的性质和原因。日志是一种重要的调试工具，强烈建议实施者在其产品中包含全面的日志功能。
The SWIMA protocol supports two different types of message exchanges for conveying software inventory information. These message exchanges are described in the following subsections, along with implementation requirements for supporting them.
SWIMA协议支持两种不同类型的消息交换，用于传输软件清单信息。以下小节将描述这些消息交换，以及支持它们的实现要求。
The SWIMA protocol also supports two simple status exchanges: a Subscription Status exchange for conveying information about active subscriptions, and a Source Metadata exchange for conveying information about a SWIMA-PC's data sources. In both cases, a SWIMA-PV sends a request attribute (Subscription Status Request or Source Metadata Request, respectively) and a SWIMA-PC responds with a matching response attribute (Subscription Status Response or Source Metadata Response, respectively). As these exchanges are straightforward, no additional information on the exchanges is provided.
SWIMA协议还支持两种简单的状态交换：用于传输活动订阅信息的订阅状态交换，以及用于传输SWIMA-PC数据源信息的源元数据交换。在这两种情况下，SWIMA-PV发送请求属性（分别为订阅状态请求或源元数据请求），SWIMA-PC使用匹配的响应属性（分别为订阅状态响应或源元数据响应）进行响应。由于这些交流是直接的，因此没有提供有关交流的其他信息。
The first type of software information exchange is used to provide the SWIMA-PV with a software inventory or event collection from the queried endpoint.
第一种软件信息交换用于向SWIMA-PV提供来自查询端点的软件清单或事件集合。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<-----------SWIMA Request------------| |
| | |
| SWIMA Response* | |
|-----------------or----------------->| |
| PA-TNC Error | |
| | V
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<-----------SWIMA Request------------| |
| | |
| SWIMA Response* | |
|-----------------or----------------->| |
| PA-TNC Error | |
| | V
*SWIMA Response is one of the following: Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events.
*SWIMA响应是以下响应之一：软件标识符清单、软件标识符事件、软件清单或软件事件。
Figure 4: SWIMA Attribute Exchange (Direct Response to SWIMA Request)
图4:SWIMA属性交换（直接响应SWIMA请求）
In this exchange, the SWIMA-PV indicates to the SWIMA-PC, via a SWIMA Request, the nature of the information it wishes to receive (inventory vs. events, full or targeted) and how it wishes the returned inventory to be expressed (with or without Software Inventory Evidence Records). The SWIMA-PC responds with the requested information using the appropriate attribute type. A single SWIMA Request MUST only lead to a single SWIMA Response or PA-TNC Error that is in direct response to that request.
在此交换中，SWIMA-PV通过SWIMA请求向SWIMA-PC表明其希望接收的信息的性质（库存与事件，完整或有针对性），以及其希望如何表达返回的库存（有或没有软件库存证据记录）。SWIMA-PC使用适当的属性类型响应请求的信息。单个SWIMA请求只能导致直接响应该请求的单个SWIMA响应或PA-TNC错误。
The second type of software information exchange allows change-event-based reporting based on a subscription. If there is an active subscription on the endpoint, the SWIMA-PC sends a SWIMA Response to the SWIMA-PV following a change event on the endpoint in fulfillment of that subscription. Such an exchange is shown in Figure 5.
第二种类型的软件信息交换允许基于订阅的基于更改事件的报告。如果端点上存在活动订阅，则SWIMA-PC会在端点上发生更改事件后向SWIMA-PV发送SWIMA响应，以实现该订阅。这种交换如图5所示。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
<Change Event>| | |
|------SWIMA Response(s)*------>| |
| | |
| | V
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
<Change Event>| | |
|------SWIMA Response(s)*------>| |
| | |
| | V
*SWIMA Response is one of the following: Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events.
*SWIMA响应是以下响应之一：软件标识符清单、软件标识符事件、软件清单或软件事件。
Figure 5: SWIMA Attribute Exchange (in Fulfillment of an Active Subscription)
图5:SWIMA属性交换（实现活动订阅）
Note that unlike direct responses to a SWIMA Request, a single change event can precipitate multiple SWIMA Responses for a single subscription, but only if all but the last of those SWIMA Responses convey partial lists of event records. When providing multiple SWIMA Responses in this way, the initial responses contain partial lists of event records and the last of those SWIMA Responses conveys the remainder of the relevant event records, completing the delivery of all relevant events in response to the change event. A single change event MUST NOT otherwise be followed by multiple SWIMA Responses or PA-TNC Error attributes in any combination.
请注意，与对SWIMA请求的直接响应不同，单个更改事件可能会导致单个订阅的多个SWIMA响应，但前提是除了最后一个SWIMA响应外，所有这些响应都会传递部分事件记录列表。当以这种方式提供多个SWIMA响应时，初始响应包含部分事件记录列表，最后一个SWIMA响应传递其余相关事件记录，完成所有相关事件的交付，以响应变更事件。否则，单个变更事件后面不得有多个SWIMA响应或任何组合的PA-TNC错误属性。
All SWIMA-PVs and SWIMA-PCs MUST support both types of software information exchanges. In particular, SWIMA-PCs MUST be capable of pushing a SWIMA Response to a SWIMA-PV immediately upon detection of a change to the endpoint's Software Inventory Evidence Collection in fulfillment of established SWIMA-PV subscriptions, as described in Section 3.8.
所有SWIMA PV和SWIMA PC必须支持这两种类型的软件信息交换。特别是，如第3.8节所述，SWIMA PC必须能够在检测到端点的软件清单证据收集发生变化后立即将SWIMA响应推送到SWIMA-PV，以实现既定的SWIMA-PV订阅。
All SWIMA-PCs MUST support both status exchanges (Subscription Status and Source Metadata); SWIMA-PVs are recommended to support these status exchanges, but doing so is not required.
所有SWIMA PC必须支持两种状态交换（订阅状态和源元数据）；建议使用SWIMA PV支持这些状态交换，但不需要这样做。
This section describes the format and semantics of the SWIMA protocol. This protocol uses the PA-TNC message header format [RFC5792].
本节介绍SWIMA协议的格式和语义。该协议使用PA-TNC消息头格式[RFC5792]。
The NEA PB-TNC [RFC5793] interface provides a general message-batching protocol capable of carrying one or more PA-TNC messages between the Posture Broker Client and Posture Broker Server. When PB-TNC is carrying a PA-TNC message, the PB-TNC message headers contain a 32-bit identifier called the "PA Subtype". The PA Subtype field indicates the type of component associated with all of the PA-TNC attributes carried by the PB-TNC message. The core set of PA Subtypes is defined in the PA-TNC specification. This specification defines a new "SWIMA Attributes" PA Subtype, which is registered in Section 10.2 of this document and is used as a namespace for the collection of SWIMA attributes defined in this document.
NEA PB-TNC[RFC5793]接口提供通用消息批处理协议，能够在姿态代理客户端和姿态代理服务器之间承载一个或多个PA-TNC消息。当PB-TNC承载PA-TNC消息时，PB-TNC消息头包含一个称为“PA子类型”的32位标识符。PA子类型字段表示与PB-TNC消息携带的所有PA-TNC属性相关联的组件类型。PA-TNC规范中定义了PA子类型的核心集。本规范定义了一个新的“SWIMA属性”PA子类型，该子类型在本文件第10.2节中注册，并用作本文件中定义的SWIMA属性集合的命名空间。
For more information on PB-TNC messages and PA-TNC messages, as well as their message headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] specifications, respectively.
有关PB-TNC消息和PA-TNC消息及其消息头的更多信息，请分别参阅PB-TNC[RFC5793]和PA-TNC[RFC5792]规范。
Each PA-TNC attribute described in this specification is intended to be sent between the SWIMA-PC and SWIMA-PV and so will be carried in a PB-TNC message indicating a PA Subtype of "SWIMA Attributes". PB-TNC messages MUST always include the SWIMA Attributes Subtype defined in Section 5.1 when carrying SWIMA attributes over PA-TNC. The attributes defined in this specification appear below, along with a short summary of their purposes.
本规范中描述的每个PA-TNC属性旨在在SWIMA-PC和SWIMA-PV之间发送，因此将在指示“SWIMA属性”的PA子类型的PB-TNC消息中携带。在PA-TNC上携带SWIMA属性时，PB-TNC消息必须始终包含第5.1节中定义的SWIMA属性子类型。本规范中定义的属性及其用途的简短摘要如下所示。
PA-TNC attribute types are identified in the PA-TNC Attribute Header via the PA-TNC Attribute Vendor ID field and the PA-TNC Attribute Type field; see Section 4.1 of [RFC5792] for details. Table 1 identifies the appropriate values for these fields for each attribute type used within the SWIMA protocol. All attributes have a PEN value of 0x000000. Both the hexadecimal and decimal values are provided in the Integer column in the table. Each attribute is described in greater detail in subsequent sections (identified in the table's Description column).
PA-TNC属性类型通过PA-TNC属性供应商ID字段和PA-TNC属性类型字段在PA-TNC属性头中标识；详见[RFC5792]第4.1节。表1为SWIMA协议中使用的每种属性类型确定了这些字段的适当值。所有属性的笔值均为0x000000。十六进制和十进制值均在表中的整数列中提供。每个属性将在后续章节中进行更详细的描述（在表的“描述”列中标识）。
+--------------+-----------------+----------------------------------+
| Attribute | Integer | Description |
| Name | | |
+--------------+-----------------+----------------------------------+
| SWIMA | 0x0000000D (13) | Request sent from a SWIMA-PV to |
| Request | | a SWIMA-PC for the SWIMA-PC to |
| | | provide a software inventory or |
| | | event list. It might also |
| | | establish a subscription. |
| | | (Section 5.6) |
| | | |
| Software | 0x0000000E (14) | An inventory sent without |
| Identifier | | Software Inventory Evidence |
| Inventory | | Records sent from a SWIMA-PC. |
| | | (Section 5.7) |
| | | |
| Software | 0x0000000F (15) | A collection of events impacting |
| Identifier | | the endpoint's Software |
| Events | | Inventory Evidence Collection, |
| | | where events do not include |
| | | Software Inventory Evidence |
| | | Records. (Section 5.8) |
| | | |
| Software | 0x00000010 (16) | An inventory including Software |
| Inventory | | Inventory Evidence Records sent |
| | | from a SWIMA-PC. (Section 5.9) |
| | | |
| Software | 0x00000011 (17) | A collection of events impacting |
| Events | | the endpoint's Software |
| | | Inventory Evidence Collection, |
| | | where events include Software |
| | | Inventory Evidence Records. |
| | | (Section 5.10) |
| | | |
| Subscription | 0x00000012 (18) | A request for a list of a |
| Status | | SWIMA-PV's active subscriptions |
| Request | | on a SWIMA-PC. (Section 5.11) |
| | | |
| Subscription | 0x00000013 (19) | A list of a SWIMA-PV's active |
| Status | | subscriptions on a SWIMA-PC. |
| Response | | (Section 5.12) |
| | | |
| Source | 0x00000014 (20) | A request for information about |
| Metadata | | a SWIMA-PC's data sources. |
| Request | | (Section 5.13) |
| | | |
+--------------+-----------------+----------------------------------+
| Attribute | Integer | Description |
| Name | | |
+--------------+-----------------+----------------------------------+
| SWIMA | 0x0000000D (13) | Request sent from a SWIMA-PV to |
| Request | | a SWIMA-PC for the SWIMA-PC to |
| | | provide a software inventory or |
| | | event list. It might also |
| | | establish a subscription. |
| | | (Section 5.6) |
| | | |
| Software | 0x0000000E (14) | An inventory sent without |
| Identifier | | Software Inventory Evidence |
| Inventory | | Records sent from a SWIMA-PC. |
| | | (Section 5.7) |
| | | |
| Software | 0x0000000F (15) | A collection of events impacting |
| Identifier | | the endpoint's Software |
| Events | | Inventory Evidence Collection, |
| | | where events do not include |
| | | Software Inventory Evidence |
| | | Records. (Section 5.8) |
| | | |
| Software | 0x00000010 (16) | An inventory including Software |
| Inventory | | Inventory Evidence Records sent |
| | | from a SWIMA-PC. (Section 5.9) |
| | | |
| Software | 0x00000011 (17) | A collection of events impacting |
| Events | | the endpoint's Software |
| | | Inventory Evidence Collection, |
| | | where events include Software |
| | | Inventory Evidence Records. |
| | | (Section 5.10) |
| | | |
| Subscription | 0x00000012 (18) | A request for a list of a |
| Status | | SWIMA-PV's active subscriptions |
| Request | | on a SWIMA-PC. (Section 5.11) |
| | | |
| Subscription | 0x00000013 (19) | A list of a SWIMA-PV's active |
| Status | | subscriptions on a SWIMA-PC. |
| Response | | (Section 5.12) |
| | | |
| Source | 0x00000014 (20) | A request for information about |
| Metadata | | a SWIMA-PC's data sources. |
| Request | | (Section 5.13) |
| | | |
| Source | 0x00000015 (21) | Descriptive metadata about a |
| Metadata | | SWIMA-PC's data sources. |
| Response | | (Section 5.14) |
| | | |
| PA-TNC Error | 0x00000008 (8) | An error attribute as defined in |
| | | the PA-TNC specification |
| | | [RFC5792]. |
+--------------+-----------------+----------------------------------+
| Source | 0x00000015 (21) | Descriptive metadata about a |
| Metadata | | SWIMA-PC's data sources. |
| Response | | (Section 5.14) |
| | | |
| PA-TNC Error | 0x00000008 (8) | An error attribute as defined in |
| | | the PA-TNC specification |
| | | [RFC5792]. |
+--------------+-----------------+----------------------------------+
Table 1: SWIMA Attribute Enumeration
表1:SWIMA属性枚举
Because one of the Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events attributes is expected to be sent to a SWIMA-PV in direct response to a SWIMA Request attribute or in fulfillment of an active subscription, those four attribute types are referred to collectively in this document as "SWIMA Response attributes".
由于软件标识符清单、软件标识符事件、软件清单或软件事件属性之一预计将发送至SWIMA-PV，以直接响应SWIMA请求属性或履行活动订阅，因此这四种属性类型在本文档中统称为“SWIMA响应属性”。
All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and be capable of receiving and processing all SWIMA Response attributes as well as PA-TNC Error attributes. All SWIMA-PCs MUST be capable of receiving and processing SWIMA Request attributes and be capable of sending all types of SWIMA Response attributes as well as PA-TNC Error attributes. SWIMA-PVs MUST ignore any SWIMA Request attributes that they receive. SWIMA-PCs MUST ignore any SWIMA Response attributes or PA-TNC Error attributes that they receive.
所有SWIMA PV必须能够发送SWIMA请求属性，并能够接收和处理所有SWIMA响应属性以及PA-TNC错误属性。所有SWIMA PC必须能够接收和处理SWIMA请求属性，并能够发送所有类型的SWIMA响应属性以及PA-TNC错误属性。SWIMA PV必须忽略其收到的任何SWIMA请求属性。SWIMA PC必须忽略接收到的任何SWIMA响应属性或PA-TNC错误属性。
This specification uses diagrams to define the syntax of new PA-TNC messages and attributes. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits depicted in each diagram as they are shown from left to right for each 32-bit quantity, "traversing" the diagram from top to bottom. Fields representing numeric values MUST be sent in network (big endian) byte order.
本规范使用图表定义新PA-TNC消息和属性的语法。每个图表以位为单位描述每个字段的格式和大小。实现必须发送每个图中描述的位，因为它们对于每个32位量从左到右显示，从上到下“遍历”图。表示数值的字段必须以网络（大端）字节顺序发送。
Descriptions of bit field (e.g., flag) values refer to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit. As such, an octet with only bit 0 set would have a value of 0x80 (1000 0000), an octet with only bit 1 set would have a value of 0x40 (0100 0000), and an octet with only bit 7 set would have a value of 0x01 (0000 0001).
位字段（例如，标志）值的描述是指位在字段中的位置。这些位位置从最高有效位到最低有效位进行编号。因此，仅设置位0的八位字节的值为0x80（1000 0000），仅设置位1的八位字节的值为0x40（0100 0000），仅设置位7的八位字节的值为0x01（0000 0001）。
In order to ensure consistency of transmitted attributes, some fields require normalization of their format. When this is necessary, this information is indicated in the field's description. In such cases, the field contents MUST be normalized to Network Unicode format as defined in RFC 5198 [RFC5198]. Network Unicode format defines a refinement of UTF-8 [RFC3629] that ensures a normalized expression of characters. SWIMA-PCs and SWIMA-PVs MUST NOT perform conversion and normalization on any field values except those specifically identified in the following sections as requiring normalization. Note, however, that some data models require additional normalization before source information is added to an endpoint's Software Inventory Evidence Collection as a record. The references from the "Software Data Model Types" registry (see Section 10.5) will note where this is necessary.
为了确保传输属性的一致性，某些字段需要规范化其格式。如有必要，此信息将在字段说明中显示。在这种情况下，字段内容必须规范化为RFC 5198[RFC5198]中定义的网络Unicode格式。网络Unicode格式定义了UTF-8[RFC3629]的细化，以确保字符的规范化表达。SWIMA PC和SWIMA PVs不得对任何字段值执行转换和标准化，以下章节中明确规定需要标准化的字段值除外。但是，请注意，在将源信息作为记录添加到端点的软件清单证据收集之前，某些数据模型需要额外的规范化。“软件数据模型类型”注册表（见第10.5节）中的参考文件将说明哪些地方是必要的。
All SWIMA Request attributes MUST include a Request ID value. The Request ID field provides a value that identifies a given request relative to other requests between a SWIMA-PV and the receiving SWIMA-PC. Specifically, the SWIMA-PV assigns each SWIMA Request attribute a Request ID value that is intended to be unique within the lifetime of a given network Connection ID.
所有SWIMA请求属性必须包含请求ID值。Request ID（请求ID）字段提供一个值，该值标识相对于SWIMA-PV和接收SWIMA-PC之间的其他请求的给定请求。具体而言，SWIMA-PV为每个SWIMA请求属性分配一个请求ID值，该值在给定网络连接ID的生存期内是唯一的。
In the case that a SWIMA Request requests the establishment of a subscription and the receiving SWIMA-PC agrees to that subscription, the Request ID of that SWIMA Request (i.e., the establishing request of the subscription) becomes that subscription's Subscription ID. All attributes sent in fulfillment of this subscription include a flag indicating that the attribute fulfills a subscription and the subscription's Subscription ID. A SWIMA-PV MUST NOT reuse a Request ID value in communications with a given SWIMA-PC while that Request ID is also serving as a Subscription ID for an active subscription with that SWIMA-PC. In the case where a SWIMA-PC receives a SWIMA Request from a given SWIMA-PV where that Request ID is also the Subscription ID of an active subscription with that SWIMA-PV, the SWIMA-PC MUST respond with a PA-TNC Error attribute with an error code of SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not cancel the indicated subscription.
如果SWIMA请求建立订阅且接收SWIMA-PC同意该订阅，则该SWIMA请求的请求ID（即订阅的建立请求）成为该订阅的订阅ID。为实现该订阅而发送的所有属性都包含一个标志，指示该属性实现订阅和订阅的订阅ID。当该请求ID也用作订阅ID时，SWIMA-PV不得在与给定SWIMA-PC的通信中重用请求ID值使用该SWIMA-PC的活动订阅的订阅ID。如果SWIMA-PC收到来自给定SWIMA-PV的SWIMA请求，且该请求ID也是使用该SWIMA-PV的活动订阅的订阅ID，则SWIMA-PC必须使用PA-TNC Error属性响应，错误代码为SWIMA_Subscription_ID_REUSE_Error。请注意，此错误不会取消指定的订阅。
Subscription Status Requests and Subscription Status Responses do not include Request IDs.
订阅状态请求和订阅状态响应不包括请求ID。
In the case where all possible Request ID values have been exhausted within the lifetime of a single network Connection ID, the sender MAY reuse previously used Request IDs within the same network connection if the ID is not being used as a Subscription ID. In the case where reuse is necessary due to exhaustion of possible ID values, the SWIMA-PV SHOULD structure the reuse to maximize the time between original and subsequent use. The Request ID value is included in a SWIMA Response attribute directly responding to this SWIMA Request to indicate which SWIMA Request was received and caused the response. Request IDs can be randomly generated or sequential, as long as values are not repeated per the rules in this paragraph. SWIMA-PCs are not required to check for duplicate Request IDs, except insofar as is necessary to detect Subscription ID reuse.
如果在单个网络连接ID的生存期内用尽了所有可能的请求ID值，则如果该ID未用作订阅ID，则发送方可以在同一网络连接内重用以前使用的请求ID。如果由于用尽了可能的ID值而需要重用，SWIMA-PV应组织重用，以最大限度地延长原始和后续使用之间的时间。请求ID值包含在直接响应此SWIMA请求的SWIMA响应属性中，以指示接收到哪个SWIMA请求并导致响应。请求ID可以是随机生成的，也可以是顺序生成的，只要不按照本段中的规则重复值即可。SWIMA PC无需检查重复的请求ID，除非有必要检测订阅ID的重复使用。
A SWIMA-PV sends this attribute to a SWIMA-PC to request that the SWIMA-PC send software inventory information to the SWIMA-PV. A SWIMA-PC MUST NOT send this attribute.
SWIMA-PV向SWIMA-PC发送此属性，以请求SWIMA-PC向SWIMA-PV发送软件清单信息。SWIMA-PC不得发送此属性。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SWIMA Request Attribute
图6:SWIMA请求属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SWIMA Request Attribute SUB-BLOCK
图7:SWIMA请求属性子块
+---------------+---------------------------------------------------+
| Field | Description |
+---------------+---------------------------------------------------+
| Flags: Bit 0 | If set (1), the SWIMA-PC MUST delete all |
| - Clear | subscriptions established by the requesting |
| Subscriptions | SWIMA-PV (barring any errors). |
| | |
| Flags: Bit 1 | If set (1), in addition to responding to the |
| - Subscribe | request as described, the SWIMA-PC MUST establish |
| | a subscription with parameters matching those in |
| | the SWIMA Request attribute (barring any errors). |
| | |
| Flags: Bit 2 | If unset (0), the SWIMA-PC's response MUST |
| - Result Type | include Software Inventory Evidence Records, and |
| | thus the response MUST be a Software Inventory, |
| | Software Events, or PA-TNC Error attribute. If |
| | set (1), the response MUST NOT include Software |
| | Inventory Evidence Records, and thus the response |
| | MUST be a Software Identifier Inventory, Software |
| | Identifier Events, or PA-TNC Error attribute. |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 3-7 - | to zero on transmission and ignored upon |
| Reserved | reception. |
| | |
| Software | A 3-byte unsigned integer indicating the number |
| Identifier | of Software Identifiers that follow. If this |
| Count | value is non-zero, this is a targeted request, as |
| | described in Section 3.5. The Software |
| | Identifier Length and Software Identifier fields |
| | are repeated, in order, the number of times |
| | indicated in this field. In the case where |
| | Software Identifiers are present, the SWIMA-PC |
| | MUST only report software that corresponds to the |
| | identifiers the SWIMA-PV provided in this |
| | attribute (or respond with a PA-TNC Error |
| | attribute). This field value MAY be 0, in which |
| | case there are no instances of the Software |
| | Identifier Length and Software Identifier fields. |
| | In this case, the SWIMA-PV is indicating an |
| | interest in all Software Inventory Evidence |
| | Records on the endpoint (i.e., this is not a |
| | targeted request). |
| | |
| Request ID | A value that uniquely identifies this SWIMA |
| | Request from a particular SWIMA-PV. |
| | |
+---------------+---------------------------------------------------+
| Field | Description |
+---------------+---------------------------------------------------+
| Flags: Bit 0 | If set (1), the SWIMA-PC MUST delete all |
| - Clear | subscriptions established by the requesting |
| Subscriptions | SWIMA-PV (barring any errors). |
| | |
| Flags: Bit 1 | If set (1), in addition to responding to the |
| - Subscribe | request as described, the SWIMA-PC MUST establish |
| | a subscription with parameters matching those in |
| | the SWIMA Request attribute (barring any errors). |
| | |
| Flags: Bit 2 | If unset (0), the SWIMA-PC's response MUST |
| - Result Type | include Software Inventory Evidence Records, and |
| | thus the response MUST be a Software Inventory, |
| | Software Events, or PA-TNC Error attribute. If |
| | set (1), the response MUST NOT include Software |
| | Inventory Evidence Records, and thus the response |
| | MUST be a Software Identifier Inventory, Software |
| | Identifier Events, or PA-TNC Error attribute. |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 3-7 - | to zero on transmission and ignored upon |
| Reserved | reception. |
| | |
| Software | A 3-byte unsigned integer indicating the number |
| Identifier | of Software Identifiers that follow. If this |
| Count | value is non-zero, this is a targeted request, as |
| | described in Section 3.5. The Software |
| | Identifier Length and Software Identifier fields |
| | are repeated, in order, the number of times |
| | indicated in this field. In the case where |
| | Software Identifiers are present, the SWIMA-PC |
| | MUST only report software that corresponds to the |
| | identifiers the SWIMA-PV provided in this |
| | attribute (or respond with a PA-TNC Error |
| | attribute). This field value MAY be 0, in which |
| | case there are no instances of the Software |
| | Identifier Length and Software Identifier fields. |
| | In this case, the SWIMA-PV is indicating an |
| | interest in all Software Inventory Evidence |
| | Records on the endpoint (i.e., this is not a |
| | targeted request). |
| | |
| Request ID | A value that uniquely identifies this SWIMA |
| | Request from a particular SWIMA-PV. |
| | |
| Earliest EID | In the case where the SWIMA-PV is requesting |
| | software events, this field contains the EID |
| | value of the earliest event the SWIMA-PV wishes |
| | to have reported. (Note: The report will be |
| | inclusive of the event with this EID value.) In |
| | the case where the SWIMA-PV is requesting an |
| | inventory, then this field MUST be 0 |
| | (0x00000000). In the case where this field is |
| | non-zero, the SWIMA-PV is requesting events, and |
| | the SWIMA-PC MUST respond using a Software |
| | Events, Software Identifier Events, or PA-TNC |
| | Error attribute. In the case where this field is |
| | zero, the SWIMA-PV is requesting an inventory, |
| | and the SWIMA-PC MUST respond using a Software |
| | Inventory, Software Identifier Inventory, or |
| | PA-TNC Error attribute. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier value |
| Identifier | from a Software Inventory Evidence Record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 5.4. This string |
| | MUST NOT be null terminated. |
+---------------+---------------------------------------------------+
| Earliest EID | In the case where the SWIMA-PV is requesting |
| | software events, this field contains the EID |
| | value of the earliest event the SWIMA-PV wishes |
| | to have reported. (Note: The report will be |
| | inclusive of the event with this EID value.) In |
| | the case where the SWIMA-PV is requesting an |
| | inventory, then this field MUST be 0 |
| | (0x00000000). In the case where this field is |
| | non-zero, the SWIMA-PV is requesting events, and |
| | the SWIMA-PC MUST respond using a Software |
| | Events, Software Identifier Events, or PA-TNC |
| | Error attribute. In the case where this field is |
| | zero, the SWIMA-PV is requesting an inventory, |
| | and the SWIMA-PC MUST respond using a Software |
| | Inventory, Software Identifier Inventory, or |
| | PA-TNC Error attribute. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier value |
| Identifier | from a Software Inventory Evidence Record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 5.4. This string |
| | MUST NOT be null terminated. |
+---------------+---------------------------------------------------+
Table 2: SWIMA Request Attribute Fields
表2:SWIMA请求属性字段
The SWIMA-PV sends the SWIMA Request attribute to a SWIMA-PC to request the indicated information. Note that between the Result Type flag and the Earliest EID field, the SWIMA-PC is constrained to a single possible SWIMA Response attribute type (or a PA-TNC Error attribute) in its response to the request.
SWIMA-PV向SWIMA-PC发送SWIMA请求属性，以请求指示信息。注意，在结果类型标志和最早的EID字段之间，SWIMA-PC在其对请求的响应中被约束为单个可能的SWIMA响应属性类型（或PA-TNC错误属性）。
The Subscribe flag and the Clear Subscriptions flag are used to manage subscriptions for the requesting SWIMA-PV on the receiving SWIMA-PC. Specifically, an attribute with the Subscribe flag set seeks to establish a new subscription by the requesting SWIMA-PV to the given SWIMA-PC, while an attribute with the Clear Subscriptions flag set seeks to delete all existing subscriptions by the requesting SWIMA-PV on the given SWIMA-PC. Note that in the latter case, only the subscriptions associated with the Connection ID and the Posture Validator Identifier of the requester are deleted as described in Section 3.8.3. A newly established subscription has the parameters outlined in the SWIMA Request attribute. Specifically, the Result Type flag indicates the type of result to send in fulfillment of the
Subscribe（订阅）标志和Clear Subscriptions（清除订阅）标志用于管理接收SWIMA-PC上请求的SWIMA-PV的订阅。具体而言，设置了Subscribe（订阅）标志的属性旨在通过请求的SWIMA-PV建立对给定SWIMA-PC的新订阅，当设置了Clear Subscriptions（清除订阅）标志的属性试图删除请求SWIMA-PV在给定SWIMA-PC上的所有现有订阅时。请注意，在后一种情况下，仅删除与请求者的连接ID和姿态验证程序标识符相关联的订阅，如第3.8.3节所述。新建立的订阅具有SWIMA请求属性中列出的参数。具体地说，结果类型标志指示要发送的结果类型，以实现
subscription, the value of the Earliest EID field indicates whether the fulfillment attributes list inventories or events, and the fields describing Software Identifiers (if present) indicate if and how a subscription is targeted. In the case that the SWIMA-PC is unable or unwilling to comply with the SWIMA-PV's request to establish or clear subscriptions, the SWIMA-PC MUST respond with a PA-TNC Error attribute with the SWIMA_SUBSCRIPTION_DENIED_ERROR error code. If the SWIMA-PV requests that subscriptions be cleared but has no existing subscriptions, this is not an error.
订阅时，“最早的EID”字段的值指示履行属性是否列出清单或事件，描述软件标识符（如果存在）的字段指示订阅是否以及如何作为目标。如果SWIMA-PC无法或不愿意遵守SWIMA-PV建立或清除订阅的请求，则SWIMA-PC必须使用PA-TNC错误属性和SWIMA\u订阅被拒绝\u错误代码进行响应。如果SWIMA-PV请求清除订阅，但没有现有订阅，则这不是错误。
An attribute requesting the establishment of a subscription is effectively doing "double duty", as it is a request for an immediate response from the SWIMA-PC in addition to setting up the subscription. Assuming that the SWIMA-PC is willing to comply with the subscription, it MUST send an appropriate response attribute to a request with the Subscribe flag set containing all requested information. The same is true of the Clear Subscriptions flag -- assuming that there is no error, the SWIMA-PC MUST generate a response attribute without regard to the presence of this flag, in addition to clearing its subscription list.
请求建立订阅的属性实际上是在执行“双重职责”，因为除了设置订阅外，它还请求SWIMA-PC立即响应。假设SWIMA-PC愿意遵守订阅，它必须向包含所有请求信息的订阅标志集的请求发送适当的响应属性。Clear Subscriptions标志也是如此——假设没有错误，SWIMA-PC除了清除其订阅列表外，还必须生成响应属性，而不考虑该标志的存在。
Both the Subscribe flag and the Clear Subscriptions flag MAY be set in a single SWIMA Request attribute. In the case where this request is successful, the end result MUST be equivalent to the SWIMA-PC clearing its subscription list for the given SWIMA-PV first and then creating a new subscription in accordance with the request parameters. In other words, do not first create the new subscription and then clear all the subscriptions (including the one that was just created). In the case that the requested actions are successfully completed, the SWIMA-PC MUST respond with a SWIMA Response attribute. The specific type of SWIMA Response attribute depends on the Result Type flag and the Earliest EID field, as described above. In the case where there is a failure that prevents some part of this request from completing, the SWIMA-PC MUST NOT add a new subscription, MUST NOT clear the old subscriptions, and MUST respond with a PA-TNC Error attribute. In other words, the SWIMA-PC MUST NOT partially succeed at implementing such a request; either all actions succeed or none succeed.
可以在单个SWIMA请求属性中设置订阅标志和清除订阅标志。在该请求成功的情况下，最终结果必须等同于SWIMA-PC首先清除给定SWIMA-PV的订阅列表，然后根据请求参数创建新订阅。换句话说，不要先创建新订阅，然后清除所有订阅（包括刚刚创建的订阅）。如果请求的操作成功完成，SWIMA-PC必须使用SWIMA响应属性进行响应。SWIMA响应属性的特定类型取决于结果类型标志和最早的EID字段，如上所述。如果出现故障导致该请求的某些部分无法完成，则SWIMA-PC不得添加新订阅，不得清除旧订阅，并且必须使用PA-TNC Error属性进行响应。换言之，SWIMA-PC不得部分成功实施此类请求；要么所有操作都成功，要么没有成功。
The Earliest EID field is used to indicate if the SWIMA-PV is requesting an inventory or event list from the SWIMA-PC. A value of 0 (0x00000000) represents a request for inventory information. Otherwise, the SWIMA-PV is requesting event information. For Earliest EID values other than 0, the SWIMA-PC MUST respond with event records, as described in Section 3.7. Note that the request does not identify a particular EID Epoch, since responses can only include events in the SWIMA-PC's current EID Epoch.
最早的EID字段用于指示SWIMA-PV是否从SWIMA-PC请求库存或事件列表。值0（0x00000000）表示请求库存信息。否则，SWIMA-PV将请求事件信息。如第3.7节所述，对于除0以外的最早EID值，SWIMA-PC必须使用事件记录进行响应。请注意，请求没有标识特定的EID历元，因为响应只能包括SWIMA-PC当前EID历元中的事件。
The Software Identifier Count indicates the number of Software Identifiers in the attribute. This number might be any value between 0 and 16,777,216, inclusive. A single Software Identifier is represented by the following fields: Software Identifier Length and Software Identifier. These fields are repeated a number of times equal to the Software Identifier Count, which may be 0. The Software Identifier Length field indicates the number of bytes allocated to the Software Identifier field. The Software Identifier field contains a Software Identifier as described in Section 3.4.1. The presence of one or more Software Identifiers is used by the SWIMA-PV to indicate a targeted request, which seeks only inventories of or events affecting software corresponding to the given identifiers. The SWIMA-PC MUST only report software that matched the Software Identifiers provided in the SWIMA-PV's SWIMA Request attribute.
软件标识符计数指示属性中软件标识符的数量。此数字可能是介于0和16777216（含）之间的任何值。单个软件标识符由以下字段表示：软件标识符长度和软件标识符。这些字段重复的次数等于软件标识符计数，可能为0。软件标识符长度字段表示分配给软件标识符字段的字节数。软件标识符字段包含第3.4.1节所述的软件标识符。SWIMA-PV使用一个或多个软件标识符的存在来指示目标请求，其仅寻求与给定标识符对应的软件的清单或影响软件的事件。SWIMA-PC必须仅报告与SWIMA-PV的SWIMA请求属性中提供的软件标识符相匹配的软件。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey the inventory of the endpoint's Software Inventory Evidence Collection without the inclusion of Software Inventory Evidence Records. This list might represent a complete inventory or a targeted list of records, depending on the parameters in the SWIMA-PV's request. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 1 and the Earliest EID is zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 1 and the Earliest EID is zero.
SWIMA-PC将此属性发送给SWIMA-PV，以传递端点软件清单证据收集的清单，而不包括软件清单证据记录。根据SWIMA-PV请求中的参数，此列表可能表示完整的库存或目标记录列表。SWIMA-PV不得发送此属性。SWIMA-PC发送此属性（1）以满足现有订阅，其中建立请求的结果类型为1，最早的EID为零；或（2）直接响应SWIMA请求属性，其中结果类型为1，最早的EID为零。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Software Identifier Inventory Attribute
图8：软件标识符清单属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Reserved | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Reserved | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Software Identifier Inventory Attribute SUB-BLOCK
图9：软件标识符清单属性子块
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | The number of Software Identifiers that follow. |
| Identifier | This field is an unsigned integer. The Record |
| Count | Identifier, Data Model Type PEN, Data Model |
| | Type, Source Identification Number, Reserved, |
| | Software Identifier Length, Software Identifier, |
| | Software Locator Length, and Software Locator |
| | fields are repeated, in order, the number of |
| | times indicated in this field. This field value |
| | MAY be 0, in which case there are no instances |
| | of these fields. |
| | |
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | The number of Software Identifiers that follow. |
| Identifier | This field is an unsigned integer. The Record |
| Count | Identifier, Data Model Type PEN, Data Model |
| | Type, Source Identification Number, Reserved, |
| | Software Identifier Length, Software Identifier, |
| | Software Locator Length, and Software Locator |
| | fields are repeated, in order, the number of |
| | times indicated in this field. This field value |
| | MAY be 0, in which case there are no instances |
| | of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field is a 4-byte unsigned |
| | integer. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the Private |
| Type PEN | Enterprise Number (PEN) of the organization that |
| | assigned the meaning of the Data Model Type |
| | value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source from which this software installation |
| Number | inventory instance was reported. |
| | |
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 5.4. |
| | This string MUST NOT be null terminated. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field is a 4-byte unsigned |
| | integer. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the Private |
| Type PEN | Enterprise Number (PEN) of the organization that |
| | assigned the meaning of the Data Model Type |
| | value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source from which this software installation |
| Number | inventory instance was reported. |
| | |
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 5.4. |
| | This string MUST NOT be null terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
+----------------+--------------------------------------------------+
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
+----------------+--------------------------------------------------+
Table 3: Software Identifier Inventory Attribute Fields
表3：软件标识符清单属性字段
In the case that this attribute is sent in fulfillment of a subscription, the Subscription Fulfillment bit MUST be set (1). In the case that this attribute is sent in direct response to a SWIMA Request, the Subscription Fulfillment bit MUST be unset (0). Note that the SWIMA Response attribute sent in direct response to a SWIMA Request that establishes a subscription (i.e., a subscription's establishing request) MUST be treated as a direct response to that SWIMA Request (and thus the Subscription Fulfillment bit is unset). SWIMA Response attributes are only treated as being in fulfillment of a subscription (i.e., Subscription Fulfillment bit set) if they are sent following a change event, as shown in Figure 3.
如果在履行订阅时发送此属性，则必须设置订阅履行位（1）。在直接响应SWIMA请求发送此属性的情况下，订阅履行位必须未设置（0）。请注意，在直接响应建立订阅的SWIMA请求（即订阅的建立请求）时发送的SWIMA响应属性必须视为对该SWIMA请求的直接响应（因此订阅履行位未设置）。如果SWIMA响应属性是在更改事件之后发送的，则仅将其视为正在履行订阅（即，订阅履行位集），如图3所示。
The Software Identifier Count field indicates the number of Software Identifiers present in this inventory. Each Software Identifier is represented by the following set of fields: Record Identifier, Data Model Type PEN, Data Model Type, Source Identification Number, Reserved, Software Identifier Length, Software Identifier, Software Locator Length, and Software Locator. These fields will appear once for each reported record.
软件标识符计数字段指示此清单中存在的软件标识符的数量。每个软件标识符由以下字段集表示：记录标识符、数据模型类型笔、数据模型类型、源标识号、保留、软件标识符长度、软件标识符、软件定位器长度和软件定位器。对于每个报告的记录，这些字段将显示一次。
When responding directly to a SWIMA Request attribute, the Request ID Copy / Subscription ID field MUST contain an exact copy of the Request ID field from that SWIMA Request. When this attribute is sent in fulfillment of an existing subscription on this SWIMA-PC, this field MUST contain the Subscription ID of the fulfilled subscription.
直接响应SWIMA请求属性时，请求ID副本/订阅ID字段必须包含来自该SWIMA请求的请求ID字段的精确副本。当发送此属性以完成此SWIMA-PC上的现有订阅时，此字段必须包含已完成订阅的订阅ID。
The EID Epoch field indicates the EID Epoch of the Last EID value. The Last EID field MUST contain the EID of the last recorded change event (see Section 3.7 for more about EIDs and recorded events) at the time this inventory was collected. In the case where there are no recorded change events at the time that this inventory was collected, the Last EID field MUST contain 0. These fields can be
EID历元字段指示最后一个EID值的EID历元。最后一个EID字段必须包含收集此清单时最后记录的更改事件的EID（有关EID和记录的事件的更多信息，请参阅第3.7节）。如果在收集此资源清册时没有记录的更改事件，则最后一个EID字段必须包含0。这些字段可以是
interpreted to indicate that the provided inventory reflects the state of the endpoint after all changes up to and including this last event have been accounted for.
解释为表明所提供的清单反映了在最后一个事件之前（包括最后一个事件）的所有更改都已被考虑之后端点的状态。
The Data Model Type PEN and Data Model Type fields are used to identify the data model associated with the given software record. These fields are discussed more in Section 3.4.2.
数据模型类型笔和数据模型类型字段用于标识与给定软件记录关联的数据模型。第3.4.2节对这些字段进行了详细讨论。
The Source Identification Number field is used to identify the source that provided the given record, as described in Section 3.1.
源标识号字段用于标识提供给定记录的源，如第3.1节所述。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey events where the affected records are reported without Software Inventory Evidence Records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 1 and the Earliest EID is non-zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 1 and the Earliest EID is non-zero.
SWIMA-PC将此属性发送给SWIMA-PV，以传递受影响记录报告时没有软件库存证据记录的事件。SWIMA-PV不得发送此属性。SWIMA-PC发送此属性（1）用于满足现有订阅，其中建立请求的结果类型为1，最早的EID为非零；或（2）直接响应SWIMA请求属性，其中结果类型为1，最早的EID为非零。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Event Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Event Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Software Identifier Events Attribute
图10：软件标识符事件属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Timestamp |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Action | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Timestamp |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Action | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Software Identifier Events Attribute SUB-BLOCK
图11：软件标识符事件属性子块
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Event Count | The number of events that are reported in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Source |
| | Identification Number, Action, Software |
| | Identifier Length, Software Identifier, Software |
| | Locator Length, and Software Locator fields are |
| | repeated, in order, the number of times |
| | indicated in this field. This field value MAY |
| | be 0, in which case there are no instances of |
| | these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field contains the EID of the |
| | SWIMA-PC's last recorded change event (which |
| | might or might not be included as an event |
| | record in this attribute). |
| | |
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Event Count | The number of events that are reported in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Source |
| | Identification Number, Action, Software |
| | Identifier Length, Software Identifier, Software |
| | Locator Length, and Software Locator fields are |
| | repeated, in order, the number of times |
| | indicated in this field. This field value MAY |
| | be 0, in which case there are no instances of |
| | these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field contains the EID of the |
| | SWIMA-PC's last recorded change event (which |
| | might or might not be included as an event |
| | record in this attribute). |
| | |
| Last Consulted | The EID of the last event record that was |
| EID | consulted when generating the event record list |
| | included in this attribute. This is different |
| | from the Last EID field value if and only if |
| | this attribute is conveying a partial list of |
| | event records. See Section 3.7.5 for more on |
| | partial lists of event records. |
| | |
| EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SWIMA-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as an ASCII string that is expressed |
| | in Coordinated Universal Time (UTC) and is |
| | compliant with RFC 3339 [RFC3339], with the |
| | additional restrictions that the 'T' delimiter |
| | and the 'Z' suffix MUST be capitalized and |
| | fractional seconds (time-secfrac) MUST NOT be |
| | included. This field conforms to the date-time |
| | ABNF production from Section 5.6 of RFC 3339, |
| | with the above restrictions. Leap seconds are |
| | permitted, and SWIMA-PVs MUST support them. The |
| | Timestamp string MUST NOT be null terminated or |
| | padded in any way. The length of this field is |
| | always 20 octets. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source for the software installation inventory |
| Number | instance that this event record reported. |
| | |
| Last Consulted | The EID of the last event record that was |
| EID | consulted when generating the event record list |
| | included in this attribute. This is different |
| | from the Last EID field value if and only if |
| | this attribute is conveying a partial list of |
| | event records. See Section 3.7.5 for more on |
| | partial lists of event records. |
| | |
| EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SWIMA-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as an ASCII string that is expressed |
| | in Coordinated Universal Time (UTC) and is |
| | compliant with RFC 3339 [RFC3339], with the |
| | additional restrictions that the 'T' delimiter |
| | and the 'Z' suffix MUST be capitalized and |
| | fractional seconds (time-secfrac) MUST NOT be |
| | included. This field conforms to the date-time |
| | ABNF production from Section 5.6 of RFC 3339, |
| | with the above restrictions. Leap seconds are |
| | permitted, and SWIMA-PVs MUST support them. The |
| | Timestamp string MUST NOT be null terminated or |
| | padded in any way. The length of this field is |
| | always 20 octets. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source for the software installation inventory |
| Number | instance that this event record reported. |
| | |
| Action | The type of event that is recorded in this event |
| | record. Possible values are as follows: 1 = |
| | CREATION - the addition of a record to the |
| | endpoint's Software Inventory Evidence |
| | Collection; 2 = DELETION - the removal of a |
| | record from the endpoint's Software Inventory |
| | Evidence Collection; 3 = ALTERATION - an |
| | alteration that was made to a record within the |
| | endpoint's Software Inventory Evidence |
| | Collection. All other values are reserved for |
| | future use and MUST NOT be used when sending |
| | attributes. In the case where a SWIMA-PV |
| | receives an event record that uses an action |
| | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
+----------------+--------------------------------------------------+
| Action | The type of event that is recorded in this event |
| | record. Possible values are as follows: 1 = |
| | CREATION - the addition of a record to the |
| | endpoint's Software Inventory Evidence |
| | Collection; 2 = DELETION - the removal of a |
| | record from the endpoint's Software Inventory |
| | Evidence Collection; 3 = ALTERATION - an |
| | alteration that was made to a record within the |
| | endpoint's Software Inventory Evidence |
| | Collection. All other values are reserved for |
| | future use and MUST NOT be used when sending |
| | attributes. In the case where a SWIMA-PV |
| | receives an event record that uses an action |
| | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
+----------------+--------------------------------------------------+
Table 4: Software Identifier Events Attribute Fields
表4：软件标识符事件属性字段
The first few fields in the Software Identifier Events attribute mirror those in the Software Identifier Inventory attribute. The primary difference is that instead of conveying an inventory the attribute conveys zero or more event records, consisting of the EID, Timestamp, Record Identifier, Data Model Type PEN, Data Model Type,
“软件标识符事件”属性中的前几个字段镜像了“软件标识符清单”属性中的字段。主要区别在于，该属性不传递库存，而是传递零个或多个事件记录，包括EID、时间戳、记录标识符、数据模型类型笔、数据模型类型、，
Source Identification Number, Action, Software Identifier Length, Software Identifier, Software Locator Length, and Software Locator fields of the affected Software Inventory Evidence Record.
受影响软件清单证据记录的源标识号、操作、软件标识符长度、软件标识符、软件定位器长度和软件定位器字段。
With regard to the Timestamp field, it is important to note that clock skew between the SWIMA-PC and SWIMA-PV as well as between different SWIMA-PCs within an enterprise might make correlation of Timestamp values difficult. This specification does not attempt to resolve clock skew issues, although other mechanisms (which are outside the scope of this specification) do exist to reduce the impact of clock skew and make the timestamp more useful for such correlation. Instead, SWIMA uses the Timestamp value primarily as a means to indicate the amount of time between two events on a single endpoint. For example, by taking the difference of the times for when a record was removed and then subsequently re-added, one can get an indication as to how long the system was without the given record (and thus without the associated software). Since this will involve comparison of Timestamp values all originating on the same system, clock skew between the SWIMA-PC and SWIMA-PV is not an issue. However, if the SWIMA-PC's clock was adjusted between two recorded events, it is possible for such a calculation to lead to misunderstandings regarding the temporal distance between events. Users of this field need to be aware of the possibility for such occurrences. In the case where the Timestamp values of two events appear to contradict the EID ordering of those events (i.e., the later EID has an earlier timestamp), the recipient MUST treat the EID ordering as correct.
关于时间戳字段，需要注意的是，SWIMA-PC和SWIMA-PV之间以及企业内不同SWIMA PC之间的时钟偏移可能会使时间戳值的关联变得困难。本规范不试图解决时钟偏移问题，尽管存在其他机制（不在本规范范围内）以减少时钟偏移的影响，并使时间戳对此类相关性更有用。相反，SWIMA主要将时间戳值用作指示单个端点上两个事件之间的时间量的方法。例如，通过获取记录被删除然后重新添加的时间差，可以得到系统没有给定记录（因此没有相关软件）的时间指示。由于这将涉及对源自同一系统的所有时间戳值的比较，所以SWIMA-PC和SWIMA-PV之间的时钟偏差不是问题。但是，如果在两个记录的事件之间调整了SWIMA-PC的时钟，则此类计算可能导致对事件之间时间距离的误解。该领域的用户需要了解此类事件的可能性。如果两个事件的时间戳值似乎与这些事件的EID顺序相矛盾（即，较后的EID具有较早的时间戳），则接收方必须将EID顺序视为正确。
All events recorded in a Software Identifier Events attribute are required to be part of the same EID Epoch. Specifically, all such reported events MUST have an EID that is from the same EID Epoch and that is the same as the EID Epoch of the Last EID and Last Consulted EID values. The SWIMA-PC MUST NOT report events with EIDs from different EID Epochs.
软件标识符事件属性中记录的所有事件都必须是同一EID历元的一部分。具体而言，所有此类报告的事件必须具有来自同一EID历元且与上一个EID和上一个参考EID值的EID历元相同的EID。SWIMA-PC不得报告来自不同EID时期的EID事件。
The Last Consulted EID field contains the EID of the last event record considered for inclusion in this attribute. If this attribute contains a partial event set (as described in Section 3.7.5), this field value will be less than the Last EID value; if this attribute contains a complete event set, the Last EID and Last Consulted EID values are identical.
Last Consulted EID字段包含考虑包含在此属性中的最后一条事件记录的EID。如果该属性包含部分事件集（如第3.7.5节所述），则该字段值将小于上一个EID值；如果此属性包含完整的事件集，则上次EID值和上次参考的EID值相同。
If multiple events are sent in a Software Identifier Events attribute, the order in which they appear within the attribute is not significant. The EIDs associated with them are used for ordering the indicated events appropriately. Also note that a single software record might be reported multiple times in an attribute, such as if multiple events involving the associated record were being reported.
如果在“软件标识符事件”属性中发送多个事件，则它们在该属性中的显示顺序并不重要。与之关联的EID用于对指示的事件进行适当排序。还请注意，单个软件记录可能会在属性中报告多次，例如，如果报告涉及关联记录的多个事件。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of inventory records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 0 and the Earliest EID is zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 0 and the Earliest EID is zero.
SWIMA-PC将此属性发送给SWIMA-PV，以传递库存记录列表。SWIMA-PV不得发送此属性。SWIMA-PC发送此属性（1）以满足现有订阅，其中建立请求的结果类型为0，最早的EID为零；或（2）直接响应SWIMA请求属性，其中结果类型为0，最早的EID为零。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Record Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Record Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Software Inventory Attribute
图12：软件清单属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Reserved | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Reserved | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Software Inventory Attribute SUB-BLOCK
图13：软件清单属性子块
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Record Count | The number of records that follow. This field |
| | is a 3-byte unsigned integer. The Record |
| | Identifier, Data Model Type PEN, Data Model |
| | Type, Source Identification Number, Reserved, |
| | Software Identifier Length, Software Identifier, |
| | Software Locator Length, Software Locator, |
| | Record Length, and Record fields are repeated, |
| | in order, the number of times indicated in this |
| | field. This field value MAY be 0, in which case |
| | there are no instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field is a 4-byte unsigned |
| | integer. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Record Count | The number of records that follow. This field |
| | is a 3-byte unsigned integer. The Record |
| | Identifier, Data Model Type PEN, Data Model |
| | Type, Source Identification Number, Reserved, |
| | Software Identifier Length, Software Identifier, |
| | Software Locator Length, Software Locator, |
| | Record Length, and Record fields are repeated, |
| | in order, the number of times indicated in this |
| | field. This field value MAY be 0, in which case |
| | there are no instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field is a 4-byte unsigned |
| | integer. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source from which this software installation |
| Number | inventory instance was reported. |
| | |
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
| | |
| Record Length | A 4-byte unsigned integer indicating the length, |
| | in bytes, of the Record field. |
| | |
| Record | A Software Inventory Evidence Record expressed |
| | as a string. The record MUST be converted and |
| | normalized to Network Unicode format, as |
| | described in Section 5.4. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source from which this software installation |
| Number | inventory instance was reported. |
| | |
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
| | |
| Record Length | A 4-byte unsigned integer indicating the length, |
| | in bytes, of the Record field. |
| | |
| Record | A Software Inventory Evidence Record expressed |
| | as a string. The record MUST be converted and |
| | normalized to Network Unicode format, as |
| | described in Section 5.4. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
Table 5: Software Inventory Attribute Fields
表5：软件清单属性字段
The Software Inventory attribute contains some number of Software Inventory Evidence Records along with the core response attribute fields. Given that the size of records can vary considerably, the length of this attribute is highly variable and, if transmitting a complete inventory, can be extremely large. To avoid unnecessarily overburdening the network, enterprises might wish to constrain the use of Software Inventory attributes to targeted requests.
软件清单属性包含一些软件清单证据记录以及核心响应属性字段。考虑到记录的大小可能会有很大的变化，此属性的长度是高度可变的，如果传输完整的库存，则可能会非常大。为了避免不必要的网络负担过重，企业可能希望将软件清单属性的使用限制到目标请求。
When copying a Software Inventory Evidence Record into the Record field, the record MUST be converted and normalized to use Network Unicode format prior to its inclusion in the Record field.
将软件清单证据记录复制到记录字段中时，在将记录包含在记录字段中之前，必须将该记录转换并规范化为使用网络Unicode格式。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of events that include Software Inventory Evidence Records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 0 and the Earliest EID is non-zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 0 and the Earliest EID is non-zero.
SWIMA-PC将此属性发送给SWIMA-PV，以传递包含软件清单证据记录的事件列表。SWIMA-PV不得发送此属性。SWIMA-PC发送此属性（1）以满足现有订阅，其中建立请求的结果类型为0且最早的EID为非零，或（2）直接响应SWIMA请求属性，其中结果类型为0且最早的EID为非零。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Event Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Event Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Software Events Attribute
图14：软件事件属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Timestamp |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Action | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Timestamp |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Action | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Software Events Attribute SUB-BLOCK
图15：软件事件属性子块
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Event Count | The number of events being reported in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Source |
| | Identification Number, Action, Software |
| | Identifier Length, Software Identifier, Software |
| | Locator Length, Software Locator, Record Length, |
| | and Record fields are repeated, in order, the |
| | number of times indicated in this field. This |
| | field value MAY be 0, in which case there are no |
| | instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field contains the EID of the |
| | SWIMA-PC's last recorded change event (which |
| | might or might not be included as an event |
| | record in this attribute). |
| | |
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Event Count | The number of events being reported in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Source |
| | Identification Number, Action, Software |
| | Identifier Length, Software Identifier, Software |
| | Locator Length, Software Locator, Record Length, |
| | and Record fields are repeated, in order, the |
| | number of times indicated in this field. This |
| | field value MAY be 0, in which case there are no |
| | instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field contains the EID of the |
| | SWIMA-PC's last recorded change event (which |
| | might or might not be included as an event |
| | record in this attribute). |
| | |
| Last Consulted | The EID of the last event record that was |
| EID | consulted when generating the event record list |
| | included in this attribute. This is different |
| | from the Last EID field value if and only if |
| | this attribute is conveying a partial list of |
| | event records. See Section 3.7.5 for more on |
| | partial lists of event records. |
| | |
| EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SWIMA-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as an ASCII string that is expressed |
| | in Coordinated Universal Time (UTC) and is |
| | compliant with RFC 3339 [RFC3339], with the |
| | additional restrictions that the 'T' delimiter |
| | and the 'Z' suffix MUST be capitalized and |
| | fractional seconds (time-secfrac) MUST NOT be |
| | included. This field conforms to the date-time |
| | ABNF production from Section 5.6 of RFC 3339, |
| | with the above restrictions. Leap seconds are |
| | permitted, and SWIMA-PVs MUST support them. The |
| | Timestamp string MUST NOT be null terminated or |
| | padded in any way. The length of this field is |
| | always 20 octets. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source for the software installation inventory |
| Number | instance that this event record reported. |
| | |
| Last Consulted | The EID of the last event record that was |
| EID | consulted when generating the event record list |
| | included in this attribute. This is different |
| | from the Last EID field value if and only if |
| | this attribute is conveying a partial list of |
| | event records. See Section 3.7.5 for more on |
| | partial lists of event records. |
| | |
| EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SWIMA-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as an ASCII string that is expressed |
| | in Coordinated Universal Time (UTC) and is |
| | compliant with RFC 3339 [RFC3339], with the |
| | additional restrictions that the 'T' delimiter |
| | and the 'Z' suffix MUST be capitalized and |
| | fractional seconds (time-secfrac) MUST NOT be |
| | included. This field conforms to the date-time |
| | ABNF production from Section 5.6 of RFC 3339, |
| | with the above restrictions. Leap seconds are |
| | permitted, and SWIMA-PVs MUST support them. The |
| | Timestamp string MUST NOT be null terminated or |
| | padded in any way. The length of this field is |
| | always 20 octets. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source for the software installation inventory |
| Number | instance that this event record reported. |
| | |
| Action | The type of event that is recorded in this event |
| | record. Possible values are as follows: 1 = |
| | CREATION - the addition of a record to the |
| | endpoint's Software Inventory Evidence |
| | Collection; 2 = DELETION - the removal of a |
| | record from the endpoint's Software Inventory |
| | Evidence Collection; 3 = ALTERATION - an |
| | alteration that was made to a record within the |
| | endpoint's Software Inventory Evidence |
| | Collection. All other values are reserved for |
| | future use and MUST NOT be used when sending |
| | attributes. In the case where a SWIMA-PV |
| | receives an event record that uses an action |
| | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
| | |
| Action | The type of event that is recorded in this event |
| | record. Possible values are as follows: 1 = |
| | CREATION - the addition of a record to the |
| | endpoint's Software Inventory Evidence |
| | Collection; 2 = DELETION - the removal of a |
| | record from the endpoint's Software Inventory |
| | Evidence Collection; 3 = ALTERATION - an |
| | alteration that was made to a record within the |
| | endpoint's Software Inventory Evidence |
| | Collection. All other values are reserved for |
| | future use and MUST NOT be used when sending |
| | attributes. In the case where a SWIMA-PV |
| | receives an event record that uses an action |
| | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
| | |
| Record Length | A 4-byte unsigned integer indicating the length, |
| | in bytes, of the Record field. |
| | |
| Record | A Software Inventory Evidence Record expressed |
| | as a string. The record MUST be converted and |
| | normalized to Network Unicode format, as |
| | described in Section 5.4. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
| Record Length | A 4-byte unsigned integer indicating the length, |
| | in bytes, of the Record field. |
| | |
| Record | A Software Inventory Evidence Record expressed |
| | as a string. The record MUST be converted and |
| | normalized to Network Unicode format, as |
| | described in Section 5.4. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
Table 6: Software Events Attribute Fields
表6：软件事件属性字段
The fields of this attribute are used in the same way as the corresponding fields of the previous attributes. As with the Software Inventory attribute, a Software Events attribute can be quite large if many events have occurred following the event indicated by a request's Earliest EID. As such, it is recommended that the SWIMA Request attributes only request that full records be sent (Result Type set to zero) in a targeted request, thus constraining the response just to records that match a given set of Software Identifiers.
此属性的字段的使用方式与前面属性的相应字段相同。与“软件资源清册”属性一样，如果在请求最早的EID指示的事件之后发生了许多事件，则“软件事件”属性可能会非常大。因此，建议SWIMA请求属性仅请求在目标请求中发送完整记录（结果类型设置为零），从而将响应限制为仅与给定软件标识符集匹配的记录。
As with the Software Identifier Events attribute, this attribute MUST only contain event records with EIDs coming from the current EID Epoch of the SWIMA-PC.
与“软件标识符事件”属性一样，此属性必须仅包含EID来自SWIMA-PC当前EID纪元的事件记录。
As with the Software Inventory attribute, the SWIMA-PC MUST perform conversion and normalization of the record.
与“软件资源清册”属性一样，SWIMA-PC必须执行记录的转换和规范化。
A SWIMA-PV sends this attribute to a SWIMA-PC to request a list of active subscriptions for which the requesting SWIMA-PV is the subscriber. A SWIMA-PC MUST NOT send this attribute.
SWIMA-PV将此属性发送给SWIMA-PC，以请求活动订阅列表，请求的SWIMA-PV是该订阅的订阅方。SWIMA-PC不得发送此属性。
This attribute has no fields.
此属性没有字段。
A SWIMA-PC MUST respond to this attribute by sending a Subscription Status Response attribute (or a PA-TNC Error attribute if it is unable to correctly provide a response).
SWIMA-PC必须通过发送订阅状态响应属性（如果无法正确提供响应，则发送PA-TNC错误属性）来响应此属性。
A SWIMA-PC sends this attribute to a SWIMA-PV to report the list of active subscriptions for which the receiving SWIMA-PV is the subscriber. A SWIMA-PV MUST NOT send this attribute.
SWIMA-PC将此属性发送给SWIMA-PV，以报告接收SWIMA-PV为订阅方的活动订阅列表。SWIMA-PV不得发送此属性。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Subscription Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Subscription Record Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Subscription Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Subscription Record Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Subscription Status Response Attribute
图16：订阅状态响应属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Subscription Status Response Attribute SUB-BLOCK
图17：订阅状态响应属性子块
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Subscription Status Response Attribute SUB-SUB-BLOCK
图18：订阅状态响应属性子块
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Status | Reserved for future use. This field MUST be set |
| Flags: Bits | to zero on transmission and ignored upon |
| 0-7 - | reception. |
| Reserved | |
| | |
| Subscription | The number of subscription records that follow. |
| Record Count | This field is a 3-byte unsigned integer. The |
| | Flags, Software Identifier Count, Request ID, and |
| | Earliest EID fields, and zero or more instances of |
| | Software Identifier Length and Software |
| | Identifier, are repeated, in order, the number of |
| | times indicated in this field. (The Software |
| | Identifier Length and Software Identifier fields |
| | within each of these sets of fields are repeated a |
| | number of times equal to the preceding Software |
| | Identifier Count value.) The Subscription Record |
| | Count field value MAY be 0, in which case there |
| | are no instances of these fields. |
| | |
| Flags, | For each active subscription, these fields contain |
| Software | an exact copy of the fields with the corresponding |
| Identifier | name provided in the subscription's establishing |
| Count, | request. |
| Request ID, | |
| Earliest | |
| EID, | |
| Software | |
| Identifier | |
| Length, and | |
| Software | |
| Identifier | |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Status | Reserved for future use. This field MUST be set |
| Flags: Bits | to zero on transmission and ignored upon |
| 0-7 - | reception. |
| Reserved | |
| | |
| Subscription | The number of subscription records that follow. |
| Record Count | This field is a 3-byte unsigned integer. The |
| | Flags, Software Identifier Count, Request ID, and |
| | Earliest EID fields, and zero or more instances of |
| | Software Identifier Length and Software |
| | Identifier, are repeated, in order, the number of |
| | times indicated in this field. (The Software |
| | Identifier Length and Software Identifier fields |
| | within each of these sets of fields are repeated a |
| | number of times equal to the preceding Software |
| | Identifier Count value.) The Subscription Record |
| | Count field value MAY be 0, in which case there |
| | are no instances of these fields. |
| | |
| Flags, | For each active subscription, these fields contain |
| Software | an exact copy of the fields with the corresponding |
| Identifier | name provided in the subscription's establishing |
| Count, | request. |
| Request ID, | |
| Earliest | |
| EID, | |
| Software | |
| Identifier | |
| Length, and | |
| Software | |
| Identifier | |
+--------------+----------------------------------------------------+
Table 7: Subscription Status Response Fields
表7：订阅状态响应字段
A Subscription Status Response contains zero or more subscription records. Specifically, it MUST contain one subscription record for each active subscription associated with the party that sent the Subscription Status Request to which this attribute is a response. As described in Section 3.8.2, the SWIMA-PC MUST use the requester's Connection ID and its Posture Validator Identifier to determine which subscriptions are associated with the requester.
订阅状态响应包含零个或多个订阅记录。具体而言，它必须包含与发送订阅状态请求（此属性为响应）的一方关联的每个活动订阅的一条订阅记录。如第3.8.2节所述，SWIMA-PC必须使用请求者的连接ID及其姿态验证器标识符来确定哪些订阅与请求者关联。
A SWIMA-PC MUST send a Subscription Status Response attribute in response to a Subscription Status Request attribute, except in cases where the SWIMA-PC experiences an error condition that prevents it from correctly populating the Subscription Status Response attribute (in which case it MUST respond with a PA-TNC Error attribute appropriate to the type of error experienced). If there are no active subscriptions associated with the requesting party, the Subscription Status Response attribute will consist only of its Status Flags field and a Subscription Record Count field with a value of 0, and no additional fields.
SWIMA-PC必须发送订阅状态响应属性以响应订阅状态请求属性，除非SWIMA-PC遇到错误情况，导致其无法正确填充订阅状态响应属性（在这种情况下，它必须使用与所经历的错误类型相适应的PA-TNC错误属性进行响应）。如果没有与请求方关联的活动订阅，则订阅状态响应属性将仅包含其状态标志字段和值为0的订阅记录计数字段，而不包含其他字段。
Each subscription record included in a Subscription Status Response attribute duplicates the fields of the SWIMA Request attribute that was the establishing request of a subscription. Note that the Request ID field in the record captures the Subscription ID associated with the given subscription record (since the Subscription ID is the same as the Request ID of the establishing request). Note also that if the establishing request is targeted, then its Record Count field will be non-zero and, within that subscription record, the Software Identifier Length and Software Identifier fields are repeated, in order, the number of times indicated in the Record Count field. As such, each subscription record can be different sizes. If the establishing request is not targeted (Record Count field is 0), the subscription record has no Software Identifier Length or Software Identifier fields.
订阅状态响应属性中包含的每个订阅记录都与作为订阅建立请求的SWIMA请求属性的字段重复。请注意，记录中的请求ID字段捕获与给定订阅记录关联的订阅ID（因为订阅ID与建立请求的请求ID相同）。还请注意，如果建立请求是目标，则其记录计数字段将非零，并且在该订阅记录中，软件标识符长度和软件标识符字段将按记录计数字段中指示的次数顺序重复。因此，每个订阅记录可以有不同的大小。如果建立请求不是目标（记录计数字段为0），则订阅记录没有软件标识符长度或软件标识符字段。
When a SWIMA-PV compares the information received in a Subscription Status Response to its own records of active subscriptions, it should be aware that the SWIMA-PC might be unable to distinguish this SWIMA-PV from other SWIMA-PVs on the same NEA Server. As a result, it is possible that the SWIMA-PC will report more subscription records than the SWIMA-PV recognizes. For this reason, SWIMA-PVs SHOULD NOT automatically assume that extra subscriptions reported in a Subscription Status Response indicate a problem.
当SWIMA-PV将订阅状态响应中收到的信息与其自己的活动订阅记录进行比较时，应注意SWIMA-PC可能无法将此SWIMA-PV与同一NEA服务器上的其他SWIMA PV区分开来。因此，SWIMA-PC可能会报告比SWIMA-PV认识到的更多的订阅记录。因此，SWIMA PVs不应自动假定订阅状态响应中报告的额外订阅表明存在问题。
A SWIMA-PV sends this attribute to a SWIMA-PC to request metadata about sources that the SWIMA-PC is using to collect software inventory information. A SWIMA-PC MUST NOT send this attribute.
SWIMA-PV将此属性发送给SWIMA-PC，以请求有关SWIMA-PC用于收集软件清单信息的源的元数据。SWIMA-PC不得发送此属性。
This attribute has no fields.
此属性没有字段。
A SWIMA-PC MUST respond to this attribute by sending a Source Metadata Response attribute (or a PA-TNC Error attribute if it is unable to correctly provide a response).
SWIMA-PC必须通过发送源元数据响应属性（如果无法正确提供响应，则发送PA-TNC错误属性）来响应此属性。
A SWIMA-PC sends this attribute to a SWIMA-PV to provide descriptive metadata about the sources of software inventory information used by the SWIMA-PC. A SWIMA-PV MUST NOT send this attribute.
SWIMA-PC向SWIMA-PV发送此属性，以提供有关SWIMA-PC使用的软件清单信息源的描述性元数据。SWIMA-PV不得发送此属性。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| SUB-BLOCK (Repeated "Source Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| SUB-BLOCK (Repeated "Source Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Source Metadata Response Attribute
图19：源元数据响应属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Metadata Length | Metadata (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Metadata Length | Metadata (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Source Metadata Response Attribute SUB-BLOCK
图20：源元数据响应属性子块
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Source Count | The number of source records that follow. The |
| | Source Identification Number, Metadata Length, |
| | and Metadata fields are repeated, in order, the |
| | number of times indicated by this field. This |
| | field MAY be 0, in which case no fields follow |
| | (but this would only be done to indicate that |
| | the SWIMA-PC has no active sources; this would |
| | not be a typical situation). |
| | |
| Source | The Source Identifier number associated with the |
| Identification | described source for any communications with the |
| Number | recipient SWIMA-PV. |
| | |
| Metadata | A 2-byte unsigned integer indicating the length, |
| Length | in bytes, of the Metadata field. |
| | |
| Metadata | A string containing descriptive metadata about |
| | the indicated data source. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Source Count | The number of source records that follow. The |
| | Source Identification Number, Metadata Length, |
| | and Metadata fields are repeated, in order, the |
| | number of times indicated by this field. This |
| | field MAY be 0, in which case no fields follow |
| | (but this would only be done to indicate that |
| | the SWIMA-PC has no active sources; this would |
| | not be a typical situation). |
| | |
| Source | The Source Identifier number associated with the |
| Identification | described source for any communications with the |
| Number | recipient SWIMA-PV. |
| | |
| Metadata | A 2-byte unsigned integer indicating the length, |
| Length | in bytes, of the Metadata field. |
| | |
| Metadata | A string containing descriptive metadata about |
| | the indicated data source. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
Table 8: Source Metadata Response Fields
表8：源元数据响应字段
A Source Metadata Response attribute contains zero or more records, each describing one of the data sources the SWIMA-PC uses to collect software inventory information. It SHOULD contain one metadata record for each source that the SWIMA-PC uses. (There might be reasons not to inform certain SWIMA-PVs of the presence of certain data sources.) The attribute MUST contain a metadata record for each source that has been identified in inventory or event messages to the given SWIMA-PV.
源元数据响应属性包含零个或多个记录，每个记录描述SWIMA-PC用于收集软件清单信息的一个数据源。它应该包含SWIMA-PC使用的每个源的一个元数据记录。（可能有理由不通知某些SWIMA PV某些数据源的存在。）该属性必须包含在给定SWIMA-PV的清单或事件消息中标识的每个源的元数据记录。
A SWIMA-PC MUST send a Source Metadata Response attribute in response to a Source Metadata Request attribute, except in cases where the SWIMA-PC experiences an error condition that prevents it from correctly populating the Source Metadata Response attribute (in which case it MUST respond with a PA-TNC Error attribute appropriate to the type of error experienced).
SWIMA-PC必须发送源元数据响应属性以响应源元数据请求属性，除非SWIMA-PC遇到错误情况，导致其无法正确填充源元数据响应属性（在这种情况下，它必须使用与所经历的错误类型相适应的PA-TNC错误属性进行响应）。
The Source Count field indicates how many source metadata records are included in the attribute. Each included record consists of a Source Identification Number field, a Metadata Length field, and a Metadata field.
Source Count字段指示属性中包含多少源元数据记录。每个包含的记录包括一个源标识号字段、一个元数据长度字段和一个元数据字段。
The Source Identification Number field in the Source Metadata Response attribute corresponds to the Source Identification Number field in inventory and event messages. In the case where (1) the Source Identification Number value in this attribute matches a Source Identification Number field in an inventory or event record and (2) both the Source Metadata Response and the inventory or event record were sent to the same SWIMA-PV, the source described in the Metadata field MUST be the same source that provided the inventory or event record associated with this Source Identifier. Recall that a SWIMA-PC MAY use different Source Identification Number associations with different SWIMA-PVs. As such, the association between a Source Identification Number and the conveyed metadata is also only meaningful for communications between the sending SWIMA-PC and receiving SWIMA-PV. When sending to a given SWIMA-PV, the SWIMA-PC MUST use the recipient SWIMA-PV's Source Identification Number associations.
源元数据响应属性中的源标识号字段与资源清册和事件消息中的源标识号字段相对应。如果（1）此属性中的源标识号值与清单或事件记录中的源标识号字段匹配，以及（2）源元数据响应和清单或事件记录都发送到同一SWIMA-PV，元数据字段中描述的源必须与提供与此源标识符关联的资源清册或事件记录的源相同。回想一下，SWIMA-PC可能与不同的SWIMA PV使用不同的源标识号关联。因此，源标识号和传送的元数据之间的关联也仅对发送SWIMA-PC和接收SWIMA-PV之间的通信有意义。当发送到给定的SWIMA-PV时，SWIMA-PC必须使用收件人SWIMA-PV的源标识号关联。
The Metadata Length field indicates the length, in bytes, of the Metadata field. The Metadata field contains information about the indicated data source. This specification does not dictate a format for the contents of the Metadata field. This field MAY include machine-readable information. For broadest utility, the Metadata field SHOULD include human-readable, descriptive information about the data source.
元数据长度字段表示元数据字段的长度（以字节为单位）。元数据字段包含有关指定数据源的信息。本规范不规定元数据字段内容的格式。该字段可以包括机器可读信息。对于最广泛的实用程序，元数据字段应该包括有关数据源的人类可读的描述性信息。
The PA-TNC Error attribute is defined in the PA-TNC specification [RFC5792], and its use here conforms to that specification. A PA-TNC Error can be sent due to any error in the PA-TNC exchange and might also be sent in response to error conditions specific to the SWIMA exchange. The latter case utilizes error codes defined below.
PA-TNC错误属性在PA-TNC规范[RFC5792]中定义，其在此处的使用符合该规范。PA-TNC错误可因PA-TNC交换中的任何错误而发送，也可因特定于SWIMA交换的错误条件而发送。后一种情况使用下面定义的错误代码。
A PA-TNC Error MUST be sent by a SWIMA-PC in response to a SWIMA Request in the case where the SWIMA-PC encounters a fatal error (i.e., an error that prevents further processing of an exchange) relating to the attribute exchange. A SWIMA-PV MUST NOT send this attribute. In the case where the SWIMA-PV experiences a fatal error, it MUST handle the error without sending a PA-TNC Error attribute. The SWIMA-PV MAY take other actions in response to the error, such as logging the cause of the error or even taking actions to isolate the endpoint.
如果SWIMA-PC遇到与属性交换有关的致命错误（即，阻止进一步处理交换的错误），则SWIMA-PC必须发送PA-TNC错误以响应SWIMA请求。SWIMA-PV不得发送此属性。如果SWIMA-PV遇到致命错误，则必须在不发送PA-TNC错误属性的情况下处理该错误。SWIMA-PV可采取其他措施响应错误，例如记录错误原因，甚至采取措施隔离端点。
A PA-TNC Error attribute is sent instead of a SWIMA Response attribute when certain issues prevent the reliable creation of a SWIMA Response. As such, a SWIMA-PC MUST NOT send both a PA-TNC Error attribute and a SWIMA Response attribute in response to a single SWIMA Request attribute.
当某些问题阻止可靠创建SWIMA响应时，将发送PA-TNC错误属性而不是SWIMA响应属性。因此，SWIMA-PC不得发送PA-TNC错误属性和SWIMA响应属性来响应单个SWIMA请求属性。
Table 9 lists the error code values for the PA-TNC Error attribute that are specific to the SWIMA exchange. Error codes are shown in both hexadecimal and decimal format. In all of these cases, the Error Code Vendor ID field MUST be set to 0x000000, corresponding to the IETF SMI PEN. The error information structures for each error code are described in the following subsections.
表9列出了特定于SWIMA交换的PA-TNC错误属性的错误代码值。错误代码以十六进制和十进制格式显示。在所有这些情况下，错误代码供应商ID字段必须设置为0x000000，对应于IETF SMI笔。每个错误代码的错误信息结构在以下小节中描述。
Note that a message with a SWIMA attribute might also result in an error condition covered by the IETF Standard PA-TNC Error Codes defined in Section 4.2.8 of [RFC5792]. For example, a SWIMA attribute might have an invalid parameter, leading to an error code of "Invalid Parameter". In this case, the SWIMA-PC MUST use the appropriate PA-TNC Error Code value as defined in Section 4.2.8 of [RFC5792].
请注意，具有SWIMA属性的消息也可能导致[RFC5792]第4.2.8节中定义的IETF标准PA-TNC错误代码所涵盖的错误情况。例如，SWIMA属性可能具有无效参数，导致错误代码为“无效参数”。在这种情况下，SWIMA-PC必须使用[RFC5792]第4.2.8节中定义的适当PA-TNC错误代码值。
+----------------+--------------------------------------------------+
| Error Code | Description |
| Value | |
+----------------+--------------------------------------------------+
| 0x00000004 (4) | SWIMA_ERROR. This indicates a fatal error |
| | (i.e., an error that precludes the creation of a |
| | suitable response attribute) other than the |
| | errors described below but still specific to the |
| | processing of SWIMA attributes. The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000005 (5) | SWIMA_SUBSCRIPTION_DENIED_ERROR. This indicates |
| | that the SWIMA-PC denied the SWIMA-PV's request |
| | to establish a subscription. The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000006 (6) | SWIMA_RESPONSE_TOO_LARGE_ERROR. This indicates |
| | that the SWIMA-PC's response to the SWIMA-PV's |
| | request was too large to be serviced. The error |
| | information structure indicates the largest |
| | possible size of a response supported by the |
| | SWIMA-PC (see Section 5.15.2). The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000007 (7) | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. This |
| | indicates that the SWIMA-PC experienced an error |
| | while fulfilling a given subscription. The |
| | error information includes the Subscription ID |
| | of the relevant subscription, as well as a |
| | sub-error that describes the nature of the error |
| | the SWIMA-PC experienced. The SWIMA-PC and |
| | SWIMA-PV MUST treat the identified subscription |
| | as cancelled. |
| | |
| 0x00000008 (8) | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. This |
| | indicates that the SWIMA-PC received a SWIMA |
| | Request from a given SWIMA-PV where the Request |
| | ID of that SWIMA Request is currently used as |
| | the Subscription ID of an active subscription |
| | with that SWIMA-PV. This error does not cancel |
| | the identified subscription. |
+----------------+--------------------------------------------------+
+----------------+--------------------------------------------------+
| Error Code | Description |
| Value | |
+----------------+--------------------------------------------------+
| 0x00000004 (4) | SWIMA_ERROR. This indicates a fatal error |
| | (i.e., an error that precludes the creation of a |
| | suitable response attribute) other than the |
| | errors described below but still specific to the |
| | processing of SWIMA attributes. The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000005 (5) | SWIMA_SUBSCRIPTION_DENIED_ERROR. This indicates |
| | that the SWIMA-PC denied the SWIMA-PV's request |
| | to establish a subscription. The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000006 (6) | SWIMA_RESPONSE_TOO_LARGE_ERROR. This indicates |
| | that the SWIMA-PC's response to the SWIMA-PV's |
| | request was too large to be serviced. The error |
| | information structure indicates the largest |
| | possible size of a response supported by the |
| | SWIMA-PC (see Section 5.15.2). The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000007 (7) | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. This |
| | indicates that the SWIMA-PC experienced an error |
| | while fulfilling a given subscription. The |
| | error information includes the Subscription ID |
| | of the relevant subscription, as well as a |
| | sub-error that describes the nature of the error |
| | the SWIMA-PC experienced. The SWIMA-PC and |
| | SWIMA-PV MUST treat the identified subscription |
| | as cancelled. |
| | |
| 0x00000008 (8) | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. This |
| | indicates that the SWIMA-PC received a SWIMA |
| | Request from a given SWIMA-PV where the Request |
| | ID of that SWIMA Request is currently used as |
| | the Subscription ID of an active subscription |
| | with that SWIMA-PV. This error does not cancel |
| | the identified subscription. |
+----------------+--------------------------------------------------+
Table 9: PA-TNC Error Codes for SWIMA
表9:SWIMA的PA-TNC错误代码
The following subsections describe the structures present in the error information fields. Note that all error structures include a variable-length field but do not include any fields indicating the length of those fields. A length field is unnecessary because all other fields in the PA-TNC Error attribute are of fixed length, and thus the length of the variable-length field can be found by subtracting the size of these fixed-length fields from the PA-TNC Attribute Length field in the PA-TNC Attribute Header.
以下小节描述错误信息字段中的结构。请注意，所有错误结构都包括可变长度字段，但不包括指示这些字段长度的任何字段。长度字段是不必要的，因为PA-TNC Error属性中的所有其他字段都是固定长度的，因此可以通过从PA-TNC属性头中的PA-TNC属性长度字段中减去这些固定长度字段的大小来找到可变长度字段的长度。
5.15.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information
5.15.1. SWIMA\u错误、SWIMA\u订阅\u拒绝\u错误和SWIMA\u订阅\u ID\u重用\u错误信息
The SWIMA_ERROR error code indicates that the sender (the SWIMA-PC) has encountered an error that is related to the processing of a SWIMA Request attribute but that is not covered by SWIMA error codes that are more specific. The SWIMA_SUBSCRIPTION_DENIED_ERROR is used when the SWIMA-PV sends a request to establish a subscription or clear all subscriptions from the given SWIMA-PV but the SWIMA-PC is unable or unwilling to comply with this request. The SWIMA_SUBSCRIPTION_ID_REUSE_ERROR is used when the SWIMA-PC receives a SWIMA Request whose Request ID duplicates a Subscription ID of an active subscription with the request's sender. All of these error codes use the following error information structure.
SWIMA_错误代码表示发送方（SWIMA-PC）遇到了与处理SWIMA请求属性有关的错误，但更具体的SWIMA错误代码未涵盖该错误。当SWIMA-PV发送建立订阅或清除来自给定SWIMA-PV的所有订阅的请求，但SWIMA-PC无法或不愿意遵守此请求时，使用SWIMA-PV订阅拒绝错误。当SWIMA-PC收到其请求ID与请求发送方的活动订阅的订阅ID重复的SWIMA请求时，使用SWIMA_订阅ID_重用_错误。所有这些错误代码都使用以下错误信息结构。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information
图21:SWIMA_错误、SWIMA_订阅_拒绝_错误和SWIMA_订阅_ID_重用_错误信息
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of | In the case that this error condition is generated |
| Request ID / | in direct response to a SWIMA Request attribute, |
| Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field in the SWIMA Request attribute |
| | that caused this error. In the case that the |
| | attribute in question is generated in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription for which |
| | the attribute was generated. (This is only |
| | possible if the error code is SWIMA_ERROR, as the |
| | other errors are not generated by subscription |
| | fulfillment.) Note that in the case of failed |
| | subscription fulfillment, the indicated error |
| | appears as a sub-error for a |
| | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in Section 5.15.3. |
| | |
| Description | A UTF-8 [RFC3629] string describing the condition |
| | that caused this error. This field MAY be zero- |
| | length. However, senders SHOULD include some kind |
| | of description in all PA-TNC Error attributes with |
| | these error codes. This field MUST NOT be null |
| | terminated. |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of | In the case that this error condition is generated |
| Request ID / | in direct response to a SWIMA Request attribute, |
| Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field in the SWIMA Request attribute |
| | that caused this error. In the case that the |
| | attribute in question is generated in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription for which |
| | the attribute was generated. (This is only |
| | possible if the error code is SWIMA_ERROR, as the |
| | other errors are not generated by subscription |
| | fulfillment.) Note that in the case of failed |
| | subscription fulfillment, the indicated error |
| | appears as a sub-error for a |
| | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in Section 5.15.3. |
| | |
| Description | A UTF-8 [RFC3629] string describing the condition |
| | that caused this error. This field MAY be zero- |
| | length. However, senders SHOULD include some kind |
| | of description in all PA-TNC Error attributes with |
| | these error codes. This field MUST NOT be null |
| | terminated. |
+--------------+----------------------------------------------------+
Table 10: SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information Fields
表10:SWIMA_错误、SWIMA_订阅_拒绝_错误和SWIMA_订阅_ID_重用_错误信息字段
This error information structure is used with SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR status codes to identify the SWIMA Request attribute that precipitated the error condition and to describe the error. The Description field contains text describing the error. The SWIMA-PC MAY encode machine-interpretable information in this field but SHOULD also include a human-readable description of the error, since the receiving SWIMA-PV might not recognize the SWIMA-PC's encoded information.
此错误信息结构与SWIMA_错误、SWIMA_订阅_拒绝_错误和SWIMA_订阅_ID_重用_错误状态代码一起使用，以识别导致错误情况的SWIMA请求属性并描述错误。描述字段包含描述错误的文本。SWIMA-PC可在此字段中对机器可解释信息进行编码，但还应包括错误的人类可读描述，因为接收SWIMA-PV可能无法识别SWIMA-PC的编码信息。
The SWIMA_RESPONSE_TOO_LARGE_ERROR error code indicates that a SWIMA-PC's response to a SWIMA-PV's SWIMA Request attribute was too large to send.
SWIMA\u响应\u过大\u错误代码表示SWIMA-PC对SWIMA-PV的SWIMA请求属性的响应过大，无法发送。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: SWIMA_RESPONSE_TOO_LARGE_ERROR Information
图22:SWIMA\u响应\u过大\u错误信息
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of | In the case that the attribute in question is |
| Request ID / | generated in direct response to a SWIMA Request, |
| Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field in the SWIMA Request attribute |
| | that caused this error. In the case that the |
| | attribute in question is generated in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription for which |
| | the attribute was generated. Note that in the |
| | latter case, the SWIMA_RESPONSE_TOO_LARGE_ERROR |
| | appears as a sub-error for a |
| | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in Section 5.15.3. |
| | |
| Maximum | This field MUST contain an unsigned integer |
| Allowed Size | indicating the largest permissible size, in bytes, |
| | of the SWIMA attribute that the SWIMA-PC is |
| | currently willing to send in response to a SWIMA |
| | Request attribute. |
| | |
| Description | A UTF-8 [RFC3629] string describing the condition |
| | that caused this error. This field MAY be zero- |
| | length. However, senders SHOULD include some kind |
| | of description in all PA-TNC Error attributes with |
| | this error code. This field MUST NOT be null |
| | terminated. |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of | In the case that the attribute in question is |
| Request ID / | generated in direct response to a SWIMA Request, |
| Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field in the SWIMA Request attribute |
| | that caused this error. In the case that the |
| | attribute in question is generated in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription for which |
| | the attribute was generated. Note that in the |
| | latter case, the SWIMA_RESPONSE_TOO_LARGE_ERROR |
| | appears as a sub-error for a |
| | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in Section 5.15.3. |
| | |
| Maximum | This field MUST contain an unsigned integer |
| Allowed Size | indicating the largest permissible size, in bytes, |
| | of the SWIMA attribute that the SWIMA-PC is |
| | currently willing to send in response to a SWIMA |
| | Request attribute. |
| | |
| Description | A UTF-8 [RFC3629] string describing the condition |
| | that caused this error. This field MAY be zero- |
| | length. However, senders SHOULD include some kind |
| | of description in all PA-TNC Error attributes with |
| | this error code. This field MUST NOT be null |
| | terminated. |
+--------------+----------------------------------------------------+
Table 11: SWIMA_RESPONSE_TOO_LARGE_ERROR Information Fields
表11:SWIMA\u响应\u过大\u错误信息字段
This error structure is used with the SWIMA_RESPONSE_TOO_LARGE_ERROR status code to identify the SWIMA Request attribute that precipitated the error condition and to describe the error. The Maximum Allowed Size field indicates the largest attribute the SWIMA-PC is willing to send in response to a SWIMA Request under the current circumstances. Note that under other circumstances, the SWIMA-PC might be willing to return larger or smaller responses than indicated (such as if the endpoint connects to the NEA Server using a different network protocol). The other fields in this error information structure have the same meanings as corresponding fields in the SWIMA_ERROR and SWIMA_SUBSCRIPTION_DENIED_ERROR information structures.
此错误结构与SWIMA_RESPONSE_to_LARGE_错误状态代码一起使用，以识别导致错误情况的SWIMA请求属性并描述错误。最大允许大小字段表示SWIMA-PC在当前情况下响应SWIMA请求愿意发送的最大属性。请注意，在其他情况下，SWIMA-PC可能愿意返回比指示的更大或更小的响应（例如，如果端点使用不同的网络协议连接到NEA服务器）。此错误信息结构中的其他字段与SWIMA_错误和SWIMA_订阅_拒绝_错误信息结构中的相应字段具有相同的含义。
The SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the SWIMA-PC encountered an error while fulfilling a subscription. The bytes after the first 4 octets duplicate a PA-TNC Error attribute (as described in Section 4.2.8 of PA-TNC [RFC5792]) that is used to identify the nature of the encountered error.
SWIMA_SUBSCRIPTION_FULFILLMENT_错误代码表示SWIMA-PC在完成订阅时遇到错误。前4个八位字节后的字节复制PA-TNC错误属性（如PA-TNC[RFC5792]第4.2.8节所述），该属性用于识别遇到的错误的性质。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-error Information (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-error Information (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information
图23:SWIMA_订阅_履行_错误信息
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Subscription | This field MUST contain the Subscription ID of the |
| ID | subscription whose fulfillment caused this error. |
| | |
| Reserved | This field MUST contain the value of the Reserved |
| | field of a PA-TNC Error attribute that describes |
| | the error condition encountered during |
| | subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Code Vendor | Code Vendor ID field of a PA-TNC Error attribute |
| ID | that describes the error condition encountered |
| | during subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Code | Code field of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Information | Information field of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
+--------------+----------------------------------------------------+
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Subscription | This field MUST contain the Subscription ID of the |
| ID | subscription whose fulfillment caused this error. |
| | |
| Reserved | This field MUST contain the value of the Reserved |
| | field of a PA-TNC Error attribute that describes |
| | the error condition encountered during |
| | subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Code Vendor | Code Vendor ID field of a PA-TNC Error attribute |
| ID | that describes the error condition encountered |
| | during subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Code | Code field of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Information | Information field of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
+--------------+----------------------------------------------------+
Table 12: SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information Fields
表12:SWIMA_订阅_履行_错误信息字段
This error structure is used with the SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of this error structure contain the Subscription ID of the subscription that was being fulfilled when the error occurred. The remaining fields of this error structure duplicate the fields of a PA-TNC Error attribute, referred to as the "sub-error". The error code of the sub-error corresponds to the code of the error that the SWIMA-PC encountered while fulfilling the given subscription. The sub-error MUST NOT have an error code of SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR.
此错误结构与SWIMA_订阅_履行_错误状态代码一起使用。此错误结构的前4个八位字节包含发生错误时正在执行的订阅的订阅ID。此错误结构的其余字段与PA-TNC错误属性（称为“子错误”）的字段重复。子错误的错误代码对应于SWIMA-PC在完成给定订阅时遇到的错误代码。子错误不得有SWIMA_订阅_履行_错误的错误代码。
The SWIMA-PC sending a PA-TNC Error attribute with this error code, and the SWIMA-PV receiving it, MUST treat the subscription identified by the Subscription ID field as cancelled. All other subscriptions are unaffected.
发送带有此错误代码的PA-TNC错误属性的SWIMA-PC和接收该错误代码的SWIMA-PV必须将订阅ID字段标识的订阅视为已取消。所有其他订阅均不受影响。
SWIMA supports an extensible list of data models for representing and transmitting software inventory information. This list of data models appears in the "Software Data Model Types" registry (see Section 10.5). This document provides guidance for an initial set of data models. Other documents might provide guidance on the use of new data models by SWIMA and will be referenced by extensions to the "Software Data Model Types" registry.
SWIMA支持用于表示和传输软件清单信息的可扩展数据模型列表。此数据模型列表出现在“软件数据模型类型”注册表中（见第10.5节）。本文档为初始数据模型集提供指导。其他文件可能为SWIMA使用新数据模型提供指导，并将被“软件数据模型类型”注册表的扩展引用。
The International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC) published the specification governing SWID tag construction and use (ISO/IEC 19770-2:2009) in 2009 [SWID09], with a revised version of the specification (ISO/IEC 19770-2:2015) published in 2015 [SWID15]. Since that time, a growing number of vendors have integrated SWID tags into their software products. SWID tags significantly simplify the task of identifying pieces of software: instead of relying on discovery processes that look for clues as to software presence, such as the presence of particular files or registry keys, vendors can use a readily available list of SWID tags that provides simple and immediate evidence as to the presence of the given piece of software.
国际标准化组织和国际电工委员会（ISO/IEC）于2009年[SWID09]发布了管理SWID标签构造和使用的规范（ISO/IEC 19770-2:2009），2015年[SWID15]发布了该规范的修订版（ISO/IEC 19770-2:2015）。从那时起，越来越多的供应商将SWID标签集成到他们的软件产品中。SWID标记大大简化了识别软件片段的任务：而不是依赖于寻找软件存在线索的发现过程，例如特定文件或注册表项的存在，供应商可以使用一个随时可用的SWID标签列表，该列表提供了关于给定软件存在的简单而直接的证据。
SWIMA has no reliance on the presence or management of SWID tags on an endpoint as described in the ISO 2015 SWID tag specification. However, as presented in the ISO 2015 SWID tag specification, the data model for describing software provides a robust and comprehensive way of describing software and is adopted here as a means of representing and transmitting software information. It should be emphasized that the use of the ISO SWID tag data model makes no assumption as to whether (1) the source of the recorded information was, in fact, an ISO SWID tag harvested from the endpoint or (2) the information was created using some other source and normalized to the SWID format.
SWIMA不依赖于ISO 2015 SWID标签规范中所述端点上的SWID标签的存在或管理。然而，正如ISO 2015 SWID标签规范中所述，用于描述软件的数据模型提供了一种稳健而全面的描述软件的方法，并在这里被用作表示和传输软件信息的手段。应强调的是，ISO SWID标签数据模型的使用并未假设（1）记录信息的来源实际上是从端点获取的ISO SWID标签，或（2）信息是使用其他来源创建的，并标准化为SWID格式。
6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags Using XML
6.1.1. 关于使用XML将源数据规范化为ISO 2015 SWID标记的指南
Any record associated with this Software Data Model Type MUST conform to [SWID15].
与此软件数据模型类型相关的任何记录必须符合[SWID15]。
If generating a new ISO 2015 SWID tag, the software generating the tag MUST use a Tag Creator RegID that is associated with the generating software, unless this is impossible, in which case it MUST use the "http://invalid.unavailable" Tag Creator RegID value. (This conforms to conventions for an unknown tag creator in the ISO 2015
如果生成新的ISO 2015 SWID标签，生成标签的软件必须使用与生成软件关联的标签创建者RegID，除非这是不可能的，在这种情况下，它必须使用“http://invalid.unavailable“标记创建者注册表项值。（这符合ISO 2015中未知标签创建者的约定
SWID tag specification.) Do not use a RegID associated with any other party. In particular, it is incorrect to use a Tag Creator RegID associated with the software being described by the tag, the enterprise that is using the software, or any other entity except that of the party that built the tool that is generating the SWID tag. This reflects the requirement that the Tag Creator RegID identify the party that created the tag. Moreover, any generated tags SHOULD conform to guidance for tag creators as provided in NISTIR 8060 [NIST8060], which provides additional recommendations to increase interoperable use of SWID tags.
SWID标签规范。）请勿使用与任何其他方关联的RegID。特别是，使用与标签描述的软件、使用软件的企业或任何其他实体（生成SWID标签的工具的制造方除外）相关联的标签创建者RegID是不正确的。这反映了标签创建者注册标识创建标签的一方的要求。此外，任何生成的标签都应符合NISTIR 8060[NIST8060]中提供的标签创建者指南，该指南提供了增加SWID标签可互操作使用的额外建议。
6.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID Tags
6.1.2. 根据ISO 2015 SWID标签创建软件标识符的指南
A Software Identifier generated from an ISO 2015 SWID tag is expressed as a concatenation of the value of the Tag Creator RegID field and the Unique ID field. Specifically, (1) it MUST be of the form TAG_CREATOR_REGID "_" "_" UNIQUE_ID and (2) it consists of the Tag Creator RegID and the Unique ID from the tag connected with a double underscore (_), without any other connecting character or whitespace.
由ISO 2015 SWID标记生成的软件标识符表示为标记创建者RegID字段和唯一ID字段值的串联。具体地说，（1）它必须是TAG_CREATOR_REGID“u”“uu”UNIQUE_ID的形式，（2）它由TAG CREATOR REGID和标记的唯一ID组成，并用双下划线（u）连接，没有任何其他连接字符或空白。
As noted above, ISO's SWID tag specification provides a useful data model for representation of software information. As of the writing of this specification, while the ISO 2015 specification is considered more comprehensive and addresses some issues with the ISO 2009 specification, 2009-format SWID tags remain far more common in deployments. For this reason, ISO 2009 SWID tags are included in the "Software Data Model Types" registry.
如上所述，ISO的SWID标签规范为软件信息的表示提供了有用的数据模型。在编写本规范时，虽然ISO 2015规范被认为更全面，并解决了ISO 2009规范的一些问题，但2009格式的SWID标签在部署中仍然更为常见。因此，ISO 2009 SWID标记包含在“软件数据模型类型”注册表中。
6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags Using XML
6.2.1. 关于使用XML将源数据规范化为ISO 2009 SWID标记的指南
Any record associated with this Software Data Model Type MUST conform to [SWID09]. Any such tag SHOULD use a UTF-8 encoding [RFC3629] but MUST NOT alter the existing encoding if doing so would invalidate digital signatures included in the tag.
与此软件数据模型类型关联的任何记录必须符合[SWID09]。任何此类标签都应使用UTF-8编码[RFC3629]，但如果这样做会使标签中包含的数字签名无效，则不得更改现有编码。
If generating a new ISO 2009 SWID tag, the software generating the tag MUST use a Tag Creator RegID that is associated with the generating software, unless this is impossible, in which case it MUST use "unknown", which indicates that the tag creator is unknown. (This conforms to conventions for an unknown tag creator in the ISO 2009 SWID tag specification.) Do not use a RegID associated with any other party. In particular, it is incorrect to use a Tag Creator RegID associated with the software being described by the tag, the
如果生成新的ISO 2009 SWID标签，生成标签的软件必须使用与生成软件关联的标签创建者RegID，除非这是不可能的，否则在这种情况下，它必须使用“未知”，这表示标签创建者未知。（这符合ISO 2009 SWID标签规范中未知标签创建者的约定。）请勿使用与任何其他方关联的RegID。特别是，使用与标签描述的软件相关联的标签创建者RegID是不正确的
enterprise that is using the software, or any other entity except that of the party that built the tool that is generating the SWID tag. This reflects the requirement that the Tag Creator RegID identify the party that created the tag.
使用软件的企业，或除生成SWID标签的工具的制造方以外的任何其他实体。这反映了标签创建者注册标识创建标签的一方的要求。
6.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID Tags
6.2.2. 根据ISO 2009 SWID标签创建软件标识符的指南
A Software Identifier generated from an ISO 2009 SWID tag is expressed as a concatenation of the value of the Tag Creator RegID field and the Unique ID field. Specifically, (1) it MUST be of the form TAG_CREATOR_REGID "_" "_" UNIQUE_ID and (2) it consists of the Tag Creator RegID and the Unique ID from the tag connected with a double underscore (_), without any other connecting character or whitespace.
从ISO 2009 SWID标记生成的软件标识符表示为标记创建者RegID字段值和唯一ID字段值的串联。具体地说，（1）它必须是TAG_CREATOR_REGID“u”“uu”UNIQUE_ID的形式，（2）它由TAG CREATOR REGID和标记的唯一ID组成，并用双下划线（u）连接，没有任何其他连接字符或空白。
This specification is expected to participate in a standard NEA architecture. As such, it is expected to be used in conjunction with the other protocols used in a NEA exchange. In particular, SWIMA attributes are conveyed over PB-TNC [RFC5793], which is in turn conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP [RFC7171]). These protocols have an especially important role, as they are responsible for ensuring that attributes defined under this specification are delivered reliably, securely, and to the appropriate party.
本规范预计将参与标准NEA体系结构。因此，预计它将与NEA交换中使用的其他协议结合使用。特别是，SWIMA属性通过PB-TNC[RFC5793]传输，而PB-TNC[RFC5793]又通过PT的某些变体（PT-TLS[RFC6876]或PT-EAP[RFC7171]）传输。这些协议具有特别重要的作用，因为它们负责确保根据本规范定义的属性可靠、安全地交付给适当的一方。
It is important to note that the Product Information, Numeric Version, and String Version attributes defined in the PA-TNC specification [RFC5792] are also meant to convey information about installed applications and the versions thereof. As such, there is some conceptual overlap between those attributes and the intent of this specification. However, PA-TNC was designed to respond to very specific queries about specific classes of products, while SWIMA is able to convey a broader query, resulting in a more comprehensive set of information regarding an endpoint's installed software. As such, this specification provides important capabilities not present in the PA-TNC specification.
需要注意的是，PA-TNC规范[RFC5792]中定义的产品信息、数字版本和字符串版本属性也旨在传达有关已安装应用程序及其版本的信息。因此，这些属性与本规范的意图之间存在一些概念上的重叠。然而，PA-TNC被设计用于响应关于特定产品类别的非常具体的查询，而SWIMA能够传达更广泛的查询，从而得到关于端点安装软件的更全面的信息集。因此，本规范提供了PA-TNC规范中不存在的重要功能。
The NEA architecture is intended to support a broad range of activities and, as such, might be employed by other specifications. For example, requirement T-001 in the SACM Requirements document [RFC8248] notes that NEA can support data collection from endpoints within the broader SACM architecture. (Other parts of the NEA architecture, which SWIMA uses, meet the other SACM data transport requirements.) In the SACM architecture, a SWIMA-PV corresponds to a "SACM Collector" and a SWIMA-PC corresponds to a "SACM Internal
NEA体系结构旨在支持广泛的活动，因此，其他规范可能会采用该体系结构。例如，SACM需求文件[RFC8248]中的需求T-001指出，NEA可以支持从更广泛的SACM体系结构中的端点收集数据。（SWIMA使用的NEA体系结构的其他部分满足其他SACM数据传输要求。）在SACM体系结构中，SWIMA-PV对应于“SACM收集器”，SWIMA-PC对应于“SACM内部收集器”
Collector". In the SACM architecture, SWIMA can support activities relating to software inventory collection. Specifically, SWIMA supports the SACM "Endpoint Posture Attribute Value Collection" use case (Section 2.1.3 in [RFC7632]) by describing a collection mechanism that enables event-driven, scheduled, and ad hoc data collection of software inventory information. SWIMA's flexibility with regard to the format of inventory data records means that it is compatible with virtually any data format that implements SACM's "Define, Publish, Query, and Retrieve Security Automation Data" use case (Section 2.1.1 in [RFC7632]). This is just one example of how SWIMA can support broader security solution standards. Note that while SWIMA can support these SACM use cases, SWIMA has no dependencies on the SACM architecture or any other context in which NEA might reasonably be applied.
收集器”。在SACM体系结构中，SWIMA可以支持与软件清单收集相关的活动。具体而言，SWIMA支持SACM“端点姿态属性值收集”用例（参见[RFC7632]中的第2.1.3节）通过描述一种收集机制，实现对软件清单信息的事件驱动、计划和特殊数据收集。SWIMA在清单数据记录格式方面的灵活性意味着它与实现SACM“定义、发布、查询、，“和检索安全自动化数据”用例（参见[RFC7632]中的第2.1.1节）。这只是SWIMA如何支持更广泛的安全解决方案标准的一个示例。请注意，虽然SWIMA可以支持这些SACM用例，但SWIMA不依赖SACM体系结构或任何其他可以合理应用NEA的上下文。
This section discusses some of the security threats facing SWIMA-PCs and SWIMA-PVs. This section primarily notes potential issues for implementers to consider, although it does contain a handful of normative requirements to address certain security issues. The issues identified below focus on capabilities specific to this document. Implementers are advised to consult other relevant NEA specifications, particularly [RFC5209] (the NEA architecture) and [RFC5792] (PA-TNC), for security issues that are applicable to such components in general.
本节讨论了SWIMA PC和SWIMA PV面临的一些安全威胁。本节主要说明了实施者需要考虑的潜在问题，尽管它确实包含了一些规范性要求来解决某些安全问题。以下确定的问题集中于本文档特定的功能。建议实施者参考其他相关NEA规范，特别是[RFC5209]（NEA架构）和[RFC5792]（PA-TNC），以了解一般适用于此类组件的安全问题。
The degree to which an endpoint's Software Inventory Evidence Collection accurately reflects the endpoint's actual software load and any changes made to this software load is dependent on the accuracy of the tools used to populate and manage the Software Inventory Evidence Records in this collection. While the SWIMA-PC is required to detect changes to an endpoint's Software Inventory Evidence Collection in near real time, some tools might not be designed to update records in the Software Inventory Evidence Collection in real time. This can result in a collection that is out of sync with actual system state. Moreover, tools might inaccurately characterize software or fail to properly record its removal. Finally, it is likely that there will be software on the endpoint that is not tracked by any source and thus is not reflected in the Software Inventory Evidence Collection. Tools that implement SWIMA ought to be aware of these potential issues and minimize them, but completely eliminating such issues is likely impossible. Users of collected Software Inventory Evidence Records need to understand that the information provided by SWIMA cannot be treated as completely accurate. Nonetheless, having endpoints report this information can
端点的软件清单证据收集准确反映端点的实际软件负载以及对此软件负载所做的任何更改的程度取决于用于填充和管理此集合中的软件清单证据记录的工具的准确性。虽然要求SWIMA-PC近乎实时地检测端点软件清单证据收集的更改，但某些工具可能无法实时更新软件清单证据收集中的记录。这可能导致集合与实际系统状态不同步。此外，工具可能不准确地描述软件，或者无法正确记录其删除。最后，端点上可能存在未被任何来源跟踪的软件，因此未反映在软件清单证据收集中。实现SWIMA的工具应该意识到这些潜在问题并将其最小化，但完全消除这些问题可能是不可能的。收集的软件库存证据记录的用户需要了解，SWIMA提供的信息不能被视为完全准确。尽管如此，让端点报告此信息可以
still provide useful insights into the state of the endpoint's software load and can alert administrators and policy tools of situations that require remediation.
仍然可以提供对端点软件负载状态的有用见解，并可以在需要修复的情况下向管理员和策略工具发出警报。
Collected software records can be sensitive in nature. This can include both security sensitivities and privacy sensitivities. Privacy sensitivities are discussed more in Section 9. With regard to security, inventory records represent a wealth of information about the endpoint in question, and for an adversary who does not already have access to the endpoint a collection of the endpoint's inventory records might provide many details that are useful for mounting an attack. A list of the inventory records associated with an endpoint reveals a list of software installed on the endpoint. This list can be very detailed, noting specific versions and even patch levels; an adversary can use this information to identify vulnerable software and design efficacious attacks.
收集的软件记录在本质上可能是敏感的。这可能包括安全敏感性和隐私敏感性。第9节将详细讨论隐私敏感性。就安全性而言，清单记录代表了有关该端点的大量信息，对于尚未访问该端点的对手，端点清单记录的集合可能会提供许多有助于发起攻击的详细信息。与端点关联的资源清册记录列表显示端点上安装的软件列表。此列表可以非常详细，注意特定版本，甚至补丁级别；对手可以利用这些信息识别易受攻击的软件并设计有效的攻击。
The following information might also be gleaned from a collection of software inventory records:
还可以从软件清单记录集合中收集以下信息：
o An inventory record might include information about where the product was installed on a given endpoint. This can reveal details about the file organization of that endpoint that an attacker can utilize.
o 库存记录可能包括有关产品在给定端点上安装位置的信息。这可以揭示攻击者可以利用的该端点的文件组织的详细信息。
o An inventory record might include information about how the software was provided to the endpoint, who in an organization signs off on the package release, and who packaged the product for installation. This information might be used as a starting point for the development of supply chain attacks.
o 清单记录可能包括有关软件是如何提供给端点的信息、组织中谁在包发布上签字以及谁打包了产品以供安装的信息。这些信息可能被用作开发供应链攻击的起点。
o Events affecting inventory records are reported with timestamps indicating when each given event occurred. This can give the attacker an indication of how quickly an organization distributes patches and updates, helping the attacker determine how long an attack window might remain open.
o 报告影响库存记录的事件，时间戳指示每个给定事件发生的时间。这可以让攻击者知道组织分发修补程序和更新的速度，帮助攻击者确定攻击窗口可能保持打开的时间。
Any consolidated software inventory is a potential risk, because such an inventory can provide an adversary an insight into the enterprise's configuration and management process. It is recommended that a centralized software inventory record collection be protected against unauthorized access. Mechanisms to accomplish this can include encrypting the data at rest, ensuring that access to the data is limited only to authorized individuals and processes, and other basic security precautions.
任何整合的软件清单都是潜在的风险，因为这样的清单可以让对手深入了解企业的配置和管理过程。建议对集中的软件清单记录收集进行保护，防止未经授权的访问。实现这一点的机制包括对静止数据进行加密、确保数据访问仅限于授权的个人和进程以及其他基本安全预防措施。
SWIMA-PCs maintain records of detected changes to the endpoint's Software Inventory Evidence Collection. These records are used to respond to a SWIMA-PV's request for change events. The SWIMA-PV might use a list of reported events to update its understanding of the endpoint's Software Inventory Evidence Collection without needing to receive a full inventory report from the SWIMA-PC. For this reason, preserving the integrity of the SWIMA-PC's record of events is extremely important. If an attacker modifies the SWIMA-PC's record of changes to the endpoint's Software Inventory Evidence Collection, this might cause the SWIMA-PV's understanding of the endpoint's Software Inventory Evidence Collection to differ from its actual state. The results of such an attack might include leading the SWIMA-PV to believe that (1) absent software was present or, conversely, that present software was absent or (2) patches have been installed even if this is not the case. Such an attack could also cause the SWIMA-PV to be unaware of other changes to Software Inventory Evidence Records. As such, the SWIMA-PC MUST take steps to protect the integrity of its event records.
SWIMA PC维护端点软件清单证据收集中检测到的更改记录。这些记录用于响应SWIMA-PV的变更事件请求。SWIMA-PV可以使用报告事件列表更新其对端点软件清单证据收集的理解，而无需从SWIMA-PC收到完整的清单报告。因此，保持SWIMA-PC事件记录的完整性极为重要。如果攻击者修改SWIMA-PC对端点软件清单证据收集的更改记录，这可能会导致SWIMA-PV对端点软件清单证据收集的理解与其实际状态不同。此类攻击的结果可能包括导致SWIMA-PV相信（1）存在缺失的软件，或者相反，存在缺失的软件，或者（2）安装了补丁，即使情况并非如此。此类攻击还可能导致SWIMA-PV不知道软件清单证据记录的其他更改。因此，SWIMA-PC必须采取措施保护其事件记录的完整性。
In addition, records of established SWIMA-PV subscriptions also require protection against manipulation or corruption. If an attacker is able to modify or delete records of a SWIMA-PV's established subscription, the SWIMA-PC might fail to correctly fulfill this subscription. The SWIMA-PV would not be aware that its subscription was not being correctly fulfilled unless it received additional information that indicated a discrepancy. For example, the SWIMA-PV might collect a full inventory and realize from this information that certain events had not been correctly reported in accordance with an established subscription. For this reason, the SWIMA-PC MUST protect the integrity of subscription records.
此外，已建立的SWIMA-PV订阅记录也需要防止操纵或腐败。如果攻击者能够修改或删除SWIMA-PV已建立订阅的记录，则SWIMA-PC可能无法正确完成此订阅。SWIMA-PV将不会意识到其认购未得到正确履行，除非其收到表明存在差异的额外信息。例如，SWIMA-PV可能会收集完整的库存，并从该信息中意识到某些事件没有按照既定订阅进行正确报告。因此，SWIMA-PC必须保护订阅记录的完整性。
A SWIMA-PC requires sufficient permissions to collect Software Inventory Evidence Records from all of its supported sources, as well as sufficient permissions to interact with the endpoint's Posture Broker Client. With regard to the former, this might require permissions to read the contents of directories throughout the filesystem. Depending on the operating environment and other activities undertaken by a SWIMA-PC (or software that incorporates a SWIMA-PC as one of its capabilities), additional permissions might be required by the SWIMA-PC software. The SWIMA-PC SHOULD NOT be granted permissions beyond what it needs to fulfill its duties.
SWIMA-PC需要足够的权限从其所有支持的源收集软件清单证据记录，以及与端点的姿态代理客户端交互的足够权限。对于前者，这可能需要在整个文件系统中读取目录内容的权限。根据SWIMA-PC（或将SWIMA-PC作为其功能之一的软件）的操作环境和其他活动，SWIMA-PC软件可能需要额外的权限。不应授予SWIMA-PC超出其履行职责所需权限的权限。
Not all sources of software inventory evidence are necessarily tightly controlled. For example, consider a source that gathers .swid files from the endpoint's filesystem. Any party could create a new .swid file that could be collected and turned into a Software Inventory Evidence Record. As a result, it is important that the contents of source information not be automatically trusted. In particular, tools that read source information and the Software Inventory Evidence Records derived therefrom, including SWIMA-PCs, need to be careful to sanitize input to prevent buffer overflow attacks, encoding attacks, and other weaknesses that might be exploited by an adversary who can control the contents of a record.
并非所有软件清单证据的来源都必须严格控制。例如，考虑从端点的文件系统收集.SWID文件的源代码。任何一方都可以创建一个新的.swid文件，该文件可以收集并转换为软件清单证据记录。因此，不自动信任源信息的内容非常重要。特别是，读取源信息和从中派生的软件清单证据记录的工具，包括SWIMA PC，需要仔细清理输入，以防止缓冲区溢出攻击、编码攻击和其他可能被能够控制记录内容的对手利用的弱点。
In addition to the aforementioned considerations, the SWIMA protocol is subject to the same security threats as other PA-TNC transactions; see Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited to, attribute theft, message fabrication, attribute modification, attribute replay, attribute insertion, and denial of service. Implementers are advised to consult the PA-TNC specification to better understand these security issues.
除上述考虑因素外，SWIMA协议与其他PA-TNC交易面临相同的安全威胁；参见PA-TNC[RFC5792]第5.2节。这些包括但不限于属性盗窃、消息制造、属性修改、属性重放、属性插入和拒绝服务。建议实施者参考PA-TNC规范，以更好地理解这些安全问题。
As noted in Section 8.2, if an adversary can gain an understanding of the software installed on an endpoint, they can utilize this to launch attacks and maintain footholds on this endpoint. For this reason, the NEA Server needs to ensure that adequate safeguards are in place to prevent exposure of collected inventory records. For similar reasons, it is advisable that an endpoint only send records to a NEA Server that is authorized to receive this information and that can be trusted to safeguard this information after collection.
如第8.2节所述，如果对手能够了解安装在某个端点上的软件，他们可以利用它发起攻击并在该端点上保持立足点。因此，NEA服务器需要确保有足够的保护措施，以防止收集的库存记录暴露。出于类似的原因，建议端点仅将记录发送到授权接收此信息且可信任在收集后保护此信息的NEA服务器。
In addition, software inventory information can lead to insights about the endpoint's primary user if that user is able to install software. (Note that users might be "able" to install their own software even if they are not "allowed" to do so.) This is especially true on endpoints that support "apps", as individual apps can be closely tied to specific groups or activities. This could conceivably allow inferences about things such as a user's hobbies; the banks and other financial institutions that they use; and information about the user's race, sex, or sexual orientation.
此外，如果端点的主要用户能够安装软件，则软件清单信息可以帮助了解该用户。（请注意，即使“不允许”用户安装自己的软件，用户也可能“能够”安装自己的软件。）在支持“应用程序”的端点上尤其如此，因为单个应用程序可能与特定的组或活动密切相关。可以想象，这可以对诸如用户的爱好之类的事情进行推断；使用的银行和其他金融机构；以及有关用户种族、性别或性取向的信息。
Organizations that collect software inventory information from endpoints ought to make sure the endpoints' users are aware of this collection. In addition, organizations should be aware that a software inventory associated with an individual, such as the inventory of the individual's primary endpoint, could expose sensitive personal information. For this reason, privacy safeguards are necessary for collected inventory information. Such safeguards would require not only protection of the inventory's confidentiality but also appropriate access controls so that only those trained in relevant privacy requirements are able to view the data.
从端点收集软件清单信息的组织应该确保端点的用户知道此收集。此外，组织应意识到，与个人相关的软件清单（如个人主要端点的清单）可能会暴露敏感的个人信息。因此，收集的库存信息需要隐私保护。此类保障措施不仅需要保护库存的机密性，还需要适当的访问控制，以便只有接受过相关隐私要求培训的人员才能查看数据。
This section extends multiple existing IANA registries. Specifically, it extends the "PA-TNC Attribute Types" and "PA-TNC Error Codes" registries defined in the PA-TNC specification [RFC5792] and the "PA Subtypes" registry defined in the PB-TNC specification [RFC5793] and extended in PA-TNC. This specification only adds values to these registries and does not alter how these registries work or are maintained. Consult the appropriate specifications for details on the operations and maintenance of these registries.
本节扩展了多个现有IANA注册中心。具体而言，它扩展了PA-TNC规范[RFC5792]中定义的“PA-TNC属性类型”和“PA-TNC错误代码”注册表，以及PB-TNC规范[RFC5793]中定义并在PA-TNC中扩展的“PA子类型”注册表。本规范仅向这些注册表添加值，不改变这些注册表的工作或维护方式。有关这些注册表的操作和维护的详细信息，请参阅相应的规范。
This section also defines a new IANA registry for "Software Data Model Types". The structure and requirements for this registry are provided, as well as guidelines for reviewers adjudicating the addition of new entries to this registry.
本节还为“软件数据模型类型”定义了一个新的IANA注册表。提供了该登记册的结构和要求，以及审查人员判定是否向该登记册添加新条目的指南。
For the "Software Data Model Types" registry defined by this specification, new values are added to the registry using the "Specification Required" process defined in RFC 8126 [RFC8126].
对于本规范定义的“软件数据模型类型”注册表，使用RFC 8126[RFC8126]中定义的“所需规范”过程向注册表添加新值。
This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for this registry.
本节为指定专家提供指导，以便他们能够使用适用于本登记册的理念做出决策。
Designated experts should focus on the following requirements. All values in this IANA registry MUST be documented in a specification that is permanently and publicly available. Values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability.
指定专家应关注以下要求。此IANA注册表中的所有值必须记录在永久公开的规范中。价值观还必须是有用的，对互联网无害，并以明确的方式定义，并有可能确保互操作性。
Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single value allocated via IETF standards. However, it is beneficial to document existing practice.
指定专家应鼓励供应商避免定义类似但不兼容的值，而是同意通过IETF标准分配的单个值。然而，记录现有实践是有益的。
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to IANA and authorize IANA to archive this copy and make it freely available to all, if at some point the document becomes no longer freely available to all through other channels.
有几种方法可以确保规范永久和公开可用。它可以作为RFC发布。或者，它可以以另一种方式发布，使任何人都可以免费获得。但是，在后一种情况下，供应商必须向IANA提供一份副本，并授权IANA存档该副本，并使其可供所有人免费使用，如果在某个时候文件不再通过其他渠道免费提供给所有人。
Sections 10.2, 10.3, and 10.4 define a new PA Subtype, new PA-TNC Attribute Types, and new PA-TNC Error Codes, respectively. Section 10.5 provides guidance to IANA in creating and managing the new "Software Data Model Types" registry defined by this specification.
第10.2、10.3和10.4节分别定义了新的PA子类型、新的PA-TNC属性类型和新的PA-TNC错误代码。第10.5节为IANA创建和管理本规范定义的新“软件数据模型类型”注册表提供了指导。
The following is an extension to the list of PA Subtypes provided in Section 7.2 of [RFC5792] and defined in the "PA Subtypes" registry in Section 6.3 of [RFC5793]. See <https://www.iana.org/assignments/ pb-tnc-parameters/>.
以下是[RFC5792]第7.2节中提供的PA子类型列表的扩展，并在[RFC5793]第6.3节中的“PA子类型”注册表中定义。看<https://www.iana.org/assignments/ pb tnc参数/>。
+-----+---------+------------------+------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+------------------+------------------------+
| 0 | 9 | SWIMA Attributes | RFC 8412 |
+-----+---------+------------------+------------------------+
+-----+---------+------------------+------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+------------------+------------------------+
| 0 | 9 | SWIMA Attributes | RFC 8412 |
+-----+---------+------------------+------------------------+
Section 5.2 of this specification defines several new PA-TNC attributes. The following values have been added to the "PA-TNC Attribute Types" registry defined in the PA-TNC specification. Note that Table 1 in Section 5.2 lists these attributes in both hexadecimal and decimal format. The decimal values given in that table are identical to those provided here. Note also that Table 1 includes an entry for the PA-TNC Error attribute, but the IANA information associated with the PA-TNC Error attribute is already defined in the PA-TNC specification and is not reproduced here.
本规范第5.2节定义了几个新的PA-TNC属性。以下值已添加到PA-TNC规范中定义的“PA-TNC属性类型”注册表中。请注意，第5.2节中的表1列出了十六进制和十进制格式的这些属性。该表中给出的十进制值与此处提供的相同。还请注意，表1包括PA-TNC错误属性的条目，但与PA-TNC错误属性相关联的IANA信息已在PA-TNC规范中定义，此处不再复制。
+-----+---------+----------------------------+----------------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+----------------------------+----------------------+
| 0 | 13 | SWIMA Request | RFC 8412 |
| | | | |
| 0 | 14 | Software Identifier | RFC 8412 |
| | | Inventory | |
| | | | |
| 0 | 15 | Software Identifier Events | RFC 8412 |
| | | | |
| 0 | 16 | Software Inventory | RFC 8412 |
| | | | |
| 0 | 17 | Software Events | RFC 8412 |
| | | | |
| 0 | 18 | Subscription Status | RFC 8412 |
| | | Request | |
| | | | |
| 0 | 19 | Subscription Status | RFC 8412 |
| | | Response | |
| | | | |
| 0 | 20 | Source Metadata Request | RFC 8412 |
| | | | |
| 0 | 21 | Source Metadata Response | RFC 8412 |
+-----+---------+----------------------------+----------------------+
+-----+---------+----------------------------+----------------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+----------------------------+----------------------+
| 0 | 13 | SWIMA Request | RFC 8412 |
| | | | |
| 0 | 14 | Software Identifier | RFC 8412 |
| | | Inventory | |
| | | | |
| 0 | 15 | Software Identifier Events | RFC 8412 |
| | | | |
| 0 | 16 | Software Inventory | RFC 8412 |
| | | | |
| 0 | 17 | Software Events | RFC 8412 |
| | | | |
| 0 | 18 | Subscription Status | RFC 8412 |
| | | Request | |
| | | | |
| 0 | 19 | Subscription Status | RFC 8412 |
| | | Response | |
| | | | |
| 0 | 20 | Source Metadata Request | RFC 8412 |
| | | | |
| 0 | 21 | Source Metadata Response | RFC 8412 |
+-----+---------+----------------------------+----------------------+
Section 5.15 of this specification defines several new PA-TNC Error Codes. The following values have been added to the "PA-TNC Error Codes" registry defined in the PA-TNC specification. Note that Table 9 in Section 5.15 lists these codes in both hexadecimal and decimal format. The decimal values given in that table are identical to those provided here.
本规范第5.15节定义了几个新的PA-TNC错误代码。以下值已添加到PA-TNC规范中定义的“PA-TNC错误代码”注册表中。请注意，第5.15节中的表9列出了十六进制和十进制格式的这些代码。该表中给出的十进制值与此处提供的相同。
+-----+---------+--------------------------------------+---------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+--------------------------------------+---------------+
| 0 | 4 | SWIMA_ERROR | RFC 8412 |
| | | | |
| 0 | 5 | SWIMA_SUBSCRIPTION_DENIED_ERROR | RFC 8412 |
| | | | |
| 0 | 6 | SWIMA_RESPONSE_TOO_LARGE_ERROR | RFC 8412 |
| | | | |
| 0 | 7 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR | RFC 8412 |
| | | | |
| 0 | 8 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | RFC 8412 |
+-----+---------+--------------------------------------+---------------+
+-----+---------+--------------------------------------+---------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+--------------------------------------+---------------+
| 0 | 4 | SWIMA_ERROR | RFC 8412 |
| | | | |
| 0 | 5 | SWIMA_SUBSCRIPTION_DENIED_ERROR | RFC 8412 |
| | | | |
| 0 | 6 | SWIMA_RESPONSE_TOO_LARGE_ERROR | RFC 8412 |
| | | | |
| 0 | 7 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR | RFC 8412 |
| | | | |
| 0 | 8 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | RFC 8412 |
+-----+---------+--------------------------------------+---------------+
For the "Software Data Model Types" registry (<https://www.iana.org/assignments/pa-tnc-parameters/ #software-data-model-types>, each entry should include a human-readable name, an SMI PEN, a decimal integer value between 0 and 2^8-1 (inclusive), and a reference to the specification where the use of this data model is defined. This referenced specification needs to provide both a description of the format used by the data model and the procedures by which Software Identifiers are derived from a record expressed using this data model. Note that a specification that just defines the data model structure and its use is generally not sufficient, as it would likely lack the procedures for constructing a Software Identifier. This is why the table below uses the SWIMA standard for ISO SWID tags as the reference for the use of ISO SWID tags and does not reference the ISO SWID tag specification.
对于“软件数据模型类型”注册表(<https://www.iana.org/assignments/pa-tnc-parameters/ #软件数据模型类型>，每个条目应包括人类可读的名称、SMI笔、0和2^8-1（含）之间的十进制整数值，以及对定义使用此数据模型的规范的引用。此引用规范需要提供数据模型所用格式的说明以及从使用此数据模型表示的记录派生软件标识符的过程。请注意，仅定义数据模型的规范odel结构及其使用通常是不够的，因为它可能缺少构建软件标识符的程序。这就是为什么下表使用ISO SWID标记的SWIMA标准作为使用ISO SWID标记的参考，而没有参考ISO SWID标记规范的原因。
The following entries for this registry are defined in this document. They are the initial entries in the "Software Data Model Types" registry. Additional entries to this registry are added following the "Specification Required" policy defined in [RFC8126], following the guidelines in Section 10.1.
本文档中定义了此注册表的以下条目。它们是“软件数据模型类型”注册表中的初始条目。根据[RFC8126]中定义的“所需规范”政策，并按照第10.1节中的指南，向该注册表添加其他条目。
+-----+---------+-----------------------------+---------------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+-----------------------------+---------------------+
| 0 | 0 | ISO 2015 SWID tags using | RFC 8412 |
| | | XML | |
| | | | |
| 0 | 1 | ISO 2009 SWID tags using | RFC 8412 |
| | | XML | |
| | | | |
| 0 | 192-255 | Reserved for local | N/A |
| | | enterprise use | |
+-----+---------+-----------------------------+---------------------+
+-----+---------+-----------------------------+---------------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+-----------------------------+---------------------+
| 0 | 0 | ISO 2015 SWID tags using | RFC 8412 |
| | | XML | |
| | | | |
| 0 | 1 | ISO 2009 SWID tags using | RFC 8412 |
| | | XML | |
| | | | |
| 0 | 192-255 | Reserved for local | N/A |
| | | enterprise use | |
+-----+---------+-----------------------------+---------------------+
[NIST8060] Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", DOI 10.6028/NIST.IR.8060, April 2016, <https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>.
[NIST8060]Waltermire，D.，Cheikes，B.，Feldman，L.，和G.Witte，“创建可互操作软件标识（SWID）标签的指南”，DOI 10.6028/NIST.IR.8060，2016年4月<https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<https://www.rfc-editor.org/info/rfc3339>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 5198，DOI 10.17487/RFC5198，2008年3月<https://www.rfc-editor.org/info/rfc5198>.
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, <https://www.rfc-editor.org/info/rfc5792>.
[RFC5792]Sangster，P.和K.Narayan，“PA-TNC：与可信网络连接（TNC）兼容的姿态属性（PA）协议”，RFC 5792，DOI 10.17487/RFC5792，2010年3月<https://www.rfc-editor.org/info/rfc5792>.
[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, <https://www.rfc-editor.org/info/rfc8089>.
[RFC8089]Kerwin，M.，“文件”URI方案，RFC 8089，DOI 10.17487/RFC8089，2017年2月<https://www.rfc-editor.org/info/rfc8089>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[SWID09] The International Organization for Standardization/ International Electrotechnical Commission, "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2009, November 2009, <https://www.iso.org/standard/53670.html>.
[SWID09]国际标准化组织/国际电工委员会，“信息技术-软件资产管理-第2部分：软件识别标签”，ISO/IEC 19770-2:2009，2009年11月<https://www.iso.org/standard/53670.html>.
[SWID15] The International Organization for Standardization/ International Electrotechnical Commission, "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2015, October 2015, <https://www.iso.org/standard/65666.html>.
[SWID15]国际标准化组织/国际电工委员会，“信息技术-软件资产管理-第2部分：软件识别标签”，ISO/IEC 19770-2:2015，2015年10月<https://www.iso.org/standard/65666.html>.
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, <https://www.rfc-editor.org/info/rfc5209>.
[RFC5209]Sangster，P.，Khosravi，H.，Mani，M.，Narayan，K.，和J.Tardo，“网络端点评估（NEA）：概述和要求”，RFC 5209，DOI 10.17487/RFC5209，2008年6月<https://www.rfc-editor.org/info/rfc5209>.
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, March 2010, <https://www.rfc-editor.org/info/rfc5793>.
[RFC5793]Sahita，R.，Hanna，S.，Hurst，R.，和K.Narayan，“PB-TNC：与可信网络连接（TNC）兼容的姿态代理（PB）协议”，RFC 5793，DOI 10.17487/RFC5793，2010年3月<https://www.rfc-editor.org/info/rfc5793>.
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013, <https://www.rfc-editor.org/info/rfc6876>.
[RFC6876]Sangster，P.，Cam Winget，N.，和J.Salowey，“TLS上的姿态传输协议（PT-TLS）”，RFC 6876，DOI 10.17487/RFC6876，2013年2月<https://www.rfc-editor.org/info/rfc6876>.
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, <https://www.rfc-editor.org/info/rfc7171>.
[RFC7171]Cam Winget，N.和P.Sangster，“PT-EAP：可扩展认证协议（EAP）隧道方法的姿态传输（PT）协议”，RFC 7171，DOI 10.17487/RFC7171，2014年5月<https://www.rfc-editor.org/info/rfc7171>.
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, <https://www.rfc-editor.org/info/rfc7632>.
[RFC7632]Waltermire，D.和D.Harrington，“端点安全态势评估：企业用例”，RFC 7632，DOI 10.17487/RFC7632，2015年9月<https://www.rfc-editor.org/info/rfc7632>.
[RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", RFC 8248, DOI 10.17487/RFC8248, September 2017, <https://www.rfc-editor.org/info/rfc8248>.
[RFC8248]Cam Winget，N.和L.Lorenzin，“安全自动化和连续监控（SACM）要求”，RFC 8248，DOI 10.17487/RFC8248，2017年9月<https://www.rfc-editor.org/info/rfc8248>.
Authors' Addresses
作者地址
Charles Schmidt The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America
查尔斯·施密特美国马萨诸塞州贝德福德伯灵顿路202号米特公司01730
Email: cmschmidt@mitre.org
Email: cmschmidt@mitre.org
Daniel Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America
丹尼尔·海恩斯美国马萨诸塞州贝德福德伯灵顿路202号米特尔公司01730
Email: dhaynes@mitre.org
Email: dhaynes@mitre.org
Chris Coffin The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America
美国马萨诸塞州贝德福德伯灵顿路202号Chris Coffin The MITRE Corporation 01730
Email: ccoffin@mitre.org
Email: ccoffin@mitre.org
David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland United States of America
David Waltermire美国马里兰州盖瑟斯堡市国家标准与技术研究所100局大道
Email: david.waltermire@nist.gov
Email: david.waltermire@nist.gov
Jessica Fitzgerald-McKay United States National Security Agency 9800 Savage Road Ft. Meade, Maryland United States of America
Jessica Fitzgerald McKay美国国家安全局9800 Savage Road Ft.Meade，美国马里兰州
Email: jmfitz2@radium.ncsc.mil
Email: jmfitz2@radium.ncsc.mil