Making Security Measurable › CPE - Common Platform Enumeration

CPE 2.0 draft and Internationalization

25 messages

1 2

Kent_Landfield

CPE 2.0 draft and Internationalization

Reply Threaded

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

There has been no discussion of Internationalization in CPE. Why not? I don’t believe the excuse dragged out on another SCAP related list about this is a US centric standard… Just because this was initiated initially by US participants, we do not need to be short sighted here.

What if we added an optional Language Component as the final component… For example.

Language Component

The fifth and final component of a CPE Name is the language of the platform part. This is an optional component. The component values are language identifiers as defined by [IETF RFC 4646], Tags for Identifying Languages, or its successor; in addition, the empty string may be specified. An empty component defaults to English (en-US).

If we did that then we would have the option to specify versions of software used through out the world. The examples below are modified from the existing draft.

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the English language.

cpe:/o:microsoft:windows:2000:

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French language.

cpe:/o:microsoft:windows:2000:fr

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French Canadian language.

cpe:/o:microsoft:windows:2000:fr-CA

FYI, these examples are arbitrary… <grin>

This capability is a major missing piece in the standard as it exists today. We should fix this now so all can use this specification.

Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

Banghart, John

Re: CPE 2.0 draft and Internationalization

Reply Threaded

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

Nothing to add other then my agreement. While this has clearly has been a US-centric effort to date, I see no reason why we shouldn’t accommodate our international colleagues.

John Banghart

Associate

Booz | Allen | Hamilton

Tel (703) 377-5040

[hidden email]

From: Kent Landfield [mailto:[hidden email]]
Sent: Monday, August 20, 2007 1:31 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization

What if we added an optional Language Component as the final component… For example.

Language Component

If we did that then we would have the option to specify versions of software used through out the world. The examples below are modified from the existing draft.

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the English language.

cpe:/o:microsoft:windows:2000:

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French language.

cpe:/o:microsoft:windows:2000:fr

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French Canadian language.

cpe:/o:microsoft:windows:2000:fr-CA

FYI, these examples are arbitrary… <grin>

This capability is a major missing piece in the standard as it exists today. We should fix this now so all can use this specification.

Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

Waltermire, Dave [USA]

Re: CPE 2.0 draft and Internationalization

Reply Threaded

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

Kent,

The aspect of language has always been part of the CPE discussion. Languages are to be included as part of the edition. The requirement for this in the CPE 2.0 spec is:

· A CPE Name MUST be able to include the language a particular platform supports.

Also on page 12:

It is quite possible that a vendor, perhaps for marketing purposes, may use different names for identical hardware and software platforms. This could occur for regional versions with different languages, or different vertical markets each with a need for the same tool. In these cases, a different CPE Name will be used for each of the different vendor-assigned names. CPE in general tries to mimic the product naming structures used by the vendors, while imposing uniform structure and matching semantics.

By adding a 5th field, are you asking that language become more prominent than it is currently?

