3.  System Requirements

   SWIMA facilitates the exchange of software inventory and event
   information.  Specifically, each application supporting SWIMA
   includes a component known as the SWIMA-PC that receives SWIMA
   attributes.  The SWIMA-PC is also responsible for sending appropriate
   SWIMA attributes back to the SWIMA-PV in response.  This section
   outlines what software inventories and events are and the
   requirements on SWIMA-PCs and SWIMA-PVs in order to support the
   stated use cases of this specification.

3.1.  Data Sources

   The records in an endpoint's Software Inventory Evidence Collection
   come from one or more "sources".  A source represents one collection
   of software inventory information about the endpoint.  Examples of
   sources include, but are not limited to, ISO SWID tags deposited on
   the filesystem and collected therefrom, information derived from
   package managers, and the output of software inventory-scanning
   tools.

   There is no expectation that any one source of inventory information
   will have either perfect or complete software inventory information.
   For this reason, this specification supports the simultaneous use of
   multiple sources of software inventory information.  Each source
   might have its own "sphere of expertise" and report the software
   within that sphere.  For example, a package manager would have an
   excellent understanding of the software that it managed but would not
   necessarily have any information about software installed via other
   means.

   A SWIMA-PC is not required to utilize every possible source of
   software information on its endpoint.  Some SWIMA-PCs might be
   explicitly tied only to one or a handful of software inventory
   sources, or a given SWIMA-PC could be designed to dynamically
   accommodate new sources.  For all software inventory evidence sources
   that a particular SWIMA-PC supports, it MUST completely support all
   requirements of this specification with regard to those sources.  A
   potential source that cannot support some set of required
   functionality (e.g., it is unable to monitor the software it reports
   for change events, as discussed in Section 3.6) MUST NOT be used as a
   source of endpoint software inventory information, even if it could
   provide some information.  In other words, a source either supports
   full functionality as described in this specification or cannot be
   used at all.  In the event that a previously used source becomes
   unavailable, this would be treated as a discontinuity in the
   SWIMA-PC's reporting.  Section 3.7.1 describes how to use changes in
   the Event Identifier (EID) Epoch value to indicate a reporting
   discontinuity.

   When sending information about installed software, the SWIMA-PC MUST
   include the complete set of relevant data from all supported sources
   of software inventory evidence.  In other words, sources need to be
   used consistently.  This is because if a particular source is
   included in an initial inventory but excluded from a later inventory,
   the SWIMA-PV receiving this information might reasonably conclude
   that the software reported by that source was no longer installed on
   the endpoint.  As such, it is important that all supported sources be
   used every time the SWIMA-PC provides information to a SWIMA-PV.

   Note that if a SWIMA-PC collects data from multiple sources, it is
   possible that some software products might be "double counted".  This
   can happen if two or more sources of inventory evidence provide a
   record for a single installation of a software product.  When a
   SWIMA-PC reports information or records events from multiple
   inventory evidence sources, it MUST use the information those sources
   provide, rather than attempt to perform some form of reduction.  In
   other words, if multiple sources report records corresponding to a
   single installation of a software product, all such records from each
   source are required to be part of the SWIMA-PC's processing even if
   this might lead to multiple reporting, and the SWIMA-PC is not to
   ignore some records to avoid such multiple reporting.

   All inventory records reported by a SWIMA-PC include a Source
   Identifier linking them to a particular source.  Source Identifiers
   are discussed more in Section 3.4.5.  As discussed in that section,
   Source Identifiers can help consumers of SWIMA data identify cases of
   multiple reporting.

