Clarify: 6.1.14 - Handling of mixed integer and semantic versioning

[peinjoh]

I'm not sure if this qualifies as a request for clarification or as a request for implementation guidance for tool developers. Please forward me if this should be asked and answered elsewhere.

For "Test 6.1.14 - Sorted Revision History", the revision history needs to be sorted first ascending by date and second by number, with the test failing if the number values of the then-sorted revision history are not also sorted ascending.

At the same time, the revision history can contain numbers with a mix of integer and semantic versioning schema. As part of "Test 6.1.30 Mixed Integer and Semantic Versioning", the revision history items are checked for this possible inconsistency.

I would argue that this leaves room for interpretation as to how test 6.1.14 (and other tests that check the number field of the revision history, like "6.1.21 - Missing Item in Revision History") are supposed to handle a revision history that - without some reinterpretation or removals - can not be totally ordered due to mixed versioning.

A minimal example:

      "revision_history": [
        {
          "date": "2026-03-09T11:00:00.000Z",
          "number": "1",
          "summary": "1"
        },
        {
          "date": "2026-03-10T11:00:00.000Z",
          "number": "2.0.0",
          "summary": "2.0.0"
        },
        {
          "date": "2026-03-11T11:00:00.000Z",
          "number": "3",
          "summary": "3"
        }
      ]

Test 6.1.30 would fail a document with this /document/tracking/revision_history. Test 6.1.14 would sort this by date, keep the order displayed as it is already ordered, check the order of the number fields and would need to:

• a) try to compare intver 1 and 3 to semver 2.0.0 (for example by reinterpreting 2.0.0 and 2) or
• b) skip or remove either of the conflicting versioning schemas from the revision history (for example by majority, first encountered, ...) or
• c) skip or fail this test entirely.

Test 6.1.30 contain a suggested quick fix:

A tool MAY assign all items their corresponding value according to integer versioning as a quick fix. In such case, the old number SHOULD be stored in legacy_version.

Option a) could be interpreted as aligned with the 6.1.30 quick fix. Is this interpretation of the quick fix the intended behaviour for tools with "CSAF Basic Validator" conformance target when running tests 6.1.14, 6.1.21 or similar?

And if so, should this be done

• 1. using the semver major version (But would it also need to be applied during test "6.1.22 - Multiple Definition in Revision History", where it would fail on semantic versioning revision histories with items with the same major version (2.0.0, 2.10 -> 2), that would otherwise pass?)
     or
• 2. using the strategy described in "9.1.5 Conformance Clause 5: CVRF CSAF Converter" utilizing the path index of the revision history item?

This issue was announced here: https://groups.oasis-open.org/discussion/new-issue-clarify-6114-handling-of-mixed-integer-and-semantic-versioning