SACM                                                           C. Coffin
Internet-Draft                                                 D. Haynes
Intended status: Standards Track                              C. Schmidt
Expires: December 10, 2016 March 16, 2017                            The MITRE Corporation
                                                     J. Fitzgerald-McKay
                                                   Department of Defense
                                                            June 8,
                                                      September 12, 2016

                 SWID

               Software Message and Attributes for PA-TNC
                  draft-coffin-sacm-nea-swid-patnc-01
                  draft-coffin-sacm-nea-swid-patnc-02

Abstract

   This document specifies the SWID Software Message and Attributes for PA-TNC. PA-
   TNC.  It extends the PA-TNC specification [RFC5792] by providing
   specific attributes and message exchanges to allow endpoints to
   report their software inventory information to a NEA server (as
   described in
   [RFC5209]) using SWID tags [SWID]. [RFC5209]).

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 10, 2016. March 16, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Scope and Audience  . . . . . . . . . . . . . . . . . . .   4
     1.2.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . .   7   6
     1.3.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   7   6
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Role of SWID Message and Attributes for PA-TNC  . . . . .   8
     2.2.  Supported Use Cases . . . . . . . . . . . . . . . . . . .   9
       2.2.1.   7
       2.1.1.  Use Software Inventory as a Factor in Determining
               Endpoint Access . . . . . . . . . . . . . . . . . . .   9
       2.2.2.   8
       2.1.2.  Maintain a Central Repository Reflecting an
               Endpoint's Software Inventory . . . . . . . . . . . .   9
       2.2.3.   8
       2.1.3.  PA-TNC Use Cases  . . . . . . . . . . . . . . . . . .  10
     2.3.   9
     2.2.  Non-supported Use Cases . . . . . . . . . . . . . . . . .  10
     2.4.   9
     2.3.  Specification Requirements  . . . . . . . . . . . . . . .  11
     2.5.  10
     2.4.  Non-Requirements  . . . . . . . . . . . . . . . . . . . .  13
     2.6.  11
     2.5.  Assumptions . . . . . . . . . . . . . . . . . . . . . . .  13
     2.7.  11
     2.6.  Non-Assumptions . . . . . . . . . . . . . . . . . . . . .  13
     2.8.  SWID  12
     2.7.  Software Message and Attributes for PA-TNC Diagram
           Conventions . . . . . . . . . . . . . . . . . . . . . . .  14  12
   3.  SWID  Software Message and Attributes for PA-TNC System
       Requirements  .  14
     3.1.  SWID Tags as Inventory Evidence . . . . . . . . . . . . .  15
     3.2.  Basic SWID Tag Inventory Exchange . . . . . . . . . . . .  15
     3.3.  SWID Tag Identifiers  . . . . . . . . . . . . . . .  13
     3.1.  Basic Inventory Exchange  . . .  16
       3.3.1.  Tag Identifier Data . . . . . . . . . . . . .  13
     3.2.  Software Identifiers  . . . .  17
       3.3.2.  Tag Identifier Instances . . . . . . . . . . . . . .  18
       3.3.3.  Comparing Tag  14
       3.2.1.  Record Identifiers and Tag Identifier
               Instances . . .  . . . . . . . . . . . . . . . . . . .  19
         3.3.3.1.  Matching Tag Identifiers Indicate the Same  15
       3.2.2.  Using Software Product  . . . . . . . . . . . . and Record Identifiers in SW
               Attributes  . . . .  20
         3.3.3.2.  Matching Tag Identifiers DO NOT Necessarily
                   Indicate Identical Tag Files . . . . . . . . . .  20
         3.3.3.3.  Matching Tag Identifier Instances MIGHT Indicate
                   Identical Tag Files . . . . . . .  16
     3.3.  Targeted Requests . . . . . . . .  21
         3.3.3.4.  Differing Tag Identifiers DO NOT Necessarily
                   Indicate Different Software Products . . . . . .  21
       3.3.4.  Using Tag Identifiers in SWID Attributes . . . . . .  22  16
     3.4.  Targeted Requests .  Monitoring Changes in an Endpoint's Software Inventory
           Evidence Collection . . . . . . . . . . . . . . . . . . .  22  17
     3.5.  Monitoring Changes in an Endpoint's SWID Tag Collection .  23
     3.6.  Reporting Change Events . . . . . . . . . . . . . . . . .  25
       3.6.1.  19
       3.5.1.  Change Event Records  . . . . . . . . . . . . . . . .  25
       3.6.2.  20
       3.5.2.  Updating Inventory Knowledge Based on Events  . . . .  27
       3.6.3.  21
       3.5.3.  Using Event Records in SWID SW Attributes  . . . . . . .  28
       3.6.4. .  22
       3.5.4.  Partial and Complete Lists of Event Records in SWID SW
               Attributes  . . . . . . . . . . . . . . . . . . . . .  28
       3.6.5.  22
       3.5.5.  Synchronizing Event Identifiers and Epochs  . . . . .  30
     3.7.  Supporting Multiple Instances of a Single Tag .  24
     3.6.  Subscriptions . . . . .  32
       3.7.1.  Inventory Reporting in the Presence of Multiply-
               Instantiated Tags . . . . . . . . . . . . . . . . .  26
       3.6.1.  Establishing Subscriptions  .  32
       3.7.2.  Event Reporting in the Presence of Multiply
               Instantiated Tags . . . . . . . . . . . . . . . . . .  32
     3.8.  Subscriptions . . . . . . . . . . . . . . . . . . . . . .  32
       3.8.1.  Establishing Subscriptions  . . . . . . . . . . . . .  33
       3.8.2.  26
       3.6.2.  Managing Subscriptions  . . . . . . . . . . . . . . .  33
       3.8.3.  27
       3.6.3.  Terminating Subscriptions . . . . . . . . . . . . . .  34
       3.8.4.  27
       3.6.4.  Subscription Status . . . . . . . . . . . . . . . . .  35
       3.8.5.  28
       3.6.5.  Fulfilling Subscriptions  . . . . . . . . . . . . . .  35
         3.8.5.1.  28
         3.6.5.1.  Subscriptions Reporting Inventories . . . . . . .  37
         3.8.5.2.  30
         3.6.5.2.  Subscriptions Reporting Events  . . . . . . . . .  37
         3.8.5.3.  30
         3.6.5.3.  Targeted Subscriptions  . . . . . . . . . . . . .  38
         3.8.5.4.  31
         3.6.5.4.  No Subscription Consolidation . . . . . . . . . .  39
         3.8.5.5.  32
         3.6.5.5.  Delayed Subscription Fulfillment  . . . . . . . .  39
     3.9.  32
     3.7.  Multiple Sources of SWID Tags . . . . . . . . . . . . . Software Inventory Evidence Records .  40
     3.10.  33
     3.8.  Error Handling  . . . . . . . . . . . . . . . . . . . . .  41  34
   4.  SWID  Software Message and Attributes for PA-TNC Protocol . . . . . . .  43  36
     4.1.  PA Subtype (AKA PA-TNC Component Type)  . . . . . . . . .  43  36
     4.2.  PB-TNC and PA-TNC Messages  . . . . . . . . . . . . . . .  44  36
     4.3.  PA-TNC Attribute Header . . . . . . . . . . . . . . . . .  44  37
     4.4.  SWID  SW Attribute Overview . . . . . . . . . . . . . . . . .  45 .  38
     4.5.  SWID  SW Attribute Exchanges  . . . . . . . . . . . . . . . .  47 .  40
     4.6.  SWID  Software Message and Attributes for PA-TNC Attribute
           Enumeration . . . . . . . . . . . . . . . . . . . . . . .  49  42
     4.7.  Normalization of Text Encoding  . . . . . . . . . . . . .  50  43
     4.8.  Request IDs . . . . . . . . . . . . . . . . . . . . . . .  51  44
     4.9.  SWID  SW Request  . . . . . . . . . . . . . . . . . . . . . .  52 .  45
     4.10. SWID Tag Software Identifier Inventory . . . . . . . . . . . . . .  56  48
     4.11. SWID Tag Software Identifier Events  . . . . . . . . . . . . . . .  59  51
     4.12. SWID Tag Software Inventory  . . . . . . . . . . . . . . . . . . .  64  56
     4.13. SWID Tag Software Events . . . . . . . . . . . . . . . . . . . . .  66  58
     4.14. Subscription Status Request . . . . . . . . . . . . . . .  70  62
     4.15. Subscription Status Response  . . . . . . . . . . . . . .  70  62
     4.16. PA-TNC Error as Used by SWID Software Message and Attributes
           for PA-TNC  . . . . . . . . . . . . . . . . . . . . . . . . .  72  64
       4.16.1.  SWID_ERROR,           SWID_SUBSCRIPTION_DENIED_ERROR  SW_ERROR,           SW_SUBSCRIPTION_DENIED_ERROR and           SWID_SUBSCRIPTION_ID_REUSE_ERROR
                SW_SUBSCRIPTION_ID_REUSE_ERROR Information . . . . .  66
       4.16.2.  SW_RESPONSE_TOO_LARGE_ERROR Information  . . . . . .  68
       4.16.3.  SW_SUBSCRIPTION_FULFILLMENT_ERROR Information  . . .  69
   5.  Supported Data Models . . . . . .  74
       4.16.2.  SWID_RESPONSE_TOO_LARGE_ERROR Information  . . . . .  75
       4.16.3.  SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information . .  77
   5.  Security Considerations . . . . . . . . .  71
     5.1.  ISO 2015 SWID Tags using XML  . . . . . . . . . .  78
     5.1.  Evidentiary Value of SWID Tags . . . .  71
       5.1.1.  Guidance on Normalizing Source Data to ISO 2015 SWID
               Tags using XML  . . . . . . . . .  79
     5.2.  Integrity of the SWID Tag Collection . . . . . . . . . .  79
     5.3.  Sensitivity  72
       5.1.2.  Guidance on Creation of Collected Software Identifiers from ISO
               2015 SWID Tags  . . . . . . . . . . . . . .  80
     5.4.  Integrity of Endpoint Records . . . . .  72
     5.2.  ISO 2009 SWID Tags using XML  . . . . . . . . .  81
     5.5.  SWID-PC Access Permissions . . . . .  72
       5.2.1.  Guidance on Normalizing Source Data to ISO 2015 SWID
               Tags using XML  . . . . . . . . . .  82
     5.6.  Sanitization of Tag Fields . . . . . . . . .  72
       5.2.2.  Guidance on Creation of Software Identifiers from ISO
               2015 SWID Tags  . . . . . .  82
     5.7.  Tag Library Poisoning . . . . . . . . . . . . .  73
   6.  Security Considerations . . . . .  83
     5.8.  PA-TNC Security Threats . . . . . . . . . . . . . . . . .  83
   6.  Privacy Considerations  . . . . . . .  73
     6.1.  Evidentiary Value of Software Inventory Evidence Records   73
     6.2.  Sensitivity of Collected Records  . . . . . . . . . . . .  83
   7.  Relationship to Other Specifications  74
     6.3.  Integrity of Endpoint Records . . . . . . . . . . . .  84
   8.  IANA Considerations . .  75
     6.4.  SW-PC Access Permissions  . . . . . . . . . . . . . . . .  75
     6.5.  Sanitization of Record Fields . . .  84
     8.1.  Registry for PA-TNC Attribute Types . . . . . . . . . . .  85
     8.2.  Registry for  76
     6.6.  PA-TNC Error Codes . . . . . . . . . . . . .  85
     8.3.  Registry for PA Subtypes  . . . . . . . . . . . . . . . .  86
   9.  References  . . . . . . . . . . . . . . . . . . . . . . Security Threats . . .  86
     9.1.  Normative References . . . . . . . . . . . . . .  76
   7.  Privacy Considerations  . . . .  87
     9.2.  Informative References . . . . . . . . . . . . . . .  76
   8.  Relationship to Other Specifications  . .  87
   Appendix A.  Examples . . . . . . . . . .  77
   9.  IANA Considerations . . . . . . . . . . . .  88
     A.1.  A Simple SWID Tag . . . . . . . . .  77
     9.1.  Registry for PA-TNC Attribute Types . . . . . . . . . . .  88
     A.2.  SWID Request Attributes  77
     9.2.  Registry for PA-TNC Error Codes . . . . . . . . . . . . .  78
     9.3.  Registry for PA Subtypes  . . . .  90
       A.2.1.  Simple Request . . . . . . . . . . . .  79
     9.4.  Registry for Software Data Models . . . . . . .  90
       A.2.2.  Subscription Request for Events . . . . .  80
   10. References  . . . . . .  91
       A.2.3.  Targeted Request . . . . . . . . . . . . . . . . . .  91
     A.3.  SWID Response Attributes .  80
     10.1.  Normative References . . . . . . . . . . . . . . .  93
       A.3.1.  SWID Tag Identifier Events Attribute . . .  80
     10.2.  Informative References . . . . .  93
       A.3.2.  SWID Tag Inventory Attribute . . . . . . . . . . . .  95  80
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  96  81

1.  Introduction

