OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xacml] Hierarchical Profile and the URI

Hi Erik and Hal,

Erik is correct. The scheme in 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:

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:

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


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,

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:


   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:


   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.


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:

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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]