CPE 2.2 and 2.3 interoperability considerations (UNCLASSIFIED)

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CPE 2.2 and 2.3 interoperability considerations (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking through the implementation issues with the new "features" in CPE 2.3

In general, I think the separation of the standard into multiple parts is a good idea.  I also agree with using the tilde in 2.2 CPE names to allow for the breakup of the edition field (though I think it's the least bad of multiple bad choices and really highlights the need to go with attribute-based naming).

The only remaining issue I haven't seen addressed in 2.2 formatted CPE names is how to deal with the requirement for wildcards/ambiguous names.

After thinking the issue over for a while, I am suggesting that we use percent-encoded spaces (%20) as a wildcard character for CPE 2.2 names since the current spec would otherwise prohibit both unencoded and encoded spaces, which makes %20 sort of an "ultra-reserved" character.  I also suggest that wildcards only be allowed at the beginning or end of CPE part names to alleviate some of the matching problems discussed at SCAP developer days.

I'm making this suggestion primarily because there is a significant infrastructure in place that uses the 2.2 CPE regular expression and that the value added by using escaping versus percent encoding in the CPE 2.3 format doesn't really justify going back and spending the 10s and possibly 100s of thousands that would be required to rebuild the code required across the DoD infrastructure.  We've been using the asterisk symbol as our wildcard, but I'm thinking a simple substitution of "%20" for "*" is probably the easiest/lowest cost solution I can come up with to allow us to continue to use the CPE 2.2 REGEX and get the benefits of the work that was done on version 2.3.

I'm interested in any comments/thoughts.

- Joe

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.2 and 2.3 interoperability considerations (UNCLASSIFIED)

Brant Cheikes
Let me see if I can rephrase your suggestions to make them actionable
proposals for changes to the draft 2.3 spec.

First, I believe that all your comments are intended to apply to the
so-called "URI binding" in the 2.3 spec.  (This is the binding form that is
intended to be backward-compatible with v2.2-conformant tools.)  That is,
while the 2.3 spec defines two different bindings ("URI" and "formatted
string"), your proposal pertains only to the URI binding.  I don't see a
proposal here to drop the formatted string binding, just a proposal to
modify the URI binding.  Putting this another way, I think you have no
interest in the formatted string binding; you're happy to leave it in the
spec as an alternative binding, but you're principally concerned with
tweaking the URI binding.

Second, I believe you're proposing that we drop one of the two supported
wildcard characters.  In the 2.3 naming spec, we define "?" and "*" as
special characters.  This allows the matching spec to assign them special
meaning, as a single-character and multiple-character wildcard,
respectively.  I think you're proposing that we only need a multi-character
wildcard (at the WFN level), so we should drop "?" from the list of special
characters.

Third, I believe you're supporting a design decision, reflected in the draft
matching spec, to restrict the wildcard character to only the beginning or
end of attribute value strings, as opposed to allowing it to appear freely
within a value string.

Fourth, I believe you're proposing that, when binding WFNs to URIs, we map
the "*" special character in the WFN to "%20" in the URI (and reverse that
translation when unbinding URIs to WFNs).  Technically, this seems doable.
At present, the grammar for value strings in WFNs precludes the use of
non-printable characters such as space, tab, and control characters.  So in
principle there's no way for a "%20" to appear in a URI binding, because a
space cannot appear in a WFN.  (Though the unbinding procedure, as currently
defined, is unclear about what should happen when processing the
percent-encoded form of an illegal character.)  It also turns out that "%20"
doesn't appear in any existing CPE name in the Official Dictionary.

In sum, I could see a way to revise the draft v2.3 naming and matching specs
to (a) enumerate the legal percent-encoded forms in URI bindings, (b) define
appropriate exception handling in the unbinding procedure when given illegal
input, (c) reduce support for wildcards to just the multi-character
wildcard, and (d) map "*" in a WFN to "%20" in a URI.  This proposal has the
advantage of providing a path that allows the wildcard to appear in URIs as
well as formatted strings, just in a different form (i.e., as "%20" in a
URI, and as "*" in a formatted string).

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Monday, October 04, 2010 4:13 PM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] CPE 2.2 and 2.3 interoperability
considerations (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking through the implementation issues with the new "features"
in CPE 2.3

In general, I think the separation of the standard into multiple parts is a
good idea.  I also agree with using the tilde in 2.2 CPE names to allow for
the breakup of the edition field (though I think it's the least bad of
multiple bad choices and really highlights the need to go with
attribute-based naming).

The only remaining issue I haven't seen addressed in 2.2 formatted CPE names
is how to deal with the requirement for wildcards/ambiguous names.

After thinking the issue over for a while, I am suggesting that we use
percent-encoded spaces (%20) as a wildcard character for CPE 2.2 names since
the current spec would otherwise prohibit both unencoded and encoded spaces,
which makes %20 sort of an "ultra-reserved" character.  I also suggest that
wildcards only be allowed at the beginning or end of CPE part names to
alleviate some of the matching problems discussed at SCAP developer days.

I'm making this suggestion primarily because there is a significant
infrastructure in place that uses the 2.2 CPE regular expression and that
the value added by using escaping versus percent encoding in the CPE 2.3
format doesn't really justify going back and spending the 10s and possibly
100s of thousands that would be required to rebuild the code required across
the DoD infrastructure.  We've been using the asterisk symbol as our
wildcard, but I'm thinking a simple substitution of "%20" for "*" is
probably the easiest/lowest cost solution I can come up with to allow us to
continue to use the CPE 2.2 REGEX and get the benefits of the work that was
done on version 2.3.

I'm interested in any comments/thoughts.

- Joe

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: CPE 2.2 and 2.3 interoperability considerations (UNCLASSIFIED)

WOLFKIEL, JOSEPH L CIV DISA PEO-MA
Classification:  UNCLASSIFIED
Caveats: NONE

Responses in line.  In general, I think you understood everything I said and captured it correctly.  Thanks for taking the effort.

- Joe


On Mon, Oct 4, 2010 at 5:50 PM, Cheikes, Brant A. <[hidden email]> wrote:


        Let me see if I can rephrase your suggestions to make them actionable
        proposals for changes to the draft 2.3 spec.
       
        First, I believe that all your comments are intended to apply to the
        so-called "URI binding" in the 2.3 spec.  (This is the binding form that is
        intended to be backward-compatible with v2.2-conformant tools.)  That is,
        while the 2.3 spec defines two different bindings ("URI" and "formatted
        string"), your proposal pertains only to the URI binding.  I don't see a
        proposal here to drop the formatted string binding, just a proposal to
        modify the URI binding.  Putting this another way, I think you have no
        interest in the formatted string binding; you're happy to leave it in the
        spec as an alternative binding, but you're principally concerned with
        tweaking the URI binding.
       


Exactly.  I think the DoD is stuck with the URI binding format for a while since it is built out in several key systems and is part of ARF 0.41, 0.41.1, and 0.41.2, plus ASR all of which are were either used in acquisition language or are being produced in Government-built tools as we speak.  My only reservation about supporting the "formatted string" binding is to have a clear transform to move between the URI binding and the formatted string.  If we can get the CPE dictionary updated to use the tilde notation and deprecate existing CPEs that can't be automatically mapped into the software edition, target hardware, target software, and "other" categories, then you should be able to do a fairly straightforward transform to move from one format to another.  The need for a wildcard character in the URI binding was the one gap that would have prevented this sort of transform.
 


        Second, I believe you're proposing that we drop one of the two supported
        wildcard characters.  In the 2.3 naming spec, we define "?" and "*" as
        special characters.  This allows the matching spec to assign them special
        meaning, as a single-character and multiple-character wildcard,
        respectively.  I think you're proposing that we only need a multi-character
        wildcard (at the WFN level), so we should drop "?" from the list of special
        characters.
       


I'm not really addressing the single-character wildcard at all.  I haven't run into a case, so far, where we needed a single-character wildcard, but I don't see a problem with having them (other than the extra coding required to implement them).  We'd just need to pick some other character or percent encoded value in the URI binding that would represent a single-character wildcard.  Is there someone advocating strongly for a single-character wildcard?  Maybe I just haven't thought of the use case where they would be required.



        Third, I believe you're supporting a design decision, reflected in the draft
        matching spec, to restrict the wildcard character to only the beginning or
        end of attribute value strings, as opposed to allowing it to appear freely
        within a value string.
       


Yes. I'm not completely sure it belongs in the matching spec since the restriction would have to apply whether you use the matching algorithm or not, but my discussions with people who understand the issues at SCAP Developer days indicate that supporting mid-text multi-character wildcards causes more problems that it's worth.



        Fourth, I believe you're proposing that, when binding WFNs to URIs, we map
        the "*" special character in the WFN to "%20" in the URI (and reverse that
        translation when unbinding URIs to WFNs).  Technically, this seems doable.
        At present, the grammar for value strings in WFNs precludes the use of
        non-printable characters such as space, tab, and control characters.  So in
        principle there's no way for a "%20" to appear in a URI binding, because a
        space cannot appear in a WFN.  (Though the unbinding procedure, as currently
        defined, is unclear about what should happen when processing the
        percent-encoded form of an illegal character.)  It also turns out that "%20"
        doesn't appear in any existing CPE name in the Official Dictionary.
       


Yes.  I chose the %20 specifically because there shouldn't be any way for it to appear in any existing CPEs, but it would be allowed by the REGEX pattern.



        In sum, I could see a way to revise the draft v2.3 naming and matching specs
        to (a) enumerate the legal percent-encoded forms in URI bindings, (b) define
        appropriate exception handling in the unbinding procedure when given illegal
        input, (c) reduce support for wildcards to just the multi-character
        wildcard, and (d) map "*" in a WFN to "%20" in a URI.  This proposal has the
        advantage of providing a path that allows the wildcard to appear in URIs as
        well as formatted strings, just in a different form (i.e., as "%20" in a
        URI, and as "*" in a formatted string).
       


That's what I was attempting.  



        /Brant
       
        Brant A. Cheikes
        The MITRE Corporation
        202 Burlington Road, M/S K302
        Bedford, MA 01730-1420
        Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352
         


Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
-----Original Message-----
From: Cheikes, Brant A. [mailto:[hidden email]]
Sent: Monday, October 04, 2010 5:51 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.2 and 2.3 interoperability considerations (UNCLASSIFIED)

Let me see if I can rephrase your suggestions to make them actionable
proposals for changes to the draft 2.3 spec.

First, I believe that all your comments are intended to apply to the
so-called "URI binding" in the 2.3 spec.  (This is the binding form that is
intended to be backward-compatible with v2.2-conformant tools.)  That is,
while the 2.3 spec defines two different bindings ("URI" and "formatted
string"), your proposal pertains only to the URI binding.  I don't see a
proposal here to drop the formatted string binding, just a proposal to
modify the URI binding.  Putting this another way, I think you have no
interest in the formatted string binding; you're happy to leave it in the
spec as an alternative binding, but you're principally concerned with
tweaking the URI binding.

Second, I believe you're proposing that we drop one of the two supported
wildcard characters.  In the 2.3 naming spec, we define "?" and "*" as
special characters.  This allows the matching spec to assign them special
meaning, as a single-character and multiple-character wildcard,
respectively.  I think you're proposing that we only need a multi-character
wildcard (at the WFN level), so we should drop "?" from the list of special
characters.

Third, I believe you're supporting a design decision, reflected in the draft
matching spec, to restrict the wildcard character to only the beginning or
end of attribute value strings, as opposed to allowing it to appear freely
within a value string.

Fourth, I believe you're proposing that, when binding WFNs to URIs, we map
the "*" special character in the WFN to "%20" in the URI (and reverse that
translation when unbinding URIs to WFNs).  Technically, this seems doable.
At present, the grammar for value strings in WFNs precludes the use of
non-printable characters such as space, tab, and control characters.  So in
principle there's no way for a "%20" to appear in a URI binding, because a
space cannot appear in a WFN.  (Though the unbinding procedure, as currently
defined, is unclear about what should happen when processing the
percent-encoded form of an illegal character.)  It also turns out that "%20"
doesn't appear in any existing CPE name in the Official Dictionary.

In sum, I could see a way to revise the draft v2.3 naming and matching specs
to (a) enumerate the legal percent-encoded forms in URI bindings, (b) define
appropriate exception handling in the unbinding procedure when given illegal
input, (c) reduce support for wildcards to just the multi-character
wildcard, and (d) map "*" in a WFN to "%20" in a URI.  This proposal has the
advantage of providing a path that allows the wildcard to appear in URIs as
well as formatted strings, just in a different form (i.e., as "%20" in a
URI, and as "*" in a formatted string).

/Brant

Brant A. Cheikes
The MITRE Corporation
202 Burlington Road, M/S K302
Bedford, MA 01730-1420
Tel. 781-271-7505; Cell. 617-694-8180; Fax. 781-271-2352


-----Original Message-----
From: WOLFKIEL, JOSEPH L CIV DISA PEO-MA [mailto:[hidden email]]
Sent: Monday, October 04, 2010 4:13 PM
To: cpe-discussion-list CPE Community Forum
Subject: [CPE-DISCUSSION-LIST] CPE 2.2 and 2.3 interoperability
considerations (UNCLASSIFIED)

Classification:  UNCLASSIFIED
Caveats: NONE

I've been thinking through the implementation issues with the new "features"
in CPE 2.3

In general, I think the separation of the standard into multiple parts is a
good idea.  I also agree with using the tilde in 2.2 CPE names to allow for
the breakup of the edition field (though I think it's the least bad of
multiple bad choices and really highlights the need to go with
attribute-based naming).

The only remaining issue I haven't seen addressed in 2.2 formatted CPE names
is how to deal with the requirement for wildcards/ambiguous names.

After thinking the issue over for a while, I am suggesting that we use
percent-encoded spaces (%20) as a wildcard character for CPE 2.2 names since
the current spec would otherwise prohibit both unencoded and encoded spaces,
which makes %20 sort of an "ultra-reserved" character.  I also suggest that
wildcards only be allowed at the beginning or end of CPE part names to
alleviate some of the matching problems discussed at SCAP developer days.

I'm making this suggestion primarily because there is a significant
infrastructure in place that uses the 2.2 CPE regular expression and that
the value added by using escaping versus percent encoding in the CPE 2.3
format doesn't really justify going back and spending the 10s and possibly
100s of thousands that would be required to rebuild the code required across
the DoD infrastructure.  We've been using the asterisk symbol as our
wildcard, but I'm thinking a simple substitution of "%20" for "*" is
probably the easiest/lowest cost solution I can come up with to allow us to
continue to use the CPE 2.2 REGEX and get the benefits of the work that was
done on version 2.3.

I'm interested in any comments/thoughts.

- Joe

Joseph L. Wolfkiel
Engineering Group Lead
DISA PEO MA/IA52
(703) 882-0772
[hidden email]
Classification:  UNCLASSIFIED
Caveats: NONE

Classification:  UNCLASSIFIED
Caveats: NONE


smime.p7s (7K) Download Attachment