I have had a chance to do a preliminary analysis of the revision you
are proposing and have a few comments.
First, I think there are a couple of typos left over from the version 3
that we should correct, which I believe should be non-controversial in
So, the rest of my comments are in section 3.3, which used to be
- Section 2.2, line 221, where it says ":", I believe it should say
- I have looked over RFC 2396, section 3, and I believe that in
section 3, when they say the following that it means that we do not
have to say "hierarchical with slashes":
also RFC 1738 defines the file: scheme as
"file://<host>/<path>", which fits the overall original 2.2
structure of "<scheme>://<authority>/<path>" (where I
have included the "//" indicated in 1 above.
- "URI that are hierarchical in nature use the slash "/"
character for separating hierarchical components."
i.e. I do not understand your distinction on line 219-220 of
"hierarchical with slashes" vs. "hierarchical using slashes", of which
you put http in the latter category, then seem to exclude http by
saying only the schemes characterized by "with slashes". i.e. is the
point of this to exclude http because that's how I read it, and if so,
why? (ok, maybe this one might be controversial depending on the answer
- Section 4.1, line 444: where it says "Section 3.2" it should say
- Section 4.3, line 471: where it says
"1.0:function:regexp-uri-match" it should say
I think I see a possible path toward closure there, so rather than
dealing with details, let me take a higher level perspective.
The "general process" on lines 374-380 may be able to pin things down,
but I have some questions about the way it is currently phrased:
- I am not sure what "collect all the hierarchies" in step 1 means
nor "discard any hierarchies" in step 2. I understand the intent, but a
"hierarchy" is a collection of nodes, and we are dealing with one node
to start, the requested node, which can belong to some hierarchies and
not to others. I think we need a notion of the "identifier" associated
with a specific hierarchy, and the requested node will have a set of
identifiers which are effectively membership identifiers within
- With the notion of identifiers associated with hierarchies, the
requested node has a list of identifiers associated with (has a one to
one relation with) a list of hierarchies.
- Now, every node in the process will have its own list of
identifiers/hierarchies of which it is a member.
- So, if based on the above notion, we could then say that what we
mean by "discard any hierarchies of which the node in question is not
actually a member", is that when ancestor nodes are processed that
"only the identifiers of which the requested node is a member will be
used" then I think things will be pinned down a little more clearly.
- Finally, I think the terminology of the "general process" has to
be carried directly into the 4 bullets so that there is no ambiguity
between the "general process" and the "bullets".
I forgot to update the table of contents in the previous version
-- Hal Lockhart
The document revision named Hierarchical Resource Profile WD 6
(xacml-3.0-hierarchical-v1-spec-wd-06-en.doc) has been submitted by Hal
Lockhart to the OASIS eXtensible Access Control Markup Language (XACML) TC
document repository. This document is revision #1 of
View Document Details:
This document is revision #1 of
xacml-3.0-hierarchical-v1-spec-wd-06-en.doc. The document details page
referenced above will show the complete revision history.
PLEASE NOTE: If the above links do not work for you, your email application
may be breaking the link into two pieces. You may be able to copy and paste
the entire link address into the address field of your web browser.
-OASIS Open Administration