Specification Notes

[Thomas R. Jones]

Hello all,

I have been thoroughly reviewing the CPE specification and have found
some issues with regards to the URI specification. The following notes
are available and submitted:

1.) The format does not follow the IETF boilerplate. For global adoption
of the CPE specification this should be done. A more approach or
architectural specification(informal) may be authored to provide for
end-user readability.
2.) The status of URI registration is not declared or even mentioned
within the specification.
3.) If no formal URI scheme registration with IANA is expected then the
URI scheme should be at minimum declared as provisional.
4.) The URI structure does not follow the URI specification. This can be
allowed due to implementation requirements, however the divergence
should be validated.
5.) The naming convention for constituent elements of the URI scheme is
highly irregular. The URI specification already denotes elemental
objects as components, sub-components,etc... Why should "part" or
"facet" by utilized, when it detracts from readability?
6.) The CPE "prefix" should be declared as a URI scheme. This brings the
CPE inline with other URI specifications. This also helps to negate the
misconception that a URI is directly associated with a protocol.
Subsequently, this validates that the preceding URI scheme structure
denotes the root hierarchy of the specification and that no other
hierarchical elements exist. Also denotes that the URI scheme follows
the URI specification and that the URI scheme is not included within a
parsing or dereferencing of the URI.
7.) The BNF syntax does not follow the BNF specification. As a side
note, it would greatly increase readability of the grammar to convert to
Extended BNF(EBNF).
8.) The CPE structure should be denoted as an "Identifier". Follows URI
specification(may also be referenced as a target). This further declares
that the resource may indeed be a non-accessible resource. Commonly with
URI's individuals associate the URI with the protocol and therefore
determine that the resource must be an accessible and discrete object.
When in fact within the context of the CPE, most will not be.
9.) Declaration of network and non-network identifiers should be made.
This disambiguates the conception that all identifiers are network
accessible.

These are just some of the noticeable issues that came to mind while
reading the specification. I thought it might be a good idea to get
these issues out in the open before the specification and subsequent
adoption gets to far along.

Thanks.
Thomas R. Jones

[Andrew Buttner]

Thank you very much for these comments.  This is really helpful for the
development of the spec.  I will try to incorporate them into the
specification revision that I am working on.

Thanks again.
Drew

>-----Original Message-----
>From: Thomas R. Jones [mailto:[hidden email]]
>Sent: Saturday, June 09, 2007 11:01 PM
>To: cpe-discussion-list CPE Community Forum
>Subject: [CPE-DISCUSSION-LIST] Specification Notes
>
>Hello all,
>
>I have been thoroughly reviewing the CPE specification and have found
>some issues with regards to the URI specification. The following notes
>are available and submitted:
>
>1.) The format does not follow the IETF boilerplate. For
>global adoption
>of the CPE specification this should be done. A more approach or
>architectural specification(informal) may be authored to provide for
>end-user readability.
>2.) The status of URI registration is not declared or even mentioned
>within the specification.
>3.) If no formal URI scheme registration with IANA is expected then

the
>URI scheme should be at minimum declared as provisional.
>4.) The URI structure does not follow the URI specification.
>This can be
>allowed due to implementation requirements, however the divergence
>should be validated.
>5.) The naming convention for constituent elements of the URI scheme
is
>highly irregular. The URI specification already denotes elemental
>objects as components, sub-components,etc... Why should "part" or
>"facet" by utilized, when it detracts from readability?
>6.) The CPE "prefix" should be declared as a URI scheme. This
>brings the
>CPE inline with other URI specifications. This also helps to negate
the

>misconception that a URI is directly associated with a protocol.
>Subsequently, this validates that the preceding URI scheme structure
>denotes the root hierarchy of the specification and that no other
>hierarchical elements exist. Also denotes that the URI scheme follows
>the URI specification and that the URI scheme is not included within a
>parsing or dereferencing of the URI.
>7.) The BNF syntax does not follow the BNF specification. As a side
>note, it would greatly increase readability of the grammar to
>convert to
>Extended BNF(EBNF).
>8.) The CPE structure should be denoted as an "Identifier". Follows

URI

>specification(may also be referenced as a target). This
>further declares
>that the resource may indeed be a non-accessible resource.
>Commonly with
>URI's individuals associate the URI with the protocol and therefore
>determine that the resource must be an accessible and discrete object.
>When in fact within the context of the CPE, most will not be.
>9.) Declaration of network and non-network identifiers should be made.
>This disambiguates the conception that all identifiers are network
>accessible.
>
>These are just some of the noticeable issues that came to mind while
>reading the specification. I thought it might be a good idea to get
>these issues out in the open before the specification and subsequent
>adoption gets to far along.
>
>Thanks.
>Thomas R. Jones
>

[Andrew Buttner]

>4.) The URI structure does not follow the URI specification.
>This can be allowed due to implementation requirements, however
>the divergence should be validated.

I assume this comment has to do with CPE's use of the slash '/'
character.  I have looked at the URI syntax specification
http://gbiv.com/protocols/uri/rfc/rfc3986.html and it says in section
3.3 that "If a URI does not contain an authority component, then the
path cannot begin with two slash characters ('//')."  The CPE spec does
not specify an authority so our names should not start with a '//'.

This double slash happens when the CPE Name does not define a hardware
part.  For example:

cpe://microsoft:windows:2000

As talked about in our call last week, the revision of the
specification I am working will only allow one part (hardware, os,
application) per name.  So I propose that instead of using a slash '/'
to distinguish each part, that we use a single character code.

h = hardware part
o = os part
a = application part

Examples would now be:

cpe:/o:microsoft:windows:2000
cpe:/o:sun:sunos:5.9
cpe:/a:adobe:reader
cpe:/h:intel:pentium

thoughts?  I think this satisfies the URI spec?

Thanks
Drew