API -> CPE map

[Andrew Buttner]

After talking with a vendor recently, an idea was presented that I have heard in the past.  I think the time might be right to make it happen.  In short, the creation of a shared map between the return of certain API calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information that a system might return and the official CPE Name.  Without this information, a manual map would have to be performed.  Hopefully this would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE site.  The format for this file will evolve over time as we learn more about it.  Right now I am thinking about something quick and dirty.  Any thoughts as to how to initially set this up?  For some CPE Names it might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Steve Meulmeester]

Andrew,

At CSE we have just completed an excercise of extracting the CPE data into a tree structure and mapping Assurent, Symantec and Idefense data to this tree. We created normalized models that support each of the vendors (including the CPE) and processed the supplied XML populating the structures. We then attempted to map the normalized data from the Vendors across a normalized model of the CPE using an Oracle implementation of the Levenshtein text matching algorithm. We had varying levels of success with the mapping and we created a web user interface that displayed the mapping and permits the user community to change the mapping. The Vendor supplied vulnerabilities are then dynamically mapped to the CPE depending on the mapping (ie if the mapping changes so do the vulnerabilities).

Our premise is that the Vendors supply a consistent set of Asset Information in the XML and that newly created Vendors, Assets or Asset Versions occur infrequently. The mapping that you are describing would have been extremely beneficial to our recent activities and in the short run is probably the only practical alternative to creating a singular view of Assets. Subject to approval from our Project Manager/Authority we would be able to contribute our attempt at the mapping back to the community. Further, a demo or at least screen shots of the functioning system might be helpful to illustrate what we have produced.

 

Thanks,

Steve Meulmeester

TVAS Developer

613-949-6297

On Mon, Apr 13, 2009 at 9:32 AM, Buttner, Drew <[hidden email]> wrote:

After talking with a vendor recently, an idea was presented that I have heard in the past.  I think the time might be right to make it happen.  In short, the creation of a shared map between the return of certain API calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information that a system might return and the official CPE Name.  Without this information, a manual map would have to be performed.  Hopefully this would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE site.  The format for this file will evolve over time as we learn more about it.  Right now I am thinking about something quick and dirty.  Any thoughts as to how to initially set this up?  For some CPE Names it might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Steve Meulmeester]

At CSE we have just completed an excercise of extracting the CPE data into a tree structure and mapping Assurent, Symantec and Idefense data to this tree. We created normalized models that support each of the vendors (including the CPE) and processed the supplied XML populating the structures. We then attempted to map the normalized data from the Vendors across a normalized model of the CPE using an Oracle implementation of the Levenshtein text matching algorithm. We had varying levels of success with the mapping and we created a web user interface that displayed the mapping and permits the user community to change the mapping. The Vendor supplied vulnerabilities are then dynamically mapped to the CPE depending on the mapping.

Our premise is that the Vendors supply a consistent set of Asset Information in the XML and that newly created Assets or Asset Versions occur infrequently. The mapping that you are describing would have been extremely beneficial to our recent activities. Subject to approval from our Project Manager/Authority we would be able to contribute our attempt at the mapping back to the community, if it would be helpful. Further, a demo or at least screen shots of the functioning system might be helpful to illustrate what we have produced.

 

Thanks,

Steve Meulmeester

TVAS Developer

613-949-6297

On Mon, Apr 13, 2009 at 9:32 AM, Buttner, Drew <[hidden email]> wrote:

After talking with a vendor recently, an idea was presented that I have heard in the past.  I think the time might be right to make it happen.  In short, the creation of a shared map between the return of certain API calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information that a system might return and the official CPE Name.  Without this information, a manual map would have to be performed.  Hopefully this would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE site.  The format for this file will evolve over time as we learn more about it.  Right now I am thinking about something quick and dirty.  Any thoughts as to how to initially set this up?  For some CPE Names it might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Gary Newman-2]

