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


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



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