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] | [Elist Home]


Subject: Re: [xacml] Non-standard functions and datatypes as MatchId functions


On 25 November, Polar Humenn writes: Re: [xacml] Non-standard functions and datatypes as MatchId functions
 > First of all of the text need not be changed. I find it troublying that
 > many things got changed here.  Furthermore, there are no change bars, so
 > I'm having difficulty seeing all that was changed in your proposed text.
 > 
 > I think the only thing that is sought after here to address this issue is
 > the relaxation of the functions that can be used for MatchId, which would
 > mean merely removing the restrictions. That can easily be done by removing
 > the following lines:
 > 
 > 3497-3503 starting with "The XACML standard functions ...."
 > 
 > And removing the last paragraphs after the last example in that section,
 > lines:
 > 
 > 3531-3542 starting with "For the match elements...".

Polar,

My guess is that you are comparing this rewording to the current
text in the 1.0 specification.  We had already agreed to change
the wording in response to Comments#5 and #12.  That wording is
attached to
http://lists.oasis-open.org/archives/xacml/200211/msg00157.html

The changes I to that already approved re-wording are only:

1. Removed "standard XACML" from following sentence:

 The MatchId attribute SHALL specify a function that compares two
                                        ^removed: standard XACML

2. Changed paragraph following the list of XACML standard
functions that may be used from:

Functions that are strictly within an extension to XACML SHALL
NOT appear as a value for the MatchId attribute.  Restricting the
MatchId attribute to XACML standard functions facilitates the use
of indexing to find the applicable policy for a particular
authorization request.

Changed to:

Functions that are strictly within an extension to XACML MAY
appear as a value for the MatchId attribute, and those functions
MAY use data types that are also extensions.  The function used
as the value for the MatchId attribute SHOULD  be easily
indexable.  Use of non-indexable or complex functions may prevent
efficient evaluation of authorization decision requests.

3. Added to the very end of the section, in response to your
comment yesterday that you did not want the example of how to
state a Match function as an equivalent Apply function to be
taken as normative:

  This expression of the semantics is NOT normative.

Do you still have objections?

Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692



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


Powered by eList eXpress LLC