This sounds like a very limited form of "Aliases" that was proposed
in the past.  Why is a single alias worth supporting, when multiple
aliases is not?

Supporting multiple such aliases would greatly benefit CPE.

Are you thinking of OS CPE Names, or applications too?

Perhaps you could let us in on which API calls you're talking about.

        -Gary-

> After talking with a vendor recently, an idea was presented that I
> have heard in the past.  I think the time might be right to make it
> happen.  In short, the creation of a shared map between the return of
> certain API calls and the CPE Name that the value would map to.
>
> This would help anyone who is trying to move between the information
> that a system might return and the official CPE Name.  Without this
> information, a manual map would have to be performed.  Hopefully this
> would help make it easier for vendors to add CPE to their tools.
>
> The plan for now would be to just create a file and post it on the CPE
> site.  The format for this file will evolve over time as we learn more
> about it.  Right now I am thinking about something quick and dirty.
> Any thoughts as to how to initially set this up?  For some CPE Names
> it might be a collection of CPE Name?
>
> Thoughts about this idea?  Would it be helpful?
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515

[Andrew Buttner]

I agree that this is close to the idea of aliasing and maybe this can be the start of it.  I also see no reason why we have to limit it to one alias.  Hopefully this can be a huge help to the community.

My guess is that both os and app name could benefit, and I wouldn't want to limit it to one or the other.  I wouldn't be surprised if one area received more focus in the beginning, but that will be determined with time.

I personally don't know which API's would be important.  I am looking for the community's help here.  Basically, I will help try and bring the community together on this and help merge data that is sent to me.  I'm sure there will be a few bumps to start with.

Thanks
Drew

>-----Original Message-----
>From: Gary Newman [mailto:[hidden email]]
>Sent: Monday, April 13, 2009 12:49 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>This sounds like a very limited form of "Aliases" that was proposed
>in the past.  Why is a single alias worth supporting, when multiple
>aliases is not?
>
>Supporting multiple such aliases would greatly benefit CPE.
>
>Are you thinking of OS CPE Names, or applications too?
>
>Perhaps you could let us in on which API calls you're talking about.
>
>        -Gary-
>
>> After talking with a vendor recently, an idea was presented that I
>> have heard in the past.  I think the time might be right to make it
>> happen.  In short, the creation of a shared map between the return of
>> certain API calls and the CPE Name that the value would map to.
>>
>> This would help anyone who is trying to move between the information
>> that a system might return and the official CPE Name.  Without this
>> information, a manual map would have to be performed.  Hopefully this
>> would help make it easier for vendors to add CPE to their tools.
>>
>> The plan for now would be to just create a file and post it on the CPE
>> site.  The format for this file will evolve over time as we learn more
>> about it.  Right now I am thinking about something quick and dirty.
>> Any thoughts as to how to initially set this up?  For some CPE Names
>> it might be a collection of CPE Name?
>>
>> Thoughts about this idea?  Would it be helpful?
>>
>> Thanks
>> Drew
>>
>> ---------
>>
>> Andrew Buttner
>> The MITRE Corporation
>> [hidden email]
>> 781-271-3515

[Sudhir Gandhe-3]

Some javascript/style in this post has been disabled (why?)

I agree that this would benefit both OS and Applications. The problem we are currently facing to generate official dictionary CPEs with the asset inventory stuff will be solved with this alias list.

Most vendors gather application inventory from the Microsoft Installer APIs, there are other ways too. Perhaps we can have a "comments" tag for each alias to describe the way the alias was generated. This could start as a separate data files and could be merged with the CPE specification later. This will enable the vendors to implement the CPE standard in their tools. We at Telos are willing to share our alias mapping list in XML or Text format, as desired.




Regards,
Sudhir

Sudhir Gandhe

Telos Corporation

On Mon, Apr 13, 2009 at 12:54 PM, Buttner, Drew <[hidden email]> wrote:

