CPE Dictionary Deprecation Issue

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

CPE Dictionary Deprecation Issue

Paul Cichonski


I was traveling all of last week so I apologize for the delay in getting this issue out on the list.  During developer days, CPE name deprecation was the primary point of contention relating to the CPE 2.3 Dictionary specification.  Specifically, there were issues raised relating to the need to support one-to-many deprecation for capturing the growth of information relative to a single CPE name.

By the end of the session, it seemed to me that three deprecation relationships existed (I think we only talked about two, but I am adding CPE Name Removal as a third).  I have listed these deprecation relationships below:

1.       CPE Name Correction - A syntax error occurred (e.g. typo, misspelling) during name creation and the name must be updated to fix this error.  This type of deprecation is one-to-one, with the deprecated CPE name pointing to the new name that represents the same product, but with the syntax error corrected.

2.       CPE Name Removal - A name exists in the dictionary that does not belong and has no replacement.  This condition normally results in the case where the dictionary maintainer makes an error that cannot be corrected with a new name (i.e. the name should never have been included in the dictionary).  In this case, the name will be deprecated without pointing to a new name.

3.       Additional Information Discovery - One or more CPE names are added to the dictionary that are more complete than an existing CPE name within the dictionary.  For example, 'cpe-23:/a:adobe:acrobat:3.0:-:*:*:*:*:*:*' and 'cpe-23:/a:adobe:acrobat:3.0:sp1:*:*:*:*:*:*' are added to a dictionary containing the name 'cpe-23:/a:adobe:acrobat:3.0:*:*:*:*:*:*:*'.  In this example, the two names that are added provide more information (i.e. update component value) than the existing name in the dictionary.   In this case, the pre-existing name really represented a set of possible products that were not known about when the name was originally added to the dictionary.  This type of deprecation must be one-to-many since the pre-existing name is deprecated to all of the names that are more complete.  This deprecation relationship is largely informational, when making this deprecation the dictionary maintainer is asserting any CPE name within the set of new CPE names is a valid replacement for the deprecated CPE name; it is up to the dictionary user to decide on which individual name to use, or to use the entire set.   

Supporting these distinct relationships within the XSD model is trivial.  I am planning on adding a 'type' attribute to the 'deprecated-by' element to capture the deprecation type.  This attribute would take a value from enumerated list containing the three distinct types.

For example:

<cpe23:deprecated-by name="cpe-23:/a:adobe:acrobat:3.0:*:*:*:*:*:*:*" type="ADDITIONAL_INFO"/>

Does anyone have issues with anything in this email?  I think the key issue here is the types of deprecation relationships we have to support in the dictionary.