1.1.  Scope and Audience

   The Network Endpoint Assessment (NEA) Working Group defines 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, monitor endpoint health,
   and for many other activities.  Information about the software
   present on an endpoint is an important consideration for such
   activities.  Software Identification  Such information can come from multiple sources,
   including tag files (such as ISO SWID tags (SWID tags) [SWID] [SWID], reports from third
   party inventory tools, output from package managers, and other
   sources.  The attributes defined in this document are
   formatted records (usually XML documents) that identify a specific used to
   communicate software product.  In this case, a "software product" can be inventory evidence, collected from a
   distinct release of some piece range of software, such as an operating
   system, web browser, etc.; a patch or plug-in for such an
   application; or a suite of such applications.  The SWID specification
   describes
   possible sources, from the format of these documents as well as rules governing
   their use on computer systems.  In particular, software that supports
   SWID tags is expected to deposit an identifying tag posture collector on the endpoint
   when the software is installed, modify or replace the tag as the
   software is updated, and delete the tag when the software is
   uninstalled.  SWID tags can also be created and managed by third-
   party tools or by local enterprises, allowing for tags to indicate
   the presence of software even when that software's manufacturer has
   not included SWID support.  As such, by collecting a list of tags on
   an endpoint, one receives evidence as to the software present on that
   endpoint.  The attributes defined in this document are used to
   communicate software inventory evidence, in the form of SWID tags,
   between the posture collector and
   posture validator on a NEA Server using the PA-TNC interface, as
   shown in Figure 1 below.

       +-------------+                          +--------------+
       |  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

   The use

   This specification defines a new set of standard protocols PA-TNC attributes, carried
   over PA-TNC messages, which are used to communicate requests for
   software information and software events, and formats for conveying evidence
   about endpoint state (in this case, endpoint inventory information)
   has that
   information back to a number NEA Server.

   Possession of benefits.  The use a list of standard protocols an endpoint's installed software is very
   useful in understanding and formats
   facilitates interoperability between products developed by different
   vendors.  This allows consumers to select the product that has
   features that best fit with maintaining the needs security state of their environment, with an
   enterprise.  For example, if an enterprise policy requires the
   expectation that it will be able to interoperate with other parts of
   their infrastructure (at least with regard to the aforementioned
   protocols and formats).  In addition, because a standard is expected
   to be implemented by multiple independent parties, this means that
   the standard protocols and formats receive more review than might be
   expected in a proprietary solution.  When the standard is managed by
   a group that is responsive to feedback from such implementers, as is
   the case with the IETF, this can lead to improvements in efficiency
   and security of those protocols and formats.  For these reasons, a
   standard means of conveying endpoint inventory information such as
   the one described in this document provides significant value to
   users.  Vendors benefit from utilizing SWIDs to serve as evidence of
   software inventory because it reduces their need to develop remote
   software inventory tools for the increasing variety of endpoint
   platforms.  If those endpoints support SWID Message and Attributes
   for PA-TNC, vendors can use these protocols to gather software
   inventory information remotely.

   This specification defines a new set of PA-TNC attributes, carried
   over PA-TNC messages, which are used to communicate requests for SWID
   tags and events surrounding those tags, and for conveying that
   information back to a NEA Server.

   Possession of a list of an endpoint's SWID tags is very useful in
   understanding and maintaining the security state of an enterprise.
   For example, if an enterprise policy requires the presence
   presence of certain pieces of software and/or prohibits the presence
   of other software,
   SWID tags reported software inventory lists can be used to
   indicate compliance or non-compliance with these requirements.  SWID tags indicating software
   Software presence and the patch level of that software can be
   compared to vulnerability or threat alerts to determine an endpoint's
   exposure to attack.  SWID
   tags provide a great deal of information about unfamiliar software
   products, including the software author and potentially including
   where the software is installed on the endpoint and what files on the
   endpoint are associated with this installed software.  All of these uses make an understanding of an
   endpoint's SWID tag software collection highly useful to NEA Servers and other
   enterprise security applications.

   Before reading this specification any further, the reader should
   review and understand the NEA reference architecture as described in
   the Network Endpoint Assessment (NEA): Overview and Requirements
   [RFC5209].  The reader should also understand the capabilities and
   requirements common to PA-TNC interfaces as defined in RFC 5792
   [RFC5792].

   This document is based on standards published by the Trusted
   Computing Group's Trusted Network Communications (TNC) workgroup.
   The TNC and NEA architectures are interoperable and the following
   components are equivalent:

     +---------------------------------------+-----------------------+
     | TNC Component                         | NEA Component         |
     +---------------------------------------+-----------------------+
     | Integrity Measurement Verifier (IMV)  | Posture Validator     |
     |                                       |                       |
     | Integrity Measurement Collector (IMC) | Posture Collector     |
     |                                       |                       |
     | TNC Server (TNCS)                     | Posture Broker Server |
     |                                       |                       |
     | TNC Client (TNCC)                     | Posture Broker Client |
     +---------------------------------------+-----------------------+

        Table 1: Equivalent components in TNC and NEA architectures

1.2.  Keywords

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   specification are to be interpreted as described in RFC 2119
   [RFC2119].  This specification does not distinguish blocks of
   informative comments and normative requirements.  Therefore, for the
   sake of clarity, note that lower case instances of must, should, etc.
   do not indicate normative requirements.

1.3.  Definitions

   This section defines terms with special meaning within this document.

   SWID-PC

   SW-PC - A Posture Collector (PC) that conforms to this specification.
   Note that such a posture collector might also support other PA-TNC
   exchanges beyond SWID Software Message and Attributes for PA-TNC.

   SWID-PV

   SW-PV - A Posture Validator (PV) that conforms to this specification.
   Note that such a posture verifier might also support other PA-TNC
   exchanges beyond SWID Software Message and Attributes for PA-TNC.

   SW Attribute - This is a PA-TNC attribute (as defined in RFC 5792
   [RFC5792] extension for conveying software inventory information.
   This specification defines several new attribute types.

   Endpoint's SWID Tag Software Inventory Evidence Collection - The set of SWID tags
   information regarding the set of software installed and
   managed on an endpoint for software installed on that endpoint.
   and expressed using one of the Software Message and Attributes data
   models, as described in the Software Data Model IANA table (see
   Section 9.4.  An endpoint's SWID tag software inventory evidence collection
   might include SWID tags information created by or derived from multiple
   sources, including but not limited to SWID tag files deposited on the
   file system during software installation, SWID tags information generated to
   report output from software discovery tools, and SWID tags information
   dynamically generated by a software or package management system on
   an endpoint.

2.  Background
2.1.  Role

   Software Inventory Evidence Record - The endpoint's Software
   Inventory Evidence Collection is composed of SWID "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 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.

   Software Identifier - A string associated with a specific version of
   a specific software product.  Each supported Software Message and
   Attributes for PA-TNC

   The International Organization data model has its own rules for Standardization and how a Software
   Identifier (see Section 3.2) is derived from the
   International Electrotechnical Commission (ISO/IEC) published representation of
   the
   specification governing SWID tag construction and use in 2009.
   [SWID] Since given software product using that time, data model, and different
   sources for this information might populate relevant information
   differently.  As such, while each Software Identifier uniquely
   identifies a growing number of vendors have integrated
   SWID tags into their specific software products.  Doing so significantly
   simplifies product, the task of identifying these pieces of software: instead
   of relying on discovery processes that look for clues as to same software
   presence, such as the presence of particular files or registry keys,
   a readily available list of SWID tags provides simple and immediate
   evidence as to the presence of the given piece of software.

   SWID tags can also product
   might be useful even when a piece of software does not
   supply the tags itself.  Discovery processes are permitted to express
   their findings using SWID tags, place these in the endpoint's SWID
   tag collection, associated with multiple Software Identifiers reflecting
   differences between different information sources and maintain them like vendor-created SWID tags. supported data
   models.

2.  Background

2.1.  Supported Use Cases

   This means that an endpoint's SWID tag collection is not necessarily
   limited to containing SWID tags section describes the Software Message and Attributes for PA-TNC
   use cases supported by this specification.  The primary use of
   exchanging software whose authors have taken inventory information over the time PA-TNC interface
   is to integrate SWID maintenance into their installation and
   update processes.  Similarly, software and package managers on an
   endpoint (such as RPM and YUM) keep records of installed software,
   and these records can be exported as enable a series of SWID tags, allowing
   these managers challenger (e.g.  NEA Server) to expose their information obtain inventory
   evidence about software inventories some system in a standards-based manner.  Finally, for organizations way that
   centrally manage the distribution of software, in-house-developed
   SWID tags can be added conforms to any NEA procedures
   and expressed using a standard format.  Collected software product that does not natively
   information can support SWID tags allowing the organization a range of security activities including
   determining whether an endpoint is permitted to accurately identify
   any connect to the
   enterprise, determining which endpoints contain software it has distributed.

   The that
   requires patching, and similar activities.

2.1.1.  Use Software Inventory as a Factor in Determining Endpoint
        Access

   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
   by endpoints that have certain prohibited pieces of software
   installed, such as applications that pose known security risks.  To
   support such policies, the NEA Server needs access to this inventory collect evidence if it
   indicating the software inventory of an endpoint that is seeking to
   use this information
   initiate or continue connectivity to assess endpoint compliance with policy.  The
   SWID the enterprise.

   Software Message and Attributes for PA-TNC specification has been created
   for this purpose.  Specifically, the attributes defined in this
   specification allow a Posture Validator to request evidence of facilitates policy
   decisions that consider an endpoint's software inventory in the form of SWID tags and allow by providing
   the Posture
   Collector to respond NEA Server with software inventory information from the appropriate information.

   It is not necessary endpoint.
   The SW-PC can provide a complete or partial inventory to understand the details of SWID tag
   construction and maintenance SW-PV as
   required to understand the behaviors described in
   the SWID Message and Attributes for PA-TNC specification, and it is
   beyond the scope of determine policy compliance.  The SW-PV can then use this specification to discuss the details
   as evidence of the
   SWID standard.  Implementers, however, will likely need to be
   familiar compliance or non-compliance with the SWID tag format and how enterprise policy.

2.1.2.  Maintain a Central Repository Reflecting an Endpoint's Software
        Inventory

   Many tools can use information about an endpoint's software inventory
   to locate tags on monitor and enforce the security of an
   endpoint.  The SWID specification is available from ISO/IEC at
   http://www.iso.org/iso/catalogue_detail.htm?csnumber=53670.  The XML
   schema for enterprise.  For example, a SWID tag file is available from ISO:
   http://standards.iso.org/iso/19770/-2/2009/schema.xsd.  The most
   current working
   software patching service can use an endpoint's software inventory to
   determine whether certain endpoints have software that requires
   patching.  A vulnerability management tool might identify endpoints
   with known vulnerabilities (patched or otherwise) and production versions use this to
   gauge enterprise exposure to attack.  A license management tool might
   verify that all copies of the XML schema a particular piece of software are
   accounted for SWID
   tags can be found in within the directory listing at
   http://standards.iso.org/iso/19770/-2/. enterprise.  The US National Institute presence of
   Standards and Technology (NIST) also has published guidelines for
   SWID tag creation, which provide further guidance for those
   interested in a central
   repository representing a real-time understanding of each endpoint's
   software inventory facilitates all such activities.  Using a central
   repository that can ensure the use and best practices surrounding SWID tags.
   [NIST-SWID]

2.2.  Supported Use Cases

   This section describes freshness of its collected information
   is generally more efficient than having each tool collect the SWID same
   inventory information from each endpoint individually and leads to a
   more consistent understanding of enterprise state.

   Software Message and Attributes for PA-TNC use
   cases supported by supports this specification.  The primary use activity
   through a number of exchanging
   SWID tag information over the PA-TNC interface is to enable mechanisms.  As noted above, it allows a
   challenger (e.g.  NEA Server) SW-PC to obtain inventory evidence about some
   system in
   provide a way that conforms to NEA procedures while taking
   advantage complete list of software present in an endpoint's Software
   Inventory Evidence Collection to the simplicity and precision of SWID tags.  Collected
   SWID tags SW-PV, which can support then pass this
   information on to a range of security activities including
   determining whether an endpoint is permitted central repository such as a Configuration
   Management Database (CMDB) or similar application.  In addition, SW-
   PCs are required to connect be able to the
   enterprise, determining which endpoints contain software that
   requires patching, and similar activities.

2.2.1.  Use monitor for changes to an endpoint's
   Software Inventory as a Factor Evidence Collection in Determining Endpoint
        Access

   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
   by endpoints that have certain prohibited pieces near real-time and push
   reports of software
   installed, such changes to the SW-PV as applications that pose known security risks.  To
   support soon as those changes are
   detected.  Thus any central repository fed by a SW-PV receiving such policies,
   information can be updated soon after the NEA Server needs to collect evidence
   indicating change occurs.  Keeping
   such a central repository synchronized with the software inventory state of an endpoint each
   endpoint's Software Inventory Evidence Collection allows tools that is seeking to
   initiate or continue connectivity
   use this information for their own security activities to the enterprise.

   SWID make
   decisions in a consistent, efficient manner.

2.1.3.  PA-TNC Use Cases

   Software Message and Attributes for PA-TNC facilitates policy decisions
   that consider an endpoint's software inventory by providing the NEA
   Server with a list of the SWID tags in are intended to operate
   over the endpoint's SWID tag
   collection.  The tags in this collection serve as evidence PA-TNC interface and, as such, are intended to meet the
   endpoint's installed software.  The SWID-PC can provide a complete or
   partial list of tags to use
   cases set out in the SWID-PV as required to determine policy
   compliance.  The SWID-PV can then PA-TNC specification.

2.2.  Non-supported Use Cases

   Some use cases not covered by this as evidence version of compliance
   or non-compliance with enterprise policy.

2.2.2.  Maintain a Central Repository Reflecting an Endpoint's Software
        Inventory

   Many tools can use information about an endpoint's software inventory
   to monitor Message and enforce
   Attributes for PA-TNC include:

   o  This specification does not address how the security of an enterprise.  For example, a
   software patching service can use an endpoint's software inventory Software
      Inventory Evidence Collection is populated.  In particular, NEA
      components are not expected to
   determine whether certain endpoints have perform software that requires
   patching.  A vulnerability management tool discovery
      activities beyond compiling information in an endpoint's Software
      Inventory Evidence Collection.  This collection might identify endpoints
   with known vulnerabilities (patched potentially
      come from multiple sources on the endpoint (e.g., information
      generated dynamically by package management tools or otherwise) and use this to
   gauge discovery
      tools, as well as SWID tag files discovered on the file system).
      While an enterprise exposure to attack.  A license management tool might
   verify that all copies of a particular piece make use of software discovery
      procedures to identify installed software such procedures are
   accounted for within
      outside the enterprise.  The presence of a central
   repository representing a real-time understanding scope of each endpoint's
   software this specification.

   o  This specification does not address converting inventory facilitates all such activities.  Using
      information expressed in a central
   repository that can ensure proprietary format into the freshness standard
      format used in the messages described in this specification.
      Instead, it focuses exclusively on defining interfaces for the
      transportation of its collected software information in the expectation that
      this is generally more efficient than having each tool collect the same
   inventory information from each endpoint individually and leads to a
   more consistent understanding of enterprise state.

   SWID Message and Attributes format around which reporting tools will converge.

   o  This specification provides no mechanisms for PA-TNC supports this activity through
   a number of mechanisms.  As noted above, it allows a SWID-PC posture validator
      to
   provide request a complete 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 tags present in an endpoint's SWID tag software inventory evidence
      collection has been copied to some central location, such as the SWID-PV, which
      CMDB, processes there can then pass this information perform queries based on to
   a central repository any criteria
      present in the collected information, but this specification does
      not address using such as a Configuration Management Database
   (CMDB) or similar application.  In addition, SWID-PCs are required to
   be able to monitor for changes queries to an endpoint's SWID tag constrain the initial collection
   in near real-time and push reports
      of changes to this information from the SWID-PV as soon
   as those changes are detected.  Thus any central repository fed by a
   SWID-PV receiving such endpoint.

   o  This specification does not address utilization of properties of
      certain sources of software information can be updated soon after that might facilitate
      local tests (i.e., on the
   change occurs.  Keeping such a central repository synchronized with endpoint) of endpoint state.  For
      example, the state optional package_footprint field of each endpoint's an ISO SWID tag collection allows tools that
   use this information for their own security activities to make
   decisions in
      can contain a consistent, efficient manner.

2.2.3.  PA-TNC Use Cases

   SWID Message list of files and Attributes for PA-TNC are intended to operate over hash values associated with the PA-TNC interface and, as such, are intended to meet
      software indicated by the tag.  Tools on the endpoint can use cases
   set out the
      values in this field to test for the PA-TNC specification.

2.3.  Non-supported Use Cases

   Some use cases 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 covered by provide values for tag
      fields that support local testing.  For this version reason, the added
      complexity of SWID supporting endpoint testing using these fields is
      out of scope for this specification.  Future versions of this
      specification might add support for such testing.

2.3.  Specification Requirements

   Below are the requirements that the Software Message and Attributes
   for PA-TNC include:

   o  This specification does not address how the endpoint's SWID tag
      collection is populated.  In particular, required to meet in order to successfully
   play its role in the NEA components are architecture.

   o  Efficient

   The NEA architecture enables delay of network access until the
   endpoint is determined not
      expected to perform software discovery activities beyond compiling pose a security threat to the tags in an endpoint's SWID tag collection.  This collection
      might potentially come from multiple sources network
   based on its asserted integrity information.  To minimize user
   frustration, the endpoint
      (e.g., SWID tags generated dynamically by package management tools
      or discovery tools, Software Message and Attributes for PA-TNC ought to
   minimize overhead delays and make PA-TNC communications as well rapid and
   efficient as SWID tag files discovered on the
      file system).  While an enterprise might make use of software
      discovery procedures to identify installed software, especially
      software possible.

   Efficiency is also important when one considers that does not install or manage its own SWID tag, such
      procedures some network
   endpoints are outside the scope of this specification.

   o  This specification does not address converting inventory
      information expressed small and low powered, some networks are low bandwidth
   and/or high latency, and some transport protocols (such as PT-EAP,
   Posture Transport (PT) Protocol for Extensible Authentication
   Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
   protocol might allow only one packet in flight at a proprietary format into the SWID tag
      format time or converting a SWID tag into a proprietary format.
      Instead, it focuses exclusively on defining interfaces for only one
   roundtrip.  However, when the
      transportation underlying PT protocol imposes fewer
   constraints on communications, this protocol ought to be capable of SWID tags
   taking advantage of more robust communication channels (e.g. using
   larger messages or multiple roundtrips).

   o  Scalable

   Software Message and Attributes for PA-TNC needs to be usable in the expectation
   enterprises that this is the
      format around which reporting contain tens of thousands of endpoints or more.  As
   such, it needs to allow a security tools will converge. 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.

   o  Interoperable

   This specification provides no mechanisms defines the protocol for a posture validator how PCs and PVs can
   exchange and use software information to request provide a specific list of tags based on arbitrary tag
      properties from the endpoint.  For example, requesting only tags
      representing NEA Server with
   information about an endpoint's software from inventory.  Therefore a particular vendor key
   goal for this specification is not supported.
      After ensuring that all SW PCs and PVs,
   regardless of the endpoint's SWID tag collection has been copied vendor who created them, are able to some
      central location, such as the CMDB, processes there can perform
      queries based on any criteria present interoperate
   in the collected SWID tags,
      but this specification does not address using such queries to
      constrain the initial collection their performance of this information from the
      endpoint. these duties.

   o  Support precise and complete historical reporting

   This specification does not address utilization outlines capabilities that support real-time
   understanding of certain SWID
      tag fields designed to facilitate local tests (i.e., on the
      endpoint) state of endpoint state.  For example, the optional
      package_footprint field of in a SWID tag can contain network in a list way that can
   be used by other tools.  One means of files facilitating such an outcome is
   for a Configuration Management Database (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 hash values associated with the
   present.  In such a scenario, it is necessary that any PC be able to
   report any changes to its software indicated by inventory evidence collection in
   near real-time while connected and, upon reconnection to the tag.
      Tools on
   enterprise, be able to update the endpoint can use NEA Server (and through it the values in this field
   CMDB) with regard to test for the presence state of its software inventory evidence
   collection throughout 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 entire interval when it was 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.  Future
      versions of this specification might add support for such testing. connected.

2.4.  Specification Requirements

   Below  Non-Requirements

   There are the certain requirements that the SWID Software Message and
   Attributes for PA-TNC specification explicitly is not required to meet in order
   meet.  This list is not exhaustive.

   o  End to successfully
   play its role in End Confidentiality

   This specification does not define mechanism for confidentiality, nor
   is this property automatically provided by PA-TNC interface use.
   Confidentiality is generally provided by the NEA architecture.

   o  Efficient

   The NEA architecture enables delay of network access until underlying transport
   protocols, such as the
   endpoint is determined not PT Binding to pose a security threat TLS [RFC6876] or PT-EAP Posture
   Transport for Tunneled EAP Methods [RFC7171] - see Section 8 for more
   information on related standards.  Should users wish confidentiality
   protection of assessment instructions or results, this needs to be
   provided by parts of the network
   based on its asserted integrity information.  To minimize user
   frustration, NEA architecture other than this
   specification.

2.5.  Assumptions

   Here are the SWID assumptions that Software Message and Attributes for PA-TNC ought to
   minimize overhead delays PA-
   TNC makes about other components in the NEA architecture.

   o  Reliable Message Delivery
   The Posture Broker Client and make Posture Broker Server are assumed to
   provide reliable delivery for PA-TNC communications as rapid messages and
   efficient as possible.

   Efficiency is also important when one considers that some network
   endpoints are small and low powered, some networks are low bandwidth
   and/or high latency, and some transport protocols (such as PT-EAP,
   Posture Transport (PT) Protocol for Extensible Authentication
   Protocol (EAP) Tunnel Methods [RFC7171]) or their underlying carrier
   protocol might allow only one packet in flight at a time or only one
   roundtrip.  However, when therefore the underlying PT protocol imposes fewer
   constraints on communications, this protocol ought to be capable of
   taking advantage of more robust communication channels (e.g. using
   larger messages or multiple roundtrips).

   o  Loosely Coupled to
   Attributes sent between the SWID Specification

   Because SW PCs and the SWID specification is managed by ISO/IEC, PVs.  In the IETF has no
   direct influence over this specification event that
   reliable delivery cannot be provided, the Posture Collector or any revisions made
   Posture Validator is expected to it.
   For this reason, terminate the SWID connection.

2.6.  Non-Assumptions

   The Software Message and Attributes for PA-TNC specification ought to minimize its requirements and assumptions with
   regard to the structure
   explicitly does not assume:

   o  Authenticity and content Accuracy of the SWID tags.  While some
   level of visibility into tag contents is required for certain
   features of this specification, minimization of such dependencies is
   necessary to improve compatibility Software Inventory Evidence
      Collection with future revisions of the SWID
   specification.

   o  Scalable

   SWID Message and Attributes for PA-TNC needs to be usable in
   enterprises that contain tens of thousands of endpoints or more.  As
   such, it needs Regard to allow a security tools Endpoint Inventory

   This specification makes no assumption as to make decisions based on
   up-to-date whether the software
   information about an endpoint's that it reports correctly reflect the software inventory without
   creating an excessive burden state on
   the enterprise's network.

   o  Interoperable endpoint.  This specification defines does not attempt to detect when the protocol for how PCs and PVs can
   exchange
   endpoint is providing false information, either through malice or
   error, but instead focuses on correctly and use SWID tags reliably providing the
   reported Software Inventory Evidence Collection to provide a the NEA Server with information
   about an endpoint's software inventory.  Therefore a key goal for Server.
   Similarly, this specification is ensuring that all SWID PCs and PVs, regardless
   of the vendor who created them, are able makes no assumption with regard to interoperate in their
   performance the
   completeness of these duties.

   o  Support precise and complete historical reporting

   This specification is expected to outline capabilities that support
   real-time understanding the Software Inventory Evidence Collection's coverage
   of the state total set of endpoint in a network in a
   way software installed on the endpoint.  It is
   possible, and even likely, that can be used by other tools.  One means of facilitating such
   an outcome some installed software is for not
   represented by a Configuration Management Database (CMDB) to be
   able to contain information about all record in an endpoints connected to the
   enterprise Software Inventory Evidence
   Collection.  See Section 6 for all points in time between more on this security consideration.

2.7.  Software Message and Attributes for PA-TNC Diagram Conventions

   This specification defines the endpoint's first
   connection syntax of the Software Message and
   Attributes for PA-TNC using diagrams.  Each diagram depicts the present.  In such a scenario, it is necessary that
   any PC be able to report any changes to its SWID tag collection
   format and size of each field in
   near real-time while connected and, upon reconnection to bits.  Implementations MUST send the
   enterprise, be able
   bits in each diagram as they are shown from left to update the NEA Server (and through it right for each
   32-bit quantity traversing the
   CMDB) with regard diagram from top to bottom.  Multi-
   octet fields representing numeric values MUST be sent in network (big
   endian) byte order.

   Descriptions of bit fields (e.g. flags) values refer to the state position
   of its SWID tag collection throughout the entire interval when it was not connected.

2.5.  Non-Requirements

   There bit within the field.  These bit positions are certain requirements that numbered from
   the SWID 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).

3.  Software Message and Attributes for PA-TNC System Requirements

   The Software Message and Attributes for PA-TNC specification explicitly is not required to meet.  This
   list is not exhaustive.

   o  End to End Confidentiality

   SWID tags have no inherent mechanism
   facilitates the exchange of software inventory and event information.
   Specifically, each application supporting Software Message and
   Attributes for confidentiality, nor is this
   property automatically provided by PA-TNC interface use.
   Confidentiality includes a component known as the SW-PC that
   receives messages sent with the SW Attributes component type.  The
   SW-PC is generally provided by also responsible for sending appropriate SW Attributes back
   to the underlying transport
   protocols, such as SW-PV in response.  This section outlines what software
   inventories and events are and the PT Binding requirements on SW-PCs and SW-PVs
   in order to TLS [RFC6876] or PT-EAP Posture
   Transport for Tunneled EAP Methods [RFC7171] - see Section 7 for more
   information on related standards.  Should users wish confidentiality
   protection support the stated use cases of assessment instructions or results, this needs to be
   provided by parts of specification.

3.1.  Basic Inventory Exchange

   In the NEA architecture other than most basic exchange supported by this
   specification.

2.6.  Assumptions

   Here are specification, a SW-PV
   sends a request to the assumptions that SWID Message and Attributes for PA-TNC
   makes about other components SW-PC requesting all inventory information in
   the NEA architecture.

   o  Reliable endpoint's Software Inventory Evidence Collection.  This simple
   exchange is shown in Figure 2.

       +-------------+                          +--------------+
       |   SW-PC     |                          |    SW-PV     |  Time
       +-------------+                          +--------------+   |
             |                                         |           |
             |<--------------SW Request----------------|           |
             |                                         |           |
             |---------------SW Response-------------->|           |
             |                                         |           V

                    Figure 2: Basic SW Message Delivery

   The Posture Broker Client and Posture Broker Server are assumed to
   provide reliable delivery for PA-TNC messages and therefore the SWID
   Attributes sent between the SWID PCs and the PVs.  In Exchange

   Upon receiving such a SW Request from the event that
   reliable delivery cannot be provided, SW-PV, the Posture Collector or
   Posture Validator SW-PC is
   expected to terminate collect all inventory information from the connection.

2.7.  Non-Assumptions

   The SWID Message endpoint's
   software evidence collection and Attributes place it within its response
   attribute.

   SW-PVs MUST discard without error any SW Response attributes that
   they receive for PA-TNC specification explicitly
   does which they do not assume:

   o  Authenticity and Accuracy of SWID tags with Regard know the SW Request parameters
   that led to Endpoint
      Inventory this SW Response.  This specification makes no assumption as is due to whether the SWID tags fact that it reports are authentic tags (rather than maliciously
   generated) or the SW
   Request includes parameters that these tags correctly reflect software state on control the
   endpoint.  This specification does not attempt to detect when nature of the
   endpoint is providing false information, either through malice or
   error, but instead focuses on correctly response
   (as will be described in the following sections) and without knowing
   those parameters the SW Response cannot be reliably providing interpreted.
   Most often receiving an unsolicited SW Response attribute happens
   when a NEA Server has multiple SW-PVs; one SW-PV sends a SW Request
   but, unless exclusive delivery is used by the
   existing SWID tags to SW-PC in sending the NEA Server.  Similarly,
   response, both SW-PVs receive copies of the resulting SW Response.
   In this specification
   makes no assumption with regard to case, the completeness of SW-PV that didn't send the SWID tag
   collection's coverage of SW Request would lack
   the total set of software installed on context necessary to correctly interpret the
   endpoint.  It is possible, SW Response it
   received and even likely, would simply discard it.  Note, however, that some installed
   software is not represented by
   proprietary measures might allow a tag in an endpoints SWID tag
   collection.  See Section 5 for more on this security consideration.

2.8.  SWID Message and Attributes for PA-TNC Diagram Conventions

   This specification defines the syntax of SW-PV to discover the SWID Message and
   Attributes SW Request
   parameters for PA-TNC using diagrams.  Each diagram depicts the
   format and size of each field in bits.  Implementations MUST a SW Response even if that SW-PV did not send the
   bits in each diagram as they
   given SW Request.  As such, there is no blanket requirement for a SW-
   PV to discard all SW Responses to SW Request the SW-PV did not
   generate itself, only that SW-PVs are shown from left required to right discard SW
   Responses for each
   32-bit quantity traversing the diagram from top which they cannot get the necessary context to bottom.  Multi-
   octet fields representing numeric values MUST be sent in network (big
   endian) byte order.

   Descriptions of bit fields (e.g. flags) values refer
   interpret.

   In the case that it is possible to do so, the position
   of SW-PC SHOULD send its
   SW Response attribute to the bit within SW-PV that requested it using exclusive
   delivery as described in section 4.5 of RFC 5793 (PB-TNC) [RFC5793].
   Exclusive delivery ensures that only the field.  These bit positions are numbered from sender of the most significant bit through SW Request
   receives the least significant bit.  As such,
   an octet with only bit 0 set would have resulting SW Response.

3.2.  Software Identifiers

   Software information records contain a value large amount of 0x80 (1000 0000),
   an octet with only bit 1 set would have a value descriptive
   information about installed software products.  However, in many
   cases the complete level of 0x40 (0100 0000),
   and an octet with only bit 7 set would have a value detail in these records is not necessary.
   For example, if one is simply tracking the installation or removal of 0x01 (0000
   0001).

3.  SWID
   known software products, one only needs enough information to
   recognize the software added or removed.  To allow such uses to be
   efficiently supported, Software Message and Attributes for PA-TNC System Requirements
   supports the use of Software Identifiers.

   A Software Identifier uniquely identifies a specific version of a
   specific software product.  The SWID Software Message and Attributes for
   PA-TNC specification facilitates does not dictate the exchange structure of SWID tag inventories and event information.
   Specifically, each application supporting SWID Message and Attributes
   for PA-TNC includes a component known as the SWID-PC Software
   Identifier (beyond stating that receives
   messages sent with the SWID Attributes component type.  The SWID-PC it is also responsible for sending appropriate SWID Attributes back to
   the SWID-PV in response.  Similarly, the SWID-PV exists on a NEA
   Server and string) or define how it is responsible
   created.  Instead, each data model described in the Software Data
   Model IANA table (Section 9.4 includes its own rules for interpreting responses, forwarding
   information to how a CMDB if desired, and making policy decisions
   Software Identifier is created based
   upon the received information.  This section outlines what a SWID tag
   inventory is, important features of tags used by this specification,
   and the requirements on SWID-PCs and SWID-PVs a record in order to support the
   stated use cases of this specification.

3.1.  SWID Tags as Endpoint's
   Software Inventory Evidence

   As noted Collection expressed in Section 2.1, SWID tags are intended to be open, easily
   accessible evidence indicating that data model.
   Within the presence of a particular piece of
   software on Software Message and Attributes for PA-TNC specification,
   the Software Identifier is simply an endpoint.  A SWID tag contains multiple fields
   intended opaque string.

   Software Identifiers allow SW Response messages to uniquely identify a single software product.  Ideally,
   to a
   SWID tag is managed by server at a fraction of the software bandwidth that installs, modifies,
   replaces, amends (e.g. patches, updates), and/or uninstalls would be needed to
   send the
   product.  Discovery processes, software package managers, and other
   tools can also create entire associated record.  For some combinations of data
   models and manage tags sources, the full record might never be necessary as a way to represent software
   that they discover or manage on the endpoint.

   It is important
   identifier can be directly correlated to note that, even in the ideal cases where a product
   manages its own contents of the full
   record.  This is possible with authoritative SWID tag, tags, since these
   tags always have the same contents and thus a tag is inherently distinct Software Identifier
   derived from the
   product that it identifies.  For this reason, a SWID tag needs to be
   treated as evidence of software presence, but cannot these tags can be treated used as
   proof of software presence.  That noted, a standardized
   representation lookup to a local copy of evidence indicative
   the full tag.  For other combinations of an endpoint's software
   inventory is source and data model, a powerful tool in managing
   server might not be able to determine the specific software within an
   enterprise.

3.2.  Basic SWID Tag Inventory Exchange

   In product
   and version associated with the most basic exchange supported by this specification, a SWID-PV
   sends identifier without requesting deliver
   of the full record.  In either case, however, a request SW-PV can use
   Software Identifiers to track the SWID-PC requesting presence of specific software
   products on an endpoint over time in a copy bandwidth-efficient manner.

   There are two important limitations of all Software Identifiers to keep
   in mind:

      The identifiers do not necessarily change when the SWID tags associated
      record changes.  In some situations, a record in the endpoint's SWID tag collection.  This simple exchange is shown
      Software Inventory Evidence Collection will change due to new
      information becoming available or in Figure 2.

       +-------------+                          +--------------+
       |  SWID-PC    |                          |   SWID-PV    |  Time
       +-------------+                          +--------------+   |
             |                                         |           |
             |<-------------SWID Request---------------|           |
             |                                         |           |
             |--------------SWID Response------------->|           |
             |                                         |           V

                   Figure 2: Basic SWID Message Exchange

   Upon receiving such a SWID Request from order to correct prior errors
      in that information.  Such changes might or might not result in
      changes to the SWID-PV, Software Identifier, depending on the SWID-PC is
   expected to locate nature of the endpoint's SWID tags
      changes and then create copies the rules governing how Software Identifiers are
      derived from records of
   all identified SWID tags and place them within its response
   attribute.

   SWID-PVs MUST discard without error any SWID Response attributes the appropriate data model.

      It is possible that
   they receive a single software product is installed on a
      single endpoint multiple times.  If both of these installation
      instances are reported by the same source using the same data
      format, then this will result in identical Software Identifiers
      for which they each installation instances.  In other words, Software
      Identifiers do not know the SWID Request parameters
   that led uniquely identify installation instances; they
      just uniquely identify software products (which might have more
      than one installation instance).  Instead, to this SWID Response.  This is due distinguish between
      multiple instances of a single software product, one needs to the fact that the
   SWID Request includes parameters that control the nature make
      use of the
   response (as will be Record Identifiers, described in the following sections) and without
   knowing those parameters the SWID Response cannot be reliably
   interpreted.  Most often receiving an unsolicited SWID Response
   attribute happens when a NEA Server has multiple SWID-PVs; one SWID-
   PV sends a SWID Request but, unless exclusive delivery section.

3.2.1.  Record Identifiers

   A Record Identifier is used a string generated by the
   SWID-PC in sending the response, both SWID-PVs receive copies of the
   resulting SWID Response.  In this case, the SWID-PV SW-PC that didn't send
   the SWID Request would lack is
   uniquely associated with a specific record within the context necessary Endpoint's
   Software Inventory Evidence Collection.  The SW-PC MUST assign a
   unique identifier to correctly
   interpret the SWID Response each record when it received and would simply discard it.
   Note, however, is added to the Endpoint's
   Software Inventory Evidence Collection.  The Record Identifier SHOULD
   remain unchanged if that proprietary measures record is modified.  The SWID-PC might allow a SWID-PV wish
   to
   discover the SWID Request parameters for a SWID Response even if assign Record Identifiers sequentially, but any scheme is
   acceptable provided that
   SWID-PV did not send no two records receive the given SWID Request.  As such, there same identifier.

   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 no
   blanket requirement for associated
   with a SWID-PV to discard all SWID Responses to
   SWID Request separate record, servers can use the SWID-PV did not generate itself, only that SWID-PVs
   are required record identifier to discard SWID Responses for which they cannot get
   distinguish between instances.  For example, if an event is reported
   (as described in Section 3.5), the
   necessary context to interpret.

   In record identifier will allow the case that it
   server to discern which instance of a software product is possible involved.

3.2.2.  Using Software and Record Identifiers in SW Attributes

   A SW Attribute reporting an endpoint's Software Inventory Evidence
   Collection can contain Software Identifiers instead of copies of
   software inventory evidence records.  The message exchange is
   identical to do so, the SWID-PC MAY send its
   SWID diagram shown in Figure 2, but the contents of the
   SW Response are Software Identifiers instead of evidence records.
   The SW Request attribute indicates whether the response is required
   to use full records or Software Identifiers.  Using Software
   Identifiers can reduce the SWID-PV that requested it using
   exclusive delivery as described in section 4.5 attribute size of RFC 5793 (PB-TNC)
   [RFC5793].  Exclusive delivery ensures that only the sender response by multiple
   orders of magnitude when compared to sending the
   SWID same inventory using
   full records.  A SW-PC responds to a SW Request receives attribute requesting
   Software Identifiers the resulting SWID Response.  However, SWID
   Message and Attributes same way it responds to a request for PA-TNC does not require support full
   software records, except that instead of copying each record entirely
   into the attribute body of the response, it provides the specific
   values that comprise a Software Identifier for
   exclusive delivery each record.

   All SW Response attributes include Record Identifiers for each
   reported record.  This is true regardless of attributes. whether the record is
   delivered in full or represented by a Software Identifier.

3.3.  SWID Tag Identifiers

   SWID tags can contain  Targeted Requests

   Sometimes a great deal of SW-PV does not require information about a software
   product.  In addition to identifying name, manufacturer, and version every piece of a
   software product, SWID tags might contain references to related
   products, associated files and libraries, dependencies on other
   software, and many other details.  Moreover, SWID tags might be
   customized on the an endpoint but only needs to indicate when the SWID tag was last
   checked for accuracy relative receive updates about
   certain software instances.  For example, enterprise endpoints might
   be required to the endpoint's installed have certain software products installed and other information about how the software was received.  (This
   document refers to this customized information as
   "installationspecific" tag information.)  For this reason, actual
   possession keep
   these updated.  Instead of requesting a SWID tag complete inventory just to
   see if these products are present, the SW-PV can be useful make a "targeted
   request" for reasoning about details of
   an endpoint's the software inventory.  However, a SWID tag file that
   contains all optional fields might be tens of KB in size.  This means
   that an endpoint's full SWID inventory, encompassing hundreds of
   applications, can be quite large.

   If bandwidth is a concern within an enterprise, there is a way to
   identify a SWID tag without needing question.

   Targeted requests follow the complete tag.  All tags same message exchange described in
   Figure 2.  The SW-PV targets its request by providing one or more
   Software Identifiers in its SW Request attribute.  The SW-PC MUST
   then limit its response to contain specific fields only records that can be used match the
   indicated Software Identifier(s).  This allows the network exchange
   to distinguish a tag for a
   particular piece of software from tags for different pieces of
   software.  The Tag Creator RegID exclude information that is not relevant to a string that uniquely identifies
   the creator of this SWID tag (who given policy
   question, thus reducing unnecessary bandwidth consumption.  The SW-
   PC's response might consist of full records or might not be the same as
   the entity who created of Software
   Identifiers, depending on the described software) while parameters of the Unique ID is
   a string SW Request.

   Note that uniquely identifies targeted requests identify the described piece of software
   according relevant to that tag creator.  These two pieces the
   request only through Software Identifiers.  This specification does
   not support arbitrary, parameterized querying of information
   together create records.  For
   example, one cannot request all records from a "tag identifier".

3.3.1.  Tag Identifier Data

   Some attributes defined in this specification contain fields certain software
   publisher, or all records created by a particular record source.
   Targeted requests only allow a requestor to hold
   tag identifiers rather than whole tags.  When populating these
   fields, both the Tag Creator RegID and the Unique ID values MUST be
   copies of the values of fields within the SWID tag that is being
   identified.  The request specific fields of software
   (as identified by their Software Identifiers) and receive a SWID tag response
   that correspond is limited to the
   Tag Creator RegID and Unique ID values vary between the different
   releases of the ISO SWID tag specification.  It named software.

   There is important to note
   that, in all other parts of this specification, no assumption that a SW-PC will recognize "synonymous
   records" - that is, records from different sources for the terms Tag Creator
   RegID same
   software.  Recall that different sources and Unique ID refer to the general field values defined above
   rather to any term used in any specific release of the ISO SWID tag
   specification.

   To identify the SWID tag field corresponding to data models may use
   different Software Identifier strings for the Tag Creator
   RegID, identify same software product.
   The SW-PC returns only records that match the field containing Software Identifiers in
   the regid value of SW Request, even if there might be other records in the entity
   that created
   endpoint's Software Inventory Evidence Collection for the given SWID tag.  Note that this same
   software product.  This is necessary because SW-PCs might not be have
   the
   same entity ability to determine that created two Software Identifiers refer to the software.
   same product.

   Targeted requests do not include Record Identifiers.  The Tag Creator RegID response to
   a targeted request MUST be
   the regid, rather than any prose name that might be include all records associated with the tag creator.  The specific structure of a regid is defined in the
   ISO/IEC SWID specification.

   To identify the SWID tag field corresponding to the Unique ID, find named
   Software Identifiers, including the field that contains a string that uniquely identifies a specific
   product, version, edition, revision, etc. of a piece of software.
   Note that this is case where there are multiple
   records associated with a single field within the SWID tag, rather than a
   concatenation Software Identifier.

   SW-PCs MUST accept targeted requests and process them correctly as
   described above.  SW-PVs MUST be capable of multiple fields.  In particular, SWID tags often
   contain designated fields for just making targeted requests
   and processing the product name, product version,
   product edition, etc., but these fields are responses thereto.

3.4.  Monitoring Changes in an Endpoint's Software Inventory Evidence
      Collection

   The software collection on an endpoint is not used to populate static.  As software is
   installed, uninstalled, patched, or updated, the
   Unique ID.  Instead, look for a single field that Software Inventory
   Evidence Collection is designed expected to
   uniquely identify a specific software product, version, etc. (and
   thus uniquely identifies a specific tag, at least according change to reflect the
   tag's creator).

   Consult the ISO/IEC specification for the specific fields that
   correspond to new software
   state on the requirements of endpoint.  Different record sources might update the Tag Creator RegID and Unique
   ID, as defined above.
   evidence collection at different rates.  For example, a package
   manager might update its records in the 2009 version 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 ISO/
   IEC SWID specification [SWID], endpoint would likely only update their records in
   the Tag Creator RegID corresponds Software Inventory Evidence Collection after each examination.

   All SW-PCs MUST be able to be able to detect changes to the value Software
   Inventory Evidence Collection.  Specifically, SW-PCs MUST be able to
   detect:

   o  The creation of the software_identification_tag/software_id/
   tag_creator_regid field in a SWID tag. records

   o  The Unique ID corresponds to deletion of records

   o  The alteration of records
   An "alteration" is anything that modifies the value contents of a record
   (or would modify it, if the software_identification_tag/software_id/unique_id
   field record is dynamically generated on
   demand) in a SWID tag.  In subsequent releases any way, regardless of whether the ISO/IEC SWID
   specification, different fields might be used to convey change is functionally
   meaningful.

   SW-PCs MUST detect such changes to the same
   information.

3.3.2.  Tag Identifier Instances

   A tag identifier endpoint's Software Inventory
   Evidence Collection in close to real-time (i.e., within seconds) when
   the combination of the Tag Creator RegID and Posture Collector is operating.  In addition, in the Unique ID fields) uniquely identifies case where
   there is a particular SWID tag, period during which corresponds the SW-PC is not operating, the SW-PC
   MUST be able to a single software product.  Assuming that this
   product manages its own SWID tag (i.e., creates determine the tag on
   installation and deletes net change to the tag when endpoint's Software
   Inventory Evidence Collection over the product is uninstalled)
   then every system with an instance of this software product installed
   would also have a copy of this same SWID tag file with period it was not operational.
   Specifically, the same tag
   identifier field values.  (Presence of SWID tags managed by other
   tools, such as discovery tools, would also depend on "net change" represents the presence difference between the
   state of
   those tools on the device.)  In fact, if multiple instances endpoint's Software Inventory Evidence Collection when
   the SW-PC was last operational and monitoring its state, and the
   state of the
   same endpoint's software product are installed on a single device (i.e., it has
   been installed twice in different locations) inventory evidence collection when
   the SW-PC resumed operation.  Note that device would have
   two instances of a net change might not
   reflect the same SWID tag, one for each installation.  Both
   instances total number of change events over this interval.  For
   example, if a record was altered three times during a period when the SWID tag would have
   SW-PC was unable to monitor for changes, the same tag identifier field
   values.  This is true even though the tags themselves net change of this
   interval might differ
   with regard only note that there was an alteration to their installation-specific tag fields.  In the record,
   but not how many cases
   it individual alteration events occurred.  It is important to distinguish between instances of
   sufficient for a particular tag
   on SW-PC's determination of a particular endpoint.  For example, if one is alerted net change to the
   deletion of note that
   there was a particular SWID tag difference between the earlier and there are multiple instances of current state rather
   than enumerating all the individual events that SWID tag on allowed the endpoint, one will likely wish current
   state to know which
   instance was deleted.

   Individual instances of SWID tags are distinguished by providing an
   "Instance ID" value along with the tag identifier.  An Instance ID is
   a string that is uniquely associated with a particular instance of a
   SWID tag on a particular endpoint. be reached.

   The exact nature of the Instance
   ID depends on the source of SW-PC MUST assign a time to each detected change in the SWID tag.  If
   endpoint's Software Inventory Evidence Collection.  These timestamps
   correspond to the SWID tag is
   represented SW-PC's best understanding as a file on disk, to when the Instance ID might detected
   change occurred.  These timestamps MUST be as accurate as possible.
   For changes to the full path
   of endpoint's Software Inventory Evidence Collection
   that occur while the SWID tag file, including SW-PC is operating, the name of SW-PC ought to be able
   to assign a time to the SWID tag file itself.
   (Note event that is accurate to within a few
   seconds.  For changes to the SWID tag filename MUST be included in endpoint's Software Inventory Evidence
   Collection that occur while the tag file
   path because it SW-PC is possible for two SWID tags, each for different
   instances of not operational, upon
   becoming operational the same software product, SW-PC needs to make a best guess as to co-exist in the same
   directory under different file names.)
   time of the relevant events (possibly by looking at timestamps on
   files), but these values might be off.  In the case that the SWID tag
   is of dynamically
   generated upon request by some source, such as an RPM
   or YUM package manager, records, the generation process MUST create an
   Instance ID to distinguish instances of a particular tag.  Inclusion time of this Instance ID ensures each tag change is uniquely identified on a
   given endpoint.

   To the extent that it is possible, time at which the generation of Instance IDs
   SHOULD be repeatable for a single installation of a single SWID tag.

   In data
   from which the case where a product is installed once, and then SWID tags records are
   generated upon request, each time generate changes, not the SWID tag time at which a
   changed record is generated the tag
   identifier instance SHOULD all have the same Instance ID value. generated.  For example, if a package manager generates a SWID tag in response to a
   request records are dynamically
   generated based on some record it possesses, and then later generates data in an RPM database, the SWID tag again based on time of change would
   be when the same RPM record was changed.

   With regard to deletions of package installation,
   then records, the same Instance ID value SHOULD be created both times.  This
   is necessary to allow remote parties SW-PC needs to understand whether a reported
   SWID tag instance is for detect the same product installation they saw
   reported earlier or if it represents
   deletion and MUST retain a new installation copy of the same
   product.  Note, however, that some exceptional situations might
   result in full deleted record along with
   its Record Identifier so that the record itself can be provided to
   the changing SW-PV upon request.  This copy of a product's Instance ID.  For example, it
   is not explicitly prohibited by the SWID specification record MUST be retained for tags to
   move after installation,
   a reasonable amount of time.  Vendors and thus have their tag file path change.
   If administrators determine
   what "reasonable" means, but a copy of the file path was used record SHOULD be retained
   for as long as the tag's Instance ID, subsequent tag
   identifier instances for that same product might appear to be
   different.  Implementers and users need to be aware event recording the deletion of the record remains
   in the SW-PC's event log (as described in Section 3.5).  This is
   recommended because, as long as the event is in the SW-PC's change
   logs, the SW-PC might send an event attribute (described in
   Section 3.5) that references this
   possibility.

   The combination of record, and a tag identifier with an Instance ID copy of the record is referred
   to as
   needed if the SW-PV wanted a "tag identifier instance".  A tag identifier instance
   uniquely identifies full copy of the relevant records.

   With regard to alterations to a particular instance record, SW-PCs MUST detect any
   alterations to the contents of a particular tag 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
   given endpoint.  Note record that two endpoints might produce identical tag
   identifier instances, but these do not mean that change
   the tag files value of a hash taken on the
   two endpoints are identical - record's contents needs to be
   detected by the tags in question indicate SW-PC.  A SW-PC might be unable to distinguish
   modifications to the same
   software product on both endpoints (since content of a record from modifications to the respective tag
   identifiers are identical), but
   metadata the tags file system associates with the record.  For example, a
   SW-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
   contents.  A SW-PC is still differ in their
   installation-specific fields.  Therefore, considered compliant with this
   specification if it is important to remember also reports metadata change events that tag identifier instances do not
   change the record itself as alterations to the record.  In other
   words, while SW-PC authors are only comparable in encouraged to exclude modifications
   that do not affect the scope of a
   single endpoint; when comparing across different endpoints, only bytes within the
   tag identifier fields (Tag Create RegID record, discriminating
   between modifications to file contents and Unique ID) can be
   meaningfully compared - any Instance ID value will need changes to file metadata
   can be
   excluded from comparison.

3.3.3.  Comparing Tag Identifiers difficult and Tag Identifier Instances

   Comparison time consuming on some systems.  As such, as
   long as the alterations detected by a SW-PC always cover all
   modifications to the contents of tag identifiers can be used record, the SW-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 determine whether a
   particular SWID tag
   record, the SW-PC is present in only required to note that an endpoint's SWID tag collection.
   A pair of SWID tag identifiers alteration
   occurred.  The SW-PC is said not required to "match" if their Tag
   Creator RegID and Unique ID fields are identical.  Similarly, a pair
   of tag identifier instances note or record how the record
   altered, nor is said it possible to match if their Tag Creator
   RegID, Unique ID, and Instance ID fields are identical.  Fields include such details in
   SWID Message and SW Attributes for PA-TNC attributes that contain tag
   identifiers or tag identifier instances MUST always be normalized to
   Network Unicode, so comparison between values transported in
   attributes can be a simple string comparison.  When comparing tag
   identifiers and tag identifier instances from attributes with
   reporting the
   corresponding values from other sources (such as when comparing them change to a full SWID tag file or similar record), the relevant fields from SW-PV.

3.5.  Reporting Change Events

   As noted in the latter need preceding section, SW-PCs MUST be able to undergo normalization prior detect
   changes to comparison.  See
   Section 4.7 for more on normalization of the encoding for these
   fields.  Comparisons are case-sensitive.

   Matching tag identifiers endpoints software inventory evidence collection
   (creation, deletion, and tag identifier instances indicate very
   specific things about alteration) in near real-time while the respective tags.  The following sections
   describe what one can SW-
   PC is operational, and cannot deduce based on matching tag
   identifiers.

3.3.3.1.  Matching Tag Identifiers Indicate MUST be able to account for any net change to
   the Same endpoint's Software Product

   The Unique ID value of a tag identifier represents a value Inventory Evidence Collection that occurs
   when the
   given tag creator will only use SW-PC is not operational.  However, to indicate a particular software
   product (e.g., a particular release be of a particular application).
   The ISO SWID specification prohibits the tag creator from associating
   a Unique ID value with multiple, different software products.  At use to the
   same time,
   enterprise, the Tag Creator RegID element value uniquely identifies a
   given tag creator.  As such, even if two different tag creators were NEA Server needs to assign the same Unique ID value be able to two different software
   products, the Tag Creator RegID values will receive these events
   and be different, able to understand how new changes relate to earlier changes.
   In Software Message and
   therefore the tag identifiers will Attributes for PA-TNC, this is facilitated by
   reporting change events.  All SW-PCs MUST be different.  For these reasons, capable of receiving
   requests for change events and sending change event attributes.  All
   SW-PVs MUST be capable of requesting and receiving change event
   attributes.

3.5.1.  Change Event Records

   A change event record consists of either a complete record or
   Software Identifier from the expectation is that if one sees two tags changed record along with the same tag
   identifiers, these tags are both associated with following
   pieces of information:

   o  The nature of the same software
   product (assuming change (i.e., creation, deletion, or lteration)

   o  An Event Identifier (EID) value

   o  An EID Epoch value

   An EID is a 4-byte unsigned integer that the tag's fields are correctly populated).

3.3.3.2.  Matching Tag Identifiers DO NOT Necessarily Indicate Identical
          Tag Files

   Some optional fields SW-PC assigns
   sequentially to each observed event (whether detected in SWID tags can reflect installation-specific
   information.  As such, the SWID tags real-time or
   deduced by looking for net changes over a piece period of software residing
   on two different endpoints (or installed twice on SW-PC
   inactivity).  All EIDs exist within the context of some "EID Epoch",
   which is also represented as a single endpoint)
   will have 4-byte unsigned integer.  EID Epochs
   are used to ensure synchronization between the same tag identifier value (same tag creator SW-PC and any SW-PVs
   with which it communicates.  EID Epoch values SHOULD be generated
   randomly and in such a way that it is unlikely that the same Unique ID for EID
   Epoch is generated twice, even if the same software product) but might contain
   different information in their installation-specific fields.  For
   this reason, one cannot assume that just because two endpoints
   provide the same tag identifier value for their software inventories,
   that SW-PC reverted to an earlier
   state (e.g., resetting it to factory defaults).  In the tags on those endpoints are identical in case where a
   SW-PC needs to reset its EID counter, either because it has exhausted
   all their fields
   (although one can deduce that the same software product was present
   on both endpoints).

   Informative note: Initial drafts of the revised ISO SWID
   specification indicate that modification of SWID tags might no longer
   be permitted by parties other than the original tag creator (usually
   the vendor of the software identified by available EID values or because the tag).  If this SW-PC's event log becomes
   part of the revised SWID specification,
   corrupted, then for SWID tags that
   conform to this revised specification, this will mean that matching
   tag identifiers do imply identical tag files.

3.3.3.3.  Matching Tag Identifier Instances MIGHT Indicate Identical Tag
          Files

   For a single endpoint, matching tag identifier instance values might
   indicate identical tag files, at least within a narrow time window.
   Tag identifier instance values are unique to a specific SWID tag
   record on new EID Epoch MUST be selected.

   Within an Epoch, EIDs MUST be assigned sequentially, so that particular endpoint at if a
   particular point in time.
   The Instance ID in event is assigned an EID of N, the tag identifier instance information ought to
   be unique relative to any other instances next observed event is
   given an EID of N+1.  In some cases, events might occur
   simultaneously, or the same SWID tag
   currently also on that endpoint.  However, tag identifier instances
   are still SW-PC might not guaranteed to otherwise be unique able to a single SWID tag file over
   a long period of time.  Consider a piece determine
   an ordering for events.  In these cases, the SW-PC creates an
   arbitrary ordering of software that is
   installed (adding a SWID tag), uninstalled (removing the SWID tag), events and then reinstalled (adding that SWID tag back but with a different
   installation-specific field values).  It is possible that the two
   SWID tag files, present at different points in time, might have
   identical tag identifier instance values even though assigns EIDs according to this
   ordering.  Two change events MUST NOT ever be assigned the tag files
   themselves were different.

   As noted above, SWID tag identifier instances are only comparable same EID
   within the context of a single endpoint.  When SWID tag identifier
   instances are collected from multiple endpoints and then compared,
   the Instance ID MUST be ignored in any same EID Epoch.  No meaningful comparison can be made
   between EID values of tag identifiers
   from different endpoints.

3.3.3.4.  Differing Tag Identifiers DO Epochs.

   The EID value of 0 is reserved and MUST NOT Necessarily Indicate
          Different Software Products

   While a tag identifier uniquely identifies a software product (i.e.,
   that tag identifier cannot be associated with any
   event.  Specifically, an EID of 0 in a different software
   product), SW Request attribute indicates
   that a single product might have more SW-PV wants an inventory response rather than one tag identifier.
   This is because it an event
   response, while an EID of 0 in a SW Response is possible for more than one tag creator used to
   create a SWID tag for indicate the same software product.  Multiple tags for
   initial state of the same software product but created by different tag creators will
   have different Tag Creator RegID values and will also likely differ
   in their Unique ID value.  Thus, these two tags will have different
   tag identifiers even though they were associated with endpoint's Software Inventory Evidence
   Collection prior to the same
   software product.  In fact, in some circumstances, two parties might
   create two different SWID tag records for a single instance observation of any events.  Thus the
   same software product.  For example, when very
   first recorded event in a product is installed, it
   creates SW-PC's records within an EID Epoch MUST be
   assigned a SWID tag file on value of 1 or greater.  Note that EID and EID Epoch values
   are assigned by the file system, SW-PC without regard to whether events are being
   reported to one or more SW-PVs.  The SW-PC records events and a software discovery
   tool also notes assigns
   EIDs during its operation.  Any and all SW-PVs that request event
   information from the installation of SW-PC will have those requests served from the product
   same event records and generates its own
   SWID tag record for thus will see the same installation.  In this case, that single
   installation is associated with two SWID tags with different SWID tag
   identifiers.  In short, identical tag identifiers always indicate EIDs and EID Epochs for
   the same software product, but different tag identifiers do not
   necessarily indicate different software products.

3.3.4.  Using Tag Identifiers in SWID Attributes

   A SWID attribute reporting an endpoint's SWID tag collection can
   contain SWID tag identifier instances instead of copies of SWID tag
   files. events.

   The message exchange SW-PC MUST ensure there is identical to the diagram shown no coverage gap (i.e., change events
   that are not recorded in
   Figure 2, but the contents SW-PC's records) in its change event
   records.  This is necessary because a coverage gap might give a SW-PV
   a false impression of the SWID Response are SWID tag
   identifier instances instead of tags.  The SWID Request attribute
   indicates whether the response is required to use full tags or tag
   identifier instances.  Using tag identifier instances can reduce the
   attribute size of the response by multiple orders of magnitude when
   compared endpoint's state.  For example, if a SW-PV
   saw an event indicating that a particular record had been added to sending
   the same endpoint's software inventory using full tags.  A SWID-PC
   responds to a SWID Request attribute requesting SWID tag identifier
   instances the same way it responds to a request for full SWID tags,
   except evidence collection, and saw no
   subsequent events indicating that instead of copying each SWID tag entirely into the
   attribute body of the response, record had been deleted, it provides the specific values that
   comprise a SWID tag identifier instance for each tag.

3.4.  Targeted Requests

   Sometimes a SWID-PV does not require information about every tag on
   an endpoint but only needs to know about certain tags.  For example,
   an endpoint might be required to have a particular patch installed.
   In determining compliance with
   reasonably assume that this policy, record was still present and thus that
   the indicated software was still installed (assuming the SWID-PV Epoch has
   not changed).  If there is only
   interested a coverage gap in the specific SWID tag associated with SW-PC's event
   records, however, this patch.
   Instead of requesting a complete inventory just to see if the patch's
   SWID tag assumption is present, false.  For this reason, the SWID-PV can make a "targeted request" for SW-
   PC's event records MUST NOT contain gaps.  In the tag in question.

   Targeted requests follow case where there
   are periods where it is possible that changes occurred without the same message exchange described in
   Figure 2.  The SWID-PV targets its request by providing one
   SW-PC detecting or more
   SWID tag identifiers in its SWID Request attribute.  The SWID-PC recording them, the SW-PC MUST
   then limit either compute a
   net change and update its response event records appropriately, or pick a new
   EID Epoch to contain only tags that match the indicated
   tag identifier(s).  This allows the network exchange indicate a discontinuity with previous event records.

   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 exclude
   information an event, that is not relevant EID cannot be reassigned to
   a given policy question, thus
   reducing unnecessary bandwidth consumption.  The SWID-PC's response
   might consist of full tags or of tag identifier instances, depending
   on the parameters of different event, and the SWID Request.

   Targeted requests event cannot target specific SWID tag instances; be assigned a different EID.
   When the SWID
   Request does not include fields SW-PC's Epoch changes, all of these associations between
   EIDs and events are cancelled, and EID values once again become free
   for Instance IDs.  As a result, when
   responding assignment.

3.5.2.  Updating Inventory Knowledge Based on Events

   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 targeted request, a SWID-PC MUST return applicable
   results for every instance complete list of the identified tags.

   Note that targeted requests identify the SWID tags relevant an endpoint's
   inventory on a regular basis, one might wish to the
   request only through SWID tag identifiers for those tags.  This
   specification does not support arbitrary, parameterized querying identify changes
   since some earlier known state of
   tags.  For example, one cannot request all tags from a certain
   software publisher, or all tags created this inventory.  This is readily
   facilitated by the use of EIDs to place change events in a particular tag creator.

   Targeted requests only allow context
   relative to earlier state.

   Every inventory sent by a requestor SW-PC to request specific tags a SW-PV (as
   identified by their tag identifiers) described in
   Section 3.1 through Section 3.3) includes the EID Epoch and receive a response EID of
   the last event recorded prior to that is
   limited inventory being compiled.  This
   allows the SW-PV to place all subsequently received event records in
   context relative to this inventory (since the named tags.  There is also no assumption that EIDs represent a SWID-
   PC will recognize "synonymous tags" - that is, tags by different tag
   creators for total
   ordering of all changes to the same endpoint's software product.  The SWID-PC returns only
   tags inventory evidence
   collection).  Specifically, a SW-PV (or, more likely, a database that match
   collects and records its findings) can record an endpoint's full
   inventory and also the tag identifiers in EID and Epoch of the SWID Request, even if
   there might be other SWID tags most recent event
   reflected in that state.  From that point on, if change events are
   observed, the endpoint's SWID tag collection
   for attribute describing these events indicates the same software product.

   SWID-PCs MUST accept targeted requests and process them correctly as
   described above.  SWID-PVs MUST be capable nature
   of making targeted
   requests the change, the affected records, and processing the responses thereto.

3.5.  Monitoring Changes order in an Endpoint's SWID Tag Collection

   The SWID collection on an endpoint is not static.  As software is
   installed, uninstalled, patched, or updated, the SWID tag collection
   is expected to change to reflect the new software state on the
   endpoint.  For tags managed which these
   events occurred (as indicated by an application's installer, tag
   changes usually occur at the time sequential EIDs).  Using this
   information, any remote record of installation or update.  For
   tags added by discovery tools, software and package managers, and
   other sources, changes to the endpoint's SWID tag collection occur
   when some process discovers the new or altered software product,
   which typically lags behind the actual installation or update time.

   All SWID-PCs MUST be able to Software Inventory
   Evidence Collection can be able to detect changes to the SWID
   tag repositories on their endpoint.  Specifically, SWID-PCs updated appropriately.

3.5.3.  Using Event Records in SW Attributes

   A SW-PV MUST be able to detect:

   o  The creation request a list of tags

   o  The deletion event records instead of tags

   o an
   inventory.  The alteration of tags

   An "alteration" is anything that modifies message flow in such an exchange looks the contents of a SWID tag
   file (or would modify it, if same as
   the tag file basic flow shown in Figure 2.  The only difference is dynamically generated on
   demand) that, in any way, regardless of whether
   the change is functionally
   meaningful.  Changes MUST be monitored for all utilized sources SW Request attribute, the SW-PV provides an EID other than 0.  (A
   value of
   SWID tags.  This includes, but is not limited to, monitoring sources
   that dynamically generate SWID tags.

   SWID-PCs MUST detect 0 in these fields represents a request for an inventory.)
   When the SW-PC receives such changes to a request, instead of identifying
   records from the endpoint's SWID tag
   collection in close to real-time (i.e., within seconds) when the
   Posture Collector is operating.  In addition, in the case where there
   is a period during which the SWID-PC is not operating, the SWID-PC Software Inventory Evidence Collection,
   it consults its list of detected changes.  The SW-PC MUST be able add an
   event record to determine the net SW Response attribute for each recorded change
   event with an EID greater than or equal to the endpoint's SWID tag
   collection over the period it was not operational.  Specifically, the
   "net change" represents the difference between the state of the
   endpoint's SWID tag collection when the SWID-PC was last operational
   and monitoring its state, and EID in the state SW Request
   attribute (although targeting of requests, as described in the endpoint's SWID tag
   collection when the SWID-PC resumed operation.  Note that a net
   change next
   paragraph, might not reflect the total number limit this list).  A list of change event records MUST only
   contain events over this
   interval.  For example, if a SWID tag file was altered three times
   during a period when with EIDs that all come from the SWID-PC was unable to monitor current Epoch.

   SW-PVs can target requests for changes, event records by including one or more
   Software Identifiers, as described in Section 3.3, in the net change of this interval might only note SW Request
   that there was requests an
   alteration to the file, but not how many individual alteration events
   occurred.  It is sufficient event record list.  A targeted request for a SWID-PC's determination of a net
   change event
   records is used to note indicate that there was a difference between the earlier and
   current state rather than enumerating all the individual only events affecting software that
   allowed
   match the current state provided Software Identifiers are to be reached.

   The SWID-PC MUST assign a time to each detected change returned.
   Specifically, in the
   endpoint's SWID tag collection.  These timestamps correspond to the
   SWID-PC's best understanding as response to when a targeted request for event records,
   the detected change occurred.
   These timestamps SW-PC MUST be as accurate as possible.  For changes to the
   endpoint's SWID tag collection exclude any event records that occur while the SWID-PC is
   operating, are less than the SWID-PC ought to be able to assign a time to
   indicated EID (within the current EID Epoch) and exclude any event
   that is accurate to within a few seconds.  For changes to the
   endpoint's SWID tag collection that occur while
   records where the SWID-PC is affected software does not
   operational, upon becoming operational match one of the SWID-PC needs to make a
   best guess as to
   provided Software Identifiers.  This might mean that the time resulting
   list of event records sent in the relevant response attribute does not provide
   a continuous sequence of EIDs.  Both SW-PCs and SWIC-PVs MUST support
   targeted request for event records.

3.5.4.  Partial and Complete Lists of Event Records in SW Attributes

   Over time, a SW-PC might record a large number of change events.  If
   a SW-PV requests all change events (possibly by looking
   at timestamps on covering a large period of time,
   the files), but these values resulting SW Response attribute might be off.  In extremely large,
   especially if the
   case SW-PV is requesting the use of full records instead
   of dynamically generated SWID tags, the time use of change is Software Identifiers (as described in Section 3.2.2).
   In the
   time at which case that the data from which resulting attribute is too large to send (either
   because it exceeds the SWID tags are generate changes,
   not 4GB attribute size limit imposed by the time at which a changed SWID tag is generated.  For example,
   if SWID tags are dynamically generated based PA-TNC
   specification, or because it exceeds some smaller size limit imposed
   on data in an RPM
   database, the time of change would be when SW-PC) the RPM record was
   changed.

   With regard to deletions SW-PC MAY send a partial list of SWID tags, the SWID-PC needs event records back
   to detect the deletion and MUST retain SW-PV.

   Generation of a copy partial list of events in a SW Response attribute
   requires the full deleted tag so that
   the tag itself can be provided SW-PC to identify a "consulted range" of EIDs.  A
   consulted range is the SWID-PV upon request.  This
   copy set of event records that are examined for
   inclusion in the SWID tag MUST SW Response attribute and that are included in that
   attribute if applicable.  Recall that, if a SW Request is targeted,
   only event records that involve the indicated software would be retained
   applicable.  (See Section 3.3 for more on Targeted Request.)  If a reasonable amount of
   time.  Vendors
   request is not targeted, all event records in the considered range
   are applicable and administrators determine what "reasonable" means,
   but a copy included in the SW Response attribute.

   The lower bound of the tag SHOULD consulted range MUST be retained for as long as the EID provided in
   the SW Request.  (Recall that a SW Request indicates a request for
   event
   recording records by providing a non-0 EID value in the deletion SW Request.  See
   Section 3.5.3.)  The upper bound of the tag remains in the SWID-PC's records.
   This consulted range is recommended because, as long as the EID of
   the latest event record (as ordered by EID values) that is included
   in the SWID-PC's
   records, the SWID-PC might send an event SW Response attribute (described in
   Section 3.6) that references this tag, and a copy of the tag is
   needed if the SWID-PV wanted a full copy of the relevant tags.

   With regard to alterations to a SWID tag file, SWID-PCs MUST detect
   any alterations it is applicable to the contents request.  The
   EID of a tag file.  Alterations need to
   be detected even if they have no functional impact on the tag file.
   For example, this last event record is called the addition of whitespace between XML attributes does
   not have any impact "Last Consulted EID".
   The SW-PC chooses this Last Consulted EID based on the meaning size of the SWID tag file, but still
   needs to be detected as a tag file alteration by a SWID-PC.  A good
   guideline
   event record list it is that any alteration willing to a file that might change the
   value of a hash taken on the file's contents needs provide to be detected by the SWID-PC. SW-PV.

   A SWID-PC might be unable to distinguish modifications
   to the content of a tag file from modifications to the metadata the
   file system associates with the tag file.  For example, a SWID-PC
   might use partial result list MUST include all applicable event records
   within the "last modification" timestamp as consulted range.  This means that for any applicable event
   record (i.e., any event record in an indication of
   alteration to un-targeted request, or an event
   record associated with software matching a given tag file, but requested Software
   Identifier in a file's last modification time
   can change for reasons other targeted request) whose EID is greater than modifications or equal
   to the file contents.
   A SWID-PC EID provided in the SW Request and whose EID is still considered compliant with this specification if it
   also reports metadata change events that do not change the SWID tag
   file itself as alterations less than or
   equal to the SWID tag file.  In other words,
   while SWID-PC authors are encouraged to exclude modifications Last Consulted EID, that do
   not affect the bytes within the tag file when detecting alterations
   to a SWID tag record, discriminating between modifications to file
   contents and changes to file metadata can event record MUST be difficult and time
   consuming on some systems.  As such, as long as the alterations
   detected by a SWID-PC always cover all modifications to included
   in the contents SW Response conveying this partial list of tag files, the SWID-PC event records.
   This ensures that every partial list of event records is considered compliant even if it also
   registers alterations always
   complete within its indicated range.

   All SW Response attributes that do not modify convey event records (either using
   full records or using Software Identifiers) include an Epoch, Last
   EID, and Last Consulted EID field.  The Last EID contains the contents EID of a tag file
   as well.  When recording an alteration to a tag file,
   the SWID-PC is
   only required last event record known to note the SW-PC at the time that an alteration occurred. the SW
   Response attribute was generated.  The SWID-PC is
   not required to note Last EID might or record how the tag file altered, nor is it
   possible to include such details in SWID Attributes reporting might not be
   part of the
   change to a SWID-PV.

3.6.  Reporting Change Events consulted range.  As noted in above, the preceding section, SWID-PCs MUST be able to detect
   changes to Last Consulted EID
   field contains the SWID tag repositories (tag creation, tag removal, and
   tag alteration) EID of the last event record in near real-time while the SWID-PC is operational, consulted
   range.  The Epoch field contains the EID Epoch associated with the
   Last EID and MUST be able to account for any net change to Last Consulted EID fields as well as all the endpoint's SWID
   tag collection that occurs when EIDs in
   event records contained within the SWID-PC is not operational.
   However, to be of use SW Response attribute.  Note that,
   if responding to a targeted SW Request, the enterprise, SW Response attribute
   might not contain the NEA Server needs to be
   able to receive these events and be able to understand how new
   changes relate to earlier changes.  In SWID Message and Attributes
   for PA-TNC, this is facilitated by reporting change events.  All
   SWID-PCs MUST be capable of receiving requests for change events and
   sending change event attributes.  All SWID-PVs MUST be capable of
   requesting and receiving change event attributes.

3.6.1.  Change Event Records

   A change event record consists of either a complete SWID tag or SWID
   tag identifier instance along with whose EID matches the following pieces of
   information:

   o  The nature Last
   Consulted EID value.  For example, the last consulted EID record
   might have been deemed inapplicable because it did not match the
   specified list of Software Identifiers in the change (i.e., tag creation, tag deletion, or tag
      alteration)

   o  An Event Identifier (EID) value

   o  An SW Request.

   If a SW-PV receives a SW Response attribute where the Last EID Epoch value

   An and
   Last Consulted EID is fields are identical, the SW-PV knows that it has
   received a 4-byte unsigned integer result list that is complete, given the SWID-PC assigns
   sequentially to each observed event (whether detected in real-time or
   deduced by looking for net changes over a period parameters of SWID-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
   request, up to ensure synchronization between the SWID-PC present time.  On the other hand, if the Last EID
   and any SWID-
   PVs with which it communicates. Last Consulted EID Epoch values SHOULD be generated
   randomly and in such differ, the SW-PV has received a way that it is unlikely that
   partial result list.  In the same EID
   Epoch is generated twice, even latter case, if the SWID-PC reverted SW-PV wishes to an earlier
   state (e.g., resetting it try
   to factory defaults).  In collect the case where a
   SWID-PC needs to reset its EID counter, either because it has
   exhausted all available EID values or because rest of the SWID-PC's event log
   becomes corrupted, partially delivered result list it then
   sends a new SW Request whose EID Epoch MUST be selected.

   Within an Epoch, EIDs MUST be assigned sequentially, so that if a
   particular event is assigned an one greater than the Last
   Consulted EID of N, in the next observed preceding response.  Doing this causes the SW-PC
   to generate another SW Response attribute containing event records
   where the earliest reported event record is
   given an EID of N+1.  In some cases, events might occur
   simultaneously, or the SWID-PC might not otherwise be able to
   determine an ordering for events.  In these cases, one immediately after
   the SWID-PC
   creates an arbitrary ordering of event record with the events and assigns Last Consulted EID (since EIDs
   according to are assigned
   sequentially).  By repeating this ordering.  Two change events MUST NOT ever be
   assigned the same EID within process until it receives a SW
   Response where the same EID Epoch.  No meaningful
   comparison can be made between EID values of different Epochs.

   The Last EID value of 0 is reserved and MUST NOT be associated with any
   event.  Specifically, an Last Consulted EID are equal, the SW-
   PV is able to collect all event records over a given range, even if
   the complete set of 0 in event records would be too large to deliver via a SWID Request attribute
   indicates
   single attribute.

   Implementers need to be aware that a SWID-PV wants SW Request might specify an inventory response rather EID
   that is greater than an
   event response, while an the EID of 0 the last event recorded by a SW-PC.
   In accordance with the behaviors described in Section 3.5.3, a SWID Response is used SW-PC
   MUST respond to
   indicate the initial state such a request with a SW Response attribute of the endpoint's SWID tag collection
   prior to
   appropriate type (using full records or Software Identifiers as
   specified in the observation of any events.  Thus SW Request) that contains zero event records.  This
   is because the very first SW-PC has recorded no event records with EIDs greater
   than or equal to the EID in the SW Request.  In such a SWID-PC's records within an case, the Last
   Consulted EID Epoch field MUST be assigned a set to the same value of 1 or greater.  Note that as the Last EID and
   field in this SW Response attribute.  This case is called out because
   the consulted range on a SW-PC in such a situation is a negative
   range, where the "first" EID Epoch values are
   assigned by in the SWID-PC without regard to whether events are being
   reported to one or more SWID-PVs.  The SWID-PC records events and
   assigns EIDs during its operation.  Any and all SWID-PVs that request
   event information from range (provided in the SWID-PC will have those requests served
   from SW
   Request) is greater than the same records and thus will see "last" EID in the range (this being the same EIDs and
   EID Epochs
   for of the same events.

   The SWID-PC MUST last recorded event on the SW-PC).  Implementers need to
   ensure there is no coverage gap (i.e., change events that are SW-PCs do not recorded experience problems in such a circumstance.

   Note that this specification only supports the SWID-PC's records) in its records returning of
   change events.  This partial
   results when returning event records.  There is necessary because a coverage gap might give no way to return a
   SWID-PV
   partial inventory list under this specification.

3.5.5.  Synchronizing Event Identifiers and Epochs

   Since EIDs are sequential within an Epoch, if a false impression SW-PV's list of event
   records contains gaps in the endpoint's state.  For example, if EID values within a SWID-PV saw an event indicating single Epoch, the
   SW-PV knows that a particular SWID tag had been
   installed, and saw no subsequent there are events indicating that tag had have not been
   deleted, it might reasonably assume that this tag was still installed
   (assuming accounted for.
   The SW-PV can either request a new event list to collect the Epoch has not changed).  If there is missing
   events or request a coverage gap in full inventory to re-sync its understanding of
   the SWID-PC's records, however, this assumption is false.  For this
   reason, state of the SWID-PC's event records MUST NOT contain gaps. Endpoint's Software Inventory Evidence Collection.
   In either case, after the
   case where there are periods where it is possible that changes
   occurred without SW-PV's record of the SWID-PC detecting or recording them, endpoint's Software
   Inventory Evidence Collection has been updated, the SWID-PC
   MUST either compute a net change SW-PV can record
   the new latest EID value and update its records
   appropriately, or pick track events normally from that point
   on.

   If the SW-PV receives any attribute from a new SW-PC where the EID Epoch to indicate a discontinuity
   with previous event records.

   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
   differs from the EID is assigned to an event, Epoch that EID cannot be reassigned was used previously, then SW-PV or
   any entity using this information to
   a different event, and track the event cannot be assigned endpoint's Software
   Inventory Evidence Collection knows that there is a different EID.
   When the SWID-PC's Epoch changes, all discontinuity in
   their understanding of these associations between
   EIDs and events are cancelled, the endpoint's state.  To move past this
   discontinuity and EID values once again become free
   for assignment.

3.6.2.  Updating Inventory Knowledge Based on Events

   Modern endpoints can have hundreds reestablish a current understanding of software products installed,
   most the state of which are unlikely
   the endpoint's Software Inventory Evidence Collection, the SW-PV
   needs to change receive a full inventory from one day to the next.  As
   such, instead of exchanging a complete list of an endpoint.  The SW-PV
   cannot be brought in sync with the endpoint's
   inventory on a regular basis, one might wish to only identify changes
   since some earlier known state through the
   collection of any set of event records in this inventory. situation.  This is readily
   facilitated by the use of EIDs
   because it is not possible to place change account for all events in a context
   relative on the SW-PC
   over the interval since the previous Epoch was used, because there is
   no way to earlier state.

   Every inventory sent by query for EIDs from a SWID-PC to previous Epoch.  Once the SW-PV has
   received a SWID-PV (as described in
   Section 3.2 through Section 3.4) includes full inventory for the new Epoch, the SW-PV records the
   latest EID reported in this new Epoch and EID of can track further events
   normally.

   A SW-PC MUST NOT report events with EIDs from any Epoch other than
   the last event recorded prior current EID Epoch.  The SW-PC MAY choose to that inventory being compiled.  This
   allows purge all event
   records from a previous Epoch from memory after an Epoch change.
   Alternately, the SWID-PV SW-PC MAY choose to place all subsequently received retain some event records from a
   previous EID Epoch and assign them new EIDs in context relative to this inventory (since the EIDs represent a
   total ordering of all changes to current Epoch.
   However, in the endpoint's SWID tag collection).
   Specifically, a SWID-PV (or, more likely, case where a database SW-PC chooses the latter option it MUST
   ensure that collects
   and records its findings) can record an endpoint's full inventory the order of events according to their EIDs is unchanged
   and
   also 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 Epoch of the most recent first event reflected in that
   state.  From recorded during the current Epoch.
   In particular, the SW-PC MUST ensure that point on, if all change events are observed, the
   attribute describing these events indicates that
   occurred after the nature of the change, last recorded event from the affected SWID tags, previous Epoch are
   known and recorded.  (This might not be possible if the order Epoch change
   is due to state corruption on the SW-PC.)  A SW-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 which these events occurred
   (as indicated by the sequential EIDs).  Using this information, any
   remote record
   window of available events.

   In the endpoint's SWID tag collection can be updated
   appropriately.

3.6.3.  Using Event Records in SWID Attributes

   A SWID-PV MUST be able to request case where a list SW-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 SW-PC MUST purge all event records instead of
   an inventory.  The message flow in such an exchange looks from before the same crash as
   the basic flow shown in Figure 2.  The only difference
   it cannot ensure that there is that, in
   the SWID Request attribute, the SWID-PV provides an EID other than 0.
   (A value of 0 in these fields represents not a request for an inventory.)
   When gap between the SWID-PC receives such a request, instead last of identifying SWID
   tags in those
   records and the endpoint's SWID tag collection, it consults its record of next detected changes. event.  The SWID-PC MUST add an event record to the SWID
   Response attribute process for each recorded change event with an generating a
   new EID greater
   than or equal to Epoch MUST minimize the EID in possibility that the SWID Request attribute (although
   targeting of requests, newly generated
   EID Epoch is the same as described a previously used EID Epoch.

   The SW-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 next paragraph, may limit same EID Epoch.  If this list).  A list occurs, the SW-PC has
   suffered an error of some kind, possibly indicative of at least
   partial corruption of its event records MUST only contain events with
   EIDs that all come from log.  In this case, the current Epoch.

   SWID-PVs can target requests for event records by including one or
   more tag identifiers, SW-PV SHOULD
   treat the situation as described in Section 3.4, if there was a change in Epoch and treat any
   local copy of the SWID
   Request endpoint's Software Inventory Evidence Collection
   as out-of-sync until a full inventory can be reported by the SW-PC.
   In this case, the SW-PV SHOULD flag the occurrence so the SW-PC can
   be examined to ensure it is now operating properly.

3.6.  Subscriptions

   Thus far, all message exchanges discussed assume that requests a SW-PV sent an event record list.  A targeted request for
   event records
   SW Request attribute and the SW-PC is used providing a direct response to indicate
   that only events affecting SWID
   tags that match request.  The Software Message and Attributes for PA-TNC
   specification also supports the provided SWID tag identifiers are ability for a SW-PC to be returned.
   Specifically, send a message
   with a SW Attribute to the SW-PV in response to observed changes in
   the endpoint's software inventory evidence collection, instead of in
   direct response to a targeted request for event records, SW Request.  An agreement by a SW-PC to send
   content when certain changes are detected to the SWID-PC MUST exclude any event records that are less than endpoint's Software
   Inventory Evidence Collection is referred to in this specification as
   a "subscription", and the
   indicated EID (within SW-PV that receives this content is said to
   be "subscribed to" the current EID Epoch) given SW-PC.  All SW-PCs and exclude any event
   records where SW-PVs MUST
   support the affected SWID tag does not match one use of subscriptions.

3.6.1.  Establishing Subscriptions

   A SW-PV establishes a subscription on a particular SW-PC by sending a
   SW Request attribute with the
   provided SWID tag identifiers.  This might mean that Subscription flag set.  The SW Request
   attribute is otherwise identical to the resulting
   list of event records sent SW Requests discussed in the response attribute does not provide
   previous sections.  Specifically, such a continuous sequence of EIDs.  Both SWID-PCs and SWIC-PVs MUST
   support targeted SW Request might request for event records.

3.6.4.  Partial
   full records or Software Identifiers, might be targeted, and Complete Lists of Event Records in SWID Attributes

   Over time, a SWID-PC might record a large number of
   request change events.
   If event records or endpoint inventory.  Assuming no
   error is encountered, a SWID-PV requests all change events covering SW-PC MUST send a large period of
   time, the resulting SWID SW Response attribute might be extremely large,
   especially in
   direct response to this SW Request attribute, just as if the SWID-PV is requesting
   Subscription flag was not set.  As such, the use of full SWID tags
   instead of message exchange that
   establishes a new subscription in a SW-PC has the use of SWID Identifier instances same flow seen in
   the previous message exchanges, as depicted in Figure 2.  If the SW-
   PV does not receive a PA-TNC Error attribute (as described in
   Section 3.3.4).  In 3.8 and Section 4.16) in response to their subscription
   request, the case that subscription has been successfully established on the resulting
   SW-PC.  The SW Request attribute that establishes a new subscription
   is too
   large referred to send (either because it exceeds the 4GB attribute size limit
   imposed by as the PA-TNC specification, or because "establishing request" for that subscription.

   When a subscription is established it exceeds some
   smaller size limit imposed on the SWID-PC) the SWID-PC MAY send is assigned a
   partial list of events back Subscription ID
   value.  The Subscription ID is equal to the SWID-PV.

   Generation value of a partial list the Request ID
   of events in a SWID Response attribute
   requires the SWID-PC establishing request.  (For more about Request IDs, see
   Section 4.8.)

   A SW-PC MUST have the ability to identify record and support multiple
   simultaneous subscriptions from a "consulted range" of EIDs. single party and from multiple
   parties.  A
   consulted range is the set of event records that are examined for
   inclusion in SW-PV MUST have the SWID Response attribute ability to record and that are included in
   that attribute if applicable.  Recall that, if support
   multiple simultaneous subscriptions to a SWID Request is
   targeted, only event records that involve single party and
   subscriptions to multiple parties.

3.6.2.  Managing Subscriptions

   The SW-PC MUST record each accepted subscription along with the indicated SWID tags
   would be applicable.  (See Section 3.4 for more on Targeted Request.)
   If a request is not targeted, all event records in
   identity of the considered
   range party to whom attributes are applicable and included to be pushed in
   compliance with the SWID Response attribute.

   The lower bound of subscription.  This identity includes both the consulted range MUST be
   NEA Server's connection ID and the EID provided in Posture Validator Identifier from
   the SWID Request.  (Recall PB-PA message that a SWID Request indicates a request delivered the request.

   Likewise, SW-PVs MUST record each accepted subscription for event records by providing a non-0 EID value in which
   they are the SWID Request.
   See Section 3.6.3.)  The upper bound of subscribing party along with the consulted range is associated Subscription
   ID and the
   EID identity of the latest event record (as ordered by EID values) SW-PC that is
   included in the SWID Response attribute if it is applicable to will be fulfilling the
   request.
   subscription.  The EID of SW-PV needs to retain this last event record is called information in order to
   correctly interpret pushed SW Response attributes sent in fulfillment
   of the "Last
   Consulted EID". subscription.  The SWID-PC chooses this Last Consulted EID based on
   the size identity of the event record list it SW-PC is willing to provide to given in the
   SWID-PV.

   A partial result list MUST include all applicable event records
   within
   Posture Collector Identifier of the consulted range.  This means PB-PA message header in all
   messages from that for SW-PC.

3.6.3.  Terminating Subscriptions

   Subscriptions MAY be terminated at any applicable event
   record whose EID is greater than or equal to time by the EID provided subscribing SW-PV
   by setting the Clear Subscriptions flag in a SW Request.  (See
   Section 4.9 for more on using this flag.)  In the
   SWID case that a SW
   Request and whose EID with the Clear Subscriptions flag set is less than or equal to received the Last
   Consulted EID, that event record SW-PC
   MUST be included in only clear subscriptions that match both the SWID
   Response conveying NEA server
   connection ID and the SW-PV ID for this partial list of event records. SW Request, and MUST clear
   all such subscriptions.

   This ensures
   that every partial list of event records is always complete within
   its indicated range.

   All SWID Response attributes that convey event records (either using
   full SWID tags or using SWID tag identifier instances) include an
   Epoch, Last EID, and Last Consulted EID field.  The Last EID contains specification does not give the EID of SW-PV the last event record known ability to terminate
   subscriptions individually - all subscriptions to the SWID-PC at the time
   that SW-PV are
   cleared when the SWID Response attribute was generated.  The Last EID might
   or might Clear Subscriptions flag is set.

   This specification does not be part of the consulted range.  As noted above, give the
   Last Consulted EID field contains SW-PC the EID of ability to
   unilaterally terminate a subscription.  However, if the last event record SW-PC
   experiences a fatal error fulfilling a subscription, resulting in
   sending a PA-TNC Error attribute of type
   SW_SUBSCRIPTION_FULFILLMENT_ERROR, then the consulted range.  The Epoch field contains the EID Epoch
   associated with subscription whose
   fulfillment led to the Last EID and Last Consulted EID fields as well error MUST be treated as
   all terminated by both
   the EIDs in event records contained within SW-PC and the SWID Response
   attribute.  Note that, if responding to a targeted SWID Request, SW-PV.  Only the
   SWID Response attribute might not contain subscription experiencing the event record whose EID
   matches
   error is cancelled and other subscriptions are unaffected.  See
   Section 3.8 for more on this error condition.

   Finally, a subscription is terminated if the Last Consulted EID value.  For example, connection between the last
   consulted EID record might have been deemed inapplicable because it
   did not match
   SW-PC and SW-PV is deleted.  This occurs when the specified list of SWID tag identifiers connection ID used
   in the SWID
   Request.

   If a SWID-PV receives a SWID Response attribute where messages between the Last EID SW-PC and Last Consulted EID fields are identical, the SWID-PV knows SW-PV becomes unbound.
   Loss of this connection ID would prevent the SW-PC from sending
   messages in fulfillment of this subscription.  As such, loss of the
   connection ID necessarily forces subscription termination between the
   affected parties.

3.6.4.  Subscription Status

   A SW-PV can request that
   it has received a result SW-PC report the list of active
   subscriptions where the SW-PV is the subscriber.  A SW-PV can use
   this to recover lost information about active subscriptions.  A SW-PV
   can also use this capability to verify that a SW-PC has not forgotten
   any of its subscriptions.  The latter is complete, especially useful where a
   SW-PC does not send any attributes in fulfillment of a given the parameters
   subscription for a long period of the request, up to the present time.  On  The SW-PV can check the other hand, if list
   of active subscriptions on the
   Last EID SW-PC and Last Consulted EID values differ, the SWID-PV has
   received a partial result list.  In the latter case, if verify whether the SWID-PV
   wishes to try
   inactivity is due to collect the rest a lack of reportable events, or due to the partially delivered result SW-PC
   forgetting its obligations to fulfill a given subscription.

   A SW-PV requests a list it of its subscriptions on a given SW-PC by
   sending that SW-PC a Subscription Status Request.  The SW-PC MUST
   then sends respond with a new SWID Request whose EID Subscription Status Response (or a PA-TNC Error
   if an error condition is experienced).  The Subscription Status
   Response MUST contain one greater than subscription record for each of the Last Consulted EID in active
   subscriptions for which the preceding response.  Doing this causes SW-PV is the SWID-PC to generate another SWID Response attribute containing
   event records where the earliest reported event record is subscribing party.

3.6.5.  Fulfilling Subscriptions

   As noted in Section 3.4 SW-PCs MUST have the one
   immediately after ability to automatically
   detect changes to an endpoint's Software Inventory Evidence
   Collection in near real-time.  For every active subscription, the event record with SW-
   PC MUST send an attribute to the Last Consulted EID (since
   EIDs are assigned sequentially).  By repeating this process until it
   receives subscribed SW-PV whenever a SWID Response where the Last EID and Last Consulted EID
   are equal, the SWID-PV change
   is able detected to collect all event relevant records over a
   given range, even if within the complete set of event records would be too
   large to deliver via a single attribute.

   Implementers need to be aware that a SWID Request might specify endpoint's Software
   Inventory Evidence Collection.  Such an
   EID that attribute is greater than said to be sent
   "in fulfillment of" the EID of given subscription and any such attribute
   MUST include that subscription's Subscription ID.  If the last event recorded by
   establishing request for that subscription was a
   SWID-PC.  In accordance with targeted request,
   then only records that match the behaviors described Software Identifiers provided in
   Section 3.6.3, a SWID-PC MUST respond to such a
   that establishing request with are considered relevant.  Otherwise, (i.e.,
   for non-targeted requests) any record is considered relevant for this
   purpose.  Figure 3 shows a SWID
   Response attribute of sample message exchange where a
   subscription is established and then later messages are sent from the appropriate type (using SWID tags or SWID
   tag identifier instances as specified
   SW-PC in fulfillment of the SWID Request) that
   contains zero event records.  This is because the SWID-PC has
   recorded no event records with EIDs greater than or equal to established subscription.

            +-------------+                    +--------------+
            |   SW-PC     |                    |    SW-PV     |  Time
            +-------------+                    +--------------+   |
                  |                                   |           |
                  |<-----------SW Request-------------|           |
                  |                                   |           |
                  |------------SW Response----------->|           |
                  |                                   |           |
                  .                                   .           .
                  .                                   .           .
                  .                                   .           .
    <Change Event>|                                   |           |
                  |------------SW Response----------->|           |
                  |                                   |           |
                  .                                   .           .
                  .                                   .           .
                  .                                   .           .
    <Change Event>|                                   |           |
                  |------------SW Response----------->|           |
                  |                                   |           V

           Figure 3: Subscription Establishment and Fulfillment

   The contents of an attribute sent in fulfillment of a subscription
   depend on the EID parameters provided in the SWID Request.  In such a case, establishing request for
   that subscription.  Specifically, the Last Consulted EID field
   MUST be set to contents of an attribute sent
   in fulfillment of a subscription have the same value format as the Last EID field in this SWID would a
   direct response attribute.  This case is called out because consulted range
   on to the establishing request.  For example, if the
   establishing request stipulated a SWID-PC response that contained an event
   record list wherein affected software indicated using Software
   Identifiers, all attributes sent in such a situation is a negative range, where the
   "first" EID fulfillment of this subscription
   will also consist of event record lists expressed using Software
   Identifiers.  As such, all SW Responses displayed in the range (provided exchange
   depicted in Figure 3 have the SWID Request) is greater
   than the "last" EID same format.  A SW Response generated
   in the range (this being the EID fulfillment of an active subscription MUST be a valid SW Response
   attribute according to all the last
   recorded event on rules outlined in the SWID-PC).  Implementers need 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 ensure an explicit request from a SW-PV that
   SWID-PCs do not experience problems in such had the same
   request parameters and which arrived immediately after the given
   change event.  There are a circumstance.

   Note few special rules that expand on this specification only supports
   guideline:

3.6.5.1.  Subscriptions Reporting Inventories

   In the returning of partial
   results when returning event records.  There is no way case that a SW-PV subscribes to return a
   partial SW-PC requesting an
   inventory list under this specification.

3.6.5.  Synchronizing Event Identifiers and Epochs

   Since EIDs attribute whenever changes are sequential within an Epoch, if a SWID-PV's list of
   event records contains gaps in detected (i.e. the EID values within a single Epoch, in
   the SWID-PV knows that there are events that have not been accounted
   for.  The SWID-PV can either establishing request a new event list to collect is 0), then the
   missing events SW-PC MUST send the
   requested inventory whenever a relevant change is detected.  (A
   "relevant change" is any change for untargeted requests, or request a full inventory change
   to re-sync its
   understanding of the state an indicated record in a targeted request.)  Upon detection of a
   relevant change for an active subscription, the SWID tags on SW-PC sends the endpoint.  In
   either case, after
   appropriate inventory information as if it had just received the SWID-PV's record
   establishing request.  Attributes sent in fulfillment of this
   subscription will probably have a large amount of redundancy, as the endpoint's SWID tag
   collection has been updated, the SWID-PV
   same records the new latest EID
   value and tracks events normally from that point on.

   If the SWID-PV receives any attribute from a SWID-PC where the EID
   Epoch differs from the EID Epoch that was used previously, then SWID-
   PV or any entity using this information are likely to track the endpoint's SWID
   tag collection knows that there is a discontinuity be present in their
   understanding of the endpoint's state.  To move past this
   discontinuity and reestablish a current understanding each of the state these SW Attributes.
   The role of
   the endpoint's SWID tag collection, the SWID-PV needs to receive a
   full an inventory from the endpoint.  This is because it subscription is not possible to account report records just
   for all events on the SWID-PC over the interval since the
   previous Epoch was used, because there items that changed - that is no way to query for EIDs
   from a previous Epoch.  Once the SWID-PV has received role of a full
   inventory for the new Epoch, the SWID-PV records the latest EID
   reported in this new Epoch and can track further subscription that
   reports events normally. (see Section 3.6.5.2).  A SWID-PC SW-PC MUST NOT report events with EIDs exclude a
   record from any Epoch other than an attribute sent in fulfillment of an inventory
   subscription simply because that record was not involved in the current EID Epoch.  The SWID-PC MAY choose to purge all
   triggering event
   records from (although a previous Epoch from memory after an Epoch change.
   Alternately, record might be excluded for other
   reasons, such as if the SWID-PC MAY choose subscription is targeted - see
   Section 3.6.5.3).

3.6.5.2.  Subscriptions Reporting Events

   The way in which a SW-PV indicates it wishes to retain some establish a
   subscription requesting event records from is by providing a previous non-zero EID Epoch and assign them new EIDs in the current Epoch.
   However,
   in the case where a SWID-PC chooses SW Request establishing the latter option it
   MUST ensure that subscription (see Section 3.5.1).
   However, when the order SW-PC constructs an attribute in fulfillment of events according the
   subscription (other than the direct response to their EIDs is
   unchanged and that there is no coverage gap between the first
   retained establishing
   request), it MUST only include event recorded during records for the previous Epoch (now reassigned detected
   change(s) that precipitated this response attribute.  In other words,
   it MUST NOT send a complete list of all changes starting with an EID in the current Epoch) and
   indicated EID, up through the first latest change, every time a new event recorded during
   the current Epoch.
   is detected.  In particular, effect, the SWID-PC MUST ensure that all
   change events EID in the establishing request is
   treated as being updated every time an attribute is sent in
   fulfillment of this subscription, such that occurred after a single event is not
   reported twice in fulfillment of a single subscription.  As such,
   every SW-PC MUST track the EID of the last recorded event from that triggered an
   attribute for the
   previous Epoch are known and recorded.  (This might not be possible
   if given subscription.  When the Epoch change next event (or set of
   events) is due to state corruption on detected, the SWID-PC.)  A
   SWID-PC might choose to reassign SW-PC MUST only report events with EIDs to records from a preceding
   Epoch to create a "sliding window" of events, where each Epoch change
   represents a shift in
   after the window of available events. last reported event.  In the case where a SWID-PC suffers a crash and loses track of its
   current that the EID Epoch or current EID, then it MUST generate a new of the
   SW-PC changes, the SW-PC MUST treat EID values in the new Epoch value and begin assigning as
   being after all EIDs within that Epoch.  In this
   case, assigned in the SWID-PC MUST purge all event records from before previous Epoch regardless of the crash
   as it cannot ensure
   relative numeric values of these EIDs.

   Note that there is not while a gap between the last of those
   records and subscription is active, the next detected event.  The process subscribing SW-PV MAY
   make other requests for generating event records that overlap with events that
   are reported in fulfillment of a
   new EID Epoch MUST minimize subscription.  Such requests are
   unaffected by the possibility that presence of the newly generated
   EID Epoch subscription, nor is the same as
   subscription affected by such requests.  In other words, a previously used EID Epoch.

   The SWID-PV given
   request will normally never receive get the same results back whether or not there was a
   subscription.  Likewise, an attribute indicating that
   the latest EID is less than the latest EID reported sent in fulfillment of a previous
   attribute within
   subscription will contain the same EID Epoch.  If this occurs, the SWID-PC has
   suffered an error of some kind, possibly indicative of at least
   partial corruption of its event log.  In this case, information whether or not other
   requests had been received from the SWID-PV
   SHOULD treat SW-PV.

   A SW-PV needs to pay attention to the situation EID Epoch in these messages, as if there was a change
   changes in the Epoch and
   treat any local copy might create discontinuities in the SW-PV's
   understanding of the endpoint's SWID tag collection Software Inventory Evidence
   Collection state, as out-of-
   sync until discussed in Section 3.5.5.  In particular, once
   the EID Epoch changes, a full inventory can be reported by the SWID-PC.  In this
   case, the SWID-PV SHOULD flag the event so it can be examined to
   ensure it is now operating properly.

3.7.  Supporting Multiple Instances of a Single Tag

   One important consideration SW-PV is unable have confidence that it is possible for multiple
   instances of has
   a SWID tag to be present on an endpoint.  (I.e.,
   multiple SWID tag files whose tag identifiers are correct understanding of the same.)  This
   can happen if there are multiple instances state of an endpoint's Software
   Inventory Evidence Collection until after the indicated software
   product installed SW-PV collects a
   complete inventory.

   SW-PCs MAY send partial lists of event records in fulfillment of a
   subscription.  (See Section 3.5.4 for more on the endpoint. partial list of event
   records.)  In order to account for the
   possibility, all SWID-PCs case that a SW-PC sends a partial list of event
   records, it MUST follow specific rules, outlined below.

3.7.1.  Inventory Reporting in immediately send the next consecutive partial list,
   and continue doing so until it has sent the Presence equivalent of Multiply-Instantiated
        Tags

   When sending an inventory, either full or based on a targeted
   request, the SWID-PC MUST include one entry for each instance
   complete list of event records.  In other words, if the SW-PC sends a
   relevant tag.  (All tags are relevant
   partial list it does not wait for another change event to send
   another SW Response, but continues sending SW Responses until it has
   sent all event records that would have been included in a full inventory.  In a complete
   fulfillment of the subscription.

3.6.5.3.  Targeted Subscriptions

   Subscriptions MAY be targeted request for an inventory, to only tags apply to records that match the tag
   identifiers provided by the SWID-PV are considered relevant.)  For
   example, if a particular piece
   given set of software is installed twice on an
   endpoint, and thus there are two instances of its SWID tag present in
   the endpoint's SWID tag collection, an inventory for which this tag
   is relevant will contain at least two records for this piece of
   software, one for each tag instance.  (It might contain more if
   multiple tag creators each created tags for the same piece of
   installed software.) Software Identifiers.  In the case where the SWID-PC's response is
   expressed using full tags, the response MUST contain one copy of each
   instance of the given tag.  In other words, the SWID-PC MUST send one
   copy of each tag instance, rather than send changes are
   detected that affect multiple copies of one
   tag instance.  In records, some matching the case where establishing
   request's Software Identifiers and some not, the SWID-PC's response is expressed
   using tag identifiers, attribute sent in
   fulfillment of the response subscription MUST only include the tag identifier
   instance inventory or events
   (as appropriate) for each instance of records that match the given tag.

3.7.2.  Event Reporting establishing request's
   Software Identifiers.  The SW-PC MUST NOT include non-matching
   records in the Presence of Multiply Instantiated Tags

   When reporting events, the specific tags attribute, even if those non-matching records
   experienced change events that were added, deleted, or
   changed co-temporal with change events on
   the matching records.

   In addition, a SW-PC MUST be indicated.  For example, send an attribute in the case where tags A and
   B are two instances of the same SWID tag, each for separate
   installations fulfillment of the same software product, and tag A a
   targeted subscription only when changes in to the endpoint's SWID tag collection, Software
   Inventory Evidence Collection impact one or more records matching the SWID-PC
   subscription's establishing request's Software Identifiers.  A SW-PC
   MUST report the event
   using tag A (rather than reporting it using B).  This means that the
   report MUST contain the tag file or NOT send any attribute in fulfillment of a targeted subscription
   based on detected change to the tag identifier instance for endpoint's Software Inventory
   Evidence Collection that did not involve any of the affected tag.

3.8.  Subscriptions

   Thus far, all message exchanges discussed assume records targeted
   by that subscription.

3.6.5.4.  No Subscription Consolidation

   A SW-PV MAY establish multiple subscriptions to a SWID-PV sent
   an SWID Request attribute and given SW-PC.  If
   this is the SWID-PC case, it is providing a direct
   response to possible that request.  The SWID Message a single change event on the
   endpoint might require fulfillment by multiple subscriptions, and Attributes for PA-TNC
   specification also supports
   that the ability for a SWID-PC to information included in attributes that fulfill each of
   these subscriptions might overlap.  The SW-PC MUST send separate
   attributes for each established subscription that requires a
   message with a SWID Attribute to the SWID-PV in response
   due to observed
   changes in the endpoint's SWID tag collection, instead given event.  Each of in direct
   response to a SWID Request.  An agreement by a SWID-PC to send
   content when certain changes are detected these attributes MUST contain all
   information required to the endpoint's SWID tag
   collection fulfill that individual subscription, even if
   that information is referred to also sent in this specification as a "subscription",
   and other attributes sent in fulfillment
   of other subscriptions at the SWID-PV that receives same time.  In other words, SW-PCs MUST
   NOT attempt to combine information when fulfilling multiple
   subscriptions simultaneously, even if this content is said results in some redundancy
   in the attributes sent to be "subscribed
   to" the given SWID-PC.  All SWID-PCs and SWID-PVs MUST support SW-PV.

3.6.5.5.  Delayed Subscription Fulfillment

   A SW-PC MAY delay the
   use fulfillment of subscriptions.

3.8.1.  Establishing Subscriptions

   A SWID-PV establishes a subscription on a particular SWID-PC by
   sending a SWID Request attribute with the Subscription flag set.  The
   SWID Request attribute is otherwise identical to the SWID Requests
   discussed in previous sections.  Specifically, such following a SWID Request
   might request full tags or tag identifier instances, might be
   targeted, and might request
   change event records or endpoint
   inventory.  Assuming no error is encountered, a SWID-PC MUST send a
   SWID Response attribute in direct response the interest of waiting to this SWID Request
   attribute, just as see if additional change
   events are forthcoming and, if so, conveying the Subscription flag was not set.  As such, relevant records
   back to the message exchange that establishes a new subscription SW-PV in a SWID-PC
   has single SW Response attribute.  This can help
   reduce network bandwidth consumption between the same flow seen in SW-PC and the previous message exchanges, as depicted
   in Figure 2. SW-PV.
   For example, consider a situation where 10 changes occur a tenth of a
   second apart.  If the SWID-PV SW-PC does not receive a PA-TNC Error
   attribute (as described delay in Section 3.10 assembling and Section 4.16) in response
   to their subscription request, sending
   SW Response attributes, the subscription has been successfully
   established on SW-PV will receive 10 separate SW
   Response attributes over a period of 1 second.  However, if the SWID-PC.  The SWID Request attribute that
   establishes SW-PC
   waits half a new subscription is referred to as second after the "establishing
   request" for initial event before assembling a SW
   Response, the SW-PV only receives two SW Response attributes over the
   same period of time.

   Note that subscription.

   When the ability to consolidate events for a single subscription is established it is assigned
   over a Subscription ID
   value.  The Subscription ID is equal to the value of the Request ID given period of time does not contradict the establishing request.  (For more about Request IDs, see rules in
   Section 4.8.)

   A SWID-PC MUST have the ability to record and support multiple
   simultaneous subscriptions from a single party and subscriptions from
   multiple parties.  A SWID-PV MUST have the ability to record and
   support multiple simultaneous subscriptions to a single party and
   subscriptions to 3.6.5.4 prohibiting consolidation across multiple parties.

3.8.2.  Managing Subscriptions

   The SWID-PC MUST record each accepted subscription along with the
   identity
   subscriptions.  When delaying fulfillment of the party to whom attributes subscriptions, SW-PCs
   are still required to be pushed fulfill each individual subscription
   separately.  Moreover, in
   compliance with the subscription.  This identity includes both case that change events within the
   NEA Server's connection ID
   delay window cancel each other out (e.g., a record is deleted and
   then re-added), the Posture Validator Identifier from
   the PB-PA message that delivered the request.

   Likewise, SWID-PVs SW-PC MUST record still report each accepted subscription for which
   they are change event rather
   than just reporting the subscribing party along with net effect of changes over the associated Subscription
   ID and delay period.
   In other words, delayed fulfillment can decrease the identity number of
   attributes send by the SWID-PC that will be fulfilling SW-PC, but it does not reduce the
   subscription.  The SWID-PV needs to retain this information in order total number
   of change events reported.

   SW-PCs are not required to correctly interpret pushed SWID Response attributes sent in support delayed fulfillment of the subscription.  The identity of the SWID-PC is
   given
   subscriptions.  However, in the Posture Collector Identifier of the PB-PA message header
   in all messages from case that SWID-PC.

3.8.3.  Terminating Subscriptions

   Subscriptions MAY be terminated at any time by the subscribing SWID-
   PV by setting SW-PC does support
   delayed subscription fulfillment, it MUST be possible to configure
   the Clear Subscriptions flag in a SWID Request.  (See
   Section 4.9 for more on using this flag.) SW-PC to disable delayed fulfillment.  In the case that the SWID-
   PC receives both the connection ID and the Posture Validator ID of
   the SWID-PV requesting that subscriptions other words, parties
   deploying SW-PCs need to be cleared (i.e., the clear allowed to disable delayed subscription request
   fulfillment in their SW-PCs.  The manner in which such configuration
   occurs is received via a TNC_IMC_ReceiveMessageLong
   function) and the SWID-PC has been recording PV IDs associated with
   subscriptions when available, left to the SWID-PC discretion of implementers, although
   implementers MUST only clear
   subscriptions that match both the connection ID and protect the PV ID, and
   MUST clear all such subscriptions. configuration procedure from
   unauthorized tampering.  In the case that the SWID-PC only
   has the connection ID of the party requesting that subscriptions other words, there needs to be
   cleared or the SWID-PC has not been recording Posture Validator IDs
   associated with subscriptions even when available, it MUST only clear
   subscriptions that match the connection ID and some
   assurance that have no
   associated Posture Validator ID, and MUST clear all such
   subscriptions.

   This specification does not give the SWID-PV the ability to terminate
   subscriptions individually - all subscriptions to the SWID-PV unauthorized individuals are
   cleared when the Clear Subscriptions flag is set.

   This specification does not give the SWID-PC the ability able to
   unilaterally terminate a subscription.  However, if the SWID-PC
   experiences a fatal error fulfilling a subscription, resulting introduce
   long delays in
   sending a PA-TNC Error attribute of type
   SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose
   fulfillment led to fulfillment.

3.7.  Multiple Sources of Software Inventory Evidence Records

   The records in an endpoint's software inventory evidence collection
   might potentially come from multiple sources.  For example, records
   might be derived from ISO SWID tags deposited on the error MUST file system and
   collected therefrom.  Records might also be treated as terminated generated by both
   the SWID-PC tools such
   as software and the SWID-PV.  Only the subscription experiencing the
   error package managers (e.g., RPM or YUM) or might be
   translated from software discovery reports.

   A SW-PC is cancelled and other subscriptions are unaffected.  See
   Section 3.10 for more not required to identify every possible source of software
   information on this error condition.

   Finally, its endpoint.  Some SW-PCs might be explicitly tied
   only to one or a subscription is terminated if the connection between handful of software inventory sources.  For all
   software inventory evidence sources that a particular SW-PC supports,
   it MUST completely support all requirements of this specification
   with regard to those sources.  In other words, for supported sources,
   the
   SWID-PC and SWID-PV SW-PC is deleted.  This occurs when required to be capable of providing a complete set of
   the connection ID
   used provided software inventory evidence records; monitoring for
   changes in the messages between the SWID-PC records reported by those sources, correctly providing
   responses for both full and targeted requests that include records
   from those sources, and providing either complete records or Software
   Identifiers as appropriate.  If the SWID-PV becomes
   unbound.  Loss source's output is not in one of this connection ID would prevent
   the SWID-PC from
   sending messages data models identified in fulfillment of this subscription.  As such, loss
   of the connection ID necessarily forces subscription termination
   between Software Data Model IANA table (see
   Section 9.4), the affected parties.

3.8.4.  Subscription Status

   A SWID-PV can request SW-PC MUST be capable of converting that a SWID-PC report the list output
   into one of active
   subscriptions where the SWID-PV is supported data models.  In all cases, the subscriber.  A SWID-PV can use
   this to recover lost information about active subscriptions.  A SWID-
   PV can SW-PC MUST
   also use this capability to verify be capable of deriving a Software Identifier from the resulting
   record and also assigning that record a SWID-PC has not
   forgotten any of its subscriptions. unique Record Identifier.
   The latter is especially useful
   where a SWID-PC does not send SW-PC MUST NOT provide any attributes inventory or event information from
   software inventory sources for which it cannot provide this full
   support.

   When providing a SW Response (either in direct response to a SW
   Request or in fulfillment of a
   given subscription for a long period of time.  The SWID-PV can check
   the list of active subscriptions on subscription) the SWID-PC and verify whether SW-PC MUST include
   the inactivity complete set of relevant data from all supported sources of
   software inventory evidence.  In other words, a full inventory is due
   required to contain all records from all supported sources, a lack of reportable events, or due
   targeted inventory is required to the
   SWID-PC forgetting its obligations contain all relevant records from
   all sources, and event tracking is required to fulfill a given subscription.

   A SWID-PV requests cover all events from
   all sources.  With regard to events, a list SW-PC's assignment of its subscriptions EIDs
   MUST reflect the presence and order of all events on a given SWID-PC by
   sending the endpoint (at
   least for supported sources) regardless of the source.  This means
   that SWID-PC a Subscription Status Request.  The SWID-PC MUST
   then respond with a Subscription Status Response (or a PA-TNC Error if source A experiences an error condition is experienced).  The Subscription Status
   Response contains one subscription record for each of the active
   subscriptions for which event, and then source B experiences
   two events, and then source A experiences another two events, the SWID-PV SW-
   PC is required to capture five events with consecutive EID values
   reflecting the subscribing party.
   Specifically, order in which the case events occur.

   Note that, if a SW-PC collects data from multiple sources, it is
   possible that the Subscription Status Request
   arrives with some software products might be "double counted".  This
   can happen if both sources of inventory evidence provide a connection ID and record for
   a Posture Validator ID and the
   SWID-PC has been recording Posture Validator IDs associated with
   subscriptions when available, the SWID-PC single installation of a software product.  Moreover, each of these
   provided records might have different Software Identifiers.  When a
   SW-PC reports information or records events from multiple inventory
   evidence sources, it MUST include only
   subscription use the information those sources provide,
   rather than attempting to perform some form of reduction.  In other
   words, if multiple sources report records associated with both corresponding to a single
   installation of a software product, all such records from each source
   are required to be part of the given connection ID and
   Posture Validator ID, SW-PC's processing even if this might
   lead to multiple reporting, and MUST include all the SW-PC is not to ignore some
   records to avoid such records.  In multiple reporting.  Similarly, in the case
   that multiple sources report an event, the Subscription Status Request arrives SW-PC MUST create separate
   event records with only a connection
   ID or the SWID-PC has not been recording Posture Validator IDs
   associated with subscriptions separate EIDs for each of these, even when available, if there is
   the SWID-PC MUST
   include only subscription records associated with chance that they represent the given
   connection ID two sources reporting the same
   action on the endpoint.  Entities tracking software inventory
   information collected via SW-PCs and SW-PVs need to be aware that have no associated Posture Validator ID, and
   MUST include all
   such records.

3.8.5.  Fulfilling Subscriptions

   As noted in Section 3.5 SWID-PCs MUST have the ability to
   automatically detect changes double-reporting might occur.  How (or if) such occurrences are
   detected and resolved is up to the implementers of those entities.

3.8.  Error Handling

   In the case where the SW-PC detects an endpoint's SWID tag collection error in
   near real-time.  For every active subscription, the SWID-PC a SW Request
   attribute that it receives it MUST send
   an respond with a PA-TNC Error
   attribute with an error code appropriate to the subscribed SWID-PV whenever a change is detected
   to relevant tags within nature of the endpoint's SWID tag collection.  The
   SWID-PC MAY choose to exclusively deliver this attribute. error.
   (See
   section 4.5 Section 4.2.8 of RFC 5793 (PB-TNC) [RFC5793] PA-TNC [RFC5792] for more on exclusive
   delivery.)  Such an attribute is said to be sent "in fulfillment of"
   the given subscription details about PA-TNC
   Error attributes and any such attribute MUST include that
   subscription's Subscription ID.  If the establishing request error codes as well as Section 4.16 in this
   specification for error codes specific to SW Attributes.)  In the
   case that
   subscription was an error is detected in a targeted request, then only tags that match SW Request the
   SWID tag identifiers provided in that establishing request are
   considered relevant.  Otherwise, (i.e., for non-targeted requests) SW-PC MUST NOT
   take any tag is considered relevant for action requested by this purpose.  Figure 3 shows a
   sample message exchange where SW Request, even if partial
   completion of the SW is possible.  In other words, a subscription SW Request that
   contains an error is established completely ignored by the SW-PC (beyond sending
   a PA-TNC Error attribute, and then
   later messages are sent from possibly logging the SWID-PC in fulfillment of error locally)
   rather than being partially executed.

   In the
   established subscription.

            +-------------+                    +--------------+
            |  SWID-PC    |                    |   SWID-PV    |  Time
            +-------------+                    +--------------+   |
                  |                                   |           |
                  |<----------SWID Request------------|           |
                  |                                   |           |
                  |-----------SWID Response---------->|           |
                  |                                   |           |
                  .                                   .           .
                  .                                   .           .
                  .                                   .           .
    <Change Event>|                                   |           |
                  |-----------SWID Response---------->|           |
                  |                                   |           |
                  .                                   .           .
                  .                                   .           .
                  .                                   .           .
    <Change Event>|                                   |           |
                  |-----------SWID Response---------->|           |
                  |                                   |           V

           Figure 3: Subscription Establishment and Fulfillment

   The contents of an attribute sent in fulfillment of case where the SW-PC receives a subscription
   depend on valid SW Request attribute but
   experiences an error during the parameters provided in process of responding to that
   attribute's instructions where that error prevents the establishing request for SW-PC from
   properly or completely fulfilling that subscription.  Specifically, request, the contents of an SW-PC MUST send a
   PA-TNC Error attribute sent
   in fulfillment with an error code appropriate to the nature
   of a subscription have the same format as would error.  In the case where a
   direct response PA-TNC Error attribute is sent,
   the SW-PC MUST NOT take any of the actions requested by the SW
   Request attribute which led to the establishing request.  For example, if detected error.  This is the
   establishing request stipulated a response that contained an event
   record list wherein affected SWID tags were indicated using SWID tag
   identifier instances, all attributes sent in fulfillment of this
   subscription will also consist of event record lists expressed using
   SWID tag identifier instances.  As such, all SWID Responses displayed
   in the exchange depicted in Figure 3 case
   even if some actions could have been completed successfully, and
   might even require the same format.  A SWID
   Response generated in fulfillment of an active subscription MUST be a
   valid SWID Response attribute according SW-PC to all the rules outlined in reverse some successful actions
   already taken before the preceding sections. error condition was detected.  In other
   words, an attribute constructed in
   fulfillment either all aspects of a subscription will look SW Request complete fully and
   successfully (in which case the same as an attribute sent
   in direct response to an explicit request from SW-PC sends a SWID-PV that had SW Response attribute),
   or no aspects of the
   same request parameters and SW Request occur (in which arrived immediately after case the given
   change event.  There are SW-PC sends
   a few special rules that expand on this
   guideline:

3.8.5.1.  Subscriptions Reporting Inventories PA-TNC Error attribute).  In the case that a SWID-PV subscribes to SW-PC sends a SWID-PC requesting an
   inventory PA-TNC
   Error attribute whenever changes are detected (i.e. the EID in
   the establishing request is 0), response to a SW Request then the SWID-PC SW-PC MUST NOT
   also send any SW Response attribute in response to the
   requested inventory whenever same SW
   Request.  For this reason, the sending of a relevant change is detected.  (A
   "relevant change" is any change for untargeted requests, or SW Response attribute
   MUST be the last action taken by a change
   to an indicated SWID tag SW-PC in response to a targeted request.)  Upon detection SW Request
   to avoid the possibility of a
   relevant change for an active subscription, processing error occurring after that
   SW Response attribute is sent.

   In the SWID-PC sends case that the
   appropriate inventory information as if SW-PC detects an error that prevents it had just received from
   properly or completely fulfilling its obligations under an active
   subscription, the
   establishing request.  Attributes sent in fulfillment of this
   subscription will probably have SW-PC MUST send a large amount PA-TNC Error attribute of redundancy, as the
   same tags are likely type
   SW_SUBSCRIPTION_FULFILLMENT_ERROR to be present in each of these SWID Attributes.
   The role the SW-PV that established this
   subscription.  This type of an inventory PA-TNC Error attribute identifies the
   specific subscription is not that cannot be adequately honored due to report tags just for the items that changed - that
   error condition as well as an error "sub-type".  The error sub-type
   is used to indicate the role type of a subscription error condition the SW-PC experienced
   that
   reports events (see Section 3.8.5.2).  A SWID-PC MUST NOT exclude a
   tag prevented it from an attribute sent in fulfillment of an inventory
   subscription simply because honoring the given subscription.  In the case
   that tag was the error condition cannot be identified or does not involved in align with
   any of the
   triggering event (although defined error codes, the tag might SW_ERROR error code SHOULD be excluded for other
   reasons, such as if the subscription is targeted - see
   Section 3.8.5.3).

3.8.5.2.  Subscriptions Reporting Events

   The way
   used in which a SWID-PV indicates it wishes to establish the sub-type.  In the case that a
   subscription requesting event records
   SW_SUBSCRIPTION_FULFILLMENT_ERROR is by providing a non-zero EID
   in the SWID Request establishing sent, the associated
   subscription (see
   Section 3.6.1).  However, when MUST be treated as cancelled by both the SWID-PC constructs an attribute in
   fulfillment of the 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 SW-PC and SW-
   PV.

   The SW-PV MUST NOT send a complete list of all changes starting
   with the indicated EID, up through the latest change, every time a
   new event is detected. any PA-TNC Error attributes to SW-PCs.  In effect, the EID in
   the establishing
   request is treated as being updated every time case that a SW-PV detects an attribute is sent
   in fulfillment error condition, it SHOULD log this
   error but does not inform any SW-PC's of this subscription, such that a single event is event.  Errors might
   include, but are not
   reported twice in fulfillment limited to, detection of malformed SW Response
   attributes sent from a single subscription.  As such,
   every SWID-PC MUST track the EID of the last event that triggered an
   attribute for the given subscription.  When the next event (or set SW-PC, as well as detection of
   events) is detected, the SWID-PC MUST only report events with later
   EIDs.  In error
   conditions when the case SW-PV processes SW Responses.

   Both SW-PCs and SW-PVs SHOULD log errors so that administrators can
   trace the EID Epoch causes of errors.  Log messages SHOULD include the SWID-PC changes, type of
   the
   SWID-PC MUST treat EID values in error, the new Epoch as being after all
   EIDs assigned time it was detected, and additional descriptive
   information to aid in understanding the previous Epoch regardless nature and cause of the relative
   numeric values
   error.

4.  Software Message and Attributes for PA-TNC Protocol

   This section describes the format and semantics of these EIDs.

   Note that while a subscription is active, the subscribing SWID-PV MAY
   make other requests Software
   Message and Attributes for event records that overlap with events that
   are reported due to a subscription.  Such requests are unaffected by PA-TNC protocol.  Software Message and
   Attributes for PA-TNC uses the presence standard PA-TNC message header format.
   See the PA-TNC specification [RFC5792] for information on this header
   format.

4.1.  PA Subtype (AKA PA-TNC Component Type)

   The NEA PB-TNC interface provides a general message-batching protocol
   capable of carrying one or more PA-TNC messages between the subscription, nor Posture
   Broker Client and Posture Broker Server.  When PB-TNC is the subscription affected by
   such requests.  In other words, carrying a given request will get
   PA-TNC message, the same
   results back whether or not there was a subscription.  Likewise, an
   attribute sent in fulfillment of a subscription will PB-TNC message headers contain a 32 bit
   identifier called the same
   information whether or not other requests had been received from the
   SWID-PV.

   A SWID-PV needs to pay attention to PA Subtype.  The PA Subtype field indicates the EID Epoch in these messages,
   as changes in
   type of component associated with all of the Epoch might create discontinuities in PA-TNC attributes
   carried by the SWID-PV's
   understanding PB-TNC message.  The core set of the endpoint's SWID tag collection state, as
   discussed PA Subtypes is
   defined in Section 3.6.5.  In particular, once the EID Epoch
   changes, a SWID-PV is unable have confidence that it has a correct
   understanding of PA-TNC specification.  This specification adds the state of an endpoint's SWID tag collection until
   after
   following enumeration element to the SWID-PV collects a complete inventory.

   SWID-PCs MAY send partial lists of event records table in fulfillment section 7.2 of a
   subscription.  (See Section 3.6.4 for more on partial list of event
   records.)  In the case that a SWID-PC sends a partial list of event
   records, it MUST immediately send PA-
   TNC specification [RFC5792] using the next consecutive partial list, IETF Standard name space (SMI
   Private Enterprise Number 0x000000):

   +-----+---------+-------------+-------------------------------------+
   | PEN | Integer | Name        | Defining Specification              |
   +-----+---------+-------------+-------------------------------------+
   | 0   | 9       | SW          | Software Message and continue doing so until it has sent the equivalent of the
   complete list of event records.  In other words, if the SWID-PC sends
   a partial list it does not wait Attributes for another change event |
   |     |         | Attributes  | PA-TNC                              |
   +-----+---------+-------------+-------------------------------------+

                            Table 2: PA Subtype

   Each PA-TNC attribute described in this specification is intended to send
   another SWID Response, but continues sending SWID Responses until it
   has
   be sent all event records that would have been included in a
   complete fulfillment of between the subscription.

3.8.5.3.  Targeted Subscriptions

   Subscriptions MAY SW-PC and SW-PV, so will be targeted to only apply to tags that match carried in a
   given set PB-TNC
   message indicating a PA Subtype of tag identifiers.  In the case where changes are detected SW Attributes.  Note that affect multiple tags, some matching the establishing request's
   tag identifiers and some not, although
   the PA-TNC Error attribute sent is defined in fulfillment the PA-TNC specification,
   when it is used in a SW Attribute exchange, it uses the SW Attributes
   Component Definition Value, as described in Section 4.2.8 of the subscription PA-
   TNC specification [RFC5792].  PB-TNC messages MUST only always include inventory or events (as
   appropriate) for tags that match the establishing request's tag
   identifiers.  The SWID-PC MUST NOT include non-matching tags
   SW Attributes Subtype defined in the
   attribute, even if those non-matching tags experienced change events
   that were co-temporal with change events on the matching tags.

   In addition, a SWID-PC MUST send an attribute in fulfillment of a
   targeted subscription only this section when changes to the endpoint's SWID tag
   collection impact carrying SW
   Attributes over PA-TNC.

4.2.  PB-TNC and PA-TNC Messages

   A PA-TNC message is wrapped within a PB-TNC message.  A single PA-TNC
   message might contain one or more tags matching the subscription's
   establishing request's tag identifiers.  A SWID-PC MUST NOT send any
   attribute in fulfillment PA-TNC attributes.  All of these
   attributes within a targeted subscription based on detected
   change to the endpoint's SWID tag collection that did not involve any
   of single PA-TNC message use the tags targeted by that subscription.

3.8.5.4.  No Subscription Consolidation

   A SWID-PV MAY establish multiple subscriptions to a given SWID-PC.
   If this is same PA Subtype
   value.  As such, SW Attributes are never sent in the case, it is possible same PA-TNC
   message as attributes defined in other PA-TNC binding specifications.

   Note, however, that a single change event on the
   endpoint PB-TNC batch might require fulfillment by contain multiple subscriptions, PB-
   TNC and PA-TNC messages, and
   that the information included in attributes that fulfill each of
   these subscriptions those messages might overlap. use
   different PA Subtypes.

   For more information on PB-TNC and PA-TNC messages and message
   headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
   specifications, respectively.

4.3.  PA-TNC Attribute Header

   The SWID-PC MUST send separate
   attributes Software Message and 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 PA-TNC protocol described in other attributes sent in fulfillment
   this specification is an extension of other subscriptions at the same time.  In other words, SWID-PCs
   MUST NOT attempt to combine information when fulfilling multiple
   subscriptions simultaneously, even if this results in some redundancy PA-TNC protocol described
   in the attributes sent NEA Architecture.  PA-TNC was designed to the SWID-PV.

3.8.5.5.  Delayed Subscription Fulfillment

   A SWID-PC MAY delay the fulfillment of a subscription following a
   change event be very flexible in the interest
   order to carry many types of waiting PA-TNC attributes that pertain to see if additional change
   events are forthcoming and, if so, conveying the relevant records
   back an
   enumerated set of component types (e.g.  Table 2).  PA-TNC attributes
   might be carried from Posture Collector to the SWID-PV in a single SWID Response attribute.  This can
   help reduce network bandwidth consumption between the SWID-PC Posture Validator or vice
   versa and the
   SWID-PV.  For example, consider a situation where 10 changes occur might carry information about endpoint state or other
   information to be sent between a
   tenth of Posture Validator and a second apart.  If Posture
   Collector.  Therefore, the SWID-PC does not delay in assembling Software Message and sending SWID Response attributes, the SWID-PV will received 10
   separate SWID Response attributes over Attributes for PA-TNC
   specification defines a period collection of 1 second.
   However, if the SWID-PC waits half a second after the initial event
   before assembling a SWID Response, the SWID-PV only receives two SWID
   Response PA-TNC attributes over relevant to
   the same period collection and transmission of time.

   Note that software inventories and
   associated events.

   Figure 4, reproduced from the ability to consolidate events for a single subscription
   over PA-TNC specification, shows the format
   of a given period of time does not contradict the rules PA-TNC attribute.  Multiple PA-TNC attributes can be sent in
   Section 3.8.5.4 prohibiting consolidation across multiple
   subscriptions.  When delaying fulfillment of subscriptions, SWID-PCs
   are still required to fulfill a
   single PB-TNC message, each individual subscription
   separately.  Moreover, in the case that change events housed within the
   delay window cancel each other out (e.g., a SWID tag is deleted an attribute structure as
   described below.

                        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     |          PA-TNC Attribute Vendor ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    PA-TNC Attribute Type                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    PA-TNC Attribute Length                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Attribute Value (Variable Length)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: PA-TNC Header and
   then re-added), the SWID-PC MUST still report each change event
   rather than just reporting Attribute Format

   +-----------+-------------------------------------------------------+
   | Field     | Description                                           |
   +-----------+-------------------------------------------------------+
   | Flags     | This field defines flags affecting the net effect processing of changes over  |
   |           | the delay
   period.  In other words, delayed fulfillment can decrease Software Message and Attributes for PA-TNC.       |
   |           | Permissible flags are given in the number PA-TNC             |
   |           | specification. [RFC5792]                              |
   |           |                                                       |
   | Attribute | This field indicates the owner of attributes send by the SWID-PC, but it does not reduce name space      |
   | Type      | associated with the total
   number of change events reported.

   SWID-PCs are not required to support delayed fulfillment of
   subscriptions.  However, Attribute Type.  Attributes       |
   | Vendor ID | defined in the case that the SWID-PC does support
   delayed subscription fulfillment, it MUST be possible Software Message and Attributes for    |
   |           | PA-TNC specification have a value corresponding to configure    |
   |           | the SWID-PC to disable delayed fulfillment.  In other words, parties
   deploying SWID-PCs need to be allowed to disable delayed subscription
   fulfillment in their SWID-PCs. IETF SMI Private Enterprise Number value          |
   |           | (0x000000). The manner in which such
   configuration occurs PA-TNC Error attribute is left to defined in  |
   |           | the discretion PA-TNC specification [RFC5792] and also uses the  |
   |           | IETF SMI Private Enterprise Number Value (0x000000).  |
   |           | See Table 4 for more information.                     |
   |           |                                                       |
   | Attribute | This field defines the type of implementers,
   although implementers MUST protect the configuration procedure from
   unauthorized tampering.  In other words, there needs Attribute. The     |
   | Type      | values corresponding to be some
   assurance that unauthorized individuals SW Attributes are not able to introduce
   long delays in subscription fulfillment.

3.9.  Multiple Sources of SWID Tags

   As noted in Section 2.1, the SWID tags given in an endpoint's SWID tag
   collection might potentially come from multiple sources.  For
   example, SWID tags might be deposited on    |
   |           | Table 4.                                              |
   |           |                                                       |
   | Attribute | This field contains the file system and
   collected therefrom.  SWID tags might also be dynamically generated
   by tools such as software and package managers (e.g., RPM or YUM) or
   might be dynamically translated from software discovery reports
   expressed length in some non-SWID format.

   A SWID-PC is not required to identify every possible source octets of SWID
   tags on its endpoint.  Some SWID-PCs might be explicitly tied only to
   one or a handful of SWID tag sources.  SWID-PCs are not required to
   be aware of SWID tags that come from sources other than those that
   they specifically support.  In particular, if an endpoint has 3
   sources the       |
   | Length    | entire Attribute, including the Attribute's header.   |
   |           |                                                       |
   | Attribute | This field contains the SW Attribute.                 |
   | Value     |                                                       |
   +-----------+-------------------------------------------------------+

              Table 3: Fields of SWID tags, and the PA-TNC Attribute Format

4.4.  SW Attribute Overview

   The attributes defined in this specification appear below with a SWID-PC supports collecting SWID tags
   from two
   short summary of those sources, not only their purposes.  Each attribute is that SWID-PC only responsible
   for reporting tags that come from its two supported sources, but it described in
   greater detail in subsequent sections.

   o  SW Request - This attribute is also only responsible for monitoring for change events used to request a software
      inventory or software event list from those
   two sources. an endpoint.  This noted, for all of the SWID tag sources that attribute
      might also establish a
   particular SWID-PC supports, it subscription on the recipient SW-PC.  A SW-
      PC MUST completely support all
   requirements of NOT send this specification with regard to its supported
   sources.  In other words, for supported sources, the SWID-PC attribute.

   o  Software Identifier Inventory - This attribute is
   required used to be capable of providing complete inventories convey
      an inventory expressed using Software Identifiers (instead of SWID
   tags; monitoring for changes in the SWID collections reported by
   those sources, correctly providing responses for both full and
   targeted requests, and providing either complete SWID tag files or
   SWID identifier instances as appropriate.  The SWID-PC
      records).  When a SW-PC receives a SW Request attribute requesting
      an inventory using Software Identifiers, the SW-PC MUST send a
      Software Identifier Inventory attribute (or a PA-TNC Error) in
      response.  This attribute also MAY be sent by the SW-PC in
      fulfillment of an active subscription.  A SW-PV MUST NOT
   provide any inventory or event information from SWID tag sources for
   which it cannot provide send this full support.

   The SWID Response attributes provide no way
      attribute.

   o  Software Identifier Events - This attribute is used to convey a
      list of distinguishing as events concerning changes to
   which SWID tags, identifier instances, or event an endpoint's Software
      Inventory Evidence Collection.  Affected software inventory
      evidence records are
   associated with specific sources.  The SWID-PC MUST include the
   complete set of relevant data from all supported sources indicated using Software Identifiers (instead
      of SWID tags
   in every SWID Response.  In other words, a full inventory is required
   to contain all the SWID tags from all supported sources, records).  When a targeted
   inventory is required to contain all relevant tags from all sources,
   and event tracking is required to cover all events from both sources.
   With regard to events, SW-PC receives a SWID-PC's assignment of EIDs MUST reflect SW Request attribute
      requesting an event collection using Software Identifiers, the presence and order of all events on SW-
      PC MUST send a Software Identifier Events attribute (or a PA-TNC
      Error) in response.  This attribute also MAY be sent by the endpoint (at least for
   supported sources) regardless SW-PC
      in fulfillment of the source.  This means that if
   source A experiences an event, and then source B experiences two
   events, and then source active subscription.  A experiences another two events, the SWID-PC SW-PV MUST NOT send
      this attribute.

   o  Software Inventory - This attribute is required used to capture five events with consecutive EID values
   reflecting the order in which the events occur.

   Note that, if a SWID-PC collects data from multiple sources, it is
   possible that some convey an inventory
      expressed using full software products might be "double counted".  This
   can happen if both sources inventory evidence records (instead
      of SWID tags provide a SWID tag for Software Identifiers).  When a
   single instance of SW-PC receives a SW Request
      attribute requesting an inventory using full software product.  Moreover, each of these
   provided tags will probably have different SWID tag identifier
   instances, since Instance IDs are managed by the process that
   extracts the SWID tags from the individual sources, and such
   processes are under no obligation to coordinate with each other as to inventory
      evidence records, the Instance ID value.  When a SWID-PC reports information or records
   events from multiple SWID tag sources, it SW-PC MUST use send a Software Inventory
      attribute (or a PA-TNC Error) in response.  This attribute also
      MAY be sent by the information
   those sources provide, rather than attempting to perform some form SW-PC in fulfillment of
   reduction.  In other words, if multiple sources report a particular
   SWID tag corresponding an active subscription.
      A SW-PV MUST NOT send this attribute.

   o  Software Events - This attribute is used to convey a single installation list of a
      events concerning changes to an endpoint's inventory evidence
      collection.  Affected software
   product, all such tags from each source inventory evidence records are required to be part
      indicated using full records (instead of Software Identifiers).
      When a SW-PC receives a SW Request attribute requesting an event
      collection using full records, the SWID-PC's processing even if this might lead to multiple
   reporting, and the SWID-PC is not to ignore some tags to avoid such
   multiple reporting.  Similarly, SW-PC MUST send a Software
      Events attribute (or a PA-TNC Error) in response.  This attribute
      also MAY be sent by the case that multiple sources
   report SW-PC in fulfillment of an event, the SWID-PC active
      subscription.  A SW-PV MUST create separate event records with
   separate EIDs for each of these, even if there is the chance that
   they represent the two sources reporting the same action on the
   endpoint.  Entities tracking SWID tags collected via SWID-PCs and
   SWID-PVs need to be aware that such double-reporting might occur.
   How (or if) such occurrences are detected and resolved NOT send this attribute.

   o  Subscription Status Request - This attribute is up used to the
   implementers request a
      SW-PC send a summary of those entities.

3.10.  Error Handling

   In all the case active subscriptions it has where
      the SWID-PC detects an error in a SWID Request
   attribute that it receives it requesting party is the subscriber.  The SW-PC MUST respond
      with a Subscription Status Response (or a PA-TNC Error Error).  A SW-PC
      MUST NOT send this attribute.

   o  Subscription Status Response - This attribute with an error code appropriate is used to convey
      information about the nature of the error.
   (See Section 4.2.8 of PA-TNC [RFC5792] active subscriptions that a SW-PC has for more details about a
      given subscriber.  A SW-PV MUST NOT send this attribute.

   o  PA-TNC Error attributes and error codes as well - This is the standard PA-TNC Error attribute as Section 4.16
      defined in this
   specification for error codes specific PA-TNC [RFC5792] and is used to SWID attributes.)  In the
   cast indicate that an error is detected in
      was encountered during a SWID Request the SWID-PC SW Attribute exchange.  It MUST NOT
   take any action requested by this SWID Request, even if some
   requested action can be completed successfully despite the error sent
      by a SW-PC in
   the attribute.  In other words, response to a SWID SW Request that contains an error
   is ignored by the SWID-PC beyond sending a PA-TNC Error attribute,
   and possibly logging the error locally.

   In in the case where the SWID-PC receives SW-PC
      encounters a valid SWID Request attribute
   but experiences fatal error (i.e., an error during the process of responding to that
   attribute's instructions where that error prevents further
      processing of an exchange) relating to the SWID-PC from
   properly or completely fulfilling that request, the SWID-PC attribute exchange.  A
      SW-PV MUST NOT send this attribute.  The SW-PC MUST then ignore
      the erroneous attribute after a PA-TNC Error attribute with an error code appropriate is sent
      (i.e., do not attempt to act on an attribute that generated a PA-
      TNC Error beyond sending the nature
   of the error. PA-TNC Error).  In the case where the
      SW-PV experiences a fatal error, it MUST ignore the erroneous
      attribute without sending a PA-TNC Error attribute is sent,
   the SWID-PC MUST NOT attribute.  It MAY take any of the
      other actions requested by the SWID
   Request attribute which led in response to the detected error.  This is error, such as logging the case cause
      of the error, or even if some taking actions can be completed successfully, and might even
   require the SWID-PC to reverse some successful actions already taken
   before isolate the error condition was detected.  In other words, either all
   aspects endpoint

   Because one of a SWID Request complete fully and successfully (in which
   case the SWID-PC sends a SWID Response attribute), Software Identifier Inventory, Software Identifier
   Events, Software Inventory, or no aspects of
   the SWID Request occur (in which case the SWID-PC sends a PA-TNC
   Error attribute).  In the case that a SWID-PC sends Software Events attributes is expected
   to be sent to a PA-TNC Error
   attribute SW-PV in direct response to a SWID SW Request then the SWID-PC MUST NOT
   also send any SWID Response attribute or
   in response fulfillment of an active subscription, those four attribute types
   are referred to the same SWID
   Request.  For collectively in this reason, the document as "SW Response"
   attributes.

   All SW-PVs MUST be capable of sending SW Requests and be capable of a SWID
   receiving and processing all SW Response attribute attributes as well as PA-TNC
   Error attributes.  All SW-PCs MUST be the last action taken by a SWID-PC in response to a SWID
   Request to avoid the possibility capable of a receiving and
   processing error occurring
   after that SWID SW Requests and be capable of sending all types of SW
   Response attribute is sent.

   In the case that the SWID-PC detects an error that prevents it from
   properly or completely fulfilling its obligations under an active
   subscription, the SWID-PC MUST send a attributes as well as PA-TNC Error attribute of type
   SWID_SUBSCRIPTION_FULFILLMENT_ERROR attributes.  In other
   words, both SW-PVs and SW-PCs are required to support their role in
   exchanges using any of the SWID-PV that established attribute types defined in this subscription.  This type of section.
   SW-PVs MUST ignore any SW Request attributes that they receive.  SW-
   PCs MUST ignore any SW Response attributes or PA-TNC Error attribute identifies
   the specific subscription attributes
   that cannot be adequately honored due to
   the error condition as well as an error "sub-type".  The error sub-
   type they receive.

4.5.  SW Attribute Exchanges

   A SW Attribute Exchange is used to indicate provide the type of error condition SW-PV with a software
   inventory or event collection from the SWID-PC
   experienced that prevented it from honoring queried endpoint.

       +-------------+                      +--------------+
       |   SW-PC     |                      |    SW-PV     |  Time
       +-------------+                      +--------------+   |
             |                                     |           |
             |<------------SW Request--------------|           |
             |                                     |           |
             |             SW Response*            |           |
             |-----------------or----------------->|           |
             |             PA-TNC Error            |           |
             |                                     |           V

     *SW Response is one of the given subscription. following: Software Identifier
      Inventory, Software Identifier Events, Software Inventory,
      or Software Events.

      Figure 5: SW Attribute Exchange (Direct Response to SW Request)

   In this exchange, the case that SW-PV indicates to the error condition cannot be identified or does not
   align with any SW-PC, via a SW Request,
   the nature of the defined error codes, information it wishes to receive (inventory vs.
   events, full or targeted) and how it wishes the SWID_ERROR error code
   SHOULD returned inventory to
   be used in the sub-type.  In the case that a
   SWID_SUBSCRIPTION_FULFILLMENT_ERROR is sent, expressed (full records or Software Identifiers).  The SW-PC
   responds with the associated
   subscription MUST be treated as cancelled by both requested information using the SWID-PC and
   SWID-PV.

   The SWID-PV appropriate
   attribute type.  A single SW Request MUST NOT send any only lead to a single SW
   Response or PA-TNC Error attributes that is in direct response to SWID-PCs. that request.

   In addition, if there is an active subscription on the case that endpoint, the
   SW-PC sends a SWID-PV detects an error condition, it SHOULD log
   this error but does not inform any SWID-PC's of this event.  Errors
   might include, but are not limited to, detection of malformed SWID SW Response attributes sent from a given SWID-PC, as well as detection
   of error conditions when the SWID-PV processes SWID Responses.

   Both SWID-PCs and SWID-PVs SHOULD log errors so that administrators
   can trace to the causes of errors.  Log messages SHOULD include SW-PV following a change event on
   the type endpoint in fulfillment of the error, the time it was detected, and additional descriptive
   information to aid that subscription.  Such an exchange
   is shown in understanding the nature and cause Figure 6.

            +-------------+                +--------------+
            |   SW-PC     |                |    SW-PV     |  Time
            +-------------+                +--------------+   |
                  |                               |           |
    <Change Event>|                               |           |
                  |--------SW Response(s)*------->|           |
                  |                               |           |

     *SW Response is one of the
   error.

4.  SWID Message and Attributes for PA-TNC Protocol

   This section describes the format and semantics following: Software Identifier
      Inventory, Software Identifier Events, Software Inventory,
      or Software Events.

       Figure 6: SW Attribute Exchange (In Fulfillment of the SWID Message
   and Attributes an Active
                               Subscription)

   Note that, unlike direct responses to a SW Request, a single change
   event can precipitate multiple SW Responses for PA-TNC protocol leveraging a single
   subscription, but only if all but the existing SWID tag
   format.  SWID Message last of those SW Responses
   convey partial lists of event records, and Attributes for PA-TNC uses the standard PA-
   TNC message header format.  See the PA-TNC specification [RFC5792]
   for information on this header format.

4.1.  PA Subtype (AKA PA-TNC Component Type)

   The NEA PB-TNC interface provides last of those SW
   Responses conveys a general message-batching protocol
   capable complete list of carrying one or more PA-TNC messages between event records.  (That is, the Posture
   Broker Client
   initial responses are partial lists and Posture Broker Server.  When PB-TNC the last response is carrying a
   PA-TNC message, the PB-TNC message headers contain a 32 bit
   identifier called
   remainder of the PA Subtype.  The PA Subtype field indicates relevant event records, completing the
   type delivery of component associated with
   all relevant events at the time of the change event.)  A single
   Change Event MUST NOT be followed by multiple SW Response or PA-TNC
   Error attributes
   carried by the PB-TNC message.  The core set of PA Subtypes is
   defined in the PA-TNC specification. any combination except as noted earlier in this
   paragraph.

   All SW-PVs and SW-PCs MUST support both types of exchanges.  In order for the NEA protocols
   particular, SW-PCs MUST be capable of pushing a SW Response to carry SWID tags, this specification adds the following enumeration
   element a SW-
   PV immediately upon detection of a change to the table endpoint's Software
   Inventory Evidence Collection in section 7.2 fulfillment of established SW-PV
   subscriptions, as described in Section 3.6.

4.6.  Software Message and Attributes for PA-TNC Attribute Enumeration

   PA-TNC attribute types are identified in the PA-TNC specification
   [RFC5792] using Attribute Header
   (see Section 4.2) via the IETF Standard name space (SMI Private Enterprise
   Number 0x000000):

   +-----+---------+----------------+----------------------------------+ Attribute Type Vendor ID and Attribute Type
   fields.  Table 4 identifies the appropriate values for these fields
   for each attribute type used within the Software Message and
   Attributes for PA-TNC protocol.

   +--------------+----------+------------+----------------------------+
   | Attribute    | PEN      | Integer    | Description                |
   | Name         | Defining Specification          |
   +-----+---------+----------------+----------------------------------+            | 0                            | 9
   +--------------+----------+------------+----------------------------+
   | SWID SW Request   | SWID Message and Attributes for 0x000000 | 0x00000011 | Request from a SW-PV to a  |
   | Attributes              | PA-TNC          |
   +-----+---------+----------------+----------------------------------+

                            Table 2: PA Subtype

   Each PA-TNC attribute described in this specification is intended to
   be sent between            | SW-PC for the SWID-PC and SWID-PV, so will be carried in a PB-
   TNC message indicating SW-PC to     |
   |              |          |            | provide a PA Subtype software         |
   |              |          |            | inventory or event list    |
   |              |          |            |                            |
   | Software     | 0x000000 | 0x00000012 | A collection of SWID Attributes.  Note that
   although the PA-TNC Error attribute is defined in the PA-TNC
   specification, when it is used in a SWID Attribute exchange, it uses
   the SWID Attributes Component Definition Value, as described in
   Section 4.2.8 of the PA-TNC specification [RFC5792].  PB-TNC messages
   MUST always include the SWID Attributes Subtype defined in this
   section when carrying SWID Attributes over PA-TNC.

4.2.  PB-TNC and PA-TNC Messages

   A PA-TNC message is wrapped within Software   |
   | Identifier   |          |            | Identifiers sent from a PB-TNC message.    |
   | Inventory    |          |            | SW-PC.                     |
   |              |          |            |                            |
   | Software     | 0x000000 | 0x00000013 | A single PA-TNC
   message might contain one or more PA-TNC attributes.  All collection of these
   attributes within a single PA-TNC message use events     |
   | Identifier   |          |            | impacting the same PA Subtype
   value.  As such, SWID Attributes endpoint's   |
   | Events       |          |            | Software Inventory         |
   |              |          |            | Evidence Collection, where |
   |              |          |            | impacted software          |
   |              |          |            | inventory evidence records |
   |              |          |            | are never indicated using        |
   |              |          |            | Software Identifiers.      |
   |              |          |            |                            |
   | Software     | 0x000000 | 0x00000014 | A collection of software   |
   | Inventory    |          |            | inventory evidence records |
   |              |          |            | sent with attributes
   defined in other PA-TNC binding specifications in a single PA-TNC
   message.  Note, however, that from a single PB-TNC batch might contain
   multiple PB-TNC and PA-TNC messages, and each SW-PC.         |
   |              |          |            |                            |
   | Software     | 0x000000 | 0x00000015 | A collection of those messages might
   use different PA Subtypes.

   For more information on PB-TNC and PA-TNC messages and message
   headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792]
   specifications, respectively.

4.3.  PA-TNC Attribute Header

   The SWID Message and Attributes for PA-TNC protocol described in this
   specification is an extension of the PA-TNC protocol described in the
   NEA Architecture.  PA-TNC was designed to be very flexible in order
   to carry many types of PA-TNC attributes that pertain to an
   enumerated set of component types (e.g.  Table 2).  PA-TNC attributes
   might be carried from Posture Collector to Posture Validator or vice
   versa and might carry information about endpoint state or other
   information to be sent between a Posture Validator and a Posture
   Collector.  Therefore the SWID Message and Attributes for PA-TNC
   specification defines a collection of PA-TNC attributes relevant to
   the collection and transmission of SWID tag inventories.

   Figure 4, reproduced from the PA-TNC specification, shows events     |
   | Events       |          |            | impacting the format
   of a PA-TNC attribute.  Multiple PA-TNC attributes can be sent in a
   single PB-TNC message, each housed within an attribute structure as
   described below.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ endpoint's   |     Flags
   |          PA-TNC Attribute Vendor ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          |                    PA-TNC Attribute Type            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Software Inventory         |                    PA-TNC Attribute Length
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              |               Attribute Value (Variable Length)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: PA-TNC Header and Attribute Format

   +-----------+-------------------------------------------------------+            | Field Evidence Collection, where | Description
   |
   +-----------+-------------------------------------------------------+              | Flags          | This field defines flags affecting the processing of            | impacted software          |
   |              |          |            | inventory evidence records |
   | the SWID Message and Attributes for PA-TNC.              |          |            | Permissible flags are given in the PA-TNC indicated using full   |
   |              | specification. [RFC5792]          |            | Attribute records.                   | This field indicates the owner of the name space
   |              | Type          | associated with the Attribute Type.  Attributes            |                            | Vendor ID
   | defined in the SWID Message and Attributes for PA-TNC Subscription | 0x000000 | 0x00000016 | specification have A request for a list of a value corresponding to the IETF  |
   | Status       | SMI Private Enterprise Number value (0x000000). The          |            | SW-PV's active             | PA-TNC Error attribute is defined in the PA-TNC
   | Request      |          | specification [RFC5792] and also uses the IETF SMI            | subscription.              |
   | Private Enterprise Number Value (0x000000). See Table              |          |            | 4 for more information.                            |
   | Attribute Subscription | This field defines the type 0x000000 | 0x00000017 | A list of the Attribute. The a SW-PV's active |
   | Type Status       | values corresponding to SWID Attributes          |            | subscriptions.             |
   | Response     |          |            |                            |
   |              |          |            |                            |
   | Reserved     | 0x000000 | 0x00000018 | These attribute types are given  |
   |              |          | -          | reserved for future use in |
   |              | Table 4.          | 0x0000001F | Attribute revisions to Software      | This field contains the length in octets of the
   |              | Length          | entire Attribute, including the Attribute's header.            | Message and Attributes for |
   |              |          |            | PA-TNC.                    |
   | Attribute              | This field contains the SWID Attribute.          |            | Value                            |
   |
   +-----------+-------------------------------------------------------+

              Table 3: Fields of the PA-TNC Attribute Format

4.4.  SWID Attribute Overview

   The attributes Error | 0x000000 | 0x00000008 | An error attribute as      |
   |              |          |            | defined in this the PA-TNC      |
   |              |          |            | specification appear below with a
   short summary [RFC5792].   |
   +--------------+----------+------------+----------------------------+

                     Table 4: SW Attribute Enumeration

4.7.  Normalization of their purposes.  Each attribute is described in
   greater detail Text Encoding

   In order to ensure consistency of transmitted attributes, a field
   requiring normalization, as indicated in subsequent sections.

   o  SWID Request - This attribute is used its description, MUST be
   normalized to request Network Unicode format as defined in RFC 5198
   [RFC5198].  Network Unicode format defines a SWID tag
      inventory or SWID event list from an endpoint.  This attribute
      might also establish refinement of UTF-8 that
   ensures a subscription on the recipient SWID-PC.  A
      SWID-PC normalized expression of characters.  SW-PCs and SW-PVs
   MUST NOT send this attribute.

   o  SWID Tag Identifier Inventory - This attribute perform conversion and normalization on any field values
   except those specifically identified as requiring normalization in
   the following sections.  Note, however, that some data models require
   additional normalization before source information is used added to convey an inventory expressed using SWID tag identifier instances
      (instead of full tags).  When a SWID-PC receives
   Endpoint's Inventory Evidence Collection as a SWID Request
      attribute requesting an inventory using SWID tag identifier
      instances, record.  The references
   from the SWID-PC Software Data Model IANA table (see section Section 9.4 will
   note where this is necessary.

4.8.  Request IDs

   All SW Request attributes MUST send include a SWID Tag Identifier Inventory
      attribute (or Request ID value.  The
   Request ID field provides a PA-TNC Error) in response.  This attribute also
      MAY be sent by value that identifies a given request
   relative to other requests between a SW-PV and the SWID-PC in fulfillment of an active
      subscription.  A SWID-PV MUST NOT send this attribute.

   o  SWID Tag Identifier Events - This receiving SW-PC.
   Specifically, the SW-PV assigns each SW Request attribute a Request
   ID value that is used intended to convey a
      list of events concerning changes to an endpoint's collection of
      SWID tags.  Affected SWID tags are indicated using SWID tag
      identifier instances (instead be unique within the lifetime of full tags).  When a SWID-PC
      receives a SWID given
   network connection ID as assigned by the SW-PV's Posture Broker
   Server.  In the case where all possible Request attribute requesting an event collection
      using with SWID tag identifier instances, ID values have been
   exhausted within the SWID-PC MUST send a
      SWID Tag Identifier Events attribute (or lifetime of a PA-TNC Error) in
      response.  This attribute also single network connection ID, the
   sender MAY be sent by reuse previously used Request IDs within the SWID-PC same network
   connection that are not being used as Subscription IDs.  (See below
   in
      fulfillment of an active subscription.  A SWID-PV MUST NOT send this attribute.

   o  SWID Tag Inventory - This attribute is used to convey section for an inventory
      expressed using full SWID tags (instead explanation of Subscription ID assignment.)
   In this case of SWID tag identifier
      instances).  When a SWID-PC receives a SWID Request attribute
      requesting an inventory using full SWID tags, ID reuse, Request IDs SHOULD be reused in the SWID-PC MUST
      send
   order of their original use.  For example, if a SWID Tag Inventory attribute (or Request ID of X was
   the first Request ID used within a PA-TNC Error) in
      response.  This attribute also MAY particular network connection and
   if the Request IDs are exhausted, X will be sent by the SWID-PC in
      fulfillment of an active subscription.  A SWID-PV MUST first reused Request
   ID.  In other words, a SW-PC SHOULD NOT send
      this attribute.

   o  SWID Tag Events - This attribute is used to convey a list of
      events concerning changes to an endpoint's collection of SWID
      tags.  Affected SWID tags are indicated using full SWID tags
      (instead of SWID tag identifier instances).  When a SWID-PC
      receives use a SWID given Request attribute requesting an event collection
      using full SWID tags, the SWID-PC MUST send ID value
   more than once within a SWID Tag Events
      attribute (or persistent connection between a PA-TNC Error) given Posture
   Broker Client-Posture Broker Server pair, but, in response.  This attribute also
      MAY be sent by the SWID-PC in fulfillment of an active
      subscription.  A SWID-PV MUST NOT send this attribute.

   o  Subscription Status Request - This attribute case where
   reuse is used necessary due to request a
      SWID-PC send a summary exhaustion of all possible ID values, the active subscriptions it has
      where SW-PC
   SHOULD structure the requesting party is reuse to maximize the subscriber. time between original and
   subsequent use.  The SWID-PC MUST
      respond with a Subscription Status Response (or Request ID value is included in a PA-TNC Error).
      A SWID-PC MUST NOT send this attribute.

   o  Subscription Status SW Response - This
   attribute is used directly responding to convey
      information about the active subscriptions that a SWID-PC has for
      a given subscriber.  A SWID-PV MUST NOT send this attribute.

   o  PA-TNC Error - This is the standard PA-TNC Error attribute as
      defined in PA-TNC [RFC5792] and is used SW Request to indicate that an error which SW
   Request was encountered during a SWID Attribute exchange.  It MUST received and caused the response.  Request IDs can be sent
      by a SWID-PC
   randomly generated or sequential, as long as values are not repeated
   per the rules in response this paragraph.  SW-PCs are not required to a SWID check
   for duplicate Request in IDs.

   In the case where that a SW Request requests the
      SWID-PC encounters establishment of a fatal error
   subscription and the receiving SW-PC agrees to that subscription, the
   Request ID of that SW Request (i.e., an error the establishing request of the
   subscription) becomes that prevents
      further processing subscription's Subscription ID.  All
   attributes sent in fulfillment of an exchange) relating to this subscription include a flag
   indicating that the attribute
      exchange. fulfills a subscription and the
   subscription's Subscription ID.  A SWID-PV SW-PV MUST NOT send this attribute.  The SWID-PC
      MUST then ignore the erroneous attribute after reuse a PA-TNC Error
      attribute is sent (i.e., do not attempt Request ID
   value in communicating to act on an attribute a given SW-PC while that generated Request ID is also
   serving as a PA-TNC Error beyond sending the PA-TNC Error). Subscription ID for an active subscription with that SW-
   PC.  In the case where the SWID-PV experiences a fatal error, it MUST
      ignore the erroneous attribute without sending SW-PC receives a PA-TNC Error
      attribute.  It MAY take other actions in response to the error,
      such as logging SW Request from a given SW-
   PV where that Request ID is also the cause Subscription ID of an active
   subscription with that SW-PV, the error, or even taking actions to
      isolate the endpoint

   Because one SW-PC MUST respond with a PA-TNC
   Error attribute with an error code of SW_SUBSCRIPTION_ID_REUSE_ERROR.
   Note that this error does not cancel the SWID Tag Identifier Inventory, SWID Tag Identifier
   Events, SWID Tag Inventory, or SWID Tag Events attributes is expected
   to be sent indicated subscription.

   Subscription Status Requests and Subscription Status Responses do not
   include Request IDs.

4.9.  SW Request

   A SW-PV sends this attribute to a SWID-PV in direct response SW-PC to a SWID Request
   attribute or in fulfillment of an active subscription, those four
   attribute types are frequently referred to collectively in this
   document as "SWID Response" attributes.

   All SWID-PVs MUST be capable of sending SWID Requests and be capable
   of receiving and processing all SWID Response attributes as well as
   PA-TNC Error attributes.  All SWID-PCs MUST be capable of receiving
   and processing SWID Requests and be capable of sending all types of
   SWID Response attributes as well as PA-TNC Error attributes.  In
   other words, both SWID-PVs and SWID-PCs are required to support their
   role in exchanges using any of the attribute types defined in this
   section.  SWID-PVs MUST ignore any SWID Request attributes that they
   receive.  SWID-PCs MUST ignore any SWID Response attributes or PA-TNC
   Error attributes request that they receive.

4.5.  SWID Attribute Exchanges

   A SWID Attribute Exchange is used to provide the SWID-PV with a SWID
   tag SW-PC
   send software inventory or event collection from information to the queried endpoint.

       +-------------+                      +--------------+ SW-PV.  A SW-PC MUST NOT
   send this attribute.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SWID-PC  Flags        |       Software Identifier Count               |   SWID-PV
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time
       +-------------+                      +--------------+                       Request ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Earliest EID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
             |<-----------SWID Request-------------|   Software Identifier Length  |    Software ID (var length)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7: SW Request Attribute

   +---------------+---------------------------------------------------+
   | Field         | Description                                       |            SWID Response*
   +---------------+---------------------------------------------------+
   | Flags: Bit 0  |
             |-----------------or----------------->| If set (1), the SW-PC MUST delete all             |
   |             PA-TNC Error - Clear       | subscriptions established by the requesting SW-PV |
   | Subscriptions |           V

     *SWID Response is one of the following: SWID Tag Identifier
      Inventory, SWID Tag Identifier Events, SWID Tag Inventory,
      or SWID Tag Events.

    Figure 5: SWID Attribute Exchange (Direct Response (barring any errors).                             |
   |               |                                                   |
   | Flags: Bit 1  | If set (1), in addition to SWID Request)

   In this exchange, the SWID-PV indicates responding to the SWID-PC, via a SWID
   Request,      |
   | - Subscribe   | request as described, the nature of SW-PC MUST establish a  |
   |               | subscription with parameters matching those in    |
   |               | the information it wishes to receive
   (inventory vs. events, full or targeted) and how it wishes request attribute (barring any errors).       |
   |               |                                                   |
   | Flags: Bit 2  | If unset (0), the
   returned SW-PC's response MUST consist   |
   | - Result Type | of complete software inventory to be expressed (full tags or tag identifier
   instances).  The SWID-PC responds with the requested information
   using evidence records   |
   |               | and thus the appropriate attribute type.  A single SWID Request response MUST
   only lead to be a single SWID Response Software          |
   |               | Inventory, a Software Events, or a PA-TNC Error that is in direct
   response to that request.

   In addition, if there is an active subscription on   |
   |               | attribute. If set (1), the endpoint, response MUST consist  |
   |               | of Software Identifiers and thus the
   SWID-PC sends response     |
   |               | MUST be a SWID Response to the SWID-PV following Software Identifier Inventory, a change event
   on the endpoint in fulfillment of that subscription.  Such an
   exchange is shown in Figure 6.

            +-------------+                +--------------+        |  SWID-PC
   |               |   SWID-PV Software Identifier Events, or a PA-TNC Error     |  Time
            +-------------+                +--------------+
   |               | attribute.                                        |
   |
    <Change Event>|               |                                                   |
                  |-------SWID Response(s)*------>|
   | Flags: Bit    | Reserved for future use. This field MUST be set   |
   |

     *SWID Response is one of the following: SWID Tag Identifier
      Inventory, SWID Tag Identifier Events, SWID Tag Inventory,
      or SWID Tag Events.

      Figure 6: SWID Attribute Exchange (In Fulfillment of an Active
                               Subscription)

   Note that, unlike direct responses 3-7 -         | to a SWID Request, a single change
   event can precipitate multiple SWID Responses, but only if all but
   the last of those SWID Responses convey partial lists of event
   records, zero on transmission and ignored upon          |
   | Reserved      | reception.                                        |
   |               |                                                   |
   | Software      | A 3-byte unsigned integer indicating the last of those SWID Responses conveys a complete list number   |
   | Identifier    | of event records.  (That is, the initial responses are partial lists
   and the last response Software Identifiers that follow. If this      |
   | Count         | value is the remainder of the relevant event records,
   completing the delivery of all relevant events at the time of the
   change event.)  A single Change Event MUST NOT be followed by
   multiple SWID Response or PA-TNC Error attributes in any combination
   except as noted earlier in non-zero, this paragraph.

   All SWID-PVs and SWID-PCs MUST support both exchanges.  In
   particular, SWID-PCs MUST be capable of pushing a SWID Response to a
   SWID-PV immediately upon detection of is a change to the endpoint's SWID
   tag collection in fulfillment of established SWID-PV subscriptions, targeted request, as |
   |               | described in Section 3.8.

4.6.  SWID Message 3.3.  The Software           |
   |               | Identifier Length and Attributes for PA-TNC Attribute Enumeration

   PA-TNC attribute types Software ID fields are identified      |
   |               | repeated, in order, the PA-TNC Attribute Header
   (see Section 4.2) via the Attribute Type Vendor ID and Attribute Type
   fields.  Table 4 identifies the appropriate values for these fields
   for each attribute type used within the SWID Message and Attributes
   for PA-TNC protocol.

   +--------------+----------+------------+----------------------------+
   | Attribute    | PEN number of times indicated | Integer
   | Description               | in this field. In the case where Software         | Name
   |               | Identifiers are present, the SW-PC MUST only      |
   |
   +--------------+----------+------------+----------------------------+               | SWID Request respond with software inventory evidence records  | 0x000000
   | 0x00000011               | Request from a SWID-PV or Software Identifiers that correspond to the    |
   |               | identifiers the SW-PV provided in this attribute  |
   |               | (or with a SWID-PC for the SWID-PC PA-TNC Error attribute).  This field   |
   |               | value MAY be 0, in which case there are no        |
   |               | instances of the Software Identifier Length and   | to provide a SWID tag
   |               | Software ID fields. In this case, the SW-PV is    |
   |               | indicating an interest in all software inventory or event list  |
   | SWID Tag               | 0x000000 evidence records on the endpoint (i.e., this is   | 0x00000012
   | A collection of SWID tag               | not a targeted request).                          | Identifier
   |               |                                                   | identifier instances sent
   | Request ID    | Inventory A value that uniquely identifies this SW Request  |
   |               | from a SWID-PC.            | particular SW-PV.                          | SWID Tag
   | 0x000000               | 0x00000013                                                   | A collection of events
   | Earliest EID  | Identifier In the case where the SW-PV is requesting         |
   |               | impacting software events, this field contains the endpoint's EID      |
   | Events               | value of the earliest event the SW-PV wishes to   |
   | SWID tag collection, where               | have reported. (Note - the report will be         |
   |               | inclusive of the event with this EID value.) In   | impacted SWID tags are
   |               | the case where the SW-PV is requesting an         |
   |               | indicated using SWID tag inventory, then this field MUST be 0.             |
   |               | (0x00000000) In the case where this field is non- |
   | identifier instances.      |
   | SWID Tag     | 0x000000 | 0x00000014 | A collection of SWID tags               |
   | Inventory zero, the SW-PV is requesting events and the SW-  |
   |               | sent from PC MUST respond using a SWID-PC.       |
   | SWID Tag     | 0x000000 | 0x00000015 Software Events, Software | A collection of events
   |               | Events Identifier Events, or a PA-TNC Error attribute.   |
   |               | impacting In the endpoint's   |
   |              |          |            | SWID tag collection, case where this field is zero, the SW-PV   |
   |               |          |            | impacted SWID tags are     |
   | is requesting an inventory and the SW-PC MUST     |
   |               | indicated respond using full SWID  |
   |              |          |            | tags.                      |
   | Subscription | 0x000000 | 0x00000016 | A request for a list of Software Inventory, a Software    |
   | Status       |          |            | SWID-PV's active               | Identifier Inventory, or a PA-TNC Error           | Request
   |               | attribute.                                        | subscription.
   |               | Subscription                                                   | 0x000000
   | 0x00000017 Software      | A list of a SWID-PV's      |
   | Status       |          |            | active subscriptions.      |
   | Response 2-byte unsigned integer indicating the length   |
   | Identifier    | in bytes of the Software ID field.                |
   | Reserved Length        | 0x000000                                                   | 0x00000018
   | These attribute types are               |                                                   |
   | Software ID   | - A string containing the Software Identifier value | reserved for future use in
   |               | from a software inventory evidence record. This   |
   | 0x0000001F               | revisions field value MUST be normalized to SWID Message  |
   |              |          |            | and Attributes for PA-TNC. |
   | PA-TNC Error Network Unicode | 0x000000
   | 0x00000008               | An error attribute format, as      |
   |              |          |            | defined described in the PA-TNC      |
   | Section 4.7.  This string |
   |               | specification [RFC5792]. MUST NOT be NULL terminated.                      |
   +--------------+----------+------------+----------------------------+
   +---------------+---------------------------------------------------+

                   Table 4: SWID 5: SW Request Attribute Enumeration

4.7.  Normalization of Text Encoding

   SWID tags do not have a required encoding format. Fields

   The 2009 ISO SWID
   specification states SW-PV sends the SW Request attribute to a SW-PC to request the
   indicated information.  Note that "For encoding purposes, between the use of utf-8 is Result Type flag and
   the suggested methodology for software identification tags...", but
   leaves implementers free Earliest EID field, the SW-PC is constrained to use different encodings if this makes
   sense a single possible
   SW Response attribute type (or a PA-TNC Error attribute) in their local environment.  As such, implementers of its
   response to the SWID
   Message request.

   The Subscribe and Attributes Clear Subscription flags are used to manage
   subscriptions for PA-TNC specification cannot assume any
   specific encoding of SWID tag fields (although, in most current
   examples of SWID tags, SWID tag creators have followed the suggestion
   of using UTF-8 encodings).  Similarly, sometimes requesting SW-PV on the SWID Message and
   Attributes for PA-TNC specification requires receiving SW-PC.
   Specifically, an attribute with the use of data taken
   from other sources, such Subscribe flag set seeks to
   establish a path from new subscription by the endpoint's file system, and
   different platforms might use different encodings for this
   information.  In order requesting SW-PV to ensure the ability given SW-
   PC, while an attribute with the Clear Subscription flag seeks to consistently and
   reliably compare information sent using
   delete all existing subscriptions by the SWID Message and
   Attributes for PA-TNC exchange, certain field values (identified
   explicitly in requesting SW-PV on the attribute definitions
   given SW-PC.  Note that, in the following sections) latter case, only the subscriptions
   associated with the Connection ID and the Posture Validator ID of the
   requester are required to undergo normalization prior to their inclusion deleted as described in an Section 3.6.3.  A newly
   established subscription has the parameters outlined in the Request
   attribute.

   In order  Specifically, the Result Type flag indicates the type of
   result to ensure consistency send in fulfillment of transmitted attributes, a field
   requiring normalization, as indicated in its description, and only
   such fields MUST be normalized to Network Unicode format as defined
   in RFC 5198 [RFC5198].  Network Unicode format defines a refinement
   of UTF-8 that ensures a normalized expression the subscription, the value of characters.  SWID-
   PCs and SWID-PVs MUST NOT perform conversion and normalization on any the
   Earliest EID field values except those specifically identified in indicates whether the following
   sections.

4.8.  Request IDs

   All SWID Request fulfillment attributes MUST include a Request ID value.  The
   Request ID field provides list
   inventories or events, and the fields describing Software Identifiers
   (if present) indicate if and how a value subscription is targeted.  In the
   case that identifies a given the SW-PC is unable or unwilling to comply with the SW-PV's
   request
   relative to other requests between establish or clear subscriptions, the SW-PC MUST respond
   with a SWID-PV and PA-TNC Error attribute with the receiving SWID-
   PC.  Specifically, SW_SUBSCRIPTION_DENIED_ERROR
   error code.  (Note that if the SWID-PV assigns each SWID Request attribute a
   Request ID value SW-PV requests that is intended to subscriptions be unique within
   cleared but has no existing subscriptions, this is not an error.)

   An attribute requesting the lifetime establishment of a given network connection ID subscription is
   effectively doing double-duty, as assigned by it is a request for an immediate
   response from the SWID-PV's Posture
   Broker Server.  In SW-PC in addition to setting up the case where all possible Request ID values have
   been exhausted within subscription.
   Assuming the lifetime of a single network connection ID, SW-PC is willing to comply with the sender MAY reuse previously used Request IDs within subscription it MUST
   send an appropriate response attribute to a request with the same
   network connection that are not being used as Subscription IDs.  (See
   below in this section for an explanation
   Subscribe flag set containing all requested information.  The same is
   true of the Clear Subscription ID
   assignment.)  In this case of Request ID reuse, Request IDs SHOULD be
   reused in flag - assuming there is no error the order of their original use.  For example, if
   SW-PC MUST generate a Request
   ID response attribute without regard to the
   presence of X was this flag in addition to clearing its subscription list.

   Both the first Request ID used within a particular network
   connection Subscribe and if the Request IDs are exhausted, X will Clear Subscription flags MAY be the first
   reused Request ID.  In other words, a SWID-PC SHOULD NOT use set in a given
   single SW Request ID value more than once within a persistent connection
   between a given Posture Broker Client-Posture Broker Server pair,
   but, in attribute.  In the case where reuse this request is necessary due to exhaustion of
   possible ID values, the SWID-PC SHOULD structure
   successful, the reuse end result MUST be equivalent to
   maximize the time between original SW-PC clearing
   its subscription list for the given SW-PV first and subsequent use.  The Request
   ID value is included in then creating a response attribute directly responding to
   this SWID Request to indicate which SWID Request was received and
   caused
   new subscription in accordance with the response.  Request IDs can be randomly generated or
   sequential, as long as values are request parameters.  (In
   other words, do not repeated per first create the rules in this
   paragraph.  SWID-PCs are not required to check for duplicate Request
   IDs.

   In new subscription and then clear
   all the case subscriptions including the one that a SWID Request requests the establishment of a
   subscription and the receiving SWID-PC agrees to that subscription, was just created.)  In
   the Request ID of case that SWID Request (i.e., the establishing request
   of requested actions are successfully completed, the subscription) becomes that subscription's Subscription ID.
   All attributes sent in fulfillment of this subscription include
   SW-PC MUST respond with a
   flag indicating that the SW Response attribute.  (The specific type
   of SW Response attribute fulfills a subscription and depends on the
   subscription's Subscription ID.  A SWID-PV MUST NOT reuse a Request
   ID value in communicating to a given SWID-PC while that Request ID is
   also serving Result Type and Earliest EID
   fields, as a Subscription ID for an active subscription with
   that SWID-PC. described above.)  In the case where there is a SWID-PC receives a SWID Request failure
   that prevents some part this request from completing, the SW-PC MUST
   NOT add a given SWID-PV where that Request ID is also new subscription, MUST NOT clear the Subscription
   ID of an active subscription with that SWID-PV, old subscriptions, and
   the SWID-PC SW-PC MUST respond with a PA-TNC Error attribute with an error code of
   SWID_SUBSCRIPTION_ID_REUSE_ERROR.  Note that this error does not
   cancel attribute.  In other
   words, the indicated subscription.

   Subscription Status Requests and Subscription Status Responses do not
   include Request IDs.

4.9.  SWID Request

   A SWID-PV sends this attribute to SW-PC MUST NOT partially succeed at implementing such a SWID-PC
   request; either both actions succeed, or neither succeed.

   The Earliest EID field is used to request that indicate whether the SWID-
   PC send SWID tag-based information to SW-PV is
   requesting an inventory or event list from the SWID-PV. SW-PC.  A SWID-PC MUST
   NOT send this attribute.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 value of 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Flags        |       Tag ID Count                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Request ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |
   (0x00000000) represents a request for inventory information.
   Otherwise, the SW-PV is requesting event information.  For Earliest
   EID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Tag Creator Length          | Tag Creator (variable length) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unique Software ID Length   |Unique Software ID (var length)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 7: SWID Request Attribute

   +---------------+---------------------------------------------------+
   | Field         | Description                                       |
   +---------------+---------------------------------------------------+
   | Flags: Bit 0  | If set (1), values other than 0, the SWID-PC SW-PC's response MUST delete all           |
   | - Clear       | subscriptions established by the requesting SWID- |
   | Subscriptions | PV (barring any errors).                          |
   | Flags: Bit 1  | If set (1), respond with event
   records, as described in addition to responding to Section 3.5.  Note that the      |
   | - Subscribe   | request as described, the SWID-PC MUST establish  |
   |               | does not
   identify a subscription with parameters matching those particular EID Epoch, since responses can only include
   events in  |
   |               | the request attribute (barring any errors).       |
   | Flags: Bit 2  | If unset (0), SW-PC's current EID Epoch.

   The Software Identifier Count indicates the SWID-PC's response MUST consist |
   | - Result Type | number of complete SWID tags and thus Software
   Identifiers in the response MUST  |
   |               | be a SWID Tag Inventory, a SWID Tag Events, or a  |
   |               | PA-TNC Error attribute. If set (1), the response  |
   |               | MUST consist of SWID tag identifier instances and |
   |               | thus the response MUST be a SWID Tag Identifier   |
   |               | Inventory, a SWID Tag Identifier Events, or a PA- |
   |               | TNC Error attribute.                              |
   | Flags: Bit    | Reserved for future use.  This field MUST number might be set   |
   | 3-7 -         | to zero on transmission any value between
   0 and ignored upon          |
   | Reserved      | reception.                                        |
   | Tag ID Count  | 16,777,216, inclusive.  A 3-byte unsigned integer indicating single Software Identifier is
   represented by fields: Software Identifier Length and Software ID.
   The Software Identifier Length field indicates the number   |
   |               | of tag identifiers that follow. If this value is  |
   |               | non-zero, this is bytes
   allocated to Software ID field.  The Software Identifier field
   contains a targeted request, Software Identifier as          |
   |               | described describe in Section 3.4. This field is a 3-byte  |
   |               | unsigned integer. 3.2.  The Tag Creator Length, Tag     |
   |               | Creator, Unique Software ID Length, and Unique    |
   |               |
   presence of one or more Software ID fields are repeated, in order, Identifiers is used by the    |
   |               | number SW-PV to
   indicate a targeted request, which seeks only inventories of times indicated in this field. In the   |
   |               | case where tag identifiers are present, or
   events affecting software corresponding to the SWID- |
   |               | PC given identifiers.
   The SW-PC MUST only respond with SWID tags or tag        |
   |               | identifier instances records that correspond to the       |
   |               | identifiers match the SWID-PV Software
   Identifiers provided in the SW-PVs SW Request attribute.

4.10.  Software Identifier Inventory

   A SW-PC sends this          |
   |               | attribute (or with to a PA-TNC Error attribute).     |
   |               | This field value MAY be 0, SW-PV to convey the inventory of
   the endpoint's Software Inventory Evidence Collection expressed using
   Software Identifiers.  This list might represent a complete inventory
   or a targeted list of records, depending on the parameters in which case there    |
   |               | are no instances the SW-
   PV's request.  A SW-PV MUST NOT send this attribute.  The SW-PC
   either sends this attribute in fulfillment of an existing
   subscription where the Tag Creator Length, Tag   | establishing request has a Result Type of 1
   and the Earliest EID is zero, or in direct response to a SW Request
   attribute where the Result Type is 1 and the Earliest EID is zero.

                        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        | Creator, Unique         Software Identifier Count             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Request ID Length, and Unique Copy / Subscription ID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        EID Epoch                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Last EID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Data Model Type|   Software IdentifierLength   |SW ID fields. In this case, the SWID-PV is  | (var len)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Record ID Length       | indicating an interest in all SWID tags on the  Record ID (variable length)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 8: Software Identifier Inventory Attribute

   +--------------+----------------------------------------------------+
   | Field        | endpoint (i.e., this is not a targeted request). Description                                        |
   +--------------+----------------------------------------------------+
   | Request ID Flags: Bit 0 | A value In the case that uniquely identifies this SWID attribute is sent in         |
   | -            | Request from fulfillment of a particular SWID-PV. subscription this bit MUST be set |
   | Earliest EID Subscription | (1).  In the case where the SWID-PV that this attribute is requesting SWID a direct  |
   | Fulfillment  | events, response to a SW Request, this field contains the EID value of the  |
   |               | earliest event the SWID-PV wishes to have         |
   |               | reported. (Note - the report will bit MUST be inclusive of unset   |
   |              | the event with this EID value.) In the case where (0).                                               |
   |              | the SWID-PV is requesting an inventory, then this                                                    |
   | Flags: Bit   | Reserved for future use. This field MUST be 0. (0x00000000) In the case where set to |
   | 1-7 -        | this field is non-zero, the SWID-PV is requesting zero on transmission and ignored upon reception.   |
   | Reserved     | events and the SWID-PC MUST respond using a SWID                                                    |
   |              | Tag Events, SWID Tag Identifier Events, or a PA-                                                    |
   | Software     | TNC Error attribute. In the case where this field The number of Software Identifiers that follow.    |
   | Identifier   | This field is zero, the SWID-PV is requesting an inventory   |
   |               | and the SWID-PC MUST respond using a SWID Tag unsigned integer. The Data Model  |
   | Count        | Inventory, a SWID Tag Type, Software Identifier Inventory, or a  |
   |               | PA-TNC Error attribute.                           |
   | Tag Creator   | A 2-byte unsigned integer indicating the length Length, SW ID, Record ID |
   | Length              | Length, and Record ID fields are repeated, in bytes of the Tag Creator field.      |
   | Tag Creator              | A string containing order, the Tag Creator RegID value number of times indicated in this       |
   |              | from within a SWID tag. field. This field value MUST MAY be  |
   |               | normalized to Network Unicode format, as          |
   |               | described 0, in Section 4.7.  This string MUST NOT which case    |
   |              | be NULL terminated. there are no instances of these fields.            |
   | Unique              | A 2-byte unsigned integer indicating the length                                                    |
   | Software Request ID   | in bytes of In the Unique Software ID field. case where this attribute is in direct      |
   | Copy /       | response to a SW Request attribute from a SW-PV,   |
   | Subscription | this field MUST contain an exact copy of the       |
   | ID           | Request ID field from that SW 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 |
   |              | an unsigned 4-byte integer.                        |
   |              |                                                    |
   | Last EID     | The EID of the last event recorded by the SW-PC,   |
   |              | or 0 if the SW-PC has no recorded events. This     |
   |              | field is an unsigned 4-byte integer.               |
   |              |                                                    |
   | Data Model   | A 1-byte unsigned integer containing an identifier |
   | Type         | number from the Software Data Model IANA table     |
   |              | that identifies the data model of the reported     |
   |              | record.                                            |
   |              |                                                    |
   | Software     | A 2-byte unsigned integer indicating the length in |
   | Identifier   | bytes of the SW ID field.                          |
   | Length       |                                                    |
   | Unique              |                                                    |
   | SW ID        | A string containing the Unique ID Software Identifier value from  |
   | Software ID              | within from a SWID tag. software inventory evidence record. This    |
   |              | field value MUST be       |
   |               | normalized to Network Unicode format, as  |
   |              | format, as described in Section 4.7. This string   |
   |              | MUST NOT be NULL terminated.                       |
   |              | NULL terminated.                                                    |
   +---------------+---------------------------------------------------+

                  Table 5: SWID Request Attribute Fields

   The SWID-PV sends
   | Record ID    | A 2-byte unsigned integer indicating the SWID Request attribute to length in |
   | Length       | bytes of the Record ID field.                      |
   |              |                                                    |
   | Record ID    | A string containing the Record Identifier value    |
   |              | from a SWID-PC software inventory evidence record. This    |
   |              | field value MUST be normalized to request Network Unicode  |
   |              | format, as described in Section 4.7. This string   |
   |              | MUST NOT be NULL terminated.                       |
   +--------------+----------------------------------------------------+

          Table 6: Software Identifier Inventory Attribute Fields

   In the indicated information.  Note case that between the Result Type flag
   and the Earliest EID field, the SWID-PC this attribute is constrained to sent in fulfillment of a single
   possible SWID Response
   subscription, the Subscription Fulfillment bit MUST be set (1).  In
   the case that this attribute type (or a PA-TNC Error attribute) is sent in its direct response to a SW
   Request, the request.

   The Subscribe and Clear Subscription flags are used to manage
   subscriptions for the requesting SWID-PV on Fulfillment bit MUST be unset (0).  Note
   that the receiving SWID-PC.
   Specifically, an SW Response attribute with the Subscribe flag set seeks sent in direct response to
   establish a new SW
   Request that establishes a subscription by the requesting SWID-PV (i.e., a subscription's
   establishing request) MUST be treated as a direct response to that SW
   Request (and thus the given
   SWID-PC, while an attribute with the Clear Subscription flag seeks to
   delete all existing subscriptions by the requesting SWID-PV on the
   given SWID-PC.  Note that, in the latter case, Fulfillment bit is unset).  SW
   Response attributes are only the subscriptions
   associated with the Connection ID and, if available, the Posture
   Validator ID of the requester are deleted treated as described being in
   Section 3.8.3.  A newly established fulfillment of a
   subscription has the parameters
   outlined (i.e., Subscription Fulfillment bit set) if they are
   sent following a change event, as shown in the Request attribute.  Specifically, the Result Type
   flag Figure 3.

   The Software Identifier Count field indicates the type number of result Software
   Identifiers present in this inventory.  Each Software Identifier is
   represented by a set of five fields: Data Model Type, Software
   Identifier Length, SW ID, Record ID Length, and Record ID.  These
   fields will appear once for each reported record.

   When responding directly to send a SW Request attribute, the Request ID
   Copy / Subscription ID field MUST contain an exact copy of the
   Request ID field from that SW Request.  When this attribute is sent
   in fulfillment of an existing subscription on this Posture Collector,
   then this field MUST contain the
   subscription, the value Subscription ID of the Earliest fulfilled
   subscription.

   The EID Epoch field indicates whether the fulfillment attributes list inventories or events, and EID Epoch of the fields
   describing tag identifiers (if present) indicate if Last EID value.
   The Last EID field MUST contain the EID of the last recorded change
   event (see Section 3.5 for more about EIDs and how a
   subscription is targeted. recorded events) at
   the time this inventory was collected.  In the case that where there are
   no recorded change events at the SWID-PC is unable or
   unwilling time that this inventory was
   collected, this field MUST contain 0.  These fields can be
   interpreted to comply with indicate that the SWID-PV's request to establish provided inventory (be it full or clear
   subscriptions, the SWID-PC MUST respond with a PA-TNC Error attribute
   with
   targeted) reflects the SWID_SUBSCRIPTION_DENIED_ERROR error code.  (Note that if record of events on the SWID-PV requests that subscriptions be cleared but has no
   existing subscriptions, endpoint after all
   changes up to and including this last event have been accounted for.

4.11.  Software Identifier Events

   A SW-PC sends this is not an error.)

   An attribute requesting the establishment of a subscription is
   effectively doing double-duty, as it is to a request for an immediate
   response from the SWID-PC in addition SW-PV to setting up convey events where the subscription.
   affected records are expressed using Software Identifiers.  A SWID-PC SW-PV
   MUST NOT send an appropriate response attribute to a request
   with the Subscribe flag set containing all requested information. this attribute.  The same is true of the Clear Subscription flag - the SWID-PC MUST
   generate a response attribute without regard to the presence of SW-PC either sends this
   flag attribute
   in addition to clearing its fulfillment of an existing subscription list.

   Both the Subscribe and Clear Subscription flags MAY be set in a
   single SWID Request attribute.  In the case where this request is
   successful, the end result MUST be equivalent to the SWID-PC clearing
   its subscription list for the given SWID-PV first and then creating a
   new subscription in accordance with the establishing
   request parameters.  (In
   other words, do not first create the new subscription has a Result Type is 1 and then clear
   all the subscriptions including the one that was just created.)  In
   the case that the requested actions are successfully completed, the
   SWID-PC MUST respond with Earliest EID is non-zero, or
   in direct response to a SWID Response attribute.  (The specific
   type of SWID Response SW Request attribute depends on where the Result Type is
   1 and the Earliest EID fields, as described above.) is non-zero.

                        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                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          EID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Action       |Data Model Type|  Software Identifier Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |SW ID (var len)|       Record ID Length        |Record ID (var)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 9: Software Identifier Events Attribute

   +--------------+----------------------------------------------------+
   | Field        | Description                                        |
   +--------------+----------------------------------------------------+
   | Flags: Bit 0 | In the case where there is
   a failure that prevents some part this request from completing, the
   SWID-PC MUST NOT add attribute is sent in         |
   | -            | fulfillment of a new subscription, MUST NOT clear the old
   subscriptions, and the SWID-PC subscription this bit MUST respond with a PA-TNC Error
   attribute. be set |
   | Subscription | (1).  In other words, the SWID-PC MUST NOT partially succeed at
   implementing such a request; either both actions succeed, or neither
   succeed.

   The Earliest EID field case that this attribute is used a direct  |
   | Fulfillment  | response to indicate whether the SWID-PV is
   requesting an inventory or event list from the SWID-PC.  A value of 0
   (0x00000000) represents a request SW Request, this bit MUST be unset   |
   |              | (0).                                               |
   |              |                                                    |
   | Flags: Bit   | Reserved for inventory information.
   Otherwise, the SWID-PV is requesting event information.  For Earliest
   EID values other than 0, the SWID-PC's response future use. This field MUST respond with
   event records, as described in Section 3.6.  Note that the request
   does not identify a particular EID Epoch, since responses can only
   include events in the SWID-PC's current EID Epoch.

   The Tag ID be set to |
   | 1-7 -        | zero on transmission and ignored upon reception.   |
   | Reserved     |                                                    |
   |              |                                                    |
   | Event Count indicates the  | The number of tag identifiers events that are reported in the this     |
   |              | attribute. This number might be any value between 0 and 16,777,216,
   inclusive.  A single tag identifier field is represented by four fields:
   Tag Creator Length, Tag Creator, Unique a 3-byte unsigned         |
   |              | integer.  The EID, Timestamp, Action, Data Model   |
   |              | Type, Software Identifier Length, SW ID, Record ID |
   |              | Length, and
   Unique Software ID.  The two length Record ID fields are used to indicate repeated, in      |
   |              | order, the number of bytes allocated to their corresponding string times indicated in this       |
   |              | field.  The
   two string fields, Tag Creator and Unique Software ID, contain copies (An instance of the SWID tag's Tag Creator RegID and Unique ID values,
   respectively, converted and normalized these fields is referred to Network Unicode format, |
   |              | as
   described an "event record" in Section 4.7.  Note that there is no this attribute.  Thus the  |
   |              | Event Count field to indicate a
   particular Instance ID.  Thus, targeted requests request all
   instances of indicates the indicated SWID tags.  The presence number of one or more
   tag identifiers is used by the SWID-PV to indicate a targeted
   request, which seeks only inventories of or events affecting SWID
   tags corresponding to the given identifiers.  The SWID-PC MUST only
   respond with tags that match the tag identifier structures provided
   in the SWID-PVs SWID Request attribute (as described event    |
   |              | records.) This field value MAY be 0, in
   Section 3.3.3) and MUST include all which case |
   |              | there are no instances of matching tags in its
   response.

4.10.  SWID Tag Identifier Inventory

   A SWID-PC sends this attribute to a SWID-PV to convey a list of the
   endpoint's SWID tags expressed using SWID tag identifier instances.
   This list might represent a complete inventory or a targeted list of
   tags, depending on the parameters in these fields.            |
   |              |                                                    |
   | Request ID   | In the SWID-PV's request.  A SWID-
   PV MUST NOT send this attribute.  The SWID-PC either sends case where this attribute in fulfillment of an existing subscription where the
   establishing request has a Result Type of 1 and the Earliest EID is
   zero, or in direct      |
   | Copy /       | response to a SWID SW Request attribute where the
   Result Type is 1 and from a SW-PV,   |
   | Subscription | this field MUST contain an exact copy of the Earliest EID is zero.

                        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
   |               Tag ID Count                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+           | Request ID Copy / Subscription ID field from that SW Request.  In the     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        EID Epoch              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ case where this attribute is sent in fulfillment   |                        Last EID
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              | Tag Creator Length            | Tag Creator (variable length) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Unique Software ID Length     |Unique Software ID (var length of an active subscription, this field MUST contain |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Instance ID Length              | Instance the Subscription ID (var length)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 8: SWID Tag Identifier Inventory Attribute

   +--------------+----------------------------------------------------+
   | Field        | Description of the subscription being      |
   +--------------+----------------------------------------------------+
   | Flags: Bit 0              | In the case that fulfilled by this attribute is sent in attribute.                       |
   | -              | fulfillment of a subscription this bit MUST be set                                                    |
   | Subscription EID Epoch    | (1).  In The EID Epoch of the case that this attribute Last EID value. This field is a direct |
   | Fulfillment              | response to a SWID Request, this bit MUST be unset an unsigned 4-byte integer.                        |
   |              | (0).                                                    |
   | Flags: Bit Last EID     | Reserved for future use. This field MUST be set to The EID of the last event recorded by the SW-PC,   |
   | 1-7 -              | zero on transmission and ignored upon reception. or 0 if the SW-PC has no recorded events. This     |
   | Reserved              | field contains the EID of the SW-PC's last         |
   | Tag ID Count              | The number of tag identifier instances that recorded change event (which might or might not be |
   |              | follow. This field is included as an unsigned integer. The Tag event record in this attribute).    |
   |              | Creator Length, Tag Creator, Unique Software ID                                                    |
   | Last         | Length, Unique Software ID, Instance ID Length, The EID of the last event record that was          |
   | Consulted    | and Instance ID fields are repeated, in order, consulted when generating the event record list    |
   | EID          | number of times indicated included in this field. attribute. This is different from |
   |              | the Last EID field value MAY be 0, in which case there are no   |
   |              | instances of these fields.                         |
   | Request ID   | In the case where if and only if this attribute is in direct       |
   | Copy /              | response to a SWID Request attribute from is conveying a SWID-  |
   | Subscription | PV, this field MUST contain an exact copy partial list of the event     |
   | ID              | Request ID field from that SWID Request.  In the records. See Section 3.5.4 for more on partial     |
   |              | case where this attribute is sent in fulfillment list of event records.                             |
   |              | of an active subscription, this field MUST contain                                                    |
   | EID          | the Subscription ID The EID of the subscription being event in this event record.         |
   |              | fulfilled by this attribute.                                                    |
   | EID Epoch Timestamp    | The EID Epoch of timestamp associated with the Last EID value. This field is event in this    |
   |              | an unsigned 4-byte integer. event record. This timestamps is the SW-PC's best  |
   | Last EID              | The EID understanding of when the last given event recorded by the SWID-PC, occurred.    |
   |              | or 0 if the SWID-PC has no recorded events. This Note that this timestamp might be an estimate.     |
   |              | field is an unsigned 4-byte integer. The Timestamp date and time MUST be represented as |
   | Tag Creator              | A 2-byte unsigned integer indicating the length an RFC 3339 [5] compliant ASCII string in          |
   | Length              | bytes of Coordinated Universal Time (UTC) time with the Tag Creator field.     |
   | Tag Creator              | A string containing additional restrictions that the Tag Creator RegID value 'T' delimiter and |
   |              | from within a SWID tag. This field value the 'Z' suffix MUST be capitalized and fractional  |
   |              | normalized to Network Unicode format, as described |
   |              | in Section 4.7. This string seconds (time-secfrac) MUST NOT be NULL       |
   | included. This  | terminated.
   |              | Unique       | A 2-byte unsigned integer indicating field conforms to the length in date-time ABNF production    |
   | Software ID              | bytes from section 5.6 of RFC 3339 [RFC3339] with the Unique Software ID field.    |
   | Length              | above restrictions.  Leap seconds are permitted    |
   | Unique              | A string containing the Unique ID value from and SW-PVs MUST support them.  The Timestamp       |
   | Software ID              | within a SWID tag. This field value string MUST NOT be NULL terminated or padded in    |
   |              | normalized to Network Unicode format, as described any way. The length of this field is always 20     |
   |              | in Section 4.7. This string MUST NOT be NULL octets.                                            |
   |              | terminated.                                                    |
   | Instance ID Action       | A 2-byte unsigned integer indicating the length The type of event that is recorded in this event   |
   | Length              | bytes record. Possible values are: 1 = CREATION - the    |
   |              | addition of a record to the Instance ID field. endpoint's Software    |
   | Instance ID              | A string containing Inventory Evidence Collection; 2 = DELETION - the Instance ID  |
   |              | removal of a given tag record from the endpoint's Software   |
   |              | instance. The exact value of this field depends on Inventory Evidence Collection; 3 = ALTERATION -    |
   |              | There was an alteration to a record within the party that provides this SWID tag. This field     |
   |              | value MUST be normalized to Network Unicode endpoint's Software Inventory Evidence Collection. |
   |              | format, as described in Section 4.7. This string All other values are reserved for future use and   |
   |              | MUST NOT be NULL terminated.                       |
   +--------------+----------------------------------------------------+

          Table 6: SWID Tag Identifier Inventory Attribute Fields used when sending attributes. In the   |
   |              | case that this attribute is sent in fulfillment of where a
   subscription, the Subscription Fulfillment bit MUST be set (1).  In
   the case SW-PV receives an event record that this attribute is sent in direct response to a SWID
   Request,   |
   |              | uses an action value other than the Subscription Fulfillment bit ones defined   |
   |              | here, it MUST be unset (0).  Note ignore that the SWID response attribute sent event record but SHOULD  |
   |              | process other event records in direct response to a SWID
   Request that establishes a subscription (i.e., a subscription's
   establishing request) MUST be treated this attribute as a direct response to   |
   |              | normal.                                            |
   |              |                                                    |
   | Data Model   | A 1-byte unsigned integer containing an identifier |
   | Type         | number from the Software Data Model IANA table     |
   |              | that
   SWID Request (and thus identifies the Subscription Fulfillment bit is unset).
   SWID Response attributes are only treated as being in fulfillment data model of
   a subscription (i.e., Subscription Fulfillment bit set) if they are
   sent following a change event, as shown in Figure 3.

   The Tag ID Count field indicates the number of tag identifier
   instances present reported     |
   |              | record.                                            |
   |              |                                                    |
   | Software     | A 2-byte unsigned integer indicating the length in this inventory.  Each tag identifier instance is
   represented by a set |
   | Identifier   | bytes of six fields: Tag Creator Length, Tag Creator,
   Unique Software the SW ID Length, Unique Software ID, Instance field.                          |
   | Length       |                                                    |
   |              |                                                    |
   | SW ID Length,
   and Instance ID.  These six fields, collectively referred to as        | A string containing the
   "Tag ID Fields", will appear once for each reported tag instance.
   Note that an endpoint's SWID tag collection might contain multiple
   instances of Software Identifier value  |
   |              | from a single tag (i.e., multiple tag files with software inventory evidence record. This    |
   |              | field value MUST be normalized to Network Unicode  |
   |              | format, as described in Section 4.7. This string   |
   |              | MUST NOT be NULL terminated.                       |
   |              |                                                    |
   | Record ID    | A 2-byte unsigned integer indicating the same tag
   identifier value).  When this occurs, length in |
   | Length       | bytes of the case where that tag is
   reported, then Record ID field.                      |
   |              |                                                    |
   | Record ID    | A string containing the response MUST contain Record Identifier value    |
   |              | from a set of Tag ID Fields for
   each instance of that tag.  (The tag might not software inventory evidence record. This    |
   |              | field value MUST be reported if normalized to Network Unicode  |
   |              | format, as described in Section 4.7. This string   |
   |              | MUST NOT be NULL terminated.                       |
   +--------------+----------------------------------------------------+
           Table 7: Software Identifier Events Attribute Fields

   The first few fields in the
   SWID-PV made a targeted request that does not match that tag's tag
   identifier.)  For example, if Software Identifier Events attribute
   mirror those in the Software Identifier Inventory attribute.  The
   primary difference is that, instead of conveying an endpoint has three copies inventory using
   Software Identifiers, the attribute conveys zero or more event
   records, consisting of tag X, the EID, timestamp, action type, data model
   type, Software Identifier, and Record Identifier of the SWID-PV requests a full inventory, then affected
   software inventory evidence record.

   With regard to the response Timestamp field, it is
   required important to include three sets of Tag ID Fields corresponding to the
   three instances of note that tag.  Only the Instance ID fields are
   different
   clock skew between these three instances.

   When responding directly to a SWID Request attribute, the Request ID
   Copy / Subscription ID field MUST contain SW-PC and SW-PV as well as between different
   SW-PCs within an exact copy enterprise might make correlation of the
   Request ID field from that SWID Request.  When this attribute is sent
   in fulfillment timestamp
   values difficult.  This specification does not attempt to resolve
   clock skew issues, although other mechanisms outside of an existing subscription on this Posture Collector,
   then this field MUST contain the Subscription ID of the fulfilled
   subscription.

   The EID Epoch field indicates the EID Epoch of the Last EID value.
   The Last EID field MUST contain
   specification do exist to reduce the EID impact of clock skew and make
   the last recorded change
   event (see Section 3.6 for timestamp more about EIDs useful for such correlation.  Instead, Software
   Message and recorded events) at Attributes for PA-TNC uses Timestamp value primarily as a
   means to indicate the amount of time this inventory was collected.  In the case where there are
   no recorded change between two events at on a single
   endpoint.  For example, by taking the time that this inventory difference of the times for
   when a record was
   collected, this field MUST contain 0.  These fields removed and then subsequently re-added, one can be
   interpreted get
   an indication as to indicate that how long the provided inventory (be it full or
   targeted) reflects system was without the given record
   (and, thus without the associated software).  Since this will involve
   comparison of events timestamp values all originating on the endpoint after all
   changes up to same system,
   clock skew between the SW-PC and including this last event have been accounted for.

4.11.  SWID Tag Identifier Events

   A SWID-PC sends this attribute to SW-PV is not an issue.  However, if
   the SW-PC's clock was adjusted between two recorded events, it is
   possible for such a SWID-PV calculation to convey events where lead to incorrect understandings
   of the affected SWID tags are expressed using SWID tag identifier
   instances.  A SWID-PV MUST NOT send this attribute.  The SWID-PC
   either sends temporal distance between events.  Users of this attribute in fulfillment field need to
   be aware of an existing
   subscription the possibility for such occurrences.  In the case where
   the establishing request Timestamp values of two events appear to contradict the EID
   ordering of those events (i.e., the later EID has a Result Type is 1
   and an earlier
   timestamp) the recipient MUST treat the Earliest EID is non-zero, or ordering as correct.

   All event records in direct response to a SWID
   Request attribute where Software Identifier Events Attribute are
   required to be part of the Result Type is 1 and same EID Epoch.  Specifically, all
   reported events MUST have an EID from the Earliest same EID Epoch as each
   other, and which is
   non-zero.

                        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                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | the same as the EID Epoch                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | of the Last EID                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | and
   Last Consulted EID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | values.  The SW-PC MUST NOT report events with
   EIDs from different EID                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Timestamp                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Action       | Tag Creator Length            |Tag Creator (v)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Unique Software ID Length   |Unique Software ID (var length)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Instance ID Length         |   Instance ID (var length)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 9: SWID Tag Identifier Events Attribute

   +--------------+----------------------------------------------------+
   | Field        | Description                                        |
   +--------------+----------------------------------------------------+
   | Flags: Bit 0 | In Epochs.

   The Last Consulted EID field contains the case that EID of the last event
   record considered for inclusion in this attribute.  If this attribute is sent in         |
   | -            | fulfillment of
   contains a subscription this bit MUST be partial event set |
   | Subscription | (1).  In the case (as described in Section 3.5.4) this
   field value will differ from that of the Last EID field; if this
   attribute is a direct  |
   | Fulfillment  | response to contains a SWID Request, this bit MUST be unset |
   |              | (0).                                               |
   | Flags: Bit   | Reserved for future use. This field MUST be set to |
   | 1-7 -        | zero on transmission complete event set, the Last EID and ignored upon reception.   |
   | Reserved     |                                                    |
   | Event Count  | The number of Last
   Consulted EID values are identical.

   If multiple events that are reported sent in this     |
   |              | attribute. This field is a 3-byte unsigned         |
   |              | integer.  The EID, Timestamp, Action, Tag Creator  |
   |              | Length, Tag Creator, Unique Software ID Length,    |
   |              | Unique Software ID, Instance ID Length, and        |
   |              | Instance ID fields are repeated, Identifier Events
   attribute, the order in order, which they appear within the attribute is not
   significant.  The EIDs associated with them are used for ordering the     |
   |              | number of times
   indicated events appropriately.  Also note that a single Software
   Identifier might appear multiple times in an attribute, such as if
   multiple events involving the associated record were being reported.

4.12.  Software Inventory

   A SW-PC sends this field. (An       |
   |              | instance attribute to a SW-PV to convey a list of these nine fields inventory
   records.  A SW-PV MUST NOT send this attribute.  The SW-PC either
   sends this attribute in fulfillment of an existing subscription where
   the establishing request had a Result Type of 0 and the Earliest EID
   is referred zero, or in direct response to as an a SW Request attribute where the
   Result Type is 0 and the Earliest EID is zero.

                        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                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | "event record" in this attribute.  Thus the Event                Request ID Copy / Subscription ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            EID Epoch                          | Count field indicates the number of event
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Last EID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Data Model Type|        Record ID Length       |Record ID (var)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | records.) This field value MAY be 0, in which case                          Record Length                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Record (Variable)                        | there are no instances of these fields.
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10: Software Inventory Attribute

   +--------------+----------------------------------------------------+
   | Field        | Description                                        | Request ID
   +--------------+----------------------------------------------------+
   | Flags: Bit 0 | In the case where that this attribute is sent in         |
   | -            | fulfillment of a subscription this bit MUST be set |
   | Subscription | (1).  In the case that this attribute is a direct  |
   | Fulfillment  | response to a SW Request, this bit MUST be unset   |
   |              | (0).                                               |
   |              |                                                    |
   | Flags: Bit   | Reserved for future use. This field MUST be set to |
   | 1-7 -        | zero on transmission and ignored upon reception.   |
   | Reserved     |                                                    |
   |              |                                                    |
   | Record Count | The number of records that follow. This field is a |
   |              | 3-byte unsigned integer. The Data Model Type,      |
   |              | Record Identifier Length, Record ID, 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 SWID SW Request attribute from a SWID- SW-PV,   |
   | Subscription | PV, this field MUST contain an exact copy of the       |
   | ID           | Request ID field from that SWID SW 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 |
   |              | an unsigned 4-byte integer.                        |
   |              |                                                    |
   | Last EID     | The EID of the last event recorded by the SWID-PC, SW-PC,   |
   |              | or 0 if the SWID-PC SW-PC has no recorded events. This     |
   |              | field contains the EID of the SWID-PC's last is an unsigned 4-byte integer.               |
   |              | recorded change event (which might or might not be                                                    |
   | Data Model   | included as A 1-byte unsigned integer containing an event record in this attribute). identifier |
   | Last Type         | The EID of number from the last event record that was Software Data Model IANA table     |
   | Consulted              | consulted when generating that identifies the event record list data model of the reported     |
   | EID              | 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.6.4 for more on partial record.                                            |
   |              | list of event records.                                                    |
   | EID Record ID    | The EID of A 2-byte unsigned integer indicating the event length in this event record. |
   | Timestamp Length       | The timestamp associated with bytes of the event in this Record ID field.                      |
   |              | event record. This timestamps is the SWID-PC's                                                    |
   | Record ID    | best understanding of when A string containing the given event Record Identifier value    |
   |              | occurred. Note that this timestamp might be an from a software inventory evidence record. This    |
   |              | estimate.  The Timestamp date and time field value MUST be normalized to Network Unicode  |
   |              | represented format, as an RFC 3339 [5] compliant ASCII     |
   |              | string described in Coordinated Universal Time (UTC) time    |
   |              | with the additional restrictions that the 'T' Section 4.7. This string   |
   |              | delimiter and the 'Z' suffix MUST NOT be capitalized NULL terminated.                       |
   |              | and fractional seconds (time-secfrac) MUST NOT be                                                    |
   | Record Len   | included. This field conforms to is a 4-byte unsigned integer indicating the date-time   |
   |              | ABNF production from section 5.6 length of RFC 3339 the following software inventory         |
   |              | [RFC3339] with the above restrictions.  Leap evidence record in bytes.                          |
   |              | seconds are permitted and SWID-PVs MUST support                                                    |
   | Record       | A software inventory evidence record as a string.  |
   |              | them. The Timestamp string record MUST NOT be NULL converted and normalized to     |
   |              | terminated or padded Network Unicode format, as described in any way. The length of Section    |
   |              | this field is always 20 octets.                    |
   | Action 4.7. This string MUST NOT be NULL terminated.      |
   +--------------+----------------------------------------------------+

               Table 8: Software Inventory Attribute Fields

   The type Software Inventory attribute contains some number of event software
   inventory evidence records.  Given that is recorded in this event   |
   |              | record. Possible values are: 1 = CREATION - the    |
   |              | addition size of a tag to the endpoint's SWID tag       |
   |              | collection; 2 = DELETION - records can vary
   considerably, the removal length of this attribute is highly variable and, if
   transmitting a tag    |
   |              | from the endpoint's SWID tag collection; 3 =       |
   |              | ALTERATION - There was an alteration complete inventory, can be extremely large.
   Enterprises might wish to a tag file |
   |              | within constrain the endpoint's tag collection. All other    |
   |              | values are reserved for future use and MUST NOT be |
   |              | used when sending attributes. In of Software Inventory
   attributes to targeted requests to avoid over-burdening the case where network
   unnecessarily.

   When copying a  |
   |              | SWID-PV receives an event software inventory evidence record that uses an      |
   |              | action value other than into the Record
   field, the ones defined here, it  |
   |              | MUST ignore that event record but SHOULD process   |
   |              | other event records MUST be converted and normalized to use Network
   Unicode format prior to its inclusion in the record field.

4.13.  Software Events

   A SW-PC sends this attribute as normal.   |
   | Tag Creator  | A 2-byte unsigned integer indicating the length in |
   | Length       | bytes of the Tag Creator field to a SW-PV to convey a list of events
   where the tag affected |
   |              | by the described event.                            |
   | Tag Creator  | software inventory evidence records are expressed
   using full records.  A string containing SW-PV MUST NOT send this attribute.  The SW-PC
   either sends this attribute in fulfillment of an existing
   subscription where the Tag Creator RegID value    |
   |              | from within establishing request has a Result Type of 0
   and the SWID tag affected by Earliest EID is non-zero, or in direct response to a SW
   Request attribute where the described |
   |              | event. Result Type is 0 and the Earliest EID is
   non-zero.

   Note that each record is reported along with its Record Identifier.
   This field value MUST can be normalized used to link reported records to reported Software
   Identifier + Record Identifier pairs.

                        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                  | Network Unicode format, as described in Section
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Request ID Copy / Subscription ID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 4.7. This string MUST NOT be NULL terminated.                           EID Epoch                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Unique                           Last EID                            | A 2-byte unsigned integer indicating the length in
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Last Consulted EID                      | Software ID
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | bytes of the Unique Software ID field of the tag                               EID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Length                            Timestamp                          | affected by the described event.
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Timestamp                          | Unique
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | A string containing the Unique ID value from                            Timestamp                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Software ID                            Timestamp                          | within the SWID tag affected by the described
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Timestamp                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | event.  This field value MUST be normalized to      Action   |Data Model Type|      Record ID Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Record Identifier (Variable Length)            | Network Unicode format, as described in Section
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Record Len                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 4.7. This string MUST NOT be NULL terminated.                  Record (Variable Length)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 11: Software Events Attribute

   +--------------+----------------------------------------------------+
   | Instance ID Field        | A 2-byte unsigned integer indicating Description                                        |
   +--------------+----------------------------------------------------+
   | Flags: Bit 0 | In the length case that this attribute is sent in         |
   | Length -            | bytes fulfillment of the Instance ID field. a subscription this bit MUST be set |
   | Instance ID Subscription | A string containing (1).  In the Instance ID of case that this attribute is a given tag direct  |
   | Fulfillment  | instance. The exact value of response to a SW Request, this field depends on bit MUST be unset   |
   |              | the party that provides this SWID tag. This field (0).                                               |
   |              | value                                                    |
   | Flags: Bit   | Reserved for future use. This field MUST be normalized set to Network Unicode |
   | 1-7 -        | format, as described zero on transmission and ignored upon reception.   |
   | Reserved     |                                                    |
   |              |                                                    |
   | Event Count  | The number of events being reported in Section 4.7. this        |
   |              | attribute. This string field is a 3-byte unsigned         |
   |              | MUST NOT be NULL terminated. integer.  The EID, Timestamp, Action, Data Model   |
   +--------------+----------------------------------------------------+

           Table 7: SWID Tag
   |              | Type, Record Identifier Events Attribute Fields

   The first few Length, Record Identifier, |
   |              | Record Length, and Record fields are repeated, in  |
   |              | order, the SWID Tag Identifier Events attribute
   mirror those number of times indicated in the SWID Tag Identifier Inventory attribute.  The
   primary difference is that, instead this       |
   |              | field. (An instance of conveying these fields is referred to |
   |              | as an inventory using
   tag identifier instances, the attribute conveys zero or more event
   records, including "event record" in this attribute. Thus the EID, timestamp, action type, and tag
   identifier instance of   |
   |              | Event Count field indicates the affected tag.

   With regard to number of event    |
   |              | records.) This field value MAY be 0, in which case |
   |              | there are no instances of these fields.            |
   |              |                                                    |
   | Request ID   | In the Timestamp field, it case where this attribute is important in direct      |
   | Copy /       | response to note that
   clock skew between the SWID-PC and SWID-PV as well as between
   different SWID-PCs within a SW Request attribute from a SW-PV,   |
   | Subscription | this field MUST contain an enterprise might make correlation exact copy of
   timestamp values difficult.  This specification does not attempt to
   resolve clock skew issues, although other mechanisms outside the       |
   | ID           | Request ID field from that SW Request.  In the     |
   |              | case where this attribute is sent in fulfillment   |
   |              | of an active subscription, this
   specification do exist to reduce field MUST contain |
   |              | the impact Subscription ID of clock skew and make
   the timestamp more useful for such correlation.  Instead, SWID
   Message and Attributes for PA-TNC uses Timestamp value primarily as a
   means to indicate the amount of time between two events on a single
   endpoint.  For example, subscription being      |
   |              | fulfilled by taking the difference this attribute.                       |
   |              |                                                    |
   | EID Epoch    | The EID Epoch of the times for
   when a SWID tag was removed and then subsequently re-added, one can
   get an indication as to how long the system was without the given tag
   (and, thus without the associated software).  Since this will involve
   comparison Last EID value. This field is |
   |              | an unsigned 4-byte integer.                        |
   |              |                                                    |
   | Last EID     | The EID of timestamp values all originating on the same system,
   clock skew between last event recorded by the SWID-PC and SWID-PV is not an issue.  However, SW-PC,   |
   |              | or 0 if the SWID-PC's clock was adjusted between two SW-PC has no recorded events, it
   is possible for such a calculation to lead to incorrect
   understandings of the temporal distance between events.  Users of
   this 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 contains the EID ordering of those events (i.e., the later EID has
   an earlier timestamp) the recipient MUST treat the EID ordering SW-PC's last         |
   |              | recorded change event (which might or might not be |
   |              | included as
   correct.

   All an event records record in a Tag Identifier Events Attribute are required
   to be part this attribute).    |
   |              |                                                    |
   | Last         | The EID of the same EID Epoch.  Specifically, all reported events
   MUST have an EID from last event record that was          |
   | Consulted    | consulted when generating the same event record list    |
   | EID Epoch as each other, and which          | included in this attribute. This is
   the same as the EID Epoch of different from |
   |              | the Last EID field value if and Last Consulted EID
   values.  The SWID-PC MUST NOT report events with EIDs from different
   EID Epochs.

   The Last Consulted EID field contains the EID of the last event
   record considered for inclusion in this attribute.  If only if this       |
   |              | attribute
   contains is conveying a partial list of event set (as described in     |
   |              | records. See Section 3.6.4) this
   field value will differ from that 3.5.4 for more on partial     |
   |              | list of the Last EID field; if this
   attribute contains a complete event set, the Last records.                             |
   |              |                                                    |
   | EID and Last
   Consulted          | The EID values are identical.

   If multiple events are sent in a SWID Tag Identifier Events
   attribute, of the order event in which they appear within the attribute is not
   significant. this event record.         |
   |              |                                                    |
   | Timestamp    | The EIDs timestamp associated with them are used for ordering the
   indicated events appropriately.  Also note that a single tag
   identifier instance might appear multiple times event in an attribute, such
   as if multiple events involving the associated tag were being
   reported.

4.12.  SWID Tag Inventory

   A SWID-PC sends this attribute to a SWID-PV to convey a list    |
   |              | event record. This timestamp is the SW-PC's best   |
   |              | understanding of SWID
   tags.  A SWID-PV MUST NOT send this attribute.  The SWID-PC either
   sends when the given event occurred.    |
   |              | Note that this attribute in fulfillment of timestamp might be an existing subscription where
   the establishing request had a Result Type of 0 estimate.     |
   |              | The Timestamp date and the Earliest EID
   is zero, or time MUST be represented as |
   |              | an RFC 3339 [5] compliant ASCII string in direct response to a SWID Request attribute where the
   Result Type is 0 and the Earliest EID is zero.

                        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         | Tag Count                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Request ID Copy / Subscription ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            EID Epoch          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Last EID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Coordinated Universal Time (UTC) time with the     |            Instance ID Length
   |  Instance ID (var length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ additional restrictions that the 'T' delimiter and |                          Tag Length
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+              |                        Tag (Variable) the 'Z' suffix MUST be capitalized and fractional  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 10: SWID Tag Inventory Attribute

   +--------------+----------------------------------------------------+
   | Field              | Description seconds (time-secfrac) MUST NOT be included. This  |
   +--------------+----------------------------------------------------+
   | Flags: Bit 0              | In field conforms to the case that this attribute is sent in date-time ABNF production    |
   | -              | fulfillment from section 5.6 of a subscription this bit MUST be set RFC 3339 [RFC3339] with the    |
   | Subscription              | (1).  In the case that this attribute is a direct above restrictions.  Leap seconds are permitted    |
   | Fulfillment              | response to a SWID Request, this bit and SW-PVs MUST be unset support them.  The Timestamp       |
   |              | (0). string MUST NOT be NULL terminated or padded in    |
   | Flags: Bit              | Reserved for future use. This any way. The length of this field MUST be set to is always 20     |
   | 1-7 -              | zero on transmission and ignored upon reception. octets.                                            |
   | Reserved              |                                                    |
   | Tag ID Count Action       | The number type of tags event that follow. This field is a    |
   | recorded in this event   | 3-byte unsigned integer. The Instance ID Length,
   |              |              | Instance ID, Tag Length, and Tag fields are        |
   |              | repeated, in order, record. Possible values are: 1 = CREATION - the number of times indicated  |
   |              | in this field. This field value MAY be 0 in which    |
   |              | case there are no instances addition of these fields. a record to the endpoint's Software    |
   | Request ID              | In Inventory Evidence Collection; 2 = DELETION - the case where this attribute is in direct  |
   | Copy /              | response to removal of a SWID Request attribute record from a SWID- the endpoint's Software   |
   | Subscription              | PV, this field MUST contain an exact copy of the Inventory Evidence Collection; 3 = ALTERATION -    |
   | ID              | Request ID field from that SWID Request.  In There was an alteration to a record within the     |
   |              | case where this attribute is sent in fulfillment endpoint's Software Inventory Evidence Collection. |
   |              | of an active subscription, this field MUST contain All other values are reserved for future use and   |
   |              | MUST NOT be used when sending attributes. In the Subscription ID of the subscription being   |
   |              | fulfilled by this attribute. case where a SW-PV receives an event record that   |
   | EID Epoch              | The EID Epoch of uses an action value other than the Last EID value. This field is ones defined   |
   |              | an unsigned 4-byte integer. here, it MUST ignore that event record but SHOULD  |
   | Last EID              | The EID of the last process other event recorded by the SWID-PC, records in this attribute as   |
   |              | or 0 if the SWID-PC has no recorded events. This normal.                                            |
   |              | field is an unsigned 4-byte integer.                                                    |
   | Instance ID Data Model   | A 2-byte 1-byte unsigned integer indicating the length in containing an identifier |
   | Length Type         | bytes of number from the Instance ID field. Software Data Model IANA table     |
   |              | that identifies the data model of the reported     |
   |              | record.                                            |
   |              |                                                    | Instance
   | Record ID    | A string containing 2-byte unsigned integer indicating the Instance ID of a given tag length in |
   | Length       | instance. The exact value bytes of this field depends on the Record ID field.                      |
   |              |                                                    |
   | Record ID    | A string containing the party that provides this SWID tag. Record Identifier value    |
   |              | from a software inventory evidence record. This field    |
   |              | field value MUST be normalized to Network Unicode  |
   |              | format, as described in Section 4.7. This string   |
   |              | MUST NOT be NULL terminated.                       |
   | Tag              |                                                    |
   | Record Len   | This is a 4-byte unsigned integer indicating the   |
   |              | length of the following SWID tag record in bytes.           |
   | Tag              |                                                    |
   | Record       | A SWID tag software inventory evidence record as a string. In the case where the      |
   |              | original SWID tag is not expressed using UTF-8  |
   |              | encoding, it The record MUST be converted and normalized to     |
   |              | Network Unicode format, as described in Section    |
   |              | 4.7. However, in the case where the original SWID  |
   |              | tag is expressed using UTF-8 encoding, the SWID    |
   |              | tag MUST be copied to this field without           |
   |              | modification, even if the original SWID tag does   |
   |              | not conform fully to Network Unicode format. This  |
   |              | string MUST NOT be NULL terminated.      |
   +--------------+----------------------------------------------------+

                 Table 8: SWID Tag Inventory 9: Software Events Attribute Fields

   The SWID Tag Inventory attribute contains some number of SWID tags.
   Given that the size of tags can vary considerably, the length fields of this attribute is highly variable and, if transmitting a complete
   inventory, can be extremely large.  Enterprises might wish to
   constrain are used in the use of SWID Tag Inventory attributes to targeted
   requests to avoid over-burdening same way as the network unnecessarily.

   Note that
   corresponding fields of the Instance ID is included in this attribute along previous attributes.  As with the tag.  This is because, unlike the Tag Creator RegID and Unique ID
   fields that make up the tag identifier, the Instance ID cannot always
   Software Inventory attribute, a Software Events attribute can be extracted from fields within
   quite large if many events have occurred following the event
   indicated by a SWID tag. request's Earliest EID.  As such, in order to be
   able to associate a tag file with a given tag identifier instance, it is necessary to include recommended
   that the Instance ID value SW Request attributes only request full records be sent
   (Result Type set to 0) in the attribute.

   When copying a SWID tag into targeted request, thus constraining the Tag field, conversion and
   normalization
   response just to records that match a given set of Software
   Identifiers.

   As with the character encoding happens if and Software Identifier Events Attribute, this attribute MUST
   only if contain event records with EIDs coming from the
   source SWID tag does not use UTF-8 encoding.  In current EID
   Epoch of the case where SW-PC.

   As with the
   source SWID tag is expressed using an encoding other than UTF-8, then
   that tag Software Inventory Attribute, the SW-PC MUST be converted perform
   conversion and normalized normalization of the record.

4.14.  Subscription Status Request

   A SW-PV sends this attribute to use Network Unicode
   format prior a SW-PC to its inclusion in the tag field.  However, in the case
   where request a list of active
   subscriptions for which the source SWID tag requesting SW-PV is expressed in UTF-8, the source tag subscriber.  A
   SW-PC MUST
   be copied to the Tag field without conversion or normalization. NOT send this attribute.

   This
   is true even attribute has no fields.

   A SW-PC MUST respond to this attribute by sending a Subscription
   Status Response attribute (or a PA-TNC Error attribute if the source SWID tag uses UTF-8 but is not fully
   conformant with Network Unicode format.  This is done because any
   conversion or normalization of a full SWID tag it is likely to break any
   cryptographic signatures included in the SWID tag.  As such,
   conversion only happens
   unable to ensure correctly provide a SWID tag is readable for the
   recipient (by ensuring it always uses UTF-8), but is otherwise
   avoided if possible.  Recipients of this attribute can always be
   assured that the Tag field uses UTF-8 format, but cannot depend on
   full Network Unicode format compliance.

4.13.  SWID Tag Events response).

4.15.  Subscription Status Response

   A SWID-PC SW-PC sends this attribute to a SWID-PV SW-PV to convey a report the list of
   events where active
   subscriptions for which the affected SWID tags are expressed using full tags. receiving SW-PV is the subscriber.  A
   SWID-PV SW-
   PV MUST NOT send this attribute.  The SWID-PC either sends this
   attribute in fulfillment of an existing subscription where the
   establishing request has a Result Type of 0 and the Earliest EID is
   non-zero, or in direct response to a SWID Request attribute where the
   Result Type is 0 and the Earliest EID is non-zero.

                        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  |                  Event            Subscription Record Count          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Request ID Copy / Subscription ID               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags         |                           EID Epoch          Software Identifier Count            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Last EID                          Request ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Last Consulted                         Earliest EID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               EID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  Software Identifier Length   |                            Timestamp    Software ID (var length)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 12: Subscription Status Response Attribute

   +-----------------+-------------------------------------------------+
   |                            Timestamp Field           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Description                                     |                            Timestamp
   +-----------------+-------------------------------------------------+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags: Bit 0-7  |                            Timestamp Reserved for future use. This field MUST be set |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Timestamp - Reserved      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to zero on transmission and ignored upon        |      Action
   |        Instance ID Length     |Instance ID (v)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                 |                             Tag Len reception.                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Tag (Variable)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 11: SWID Tag Events Attribute

   +--------------+----------------------------------------------------+                                                 | Field
   | Description Subscription    |
   +--------------+----------------------------------------------------+
   | Flags: Bit 0 | In the case that this attribute is sent in         |
   | -            | fulfillment The number of a subscription this bit MUST be set |
   | Subscription | (1).  In the case records that this attribute is a direct  |
   | Fulfillment  | response to a SWID Request, this bit MUST be unset |
   |              | (0).                                               |
   | Flags: Bit   | Reserved for future use. This field MUST be set to |
   | 1-7 -        | zero on transmission and ignored upon reception.   |
   | Reserved     | follow. |
   | Event Record Count    | The number of events being reported in this        |
   |              | attribute. This field is a 3-byte unsigned         |
   |              | integer.  The EID, Timestamp, Action, Instance ID   |
   |                 | Length, Instance Flags, Software Identifier Count, Request ID, Tag   |
   |                 | Earliest EID, Software Identifier Length, and Tag fields   |
   |                 | Software ID fields are repeated, in order, the number of times  |
   |                 | number of times indicated in this field. (An instance of these     |
   |              | five fields is referred to as an "event record" in |
   |              | this attribute. Thus the Event Count field         |
   |              | indicates the number of event records.) This field   |
   |                 | field value MAY be 0, 0 in which case there are no |
   |                 | instances of these fields.                      |
   | Request ID                 | In the case where this attribute is in direct                                                 |
   | Copy / Flags, Software | response to a SWID Request attribute from a SWID- For each active subscription, these fields      |
   | Subscription Identifier      | PV, this field MUST contain an exact copy of the fields with the    |
   | ID           | Count, Request ID field from that SWID Request.  In  | same name as provided in the subscription's     |
   | ID, Earliest    | case where this attribute is sent in fulfillment establishing request.                           |
   | EID, Software   | 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 |
   |              | an unsigned 4-byte integer. Identifier      |                                                 | Last EID     | The EID of the last event recorded by the SWID-PC,
   | Length, and     |                                                 | or 0 if the SWID-PC has no recorded events. This
   | Software ID     |                                                 | field
   +-----------------+-------------------------------------------------+

               Table 10: Subscription Status Response Fields

   A Subscription Status Response contains the EID of the SWID-PC's last       |
   |              | recorded change event (which might zero or might not be |
   |              | included as an event more subscription
   records.  Specifically, it MUST contain one subscription record in this attribute).    |
   | Last         | The EID of for
   each active subscription associated with the last event record party that was          |
   | Consulted    | consulted when generating the event record list    |
   | EID          | included in this attribute. This is different from |
   |              | sent the Last EID field value if and only if
   Subscription Status Request to which this       |
   |              | attribute is conveying a partial list of event     |
   |              | records. See response.
   As described in Section 3.6.4 for more on partial     |
   |              | list of event records.                             |
   | EID          | The EID of 3.6.2, the event in this event record.         |
   | Timestamp    | The timestamp SW-PC MUST use the requester's
   Connection ID and its Posture Validator ID to determine which
   subscriptions are associated with the event requester.

   A SW-PC MUST send a Subscription Status Response attribute in
   response to a Subscription Status Request attribute.  The only
   exception to this    |
   |              | event record. This timestamps is if the SWID-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 SW-PC experiences an RFC 3339 [5] compliant ASCII     |
   |              | string in Coordinated Universal Time (UTC) time    |
   |              | with the additional restrictions error condition that
   prevents it from correctly populating the 'T'      |
   |              | delimiter and the 'Z' suffix MUST be capitalized   |
   |              | and fractional seconds (time-secfrac) Subscription Status
   Response attribute, in which case it MUST NOT be  |
   |              | included. This field conforms respond with a PA-TNC Error
   attribute appropriate to the date-time     |
   |              | ABNF production from section 5.6 type of RFC 3339       |
   |              | [RFC3339] error experienced.  If there are
   no active subscriptions associated with the above restrictions.  Leap       |
   |              | seconds are permitted and SWID-PVs MUST support    |
   |              | them.  The Timestamp string MUST NOT be NULL       |
   |              | terminated or padded in any way. The length requesting party, the
   Subscription Status Response attribute will consist of     |
   |              | this its Status
   Flags field, a Subscription Record Count field is always 20 octets.                    |
   | Action       | The type with a value of event that is recorded 0, and
   no additional fields.

   Each subscription record included in this event   |
   |              | record. Possible values are: 1 = CREATION - a Subscription Status Response
   attribute duplicates the    |
   |              | addition fields of a tag to SW Request attribute that was
   the endpoint's SWID tag       |
   |              | collection; 2 = DELETION - the removal establishing request of a tag    |
   |              | from the endpoint's SWID tag collection; 3 =       |
   |              | ALTERATION - There was an alteration to a tag file |
   |              | within subscription.  Note that the endpoint's tag collection. All other    |
   |              | values are reserved for future use and MUST NOT be |
   |              | used when sending attributes. In Request ID
   field in the case where a  |
   |              | SWID-PV receives an event record that uses an      |
   |              | action value other than captures the ones defined here, it  |
   |              | MUST ignore that event record but SHOULD process   |
   |              | other event records in this attribute as normal.   |
   | Instance Subscription ID  | A 2-byte unsigned integer indicating associated with the length in |
   | Length       | bytes of
   given subscription record (since the Instance ID field.                    |
   | Instance Subscription ID  | A string containing is the same as
   the Instance Request ID of a given tag |
   |              | instance. The exact value of this field depends on |
   |              | the party establishing request).  Note also that provides this SWID tag. This if the
   establishing request is targeted, then its Record Count field  |
   |              | value MUST will be normalized to Network Unicode        |
   |              | format, as described
   non-zero and, within that subscription record, the Record Namespace
   Length, Record Namespace, Record ID Length, and Record ID fields are
   repeated, in Section 4.7. This string   |
   |              | MUST NOT be NULL terminated.                       |
   | Tag Len      | This is a 4-byte unsigned integer indicating order, the   |
   |              | length number of the following SWID tag times indicated in bytes.         |
   | Tag          | A SWID tag as a string. In the case where Record Count
   field.  As such, each subscription record can be different sizes.  If
   the      |
   |              | original SWID tag establishing request is not expressed using UTF-8     |
   |              | encoding, it MUST be converted and normalized to   |
   |              | Network Unicode format, as described in Section    |
   |              | 4.7. However, in the case where the original SWID  |
   |              | tag targeted (Record Count field is expressed using UTF-8 encoding, 0),
   the SWID    |
   |              | tag MUST be copied to this field without           |
   |              | modification, even if subscription record has no Record Namespace Length, Record
   Namespace, Record ID Length, or Record ID fields.

   When a SW-PV compares the original SWID tag does   |
   |              | not conform fully information received in a Subscription
   Status Response to Network Unicode format. This  |
   |              | string MUST NOT be NULL terminated.                |
   +--------------+----------------------------------------------------+

                 Table 9: SWID Tag Events Attribute Fields

   The fields its own records of active subscriptions it should
   be aware that the SW-PC might be unable to distinguish this attribute are used in SW-PV
   from other SW-PVs on the same way as the
   corresponding fields of the previous attributes. NEA Server.  As with the SWID
   Tag Inventory attribute, a SWID Tag Events attribute can be quite
   large if many events have occurred following the event indicated by a
   request's Earliest EID.  As such, result, it is recommended
   possible that the SWID
   Request attributes only request full tags be sent (Result Type set to
   0) in a targeted request, thus constraining SW-PC will report more subscription records than
   the response just to tags SW-PV recognizes.  For this reason, SW-PVs SHOULD NOT
   automatically assume that match extra subscriptions reported in a given set of tag identifiers.

   As with the SWID Tag Identifier Events Attribute, this
   Subscription Status Response indicate a problem.

4.16.  PA-TNC Error as Used by Software Message and Attributes for PA-
       TNC

   The PA-TNC Error attribute MUST
   only contain event records with EIDs coming from the current EID
   Epoch of the SWID-PC.

   As with the SWID Tag Inventory Attribute, is defined in the SWID-PC MUST perform
   conversion PA-TNC specification
   [RFC5792], and normalization of the SWID tag itself its use here conforms to that specification.  A PA-TNC
   Error can be sent due to any error in the case where
   the source SWID tag is expressed using an encoding other than UTF-8, PA-TNC exchange and MUST NOT perform conversion or normalization of the SWID tag
   itself might
   also be sent in response to error conditions specific to the Software
   Message and Attributes for PA-TNC exchange.  The latter case where the source SWID tag is expressed using UTF-
   8.

4.14.  Subscription Status Request utilizes
   error codes defined below.

   A SWID-PV sends this PA-TNC Error attribute to is sent instead of a SWID-PC SW Response attribute
   due to request a list of
   active subscriptions for which the requesting SWID-PV is factors that prevent the
   subscriber.  A SWID-PC reliable creation of a SW Response.
   As such, a SW-PC MUST NOT send this attribute.

   This attribute has no fields.

   A SWID-PC MUST respond to this attribute by sending a Subscription
   Status Response attribute (or both a PA-TNC Error attribute if it is
   unable to correctly provide and a response).

4.15.  Subscription Status SW
   Response

   A SWID-PC sends this attribute in response to a SWID-P to report single SW Request attribute.

   Table 11 lists the list of
   active subscriptions Error Code values for which the receiving SWID-PV is PA-TNC Error attribute
   specific to the
   subscriber.  A SWID-PV Software Message and Attributes for PA-TNC exchange.
   In all of these cases, the Error Code Vendor ID field MUST NOT send be set to
   0x000000, corresponding to the IETF SMI Private Enterprise Number.
   The Error Information structures for each error type are described in
   the following subsections.

   Note that a message with a Software Message and Attributes for PA-TNC
   attribute might also result in an error condition covered by the
   Standard PA-TNC Error Codes defined in PA-TNC.  For example, a SW
   Attribute might have an invalid parameter, leading to an error code
   of "Invalid Parameter".  In this attribute.

                        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 case, the SW-PC MUST use the
   appropriate PA-TNC Error Code value as defined in Section 4.2.8 of
   PA-TNC specification.

   +-----------------------+-------------------------------------------+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Value      | Flags Description                               |                   Tag ID Count
   +-----------------------+-------------------------------------------+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x00000020            |                          Request ID SW_ERROR. This indicates a fatal error    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Earliest EID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (i.e., an error that precludes the        |       Tag Creator Length
   | Tag Creator (variable length)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ creation of a suitable response           | Unique Software ID Length     |Unique Software ID (var length)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 12: Subscription Status Response Attribute

   +------------------+------------------------------------------------+
   | Field                       | Description attribute) other than the errors          |
   +------------------+------------------------------------------------+
   | Flags: Bit 0-7 -                       | Reserved for future use. This field MUST be described below but still specific to the |
   | Reserved                       | set to zero on transmission and ignored upon processing of SW Attributes. The          |
   |                       | reception. Description field SHOULD contain          |
   | Subscription                       | The number of subscription records that additional diagnostic information.        |
   | Record Count                       | follow.                                           |
   | 0x00000021            | SW_SUBSCRIPTION_DENIED_ERROR. This field is        |
   |                       | indicates that the SW-PC denied the SW-   |
   |                       | PV's request to establish a 3-byte unsigned subscription. |
   |                       | integer. The Flags, Tag ID Count, Request ID, Description field SHOULD contain      |
   |                       | Earliest EID, Tag Creator Length, Tag Creator, additional diagnostic information.        |
   |                       | Unique Software ID Length, and Unique Software                                           |
   | 0x00000022            | ID fields are repeated, in order, the number SW_RESPONSE_TOO_LARGE_ERROR. This         |
   |                       | of times indicated in this field. This field indicates that the SW-PC's response to    |
   |                       | value MAY the SW-PV's request was too large to be 0 in which case there are no   |
   |                       | instances of these fields. serviced. The error information structure |
   | Flags, Tag ID                       | For each active subscription, these fields indicates the largest possible size of a  |
   | Count, Request                       | contain an exact copy of the fields with response supported by the SW-PC (see      |
   | ID, Earliest                       | same name as provided in the subscription's Section 4.16.2).  The Description field   |
   | EID, Tag Creator                       | establishing request. SHOULD contain additional diagnostic      |
   | Length, Tag                       | information.                              |
   | Creator, Unique                       |                                           |
   | Software ID 0x00000023            | SW_SUBSCRIPTION_FULFILLMENT_ERROR. This   |
   |                       | Length, and indicates that the SW-PC experienced an   |
   |                       | Unique Software error fulfilling a given subscription.    |
   |                       | ID The error information includes the        |
   |                       |
   +------------------+------------------------------------------------+

               Table 10: Subscription Status Response Fields

   A Subscription Status Response contains zero or more subscription
   records.  Specifically, it MUST contain one subscription record for
   each active subscription associated with ID of the party relevant           |
   |                       | subscription, as well as a sub-error that sent |
   |                       | describes the
   Subscription Status Request to which this attribute is a response.
   As described in Section 3.8.2, the SWID-PC MUST use the requester's
   Connection ID and, if available, its Posture Validator ID to
   determine which subscriptions are associated with the requester.

   A SWID-PC MUST send a Subscription Status Response attribute in
   response to a Subscription Status Request attribute.  The only
   exception to this is if nature of the SWID-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 SW- |
   |                       | PC experienced.  If there are
   no active subscriptions associated with the requesting party, the
   Subscription Status Response attribute will consist of its Status
   Flags field, a Subscription Record Count field with a value of 0, The SW-PC and
   no additional fields.

   Each subscription record included in a Subscription Status Response
   attribute duplicates SW-PV MUST  |
   |                       | treat the fields of a SWID Request attribute identified subscription as      |
   |                       | cancelled.                                |
   |                       |                                           |
   | 0x00000024            | SW_SUBSCRIPTION_ID_REUSE_ERROR. This      |
   |                       | indicates that was the establishing request of SW-PC received a subscription.  Note that the SW    |
   |                       | Request ID
   field in the record captures the Subscription ID associated with the from a given subscription record (since SW-PV where the Subscription      |
   |                       | Request ID of that SW Request is the same          |
   |                       | currently used as the Request Subscription ID of the establishing request).  Note also  |
   |                       | an active subscription with that if SW-PV.   |
   |                       | This error does not cancel the
   establishing request is targeted, then its Tag ID Count field will be
   non-zero and, within that subscription record, identified |
   |                       | subscription.                             |
   |                       |                                           |
   | 0x00000025-0x0000002F | RESERVED. These Error Codes are reserved  |
   |                       | for use by future revisions of the Tag Creator
   Length, Tag Creator, Unique        |
   |                       | Software ID Length, Message and Unique Attributes for PA-   |
   |                       | TNC specification. Any PA-TNC Error       |
   |                       | attribute using one of these Error Codes  |
   |                       | MUST be treated as indicating a fatal     |
   |                       | error on the sender without further       |
   |                       | interpretation.                           |
   +-----------------------+-------------------------------------------+

   Table 11: PA-TNC Error Codes for Software
   ID fields are repeated, in order, Message and Attributes for
                                  PA-TNC

   The following subsections describe the number of times indicated structures present in the Tag ID Count field.  As such, each subscription record can be
   different sizes.  Likewise, if
   Error Information fields.

4.16.1.  SW_ERROR, SW_SUBSCRIPTION_DENIED_ERROR and
         SW_SUBSCRIPTION_ID_REUSE_ERROR Information

   The SW_ERROR error code indicates that the establishing request sender (the SW-PC) has
   encountered an error related to the processing of a SW Request
   attribute but which is not
   targeted (Tag ID Count field covered by more specific SW error codes.
   The SW_SUBSCRIPTION_DENIED_ERROR is 0), used when the SW-PV requests to
   establish a subscription record has no
   Tag Creator Length, Tag Creator, Unique Software ID Length, or Unique
   Software ID fields.

   When a SWID-PV compares the information received in a Subscription
   Status Response to its own records of active clear all subscriptions it should
   be aware that from the SWID-PC might be given
   SW-PV, but the SW-PC is unable or unwilling to distinguish comply with this SWID-PV
   from other SWID-PVs on the same NEA Server.  As a result, it
   request.  The SW_SUBSCRIPTION_ID_REUSE_ERROR is
   possible that used when the SWID-PC will report more subscription records than
   the SWID-PV recognizes.  For this reason, SWID-PVs SHOULD NOT
   automatically assume that extra subscriptions reported in SW-PC
   receives a
   Subscription Status Response indicate SW Request whose Request ID duplicates a problem.

4.16.  PA-TNC Error as Used by SWID Message and Attributes for PA-TNC

   The PA-TNC Error attribute is defined in Subscription ID
   of an active subscription with the PA-TNC specification
   [RFC5792], and its use here conforms to that specification.  A PA-TNC
   Error can be sent due to any request's sender.  All of these
   error in codes use the PA-TNC exchange and might
   also be sent in response to following error conditions specific to the SWID
   Message information structure.

                        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 13: SW Error, Subscription Error, and Attributes for PA-TNC exchange.  The latter Subscription ID Reuse
                                Information

   +--------------+----------------------------------------------------+
   | Field        | Description                                        |
   +--------------+----------------------------------------------------+
   | Copy of      | In the case utilizes that this error codes defined below.

   A PA-TNC Error attribute condition is sent instead of a SWID Response attribute
   due to factors that prevent the reliable creation of a SWID Response.
   As such, a SWID-PC MUST NOT send both a PA-TNC Error attribute and a
   SWID Response attribute generated |
   | Request ID / | in direct response to a single SWID SW Request
   attribute.

   Table 11 lists attribute, this |
   | Subscription | field MUST contain an exact copy of the Error Code values for the PA-TNC Error attribute
   specific to the SWID Message and Attributes for PA-TNC exchange.  In
   all of these cases, the Error Code Vendor Request ID |
   | ID           | field MUST be set to
   0x000000, corresponding to the IETF SMI Private Enterprise Number.
   The Error Information structures for each error type are described in the following subsections.

   Note that a message with a SWID Message and Attributes for PA-TNC SW Request attribute might also result in an error condition covered by the
   Standard PA-TNC Error Codes defined in PA-TNC.  For example, the SWID
   Attribute might have an invalid parameter, leading to an error code
   of "Invalid Parameter".  In that caused this case, the SWID-PC MUST use the
   appropriate PA-TNC Error Code value as defined in Section 4.2.8 of
   PA-TNC specification.

   +-----------------------+-------------------------------------------+
   | Error Code Value      | Description                               |
   +-----------------------+-------------------------------------------+
   | 0x00000020            | SWID_ERROR. This indicates a fatal error |
   |              | (i.e., an error error.  In the case that precludes the attribute in question |
   |              | creation is generated in fulfillment of a suitable response           |
   |                       | attribute) other than the errors an active           |
   |              | described below but still specific to subscription, this field MUST contain the          |
   |              | processing Subscription ID of SWID Attributes. The the subscription for which the  |
   |              | Description field SHOULD contain attribute was generated.  (This is only possible   |
   |              | additional diagnostic information. if the error code is SW_ERROR as the other errors  |
   | 0x00000021              | SWID_SUBSCRIPTION_DENIED_ERROR. This are not generated by subscription fulfillment.)    |
   |              | indicates that the SWID-PC denied Note that, in this case, the indicated error       |
   |              | SWID-PV's request to establish appears as a sub-error for a                       |
   |              | subscription. The Description field SW_SUBSCRIPTION_FULFILLMENT_ERROR, as described in |
   |              | SHOULD contain additional diagnostic Section 4.16.3.                                    |
   |              | information.                              |
   | 0x00000022            | SWID_RESPONSE_TOO_LARGE_ERROR. This                                                    |
   | Description  | indicates that A UTF-8 string describing the SWID-PC's response to condition that       |
   |              | the SWID-PV's request was too large to caused this error. This field MAY be 0-length.     |
   |              | serviced. The error information structure However, senders SHOULD include some description   |
   |              | indicates the largest possible size in all PA-TNC Error attributes of a  |
   | these types.     | response supported by the SWID-PC (see
   |              | This field MUST NOT be NULL terminated.            | Section 4.16.2).
   +--------------+----------------------------------------------------+

     Table 12: SW Error, Subscription Error, and Subscription ID Reuse
                            Information Fields

   This error information structure is used with SW_ERROR,
   SW_SUBSCRIPTION_DENIED_ERROR, and SW_SUBSCRIPTION_ID_REUSE_ERROR
   status codes to identify the SW Request attribute that precipitated
   the error condition and to describe the error.  The Description field
   contains text describing the error.  The SW-PC MAY encode machine-
   interpretable information in this field, but SHOULD also include a
   human-readable description of the error, since the receiving SW-PV
   might not recognize the SW-PC's encoded information.

4.16.2.  SW_RESPONSE_TOO_LARGE_ERROR Information

   The SW_RESPONSE_TOO_LARGE_ERROR error code indicates that a response
   generated by a SW-PC in response to a SW-PV's SW Request attribute
   was too large to send.

                        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 I              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SHOULD contain additional diagnostic      |                    Maximum Allowed Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | information.                  Description (variable length)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 14: SW Response Too Large Error Information

   +--------------+----------------------------------------------------+
   | 0x00000023 Field        | SWID_SUBSCRIPTION_FULFILLMENT_ERROR. This Description                                        |
   +--------------+----------------------------------------------------+
   | Copy of      | indicates In the case that the SWID-PC experienced an | attribute in question is      |
   | error fulfilling a given subscription.    |
   |                       | The error information includes the Request ID / | generated in direct response to a SW Request, this |
   | Subscription ID | field MUST contain an exact copy of the relevant Request ID |
   | ID           | subscription, as well as a sub-error field in the SW Request attribute that caused this |
   |              | describes the nature of error.  In the error case that the attribute in question |
   |              | SWID-PC experienced. The SWID-PC and is generated in fulfillment of an active           |
   |              | SWID-PV subscription, this field MUST treat contain the identified          |
   |              | Subscription ID of the subscription as cancelled. for which the  |
   | 0x00000024              | SWID_SUBSCRIPTION_ID_REUSE_ERROR. This attribute was generated. Note that, in the latter  |
   |              | indicates that case, the SWID-PC received SW_RESPONSE_TOO_LARGE_ERROR appears as a |
   |              | SWID Request from sub-error for a given SWID-PV where SW_SUBSCRIPTION_FULFILLMENT_ERROR, |
   |              | the Request ID of that SWID Request is as described in Section 4.16.3.                    |
   |              | currently used as the Subscription ID of                                                    |
   | Maximum      | This field MUST contain an active subscription with that SWID-PV. unsigned integer        |
   | Allowed Size | This error does not cancel indicating the identified largest permissible size, in bytes, |
   |              | subscription. of SW Attribute that the SW-PC is currently        |
   | 0x00000025-0x0000002F              | RESERVED. These Error Codes are reserved willing to send in response to a SW Request        |
   |              | for use by future revisions of the SWID attribute.                                         |
   |              | Message and Attributes for PA-TNC                                                    |
   | Description  | specification. Any PA-TNC Error attribute A UTF-8 string describing the condition that       |
   |              | using one of these Error Codes MUST caused this error. This field MAY be 0-length.     |
   |              | treated as indicating a fatal error on However, senders SHOULD include some description   |
   |              | the sender without further in all PA-TNC Error attributes of these types.     |
   |              | interpretation. This field MUST NOT be NULL terminated.            |
   +-----------------------+-------------------------------------------+
   +--------------+----------------------------------------------------+

         Table 11: PA-TNC Error Codes for SWID Message and Attributes for PA-
                                    TNC

   The following subsections describe the structures present in the 13: SW Response Too Large Error Information fields.

4.16.1.  SWID_ERROR, SWID_SUBSCRIPTION_DENIED_ERROR and
         SWID_SUBSCRIPTION_ID_REUSE_ERROR Information

   The SWID_ERROR Fields

   This error code indicates that structure is used with the sender (the SWID-PC) has
   encountered an error related SW_RESPONSE_TOO_LARGE_ERROR
   status code to identify the processing of a SWID SW Request attribute but which is not covered by more specific SWID that precipitated
   the error codes. condition and to describe the error.  The SWID_SUBSCRIPTION_DENIED_ERROR is used when Maximum Allowed
   Size field indicates the SWID-PV requests largest attribute the SW-PC is willing to
   send in response to establish a subscription or clear all subscriptions from SW Request under the given
   SWID-PV, but current circumstances.
   Note that under other circumstances, the SWID-PC is unable SW-PC might be willing to
   return larger or unwilling smaller responses than indicated (such as if the
   endpoint connects to comply with the NEA Server using a different network
   protocol).  The other fields in this
   request. error information structure have
   the same meanings as corresponding fields in the SW_ERROR and
   SW_SUBSCRIPTION_DENIED_ERROR information structure.

4.16.3.  SW_SUBSCRIPTION_FULFILLMENT_ERROR Information

   The SWID_SUBSCRIPTION_ID_REUSE_ERROR is used when SW_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the SWID-
   PC receives
   SW-PC encountered an error while fulfilling a SWID Request whose Request ID duplicates subscription.  The
   bytes after the first 4 octets duplicate a Subscription
   ID PA-TNC Error attribute (as
   described in Section 4.2.8 of an active subscription with PA-TNC) that is used to identify the request's sender.  All
   nature of these
   error codes use the following error information structure. encountered error.

                        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)    Reserved   |           Sub Error Code Vendor ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Sub Error Code                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Sub Error Information (Variable Length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 13: SWID Error, Subscription Error, and 15: SW Subscription ID Reuse Fulfillment Error Information

   +--------------+----------------------------------------------------+
   | Field        | Description                                        |
   +--------------+----------------------------------------------------+
   | Copy of Subscription | In This field MUST contain the Subscription ID of the case that this error condition is generated |
   | Request ID /           | in direct response to a SWID Request attribute, subscription whose fulfillment caused this error.  |
   | Subscription              | this                                                    |
   | Reserved     | This field MUST contain an exact copy the value of the Reserved  |
   | ID              | Request ID field in the SWID Request of a PA-TNC Error attribute that describes   |
   |              | that caused this error.  In the case that the error condition encountered during             |
   |              | attribute in question is generated in fulfillment subscription processing.                           |
   |              | of an active subscription, this field MUST contain                                                    |
   | Sub Error    | This field MUST contain the Subscription ID value of the subscription for which Error     |
   | Code Vendor  | the Code Vendor ID field of a PA-TNC Error attribute was generated.  (This is only   |
   | ID           | possible if that describes the error code is SWID_ERROR as the condition encountered     |
   |              | other errors are not generated by during subscription processing.                    |
   |              | fulfillment.) Note that, in this case,                                                    |
   | Sub Error    | This field MUST contain the value of the Error     |
   | Code         | indicated error appears as a sub-error for Code field of a PA-TNC Error attribute that        |
   |              | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described describes the error condition encountered during   |
   |              | in Section 4.16.3. subscription processing.                           |
   | Description              | A UTF-8 string describing the condition that                                                    |
   | Sub Error    | caused this error. This field MAY be 0-length. MUST contain the value of the Error     |
   | Information  | However, senders SHOULD include some description Information field of a PA-TNC Error attribute that |
   |              | in all PA-TNC Error attributes of these types. describes the error condition encountered during   |
   |              | This field MUST NOT be NULL terminated. subscription processing.                           |
   +--------------+----------------------------------------------------+

      Table 12: SWID Error, Subscription Error, and 14: SW Subscription ID Reuse Fulfillment Error Information Fields

   This error information structure is used with SWID_ERROR,
   SWID_SUBSCRIPTION_DENIED_ERROR, and SWID_SUBSCRIPTION_ID_REUSE_ERROR the
   SW_SUBSCRIPTION_FULFILLMENT_ERROR status codes to identify code.  The first 4 octets of
   this error structure contain the SWID Request attribute Subscription ID of the subscription
   that precipitated was being fulfilled when the error condition and to describe the error.  The Description field
   contains text describing the error. occurred.  The SWID-PC MAY encode machine-
   interpretable information in remaining
   fields of this field, but SHOULD also include error structure duplicate the fields of a
   human-readable description PA-TNC Error
   attribute, referred to as the "sub-error".  The error code of the error, since
   sub-error corresponds to the receiving SWID-PV
   might not recognize type of error that the SWID-PC's encoded information.

4.16.2.  SWID_RESPONSE_TOO_LARGE_ERROR Information SW-PC encountered
   while fulfilling the given subscription.  The SWID_RESPONSE_TOO_LARGE_ERROR sub-error MUST NOT have
   an error code indicates that a
   response generated by a SWID-PC in response to a SWID-PV's SWID
   Request attribute was too large to send.

                        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 I              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Maximum Allowed Size                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Description (variable length)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 14: SWID Response Too Large SW_SUBSCRIPTION_FULFILLMENT_ERROR.

   The SW-PC sending a PA-TNC Error Information

   +--------------+----------------------------------------------------+
   | Field        | Description                                        |
   +--------------+----------------------------------------------------+
   | Copy of      | In the case that the attribute in question is      |
   | Request ID / | generated in direct response to a SWID Request,    |
   | Subscription | with this field error code, and
   the SW-PV receiving it, MUST contain an exact copy of treat the       |
   | ID           | Request subscription identified by the
   Subscription ID field in the SWID Request attribute     |
   |              | that caused this error.  In the case that the      |
   |              | attribute in question is generated in fulfillment  |
   |              | of as cancelled.  All other subscriptions are
   unaffected.

5.  Supported Data Models

   Software Message and Attributes for PA-TNC supports an active subscription, this field MUST contain |
   |              | the Subscription ID extensible
   list of the subscription data models for which  |
   |              | the attribute was generated. Note that, in this    |
   |              | case, the SWID_RESPONSE_TOO_LARGE_ERROR representing and transmitting software
   inventory information.  This list of data models appears as |
   |              | a sub-error for a                                  |
   |              | SWID_SUBSCRIPTION_FULFILLMENT_ERROR, as described  |
   |              | in the
   Software Data Model IANA table (see Section 4.16.3.                                 |
   | Maximum      | 9.4).  This field MUST contain document
   provides guidance for an unsigned integer        |
   | Allowed Size | indicating initial set of data models.  Other documents
   might provide guidance on the largest permissible size, in bytes, |
   |              | use of new data models by Software
   Message and Attributes for PA-TNC, and will be referenced by
   extensions to the Software Data Model IANA table.

5.1.  ISO 2015 SWID Attribute that Tags using XML

   The International Organization for Standardization and the SWID-PC is currently    |
   |              | willing to send
   International Electrotechnical Commission (ISO/IEC) published the
   specification governing SWID tag construction and use in response to 2009 with a
   revised version published in 2015.  [SWID] Since that time, a growing
   number of vendors have integrated SWID Request      |
   |              | attribute.                                         |
   | Description  | A UTF-8 string describing tags into their software
   products.  Doing so significantly simplifies the condition that       |
   |              | caused this error. This field MAY be 0-length.     |
   |              | However, senders SHOULD include some description   |
   |              | in all PA-TNC Error attributes task of identifying
   these types.     |
   |              | This field MUST NOT be NULL terminated.            |
   +--------------+----------------------------------------------------+

        Table 13: SWID Response Too Large Error Information Fields

   This error structure is used with the SWID_RESPONSE_TOO_LARGE_ERROR
   status code pieces of software: instead of relying on discovery processes
   that look for clues as to identify software presence, such as the presence of
   particular files or registry keys, a readily available list of SWID Request attribute that precipitated
   the error condition
   tags provides simple and immediate evidence as to describe the error.  The Maximum Allowed
   Size field indicates presence of the largest attribute
   given piece of software.

   SWID Message and Attributes for PA-TNC has no reliance on the SWID-PC is willing to
   send in response to a
   presence or management of SWID Request under tags on an endpoint as described in
   the current circumstances.

   Note ISO specification.  However, the data model for describing
   software that under other circumstances, is presented in the SWID-PC might be willing to
   return larger responses than indicated (such ISO specification provides a robust
   and comprehensive way of describing software and is adopted here as if a
   means of representing and transmitting software information.  It
   should be emphasized, the endpoint
   connects use of the ISO SWID tag data model makes no
   assumption as to whether the NEA Server using a different network protocol).  The
   other fields in this error information structure have source of the same
   meanings as corresponding fields recorded information was,
   in fact, an ISO SWID tag harvested from the endpoint or whether the SWID_ERROR and
   SWID_SUBSCRIPTION_DENIED_ERROR
   information structure.

4.16.3.  SWID_SUBSCRIPTION_FULFILLMENT_ERROR Information

   The SWID_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the
   SWID-PC encountered an error while fulfilling a subscription.  The
   bytes after was created using some other source and normalized to the first 4 octets duplicate a PA-TNC Error attribute (as
   described in Section 4.2.8 of PA-TNC) that is used
   SWID format.

5.1.1.  Guidance on Normalizing Source Data to identify ISO 2015 SWID Tags using
        XML

   TBD

   Don't violate the
   nature of specification

   Use your own Tag Creator RegID or the encountered error.

                        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 15: SWID Subscription Fulfillment Error Information

   +--------------+----------------------------------------------------+
   | Field        | Description                                        |
   +--------------+----------------------------------------------------+
   | Subscription | This field MUST contain Unknown Tag Creator RegID.  Do
   not use some other party's RegID, especially not the Subscription ID RegID of the |
   | ID           | subscription whose fulfillment caused this error.  |
   | Reserved     | This field MUST contain
   software author if you are not the value author.

5.1.2.  Guidance on Creation of Software Identifiers from ISO 2015 SWID
        Tags

   TBD

   Use combination of Tag Creator RegID and Unique ID fields.
   Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID,
   where NUMBER is the Reserved  |
   |              | field length of TAG_CREATOR_REGID in bytes.  The rest
   of a PA-TNC Error attribute that describes   |
   |              | the error condition encountered during             |
   |              | subscription processing.                           |
   | Sub Error    | This field Software Identifier MUST contain be the value concatination 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 Tag
   Creator RegID and the value of Unique ID from the Error     |
   | Code         | Code field of tag, without any connecting
   character or whitespace.

5.2.  ISO 2009 SWID Tags using XML

   As noted above, ISO's SWID tag specification provides a PA-TNC Error attribute that        |
   |              | describes the error condition encountered during   |
   |              | subscription processing.                           |
   | Sub Error    | This field MUST contain the value useful data
   model for representation of the Error     |
   | Information  | Information field software information.  As of a PA-TNC Error attribute that |
   |              | describes the error condition encountered during   |
   |              | subscription processing.                           |
   +--------------+----------------------------------------------------+

     Table 14: SWID Subscription Fulfillment Error Information Fields

   This error structure is used with the
   SWID_SUBSCRIPTION_FULFILLMENT_ERROR status code.  The first 4 octets writing
   of this error structure contain the Subscription ID of specification, while the
   subscription that was being fulfilled when 2015 specification is considered
   more comprehensive and addresses some issues with the error occurred.  The
   remaining fields of 2009
   specification, 2009-format SWID tags remain far more common in
   deployments.  For this error structure duplicate reason, ISO 2009 SWID tags are included in the fields of a
   PA-TNC Error attribute, referred
   Software Data Model IANA table.

5.2.1.  Guidance on Normalizing Source Data to as ISO 2015 SWID Tags using
        XML

   TBD

   Don't violate the "sub-error".  The error
   code of specification

   Use your own Tag Creator RegID or the sub-error corresponds to Unknown Tag Creator RegID.  Do
   not use some other party's RegID, especially not the type RegID of error that the SWID-
   PC encountered while fulfilling
   software author if you are not the given subscription.  The sub-
   error MUST NOT have an error code author.

5.2.2.  Guidance on Creation of
   SWID_SUBSCRIPTION_FULFILLMENT_ERROR.

   The SWID-PC sending a PA-TNC Error attribute with this error code, Software Identifiers from ISO 2015 SWID
        Tags

   TBD

   Use combination of Tag Creator RegID and Unique ID fields.
   Specifically, format should be NUMBER::TAG_CREATOR_REGID UNIQUE_ID,
   where NUMBER is the SWID-PV receiving it, length of TAG_CREATOR_REGID in bytes.  The rest
   of the Software Identifier MUST treat be the subscription identified
   by concatination of the Subscription Tag
   Creator RegID and the Unique ID field as cancelled.  All other subscriptions
   are unaffected.

5. from the tag, without any connecting
   character or whitespace.

6.  Security Considerations

   This section discusses some of the security threats facing Posture
   Collectors and Posture Validators that implement the SWID Software Message
   and Attributes for PA-TNC protocol.  This section primarily notes
   potential issues for implementers to consider, although it does
   contain a handful of normative requirements to address certain
   security issues.  Implementers need to make the final decision as to
   how their implementations address the given issues.  The issues
   identified below focus on capabilities specific to this document.
   Implementers are advised to consult other relevant NEA specifications
   for security issues that are applicable to such components in
   general.

   Reading the Security Considerations section of any well-written
   specification can be discouraging, as a long list of possible threats
   is catalogued.  Keep in mind that no security measure is absolute,
   but each one can be beneficial.  By understanding the weaknesses of
   each security measure, we can put in place countermeasures to protect
   against exploitation of these weaknesses.

5.1.

6.1.  Evidentiary Value of SWID Tags

   A SWID tag is only indirect evidence as to Software Inventory Evidence Records

   It must be remembered that the installation of a
   piece accuracy of software on an endpoint.  While the ideal is for the
   presence of a tag to correspond to the presence endpoints Software
   Inventory Evidence Collection as an indicator of the corresponding
   software, such a correlation hinges on software that accurately
   manages individual tags as endpoints
   software load and changes thereon is added only as accurate as the tools
   that populate and removed.
   Utilization of manage the tests included in a tag's package_footprint and/or
   validation elements can provide more direct evidence of software
   presence, but inventory evidence records in
   this information collection.  Some tools might not be present designed to update records
   in many tags and,
   because of its limited support, this version of the SWID Message and
   Attributes for PA-TNC specification does not support use of these
   flags.  Tags can include cryptographic signatures of some or all of
   their fields, which can enable detection of field modification.  This
   is extremely useful Software Inventory Evidence Collection in ensuring real time resulting
   in a collection that sensitive fields are not
   modified maliciously.  However, the use of cryptographic signatures is not required in SWID tags, and even when utilized, not all fields out-of-step with actual system state.
   Moreover, tools might inaccurately characterize software, or fail to
   properly record its removal.  Finally, it is likely that there will necessarily
   be protected software on the endpoint that is not tracked by signatures.  For these reasons, it any source and
   thus is important to treat SWID tags as evidence rather than proof not reflected in the Software Inventory Evidence Collection.
   Users of collected software presence.

5.2.  Integrity of inventory evidence records need to
   understand that the SWID Tag Collection

   On a related note, while some systems might protect SWID tags against
   modification, on others there might information provided by the Software Message and
   Attributes for PA-TNC capability cannot be very few restrictions on who
   can add or delete tags on an endpoint.  This treated as completely
   accurate.  Nonetheless, having endpoints report this information can mean that a
   malicious party has relatively free rein to add and remove tags with
   still provide useful insights into the goal state of obscuring the actual endpoint's
   software inventory load, and can alert administrators and policy tools of the endpoint.
   As noted above, signatures
   situations that require remediation.

6.2.  Sensitivity of Collected Records

   Software records on tag files can keep tag modification
   from going undetected, but an attacker endpoint are generally not considered to be
   sensitive, although there can simply delete the signed
   tag and replace it with a modified tag that lacks be exceptions to this generalization as
   noted in the associated
   signature. section on Privacy Considerations.  In fact, even a signed tag general, an
   endpoint's Software Inventory Evidence Collection can be added by an adversary browsed and go undetected if
   individual records read by any party with access to the tag does endpoint.
   This is generally not include fields considered to verify
   software presence, such be problematic, as the package_footprint or validation
   element

   There is little a SWID-PC can do to prevent unauthorized
   modifications of the endpoint's SWID tag from occurring if the local
   system does not provide protections for tags.  Instead, the SWID-PV
   and NEA Server need to operate with an awareness that this type of
   modification can occur.  The use of mechanisms to corroborate
   software inventories can help detect malicious modification of an
   endpoint's SWID tag collection.  Likewise, the SWID-PV can look for
   odd behavior such as the deletion and rapid re-installation of a
   particular tag, especially the replacement of a signed tag with an
   unsigned one.  Parties that use SWID tags as evidence of compliance
   with security policies need to be aware of the possible risks of
   corruption of an endpoint's SWID tag collection.

5.3.  Sensitivity of Collected Tags

   Tags on an endpoint are generally not considered to be sensitive,
   although there can be exceptions to this generalization as noted in
   the section on Privacy Considerations.  In general, an endpoint's
   SWID tag collection can be browsed and individual tags read by any
   party with access to the endpoint.  This is generally not considered
   to be problematic, as those with access to those with
   access to the endpoint can usually learn of everything disclosed by
   that endpoint's tags records simply by inspecting other parts of the
   endpoint.

   The situation changes when an endpoint's SWID tags inventory records are
   collected and stored off of the endpoint itself, such as on a NEA
   Server or CMDB.
   Tags  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 tags
   inventory records might provide many details that are useful for
   mounting an attack.  A list of the tags inventory records associated with
   an endpoint reveals a list of software installed on the endpoint.
   This list is can be very detailed, generally noting specific versions and even
   patch levels, which an adversary can use to identify vulnerable
   software and design efficacious attacks.

   In addition, other information might also be gleaned from a
   collection of SWID tags: software inventory records:

   o  A SWID tag  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  A SWID tag  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  Events affecting SWID tags 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.

   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 tag 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 necessary individuals and processes, and other
   basic security precautions.

5.4.

6.3.  Integrity of Endpoint Records

   SWID-PCs

   SW-PCs maintain records of detected changes to the endpoint's SWID
   tag collection.
   Software Inventory Evidence Collection.  These records are used to
   respond to a SWID-PV's SW-PV's request for change events.  The SWID-PV SW-PV might use
   a list of reported events to update its understanding of the
   endpoint's SWID tag
   collection Software Inventory Evidence Collection without needing to
   receive a full inventory report from the SWID-PC. SW-PC.  For this reason,
   preserving the integrity of the SWID-
   PC's SW-PC's record of events is extremely
   important.  If an attacker modifies the SWID-PC's SW-PC's record of changes to
   the endpoint's SWID tag
   collection, Software Inventory Evidence Collection, this might
   cause the SWID-PV's SW-PV's understanding of the endpoint's SWID tag collection Software Inventory
   Evidence Collection to differ from its actual state.  Results might
   include leading the SWID-PV SW-PV to believe that absent software was
   present, that present software was absent, that patches have been
   installed even if this is not the case, or to be unaware of other
   changes to SWID tags. Software Inventory Evidence Records.  As such, the SWID-PC SW-PC
   MUST take steps to protect the integrity of its event record. records.

   In addition, sometimes a SWID-PC captures metadata about existing
   tags or even creates copies of whole tags.  Metadata might include
   hash values of tag files or records of the last time a particular tag
   file was modified, while whole tags might be preserved to record tags
   that were deleted from the endpoint's SWID tag collection.  If an
   attacker is able to corrupt or modify this information, they might
   cause a SWID-PC to fail to detect certain change events, incorrectly
   report information, or otherwise fail to correctly fulfill SWID-PV
   requests.  As such, this additional information about SWID tags, if
   collected, MUST be integrity protected.

   Finally, records of established SWID-PV SW-PV subscriptions also require
   protection against manipulation or corruption.  If an attacker is
   able to modify or delete records of an established subscription by a
   SWID-PV,
   SW-PV, the SWID-PC SW-PC might fail to correctly fulfill this subscription.
   The SWID-PV SW-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 SWID-PV SW-PV might collect a full
   inventory and realize from this that certain events had not been
   correctly reported in accordance with an established subscription.
   For this reason, the SWID-PC SW-PC MUST protect the integrity of subscription
   records.

5.5.  SWID-PC

6.4.  SW-PC Access Permissions

   A SWID-PC SW-PC requires sufficient permissions to locate and read SWID
   tags on the endpoint that constitute the endpoint's SWID tag
   collection, and 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 file system.
   Depending on the operating environment and other activities
   undertaken by a SWID-PC SW-PC (or software that incorporates a SWID-PC SW-PC as one
   of its capabilities) additional permissions might be required by the SWID-PC
   SW-PC software.  The SWID-PC SW-PC SHOULD NOT be granted permissions beyond
   what it needs in order to fulfill its duties.

5.6.

6.5.  Sanitization of Tag Record Fields

   In most cases there is no constraint on an endpoint as to who can add
   tags.  This open model allows applications that run in user space to
   register tags as easily as more privileged applications.  However,
   this also means

   Not all sources of software inventory evidence are necessarily
   tightly controlled.  For example, consider a source that any tool reading an gathers
   .swid files from the endpoint's tags needs to
   treat these tags as un-vetted input file system.  Any party could create
   a new .swid file that could be collected and employ appropriate
   safeguards. 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 SWID tags, source information and the Software
   Inventory Evidence Records derived therefrom, including
   SWID-PCs, SW-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 tag.

   Fields of a SWID tag that change the SWID-PC's behavior, alter system
   state, or execute code need to be handled with special care. record.

6.6.  PA-TNC Security Threats

   In
   particular, addition to the validation element, which provides a command line
   that can nominally be executed to validate the tag's correctness, can
   be utilized by an attacker to point to a malicious executable.  To
   defend against this, SWID-PCs MUST NOT execute an application
   indicated by a validation element unless the element is signed and
   the SWID-PC has determined that aforementioned considerations the signature is intact Software Message
   and trusted.

5.7.  Tag Library Poisoning

   It can be useful Attributes for a SWID-PV to have access PA-TNC protocol is subject to a library of tags.
   If the SWID-PV receives a list same security
   threats as other PA-TNC transactions, as noted in Section 5.2 of tag identifier instances, it can
   consult this library PA-
   TNC [RFC5792].  These include, but are not limited to, attribute
   theft, message fabrication, attribute modification, attribute replay,
   attribute insertion, and collect full tags corresponding denial of service.  Implementers are advised
   to those
   identifiers.  Assuming it does not need access consult the PA-TNC specification to installation-
   specific information, it can perform calculations on better understand these full tags
   as
   security issues.

7.  Privacy Considerations

   As noted in Section 6.2, if it had received them from a SWID-PC.  For example, it an adversary can use gain an understanding of
   the software installed on an endpoint, they can utilize this library to derive software names, publishers,
   launch attacks and version by
   finding maintain footholds on this endpoint.  For this
   reason, the tag that corresponds NEA Server needs to the given tag identifier value.

   If the SWID-PV keeps a collection of full SWID tags for matching
   against tag identifiers, there might be a temptation ensure adequate safeguards are in
   place to add any
   previously unknown tags prevent exposure of collected inventory records.  For
   similar reasons, it is advisable that an endpoint only send records
   to a SWID-PC might report NEA Server that is authorized to receive this library
   automatically.  In fact, this behavior information and
   that can pose a security risk.  If
   the endpoint has been compromised and the tag manipulated on that
   endpoint, the tag that it provides to the SWID-PV might be misleading
   with regard trusted to the software associated with this tag.  If the SWID-PV
   automatically adds safeguard this corrupted tag information after collection.

8.  Relationship to its library, not only will
   the computations with the compromised endpoint be affected, but
   computations with other endpoints that provide tag identifier
   instances that map Other Specifications

   This specification makes frequent reference to the corrupted tag will also be affected.
   Instead, if the SWID-PV does make and use of other
   specifications.  This section describes these relationships.

   This specification is expected to participate in a tag library, standard NEA
   architecture.  As such, it is
   recommended expected to only populate that library be used in conjunction with tags retrieved from a
   trusted source, or at least to segregate collections of reported tags
   by endpoint, so corrupted tags on one endpoint will not affect tag
   computations involving
   the other endpoints.  In general, tags retrieved
   from a trusted source and signed by a trusted authority are likely be
   safe for inclusion protocols used in a tag library.

5.8.  PA-TNC Security Threats NEA exchange.  In addition to the aforementioned considerations the SWID Message and particular, SW
   Attributes for PA-TNC protocol are conveyed over PB-TNC [RFC5793], which is subject to the same security
   threats as other PA-TNC transactions, as noted in Section 5.2 turn
   conveyed over some variant of PA-
   TNC [RFC5792]. PT (either PT-TLS [RFC6876] or PT-EAP
   [RFC7171]).  These include, but protocols have an especially important role, as
   they are not limited to, attribute
   theft, message fabrication, attribute modification, attribute replay,
   attribute insertion, and denial of service.  Implementers responsible for ensuring that attributes defined under this
   specification are advised delivered reliably, securely, and to consult the PA-TNC specification to better understand these
   security issues.

6.  Privacy Considerations

   As noted in Section 5.3, 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 adequate safeguards are in
   place to prevent exposure of collected tags.  For similar reasons, it
   is advisable that an endpoint only send tags to a NEA Server that is
   authorized to receive this information and that can be trusted to
   safeguard this information after collection.

7.  Relationship to Other Specifications

   This specification makes frequent reference to and use of other
   specifications.  This section describes these relationships.

   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, SWID
   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.

   It is important
   appropriate party.

   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 the SWID
   Software Message and Attributes for PA-TNC specification is able to
   convey a broader query, resulting in a more comprehensive set of
   evidence regarding an endpoint's installed software.  Moreover, because this
   specification makes use of the well-defined structures in SWID tags,
   it is able to convey information that is more concise (by making use
   of specific identifier fields instead of sending the whole SWID tag)
   and/or more comprehensive (as the SWID structures contain many more
   fields than expressible in PA-TNC).  As such, this
   specification provides important capabilities not present in the PA-TNC PA-
   TNC specification.

8.

9.  IANA Considerations

   This section extends multiple existing IANA registries.
   Specifically, it extends the PA-TNC Attribute Types and PA-TNC Error
   Codes 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.

8.1.

9.1.  Registry for PA-TNC Attribute Types

   Section 4.6 of this specification defines several new PA-TNC
   attributes.  The following values are added to the registry for PA-
   TNC Attribute Types defined in the PA-TNC specification.  Note that
   Table 4 in Section 4.6 lists these attributes but uses a hexadecimal
   value to identify their associated integer.  The integer values given
   in that table are identical to those provided here.  Note also that
   Table 4 includes an entry for PA-TNC Error attributes, but the IANA
   information associated with that attribute is already defined in the
   PA-TNC specification and is not reproduced here.

   +-----+---------+----------------------+----------------------------+

   +-----+---------+---------------------+-----------------------------+
   | PEN | Integer | Name                | Defining Specification      |
   +-----+---------+----------------------+----------------------------+
   +-----+---------+---------------------+-----------------------------+
   | 0   | 17      | SWID SW Request          | SWID Software Message and        |
   |     |         |                     | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 18      | SWID Tag Software Identifier | SWID Software Message and        |
   |     |         | Inventory           | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 19      | SWID Tag Software Identifier | SWID Software Message and        |
   |     |         | Events              | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 20      | SWID Tag Software Inventory  | SWID Software Message and        |
   |     |         |                     | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 21      | SWID Tag Software Events     | SWID Software Message and        |
   |     |         |                     | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 22      | Subscription Status | SWID Software Message and        |
   |     |         | Request             | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 23      | Subscription Status | SWID Software Message and        |
   |     |         | Response            | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 24      | Subscription Status | SWID Software Message and        |
   |     |         | Response            | Attributes for PA-TNC       |
   |     |         |                     |                             |
   | 0   | 25 - 31 | Reserved for future | SWID Software Message and        |
   |     |         | use                 | Attributes for PA-TNC       |
   +-----+---------+----------------------+----------------------------+

8.2.
   +-----+---------+---------------------+-----------------------------+

9.2.  Registry for PA-TNC Error Codes

   Section 4.16 of this specification defines several new PA-TNC Error
   Codes.  The following values are added to the registry for PA-TNC
   Error Codes defined in the PA-TNC specification.  Note that Table 11
   in Section 4.16 lists these attributes codes but uses a hexadecimal value to
   identify their associated integer.  The integer values given in that
   table are identical to those provided here.

   +----+---------+------------------------------------+---------------+

   +-----+---------+-----------------------------------+---------------+
   | PE PEN | Integer | Name                              | Defining      |
   | N     |         |                                   | Specification |
   +----+---------+------------------------------------+---------------+
   +-----+---------+-----------------------------------+---------------+
   | 0   | 32      | SWID_ERROR SW_ERROR                          | SWID Message Software      |
   |     |         |                                   | Message and   |
   |     |         |                                   | Attributes    |
   |     |         |                                   | for PA-TNC    |
   |     |         |                                   |               |
   | 0   | 33      | SWID_SUBSCRIPTION_DENIED_ERROR SW_SUBSCRIPTION_DENIED_ERROR      | SWID Message Software      |
   |     |         |                                   | Message and   |
   |     |         |                                   | Attributes    |
   |     |         |                                   | for PA-TNC    |
   |     |         |                                   |               |
   | 0   | 34      | SWID_RESPONSE_TOO_LARGE_ERROR SW_RESPONSE_TOO_LARGE_ERROR       | SWID Message Software      |
   |     |         |                                   | Message and   |
   |     |         |                                   | Attributes    |
   |     |         |                                   | for PA-TNC    |
   |     |         |                                   |               |
   | 0   | 35      | SWID_SUBSCRIPTION_FULFILLMENT_ERRO SW_SUBSCRIPTION_FULFILLMENT_ERROR | SWID Message Software      |
   |     |         | R                                   | Message and   |
   |     |         |                                   | Attributes    |
   |     |         |                                   | for PA-TNC    |
   |     |         |                                   |               |
   | 0   | 36      | SWID_SUBSCRIPTION_ID_REUSE_ERROR SW_SUBSCRIPTION_ID_REUSE_ERROR    | SWID Message Software      |
   |     |         |                                   | Message and   |
   |     |         |                                   | Attributes    |
   |     |         |                                   | for PA-TNC    |
   |     |         |                                   |               |
   | 0   | 37-47   | Reserved for future use           | SWID Message Software      |
   |     |         |                                   | Message and   |
   |     |         |                                   | Attributes    |
   |     |         |                                   | for PA-TNC    |
   +----+---------+------------------------------------+---------------+

8.3.
   +-----+---------+-----------------------------------+---------------+

9.3.  Registry for PA Subtypes

   Section 4.1 of this specification defines one new PA Subtype.  The
   following value is added to the registry for PA Subtypes defined in
   the PB-TNC specification.

   +-----+---------+----------------+----------------------------------+

   +-----+---------+-------------+-------------------------------------+
   | PEN | Integer | Name        | Defining Specification              |
   +-----+---------+----------------+----------------------------------+
   +-----+---------+-------------+-------------------------------------+
   | 0   | 9       | SWID SW          | SWID Software Message and Attributes for |
   |     |         | Attributes  | PA-TNC                              |
   +-----+---------+----------------+----------------------------------+

9.
   +-----+---------+-------------+-------------------------------------+

9.4.  Registry for Software Data Models

   TBD

10.  References
9.1.

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://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,
              <http://www.rfc-editor.org/info/rfc3339>.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
              <http://www.rfc-editor.org/info/rfc5198>.

   [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,
              <http://www.rfc-editor.org/info/rfc5209>.

   [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,
              <http://www.rfc-editor.org/info/rfc5792>.

   [SWID]     The International Organization for Standardization/
              International Electrotechnical Commission, "Information
              Technology - Software Asset Management - Part 2: Software
              Identification Tag, ISO/IEC 19770-2", November 2009.

9.2.

10.2.  Informative References

   [NIST-SWID]
              The National Institute of Standards and Technology and The
              MITRE Corporation, "Guidelines for the Creation of
              Interoperable Software Identification (SWID) Tags", August
              2013.

   [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, <http://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,
              <http://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,
              <http://www.rfc-editor.org/info/rfc7171>.

Appendix A.  Examples

   This appendix includes examples of a SWID tag file and SWID
   attributes.  All examples represent fictional content.  Examples are
   provided using the 2009 release of the ISO/IEC SWID specification.

A.1.  A Simple SWID Tag

   Figure 16 shows an example SWID tag for a fictional software product
   called SomeApp created by Vendor Inc. This example includes only the
   required SWID tag fields.  This tag is for version 2.3, build 12 of
   the product.

  1]<?xml version="1.0" encoding="UTF-8"?>
  2]<swid:software_identification_tag
  3]  xmlns:swid="http://standards.iso.org/iso/19770/-2/2009/schema.xsd"
  4]  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  5]    <swid:entitlement_required_indicator>
  6]        true
  7]    </swid:entitlement_required_indicator>
  8]    <swid:product_title>SomeApp</swid:product_title>
  9]    <swid:product_version>
 10]        <swid:name>2.3 r12</swid:name>
 11]        <swid:numeric>
 12]            <swid:major>2</swid:major>
 13]            <swid:minor>3</swid:minor>
 14]            <swid:build>12</swid:build>
 15]            <swid:review>0</swid:review>
 16]        </swid:numeric>
 17]    </swid:product_version>
 18]    <swid:software_creator>
 19]        <swid:name>Vendor Inc.</swid:name>
 20]        <swid:regid>regid.2013-06.com.vendor</swid:regid>
 21]    </swid:software_creator>
 22]    <swid:software_licensor>
 23]        <swid:name>Vendor Inc.</swid:name>
 24]        <swid:regid>regid.2013-06.com.vendor</swid:regid>
 25]    </swid:software_licensor>
 26]    <swid:software_id>
 27]        <swid:unique_id>
 28]            someapp-21ec2020-3aea-1069-a2dd-08002b30309d
 29]        </swid:unique_id>
 30]        <swid:tag_creator_regid>
 31]            regid.2013-06.com.vendor
 32]        </swid:tag_creator_regid>
 33]    </swid:software_id>
 34]    <swid:tag_creator>
 35]        <swid:name>Vendor Inc.</swid:name>
 36]        <swid:regid>regid.2013-06.com.vendor</swid:regid>
 37]    </swid:tag_creator>
 38]</swid:software_identification_tag>

                       Figure 16: A Simple SWID Tag

   The SWID tag described in Figure 16 is limited to only the
   information required by the SWID specification [SWID].  This
   information includes the following:

   o  Lines 5-7: Entitlement requirement indicator.  This indicates
      whether some sort of entitlement (e.g., a license) is required in
      order to install and/or use the software.

   o  Line 8: Prose name of the product

   o  Lines 9-17: Product version.  This includes both a prose
      expression of the full product version and the version information
      broken down into distinct fields.

   o  Lines 18-21: Software creator identification.  This identifies the
      party that created the software.  This includes both a prose name
      of the software creator and their "regid" value.

   o  Lines 22-25: Software licensor identification.  This identifies
      the party that holds the rights to license others to use the
      software.

   o  Lines 26-33: Software unique identifier.  This structure contains
      the regid for the party that created this tag and a value that
      party uses to uniquely identify the named software product.  The
      SWID Message and Attributes for PA-TNC specification uses the
      values of these fields when constructing a SWID tag identifier, as
      described in Section 3.3.

   o  Lines 34-37: Tag creator identification.  This identifies the
      party that created the tag.

   Assume the SWID tag file is installed on the file system in the
   following location:

   C:\ProgramData\Vendor\regid.2013-06.com.vendor_someapp-21ec2020-3aea-
   1069.swidtag