I agree that this is close to the idea of aliasing and maybe this can be the start of it.  I also see no reason why we have to limit it to one alias.  Hopefully this can be a huge help to the community.

My guess is that both os and app name could benefit, and I wouldn't want to limit it to one or the other.  I wouldn't be surprised if one area received more focus in the beginning, but that will be determined with time.

I personally don't know which API's would be important.  I am looking for the community's help here.  Basically, I will help try and bring the community together on this and help merge data that is sent to me.  I'm sure there will be a few bumps to start with.

Thanks
Drew

>-----Original Message-----
>From: Gary Newman [mailto:[hidden email]]
>Sent: Monday, April 13, 2009 12:49 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>This sounds like a very limited form of "Aliases" that was proposed
>in the past.  Why is a single alias worth supporting, when multiple
>aliases is not?
>
>Supporting multiple such aliases would greatly benefit CPE.
>
>Are you thinking of OS CPE Names, or applications too?
>
>Perhaps you could let us in on which API calls you're talking about.
>
>        -Gary-
>
>> After talking with a vendor recently, an idea was presented that I
>> have heard in the past.  I think the time might be right to make it
>> happen.  In short, the creation of a shared map between the return of
>> certain API calls and the CPE Name that the value would map to.
>>
>> This would help anyone who is trying to move between the information
>> that a system might return and the official CPE Name.  Without this
>> information, a manual map would have to be performed.  Hopefully this
>> would help make it easier for vendors to add CPE to their tools.
>>
>> The plan for now would be to just create a file and post it on the CPE
>> site.  The format for this file will evolve over time as we learn more
>> about it.  Right now I am thinking about something quick and dirty.
>> Any thoughts as to how to initially set this up?  For some CPE Names
>> it might be a collection of CPE Name?
>>
>> Thoughts about this idea?  Would it be helpful?
>>
>> Thanks
>> Drew
>>
>> ---------
>>
>> Andrew Buttner
>> The MITRE Corporation
>> [hidden email]
>> 781-271-3515

[Tim Keanini]

Question 1: What is meant by API in this context?  What is the target
API and who is calling it?  Sounds like a massive information space to
be exploring and highly dynamic.

Question 2: While this might be a good idea initially, has anyone
thought about the long term costs in maintaining this method? Or if it
is "short term", what happens when we can say it is no longer short term
and we have to deal with the long term problem space?  It seems to be a
n(n-1)/2 or something close to it because the term vendor includes
vendors who speak authoritatively over their own CPE and other vendors
who speak beyond their CPE and about other vendors CPEs.  

I'm willing to participate in this effort, I just need to understand the
value today and then long term.

--tk

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, April 13, 2009 8:33 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] API -> CPE map

After talking with a vendor recently, an idea was presented that I have
heard in the past.  I think the time might be right to make it happen.
In short, the creation of a shared map between the return of certain API
calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information
that a system might return and the official CPE Name.  Without this
information, a manual map would have to be performed.  Hopefully this
would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE
site.  The format for this file will evolve over time as we learn more
about it.  Right now I am thinking about something quick and dirty.  Any
thoughts as to how to initially set this up?  For some CPE Names it
might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Ernest Park-2]

could I suggest that CPE try to be a name, and nothing more?

If we agree on the string identifiers for software applications, then vendors, application and service developers will extend the capability of a CPE name. It is the service and product providers that can resolve a CPE string to extended metadata beyond what CPE is.

In this way, the community evolves CPE. If CPE tries to be everything, it becomes the competitor of innovation. It also likely fails at doing any one thing well.

Aliases. Let's have many of them - who cares. Let vendors extend aliases.

If CPE focuses on the core descriptor, everyone else can focus on adding extra content, both proprietary and open. In this way, CPE will serve its purpose to be a single descriptor for software packages. Additionally, nothing more is needed in a CPE provided API than the validation of a CPE name structure and possibly the existence of such a name in the current dictionary. 

