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 (#4736): https://lists.spdx.org/g/Spdx-tech/message/4736
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]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to