3.2.  Data Models

   SWIMA conveys records about software presence from a SWIMA-PC to a
   SWIMA-PV.  SWIMA does not manage the actual generation or collection
   of such records on the endpoint.  As a result, information available
   to SWIMA-PCs might come in a variety of formats, and a SWIMA-PC could
   have little control over the format of the data made available to it.
   Because of this, SWIMA places no constraints on the format of these
   generated records and supports an open set of record formats by which
   installed software instances can be described.  The following terms
   are used in this document:

   o  Data model - The format used to structure data within a given
      record.  SWIMA does not constrain the data models it conveys.

   o  Record - A populated instance of some data model that describes a
      software product.

   Do not confuse the "data model" described here with the structure of
   the SWIMA messages and attributes used to convey information between
   SWIMA-PVs and SWIMA-PCs.  The SWIMA standard dictates the structure
   of its messages and attributes.  Some attributes, however, have
   specific fields used to convey inventory records, and those fields
   support an extensible list of data models for their values.  In other
   words, SWIMA data models provide an extension point within SWIMA
   attributes that allows the structure of inventory records to evolve.

   The data model used to structure software inventory information has
   very little impact on the behavior of the components defined in this
   specification.  The SWIMA-PV has no dependency on the data model of
   records conveyed in SWIMA messages.  For this reason, it MUST NOT
   reject a message or respond with a PA-TNC Error due to the data model
   used to structure records in attributes it receives.  Similarly, it
   MUST NOT reject a message or respond with a PA-TNC Error if a record
   fails to comply with a stated format, unless that failure prevents
   correct parsing of the attribute itself.  In short, the record bodies
   are effectively treated as "black boxes" by the SWIMA-PV.  (Note that
   the SWIMA-PV might serve as the "front end" of other functionality
   that does have a dependency on the data model used to structure
   software information, but any such dependency is beyond the scope of
   this specification and needs to be addressed outside the behaviors
   specified in this document.  This specification is only concerned
   with the collection and delivery of software inventory information;
   components that consume and use this information are a separate
   concern.)

   The SWIMA-PC does have one functional dependency on the data models
   used in the software records it delivers, but only insofar as it is
   required to deterministically create a Software Identifier (described
   in Section 3.4.1) based on each record it delivers.  The SWIMA-PC
   MUST be able to generate a Software Identifier for each record it
   delivers, and if the SWIMA-PC cannot do so, it cannot deliver the
   record.  All SWIMA-PCs MUST at least be able to generate Software
   Identifiers for the data model types specified in Section 6 of this
   document.  A SWIMA-PC MAY include the ability to generate Software
   Identifiers for other data model types and thus be able to support
   them as well.

3.3.  Basic Attribute Exchange

   In the most basic exchange supported by this specification, a
   SWIMA-PV sends a request to the SWIMA-PC, requesting some type of
   information about the endpoint's software inventory.  This simple
   exchange is shown in Figure 2.

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

                 Figure 2: Basic SWIMA Attribute Exchange

   Upon receiving such a SWIMA Request from the SWIMA-PV, the SWIMA-PC
   is expected to collect all the relevant software inventory
   information from the endpoint's Software Inventory Evidence
   Collection and place it within its response attribute.

   SWIMA-PVs MUST discard, without error, any SWIMA Response attributes
   that they receive for which they do not know the SWIMA Request
   parameters that led to this SWIMA Response.  This is due to the fact
   that the SWIMA Request includes parameters that control the nature of
   the response (as will be described in the following sections);
   without knowing those parameters, the SWIMA Response cannot be
   reliably interpreted.  Each SWIMA Request includes a Request ID,
   which is echoed in any SWIMA Response to that request and allows
   matching of responses to requests.  See Section 5.5 for more on
   Request IDs.  Receiving an unsolicited SWIMA Response attribute will
   most often happen when a NEA Server has multiple SWIMA-PVs; one
   SWIMA-PV sends a SWIMA Request, but unless exclusive delivery
   [RFC5793] is set by the sender and honored by the recipient, multiple
   SWIMA-PVs will receive copies of the resulting SWIMA Response.  In
   this case, the SWIMA-PV that didn't send the SWIMA Request would lack
   the context necessary to correctly interpret the SWIMA Response it
   received and would simply discard it.  Note, however, that
   proprietary measures might allow a SWIMA-PV to discover the SWIMA
   Request parameters for a SWIMA Response even if that SWIMA-PV did not
   send the given SWIMA Request.  As such, there is no blanket
   requirement for a SWIMA-PV to discard all SWIMA Responses to SWIMA
   Requests that the SWIMA-PV did not generate itself -- only that
   SWIMA-PVs are required to discard SWIMA Responses for which they
   cannot get the necessary context to interpret.

   In the case that it is possible to do so, the SWIMA-PC SHOULD send
   its SWIMA Response attribute to the SWIMA-PV that requested it, using
   exclusive delivery as described in Section 4.5 of "PB-TNC: A Posture
   Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)"
   [RFC5793].  Exclusive delivery requests that only the sender of the
   SWIMA Request be the receiver of the resulting SWIMA Response.  Note,
   however, that PB-TNC does not require the recipient to honor the
   exclusive delivery flag in messages that it receives, so setting the
   flag cannot be guaranteed to prevent a SWIMA-PV from receiving
   unsolicited SWIMA Responses.

   Note that, in the case that a single endpoint hosts multiple
   SWIMA-PCs, a single SWIMA Request could result in multiple SWIMA
   Responses.  SWIMA-PVs need to handle such an occurrence without
   error.

   All numeric values sent in SWIMA messages are sent in network
   (big endian) byte order.