Beyond that, third parties can use the name structure as "the API", and then extend what they can deliver against that string.

On Mon, Apr 13, 2009 at 10:56 PM, Tim Keanini <[hidden email]> wrote:

Question 1: What is meant by API in this context?  What is the target
API and who is calling it?  Sounds like a massive information space to
be exploring and highly dynamic.

Question 2: While this might be a good idea initially, has anyone
thought about the long term costs in maintaining this method? Or if it
is "short term", what happens when we can say it is no longer short term
and we have to deal with the long term problem space?  It seems to be a
n(n-1)/2 or something close to it because the term vendor includes
vendors who speak authoritatively over their own CPE and other vendors
who speak beyond their CPE and about other vendors CPEs.

I'm willing to participate in this effort, I just need to understand the
value today and then long term.

--tk

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Monday, April 13, 2009 8:33 AM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] API -> CPE map

After talking with a vendor recently, an idea was presented that I have
heard in the past.  I think the time might be right to make it happen.
In short, the creation of a shared map between the return of certain API
calls and the CPE Name that the value would map to.

This would help anyone who is trying to move between the information
that a system might return and the official CPE Name.  Without this
information, a manual map would have to be performed.  Hopefully this
would help make it easier for vendors to add CPE to their tools.

The plan for now would be to just create a file and post it on the CPE
site.  The format for this file will evolve over time as we learn more
about it.  Right now I am thinking about something quick and dirty.  Any
thoughts as to how to initially set this up?  For some CPE Names it
might be a collection of CPE Name?

Thoughts about this idea?  Would it be helpful?

Thanks
Drew

---------

Andrew Buttner
The MITRE Corporation
[hidden email]
781-271-3515

[Andrew Buttner]

>Question 1: What is meant by API in this context?  What is the target
>API and who is calling it?  Sounds like a massive information space to
>be exploring and highly dynamic.

What I had in mind is some type of mapping file that supported users trying to create a map from their internal name to a CPE Name.  It was suggested that one way to do this would be to map the return values of certain API's as it is these return values that are often used by system inventory applications.

For example, say there is an API GetInstalledApps().  This might return "ACME Tool 3.4".  Our file would contain:

GetInstalledApps - ACME Tool 3.4 - cpe:/a:acme:tool:3.4

I agree that this is a massive information space, but the thinking is that even if we only map a small portion of it, that small portion could be useful to some.



>Question 2: While this might be a good idea initially, has anyone
>thought about the long term costs in maintaining this method? Or if it
>is "short term", what happens when we can say it is no longer short term
>and we have to deal with the long term problem space?  It seems to be a
>n(n-1)/2 or something close to it because the term vendor includes
>vendors who speak authoritatively over their own CPE and other vendors
>who speak beyond their CPE and about other vendors CPEs.

I would say that this is a short term idea.  Basically, anyone that currently wants to use CPE has to go through a manual process to map their internal product list to CPE, so this work has to be done anyway.

I think the long term solution has to be a new version of CPE or a new standard.  (unless vendors start using CPE as their output)



>I'm willing to participate in this effort, I just need to understand the
>value today and then long term.

Did this answer the questions?

Basically, for anyone that wants to help with this effort, what we are looking to do is compile all the different maps that the community might have already done and publish it to help others get started.  (hopefully those that contribute will also benefit by leveraging maps from others)  Note that only maps to externally available references will be of any use.

Thanks
Drew

[Andrew Buttner]

Steve,

If approval is given, I'm sure the CPE Community would love to add this mapping to the list, and hopefully would be able to help build on the mapping for your own benefit.

Thanks
Drew

