Discuss XML namespaces URL's for OVAL 5.12 and OVAL 6.0

[vanderpol]

@OVAL-Community/oval-board-members
Given that MITRE is no longer involved with OVAL, is there any reason (besides historical reference) to have http://oval.mitre.org as the namespace base?

    xmlns:oval-sc="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5"
        xmlns:oval="http://oval.mitre.org/XMLSchema/oval-common-5"
        xmlns:win-sc="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows"
        targetNamespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5#windows"
        elementFormDefault="qualified" version="5.11">
 <xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-common-5" schemaLocation="oval-common-schema.xsd"/>
 <xsd:import namespace="http://oval.mitre.org/XMLSchema/oval-system-characteristics-5" schemaLocation="oval-system-characteristics-schema.xsd"/>
 <xsd:annotation>

Should these be updated for 5.12 or 6.0? If so, what should they be updated to?

For OVAL 6, I assume we at a minimum need to be changing them all from -5 to -6

[solind]

These should absolutely not be updated for 5.12, it'll break backwards-compatibility.

For 6.0, we could do anything. I'd suggest making them shorter, perhaps using a URN, e.g. urn:oval:oval6:schema:definitions.

[vanderpol]

Thanks for the sanity check! Just to make sure I'm fully understanding your shorter prefixes, could you drop a sample that would replace the snippet I put in the base discussion? Thanks!

[solind]

Here's a full rewrite of your snippet using what I've proposed:

    xmlns:oval-sc="urn:oval:oval6:schema:system-characteristics"
        xmlns:oval="urn:oval:oval6:schema:common"
        xmlns:win-sc="urn:oval:oval6:schema:system-characteristics:windows"
        targetNamespace="urn:oval:oval6:schema:system-characteristics:windows"
        elementFormDefault="qualified" version="5.11">
 <xsd:import namespace="urn:oval:oval6:schema:common" schemaLocation="oval-common-schema.xsd"/>
 <xsd:import namespace="urn:oval:oval6:schema:system-characteristics" schemaLocation="oval-system-characteristics-schema.xsd"/>
 <xsd:annotation>

[wmunyan]

Would the “elementFormDefault” version change to “6.0”?CheersBill MSent from my iPhoneOn Oct 3, 2024, at 11:18, David Solin ***@***.***> wrote: Here's a full rewrite of your snippet using what I've proposed: xmlns:oval-sc="urn:oval:oval6:schema:system-characteristics" xmlns:oval="urn:oval:oval6:schema:common" xmlns:win-sc="urn:oval:oval6:schema:system-characteristics:windows" targetNamespace="urn:oval:oval6:schema:system-characteristics:windows" elementFormDefault="qualified" version="5.11"> <xsd:import namespace="urn:oval:oval6:schema:common" schemaLocation="oval-common-schema.xsd"/> <xsd:import namespace="urn:oval:oval6:schema:system-characteristics" schemaLocation="oval-system-characteristics-schema.xsd"/> <xsd:annotation> —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[solind]

Oh, yeah, I assume you actually mean the version attribute? I forgot to change that.

[vanderpol]

@solind in looking at making this as short/simple as possible, what value does the ":schema:" provide? Also wondering about ":oval:"? Would this still work, or am I overlooking something?

xmlns:oval-sc="urn:oval6:system-characteristics"
    xmlns:oval="urn:oval6:common"
    xmlns:win-sc="urn:oval6:system-characteristics:windows"
    targetNamespace="urn:oval6:system-characteristics:windows"
    elementFormDefault="qualified" version="6.0">

<xsd:import namespace="urn:oval6:common" schemaLocation="oval-common-schema.xsd"/>
<xsd:import namespace="urn:oval6:system-characteristics" schemaLocation="oval-system-characteristics-schema.xsd"/>

[solind]

Sure, less is more! It seems very unlikely there will be future namespace conflicts with this convention, so perhaps there's no need for keywords like "schema". I might do oval:v6 or oval:6 instead of oval6 though. Because I'm mental.

[vanderpol]

I'm good with either oval:v6 or oval:6, although my preference is oval:v6 for some reason.

[balleman-ctr]

Is formal registration of the namespace being considered? Some cursory searching suggests IANA is the authority for URN namespaces/NIDs.

[solind]

If we want to register it with IANA, then I think registering "oval" is what makes the most sense, and putting the version in a subsequent field.

Only question, then, is 6 or v6.

[harrisdk]

So I have done some research on what our options are for namespaces. There are a couple of paths available:

1. Keep the namespaces as they are now. This requires the least effort but is also the least desirable.
2. Move to using a URN. In order to go this method we should register with IANA which would require a notable amount of effort to accomplish. While I believe this is the most desirable option it would likely require someone willing to champion the effort to get the namespace registered.
3. Move to a custom/unofficial URL scheme. While new URI schemes are supposed to be registered with IANA there are many cases where people have opted not to do so because their use is internal to the product family they are being used with. An example of what this option could look like is "oval:v6:windows:system-characteristics". This would require a small effort from the OVAL community but we would be traversing an unofficial but not untraveled path for our namespace URI.
4. Continue to use a URL but move to a donated/custom address. We could change the current URL base that is being used to a custom one such as "oval-community.org" and link from there to the GitHub project as well as any other files or documentation we wish. This would require someone to donate a small amount of funds for minimal hosting and domain registration. If this is the path we wish to choose I am willing to purchase and maintain the domain name as well as to provide some hosting for the domain name and a basic website to support it, I could commit to a minimum of 10 years, likely more if needed, of hosting.

There are certainly pros and cons for each option, I personally like either options 3 or 4 the most.

[vanderpol]

Thanks @harrisdk, I'm good with options 2, 3 or 4, although only option 2 if someone else on the board (not from our NIWC team) decides to champion the URN registration with IANA. Our team can fund the effort if option 4 is desired.

[solind]

I'm going to go out on a limb and say that I think registering the URN is probably not that important. Who's creating new URN prefixes these days?

[vanderpol]

I think as a group that's trying to promote standards, someone from the OVAL board should at least try to register with IANA if we want to proceed with the URN format. Or if the consensus is just to proceed, just let me know

[balleman-ctr]

For 2 (URN), XCCDF appears to have already gone this route for fix/@system, facts, and scoring models, without any official registration. I would lean towards 2 or 3.

[vanderpol]

If NIST proceeded without any official registration, that seems to say the precedence has been set. Given our short timeframe on all of this I'll plan to proceed with the @solind proposed URN format and let everyone do a review of the pull request.