3.4.  Core Software-Reporting Information

   Different parameters in the SWIMA Request can influence what
   information is returned in the SWIMA Response.  However, while each
   SWIMA Response provides different additional information about this
   installed software, the responses all share a common set of fields
   that support reliable software identification on an endpoint.  These
   fields include Software Identifiers, Data Model Type, Record
   Identifiers, Software Locators, and Source Identifiers.  These fields
   are present for each reported piece of software in each type of SWIMA
   Response.  The following sections examine these information types in
   more detail.

3.4.1.  Software Identifiers

   A Software Identifier uniquely identifies a specific version of a
   specific software product.  The SWIMA standard does not dictate the
   structure of a Software Identifier (beyond stating that it is a
   string) or define how it is created.  Instead, each data model
   described in the "Software Data Model Types" registry (Section 10.5)
   includes its own rules for how a Software Identifier is created based
   on a record in the endpoint's Software Inventory Evidence Collection
   expressed in that data model.  Other data models will have their own
   procedures for the creation of associated Software Identifiers.
   Within SWIMA, the Software Identifier is simply an opaque string, and
   there is never any need to unpack any information that might be part
   of that identifier.

   A Software Identifier is a fraction of the size of the inventory
   record from which it is derived.  For this reason, it is often more
   efficient to collect full inventories using Software Identifiers and
   only collect full records when necessary using targeted requests.
   For some combinations of data models and sources, the full record
   might never be necessary, as the identifier can be directly
   correlated to the contents of the full record.  This is possible with
   authoritative SWID tags, since these tags always have the same
   contents and thus a Software Identifier derived from these tags can
   be used as a lookup to a local copy of the full tag.  For other
   combinations of source and data model, a server might not be able to
   determine the specific software product and version associated with
   the identifier without requesting the delivery of the full record.
   However, even in those cases, downstream consumers of this
   information might never need the full record as long as the Software
   Identifiers they receive can be tracked reliably.  A SWIMA-PV can use
   Software Identifiers to track the presence of specific software
   products on an endpoint over time in a bandwidth-efficient manner.

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

   1.  The identifiers do not necessarily change when the associated
       record changes.  In some situations, a record in the endpoint's
       Software Inventory Evidence Collection will change due to new
       information becoming available or in order to correct prior
       errors in that information.  Such changes might or might not
       result in changes to the Software Identifier, depending on the
       nature of the changes and the rules governing how Software
       Identifiers are derived from records of the appropriate data
       model.

   2.  It is possible that a single software product is installed on a
       single endpoint multiple times.  If these multiple installation
       instances are reported by the same source using the same data
       format, then this can result in identical Software Identifiers
       for both installation instances.  In other words, Software
       Identifiers might not uniquely identify installation instances;
       they are just intended to uniquely identify software products
       (which might have more than one installation instance).  Instead,
       to reliably distinguish between multiple instances of a single
       software product, one needs to make use of Record Identifiers as
       described in Section 3.4.3.