>-----Original Message-----
>From: Steve Meulmeester [mailto:[hidden email]]
>Sent: Monday, April 13, 2009 10:33 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>Andrew,
>At CSE we have just completed an excercise of extracting the CPE data
>into a tree structure and mapping Assurent, Symantec and Idefense data
>to this tree. We created normalized models that support each of the
>vendors (including the CPE) and processed the supplied XML populating
>the structures. We then attempted to map the normalized data from the
>Vendors across a normalized model of the CPE using an Oracle
>implementation of the Levenshtein text matching algorithm. We had
>varying levels of success with the mapping and we created a web user
>interface that displayed the mapping and permits the user community to
>change the mapping. The Vendor supplied vulnerabilities are then
>dynamically mapped to the CPE depending on the mapping (ie if the
>mapping changes so do the vulnerabilities).
>
>Our premise is that the Vendors supply a consistent set of Asset
>Information in the XML and that newly created Vendors, Assets or Asset
>Versions occur infrequently. The mapping that you are describing would
>have been extremely beneficial to our recent activities and in the short
>run is probably the only practical alternative to creating a singular
>view of Assets. Subject to approval from our Project Manager/Authority
>we would be able to contribute our attempt at the mapping back to the
>community. Further, a demo or at least screen shots of the functioning
>system might be helpful to illustrate what we have produced.
>
>Thanks,
>Steve Meulmeester
>TVAS Developer
>613-949-6297
>
>On Mon, Apr 13, 2009 at 9:32 AM, Buttner, Drew <[hidden email]>
>wrote:
>
>
> After talking with a vendor recently, an idea was presented that I
>have heard in the past.  I think the time might be right to make it
>happen.  In short, the creation of a shared map between the return of
>certain API calls and the CPE Name that the value would map to.
>
> This would help anyone who is trying to move between the
>information that a system might return and the official CPE Name.
>Without this information, a manual map would have to be performed.
>Hopefully this would help make it easier for vendors to add CPE to their
>tools.
>
> The plan for now would be to just create a file and post it on the
>CPE site.  The format for this file will evolve over time as we learn
>more about it.  Right now I am thinking about something quick and dirty.
>Any thoughts as to how to initially set this up?  For some CPE Names it
>might be a collection of CPE Name?
>
> Thoughts about this idea?  Would it be helpful?
>
> Thanks
> Drew
>
> ---------
>
> Andrew Buttner
> The MITRE Corporation
> [hidden email]
> 781-271-3515
>
>

[Andrew Buttner]

>We at Telos are willing to share our alias mapping list in
>XML or Text format, as desired.

Would a good first step be to send something out in whatever format you have and then see what is included.  From there we can determine if we need to transform the format.  One outstanding question I have is how to handle name that are generated from multiple different APIs.  For example:

GetOsVersion() = ACME OS 2.3
GetOsEdition() = Desktop

CPE Name = cpe:/o:acme:os:2.3:-:desktop

Thoughts?

Thanks
Drew

[Andrew Buttner]

