Hi Erik and Hal,
Erik is correct. The scheme in 3.2.2.1 of the proposed v5-02 is based
on the assumption that URIs are in the form prescribed in section 2.2.
As to accuracy of the "form" in section 2.2, the only real problem I
see is that the ":" should be fixed to be "://". I believe this was an
oversight in the original.
As to the inclusion of the "/" after the "<authority>", this is
because the <authority> in the notes following is assumed to be
always present, which means according to RFC 2396 that a "/" will, at
minimum follow.
The "<path>" is then prescribed to be <root name> [ "/"
<node name> ] * , which is a perfectly legal URI.
As to the intention of this section being simply a faulty summary of
the RFC 2396 spec vs a "prescription" recommended URI, I would cite the
original email and spec where this data appeared:
http://lists.oasis-open.org/archives/xacml/200405/msg00104.html
which says:
"The revision has the following significant changes:
1) Proposes a standard URI representation for hierarchical resources
that are not XML documents. This representation allows use of the
anyURI-equal and anyURI-match functions where the path to a requested
node is important. This representation may be overridden by a
resource-specific Profile. ..."
This appears to fairly unambiguously state that it is a prescription
specially defined to ensure that it would work with the anyURI
functions.
Furthermore, the whole section in the actual text of that revision
(attached to the email ref) was prefaced by this sentence:
"Unless otherwise specified by a resource-specific Profile,
the identity of a node in a resource that is not an XML document SHALL
be in the form specified the remainder of this Section."
This sentence appears to have been dropped in some rearrangement of the
next version:
http://lists.oasis-open.org/archives/xacml/200406/msg00008.html
http://lists.oasis-open.org/archives/xacml/200406/msg00009.html
where the first email describes the release, which was only breaking up
the previous version into the multi and hier profiles, and specifically
says that it "contains the same hierarchical resources content" as the
previous version. Point being any info conveyed in above sentence was
not intentionally dropped as indication of change of purpose.
Bottom line on URI section 2.2, is that I think it is fine except for
above typo of "://" and there might be some slight grammatical
corrections needed.
Any other prescription for URI forms or other node identity
representations that people might want, I suggest be put in another
section.
One final note is that it is interesting to follow the evolution of
what was to become the final 3.2 algorithms for ancestor selection in
these early drafts. It is pretty clear that the original hierarchies
were regarded as a forest and there was no explicit intention to
transform these into a DAG, which is the unfortunate result of the
subsequent changes that were made to these algorithms, which in
seemingly innocent identification of ancestors to be collected
apparently inadvertently created the implied condition that the
collection became transformed to a DAG.
Again, I do not recommend removing the DAG transformation and keep it
in the v5-02 section 3.2.1, however, we do need to include the option
for the forest representation, which is covered in v5-02 section 3.2.2.
Finally, the 2.2 URI section is picked up as the concrete forest
"implmentation" in section 3.2.2.1.
Thanks,
Rich
Erik Rissanen wrote:
49B6170A.50204@axiomatics.com" type="cite">Thanks
Hal for the clarifications.
For the URI based scheme which Rich is proposing, we would require that
the data type is a URI. It's an alternative form of requests/policies
for hierarchical resources, which is independent of and not used in
combination with the ancestor scheme. (Or at least that I was I think.
Rich, please correct me if I am mistaken.)
I'm not sure what to do with the actual form of the URI. Should we
mandate a subset of the URI space? Or do we leave it as something to be
agreed between the PEP and PDP/Policies?
Best regards,
Erik
Hal Lockhart wrote:
In addition to previously discussed issues, I
would like to fix the sections in the hierarchical profile on using
URIs.
In section 2.2 the profile says:
----
The identity of a node in a hierarchical resource that is not
represented as an XML document instance SHALL be represented as a URI
that conforms to [RFC2396]. Such URIs are of the following form.
<scheme> ":" <authority> "/" <pathname> ----
This is not true and it is not what RFC 2396 says. In section 3, it
says:
---
The URI syntax is dependent upon the scheme. In general, absolute
URI are written as follows:
<scheme>:<scheme-specific-part>
An absolute URI contains the name of the scheme being used
(<scheme>)
followed by a colon (":") and then a string (the
<scheme-specific-
part>) whose interpretation depends on the scheme.
The URI syntax does not require that the scheme-specific-part have
any general structure or set of semantics which is common among all
URI. However, a subset of URI do share a common syntax for
representing hierarchical relationships within the namespace. This
"generic URI" syntax consists of a sequence of four main components:
<scheme>://<authority><path>?<query>
each of which, except <scheme>, may be absent from a
particular URI.
For example, some URI schemes do not allow an <authority>
component,
and others do not use a <query> component.
----
Some URI schemes use a hierarchical path component with segments
separated by "/" and others do not. This is not mere nitpicking as the
XML Schema AnyURI type is defined as containing "a URI as defined by
RFC 2396. This means a valid type checked element of type AnyURI can
contain something like email:john@example.com or
http://www.example.com/main/index.html.
It seems to me that we should recommend as a matter of best practice
that policies first check the scheme name using the uri-starts-with
function before using any regex functions to pick the hierarchical
portion apart.
This brings us the question of what type of URI to allow or permit to
be used to represent a hierarchical resource on the non-XML type.
Obviously since we decided to allow any data type, we can no longer
require that a URI be used at all. However, I suggest we follow the
existing profile and say that if a URI is used, then if the resource
already is named using a registered scheme OF THE HIERARCHICAL TYPE,
then that should be used, otherwise a "file" scheme URI should be
constructed as described in the current (2.0) profile.
Hal
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php