[sacm] SWIMA and Data Models

["Schmidt, Charles M." <[e-mail]>]

Hello all,

In last week's virtual interim meeting we did not have time to discuss the recent changes to how data models are handled in the latest SWIMA draft. Hence, these questions are going to the list. References to the current draft are to draft-ietf-sacm-nea-swid-patnc-00 (https://datatracker.ietf.org/doc/draft-ietf-sacm-nea-swid-patnc/). References to issue numbers are from the Software Identification GitHub tracker (https://github.com/sacmwg/software-identification).

== Multiple open issues were addressed in the latest draft.
Issue #5 - Clarify that the SW M&A must accept all data models
Section 3.2 addresses this. Specifically, it notes that servers "MUST NOT reject a record or respond with a PA-TNC Error due to the data model used in attributes it receives." The section goes on to note that, while servers have no dependency on parsing the records they receive, downstream components that consume the collected information might. However, it notes that is strictly concerned with conveying the information that a Collector finds, and that filtering that available data by data model would be the responsibility of those downstream components.

Are people comfortable with this?

== Issue #6 - MTI data models
Section 3.2 addresses this. It notes that Validators have no dependency on the type of data models they receive (and thus "MTI" for them is a meaningless concept) and that the job of Collectors is to convey the data that their sources make available (and we cannot reasonably demand that the endpoint utilize certain data models). Thus the only dependency SWIMA has on the data model is the requirement that Collectors be able to deterministically generate Software Identifiers from each record it delivers. This requires that Collectors know the algorithm to do this for each supported data model. The section goes on to note that all Collectors MUST at least support the data models identified in section 5 of the specification. Section 5 identifies ISO 2015 SWID Tags using XML and ISO 2009 SWID Tags using XML, and defines the procedures for generating Software Identifiers from each.

Are people comfortable with this?

== Procedures for generating Software Identifiers from SWID tags
Sections 5.1.2 (for SWID 2015) and 5.2.2 (for SWID 2009) contain procedures for generating Software Identifiers from the respective versions of these SWID tags. Currently, the Identifiers are "a concatenation of the value of the Tag Creator RegID field and the Unique ID field.  Specifically, it MUST be of the form:  NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID, where NUMBER is the length of TAG_CREATOR_REGID in bytes."
If one wished to decompose this Software Identifier, one would read until the ::, convert that into a integer, read that many bytes as the Tag Creator RegID, and then read the remainder of the bytes into the Unique ID. 

A comment was made that an easier procedure would be to use a delimiting character to separate the Tag Creator RegID  and the Unique ID values. In the case of 2015 SWID tags, the Tag Creator RegID is required to be a URI, and thus we could use whitespace as such a delimiter. Unfortunately, the only restriction on the Tag Creator RegID imposed by the 2009 spec is that "all characters are valid for use in filenames on any platforms the tag will be installed on", so in this case a delimiting character is not possible. The question thus becomes: do we use a delimiter in the 2015 SWID tag Software Identifier (because we can), or do we have both use the same NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID format for the sake of consistency?

For the sake of providing a yes/no question: are people comfortable with having both 2015 and 2009 use the NUMBER "::" TAG_CREATOR_REGID UNIQUE_ID format for Software Identifiers so both can use the same procedures?

== Other Data Models?
Section 5 describes the use of ISO 2015 SWID Tags using XML and ISO 2009 SWID Tags using XML as data models. SWIMA is not limited to conveying information using these data models, but 1) the data models described in this section are MTI (according to section 3.2 of the document) and 2) the fact that the document directly provides procedures for these makes them easier to use. Are there other data models that are reasonable to use in this specification directly (noting that the Software Data Models IANA table can easily be extended at a later date to identify new data models and their associated procedures for generating Software Identifiers?

Are ISO 2015 SWID Tags using XML and ISO 2009 SWID Tags using XML sufficient data models for initial release of SWIMA?

Thanks,
Charles