The fields of a CPE (part, vendor, product, etc) can be serialized (bound) to the string format and recovered (unbound) from the string format using the algorithms defined in chapter 6 of https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf. The algorithms aren't trivial, and CPE 2.3 introduced the Well Formed CPE Name (WFN) model to avoid them: "The WFN concept and the bindings defined by the CPE Naming specification are the fundamental building blocks at the core of all CPE functionality."
So although the output of the URN binding is a simple string, the processing required to generate it isn't simple. If SPDX applications only pass around CPEs as opaque blobs, then string blobs are the simplest. But if applications use the CPEs (e.g., to filter by vendor), serializing the structures directly is simpler than parsing strings into structures. Regards, David On Thu, Aug 11, 2022 at 1:05 AM Karsten Klein <[email protected]> wrote: > Hi all, > > I would try to keep the processing/interpretation of CPEs to a minimum. As > such I would > > - use the string representation > - ensure that escaping is applied consistent to the spec > - remove trailing :* as these do not convey any further information > > This way we rely only on few aspects on the interpretation of CPEs. In > particular we also stable in respect to further dimensions being added in > the future. > > My vote in for the string option with above consolidation for > canonicalization. > > Regards, > Karsten > > > metaeffekt GmbH > Firmensitz: Renettenweg 6/1, 69124 Heidelberg > Registergericht: Amtsgericht Mannheim, HRB 725313 > Geschäftsführer: Karsten Klein > USt.-IdNr.: DE307084554 > > Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen > beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren > Sie bitte den Absender und löschen Sie diese E-Mail und alle Kopien > umgehend. Eine unbefugte Weitergabe der E-Mail oder deren Inhalte und > Anhänge ist nicht gestattet. > > Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen > Sie sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die > metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle > Selbstbestimmung und übermittelt Informationen ausschließlich auf der > Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). > Weitere Informationen zu den Datenverarbeitungsvorgängen und insbesondere > Ihrer Rechte entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH < > http://www.metaeffekt.com/files/metaeffekt-data-privacy_v2018-05-29.pdf>. > > > On 06.08.22, 01:21, "Sebastian Crane" <[email protected] on > behalf of [email protected]> wrote: > > Dear all, > > We had a very productive Canonicalisation Committee meeting today, in > which we > explored the many aspects of CPEs and discussed their representation > in the SPDX > Canonical Serialisation. There are two forms of CPE which we support > as External > Reference Types in SPDX: CPE version 2.2 from 2009, and CPE version 2.3 > from 2011. They differ a little from each other in terms of their > usual string > representation, but share the same basic constructs. > > During the meeting, we came up with three different JSON > representations that > would be suitable for encoding CPE information unambiguously. As all > three could > be used in the Canonical Serialisation, we decided to call a vote as > to which > was preferred by the SPDX community, including tooling developers > intending to > support the Canonical Serialisation for SPDX 3.0. Please feel free to > vote, and > make sure to cast it by means of a reply on this mailing list! :) > > > > -------------------------------------------------------------------------------- > > 'Object' option: > > > {"part":"a","product":"php5-common","vendor":"debian","version":"5.3.2-1"} > > 'Array' option: > > ["a","debian","php5-common","5.3.2-1"] > > 'String' option: > > "cpe:2.3:a:debian:php5-common:5.3.2-1:*:*:*:*:*:*:*" > > > > -------------------------------------------------------------------------------- > > Please note that the Object option has key-value pairs sorted > alphabetically by > their key's name, as will be the case for all objects in the SPDX 3.0 > Canonical > Serialisation. > > Versions 2.2 and 2.3 of the CPE specification are similar enough that > we'll use > the same format for both of them in the Canonical Serialisation. > > An important factor that we will discuss later (and which we're not > voting on > here) is how null (wildcard) attributes are represented. In these > examples, I've > omitted the null attributes for the Object and Array options, leaving > out the > entire key-value pair (for Object) and the null array elements > (Array). We could > just as easily define that the String option must also have trailing > null > attributes removed, and conversely we could specify that all > attributes are > present for the Object and Array options, requiring a special value > (such as > NULL or the empty string) as its value. > > I'll count the votes on Thursday the 11th of August. Feel free to > discuss the > relative merits of the options here on the mailing list, and I look > forward to > seeing which option wins! :) > > Best wishes, > > Sebastian > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4737): https://lists.spdx.org/g/Spdx-tech/message/4737 Mute This Topic: https://lists.spdx.org/mt/92846339/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