A.2.  SWID Request Attributes

   Below are hexadecimal dumps of example SWID Request attributes.  SWID
   Request attributes are described in more detail in Section 4.7.

A.2.1.  Simple Request

   This is a basic SWID request for inventory information - the request
   is not targeted nor does the request establish a subscription on the
   endpoint.  The SWID Request dictates that the response be expressed
   using SWID tag identifier instances.

   +-------------+-----------------------------------------------------+
   | 20 00 00 00 | Clear Subscriptions = 0 (don't clear                |
   |             | subscriptions), Subscribe = 0 (don't establish a    |
   |             | new subscription), Result Type = 1 (respond using   |
   |             | SWID tag identifier instances), Tag ID Count = 0    |
   |             | (non-targeted request)                              |
   | ----------- |                                                     |
   | 00 00 3a 76 | Request ID = 14966                                  |
   | ----------- |                                                     |
   | 00 00 00 00 | Earliest EID = 0 (respond with inventory rather     |
   |             | than event records)                                 |
   +-------------+-----------------------------------------------------+

   Note that this attribute does not contain any Tag Creator Length, Tag
   Creator, Unique Software ID Length, or Unique Software ID fields
   because the Tag ID Count field is 0.

A.2.2.  Subscription Request for Events

   This attribute establishes a request for a new subscription that will
   report new SWID change events as they occur.

   +-------------+-----------------------------------------------------+
   | 60 00 00 00 | Clear Subscriptions = 0 (don't clear                |
   |             | subscriptions), Subscribe = 1 (establish a new      |
   |             | subscription), Result Type = 1 (respond using SWID  |
   |             | tag identifier instances), Tag ID Count = 0 (non-   |
   |             | targeted request)                                   |
   | ----------- |                                                     |
   | 00 00 3a 76 | Request ID = 14967                                  |
   | ----------- |                                                     |
   | 00 02 cc 3a | Earliest EID = 183354                               |
   +-------------+-----------------------------------------------------+

   As before, this attribute does not contain any Tag Creator Length,
   Tag Creator, Unique Software ID Length, or Unique Software ID fields
   because the Tag ID Count field is 0.  The immediate response to this
   message (assuming no errors are encountered) will be a list of events
   with EIDs that are greater than or equal to 183354.  Thereafter, if
   any new events are recorded, those events (and only those events)
   will be sent back to the SWID-PV in fulfillment of this subscription.
   (See Section 3.8.2 for more on subscription fulfillment.)

