Define namespace for new "scid" PURL type

[mjherzog]

Background

With all deference to the the original idea from @stevespringett and commentary from the community in:

• New scid PURL type for non-packaged software #516

I have created this separate issue in response to community suggestions that we focus on the namespace question on its own. The rationale is that:

• namespace is the gating item for definition of a new 'scid' PURL type
• We may need to include name in this discussion, but it is not clear why name would be different than for other PURL types
• There is nothing special about version for a 'scid' PURL type
• Examples of how to use qualifiers in the 'scid' context may be helpful, but qualifiers are always available
• There is nothing special about subpath for a 'scid' PURL type

For convenience I have copied the outline of the original 'scid' proposal with 2 changes:

• Changed 'vendor' to 'supplier'. If we want one new PURL type to cover both proprietary and open source software we need a more neutral term than 'vendor'; 'publisher' is another option.
• Simplified the qualifiers to a placeholder in the PURL string and the table.

Proposed 'scid' PURL type syntax

pkg:scid/<domain>/<publisher>/<component>@<version>?<qualifiers>#<subpath>

Field Breakdown

Field	PURL Component	Required	Description
domain	namespace	Yes	Internet domain name of the entity making the claim (e.g., publisher, distributor).
supplier	namespace	Yes	Human-readable name of the software creator, distributor or supplier (e.g., Microsoft, Acme Corp, or FOSS project).
component	name	Yes	Name of the actual software product, project, or application.
version	version	Optional	Version string identifying the specific release, tag, or snapshot of the product.
	qualifiers	Optional	One or more relevant attributes of a PURL stated as a key-value pair.
	subpath	Optional	The subpath optionally identifies a specific module, subcomponent, or file within a software package.

I have not copied over the Why Both Domain and Vendor Are Required section from #516 here, but you should read that section carefully if you have not done so already.

Scope

The scope of this issue is to define the structure for the namespace component for a new 'scid' PURL type so that it can identify a software package/component in combination with the name component. Some assumptions/considerations:

• namespace will be a required PURL component for the 'scid' type
• namespace may have more segments than domain and supplier. Suggestions include a segment to specify a sub-organization of 'supplier', a product line or some other <supplier-specific-namespace>.

The scope of this issue does not include:

• Specifying a URL or other locator for the software - that will be discussed separately.
• A requirement to "register" a 'scid' namespace in order for it to be valid. Conformance with the spec ('base' test_group) will only require that the 'scid' PURL namespace syntax is correct. Tools may choose to validate a 'scid' namespace value against a registry and document this in 'advanced' test_group test cases.

NB: I have done my best to include relevant points from the discussion in issue #516 but I have probably missed some.

[mjherzog]

Some interesting commentary on domain names as used in RFC 7595
https://www.rfc-editor.org/rfc/rfc7595.html#section-3.8

"Some organizations desire their own namespace for URI scheme names
for private use (see Section 6). In doing so, it is important to
prevent collisions and to make it possible to identify the owner of a
private-use scheme. To accomplish these two goals, such
organizations SHOULD use a prefix based on their domain name,
expressed in reverse order. For example, a URI scheme name of
com.example.mything might be used by the organization that owns the
example.com domain name. Care must be taken, however, if the
organization later loses the domain name embedded in their scheme
names since domain name registrations are not permanent. To
associate the private-use scheme name with the original organization,
the private-use scheme can be registered using the registration
procedure in Section 7.

Furthermore, to prevent collisions with private-use scheme names, new
scheme names registered MUST NOT contain a "." unless actually
constructed from a reversed domain name."

[pombredanne]

I am proposing an alternative for namespaces in:

• Register new PURL type: cid or sid for packages that do not have a registry #837

The idea there is not to define a supplier segment at all. Instead define optional slash-separated segments that can be anything. Optional removes the burden of definition, and free content can be used both as supplier or something else, like subproject names, or else.