3.4.2.  Data Model Type

   The Data Model Type consists of two fields: Data Model Type PEN and
   Data Model Type.  ("PEN" stands for "Private Enterprise Number".)
   The combination of these fields is used to identify the type of data
   model of the associated software inventory record.  The data model is
   significant not only because it informs the recipient of the data
   model of the associated record but also because the process for
   generating the Software Identifier for the record depends on the
   record's data model.  Clearly identifying the type of data model from
   which the Software Identifier was derived thus provides useful
   context for that value.

   The PEN identifies the organization that assigns meaning to the Data
   Model Type field value.  PENs are managed by IANA in the "Private
   Enterprise Numbers" registry.  PENs allow vendors to designate their
   own set of data models for software inventory description.  IANA
   reserves the PEN of 0x000000.  Data Model Types associated with this
   PEN are defined in the "Software Data Model Types" registry; see
   Section 10.5 of this specification.  Note that this IANA table
   reserves all values greater than or equal to 0xC0 (192) for local
   enterprise use.  This means that local enterprises can use custom
   data formats and indicate them with the IANA PEN and a Data Model
   Type value between 0xC0 and 0xFF, inclusive.  Those enterprises are
   responsible for configuring their SWIMA-PCs to correctly report those
   custom data models.

3.4.3.  Record Identifiers

   A Record Identifier is a 4-byte unsigned integer that is generated by
   the SWIMA-PC and is uniquely associated with a specific record within
   the endpoint's Software Inventory Evidence Collection.  The SWIMA-PC
   MUST assign a unique identifier to each record when it is added to
   the endpoint's Software Inventory Evidence Collection.  The Record
   Identifier SHOULD remain unchanged if that record is modified.
   However, it is recognized that, in some circumstances, record
   modification might be hard to distinguish from record deletion
   followed by creation of a new record.  For this reason, retaining a
   constant Record Identifier across a record modification is
   recommended but not required.  Similarly, in the case that the
   software product associated with a record is moved, ideally the
   Record Identifier for the record of the moved software will remain
   unchanged, reflecting that it represents the same software product
   instance, albeit in a new location.  However, this level of tracking
   could prove difficult to achieve and is not required.  The SWIMA-PC
   might wish to assign Record Identifiers sequentially, but any scheme
   is acceptable, provided that no two records receive the same
   identifier.

   Servers can use Record Identifiers to distinguish between multiple
   instances of a single software product installed on an endpoint.
   Since each installation instance of a software product is associated
   with a separate record, servers can use the Record Identifier to
   distinguish between instances.  For example, if an event is reported
   (as described in Section 3.7), the Record Identifier will allow the
   server to discern which instance of a software product is involved.

3.4.4.  Software Locators

   In addition to the need to identify what software products are on an
   endpoint, some processes that use inventory information also need to
   know where software is located on the endpoint.  This information
   might be needed to direct remediation actions or similar processes.
   For this reason, every reported software product also includes a
   Software Locator to identify where the software is installed on the
   endpoint.

   If the location is not provided directly by the data source, the
   SWIMA-PC is responsible for attempting to determine the location of
   the software product.  The "location" of a product SHOULD be the
   directory in which the software product's executables are kept.  The
   SWIMA-PC MUST be consistent in reporting the location of a software
   product.  In other words, assuming that a software product has not
   moved, the SWIMA-PC cannot use one location in one report and a
   different location for the same software product in another.  (If a
   software product has moved, the Software Locator needs to reflect the
   new location.)

   The location is expressed as a URI string.  The string MUST conform
   to URI syntax requirements [RFC3986].  The URI scheme describes the
   context of the described location.  For example, in most cases the
   location of the installed software product will be expressed in terms
   of its path in the filesystem.  For such locations, the location URI
   scheme MUST be "file", and the URI MUST conform to the "file" URI
   scheme standard [RFC8089], including the percent-encoding of
   whitespace and other special characters.  It is possible that other
   schemes could be used to represent other location contexts.  Apart
   from specifying the use of the "file" scheme, this specification does
   not identify other schemes or define their use.  When representing
   software products in other location contexts, tools MUST be
   consistent in their use of schemes, but the exact schemes are not
   normatively defined here.  SWIMA implementations are not limited to
   the IANA list of URI schemes <https://www.iana.org/assignments/
   uri-schemes/> and can define new schemes to support other types of
   application locations.

   It is possible that a SWIMA-PC is unable to determine the location of
   a reported software product.  In this case, the SWIMA-PC MUST provide
   a zero-length Software Locator.

