Hiearchical Profile WD 7

["<Mail Display Name>" <hal.lockhart@oracle.com>]

I have posted an update to the hiearchical profile in response to comments from Rich. My specific responses to Rich are inline below.

I have not done any editorial cleanup. I will be on vacation until next Tuesday April 7. If the document seems ok and somebody wants to take on the task of doing cleanup on it, fine. If not I will do it after I return.

Hal

>Subject: Re: [xacml] Groups - Hierarchical Resource Profile WD 6 (xacml-3.0-hierarchical-v1-spec-wd-06-en.doc)uploaded
>From: "Rich.Levinson" <rich.levinson@oracle.com>
>To: hal.lockhart@oracle.com
>Date: Wed, 25 Mar 2009 23:44:47 -0400


>Hi Hal,

>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 nature:

>Section 2.2, line 221, where it says ":", I believe it should say "://".

Corrected.

>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": 

>"URI that are hierarchical in nature use the slash "/" character for separating hierarchical components."
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.
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 :) )

Most of this confusion from a typo. Changed "with" to "without" near the mention of urn: as a example of hiearchical  without slashes.

RFC 2396 says:

   '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>'

Notice it does not give this "subset" any particular name.  Generic URI sounds good until you realise the title of RFC 2396 is "URI Generic Syntax." Since RFC 2396 gives no name to this subset, I invented one. It seems clear to me that a urn: is hierachical, yet it has no slashes. Hence I chose "hierachical with slashes."

>Section 4.1, line 444: where it says "Section 3.2" it should say "Section 2.2".

Corrected

>Section 4.3, line 471: where it says "1.0:function:regexp-uri-match" it should say "2.0:function:anyURI-regexp-match".

Corrected.

>So, the rest of my comments are in section 3.3, which used to be section 3.2. 
>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 specific hierarchies.
>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 think your view is too limited in some areas. I added new text ahead of the numbered which discusses what I think is or is not assumed about hiearchies and serves as a lead in to the number steps. I changed "Discard" to "Drop from consideration". I hope this makes the intent clear to all.

Hal

>Thanks,
>Rich