A.2.3.  Targeted Request

   This example shows a targeted request.  Specifically, the request
   includes two SWID tag identifiers.  The attribute requests that the
   corresponding full SWID tags be returned.

   +-----------------+-------------------------------------------------+
   | 00 00 00 02     | Clear Subscriptions = 0 (don't clear            |
   |                 | subscriptions), Subscribe = 0 (don't establish  |
   |                 | a new subscription), Result Type = 0 (respond   |
   |                 | using full SWID tags), Tag ID Count = 2         |
   |                 | (targeted request identifying two SWID tags)    |
   | -----------     |                                                 |
   | 00 00 3a 76     | Request ID = 14968                              |
   | -----------     |                                                 |
   | 00 00 00 00     | Earliest EID = 0 (respond with inventory rather |
   |                 | than event records)                             |
   | ===========     | START TAG IDENTIFIER 1                          |
   | 00 18           | Tag Creator Length = 24                         |
   | -----------     |                                                 |
   | 72 65 67 69 64  | Tag Creator = regid.2013-06.com.vendor          |
   | 2e 32 30 31 33  |                                                 |
   | 2d 30 36 2e 63  |                                                 |
   | 6f 6d 2e 76 65  |                                                 |
   | 6e 64 6f 72     |                                                 |
   | -----------     |                                                 |
   | 00 2c           | Unique Software ID Length = 44                  |
   | -----------     |                                                 |
   | 73 6f 6d 65 61  | Unique Software ID =                            |
   | 70 70 2d 32 31  | someapp-21ec2020-3aea-1069-a2dd-08002b30309d    |
   | 65 63 32 30 32  |                                                 |
   | 30 2d 33 61 65  |                                                 |
   | 61 2d 31 30 36  |                                                 |
   | 39 2d 61 32 64  |                                                 |
   | 64 2d 30 38 30  |                                                 |
   | 30 32 62 33 30  |                                                 |
   | 33 30 39 64     |                                                 |
   | ===========     | START TAG IDENTIFIER 2                          |
   | 00 18           | Tag Creator Length = 24                         |
   | -----------     |                                                 |
   | 72 65 67 69 64  | Tag Creator = regid.2013-06.com.vendor          |
   | 2e 32 30 31 33  |                                                 |
   | 2d 30 36 2e 63  |                                                 |
   | 6f 6d 2e 76 65  |                                                 |
   | 6e 64 6f 72     |                                                 |
   | -----------     |                                                 |
   | 00 2f           | Unique Software ID Length = 47                  |
   | -----------     |                                                 |
   | 61 6e 6f 74 68  | Unique Software ID =                            |
   | 65 72 61 70 70  | anotherapp-23a52020-3aea-1069-a2dd-0800884d4e21 |
   | 2d 32 33 61 35  |                                                 |
   | 32 30 32 30 2d  |                                                 |
   | 33 61 65 61 2d  |                                                 |
   | 31 30 36 39 2d  |                                                 |
   | 61 32 64 64 2d  |                                                 |
   | 30 38 30 30 38  |                                                 |
   | 38 34 64 34 65  |                                                 |
   | 32 31           |                                                 |
   +-----------------+-------------------------------------------------+

   This message contains SWID tag identifiers for two SWID tags.  The
   first of these tags is the example SWID tag described in
   Appendix A.1.  The second tag is created by the same tag creator, but
   indicates a different software product.

