[xacml] Updated Errata list

[Anne Anderson <Anne.Anderson@Sun.com>]

The attached list documents all decisions made on potential
errata submissions to xacml-comment@lists.oasis-open.org

This includes comments up through
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00076.html

Simon has agreed to maintain this list in some form from now on.

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

XACML Committee Specification 1.0 (Revision 1), 12 December 2002
Title: Errata List
Version: 1.2, 03/01/09 (yymmdd)

Errata are in order according to location in the document.  Each
erratum has a STATUS indicating whether it has been approved by
the XACML TC.

This includes submissions to xacml-comment@lists.oasis-open.org
up through
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00076.html
==========================================================================
2.1 Requirements, pdf:357-358

When I read the line #[357-358], I got the impression that this
is about creating policy sets, but this is about combining rules
and policies to evaluate authZ decision. I think changing the
term "action" to "access request" makes it clear. At the same
time, the objective of combining rules and policies is to
evaluate the consolidated authorization decision and not to
create a policy set(?). I would say statement like "To provide a
method for combining individual rules and policies to evaluate
authZ decision that applies to a given access request" is more
clear. Lines #[403-405 2.3 Combining algorithms] indicate the
same.

Submitted by: "Chopra, Dipak" <dipak.chopra@sap.com>
Date: 11 Dec 2002
STATUS: Not erratum.  Leave as is.  The word "action" has already
been changed to "decision request", and that is bolded to
indicate it is defined in the glossary.
===================================================================
A.2 Primitive types

Add something to mention the extensibility of the data type
system.

Submitted by: Daniel Engovatov <dengovatov@crosslogix.com>
Date: 11 Dec 2002
STATUS: Daniel requested to propose additional text.
-------------------------------------------------------------
ALTERNATIVE: Already described in "8.1 Extensible XML attribute
types"

Submitted by: Anne Anderson <Anne.Anderson@Sun.com>
Date: 13 Dec 2002
STATUS: If Daniel does not propose additional text for A.2, then
leave doc as is.
===================================================================
A.3 Structured types, pdf:3408

In the first item of Appendix A.3,
1) Replace "xsi:string" by the correct URI.
2) Replace "XMLSchema-Instance#string" by "XMLSchema#string"

Submitted by: Satoshi Hada <SATOSHIH@jp.ibm.com>
Date: 11 Dec 2002
STATUS: Approved as errata items.
=========================================================================
A.6 Expressions, pdf:3458-3461

Section A.6 states that all expressions listed below evaluate to either a
primitive type, or a bag of primitive types.

This needs to be enhanced because of the <Function> argument, and also it
states nothing of extension types.

I suggest the following wording:

Change the first paragraph to:

XACML specifies expressions in terms of the following elements of which
the <Apply> and <Condition> elements recursively compose greater
expressions.  Valid expressions shall be type correct, which means that
the types of each of the elements contained within <Apply> and <Condition>
elements shall agree with the respective argument types of the function
that is named by the FunctionId attribute.  The resultant type of the
<Apply> or <Condition> element shall be the resultant type of the
function, which may be narrowed to a primitive data type or a bag of a
primitive data type by type unification. XACML defines an evaluation
result of "Indeterminate", which is said to be the result of an invalid
expression, or an operational error occurring during the evaluation of the
expression.

Submitted by: Polar Humenn <polar@syr.edu>
Date: 11 Dec 2002
STATUS: Polar requested to supply clarification of "type
unification", which is not defined anywhere in the spec.
=========================================================================

Submitted by: 
Date: 
STATUS: Not yet discussed.
=========================================================================