FAQ

• Why creating yet another standard with a purl?

  • You were about to "XKCD" me with a link to https://xkcd.com/927/: this not entirely correct. There is no such standard URL like a purl: only some attempts to define something similar. Therefore a purl is not another standard but instead can be the standard. Furthermore, it is a grassroot effort to define conventions to reference and locate packages and builds on, embraces and clarifies existing conventions used by many existing tools dealing with many software packages.

• Can I use an existing URL parsing library to parse a purl?

  • Yes and this is highly encouraged! A purl is a valid URL and should be parseable by any conforming URL/URI parser (that at least can accept any scheme). You can then focus on the specific of purl component encoding and decoding, component normalization and additional parsing (e.g. for qualifiers) and component value validation.

• Can I use a subpath with multiple subpaths, globs or regexes in a purl?

  • No. Use multiple purl or other attributes outside of a purl.

• Why is the purl version optional?

  • This is to support pointers to any version of a package or when you do not know the version (yet). This should not be abused but is useful and used in practice: for instance a package version may depend on another package with no version specified.

• Can I use the Authority of a URI/URI in a purl?

  • No. There are several reasons: The rules for parsing user/host/password and ports are complex and more so when you add IDAN, ppunycode and IPv4/v6. These would introduce subtle quirks if for instance the user/password was used as a purl version.

    Also while host may be important to locate a package it is not required to identify it: the exact same package may exist in multiple repositories, local, remote or private mirrors. This is still the same package.

    And the Autority comes before the Path in a URL: this would break the hierachical nature of the purl components and no longer make them nicely sortable as plain strings: this a good property when dealing with many purl in a database or even small lists in a UI.

• Can I use a CPE instead of a purl

  • Not really CPE https://en.wikipedia.org/wiki/Common_Platform_Enumeration are URIs and fairly close to purl concepts but they are rather complex and there are subtle differences: cpe:2.3:a:artifex:ghostscript:8_64:*:*:*:*:*:*:*

    CPEs started from the world of proprietary software security and require a 'vendor' attribute before the 'name' attribute, somewhat similar to a purl namespace but not exactly. These names are assigned centrally and arbitrarily assigned by NIST and Mitre. For instance, the vendor for zlib is GNU: this does not make any sense.

    In contrast, purl names are not centrally or arbitrarily assigned or created: they are naturally and directly derived from whatever names a package author picked. Also CPEs specifies rather complex version semantics and can be hard to parse and build. Overall, they often mesh poorly with the world of software packages.

    Yet they are a great additional reference when they exist to relate a package to known NVD vulnerabilities. A valuable side project could create mappings of purl to known CPEs.

• Why not using the ISO 19770-2 spec for SWID tags instead of a purl?

  • Avoid this. This is a proprietary and opaque specification with a centrally managed pay-for-play registry (tagvault). Its purpose is primarily to help inventory installed proprietary software when managing IT assets by assign arbitrary tags to a software binary.

    In contrast a purl is an open way to identify and locate a software package as used in modern software development with no arbitrary central name assignments needed.