A.3.  SWID Response Attributes

   This section contains examples of SWID response attributes.

A.3.1.  SWID Tag Identifier Events Attribute

   This shows an example of a SWID Tag Identifier Events attribute.  In
   this case, this attribute is sent in fulfillment of an established
   subscription rather than in direct response to a SWID Request
   attribute.  (This is indicated by setting the Subscription
   Fulfillment flag.)  The SWID Request attribute shown in
   Appendix A.2.2 established this subscription (as indicated by the
   Subscription ID field).

   This response contains two event records.

   +-------------------+-----------------------------------------------+
   | 80 00 00 02       | Subscription Fulfillment = 1, Event Count = 2 |
   | -----------       |                                               |
   | 00 00 3a 76       | Subscription ID = 14968                       |
   | -----------       |                                               |
   | 7e 82 1c aa       | EID Epoch = 2122456234                        |
   | -----------       |                                               |
   | 00 02 cc 84       | Last EID = 183428                             |
   | -----------       |                                               |
   | 00 02 cc 84       | Last Consulted EID = 183428 (Same as Last EID |
   |                   | so this is a complete result)                 |
   | ===========       | START EVENT RECORD 1                          |
   | 00 02 cc 83       | EID = 183427                                  |
   | -----------       |                                               |
   | 32 30 31 33 2d 30 | Timestamp = 2013-07-21T04:32:16Z              |
   | 37 2d 32 31 54 30 |                                               |
   | 34 3a 33 32 3a 31 |                                               |
   | 36 5a             |                                               |
   | -----------       |                                               |
   | 01                | Action = 1 (CREATION)                         |
   | -----------       |                                               |
   | 00 18             | Tag Creator Length = 24                       |
   | -----------       |                                               |
   | 72 65 67 69 64 2e | Tag Creator = regid.2013-06.com.vendor        |
   | 32 30 31 33 2d 30 |                                               |
   | 36 2e 63 6f 6d 2e |                                               |
   | 76 65 6e 64 6f 72 |                                               |
   | -----------       |                                               |
   | 00 2c             | Unique Software ID Length = 44                |
   | -----------       |                                               |
   | 73 6f 6d 65 61 70 | Unique Software ID =                          |
   | 70 2d 32 31 65 63 | someapp-21ec2020-3aea-1069-a2dd-08002b30309d  |
   | 32 30 32 30 2d 33 |                                               |
   | 61 65 61 2d 31 30 |                                               |
   | 36 39 2d 61 32 64 |                                               |
   | 64 2d 30 38 30 30 |                                               |
   | 32 62 33 30 33 30 |                                               |
   | 39 64             |                                               |
   | -----------       |                                               |
   | 00 51             | Instance ID Length = 81                       |
   | -----------       |                                               |
   | 43 3a 5c 50 72 6f | Instance ID =                                 |
   | 67 72 61 6d 44 61 | C:\ProgramData\Vendor\regid.2013-06.          |
   | 74 61 5c 56 65 6e | com.vendor_someapp-21ec2020-3aea-1069.swidtag |
   | 64 6f 72 5c 72 65 |                                               |
   | 67 69 64 2e 32 30 |                                               |
   | 31 33 2d 30 36 2e |                                               |
   | 63 6f 6d 2e 76 65 |                                               |
   | 6e 64 6f 72 5f 73 |                                               |
   | 6f 6d 65 61 70 70 |                                               |
   | 2d 32 31 65 63 32 |                                               |
   | 30 32 30 2d 33 61 |                                               |
   | 65 61 2d 31 30 36 |                                               |
   | 39 2e 73 77 69 64 |                                               |
   | 74 61 67          |                                               |
   | ============      | START EVENT RECORD 2                          |
   | 00 02 cc 84       | EID = 183428                                  |
   | -----------       |                                               |
   | 32 30 31 33 2d 30 | Timestamp = 2013-07-21T04:32:22Z              |
   | 37 2d 32 31 54 30 |                                               |
   | 34 3a 33 32 3a 32 |                                               |
   | 32 5a             |                                               |
   | -----------       |                                               |
   | 02                | Action = 2 (DELETED)                          |
   | -----------       |                                               |
   | 00 18             | Tag Creator Length = 24                       |
   | -----------       |                                               |
   | 72 65 67 69 64 2e | Tag Creator = regid.2009-08.com.company       |
   | 32 30 30 39 2d 30 |                                               |
   | 38 2e 63 6f 6d 2e |                                               |
   | 63 6f 6d 70 61 6e |                                               |
   | 79                |                                               |
   | -----------       |                                               |
   | 00 24             | Unique Software ID Length = 36                |
   | -----------       |                                               |
   | 32 34 38 35 34 39 | Unique Software ID =                          |
   | 37 35 2d 31 32 35 | 24854975-125e-ee3e-98ac-45684248eefa          |
   | 65 2d 65 65 33 65 |                                               |
   | 2d 39 38 61 63 2d |                                               |
   | 34 35 36 38 34 32 |                                               |
   | 34 38 65 65 66 61 |                                               |
   | -----------       |                                               |
   | 00 47             | Instance ID Length = 71                       |
   | -----------       |                                               |
   | 43 3a 5c 50 72 6f | Instance ID = C:\Program                      |
   | 67 72 61 6d 20 46 | Files\Company\OurProduct\                     |
   | 69 6c 65 73 5c 43 | OurProduct_8749-84789200-02.swidtag           |
   | 6f 6d 70 61 6e 79 |                                               |
   | 5c 4f 75 72 50 72 |                                               |
   | 6f 64 75 63 74 5c |                                               |
   | 4f 75 72 50 72 6f |                                               |
   | 64 75 63 74 5f 38 |                                               |
   | 37 34 39 2d 38 34 |                                               |
   | 37 38 39 32 30 30 |                                               |
   | 2d 30 32 2e 73 77 |                                               |
   | 69 64 74 61 67    |                                               |
   +-------------------+-----------------------------------------------+

   This response contains two event records.  Note that their timestamps
   indicate that they occurred a few seconds apart - some SWID-PCs might
   choose to wait a brief time before sending messages in fulfillment of
   subscriptions so as to send multiple event records in a single
   attribute.  The first event record indicates the creation of the SWID
   tag shown in Appendix A.1.  The second event record indicates the
   deletion of a different SWID tag.  Finally, note that since the Last
   EID field is equal to the EID of one of the reported event records,
   this indicates that the SWID-PC has no later recorded events.