We might want to express the language using ISO 639 two-letter code and the ISO 3166 country codes only. The IETF RFC 4646 (http://tools.ietf.org/rfc/bcp/bcp47.txt) allows a script identifier and additional optional content that may be a bit of overkill. This is definitely worth more investigation and discussion.

Dave

From: Banghart, John [mailto:[hidden email]]
Sent: Monday, August 20, 2007 1:47 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization

Nothing to add other then my agreement. While this has clearly has been a US-centric effort to date, I see no reason why we shouldn’t accommodate our international colleagues.

--

John Banghart

Associate

Booz | Allen | Hamilton

Tel (703) 377-5040

[hidden email]

From: Kent Landfield [mailto:[hidden email]]
Sent: Monday, August 20, 2007 1:31 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization

There has been no discussion of Internationalization in CPE. Why not? I don’t believe the excuse dragged out on another SCAP related list about this is a US centric standard… Just because this was initiated initially by US participants, we do not need to be short sighted here.

What if we added an optional Language Component as the final component… For example.

Language Component

The fifth and final component of a CPE Name is the language of the platform part. This is an optional component. The component values are language identifiers as defined by [IETF RFC 4646], Tags for Identifying Languages, or its successor; in addition, the empty string may be specified. An empty component defaults to English (en-US).

If we did that then we would have the option to specify versions of software used through out the world. The examples below are modified from the existing draft.

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the English language.

cpe:/o:microsoft:windows:2000:

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French language.

cpe:/o:microsoft:windows:2000:fr

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French Canadian language.

cpe:/o:microsoft:windows:2000:fr-CA

FYI, these examples are arbitrary… <grin>

This capability is a major missing piece in the standard as it exists today. We should fix this now so all can use this specification.

--

Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

Kent_Landfield

Re: CPE 2.0 draft and Internationalization

Reply Threaded

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

Hi Dave,

Because there is a requirement does not mean it is supported. What I would like to see is the international language usage called out and specified in the specification. Today, while the requirement is there, the support is not.

> We might want to express the language using ISO 639 two-letter code and the ISO 3166 country codes only.

> The IETF RFC 4646 (http://tools.ietf.org/rfc/bcp/bcp47.txt) allows a script identifier and additional optional content

> that may be a bit of overkill. This is definitely worth more investigation and discussion.

I agree that including all aspects of 4646 is overkill. We list what aspects pertain to CPE and effectively limit it. Reality is I was looking at what you suggested as well as to start the discussion.

Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

From: Waltermire, Dave [mailto:[hidden email]]
Sent: Monday, August 20, 2007 8:03 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization

Kent,

The aspect of language has always been part of the CPE discussion. Languages are to be included as part of the edition. The requirement for this in the CPE 2.0 spec is:

· A CPE Name MUST be able to include the language a particular platform supports.

Also on page 12:

By adding a 5th field, are you asking that language become more prominent than it is currently?

Dave

From: Banghart, John [mailto:[hidden email]]
Sent: Monday, August 20, 2007 1:47 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization

Nothing to add other then my agreement. While this has clearly has been a US-centric effort to date, I see no reason why we shouldn’t accommodate our international colleagues.

--

John Banghart

Associate

Booz | Allen | Hamilton

Tel (703) 377-5040

[hidden email]

From: Kent Landfield [mailto:[hidden email]]
Sent: Monday, August 20, 2007 1:31 PM
To: [hidden email]
Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization

There has been no discussion of Internationalization in CPE. Why not? I don’t believe the excuse dragged out on another SCAP related list about this is a US centric standard… Just because this was initiated initially by US participants, we do not need to be short sighted here.

What if we added an optional Language Component as the final component… For example.

Language Component

The fifth and final component of a CPE Name is the language of the platform part. This is an optional component. The component values are language identifiers as defined by [IETF RFC 4646], Tags for Identifying Languages, or its successor; in addition, the empty string may be specified. An empty component defaults to English (en-US).

If we did that then we would have the option to specify versions of software used through out the world. The examples below are modified from the existing draft.

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the English language.

cpe:/o:microsoft:windows:2000:

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French language.

cpe:/o:microsoft:windows:2000:fr

The example name below represents a typical CPE Name that refers to the Microsoft Windows™ 2000 operating system, all editions and update levels in the French Canadian language.

cpe:/o:microsoft:windows:2000:fr-CA

FYI, these examples are arbitrary… <grin>

This capability is a major missing piece in the standard as it exists today. We should fix this now so all can use this specification.

--

Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

Andrew Buttner

Re: CPE 2.0 draft and Internationalization

Reply Threaded

Remember that at the core of CPE is a unique string that represents and
ID for a certain platform type. The specification of different fields
(i.e. vendor, product, ...) is only there to help in the creation of
these IDs. Given this, I think support for different languages is
already 'available'. Just create a new name for each different
language version. Maybe use the edition field.

One area of concern that Kent brings up though is how intuitive the
language piece is in the current spec. Remember that one of our goals
of the specification is define how to come up with a new CPE Name, so
that if two people try to name the same platform then they will come up
with the same name. I would agree with Kent that the current spec does
not do a good job in defining this part of the platform name.

I don't know if adding new field is the right answer, or if better
describing how to use the edition field is the way to go. Thoughts?

Drew

>-----Original Message-----
>From: Kent Landfield [mailto:[hidden email]]
>Sent: Tuesday, August 21, 2007 10:39 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>Hi Dave,
>
>
>
>Because there is a requirement does not mean it is supported.
> What I would like to see is the international language usage
>called out and specified in the specification. Today, while
>the requirement is there, the support is not.
>
>
>
>> We might want to express the language using ISO 639
>two-letter code and the ISO 3166 country codes only.
>
>> The IETF RFC 4646 (http://tools.ietf.org/rfc/bcp/bcp47.txt)
>allows a script identifier and additional optional content
>
>> that may be a bit of overkill. This is definitely worth
>more investigation and discussion.
>
>I agree that including all aspects of 4646 is overkill. We
>list what aspects pertain to CPE and effectively limit it.
>Reality is I was looking at what you suggested as well as to
>start the discussion.
>
>
>
>--
>
>Kent Landfield
>Director, Security Research
>McAfee, Inc.
>+1 972.963.7096 Direct
>+1 817.637.8026 Mobile
>[hidden email] <mailto:[hidden email]>
>www.mcafee.com <http://www.mcafee.com/>
>
>
>
>________________________________
>
>From: Waltermire, Dave [mailto:[hidden email]]
>Sent: Monday, August 20, 2007 8:03 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>
>
>Kent,
>
>
>
>The aspect of language has always been part of the CPE
>discussion. Languages are to be included as part of the
>edition. The requirement for this in the CPE 2.0 spec is:
>
>
>
>* A CPE Name MUST be able to include the language a
>particular platform supports.
>
>Also on page 12:
>
>It is quite possible that a vendor, perhaps for marketing
>purposes, may use different names for identical hardware and
>software platforms. This could occur for regional versions
>with different languages, or different vertical markets each
>with a need for the same tool. In these cases, a different
>CPE Name will be used for each of the different
>vendor-assigned names. CPE in general tries to mimic the
>product naming structures used by the vendors, while imposing
>uniform structure and matching semantics.
>
>By adding a 5th field, are you asking that language become
>more prominent than it is currently?
>
>We might want to express the language using ISO 639 two-letter
>code and the ISO 3166 country codes only. The IETF RFC 4646
>(http://tools.ietf.org/rfc/bcp/bcp47.txt) allows a script
>identifier and additional optional content that may be a bit
>of overkill. This is definitely worth more investigation and
>discussion.
>
>Dave
>
>
>________________________________
>
>
> From: Banghart, John [mailto:[hidden email]]
> Sent: Monday, August 20, 2007 1:47 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
> Nothing to add other then my agreement. While this has
>clearly has been a US-centric effort to date, I see no reason
>why we shouldn't accommodate our international colleagues.
>
>
>
>
>
> --
>
> John Banghart
>
> Associate
>
> Booz | Allen | Hamilton
>
> Tel (703) 377-5040
>
> [hidden email]
>
>
>________________________________
>
>
> From: Kent Landfield [mailto:[hidden email]]
> Sent: Monday, August 20, 2007 1:31 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>
>
> There has been no discussion of Internationalization in
>CPE. Why not? I don't believe the excuse dragged out on
>another SCAP related list about this is a US centric standard...
> Just because this was initiated initially by US participants,
>we do not need to be short sighted here.
>
>
>
> What if we added an optional Language Component as the
>final component... For example.
>
>
>
>
> Language Component
>
>
> The fifth and final component of a CPE Name is the
>language of the platform part. This is an optional component.
>The component values are language identifiers as defined by
>[IETF RFC 4646]
><ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt> , Tags for
>Identifying Languages, or its successor; in addition, the
>empty string may be specified. An empty component defaults to
>English (en-US).
>
> If we did that then we would have the option to specify
>versions of software used through out the world. The examples
>below are modified from the existing draft.
>
>
>
> The example name below represents a typical CPE
>Name that refers to the Microsoft Windows(tm) 2000 operating
>system, all editions and update levels in the English language.
>
> cpe:/o:microsoft:windows:2000:
>
> The example name below represents a typical CPE Name
>that refers to the Microsoft Windows(tm) 2000 operating system,
>all editions and update levels in the French language.
>
> cpe:/o:microsoft:windows:2000:fr
>
> The example name below represents a typical CPE Name
>that refers to the Microsoft Windows(tm) 2000 operating system,
>all editions and update levels in the French Canadian language.
>
> cpe:/o:microsoft:windows:2000:fr-CA
>
> FYI, these examples are arbitrary... <grin>
>
> This capability is a major missing piece in the
>standard as it exists today. We should fix this now so all can
>use this specification.
>
>
>
> --
>
> Kent Landfield
> Director, Security Research
> McAfee, Inc.
> +1 972.963.7096 Direct
> +1 817.637.8026 Mobile
> [hidden email] <mailto:[hidden email]>
> www.mcafee.com <http://www.mcafee.com/>
>
>
>
>

Wolfkiel, Joseph

Re: CPE 2.0 draft and Internationalization

Reply Threaded

In reply to this post by Kent_Landfield

I'm a little concerned that bringing in multiple languages virtually
guarantees that the CPE dictionary will have multiple unique identifiers
that mean the same thing. The systems analyst in me is doing flip-flops at
the concept. Seems there will be difficulties in ensuring all new
vulnerabilities end up getting pointed back to all the CPEs in all the
different languages they are stored in that mean exactly the same thing.

Lt Col Joseph L. Wolfkiel

Director, Computer Network Defense Research & Technology (CND R&T) Program
Management Office

NSA/I71
9800 Savage Rd Ste 6767
Ft Meade, MD 20755-6767
Commercial 410-854-5401 DSN 244-5401
Fax 410-854-6700

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 21, 2007 2:41 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
Internationalization

Remember that at the core of CPE is a unique string that represents and
ID for a certain platform type. The specification of different fields
(i.e. vendor, product, ...) is only there to help in the creation of
these IDs. Given this, I think support for different languages is
already 'available'. Just create a new name for each different
language version. Maybe use the edition field.

One area of concern that Kent brings up though is how intuitive the
language piece is in the current spec. Remember that one of our goals
of the specification is define how to come up with a new CPE Name, so
that if two people try to name the same platform then they will come up
with the same name. I would agree with Kent that the current spec does
not do a good job in defining this part of the platform name.

I don't know if adding new field is the right answer, or if better
describing how to use the edition field is the way to go. Thoughts?

Drew

Andrew Buttner

Re: CPE 2.0 draft and Internationalization

Reply Threaded

Very good point. Having to maintain a long list of languages for each
bulletin would be a nightmare. We would need to make sure that when
languages weren't important (i.e. a vuln applies to all language
versions) then the community uses roll-up names. If used correctly,
having the option specifying a language will allow us to denote such
platforms when necessary (i.e. a vuln that only applies to a specific
lang).

Thanks
Drew

>-----Original Message-----
>From: Wolfkiel, Joseph [mailto:[hidden email]]
>Sent: Tuesday, August 21, 2007 3:10 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>I'm a little concerned that bringing in multiple languages virtually
>guarantees that the CPE dictionary will have multiple unique
>identifiers
>that mean the same thing. The systems analyst in me is doing
>flip-flops at
>the concept. Seems there will be difficulties in ensuring all new
>vulnerabilities end up getting pointed back to all the CPEs in all the
>different languages they are stored in that mean exactly the
>same thing.
>
>Lt Col Joseph L. Wolfkiel
>
>Director, Computer Network Defense Research & Technology (CND
>R&T) Program
>Management Office
>
>NSA/I71
>9800 Savage Rd Ste 6767
>Ft Meade, MD 20755-6767
>Commercial 410-854-5401 DSN 244-5401
>Fax 410-854-6700
>
>
>-----Original Message-----
>From: Buttner, Drew [mailto:[hidden email]]
>Sent: Tuesday, August 21, 2007 2:41 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>
>Remember that at the core of CPE is a unique string that represents

and

>ID for a certain platform type. The specification of different fields
>(i.e. vendor, product, ...) is only there to help in the creation of
>these IDs. Given this, I think support for different languages is
>already 'available'. Just create a new name for each different
>language version. Maybe use the edition field.
>
>One area of concern that Kent brings up though is how intuitive the
>language piece is in the current spec. Remember that one of our goals
>of the specification is define how to come up with a new CPE Name, so
>that if two people try to name the same platform then they will come

up
>with the same name. I would agree with Kent that the current spec
does

>not do a good job in defining this part of the platform name.
>
>I don't know if adding new field is the right answer, or if better
>describing how to use the edition field is the way to go. Thoughts?
>
>Drew
>
>>-----Original Message-----
>>From: Kent Landfield [mailto:[hidden email]]
>>Sent: Tuesday, August 21, 2007 10:39 AM
>>To: cpe-discussion-list CPE Community Forum
>>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>>Internationalization
>>
>>Hi Dave,
>>
>>
>>
>>Because there is a requirement does not mean it is supported.
>> What I would like to see is the international language usage
>>called out and specified in the specification. Today, while
>>the requirement is there, the support is not.
>>
>>
>>
>>> We might want to express the language using ISO 639
>>two-letter code and the ISO 3166 country codes only.
>>
>>> The IETF RFC 4646 (http://tools.ietf.org/rfc/bcp/bcp47.txt)
>>allows a script identifier and additional optional content
>>
>>> that may be a bit of overkill. This is definitely worth
>>more investigation and discussion.
>>
>>I agree that including all aspects of 4646 is overkill. We
>>list what aspects pertain to CPE and effectively limit it.
>>Reality is I was looking at what you suggested as well as to
>>start the discussion.
>>
>>
>>
>>--
>>
>>Kent Landfield
>>Director, Security Research
>>McAfee, Inc.
>>+1 972.963.7096 Direct
>>+1 817.637.8026 Mobile
>>[hidden email] <mailto:[hidden email]>
>>www.mcafee.com <http://www.mcafee.com/>
>>
>>
>>
>>________________________________
>>
>>From: Waltermire, Dave [mailto:[hidden email]]
>>Sent: Monday, August 20, 2007 8:03 PM
>>To: [hidden email]
>>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>>Internationalization
>>
>>
>>
>>Kent,
>>
>>
>>
>>The aspect of language has always been part of the CPE
>>discussion. Languages are to be included as part of the
>>edition. The requirement for this in the CPE 2.0 spec is:
>>
>>
>>
>>* A CPE Name MUST be able to include the language a
>>particular platform supports.
>>
>>Also on page 12:
>>
>>It is quite possible that a vendor, perhaps for marketing
>>purposes, may use different names for identical hardware and
>>software platforms. This could occur for regional versions
>>with different languages, or different vertical markets each
>>with a need for the same tool. In these cases, a different
>>CPE Name will be used for each of the different
>>vendor-assigned names. CPE in general tries to mimic the
>>product naming structures used by the vendors, while imposing
>>uniform structure and matching semantics.
>>
>>By adding a 5th field, are you asking that language become
>>more prominent than it is currently?
>>
>>We might want to express the language using ISO 639 two-letter
>>code and the ISO 3166 country codes only. The IETF RFC 4646
>>(http://tools.ietf.org/rfc/bcp/bcp47.txt) allows a script
>>identifier and additional optional content that may be a bit
>>of overkill. This is definitely worth more investigation and
>>discussion.
>>
>>Dave
>>
>>
>>________________________________
>>
>>
>> From: Banghart, John [mailto:[hidden email]]
>> Sent: Monday, August 20, 2007 1:47 PM
>> To: [hidden email]
>> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>>Internationalization
>>
>> Nothing to add other then my agreement. While this has
>>clearly has been a US-centric effort to date, I see no reason
>>why we shouldn't accommodate our international colleagues.
>>
>>
>>
>>
>>
>> --
>>
>> John Banghart
>>
>> Associate
>>
>> Booz | Allen | Hamilton
>>
>> Tel (703) 377-5040
>>
>> [hidden email]
>>
>>
>>________________________________
>>
>>
>> From: Kent Landfield [mailto:[hidden email]]
>> Sent: Monday, August 20, 2007 1:31 PM
>> To: [hidden email]
>> Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>>Internationalization
>>
>>
>>
>> There has been no discussion of Internationalization in
>>CPE. Why not? I don't believe the excuse dragged out on
>>another SCAP related list about this is a US centric standard...
>> Just because this was initiated initially by US participants,
>>we do not need to be short sighted here.
>>
>>
>>
>> What if we added an optional Language Component as the
>>final component... For example.
>>
>>
>>
>>
>> Language Component
>>
>>
>> The fifth and final component of a CPE Name is the
>>language of the platform part. This is an optional component.
>>The component values are language identifiers as defined by
>>[IETF RFC 4646]
>><ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt> , Tags for
>>Identifying Languages, or its successor; in addition, the
>>empty string may be specified. An empty component defaults to
>>English (en-US).
>>
>> If we did that then we would have the option to specify
>>versions of software used through out the world. The examples
>>below are modified from the existing draft.
>>
>>
>>
>> The example name below represents a typical CPE
>>Name that refers to the Microsoft Windows(tm) 2000 operating
>>system, all editions and update levels in the English language.
>>
>> cpe:/o:microsoft:windows:2000:
>>
>> The example name below represents a typical CPE Name
>>that refers to the Microsoft Windows(tm) 2000 operating system,
>>all editions and update levels in the French language.
>>
>> cpe:/o:microsoft:windows:2000:fr
>>
>> The example name below represents a typical CPE Name
>>that refers to the Microsoft Windows(tm) 2000 operating system,
>>all editions and update levels in the French Canadian language.
>>
>> cpe:/o:microsoft:windows:2000:fr-CA
>>
>> FYI, these examples are arbitrary... <grin>
>>
>> This capability is a major missing piece in the
>>standard as it exists today. We should fix this now so all can
>>use this specification.
>>
>>
>>
>> --
>>
>> Kent Landfield
>> Director, Security Research
>> McAfee, Inc.
>> +1 972.963.7096 Direct
>> +1 817.637.8026 Mobile
>> [hidden email] <mailto:[hidden email]>
>> www.mcafee.com <http://www.mcafee.com/>
>>
>>
>>
>>
>

Kent_Landfield

Re: CPE 2.0 draft and Internationalization

Reply Threaded

>I'm a little concerned that bringing in multiple languages virtually
>guarantees that the CPE dictionary will have multiple unique
>identifiers
>that mean the same thing. The systems analyst in me is doing
>flip-flops at
>the concept. Seems there will be difficulties in ensuring all new
>vulnerabilities end up getting pointed back to all the CPEs in all the
>different languages they are stored in that mean exactly the
>same thing.

That is not the intention of adding the appropriate language support.
The
intention is to assure items that are language specific have a means
to indicate so. A common issue is a common issue and there is no need
to break it out into each possible language just to do so.

Developing checks to support specific patch definitions have a real need
to
be able to indicate which language pack/platform they pertain to. If we
are
determining system compliance that includes being up-to-date with the
latest patches, we need language support in the specification. Same
thing is true
for certain configuration items that have language specific
requirements.

A German version of Microsoft XP is pretty common in Germany, a Japanese
version of XP is pretty common in Japan and so on. OS vendors have
support
for multiple languages in their operating systems and at a bare minimum
we
need to be able to support them. Otherwise we need to change the name of
the
effort from Common Platform Enumeration to something else. <grin>

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

and

up
>with the same name. I would agree with Kent that the current spec
does

Thomas R. Jones

Re: CPE 2.0 draft and Internationalization

Reply Threaded

In reply to this post by Andrew Buttner

On Tue, 2007-08-21 at 14:40 -0400, Buttner, Drew wrote:

> Remember that at the core of CPE is a unique string that represents and
> ID for a certain platform type. The specification of different fields
> (i.e. vendor, product, ...) is only there to help in the creation of
> these IDs. Given this, I think support for different languages is
> already 'available'. Just create a new name for each different
> language version. Maybe use the edition field.
>
> One area of concern that Kent brings up though is how intuitive the
> language piece is in the current spec. Remember that one of our goals
> of the specification is define how to come up with a new CPE Name, so
> that if two people try to name the same platform then they will come up
> with the same name. I would agree with Kent that the current spec does
> not do a good job in defining this part of the platform name.
>
> I don't know if adding new field is the right answer, or if better
> describing how to use the edition field is the way to go. Thoughts?

Why not use standardized language specification already implemented ---
xml:lang? No reason to reinvent the wheel.

http://www.w3.org/TR/REC-xml/

Cheers.
Thomas

signature.asc (196 bytes) Download Attachment

Andrew Buttner

Re: CPE 2.0 draft and Internationalization

Reply Threaded

>> Remember that at the core of CPE is a unique string that
>> represents and ID for a certain platform type. The
>> specification of different fields (i.e. vendor, product,
>> ...) is only there to help in the creation of these IDs.
>> Given this, I think support for different languages is
>> already 'available'. Just create a new name for each
>> different language version. Maybe use the edition field.
>>
>> One area of concern that Kent brings up though is how
>> intuitive the language piece is in the current spec.
>> Remember that one of our goals of the specification is
>> define how to come up with a new CPE Name, so
>> that if two people try to name the same platform then
>> they will come up with the same name. I would agree with
>> Kent that the current spec does not do a good job in
>> defining this part of the platform name.
>>
>> I don't know if adding new field is the right answer, or if better
>> describing how to use the edition field is the way to go. Thoughts?
>
>Why not use standardized language specification already implemented

---
>xml:lang? No reason to reinvent the wheel.

I think xml:lang will work for XML languages like XCCDF and OVAL, where
we need to encode in XML the language that is being used for the
enclosed text elements. But for CPE we are looking to create an ID in
a URI format with this ID referring to a platform targeted at a
specific language. Since we aren't using XML, I don't thing xml:lang
will work for us.

Having said that, we can (and should) use xml:lang in the CPE
Dictionary schema for the <title> element to enable different titles
for the different languages. I will add this to the next draft.

Thanks
Drew

Noakes, Douglas [USA]

Re: CPE 2.0 draft and Internationalization

Reply Threaded

In reply to this post by Andrew Buttner

NVD Analyst perspective:
The edition field is where this information is currently stored (if it
exists) for the most part. I suspect there are some instances of
products where this information is captured somewhere else (i.e., the
product name itself has language-specific identifiers, or possibly a
version that has some type of language identifier attached to it, for
example "2.0 fr" meaning the French instantiation of version 2.0 of XXX
product).

I would also say that language specification is not terribly common.

Thank You,
Doug

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: Tuesday, August 21, 2007 2:41 PM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
Internationalization

Remember that at the core of CPE is a unique string that represents and
ID for a certain platform type. The specification of different fields
(i.e. vendor, product, ...) is only there to help in the creation of
these IDs. Given this, I think support for different languages is
already 'available'. Just create a new name for each different language
version. Maybe use the edition field.

One area of concern that Kent brings up though is how intuitive the
language piece is in the current spec. Remember that one of our goals
of the specification is define how to come up with a new CPE Name, so
that if two people try to name the same platform then they will come up
with the same name. I would agree with Kent that the current spec does
not do a good job in defining this part of the platform name.

I don't know if adding new field is the right answer, or if better
describing how to use the edition field is the way to go. Thoughts?

Drew

>there, the support is not.
>
>
>
>> We might want to express the language using ISO 639
>two-letter code and the ISO 3166 country codes only.
>
>> The IETF RFC 4646 (http://tools.ietf.org/rfc/bcp/bcp47.txt)
>allows a script identifier and additional optional content
>
>> that may be a bit of overkill. This is definitely worth
>more investigation and discussion.
>
>I agree that including all aspects of 4646 is overkill. We list what
>aspects pertain to CPE and effectively limit it.
>Reality is I was looking at what you suggested as well as to start the
>discussion.
>
>
>
>--
>
>Kent Landfield
>Director, Security Research
>McAfee, Inc.
>+1 972.963.7096 Direct
>+1 817.637.8026 Mobile
>[hidden email] <mailto:[hidden email]>
>www.mcafee.com <http://www.mcafee.com/>
>
>
>
>________________________________
>
>From: Waltermire, Dave [mailto:[hidden email]]
>Sent: Monday, August 20, 2007 8:03 PM
>To: [hidden email]
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>
>
>Kent,
>
>
>
>The aspect of language has always been part of the CPE discussion.
>Languages are to be included as part of the edition. The requirement
>for this in the CPE 2.0 spec is:
>
>
>
>* A CPE Name MUST be able to include the language a
>particular platform supports.
>
>Also on page 12:
>
>It is quite possible that a vendor, perhaps for marketing purposes, may

>use different names for identical hardware and software platforms.
>This could occur for regional versions with different languages, or
>different vertical markets each with a need for the same tool. In
>these cases, a different CPE Name will be used for each of the
>different vendor-assigned names. CPE in general tries to mimic the
>product naming structures used by the vendors, while imposing uniform
>structure and matching semantics.
>
>By adding a 5th field, are you asking that language become more
>prominent than it is currently?
>
>We might want to express the language using ISO 639 two-letter code and

>the ISO 3166 country codes only. The IETF RFC 4646
>(http://tools.ietf.org/rfc/bcp/bcp47.txt) allows a script identifier
>and additional optional content that may be a bit of overkill. This is

>definitely worth more investigation and discussion.
>
>Dave
>
>
>________________________________
>
>
> From: Banghart, John [mailto:[hidden email]]
> Sent: Monday, August 20, 2007 1:47 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
> Nothing to add other then my agreement. While this has clearly

has

>been a US-centric effort to date, I see no reason why we shouldn't
>accommodate our international colleagues.
>
>
>
>
>
> --
>
> John Banghart
>
> Associate
>
> Booz | Allen | Hamilton
>
> Tel (703) 377-5040
>
> [hidden email]
>
>
>________________________________
>
>
> From: Kent Landfield [mailto:[hidden email]]
> Sent: Monday, August 20, 2007 1:31 PM
> To: [hidden email]
> Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and

Internationalization
>
>
>
> There has been no discussion of Internationalization in CPE.
Why not?

>I don't believe the excuse dragged out on another SCAP related list
>about this is a US centric standard...
> Just because this was initiated initially by US participants, we do
>not need to be short sighted here.
>
>
>
> What if we added an optional Language Component as the final
>component... For example.
>
>
>
>
> Language Component
>
>
> The fifth and final component of a CPE Name is the language of

the
>platform part. This is an optional component.
>The component values are language identifiers as defined by [IETF RFC
>4646] <ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt> , Tags for
>Identifying Languages, or its successor; in addition, the empty string
>may be specified. An empty component defaults to English (en-US).
>
> If we did that then we would have the option to specify versions
of
>software used through out the world. The examples below are modified
>from the existing draft.
>
>
>
> The example name below represents a typical CPE Name that
refers
>to the Microsoft Windows(tm) 2000 operating system, all editions and
>update levels in the English language.
>
> cpe:/o:microsoft:windows:2000:
>
> The example name below represents a typical CPE Name that refers
to
>the Microsoft Windows(tm) 2000 operating system, all editions and
>update levels in the French language.
>
> cpe:/o:microsoft:windows:2000:fr
>
> The example name below represents a typical CPE Name that refers
to
>the Microsoft Windows(tm) 2000 operating system, all editions and
>update levels in the French Canadian language.
>
> cpe:/o:microsoft:windows:2000:fr-CA
>
> FYI, these examples are arbitrary... <grin>
>
> This capability is a major missing piece in the standard as it
exists

>today. We should fix this now so all can use this specification.
>
>
>
> --
>
> Kent Landfield
> Director, Security Research
> McAfee, Inc.
> +1 972.963.7096 Direct
> +1 817.637.8026 Mobile
> [hidden email] <mailto:[hidden email]>
> www.mcafee.com <http://www.mcafee.com/>
>
>
>
>

Neal Ziring-2

Re: CPE 2.0 draft and Internationalization

Reply Threaded

In reply to this post by Kent_Landfield

Drew, Doug, and everybody,

The language is not always captured in
the version number. For example, Windows is
sold for many different locales, and patches
and other mitigations have to be adjusted for
that. This would be relevant for the <fix>
tag in XCCDF. Some applications are sold or
installed in different language versions, too.

The standard format for a language code is
the 2-character language followed by an
underscore and then the 2-character country
code.

So, if we were talking about a Spanish
version of Windows XP Pro, we might have:

cpe:/o:microsoft:windows:xp:pro:sp_mx [N.G.]

Unfortunately, not everybody uses the full
language code on their software. Some use
just the language. So, we might want to
separate the code into two parts:

cpe:/o:microsoft:windows:xp:pro:sp:mx [OK]

This has the desired prefix property. If
you wanted to refer to all Chinese editions of
RedHat AS 4, you might use

cpe:/o:redhat:linux:4:as:zh

However, this raises an issue that I could not
resolve by reading the current spec draft:
are name components after the first four
ordered? In other words, are the two names
below different CPE Names?

cpe:/o:microsoft:windows:vista:ultimate:fr:sp2
cpe:/o:microsoft:windows:vista:ultimate:sp2:fr

Drew - I'm ready to re-write section 7 of the spec
document, but we need to resolve this ordering issue
first.

.nz (Neal Ziring, NSA I7, 410-854-5762)

Noakes, Douglas wrote:

> NVD Analyst perspective:
> The edition field is where this information is currently stored (if it
> exists) for the most part. I suspect there are some instances of
> products where this information is captured somewhere else (i.e., the
> product name itself has language-specific identifiers, or possibly a
> version that has some type of language identifier attached to it, for
> example "2.0 fr" meaning the French instantiation of version 2.0 of XXX
> product).
>
> I would also say that language specification is not terribly common.
>
> Thank You,
> Doug
>
>
> -----Original Message-----
> From: Buttner, Drew [mailto:[hidden email]] Sent: Tuesday, August 21, 2007 2:41 PM
> To: [hidden email]
> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
> Internationalization
>
> Remember that at the core of CPE is a unique string that represents and
> ID for a certain platform type. The specification of different fields
> (i.e. vendor, product, ...) is only there to help in the creation of
> these IDs. Given this, I think support for different languages is
> already 'available'. Just create a new name for each different language
> version. Maybe use the edition field.
>
> One area of concern that Kent brings up though is how intuitive the
> language piece is in the current spec. Remember that one of our goals
> of the specification is define how to come up with a new CPE Name, so
> that if two people try to name the same platform then they will come up
> with the same name. I would agree with Kent that the current spec does
> not do a good job in defining this part of the platform name.
>
> I don't know if adding new field is the right answer, or if better
> describing how to use the edition field is the way to go. Thoughts?
>
> Drew
>
>> -----Original Message-----
>> From: Kent Landfield [mailto:[hidden email]]
>> Sent: Tuesday, August 21, 2007 10:39 AM
>> To: cpe-discussion-list CPE Community Forum
>> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization
>>
>> Hi Dave,
>>
>>
>>
>> Because there is a requirement does not mean it is supported. What I would like to see is the international language usage called out and specified in the specification. Today, while the requirement is
>
>> there, the support is not.
>>
>>
>>
>>> We might want to express the language using ISO 639
>> two-letter code and the ISO 3166 country codes only.
>>> The IETF RFC 4646 (http://tools.ietf.org/rfc/bcp/bcp47.txt)
>> allows a script identifier and additional optional content
>>
>>> that may be a bit of overkill. This is definitely worth
>> more investigation and discussion.
>>
>> I agree that including all aspects of 4646 is overkill. We list what aspects pertain to CPE and effectively limit it.
>> Reality is I was looking at what you suggested as well as to start the discussion.
>>
>>
>>
>> --
>>
>> Kent Landfield
>> Director, Security Research
>> McAfee, Inc.
>> +1 972.963.7096 Direct
>> +1 817.637.8026 Mobile
>> [hidden email] <mailto:[hidden email]>
>> www.mcafee.com <http://www.mcafee.com/>
>>
>>
>>
>> ________________________________
>>
>> From: Waltermire, Dave [mailto:[hidden email]]
>> Sent: Monday, August 20, 2007 8:03 PM
>> To: [hidden email]
>> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization
>>
>>
>>
>> Kent,
>>
>>
>>
>> The aspect of language has always been part of the CPE discussion. Languages are to be included as part of the edition. The requirement for this in the CPE 2.0 spec is:
>>
>>
>>
>> * A CPE Name MUST be able to include the language a particular platform supports.
>> Also on page 12:
>>
>> It is quite possible that a vendor, perhaps for marketing purposes, may
>
>> use different names for identical hardware and software platforms. This could occur for regional versions with different languages, or different vertical markets each with a need for the same tool. In these cases, a different CPE Name will be used for each of the different vendor-assigned names. CPE in general tries to mimic the product naming structures used by the vendors, while imposing uniform structure and matching semantics.
>>
>> By adding a 5th field, are you asking that language become more prominent than it is currently?
>>
>> We might want to express the language using ISO 639 two-letter code and
>
>> the ISO 3166 country codes only. The IETF RFC 4646
>> (http://tools.ietf.org/rfc/bcp/bcp47.txt) allows a script identifier and additional optional content that may be a bit of overkill. This is
>
>> definitely worth more investigation and discussion.
>>
>> Dave
>>
>>
>> ________________________________
>>
>>
>> From: Banghart, John [mailto:[hidden email]] Sent: Monday, August 20, 2007 1:47 PM
>> To: [hidden email]
>> Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and Internationalization
>>
>> Nothing to add other then my agreement. While this has clearly
> has
>> been a US-centric effort to date, I see no reason why we shouldn't accommodate our international colleagues.
>>
>>
>>
>> --
>>
>> John Banghart
>>
>> Associate
>>
>> Booz | Allen | Hamilton
>>
>> Tel (703) 377-5040
>>
>> [hidden email]
>>
>>
>> ________________________________
>>
>>
>> From: Kent Landfield [mailto:[hidden email]] Sent: Monday, August 20, 2007 1:31 PM
>> To: [hidden email]
>> Subject: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
> Internationalization
>>
>> There has been no discussion of Internationalization in CPE.
> Why not?
>> I don't believe the excuse dragged out on another SCAP related list about this is a US centric standard...
>> Just because this was initiated initially by US participants, we do not need to be short sighted here.
>>
>>
>> What if we added an optional Language Component as the final component... For example.
>>
>>
>>
>> Language Component
>>
>>
>> The fifth and final component of a CPE Name is the language of
> the
>> platform part. This is an optional component.
>> The component values are language identifiers as defined by [IETF RFC 4646] <ftp://ftp.rfc-editor.org/in-notes/rfc4646.txt> , Tags for Identifying Languages, or its successor; in addition, the empty string may be specified. An empty component defaults to English (en-US).
>>
>> If we did that then we would have the option to specify versions
> of
>> software used through out the world. The examples below are modified from the existing draft.
>>
>> The example name below represents a typical CPE Name that
> refers
>> to the Microsoft Windows(tm) 2000 operating system, all editions and update levels in the English language.
>>
>> cpe:/o:microsoft:windows:2000:
>>
>> The example name below represents a typical CPE Name that refers
> to
>> the Microsoft Windows(tm) 2000 operating system, all editions and update levels in the French language.
>>
>> cpe:/o:microsoft:windows:2000:fr
>>
>> The example name below represents a typical CPE Name that refers
> to
>> the Microsoft Windows(tm) 2000 operating system, all editions and update levels in the French Canadian language.
>>
>> cpe:/o:microsoft:windows:2000:fr-CA
>>
>> FYI, these examples are arbitrary... <grin>
>>
>> This capability is a major missing piece in the standard as it
> exists
>> today. We should fix this now so all can use this specification.
>>
>>
>> --
>>
>> Kent Landfield
>> Director, Security Research
>> McAfee, Inc.
>> +1 972.963.7096 Direct
>> +1 817.637.8026 Mobile
>> [hidden email] <mailto:[hidden email]> www.mcafee.com <http://www.mcafee.com/>
>>
>>
>>

...nz (Neal Ziring, [hidden email], http://users.erols.com/ziring/)

Andrew Buttner

Re: CPE 2.0 draft and Internationalization

Reply Threaded

>However, this raises an issue that I could not
>resolve by reading the current spec draft:
>are name components after the first four
>ordered? In other words, are the two names
>below different CPE Names?
>
> cpe:/o:microsoft:windows:vista:ultimate:fr:sp2
> cpe:/o:microsoft:windows:vista:ultimate:sp2:fr

NOTE - We were leaning for including service pack info as part of the
version. So ...

cpe:/o:microsoft:windows:xp-sp2
cpe:/o:microsoft:windows:vista-sp1
etc.

This is only called out in the spec through an example, I will try to
expand this a bit.

The 2.0 spec does not allow additional components. It stops after the
edition. The reason for this change is that we could not figure out
how to handle the inconsistency with undefined components. For
example, two people would come up with different names that mean the
same thing, just like the example you point out above.

I see two possibilities for language:

1) add another component after edition that refers to language.
Remember that we can leave components empty so if we want to write a
name for all Chinese editions of Red Hat Enterprise Linux we would get:

cpe:/o:redhat:enterprise_linux:::zh

For all Chinese editions of Red Hat Enterprise Linux 4 AS, we would
get:

cpe:/o:redhat:enterprise_linux:4:as:zh

As Neal mentioned, we would still have to decide if this language
component is two components (to satisfy language and country codes) or
if there should just be a single language component that holds both
pieces of info.

>Drew - I'm ready to re-write section 7 of the spec
>document, but we need to resolve this ordering issue
>first.

Great, I have an update to send you before you start.

Thanks
Drew

Jay Graver

Re: CPE 2.0 draft and Internationalization

Reply Threaded

>> cpe:/o:microsoft:windows:vista:ultimate:fr:sp2
>> cpe:/o:microsoft:windows:vista:ultimate:sp2:fr
>
> NOTE - We were leaning for including service pack info as part of the
> version. So ...
>
> cpe:/o:microsoft:windows:xp-sp2
> cpe:/o:microsoft:windows:vista-sp1
> etc.

Would that make the 'Release Version' of these OSes

cpe:/o:microsoft:windows:xp-sp0
cpe:/o:microsoft:windows:vista-sp0

??

Jay Graver
nCircle Network Security

Andrew Buttner

Re: CPE 2.0 draft and Internationalization

Reply Threaded

I think Microsoft uses the term "gold" so you would have:

cpe:/o:microsoft:windows:xp-gold
cpe:/o:microsoft:windows:vista-gold

>-----Original Message-----
>From: Jay Graver [mailto:[hidden email]]
>Sent: Monday, August 27, 2007 10:20 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>>> cpe:/o:microsoft:windows:vista:ultimate:fr:sp2
>>> cpe:/o:microsoft:windows:vista:ultimate:sp2:fr
>>
>> NOTE - We were leaning for including service pack info as part of

the

>> version. So ...
>>
>> cpe:/o:microsoft:windows:xp-sp2
>> cpe:/o:microsoft:windows:vista-sp1
>> etc.
>
>
>Would that make the 'Release Version' of these OSes
>
>cpe:/o:microsoft:windows:xp-sp0
>cpe:/o:microsoft:windows:vista-sp0
>
>??
>
>Jay Graver
>nCircle Network Security
>

Jay Graver

Re: CPE 2.0 draft and Internationalization

Reply Threaded

They appear to use 'RTM' (Release To Manufacture) as often if not more
often than 'Gold'.

RTM seems to date back to Windows NT 4.0.

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: August 27, 2007 10:23 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
Internationalization

I think Microsoft uses the term "gold" so you would have:

cpe:/o:microsoft:windows:xp-gold
cpe:/o:microsoft:windows:vista-gold

the

Kent_Landfield

Re: CPE 2.0 draft and Internationalization

Reply Threaded

We need to be able to specify both...

cpe:/o:microsoft:windows:xp

since there may be a need to identify all xp systems as is shown above.

Specifying
cpe:/o:microsoft:windows:xp-gold (or rtm or what ever is decided upon)

would be used to specify an issue or configuration that only exists on
that specific version of Windows XP.

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

-----Original Message-----
From: Jay Graver [mailto:[hidden email]]
Sent: Monday, August 27, 2007 9:38 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
Internationalization

They appear to use 'RTM' (Release To Manufacture) as often if not more
often than 'Gold'.

RTM seems to date back to Windows NT 4.0.

-----Original Message-----
From: Buttner, Drew [mailto:[hidden email]]
Sent: August 27, 2007 10:23 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
Internationalization

I think Microsoft uses the term "gold" so you would have:

cpe:/o:microsoft:windows:xp-gold
cpe:/o:microsoft:windows:vista-gold

the

Kent_Landfield

Re: CPE 2.0 draft and Internationalization

Reply Threaded

In reply to this post by Andrew Buttner

I asked our i18N Development Manager responsible for McAfee Localization
as to what made the most sense from an existing commercial product
industry perspective. His response is included below this message.

Drew writes:
> I see two possibilities for language:
>
> 1) add another component after edition that refers to language.
> Remember that we can leave components empty so if we want to write a
> name for all Chinese editions of Red Hat Enterprise Linux we would
get:

>
> cpe:/o:redhat:enterprise_linux:::zh
>
> For all Chinese editions of Red Hat Enterprise Linux 4 AS, we would
> get:
>
> cpe:/o:redhat:enterprise_linux:4:as:zh
>
> As Neal mentioned, we would still have to decide if this language
> component is two components (to satisfy language and country codes) or
> if there should just be a single language component that holds both
> pieces of info.

I think it should be a single component that contains both pieces as
required since both may not be required to properly identify a specific
version of the software.

For example - All German versions of RHEL 4 AS
cpe:/o:redhat:enterprise_linux:4:as:de

For example - German version of RHEL 4 AS for Austria
cpe:/o:redhat:enterprise_linux:4:as:de-at

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

-----Original Message-----
From: Killeen, Aidan
Sent: Thursday, August 23, 2007 3:37 AM
To: Landfield, Kent
Subject: Iso codes for specifying the locale for software

Hi Kent,

Just to clarify some of the things we discussed yesterday.

The Culture or Locale for a piece of software is generally sepcified by
a unique name based on the original RFC1766 standard. This standard uses
the format:

<languagecode2>-<country/regioncode2>

Where <languagecode2> is a lowercase two-letter culture code associated
with a language, derived from ISO 639-1 and where <country/regioncode2>
is an uppercase two-letter subculture code derived from ISO 3166.

Some examples

en-US - English as spoken/written in the US
en-GB - English as spoken/written in the UK
de-DE - German as spoken/written in Germany
de-AT - German as spoken/written in Austria
fr-FR - French as spoken/written in France
fr-CA - French as spoken/written in Canada
ja-JP - Japanese as spoken/written in Japan

McAfee and most other software manufacturers will use these codes to
describe the language version of their products and it would make sense
to use this standard.

Often it doesn't make sense to release a version of a product for each
locale and in these cases the locale will be specified as the "neutral
culture" - for example we only have one German version of our products
so would generally specify it as "de" rather than "de-DE". Using the
neutral culture specifies the language rather than a specific region
that speaks the language and the software will work in de-DE and de-AT
and any other region that speaks German.

It is very important to use the correct neutral culture as specified by
the standard - we frequently have problems with people using "JP" as the
netural culture for Japan when the correct neutral culture is "ja".

Please let me know if you need any further assistance.

Best regards

Aidan

Aidan Killeen
Development Manager - i18n
McAfee Localisation - Cork

Ken Lassesen-2

Re: CPE 2.0 draft and Internationalization

Reply Threaded

I'm in agreement with Kent.

If it's an issue with something like cryptography, then there may be a
difference of product between Chinese windows for sale in China and
Chinese windows for sale in Canada (some cities has a large Chinese
population to put it very mildly)

Ken Lassesen,
Office 206-734-4718 Home: 360-297-4717 Cell: 360-509-2402 Skype:
Ken.Lassesen
IM: [hidden email]

CONFIDENTIALITY NOTICE
The information contained in this electronic message may contain
confidential and privileged information and is intended only for use by
the individual(s) or entity(ies) to whom it was addressed. Any
unauthorized review, use, disclosure, or distribution of this
communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and permanently
delete and destroy the original message.

-----Original Message-----
From: Kent Landfield [mailto:[hidden email]]
Sent: Monday, August 27, 2007 8:13 AM
To: [hidden email]
Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
Internationalization
I think it should be a single component that contains both pieces as
required since both may not be required to properly identify a specific
version of the software.

For example - All German versions of RHEL 4 AS
cpe:/o:redhat:enterprise_linux:4:as:de

For example - German version of RHEL 4 AS for Austria
cpe:/o:redhat:enterprise_linux:4:as:de-at

--
Kent Landfield
Director, Security Research
McAfee, Inc.
+1 972.963.7096 Direct
+1 817.637.8026 Mobile
[hidden email]
www.mcafee.com

Andrew Buttner

Re: CPE 2.0 draft and Internationalization

Reply Threaded

In reply to this post by Kent_Landfield

Really good info, thanks!! After reading this I am in agreement about
the single component, although CPE matching won't work perfectly as

cpe:/o:redhat:enterprise_linux:4:as:de
cpe:/o:redhat:enterprise_linux:4:as:de-at

will be thought of as two different platform types even though one is a
subset of the other.

The example above is also using language as a separate component. So
the CPE Name would take the form:

part:vendor:product:version:edition:language

Is adding another component something we want to do? If so do we also
want to add one for "update"? (ie service pack for windows) In that
case names would take the form:

part:vendor:product:version:update:edition:language

What about architecture? We need to be careful about where we stop.
We don't want to keep adding components all the time. At some point,
CPE should stop and lower level languages like OVAL should be used to
identify platforms.

Thanks
Drew

>-----Original Message-----
>From: Kent Landfield [mailto:[hidden email]]
>Sent: Monday, August 27, 2007 11:13 AM
>To: cpe-discussion-list CPE Community Forum
>Subject: Re: [CPE-DISCUSSION-LIST] CPE 2.0 draft and
>Internationalization
>
>I asked our i18N Development Manager responsible for McAfee
>Localization
>as to what made the most sense from an existing commercial product
>industry perspective. His response is included below this message.
>
>Drew writes:
>> I see two possibilities for language:
>>
>> 1) add another component after edition that refers to language.
>> Remember that we can leave components empty so if we want to write a
>> name for all Chinese editions of Red Hat Enterprise Linux we would
>get:
>>
>> cpe:/o:redhat:enterprise_linux:::zh
>>
>> For all Chinese editions of Red Hat Enterprise Linux 4 AS, we would
>> get:
>>
>> cpe:/o:redhat:enterprise_linux:4:as:zh
>>
>> As Neal mentioned, we would still have to decide if this language
>> component is two components (to satisfy language and country
>codes) or
>> if there should just be a single language component that holds both
>> pieces of info.
>
>I think it should be a single component that contains both pieces as
>required since both may not be required to properly identify a

specific

>version of the software.
>
>For example - All German versions of RHEL 4 AS
> cpe:/o:redhat:enterprise_linux:4:as:de
>
>For example - German version of RHEL 4 AS for Austria
> cpe:/o:redhat:enterprise_linux:4:as:de-at
>
>--
>Kent Landfield
>Director, Security Research
>McAfee, Inc.
>+1 972.963.7096 Direct
>+1 817.637.8026 Mobile
>[hidden email]
>www.mcafee.com
>
>
>-----Original Message-----
>From: Killeen, Aidan
>Sent: Thursday, August 23, 2007 3:37 AM
>To: Landfield, Kent
>Subject: Iso codes for specifying the locale for software
>
>Hi Kent,
>
>Just to clarify some of the things we discussed yesterday.
>
>The Culture or Locale for a piece of software is generally sepcified

by
>a unique name based on the original RFC1766 standard. This
>standard uses
>the format:
>
><languagecode2>-<country/regioncode2>
>
>Where <languagecode2> is a lowercase two-letter culture code
associated
>with a language, derived from ISO 639-1 and where
<country/regioncode2>

>is an uppercase two-letter subculture code derived from ISO 3166.
>
>Some examples
>
>en-US - English as spoken/written in the US
>en-GB - English as spoken/written in the UK
>de-DE - German as spoken/written in Germany
>de-AT - German as spoken/written in Austria
>fr-FR - French as spoken/written in France
>fr-CA - French as spoken/written in Canada
>ja-JP - Japanese as spoken/written in Japan
>
>McAfee and most other software manufacturers will use these codes to
>describe the language version of their products and it would make

sense

>to use this standard.
>
>Often it doesn't make sense to release a version of a product for each
>locale and in these cases the locale will be specified as the "neutral
>culture" - for example we only have one German version of our products
>so would generally specify it as "de" rather than "de-DE". Using the
>neutral culture specifies the language rather than a specific region
>that speaks the language and the software will work in de-DE and de-AT
>and any other region that speaks German.
>
>It is very important to use the correct neutral culture as specified

>the standard - we frequently have problems with people using
>"JP" as the
>netural culture for Japan when the correct neutral culture is "ja".
>
>Please let me know if you need any further assistance.
>
>Best regards
>
>Aidan
>
>Aidan Killeen
>Development Manager - i18n
>McAfee Localisation - Cork
>

1 2