Hi Philippe,

    The document you commented on was from last week's discussion.  

Your input is appreciated and you're opinion is lining up 

with some of the thoughts expressed as part of the external identifier

proposal from 2 weeks ago from Bill Schineller.

Kate

On Tue, Aug 4, 2015 at 8:34 AM, Philippe Ombredanne <pombredanne@...> wrote:

On Tue, Aug 4, 2015 at 5:00 AM, Yev Bronshteyn
<ybronshteyn@...> wrote:
> Here is the spec for the proposed EternalPackage element. While I touch on
> usage in the beginning, I'll discuss some specific use cases in the context
> of SpdxTools on the call.
>
> https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharinghttps://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit?usp=sharing
>

Yev:
I guess you meant External and not Eternal....

I provided a few comments to your proposed spec in the doc at
https://docs.google.com/document/d/1WfArS8_xR_CQ_5plOOMtj1y9ps5M-gXFjofUBXR8hyE/edit#

The gist of my feedback:
- SWID tags are a nice concept but look to me at best new and may be
emerging, and at worst an unknown quantity fraught with many issues:
 - no open neutral registry (like a IANA);
 - little or no known usage in the FOSS world and no known usage by
any Linux distro as far as I know;
 - a de-jure standard backed primarily by commercial entities for
commercial licensing compliance, with a closed and pay-walled-garden
called tagvault.org;
 - little general adoption that I could find beyond a few commercial
vendors of asset management tools and a few (albeit large) commercial
software vendors like Microsoft;
 - and yet another new standard on top of another standard: based on
the NIST discussion draft you provided the ambition of SWID tags seems
to be a rehash on top CPEs.

- Why limit the purpose to security? identification has a rather
general purpose.

- Why limit an external id to CPE and SWID tags? There are several
other sources of (rather widely used) globally unique ID:
 - Linux distros package name/version
 - other package managers name/version such as npm, rubygems, pypi, maven, etc
 - repo or project names on hosting sites such as Github, Google Code
(RIP), Apache, Eclipse, Sourceforge and several others.

All these should be supported and are IMHO far better and more widely
used that SWID tags. Hence my suggestion for something more inclusive
and generic.

An interesting question is how you map these to one another: for
instance what is the corresponding Debian package for a Fedora RPM?
What would be the common id for the upstream of these two packages?
What is the corresponding CPE if any?

--
Cordially
Philippe Ombredanne

_______________________________________________
Spdx mailing list
Spdx@...
https://lists.spdx.org/mailman/listinfo/spdx