3.4.5.  Source Identifiers

   All SWIMA-PCs MUST track the source of each piece of software
   information they report.  Each time a SWIMA-PC gets information to
   send to a given SWIMA-PV from a new source (from the perspective of
   that SWIMA-PV), the SWIMA-PC MUST assign that source a Source
   Identifier, which is an 8-bit unsigned integer.  Each item reported
   includes the number of the Source Identifier for the source that
   provided that information.  All information that is provided by that
   source MUST be delivered with this same Source Identifier.  This MUST
   be done for each source used.  If the SWIMA-PC is ever unclear as to
   whether a given source is new or not, it MUST assume that this is a
   new source and assign it a new Source Identifier.  Source Identifier
   numbers do not need to be assigned sequentially.  SWIMA does not
   support the presence of more than 256 sources, as the chance that a
   single endpoint will have more than 256 methods of collecting
   inventory information is vanishingly small.  All possible values
   between 0 and 255 are valid; there are no reserved Source Identifier
   numbers.

   Source Identifiers can help with (although will not completely
   eliminate) the challenges posed by multiple reporting of a single
   software instance.  If multiple sources each report the same type of
   software product once, there is most likely a single instance of that
   product installed on the endpoint, which each source has detected
   independently.  On the other hand, if multiple instances are reported
   by a single source, this almost certainly means that there are
   actually multiple instances that are being reported.

   The SWIMA-PC is responsible for tracking associations between Source
   Identifiers and the given data source.  This association MUST remain
   consistent with regard to a given SWIMA-PV while there is an active
   PB-TNC session with that SWIMA-PV.  The SWIMA-PC MAY have a different
   Source Identifier association for different SWIMA-PVs.  Likewise, the
   SWIMA-PC MAY change the Source Identifier association for a given
   SWIMA-PV if the PB-TNC session terminates.  However, implementers of
   SWIMA-PCs will probably find it easier to manage associations by
   maintaining the same association for all SWIMA-PVs and across
   multiple sessions.

   Of special note, event records reported from the SWIMA-PC's event log
   (discussed in Section 3.7) also need to be sent with their associated
   data source.  The Source Identifier reported with events MUST be the
   current (i.e., at the time the event is sent) Source Identifier

   associated with the data source that produced the event, regardless
   of how long ago that event occurred.  Event logs are likely to
   persist far longer than a single PB-TNC session.  SWIMA-PCs MUST
   ensure that each event can be linked to the appropriate data source,
   even if the Source Identifiers used when the event was created have
   since been reassigned.  In other words, when sending an event, it
   needs to be sent with the Source Identifier currently linked to the
   data source that produced it, regardless of whether a different
   Source Identifier would have been associated with the event when the
   event was first created.

   Note that the Source Identifier is primarily used to support
   recognition, rather than identification, of sources.  That is to say,
   a Source Identifier can tell a recipient that two events were
   reported by the same source, but the number will not necessarily help
   that recipient determine which source was used.  Moreover, different
   SWIMA-PCs will not necessarily use the same Source Identifiers for
   the same sources.  SWIMA-PCs MUST track the assignment of Source
   Identifiers to ensure consistent application thereof.  SWIMA-PCs MUST
   also track which Source Identifiers have been used with each SWIMA-PV
   with which they communicate.

3.4.6.  Using Software and Record Identifiers in SWIMA Attributes

   A SWIMA attribute reporting an endpoint's Software Inventory Evidence
   Collection always contains the Software Identifiers associated with
   the identified software products.  A SWIMA attribute might or might
   not also contain copies of Software Inventory Evidence Records.  The
   attribute exchange is identical to the diagram shown in Figure 2,
   regardless of whether Software Inventory Evidence Records are
   included.  The SWIMA Request attribute indicates whether the response
   is required to include Software Inventory Evidence Records.
   Excluding Software Inventory Evidence Records can reduce the
   attribute size of the response by multiple orders of magnitude when
   compared to sending the same inventory with full records.

