Clarifying the format of "spec_version"

[erickt]

The spec defines the spec_version" as:

SPEC_VERSION is the version number of the specification. Metadata is written according to version "spec_version" of the specification, and clients MUST verify that "spec_version" matches the expected version number. Adopters are free to determine what is considered a match (e.g., the version number exactly, or perhaps only the major version number (major.minor.fix).

Two requests:

• The document implies that spec_version is a string. Could this be explicitly mentioned?
• The document does not describe the format of the spec_version string. Can it contain arbitrary values, or is it only to be semver compatible?

Would it be acceptable to submit PRs to change the spec, or would these changes need to go through TAPs first?

[erickt]

Also, does "SPEC_VERSION is the version number of the specification" mean the TUF specification, or can servers/clients customize it? Say we wanted to standardize our custom fields. Can we add this metadata in the spec_version, as in 1.0+my-customizations-1.2, or would it be better to track this as separate metadata, as in:

 { "_type" : "root",
   "spec_version" : SPEC_VERSION,
   "custom": { "my-customizations": "1.2" },
   ...

[mnm678]

The spec_version should be semver compatible.

If there are custom versions, these can be added through profiles (theupdateframework/taps#106), which are added to root as separate metadata, for example:

{ "_type" : "root",
   "spec_version" : SPEC_VERSION,
   "profile": PROFILE_NUMBER,
   ...