From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Tuesday, March 10, 2009 9:27
AM
To: Erik Rissanen
Cc: hal.lockhart@oracle.com;
xacml@lists.oasis-open.org
Subject: Re: [xacml] Hierarchical
Profile and the URI
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:
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