Given the current state of the shorthand vector after #64, and in the process of reviewing #86 I have the following suggestions:

• replace SSVCv2/... with either SSVC/2/... or SSVC/v2/... -- "ssvc" as a namespace, "version" is just a string
• all timestamps should be in ISO 8601 YYYY-mm-ddTHH:MM:SS±TZ format including TZ, with UTC implied if no TZ specified
• (moved to Add Vul ID to SSVC vector format #108) consider including a slot for a vul ID. This needn't be CVE, could be VU#, JVN#, or just a locally-relevant case number from a ticketing system or scan finding ID. I'd probably put it closer to the front than back, so maybe SSVC/v2/VU#99999//
• (moved to Vector docs should specify whether parameter order and inclusion is required  #109) The doc should specify whether order of parameters matters and how to determine that (is there a canonical ordering?) My own opinion is that order shouldn't matter.
• If order doesn't matter then either timestamp needs to always be last or should be moved to the frontmatter of the string (not necessarily first position, but before the k:v starts) so that parsing code knows where key:value pairs stop
• Are underspecfied vectors allowed? (e.g. if I only know two parameters can I still vectorize?) If so, how are gaps notated? (e.g., key:- means null value for key vs just omitting keys with null values from the vector)
• (moved to Vector should indicate which stakeholder tree it addresses #110) Even a single "version" of SSVC like v2 has multiple trees -- does the vector represent all of them simultaneously? Or do we need to be able to specify which tree within a version this applies to? (e.g., SSVC/v2/coordinate/vul_id/key:value.../timestamp)

Commentary:

• Separate namespace and version to simplify parsing
• We should avoid overspecifying numeric version strings, because the whole point of SSVC is customization and so there could be a lot of versions and we're not proposing to establish a versioning authority
• Make timestamp parsing easy by being really specific and consistent on what the format should be, and use a globally recognized standard that is guaranteed to have code support regardless of language or platform. Unix Epoch time seems inferior to TZ-aware ISO 8601 to me.
• Adding a vul ID breaks some format symmetry with CVSS vectors but I don't think there's a requirement to maintain that degree of symmetry in the first place.
• People will come up with creative interpretations of any gaps in our spec, and that can inhibit interoperability in the long run.