3.5.  Targeted Requests

   Sometimes a SWIMA-PV does not require information about every piece
   of software on an endpoint but only needs to receive updates about
   certain software instances.  For example, enterprise endpoints might
   be required to have certain software products installed and to keep
   these updated.  Instead of requesting a complete inventory just to
   see if these products are present, the SWIMA-PV can make a "targeted
   request" for the software in question.

   Targeted requests follow the same attribute exchange as the exchange
   described in Figure 2.  The SWIMA-PV targets its request by providing
   one or more Software Identifiers in its SWIMA Request attribute.  The
   SWIMA-PC MUST then limit its response to contain only records that
   match the indicated Software Identifier(s).  This allows the network
   exchange to exclude information that is not relevant to a given
   policy question, thus reducing unnecessary bandwidth consumption.
   The SWIMA-PC's response might or might not include Software Inventory
   Evidence Records, depending on the parameters of the SWIMA Request.

   Note that targeted requests identify the software relevant to the
   request only through Software Identifiers.  This specification does
   not support arbitrary, parameterized querying of records.  For
   example, one cannot request all records from a certain software
   publisher or all records created by a particular data source.
   Targeted requests only allow a requester to request specific software
   (as identified by their Software Identifiers) and receive a response
   that is limited to the named software.

   There is no assumption that a SWIMA-PC will recognize "synonymous
   records" -- that is, records from different sources for the same
   software.  Recall that different sources and data models may use
   different Software Identifier strings for the same software product.
   The SWIMA-PC returns only records that match the Software Identifiers
   in the SWIMA Request, even if there might be other records in the
   endpoint's Software Inventory Evidence Collection for the same
   software product.  This is necessary because SWIMA-PCs might not have
   the ability to determine that two Software Identifiers refer to the
   same product.

   A targeted SWIMA Request attribute does not specify Record
   Identifiers or Software Locators.  The response to a targeted request
   MUST include all records associated with the named Software
   Identifiers, including the case where there are multiple records
   associated with a single Software Identifier.

   SWIMA-PCs MUST accept targeted requests and process them correctly as
   described above.  SWIMA-PVs MUST be capable of making targeted
   requests and processing the responses thereto.

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

   The software collection on an endpoint is not static.  As software is
   installed, uninstalled, patched, or updated, the Software Inventory
   Evidence Collection is expected to change to reflect the new software
   state on the endpoint.  Different data sources might update the
   evidence collection at different rates.  For example, a package

   manager might update its records in the Software Inventory Evidence
   Collection immediately whenever it is used to add or remove a
   software product.  By contrast, sources that perform periodic
   examination of the endpoint would likely only update their records in
   the Software Inventory Evidence Collection after each examination.

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

   o  The creation of records

   o  The deletion of records

   o  The alteration of records

   An "alteration" is anything that modifies the contents of a record
   (or would modify it, if the record is dynamically generated on
   demand) in any way, regardless of whether the change is functionally
   meaningful.

   SWIMA-PCs MUST detect such changes to the endpoint's Software
   Inventory Evidence Collection in close to real time (i.e., within
   seconds) when the SWIMA-PC is operating.  In addition, in the case
   where there is a period during which the SWIMA-PC is not operating,
   the SWIMA-PC MUST be able to determine the net change to the
   endpoint's Software Inventory Evidence Collection over the period it
   was not operational.  Specifically, the "net change" represents the
   difference between (1) the state of the endpoint's Software Inventory
   Evidence Collection when the SWIMA-PC was last operational and
   monitoring its state and (2) the state of the endpoint's Software
   Inventory Evidence Collection when the SWIMA-PC resumed operation.
   Note that a net change might not reflect the total number of change
   events over this interval.  For example, if a record was altered
   three times during a period when the SWIMA-PC was unable to monitor
   for changes, the net change of this interval might only note that
   there was an alteration to the record, but not how many individual
   alteration events occurred.  It is sufficient for a SWIMA-PC's
   determination of a net change to note that there was a difference
   between the earlier and current state, rather than to enumerate all
   the individual events that allowed the current state to be reached.

   The SWIMA-PC MUST assign a time to each detected change in the
   endpoint's Software Inventory Evidence Collection.  These timestamps
   correspond to the SWIMA-PC's best understanding as to when the
   detected change occurred.  For changes to the endpoint's Software
   Inventory Evidence Collection that occur while the SWIMA-PC is
   operating, the SWIMA-PC ought to be able to assign a time to the

   event that is accurate to within a few seconds.  For changes to the
   endpoint's Software Inventory Evidence Collection that occur while
   the SWIMA-PC is not operational, upon becoming operational the
   SWIMA-PC needs to make a best guess as to the time of the relevant
   events (possibly by looking at timestamps on files), but these values
   might be off.  In the case of dynamically generated records, the time
   of change is the time at which the data from which the records are
   generated changes, not the time at which a changed record is
   generated.  For example, if records are dynamically generated based
   on data in an RPM database (<http://rpm.org/>), the time of change
   would be when the RPM database changed.

   With regard to deletions of records, the SWIMA-PC needs to detect the
   deletion of a given record and MUST retain a copy of the full deleted
   record along with the associated Record Identifier and Software
   Locator so that the record and associated information can be provided
   to the SWIMA-PV upon request.  This copy of the record MUST be
   retained for a reasonable amount of time.  Vendors and administrators
   determine what "reasonable" means, but a copy of the record SHOULD be
   retained for as long as the event recording the deletion of the
   record remains in the SWIMA-PC's event log (as described in
   Section 3.7).  This is recommended, because as long as the event is
   in the SWIMA-PC's event log the SWIMA-PC might send a change event
   attribute (described in Section 3.7) that references this record, and
   a copy of the record is needed if the SWIMA-PV wants a full copy of
   the relevant record.  In the case that a SWIMA-PC is called upon to
   report a deletion event that is still in the event log but where the
   record itself is no longer available, the SWIMA-PC will still return
   an entry corresponding to the deletion event, but the field of that
   entry that would normally contain the full copy of the record SHOULD
   be zero-length.

   With regard to alterations to a record, SWIMA-PCs MUST detect any
   alterations to the contents of a record.  Alterations need to be
   detected even if they have no functional impact on the record.  A
   good guideline is that any alteration to a record that might change
   the value of a hash taken on the record's contents needs to be
   detected by the SWIMA-PC.  A SWIMA-PC might be unable to distinguish
   modifications to the contents of a record from modifications to the
   metadata that the filesystem associates with the record.  For
   example, a SWIMA-PC might use the "last modification" timestamp as an
   indication of alteration to a given record, but a record's last
   modification time can change for reasons other than modifications to
   the record's contents.  A SWIMA-PC is still considered compliant with
   this specification if it also reports metadata change events that do
   not change the record itself as alterations to the record.  In other
   words, while SWIMA-PC implementers are encouraged to exclude
   modifications that do not affect the bytes within the record,

   discriminating between modifications to file contents and changes to
   file metadata can be difficult and time consuming on some systems.
   As such, as long as the alterations detected by a SWIMA-PC always
   cover all modifications to the contents of a record, the SWIMA-PC is
   considered compliant even if it also registers alterations that do
   not modify the contents of a record as well.  When recording an
   alteration to a record, the SWIMA-PC is only required to note that an
   alteration occurred.  The SWIMA-PC is not required to note or record
   how the record was altered, nor is it possible to include such
   details in SWIMA attributes reporting the change to a SWIMA-PV.
   There is no need to retain a copy of the original record prior to the
   alteration.

   When a record changes, it SHOULD retain the same Record Identifier.
   The Software Locator might or might not change, depending on whether
   the software changed locations during the changes that led to the
   record change.  A record change MUST retain the same Software
   Identifier.  This means that any action that changes a software
   product (e.g., application of a patch that results in a change to the
   product's version) MUST NOT be reflected by a record change but
   instead MUST result in the deletion of the old record and the
   creation of a new record.  This reflects the requirement that a
   record in the endpoint's Software Inventory Evidence Collection
   correspond directly with an instance of a specific software product.