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

	

Figure 2: Basic SWID Message Exchange

Upon receiving such a SWID Request from the SWID-PV, the SWID-PC is expected to locate the endpoint's SWID tags and then create copies of all identified SWID tags and place them within its response attribute.

SWID-PVs MUST discard without error any SWID Response attributes that they receive for which they do not know the SWID Request parameters that led to this SWID Response. This is due to the fact that the SWID Request includes parameters that control the nature of the response (as will be 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 is used by the SWID-PC in sending the response, both SWID-PVs receive copies of the resulting SWID Response. In this case, the SWID-PV that didn't send the SWID Request would lack the context necessary to correctly interpret the SWID Response it received and would simply discard it. Note, however, that proprietary measures might allow a SWID-PV to discover the SWID Request parameters for a SWID Response even if that SWID-PV did not send the given SWID Request. As such, there is no blanket requirement for a SWID-PV to discard all SWID Responses to SWID Request the SWID-PV did not generate itself, only that SWID-PVs are required to discard SWID Responses for which they cannot get the necessary context to interpret.

In the case that it is possible to do so, the SWID-PC MAY send its SWID Response attribute to the SWID-PV that requested it using exclusive delivery as described in section 3.3.2.2 of the IF-IMV r1.4 specification. Exclusive delivery ensures that only the sender of the SWID Request receives the resulting SWID Response. However, exclusive delivery is not always possible (it requires the use of IF-IMC 1.3 or later and IF-IMV 1.3 or later, and not all products currently do this) or necessarily desirable in all cases. As such, SWID Message and Attributes for PA-TNC does not require support for exclusive delivery of attributes.

3.3. SWID Tag Identifiers

SWID tags can contain a great deal of information about a software product. In addition to identifying name, manufacturer, and version 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 endpoint to indicate when the SWID tag was last checked for accuracy relative to the endpoint's installed software 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 of a SWID tag can be useful for reasoning about details of an endpoint's 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 the complete tag. All tags contain specific fields that can be used to distinguish a tag for a particular piece of software from tags for different pieces of software. The Tag Creator RegID is a string that uniquely identifies the creator of this SWID tag (who might or might not be the same as the entity who created the described software) while the Unique ID is a string that uniquely identifies the described piece of software according to that tag creator. These two pieces of information together create a "tag identifier".

3.3.1. Tag Identifier Data

Some attributes defined in this specification contain fields 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 specific fields of a SWID tag that correspond to the Tag Creator RegID and Unique ID values vary between the different releases of the ISO SWID tag specification. It is important to note that, in all other parts of this specification, the terms Tag Creator RegID 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 the Tag Creator RegID, identify the field containing the regid value of the entity that created the given SWID tag. Note that this might not be the same entity that created the software. The Tag Creator RegID MUST be the regid, rather than any prose name that might be 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 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 a single field within the SWID tag, rather than a concatenation of multiple fields. In particular, SWID tags often contain designated fields for just the product name, product version, product edition, etc., but these fields are not used to populate the Unique ID. Instead, look for a single field that is designed to uniquely identify a specific software product, version, etc. (and thus uniquely identifies a specific tag, at least according to the tag's creator).

Consult the ISO/IEC specification for the specific fields that correspond to the requirements of the Tag Creator RegID and Unique ID, as defined above. For example, in the 2009 version of the ISO/IEC SWID specification [SWID], the Tag Creator RegID corresponds to the value of the software_identification_tag/software_id/tag_creator_regid field in a SWID tag. The Unique ID corresponds to the value of the software_identification_tag/software_id/unique_id field in a SWID tag. In subsequent releases of the ISO/IEC SWID specification, different fields might be used to convey the same information.

3.3.2. Tag Identifier Instances

A tag identifier (i.e., the combination of the Tag Creator RegID and the Unique ID fields) uniquely identifies a particular SWID tag, which corresponds to a single software product. Assuming that this product manages its own SWID tag (i.e., creates the tag on installation and deletes the tag when 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 the same tag identifier field values. (Presence of SWID tags managed by other tools, such as discovery tools, would also depend on the presence of those tools on the device.) In fact, if multiple instances of the same software product are installed on a single device (i.e., it has been installed twice in different locations) that device would have two instances of the same SWID tag, one for each installation. Both instances of the SWID tag would have the same tag identifier field values. This is true even though the tags themselves might differ with regard to their installation-specific tag fields. In many cases it is important to distinguish between instances of a particular tag on a particular endpoint. For example, if one is alerted to the deletion of a particular SWID tag and there are multiple instances of that SWID tag on the endpoint, one will likely wish 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. The exact nature of the Instance ID depends on the source of the SWID tag. If the SWID tag is represented as a file on disk, the Instance ID might be the full path of the SWID tag file, including the name of the SWID tag file itself. (Note that the SWID tag filename MUST be included in the tag file path because it is possible for two SWID tags, each for different instances of the same software product, to co-exist in the same directory under different file names.) In the case that the SWID tag is dynamically generated upon request by some source, such as an RPM or YUM package manager, the generation process MUST create an Instance ID to distinguish instances of a particular tag. Inclusion of this Instance ID ensures each tag is uniquely identified on a given endpoint.

To the extent that it is possible, the generation of Instance IDs SHOULD be repeatable for a single installation of a single SWID tag. In the case where a product is installed once, and then SWID tags are generated upon request, each time the SWID tag is generated the tag identifier instance SHOULD all have the same Instance ID value. For example, if a package manager generates a SWID tag in response to a request based on some record it possesses, and then later generates the SWID tag again based on the same record of package installation, then the same Instance ID value SHOULD be created both times. This is necessary to allow remote parties to understand whether a reported SWID tag instance is for the same product installation they saw reported earlier or if it represents a new installation of the same product. Note, however, that some exceptional situations might result in the changing of a product's Instance ID. For example, it is not explicitly prohibited by the SWID specification for tags to move after installation, and thus have their tag file path change. If the file path was used 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 of this possibility.

The combination of a tag identifier with an Instance ID is referred to as a "tag identifier instance". A tag identifier instance uniquely identifies a particular instance of a particular tag on a given endpoint. Note that two endpoints might produce identical tag identifier instances, but these do not mean that the tag files on the two endpoints are identical - the tags in question indicate the same software product on both endpoints (since the respective tag identifiers are identical), but the tags might still differ in their installation-specific fields. Therefore, it is important to remember that tag identifier instances are only comparable in the scope of a single endpoint; when comparing across different endpoints, only the tag identifier fields (Tag Create RegID and Unique ID) can be meaningfully compared - any Instance ID value will need to be excluded from comparison.

3.3.3. Comparing Tag Identifiers and Tag Identifier Instances

Comparison of tag identifiers can be used to determine whether a particular SWID tag is present in an endpoint's SWID tag collection. A pair of SWID tag identifiers is said to "match" if their Tag Creator RegID and Unique ID fields are identical. Similarly, a pair of tag identifier instances is said to match if their Tag Creator RegID, Unique ID, and Instance ID fields are identical. Fields in SWID Message and 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 the corresponding values from other sources (such as when comparing them to a full SWID tag file or similar record), the relevant fields from the latter need to undergo normalization prior to comparison. See Section 4.7 for more on normalization of the encoding for these fields. Comparisons are case-sensitive.

Matching tag identifiers and tag identifier instances indicate very specific things about the respective tags. The following sections describe what one can and cannot deduce based on matching tag identifiers.

3.3.3.1. Matching Tag Identifiers Indicate the Same Software Product

The Unique ID value of a tag identifier represents a value that the given tag creator will only use to indicate a particular software product (e.g., a particular release of a particular application). The ISO SWID specification prohibits the tag creator from associating a Unique ID value with multiple, different software products. At the same time, the Tag Creator RegID element value uniquely identifies a given tag creator. As such, even if two different tag creators were to assign the same Unique ID value to two different software products, the Tag Creator RegID values will be different, and therefore the tag identifiers will be different. For these reasons, the expectation is that if one sees two tags with the same tag identifiers, these tags are both associated with the same software product (assuming the tag's fields are correctly populated).

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

Some optional fields in SWID tags can reflect installation-specific information. As such, the SWID tags for a piece of software residing on two different endpoints (or installed twice on a single endpoint) will have the same tag identifier value (same tag creator with the same Unique ID for 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 the tags on those endpoints are identical in 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 the tag). If this becomes part of the revised SWID specification, 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 that particular endpoint at a particular point in time. The Instance ID in the tag identifier instance information ought to be unique relative to any other instances of the same SWID tag currently also on that endpoint. However, tag identifier instances are still not guaranteed to be unique to a single SWID tag file over a long period of time. Consider a piece of software that is installed (adding a SWID tag), uninstalled (removing the SWID tag), 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 the tag files themselves were different.

As noted above, SWID tag identifier instances are only comparable 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 comparison of tag identifiers from different endpoints.

3.3.3.4. Differing Tag Identifiers DO NOT Necessarily Indicate Different Software Products

While a tag identifier uniquely identifies a software product (i.e., that tag identifier cannot be associated with a different software product), a single product might have more than one tag identifier. This is because it is possible for more than one tag creator to create a SWID tag for the same software product. Multiple tags for 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 the same software product. In fact, in some circumstances, two parties might create two different SWID tag records for a single instance of the same software product. For example, when a product is installed, it creates a SWID tag file on the file system, and a software discovery tool also notes the installation of the product and generates its own SWID tag record for 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 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. The message exchange is identical to the diagram shown in Figure 2, but the contents 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 to sending the same 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 that instead of copying each SWID tag entirely into the attribute body of the response, 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 this policy, the SWID-PV is only interested in the specific SWID tag associated with this patch. Instead of requesting a complete inventory just to see if the patch's SWID tag is present, the SWID-PV can make a "targeted request" for the tag in question.

Targeted requests follow the same message exchange described in Figure 2. The SWID-PV targets its request by providing one or more SWID tag identifiers in its SWID Request attribute. The SWID-PC MUST then limit its response to contain only tags that match the indicated tag 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 SWID-PC's response might consist of full tags or of tag identifier instances, depending on the parameters of the SWID Request.

Targeted requests cannot target specific SWID tag instances; the SWID Request does not include fields for Instance IDs. As a result, when responding to a targeted request, a SWID-PC MUST return applicable results for every instance of the identified tags.

Note that targeted requests identify the SWID tags relevant to the request only through SWID tag identifiers for those tags. This specification does not support arbitrary, parameterized querying of tags. For example, one cannot request all tags from a certain software publisher, or all tags created by a particular tag creator. Targeted requests only allow a requestor to request specific tags (as identified by their tag identifiers) and receive a response that is limited to the named tags. There is also no assumption that a SWID-PC will recognize "synonymous tags" - that is, tags by different tag creators for the same software product. The SWID-PC returns only tags that match the tag identifiers in the SWID Request, even if there might be other SWID tags in the endpoint's SWID tag collection for the same software product.

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

3.5. Monitoring Changes 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 by an application's installer, tag changes usually occur at the time 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 be able to detect changes to the SWID tag repositories on their endpoint. Specifically, SWID-PCs MUST be able to detect:

• The creation of tags
• The deletion of tags
• The alteration of tags

An "alteration" is anything that modifies the contents of a SWID tag file (or would modify it, if the tag file is dynamically generated on demand) in any way, regardless of whether the change is functionally meaningful. Changes MUST be monitored for all utilized sources of SWID tags. This includes, but is not limited to, monitoring sources that dynamically generate SWID tags.

SWID-PCs MUST detect such changes to 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 MUST be able to determine the net change 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 the state of the endpoint's SWID tag collection when the SWID-PC resumed operation. Note that a net change might not reflect the total number of change events over this interval. For example, if a SWID tag file was altered three times during a period when the SWID-PC was unable to monitor for changes, the net change of this interval might only note that there was an alteration to the file, but not how many individual alteration events occurred. It is sufficient for a SWID-PC's determination of a net change to note that there was a difference between the earlier and current state rather than enumerating all the individual events that allowed the current state to be reached.

The SWID-PC MUST assign a time to each detected change in the endpoint's SWID tag collection. These timestamps correspond to the SWID-PC's best understanding as to when the detected change occurred. These timestamps MUST be as accurate as possible. For changes to the endpoint's SWID tag collection that occur while the SWID-PC is operating, the SWID-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 SWID tag collection that occur while the SWID-PC is not operational, upon becoming operational the SWID-PC needs to make a best guess as to the time of the relevant events (possibly by looking at timestamps on the files), but these values might be off. In the case of dynamically generated SWID tags, the time of change is the time at which the data from which the SWID tags are generate changes, not the time at which a changed SWID tag is generated. For example, if SWID tags are dynamically generated based on data in an RPM database, the time of change would be when the RPM record was changed.

With regard to deletions of SWID tags, the SWID-PC needs to detect the deletion and MUST retain a copy of the full deleted tag so that the tag itself can be provided to the SWID-PV upon request. This copy of the SWID tag MUST be retained for a reasonable amount of time. Vendors and administrators determine what "reasonable" means, but a copy of the tag SHOULD be retained for as long as the event recording the deletion of the tag remains in the SWID-PC's records. This is recommended because, as long as the event is in the SWID-PC's records, the SWID-PC might send an event 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 to the contents of a tag file. Alterations need to be detected even if they have no functional impact on the tag file. For example, the addition of whitespace between XML attributes does not have any impact on the meaning of the SWID tag file, but still needs to be detected as a tag file alteration by a SWID-PC. A good guideline is that any alteration to a file that might change the value of a hash taken on the file's contents needs to be detected by the SWID-PC. 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 the "last modification" timestamp as an indication of alteration to a given tag file, but a file's last modification time can change for reasons other than modifications to the file contents. A SWID-PC 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 to the SWID tag file. In other words, while SWID-PC authors are encouraged to exclude modifications 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 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 the contents of tag files, the SWID-PC is considered compliant even if it also registers alterations that do not modify the contents of a tag file as well. When recording an alteration to a tag file, the SWID-PC is only required to note that an alteration occurred. The SWID-PC is not required to note or record how the tag file altered, nor is it possible to include such details in SWID Attributes reporting the change to a SWID-PV.

3.6. Reporting Change Events

As noted in the preceding section, SWID-PCs MUST be able to detect changes to the SWID tag repositories (tag creation, tag removal, and tag alteration) in near real-time while the SWID-PC is operational, and MUST be able to account for any net change to the endpoint's SWID tag collection that occurs when the SWID-PC is not operational. However, to be of use to the enterprise, the NEA Server needs to be able to receive these events and be able to understand how new changes relate to earlier changes. In 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 the following pieces of information:

• The nature of the change (i.e., tag creation, tag deletion, or tag alteration)
• An Event Identifier (EID) value
• An EID Epoch value

An EID is a 4-byte unsigned integer that the SWID-PC assigns sequentially to each observed event (whether detected in real-time or deduced by looking for net changes over a period 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 to ensure synchronization between the SWID-PC and any SWID-PVs with which it communicates. EID Epoch values SHOULD be generated randomly and in such a way that it is unlikely that the same EID Epoch is generated twice, even if the SWID-PC reverted to an earlier state (e.g., resetting it to factory defaults). In the case where a SWID-PC needs to reset its EID counter, either because it has exhausted all available EID values or because the SWID-PC's event log becomes corrupted, then a new EID Epoch MUST be selected.

Within an Epoch, EIDs MUST be assigned sequentially, so that if a particular event is assigned an EID of N, the next observed event is given an EID of N+1. In some cases, events might occur simultaneously, or the SWID-PC might not otherwise be able to determine an ordering for events. In these cases, the SWID-PC creates an arbitrary ordering of the events and assigns EIDs according to this ordering. Two change events MUST NOT ever be assigned the same EID within the same EID Epoch. No meaningful comparison can be made between EID values of different Epochs.

The EID value of 0 is reserved and MUST NOT be associated with any event. Specifically, an EID of 0 in a SWID Request attribute indicates that a SWID-PV wants an inventory response rather than an event response, while an EID of 0 in a SWID Response is used to indicate the initial state of the endpoint's SWID tag collection prior to the observation of any events. Thus the very first recorded event in a SWID-PC's records within an EID Epoch MUST be assigned a value of 1 or greater. Note that EID and EID Epoch values are assigned by 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 the SWID-PC will have those requests served from the same records and thus will see the same EIDs and EID Epochs for the same events.

The SWID-PC MUST ensure there is no coverage gap (i.e., change events that are not recorded in the SWID-PC's records) in its records of change events. This is necessary because a coverage gap might give a SWID-PV a false impression of the endpoint's state. For example, if a SWID-PV saw an event indicating that a particular SWID tag had been installed, and saw no subsequent events indicating that tag had been deleted, it might reasonably assume that this tag was still installed (assuming the Epoch has not changed). If there is a coverage gap in the SWID-PC's records, however, this assumption is false. For this reason, the SWID-PC's event records MUST NOT contain gaps. In the case where there are periods where it is possible that changes occurred without the SWID-PC detecting or recording them, the SWID-PC MUST either compute a net change and update its records appropriately, or pick a new 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 EID is assigned to an event, that EID cannot be reassigned to a different event, and the event cannot be assigned a different EID. When the SWID-PC's Epoch changes, all of these associations between EIDs and events are cancelled, and EID values once again become free for assignment.

3.6.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 complete list of an endpoint's inventory on a regular basis, one might wish to only identify changes since some earlier known state of this inventory. This is readily facilitated by the use of EIDs to place change events in a context relative to earlier state.

Every inventory sent by a SWID-PC to a SWID-PV (as described in Section 3.2 through Section 3.4) includes the EID Epoch and EID of the last event recorded prior to that inventory being compiled. This allows the SWID-PV to place all subsequently received event records in context relative to this inventory (since the EIDs represent a total ordering of all changes to the endpoint's SWID tag collection). Specifically, a SWID-PV (or, more likely, a database that collects and records its findings) can record an endpoint's full inventory and also the EID and Epoch of the most recent event reflected in that state. From that point on, if change events are observed, the attribute describing these events indicates the nature of the change, the affected SWID tags, and the order in which these events occurred (as indicated by the sequential EIDs). Using this information, any remote record of 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 a list of event records instead of an inventory. The message flow in such an exchange looks the same as the basic flow shown in Figure 2. The only difference is that, in the SWID Request attribute, the SWID-PV provides an EID other than 0. (A value of 0 in these fields represents a request for an inventory.) When the SWID-PC receives such a request, instead of identifying SWID tags in the endpoint's SWID tag collection, it consults its record of detected changes. The SWID-PC MUST add an event record to the SWID Response attribute for each recorded change event with an EID greater than or equal to the EID in the SWID Request attribute (although targeting of requests, as described in the next paragraph, may limit this list). A list of event records MUST only contain events with EIDs that all come from the current Epoch.

SWID-PVs can target requests for event records by including one or more tag identifiers, as described in Section 3.4, in the SWID Request that requests an event record list. A targeted request for event records is used to indicate that only events affecting SWID tags that match the provided SWID tag identifiers are to be returned. Specifically, in response to a targeted request for event records, the SWID-PC MUST exclude any event records that are less than the indicated EID (within the current EID Epoch) and exclude any event records where the affected SWID tag does not match one of the provided SWID tag identifiers. This might mean that the resulting list of event records sent in the response attribute does not provide a continuous sequence of EIDs. Both SWID-PCs and SWIC-PVs MUST support targeted request for event records.

3.6.4. Partial and Complete Lists of Event Records in SWID Attributes

Over time, a SWID-PC might record a large number of change events. If a SWID-PV requests all change events covering a large period of time, the resulting SWID Response attribute might be extremely large, especially if the SWID-PV is requesting the use of full SWID tags instead of the use of SWID Identifier instances (as described in Section 3.3.4). In the case that the resulting attribute is too large to send (either because it exceeds the 4GB attribute size limit imposed by the PA-TNC specification, or because it exceeds some smaller size limit imposed on the SWID-PC) the SWID-PC MAY send a partial list of events back to the SWID-PV.

Generation of a partial list of events in a SWID Response attribute requires the SWID-PC to identify a "consulted range" of EIDs. A consulted range is the set of event records that are examined for inclusion in the SWID Response attribute and that are included in that attribute if applicable. Recall that, if a SWID Request is targeted, only event records that involve 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 the considered range are applicable and included in the SWID Response attribute.

The lower bound of the consulted range MUST be the EID provided in the SWID Request. (Recall that a SWID Request indicates a request for event records by providing a non-0 EID value in the SWID Request. See Section 3.6.3.) The upper bound of the consulted range is the EID of the latest event record (as ordered by EID values) that is included in the SWID Response attribute if it is applicable to the request. The EID of this last event record is called the "Last Consulted EID". The SWID-PC chooses this Last Consulted EID based on the size of the event record list it is willing to provide to the SWID-PV.

A partial result list MUST include all applicable event records within the consulted range. This means that for any applicable event record whose EID is greater than or equal to the EID provided in the SWID Request and whose EID is less than or equal to the Last Consulted EID, that event record MUST be included in the SWID Response conveying this partial list of event records. 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 the EID of the last event record known to the SWID-PC at the time that the SWID Response attribute was generated. The Last EID might or might not be part of the consulted range. As noted above, the Last Consulted EID field contains the EID of the last event record in the consulted range. The Epoch field contains the EID Epoch associated with the Last EID and Last Consulted EID fields as well as all the EIDs in event records contained within the SWID Response attribute. Note that, if responding to a targeted SWID Request, the SWID Response attribute might not contain the event record whose EID matches the 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 SWID tag identifiers in the SWID Request.

If a SWID-PV receives a SWID Response attribute where the Last EID and Last Consulted EID fields are identical, the SWID-PV knows that it has received a result list that is complete, given the parameters of the request, up to the present time. On the other hand, if the Last EID and Last Consulted EID values differ, the SWID-PV has received a partial result list. In the latter case, if the SWID-PV wishes to try to collect the rest of the partially delivered result list it then sends a new SWID Request whose EID is one greater than the Last Consulted EID in the preceding response. Doing this causes the SWID-PC to generate another SWID Response attribute containing event records where the earliest reported event record is the one immediately after the event record with the Last Consulted EID (since EIDs are assigned sequentially). By repeating this process until it receives a SWID Response where the Last EID and Last Consulted EID are equal, the SWID-PV is able to collect all event records over a given range, even if the complete set of event records would be too large to deliver via a single attribute.

Implementers need to be aware that a SWID Request might specify an EID that is greater than the EID of the last event recorded by a SWID-PC. In accordance with the behaviors described in Section 3.6.3, a SWID-PC MUST respond to such a request with a SWID Response attribute of the appropriate type (using SWID tags or SWID tag identifier instances as specified in 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 the EID in the SWID Request. In such a case, the Last Consulted EID field MUST be set to the same value as the Last EID field in this SWID response attribute. This case is called out because consulted range on a SWID-PC in such a situation is a negative range, where the "first" EID in the range (provided in the SWID Request) is greater than the "last" EID in the range (this being the EID of the last recorded event on the SWID-PC). Implementers need to ensure that SWID-PCs do not experience problems in such a circumstance.

Note that this specification only supports the returning of partial results when returning event records. There is no way to return a partial inventory list under this specification.

3.6.5. Synchronizing Event Identifiers and Epochs

Since EIDs are sequential within an Epoch, if a SWID-PV's list of event records contains gaps in the EID values within a single Epoch, the SWID-PV knows that there are events that have not been accounted for. The SWID-PV can either request a new event list to collect the missing events or request a full inventory to re-sync its understanding of the state of the SWID tags on the endpoint. In either case, after the SWID-PV's record of the endpoint's SWID tag collection has been updated, the SWID-PV 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 to track the endpoint's SWID tag collection knows that there is a discontinuity in their understanding of the endpoint's state. To move past this discontinuity and reestablish a current understanding of the state of the endpoint's SWID tag collection, the SWID-PV needs to receive a full inventory from the endpoint. This is because it is not possible to account for all events on the SWID-PC over the interval since the previous Epoch was used, because there is no way to query for EIDs from a previous Epoch. Once the SWID-PV has received a full inventory for the new Epoch, the SWID-PV records the latest EID reported in this new Epoch and can track further events normally.

A SWID-PC MUST NOT report events with EIDs from any Epoch other than the current EID Epoch. The SWID-PC MAY choose to purge all event records from a previous Epoch from memory after an Epoch change. Alternately, the SWID-PC MAY choose to retain some event records from a previous EID Epoch and assign them new EIDs in the current Epoch. However, in the case where a SWID-PC chooses the latter option it MUST ensure that the order of events according to their EIDs is unchanged and that there is no coverage gap between the first retained event recorded during the previous Epoch (now reassigned with an EID in the current Epoch) and the first event recorded during the current Epoch. In particular, the SWID-PC MUST ensure that all change events that occurred after the last recorded event from the previous Epoch are known and recorded. (This might not be possible if the Epoch change is due to state corruption on the SWID-PC.) A SWID-PC might choose to reassign EIDs to records from a preceding Epoch to create a "sliding window" of events, where each Epoch change represents a shift in the window of available events.

In the case where a SWID-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 SWID-PC MUST purge all event records from before the crash as it cannot ensure that there is not a gap between the last of those records and the next detected event. The process for generating a new EID Epoch MUST minimize the possibility that the newly generated EID Epoch is the same as a previously used EID Epoch.

The SWID-PV will normally never receive an attribute indicating that the latest EID is less than the latest EID reported in a previous attribute within the same EID Epoch. If this occurs, the SWID-PC has suffered an error of some kind, possibly indicative of at least partial corruption of its event log. In this case, the SWID-PV SHOULD treat the situation as if there was a change in Epoch and treat any local copy of the endpoint's SWID tag collection as out-of-sync until 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 is that it is possible for multiple instances of a SWID tag to be present on an endpoint. (I.e., multiple SWID tag files whose tag identifiers are the same.) This can happen if there are multiple instances of the indicated software product installed on the endpoint. In order to account for the possibility, all SWID-PCs MUST follow specific rules, outlined below.

3.7.1. Inventory Reporting in the Presence 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 of a relevant tag. (All tags are relevant in a full inventory. In a targeted request for an inventory, only tags that match the tag identifiers provided by the SWID-PV are considered relevant.) For example, if a particular piece 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.) 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 multiple copies of one tag instance. In the case where the SWID-PC's response is expressed using tag identifiers, the response MUST include the tag identifier instance for each instance of the given tag.

3.7.2. Event Reporting in the Presence of Multiply Instantiated Tags

When reporting events, the specific tags that were added, deleted, or changed MUST be indicated. For example, in the case where tags A and B are two instances of the same SWID tag, each for separate installations of the same software product, and tag A changes in the endpoint's SWID tag collection, the SWID-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 the tag identifier instance for the affected tag.

3.8. Subscriptions

Thus far, all message exchanges discussed assume that a SWID-PV sent an SWID Request attribute and the SWID-PC is providing a direct response to that request. The SWID Message and Attributes for PA-TNC specification also supports the ability for a SWID-PC to send a message with a SWID Attribute to the SWID-PV in response to observed changes in the endpoint's SWID tag collection, instead of in direct response to a SWID Request. An agreement by a SWID-PC to send content when certain changes are detected to the endpoint's SWID tag collection is referred to in this specification as a "subscription", and the SWID-PV that receives this content is said to be "subscribed to" the given SWID-PC. All SWID-PCs and SWID-PVs MUST support the use 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 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 to this SWID Request attribute, just as if the Subscription flag was not set. As such, the message exchange that establishes a new subscription in a SWID-PC has the same flow seen in the previous message exchanges, as depicted in Figure 2. If the SWID-PV does not receive a PA-TNC Error attribute (as described in Section 3.10 and Section 4.16) in response to their subscription request, the subscription has been successfully established on the SWID-PC. The SWID Request attribute that establishes a new subscription is referred to as the "establishing request" for that subscription.

When a subscription is established it is assigned a Subscription ID value. The Subscription ID is equal to the value of the Request ID of the establishing request. (For more about Request IDs, see Section 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 multiple parties.

3.8.2. Managing Subscriptions

The SWID-PC MUST record each accepted subscription along with the identity of the party to whom attributes are to be pushed in compliance with the subscription. If the attribute is received by the SWID-PC using the TNC_IMC_ReceiveMessage (section 3.8.4 of IF-IMC 1.3 [IF-IMC]) function, then only the connection ID of the SWID-PV's NEA Server is available to the SWID-PC. If the attribute is received by the SWID-PC using the TNC_IMC_ReceiveMessageLong function (section 3.8.6 of IF-IMC) then the SWID-PC has both the NEA Server's connection ID and the Posture Validator ID of the sending SWID-PV. SWID-PCs SHOULD support TNC_IMC_ReceiveMessageLong function calls. SWID-PCs MUST record the connection ID of the SWID-PV's NEA Server for each accepted subscription. SWID-PCs SHOULD record the SWID-PV's Posture Validator ID for each accepted subscription if this information is available.

Likewise, SWID-PVs MUST record each accepted subscription for which they are the subscribing party along with its Subscription ID and the identity of the SWID-PC that will be fulfilling the subscription. The SWID-PV needs to retain this information in order to correctly interpret pushed SWID Response attributes sent in fulfillment of the subscription. As with the SWID-PC, the SWID-PV might only have access to the connection ID of the SWID-PC's endpoint, or might have both this connection ID and the SWID-PC's Posture Collector ID depending on the supported IF-IMV functions [IF-IMV]. SWID-PVs SHOULD support TNC_IMV_ReceiveMessageLong function calls so as to be capable of receiving the SWID-PC's Posture Collector ID. SWID-PVs MUST record the connection ID of the SWID-PC's endpoint for each accepted subscription. The SWID-PV SHOULD record the SWID-PC's Posture Collector ID for each accepted subscription if this information is available.

3.8.3. Terminating Subscriptions

Subscriptions MAY be terminated at any time by the subscribing SWID-PV by setting the Clear Subscriptions flag in a SWID Request. (See Section 4.9 for more on using this flag.) In the case that the SWID-PC receives both the connection ID and the Posture Validator ID of the SWID-PV requesting that subscriptions be cleared (i.e., the clear subscription request is received via a TNC_IMC_ReceiveMessageLong function) and the SWID-PC has been recording PV IDs associated with subscriptions when available, the SWID-PC MUST only clear subscriptions that match both the connection ID and the PV ID, and MUST clear all such subscriptions. In the case that the SWID-PC only has the connection ID of the party requesting that subscriptions 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 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 are cleared when the Clear Subscriptions flag is set.

This specification does not give the SWID-PC the ability to unilaterally terminate a subscription. However, if the SWID-PC experiences a fatal error fulfilling a subscription, resulting in sending a PA-TNC Error attribute of type SWID_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose fulfillment led to the error MUST be treated as terminated by both the SWID-PC and the SWID-PV. Only the subscription experiencing the error is cancelled and other subscriptions are unaffected. See Section 3.10 for more on this error condition.

Finally, a subscription is terminated if the connection between the SWID-PC and SWID-PV is deleted, as indicated by the connection state changing to DELETE. (Described in section 3.5.2.2 of IF-IMC [IF-IMC] and section 3.5.2.2 of IF-IMV [IF-IMV].) Doing this renders the SWID-PC incapable of pushing additional SWID Response attributes to the subscribing party. Both the SWID-PC and SWID-PV MUST delete all subscriptions for which the connection has been deleted. SWID-PCs MUST support the TNC_IMC_NotifyConnectionChange function, as defined in IF-IMC 1.3 section 3.8.2, so that the SWID-PC can be informed when a connection's state changes to DELETE. Likewise, a SWID-PV MUST support the TNC_IMV_NotifyConnectionChange function, as defined in IF-IMV 1.4 section 3.8.2, for the same reason.

3.8.4. Subscription Status

A SWID-PV can request that a SWID-PC report the list of active subscriptions where the SWID-PV is the subscriber. A SWID-PV can use this to recover lost information about active subscriptions. A SWID-PV can also use this capability to verify that a SWID-PC has not forgotten any of its subscriptions. The latter is especially useful where a SWID-PC does not send any attributes in fulfillment of a given subscription for a long period of time. The SWID-PV can check the list of active subscriptions on the SWID-PC and verify whether the inactivity is due to a lack of reportable events, or due to the SWID-PC forgetting its obligations to fulfill a given subscription.

A SWID-PV requests a list of its subscriptions on a given SWID-PC by sending that SWID-PC a Subscription Status Request. The SWID-PC MUST then respond with a Subscription Status Response (or a PA-TNC Error if an error condition is experienced). The Subscription Status Response contains one subscription record for each of the active subscriptions for which the SWID-PV is the subscribing party. Specifically, in the case that the Subscription Status Request arrives with both a connection ID and a Posture Validator ID and the SWID-PC has been recording Posture Validator IDs associated with subscriptions when available, the SWID-PC MUST include only subscription records associated with both the given connection ID and Posture Validator ID, and MUST include all such records. In the case that the Subscription Status Request arrives with only a connection ID or the SWID-PC has not been recording Posture Validator IDs associated with subscriptions even when available, the SWID-PC MUST include only subscription records associated with the given connection ID and 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 to an endpoint's SWID tag collection in near real-time. For every active subscription, the SWID-PC MUST send an attribute to the subscribed SWID-PV whenever a change is detected to relevant tags within the endpoint's SWID tag collection. The SWID-PC MAY choose to exclusively deliver this attribute in the case that the SWID-PV's Posture Validator ID is known. (See section 3.3.2.2 of IF-IMC 1.3 [IF-IMC] or section 3.3.2.2 of IF-IMV 1.4 [IF-IMV] for more on exclusive delivery.) Such an attribute is said to be sent "in fulfillment of" the given subscription and any such attribute include that subscription's Subscription ID. If the establishing request for that subscription was a targeted request, then only tags that match the SWID tag identifiers provided in that establishing request are considered relevant. Otherwise, (i.e., for non-targeted requests) any tag is considered relevant for this purpose. Figure 3 shows a sample message exchange where a subscription is established and then later messages are sent from the SWID-PC in fulfillment of the established subscription.

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

	

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

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

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

	   

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

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

	

     
                     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                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 			Earliest EID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Tag Creator Length          | Tag Creator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Unique Software ID Length   |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags        | 		Tag ID Count                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 		Request ID Copy / Subscription ID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			 EID Epoch                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 			 Last EID			        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag Creator Length            | Tag Creator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length     |Unique Software ID (var length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID Length 		| Instance ID (var length)      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags        |                Event Count                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Request ID Copy / Subscription ID                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       EID Epoch                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			 Last EID                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 		Last Consulted EID                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|			   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)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     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                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Instance ID Length |  Instance ID (var length)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Tag Length                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Tag (Variable)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     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   |        Instance ID Length     |Instance ID (v)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Tag Len                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Tag (Variable)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     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          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         |                   Tag ID Count                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Request ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Earliest EID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Tag Creator Length      | Tag Creator (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique Software ID Length     |Unique Software ID (var length)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Copy of Request ID / Subscription ID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Description (variable length)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Subscription ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   |           Sub Error Code Vendor ID            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             Sub Error Code                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Sub Error Information (Variable Length)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 1]<?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>