rfd: Introduce a Validation Library

[alilleybrinker]

This RFD describes the need to create a JavaScript library for validating CVE Records.

Rendered

[zmiele]

The versioning of this library would, for clarity and simplicity, be matched to the versioning of the CVE Record Format. Whenever new versions of the Record Format are published, a new release of the validation library with a matching version number would also be published.

One small concern that comes to mind here is that this will require the inverse to be true as well. If there is an issue with the library, we'll be required to bump the version of the schema in order to provide fixes in the validation library. Is that something we're comfortable with? If so, we'll need to keep that in mind when defining the versioning rules for the schema in #418.

[alilleybrinker]

@zmiele hm, that's a fair point. In general, I think that such a binding still makes sense. The schema and the validation library become, in effect, a single product with a single version. Fixes to address bugs would be a patch release for both, whether the error is in the schema or in the library.

[alilleybrinker]

In discussion among the QWG today, we agreed that the negative operational trade-offs for matching versions between the validation library and the Record Format make such a matching commitment not worth it. We can instead document compatibility between the two. I'll amend the RFD.

[alilleybrinker]

Potential requirements for what we want out of the validator library:

• (@ccoffin) Provide clear and descriptive schema validation error reporting for CNAs and other data producers
• (@ccoffin) Provide warnings/notifications for future schema changes (e.g., this property will be deprecated in 6.0)
• (@alilleybrinker) Be usable by both CVE Services and 3rd-party consumers