>-----Original Message-----
>From: Ernest Park [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 1:21 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>could I suggest that CPE try to be a name, and nothing more?

I think this is what we are trying to do.  We are on the same page here.



>If we agree on the string identifiers for software applications, then
>vendors, application and service developers will extend the capability
>of a CPE name. It is the service and product providers that can resolve
>a CPE string to extended metadata beyond what CPE is.

Yes!


Our hope with this thread is that we can jump start the adoption of CPE by all pitching in on the biggest barrier to entry - the manual map.  We believe that everyone will benefit from helping with this as everyone will benefit once CPE gains more traction.  (for all the reasons Ernest pointed out)

Thanks
Drew

[Ernest Park-2]

btw - it seems that the report you want  could be had if you encourage companies like Symantec, McAfee, Palamida, Blackduck and others to output discovered inventory information as CPE data.

The "query" API as delineated herein should be generalized, such that any CPE compliant system can either return a CPE structured name, or resolve a name within a structured query with additional proprietary and community data, such as . . .

select * from my.cpe.database where cpename like 'cpe:/a:vendor:product';

therefore, a vendor would have to have an alias table representing the component parts of CPE names as a single string, but each part joined into the metadata relevant for the vendor.

This way, I avoid an API, but can still integrate data from Symantec, Palamida and McAfee if I know that I share common name syntaxes. Beyond that, each vendor delivers additional proprietary data, thereby allowing customers to use the CPE name as an integration point.

My company has done a lot of this work if anyone is curious.

On Wed, Apr 15, 2009 at 3:46 PM, Buttner, Drew <[hidden email]> wrote:

>-----Original Message-----
>From: Ernest Park [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 1:21 PM
>To: cpe-discussion-list CPE Community Forum

>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>could I suggest that CPE try to be a name, and nothing more?

I think this is what we are trying to do.  We are on the same page here.



>If we agree on the string identifiers for software applications, then
>vendors, application and service developers will extend the capability
>of a CPE name. It is the service and product providers that can resolve
>a CPE string to extended metadata beyond what CPE is.

Yes!


Our hope with this thread is that we can jump start the adoption of CPE by all pitching in on the biggest barrier to entry - the manual map.  We believe that everyone will benefit from helping with this as everyone will benefit once CPE gains more traction.  (for all the reasons Ernest pointed out)

Thanks
Drew

[Maneesh Jolly]

Some javascript/style in this post has been disabled (why?)

In the current scenario, every vendor might be having his own method of identifying OS or Application. They might not be storing the return values of the API used to identify the application. Lets consider the case Microsoft windows OS only for now.

Vendor A might have a function that use the API’s (GetSystemInfo, GetVersionEx etc) to generate one identifier for that OS type but vendor B might be generating 2 identifier that are combined to identify the OS type.

The best method would have been for the vendor to associate CPE id with their internal Id, but this of course is not at all going to help the progress of CPE effort.

 

Now mapping API with CPE Id as suggested by Drew can be done, but then we need to remember that we might have to logically combine return values of several APIs to map it to CPE Id. This will be quite similar to associating an OVAL definition Id with a CPE identifier.

 

---

From: Ernest Park [mailto:[hidden email]]
Sent: Thursday, April 16, 2009 1:35 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map

 

btw - it seems that the report you want  could be had if you encourage companies like Symantec, McAfee, Palamida, Blackduck and others to output discovered inventory information as CPE data.

 

The "query" API as delineated herein should be generalized, such that any CPE compliant system can either return a CPE structured name, or resolve a name within a structured query with additional proprietary and community data, such as . . .

 

 

select * from my.cpe.database where cpename like 'cpe:/a:vendor:product';

 

 

 

therefore, a vendor would have to have an alias table representing the component parts of CPE names as a single string, but each part joined into the metadata relevant for the vendor.

 

This way, I avoid an API, but can still integrate data from Symantec, Palamida and McAfee if I know that I share common name syntaxes. Beyond that, each vendor delivers additional proprietary data, thereby allowing customers to use the CPE name as an integration point.

 

 

 

 

My company has done a lot of this work if anyone is curious.

 

 

On Wed, Apr 15, 2009 at 3:46 PM, Buttner, Drew <[hidden email]> wrote:

>-----Original Message-----
>From: Ernest Park [mailto:[hidden email]]
>Sent: Tuesday, April 14, 2009 1:21 PM
>To: cpe-discussion-list CPE Community Forum

>Subject: Re: [CPE-DISCUSSION-LIST] API -> CPE map
>
>could I suggest that CPE try to be a name, and nothing more?

I think this is what we are trying to do.  We are on the same page here.



>If we agree on the string identifiers for software applications, then
>vendors, application and service developers will extend the capability
>of a CPE name. It is the service and product providers that can resolve
>a CPE string to extended metadata beyond what CPE is.

Yes!


Our hope with this thread is that we can jump start the adoption of CPE by all pitching in on the biggest barrier to entry - the manual map.  We believe that everyone will benefit from helping with this as everyone will benefit once CPE gains more traction.  (for all the reasons Ernest pointed out)

Thanks
Drew