A.3.2.  SWID Tag Inventory Attribute

   This shows an example of a SWID Tag Inventory attribute.  In this
   case, this attribute is being sent in direct response to a SWID
   Request attribute, as indicated by the Subscription Fulfillment flag
   being unset.  (Specifically, it is being sent in response to the SWID
   Request shown in Appendix A.2.3, as can be shown by comparing the
   Request ID and Request ID Copy fields.)  The result includes a single
   tag entry.

   +-----------------------+-------------------------------------------+
   | 00 00 00 01           | Subscription Fulfillment = 0, Tag Count = |
   |                       | 1                                         |
   | -----------           |                                           |
   | 00 00 3a 76           | Request ID Copy = 14968                   |
   | -----------           |                                           |
   | 7e 82 1c aa           | EID Epoch = 2122456234                    |
   | -----------           |                                           |
   | 00 02 cc 84           | Last EID = 183428                         |
   | ===========           | BEGIN TAG ENTRY                           |
   | 00 51                 | Instance ID Length = 81                   |
   | -----------           |                                           |
   | 43 3a 5c 50 72 6f 67  | Instance ID =                             |
   | 72 61 6d 44 61 74 61  | C:\ProgramData\Vendor\regid.2013-06.com.  |
   | 5c 56 65 6e 64 6f 72  | vendor_someapp-21ec2020-3aea-1069.swidtag |
   | 5c 72 65 67 69 64 2e  |                                           |
   | 32 30 31 33 2d 30 36  |                                           |
   | 2e 63 6f 6d 2e 76 65  |                                           |
   | 6e 64 6f 72 5f 73 6f  |                                           |
   | 6d 65 61 70 70 2d 32  |                                           |
   | 31 65 63 32 30 32 30  |                                           |
   | 2d 33 61 65 61 2d 31  |                                           |
   | 30 36 39 2e 73 77 69  |                                           |
   | 64 74 61 67           |                                           |
   | -----------           |                                           |
   | 05 ac                 | Tag Length = 1452                         |
   | -----------           |                                           |
   | 3c 3f 78 6d 6c 20 76  | The Tag field is equal to the SWID tag    |
   | ...  69 6f 6e 5f 74   | shown in Figure 16. Note that since the   |
   | 61 67 3e              | original tag used UTF-8 encoding, the tag |
   |                       | is copied without undergoing any          |
   |                       | conversion or normalization.              |
   +-----------------------+-------------------------------------------+

   This attribute contains a single SWID tag.  As a response to the
   targeted SWID Request in Appendix A.2.3, this indicates a single
   instance of the first requested SWID tag and no instances of the
   second requested tag were present in the endpoint's SWID tag
   collection.  Moreover, if the same party receives both this attribute
   and the attribute in Appendix A.3.1, one can tell that there have
   been no change events recorded since the preceding message, because
   the EID Epoch and Last EID values are unchanged.

Authors' Addresses

   Chris Coffin
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730
   USA

   Email: ccoffin@mitre.org

   Daniel Haynes
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730
   USA

   Email: dhaynes@mitre.org

   Charles Schmidt
   The MITRE Corporation
   202 Burlington Road
   Bedford, MA  01730
   USA

   Email: cmschmidt@mitre.org

   Jessica Fitzgerald-McKay
   Department of Defense
   9800 Savage Road
   Ft. Meade, Maryland
   USA

   Email: jmfitz2@nsa.gov