Clarification on `default_repository_url` in type definition and `repository_url` in qualifiers

[yan-foto]

tl;dr

Assumption: If a type definition does not include a default_repository_url, then repository_url must be a required qualifier so that respective PURL conforms to the definition of URL in RFC3986.

Is this correct?

Details

The specification states "PURL is a URL". As such I would expect a PURL to be an actual locator, i.e., pointing me to a location that I can fetch the "package" that PURL is identifying, just as a URL should do:

The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location").
-- RFC3986

So if a type definition does not provide a default_repository_url, then I'd expect that repository_url qualifier to be present.

Does this assumption align with what PURL should be?

[matt-phylum]

Counterexample: pkg:golang does not have a default repository URL and does not need a repository URL because Go has a system where the package ID v.io (pkg:golang/v.io) is resolved to code files without requiring any registry or repository: https://go.dev/ref/mod#vcs-find .

[yan-foto]

@matt-phylum that is a very good point.

In Go, however, namespace + name is the repository URL. So I'd argue that a Go PURL is still a proper locator.

I wrote this issue as I was looking at the definition of swid, specifically the examples:

purl-spec/types/swid-definition.json

Lines 57 to 61 in 875da6c

	"examples": [
	"pkg:swid/Acme/example.com/Enterprise%2BServer@1.0.0?tag_id=75b8c285-fa7b-485b-b199-4745e3004d0d",
	"pkg:swid/Fedora@29?tag_id=org.fedoraproject.Fedora-29",
	"pkg:swid/Adobe%2BSystems%2BIncorporated/Adobe%2BInDesign@CC?tag_id=CreativeCloud-CS6-Win-GM-MUL"
	]

I would expect that an SWID PURL would point to the location of the SWID file.

EDIT:
Another thing that might need clarification: you mentioned that go can does not need the explicit repository URL. That is correct but two thoughts:

1. It has an algorithm to build that URL.
2. My assumption is that the consumer of a PURL is not necessarily aware of such internal algorithms.

So I'd argue that the PURL must include all info necessary to reconstruct a valid URL.

[mjherzog]

For better or worse the current PURL spec does not require that a PURL include all information necessary to reconstruct a valid URL. This is primarily because there are use cases where location is not required because the goal is to identify a package, not necessarily to download it.
And in many like the 'golang' example from Matt, there are algorithms or tools to build a URL from PURL data that does not include an explicit URL.
It is allowed, but discouraged, to require, a qualifiers key like 'repository_url' for a particular PURL type.
For the current update cycle for ECMA-427 2nd Edition (closing end of this month) our focus has been on clarifying (1) canonical form and (2) 'required' ("shall" in the spec) versus 'recommended' ("should" in the spec) rules and behaviors.

[yan-foto]

Thanks @mjherzog for the elaboration!

I searched the type definitions for "use_repository": false and there are only 3 types that match:

• generic: understandable.
• otp: mentions that repository_url is desirable and all provided examples have it.
• swid: this shouldn't be a PURL type at all IMO. It is requires tag_id, a globally unique identifier, and there's no need to wrap it in a PURL to create an ID.

The rest either has a default repository, note that the repository can be reconstructed from other components, or mention that repository_url is encouraged. That solves the locator issue for me. Thanks again for the clarification.

After reading your answer, I have some more questions below, that I appreciate if you could take a look at. Please excuse me in advance for being pedantic.

---

1. Locator property of PURL

To avoid confusion: I don't expect PURLs to be directly mapped to a Web URL (http/https scheme). But I'd still expect them to be locators, i.e., allow me to locate the package they are identifying. This would be in line with the specs:

A PURL is a valid URL because it is a locator even though it has no Authority URL component: each type has a default repository location when defined.

And RFC1736 defines a locator as:

A general resource locator is an object that describes the location of a resource.

So my question is now if the terminology used in the specs aligns with the RFC definition of a URL (and related RFCs)?

2. Discouraged qualifier keys

It is allowed, but discouraged, to require, a qualifiers key like 'repository_url' for a particular PURL type.

Why is it discouraged? Only for repository_url? I'm building a simple linter in my PURL library and it would be interesting to integrate this type information.

3. PURL as identifier

[…] there are use cases where location is not required because the goal is to identify a package […]

There are cases that the repository, where a package originates from, is part of the identity. For example, There are maven packages that are present in multiple repositories under the same artifact/group ID but with (slightly) different payloads. So I'd need the repo to uniquely identify the package.

[mjherzog]

@yan-foto First - you are not pedantic, just showing good attention to detail.

1. Locator property of PURL: My answer is that we use the RFC 3986 as our primary reference, but PURL needs to support use cases where it may provide identity without a locator. We may need to update the Core Spec to clarify this point.
2. Discouraged qualifiers keys: Also related to the non-locator use cases.
3. PURL as identifier: Agreed that there are many use cases that require the precision of a locator/URL, but there are others that do not.
   Please see the related discussion points in RPM definition missing qualifiers entries for repository_url and distro #935 .