The attached document contains the resolutions to every comment on the XACML 1.0 Specification or schemas that was submitted to the
xacml-comment@lists.oasis-open.org mailing list during the public review period from November 8, 2002 through December 8, 2002. At the XACML Comments Subcommittee meeting on 12/10/02, changes were made to the previous resolution to Comment#52b (Seth Proctor). Comment#71 (Anne Anderson), 72 (John Merrells), and 73 (Dipak Chopra) were resolved. These resolutions are reflected in this document. Attendees at the 12/10/02 Comments Subcommittee meeting were: Carlisle Adams, Tim Moses, Anne Anderson, Polar Humenn, and Michiharu Kudo Anne Anderson -- 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 Title: Comments on XACML 1.0 Committee Specification Maintainer: Anne Anderson Version: 1.33, 02/12/10 (yy/mm/dd) Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.Comments.txt This file contains a link to every comment received on the
xacml-comment@lists.oasis-open.org mailing list reporting any kind of problem with the specification or schemas since the public review was announced on November 8, 2002. Each comment is broken down into specific sub-comments, and the response to each is described, along with any actions to be taken by the TC. This version of the file contains e-mail up through
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00057.html and
http://lists.oasis-open.org/archives/xacml/200212/msg00075.html CATEGORIES ---------- Editorial: Formatting error or formatting inconsistency. Inconsistent: Specification says one thing in one place and another thing in another place. Incomplete: Specification omits information required for full specification of a feature. Incorrect: Specification describes functionality that will not work due to external or internal constraints. Unclear: Description of feature is not clear or is ambiguous. Undesirable: Feature is not desirable. Alternative: Proposed alternative to a feature ====================================================================== COMMENTS ====================================================================== 0001.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00003.html Subject: An editorial comment on the XACML 1.0 document From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Sat, 09 Nov 2002 02:16:43 +0900 Appendix B.1 says that two namespaces are defined, but there are three URIs there. The URI for XACML datatypes should be removed? CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove B.1 lines 4332-4333 describing the urn:oasis:names:tc:xacml:1.0:data-type identifier from the specification. ============================================================================= 0002.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00004.html Subject: xs:time From: Seth Proctor <
seth.proctor@sun.com> Date: Fri, 08 Nov 2002 12:33:59 -0500 Sections A.2 (Primitive types) and B.4 (Data types) include date and dateTime, but not time. The time type is used by many functions and at least one standard attribute, and should be on those list. CATEGORY: Inconsistent. SEE ALSO: #4 STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add
http://www.w3.org/2001/XMLSchema#time to Sections 10.3.7, A.2, and B.4. ====================================================================== 0003.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00005.html Subject: resubmission: v_1.0 - niggling editorial nuggets From: bill parducci <
bill.parducci@overxeer.com> Date: Fri, 08 Nov 2002 10:01:51 -0800 --------------------------------------------------------------------------- 0003a. line 520: '...element from each of the policies or policy' the word 'policy' is *half* bold. CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Line 520, make word 'policy' all bold. --------------------------------------------------------------------------- 0003b. line 793: '[c01] <?xml version="1.0" encoding="UTF-8"?>' inconsistent font (times) actually, upon further inspection, the document seems to use proportionally spaced, sans serif fonts (e.g. 'arial') in the listings and example code starting at line 641 and continuing to line 826, at which point it uses the correct font, non proportional serif font (courier). CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: On lines 641-826, use non-proportional serif fonts. --------------------------------------------------------------------------- 0003c. line 1039: starting with line 1039 the examples are color encoded. the snippets prior to this are not. given the darkened background i think that the color makes it harder to read (and print), but either way i think that it should be consistent (sections 5 & 6 go back and forth twixt the two). this continues thorough [portions] of the primer. CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove all color-encoding from XML fragments in the document. --------------------------------------------------------------------------- 0003d. line 3278: 'xacml:Policy:PolicySet' there seems to be an extraneous border line above the row in the table CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove border line above xacml:Policy:PolicySet in the table following line 3278. --------------------------------------------------------------------------- 0003e. line 3291: 'Urn:oasis:names:tc:xacml:1.0:environment' there seems to be extraneous border lines above each of the rows in this table CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove border lines between urns in table following line 3291. --------------------------------------------------------------------------- 0003f. line 3385: '<AttributeValue' snippet font (should be 'courier') CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use courier font in schema fragment following line 3385. --------------------------------------------------------------------------- 0003g. line 3399: '[IBMDSA]' i thought that the IBMDSA reference was replaced with an IEEE spec throughout the doc, or was this only in a specific instance? CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: In A.4, lines 3398-3399, change reference from "IBM Standard Decimal Arithmetic [IBMDSA]" to "IEEE Standard for Binary Floating-Point Arithmetic [IEEE754]". --------------------------------------------------------------------------- 0003h. line 4277: 'first argument of
Anderson@sun.com?' question mark should be quotation mark CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: On line 4277, change '
Anderson@sun.com?' to '
Anderson@sun.com"' --------------------------------------------------------------------------- 0003i. line 4434: ' urn:oasis:names:tc:xacml:1.0:resource:scope' leading spaces or indentation (should be left margin aligned) CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: On line 4434, align "urn:oasis:names:tc:xacml:1.0:resource:scope" with the left margin. --------------------------------------------------------------------------- 0003j. finally, there seems to be some squooshing going on with lines 2618, 2742, 2778 in the pdf. can others confirm? CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: "squooshing" confirmed. ACTIONS: Unsquoosh lines 2618, 2742, 2778 in PDF version of next specification release. ====================================================================== 0004.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00006.html Subject: followup to xs:time comment From: Seth Proctor <
seth.proctor@sun.com> Date: Fri, 08 Nov 2002 14:51:42 -0500 all of the functions defined as type-* (like the type-one-and-only function) need to have a time-* version added in 10.3.8 (and maybe elsewhere, though I don't think so) CATEGORY: Inconsistent. SEE ALSO: #2 STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add function:time-one-and-only, function:time-bag-size, function:time-is-in, function:time-bag functions as mandatory-to-implement in the table in Section 10.3.8 "Functions". ====================================================================== 0005.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00007.html Subject: Inconsistent specification of <*Match> elements and-match functions From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Mon, 11 Nov 2002 14:28:14 -0500 (EST) Problem: MatchId functions used in a target take one AttributeDesignator or AttributeSelector argument, and one literal AttributeValue argument. The order of the two arguments is specified differently in different parts of the specification. Also, the *-match functions can only be used in a Target if the order of their arguments (template, specific value) agree with the order of arguments in a MatchId function (the AttributeDesignator or AttributeSelector, and the literal value). Recommendation: Option 1: Specify that the first argument to each *-match function is the specific value to be compared to the template, and the second argument is the template. To be consistent, rename "regexp-string-match" to "string-regexp-match". This requires the least change to the specification. Option 2: Specify that the first argument to a MatchId function is a literal AttributeValue and the second argument is the AttributeDesignator or AttributeSelector. Text locations where references occur: 1 must change if Option 1 selected 2 must change if Option 2 selected 2 - Every occurrence of <SubjectMatch, <ResourceMatch, or <ActionMatch except as called out below: Change order of AttributeSelector or AttributeDesignator argument and AttributeValue argument 2 - Section A.12 lines 3491-3493: reword as follows: "Each argument to the named function MUST match the appropriate primitive types for the explict attribute value and the following <AttributeDesignator> or <AttributeSelector> element, ... 1 - Section A.12, lines 3493-3496: reword as follows: "... such that an element of the bag returned by the <AttributeDesignator> or <AttributeSelector> element is placed as the first argument to the function, and the explicit attribute value is placed as the second argument to the function." 1 - Section A.14.12, lines 4250-4281: reverse order of arguments in the specifications for the -match functions, such that the first argument is the full value to be compared to the template or dominating value, and the second argument is the template or dominating (higher in the tree of values) value. 2 - Section A.14.13, lines 4306-4313: the specification of the xpath-node-match function probably needs to change to be consistent with the above if xpath-node-match is to be allowed in a Target expression. Note that several examples use xpath-node-match as MatchId functions, and line 3503 implies that this is permissable, but lines 3535-3540 indicate that xpath-node-match is NOT permissable in a MatchId function. CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. SEE ALSO: #51,#57 RESPONSE: See #57. This was initially rejected, but #57 resolves the issue in this comment by changing the order of the elements in the Target to be (AttributeValue, AttributeDesignator/Selector). ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. ====================================================================== 0006.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00008.html Subject: present function From: Seth Proctor <
seth.proctor@sun.com> Date: Tue, 12 Nov 2002 11:00:52 -0500 Section A14.5 still lists a present function. I think the decision was to remove this functionality entirely for the time being. CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove lines 3730-3738, describing the "present" function, from the specification. ====================================================================== 0007.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00009.html Subject: a few typos From: Seth Proctor <
seth.proctor@sun.com> Date: Tue, 12 Nov 2002 11:08:13 -0500 --------------------------------------------------------------------------- 0007a. 10.3.7: dayTime and yearMonth durations should read "xquery-operators" not "xquey-operaqtors" CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: In Section 10.3.7, change two instances of "xquey-operaqtors" to "xquery-operators". --------------------------------------------------------------------------- 0007b. 10.3.8: function:rfc822Name-equal is listed as rfc822name-equal (lower case 'n' in 'name') CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: In Section 10.3.8, change "function:rfc822name-equal" to "function:rfc822Name-equal" ====================================================================== 0008.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00010.html Subject: ...IsPresent and Qualified... From: John Merrells <
merrells@jiffysoftware.com> Date: Tue, 12 Nov 2002 16:40:59 -0800 --------------------------------------------------------------------------- 0008a. In draft 18f section 5.30, 5.31, and 5.32 documents the AttributeIsPresent elements, but the 18f schema doesn't contain these. CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. RESPONSE: Rejected. The *AttributeIsPresent" elements were removed from the specification in XACML 1.0, which is the version being reviewed. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. --------------------------------------------------------------------------- 0008b. Also, the 18f schema contains the QualifiedSubjectAttributeDesignator element, but this isn't described in the 18f draft, it first appears in the conformance tables 10.3.1 CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. RESPONSE: Rejected. The "QualifiedSubjectAttributeDesignator" element is named "SubjectAttributeDesignator" in the XACML 1.0 version of the specification, which is the version being reviewed. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. ====================================================================== 0009.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00010.html Subject: Urn versus urn From: Seth Proctor <
seth.proctor@sun.com> Date: Tue, 12 Nov 2002 11:03:53 -0500 in a number of sections in 10.3 (10.3.2, 10.3.4, 10.3.5, 10.3.6, 10.3.7) the 'u' in 'urn' has become a 'U' CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change "Urn:" to "urn:" in Sections 10.3.2, 10.3.4, 10.3.5, 10.3.6, and 10.3.7 (two types at the end of the table). ====================================================================== 0010.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00012.html Subject: missing functions in 10.3.8 From: Seth Proctor <
seth.proctor@sun.com> Date: Wed, 13 Nov 2002 17:52:46 -0500 Section 10.3.8 is missing the regexp-string-match function as well as all of the Set functions CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: To Section 10.3.8, as mandatory-to-implement, add the following functions: function:regexp-string-match <type>-intersection <type>-at-least-one-member-of <type>-union <type>-subset <type>-set-equals where <type> is "string", "boolean", "integer", "double", "date", "time", "dateTime", "anyURI", "hexBinary", "base64Binary", "dayTimeDuration", "yearMonthDuration", "x500Name", and "rfc822Name". ====================================================================== 0011a.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00013.html Subject: The namespace URI for XACML data types From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Thu, 14 Nov 2002 14:11:15 +0900 Section 1.3 mentions a namespace URI for XACML data types. It should be removed. CATEGORY: Editorial. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: In Section 1.3 "Schema organization and namespaces", remove lines 320-321 that describe the urn:oasis:names:tc:xacml:1.0:data-type namespace. ====================================================================== 0011b.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00014.html Subject: The footnote 1 in Appendix A.4 From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Thu, 14 Nov 2002 14:17:39 +0900 There is a footnote in Appendix A.4. An earlier RFC, RFC 1779 "A String Representation of Distinguished Names", is less restrictive, so xacml:x500Name uses the syntax in RFC 2253 for better interoperability xacml:x500Name should be replaced with the correct identifier. CATEGORY: Inconsistent. STATUS: Resolved 11/14/02. RESPONSE: Approved. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: In footnote "1" under Section A.1, change "xacml:x500Name" to "urn:oasis:names:tc:xacml:1.0:data-type:x500Name". ====================================================================== 0012.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00015.htm Subject: Section A12 From: John Merrells <
merrells@jiffysoftware.com> Date: Thu, 14 Nov 2002 01:03:04 -0800 I'm finding section A12 difficult to understand. I think the information could be more clearly presented. 1) It introduces the Target element and its immediate child elements, and then the standard functions that can be used for a MatchID. But then a couple of paragraphs later it says that the only functions that can appear in a MatchID of a Target child are a different bunch of functions. This is confusing. 2) <i>type</i>-match appears as a standard function. (And does not appear in the conformance tables.) The subsequent paragraph starts "The evaluation semantics for a match is as follows...' But is this referring to the standard match functions as a whole, or just the behaviour of the <i>type</i>-match function itself. If not then where's the definition of <i>type</i>-match ? 3) The text and the examples refer to the special match functions before they've actually been defined. I think a reorg of section A12 would improve the legibility quite a bit. And followup in
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00016.html: > 2) <i>type</i>-match appears as a standard function. (And does not appear > in the conformance tables.) The subsequent paragraph starts "The > evaluation > semantics for a match is as follows...' But is this referring to the > standard > match functions as a whole, or just the behaviour of the > <i>type</i>-match > function itself. If not then where's the definition of > <i>type</i>-match ? I think I've worked out that the <i>type</i> place holder in the list of the standard match functions is not meant to stand in for all the types recognized by xacml, but is meant as a kind of wildcard to refer to the functions actually specified. So <i>type</i>-match doesn't mean integer-match, double-match, etc, but actually just rfc822Name-match and x500Name-match.I think other readers might be confused by this too. CATEGORY: Unclear. STATUS: Resolved 11/21/02. Changed 12/02/02. SEE ALSO: #48,#57 RESPONSE: Approved. We agreed that this section is unclear and needs to be re-worded. On 12/02/02, we decided to change the argument order to make MatchId functions consistent with FunctionId functions after further comments came in from reviewers. See #57 ACTIONS IMPLEMENTED IN: draft sent Tue. 3 Dec 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200212/msg00007.html ACTIONS: Replace Appendix A.12 "Matching elements" with the revised text attached to e-mail message
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00000.html ========================================================================= 0013.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00032.html Subject: The PolicySet Schema (Line 1759--1762) From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Mon, 18 Nov 2002 15:02:24 +0900 A minor comment on Line 1759--1762. I found the type of two attributes (PolicySetId and PolicyCombiningAlgId) specified by a long URI
http://www.w3.org/2001/XMLSchema#anyURI I'm not sure this is wrong, but I can say it's strange in the sense that the qname xs:anyURI is used in other schema descriptions (e.g., Line 1819, 1889). I think it's better to replace the long URI with the (short) qname. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. Change to use qnames, since this is a fragment from the schema, not from an instance. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change document lines 1759 and 1762 such that xs: is used instead of "
http://www.w3.org/2001/XMLSchema#" ;. ========================================================================= 0014.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00033.html Subject: No description about the PolicyDefaults element From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Mon, 18 Nov 2002 15:48:16 +0900 The <PolicySetDefaults> element is described in Section 5.3, but I could find no section describing the <PolicyDefaults> element. As a result, no syntax is defined for it in the specification document. Is this okay? CATEGORY: Incomplete. STATUS: Resolved 11/21/02. RESPONSE: Approved adding PolicyDefaults description. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add PolicyDefaults section as new 5.21 as follows: 5.21 Element <PolicyDefaults> The <PolicyDefaults> element SHALL specify default values that apply to the <Policy> element. <xs:element name="PolicyDefaults" type="xacml:DefaultsType"/> <xs:complexType name="DefaultsType"> <xs:sequence> <xs:choice> <xs:element ref="xacml:XPathVersion" minOccurs="0"/> </xs:choice> </xs:sequence> </xs:complexType> <PolicyDefaults> element is of DefaultsType complex type. <XPathVersion> [Optional] Default XPath version. ========================================================================= 0015.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00034.html Subject: conformance tests (NotApplicatble or Not-Applicabale) From: John Merrells <
merrells@jiffysoftware.com> Date: Sun, 17 Nov 2002 23:32:46 -0800 The spec says 'Not-Applicable', but the tests (eg. IIB003Response.xml) say 'NotApplicable'. CATEGORY: Inconsistent. SEE ALSO: #16 STATUS: Resolved 11/21/02. RESPONSE: Approved changing specification text to "NotApplicable". ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change specification text throughout to use "NotApplicable" rather than "Not-Applicable". ========================================================================= 0016.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00035.html Subject: NotApplicable From: Seth Proctor <
seth.proctor@sun.com> Date: Mon, 18 Nov 2002 10:07:50 -0500 The schema uses "NotApplicable" in a Decision, but the spec says that it's "Not-applicable" ... I'm pretty sure the schema is correct here, right? CATEGORY: Inconsistent. SEE ALSO: #15 STATUS: Resolved 11/21/02. RESPONSE: Approved changing specification text to "NotApplicable". ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change specification text throughout to use "NotApplicable" rather than "Not-Applicable". ========================================================================= 0017.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00036.html Subject: Another A.12 comment From: Seth Proctor <
seth.proctor@sun.com> Date: Mon, 18 Nov 2002 10:09:47 -0500 Section A.12 (which I know Anne is re-working) makes several mentions of the EnvironmentMatch type ... there is no such type, so this should probably be removed from A.12 CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Remove EnvironmentMatch type. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Replace Section A.12 with the text supplied in e-mail message
http://lists.oasis-open.org/archives/xacml/200211/msg00157.html . Revised again in response to #48 and #57; attached to e-mail message
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00000.html ========================================================================= 0018.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00039.html Subject: xacml:Policy:XpathVersion mandatory-to-implement? From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 11:45:24 -0500 (EST) In Section 10.3.1, "xacml:Policy:XpathVersion" is listed as mandatory-to-implement. ------------------------------------------------------------------------ 0018a. This should be spelled "XPathVersion" CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. Spelling should be "XPathVersion". ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change 10.3.1 to use "XPathVersion" spelling. ------------------------------------------------------------------------ 0018b. This should not be mandatory-to-implement, since support for XPath functionality and the containing PolicyDefaults are not mandatory-to-implement. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. XPathVersion is not mandatory-to-implement. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change 10.3.1 M/O column for "xacml:Policy:XPathVersion" to "O". ------------------------------------------------------------------------ 0018c. 10.3.1 should contain "xacml:Policy:PolicyDefaults", and it should be marked not mandatory-to-implement CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved. Add an entry for PolicyDefaults marked not mandatory-to-implement. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add to 10.3.1 an entry for "xacml:Policy:PolicyDefaults", marked "O" (optional). ========================================================================= 0019.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00040.html Subject: Incomplete: behavior if <Obligations> present but notsupported From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 13:25:13 -0500 (EST) The behavior of a PDP that does not support the optional <Obligations> element when presented with a Policy containing <Obligations> is not specified. Possible behavior: if a Policy or PolicySet is Applicable to a Request and the Policy or PolicySet contains <Obligations>, but the PDP does not support <Obligations>, that the PDP MUST return "Deny". CATEGORY: Incomplete. SEE ALSO: #20 STATUS: Resolved 11/21/02. RESPONSE: Approved specifying behavior. Behavior SHALL be to return "Indeterminate". ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add new Section 7.12 "Unsupported functionality" as follows: 7.12 Unsupported functionality If the PDP attempts to evaluate a PolicySet or Policy that contains an element type or feature that the PDP does not support, then the PDP SHALL return a response of "Indeterminate". If a StatusCode is also returned, the PDP SHALL return a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error" for an unsupported element type error , and "urn:oasis:names:tc:xacml:1.0:status:processing-error" for an unsupported feature error. ========================================================================= 0020.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00041.html Subject: INCOMPLETE: behavior when XPath encountered,but not supported From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 13:37:35 -0500 (EST) The behavior of a PDP that does not support the optional XPath *Defaults, selectors, functions, etc. when presented with a policy containing such elements is not specified. In some cases, the XPath elements may appear in a <Target> element, making it impossible to determine whether or not a PolicySet, Policy, or Rule is applicable. In other cases, the <Target> element may not require any XPath functionality, and a PolicySet, Policy, or Rule may be applicable, but evaluating the <Condition> in the Rule may require XPath functionality. Possible behavior: If, during evaluation of a Request, any unsupported element is encountered, then the PDP MUST return a result of Indeterminate. CATEGORY: Incomplete. SEE ALSO: #19 STATUS: Resolved 11/21/02. RESPONSE: Approved specifying behavior. Behavior SHALL be to return "Indeterminate". ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add new Section 7.12 "Unsupported functionality" as follows: 7.12 Unsupported functionality If the PDP attempts to evaluate a PolicySet or Policy that contains an element type or feature that the PDP does not support, then the PDP SHALL return a response of "Indeterminate". If a StatusCode is also returned, the PDP SHALL return a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error" for an unsupported element type error , and "urn:oasis:names:tc:xacml:1.0:status:processing-error" for an unsupported feature error. ========================================================================= 0021.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00042.html Subject: C.3 First-Applicable policy-combining alg inconsistent From: Anne Anderson <
Anne.Anderson@Sun.com> Date: Mon, 18 Nov 2002 16:29:27 -0500 (EST) In the description of the policy-combining algorithm for FirstApplicable, lines 4752-4754 say: if error occurs while evaluating a policy, then evaluation shall continue looking for an applicable policy, returning Indeterminate only if no applicable policy found. But lines 4755-4758 say: if error occurs while evaluation a policy, then evaluation shall halt and policy set shall evaluate to "Indeterminate". Lines 4752-4754 should be deleted. That would be consistent with the pseudo-code and with the "safety" of not allowing any "Permit" if there is an Indeterminate that should have returned a Deny. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved deleting pdf:4752-4754. This removes the first, incorrect description of how the PDP behaves in the face of an error and retains the second, correct description. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Delete lines pdf:4752-4754 ========================================================================= 0022.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00044.html Subject: Section 5.24 From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 14:31:14 +0900 There is no description about the child element <xacml:SubjectAttributeDesignator> in Section 5.24. Some description should be added between Lines 2162 and 2163. CATEGORY: Incomplete. SEE ALSO: #44 STATUS: Resolved 11/21/02. RESPONSE: Approved adding a description of SubjectAttributeDesignator. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add the following before line pdf:2168: <SubjectAttributeDesignator> [Optional] A subject attribute argument. ========================================================================= 0023.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00045.html Subject: Line 308: The SAML prefix From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 14:41:02 +0900 In Line 308, the SAML prefix (saml:) is mentioned, but it never appears anywhere in the document. The line should be removed. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved removing line pdf:308 ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Remove line pdf:308 ========================================================================= 0024.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00046.html Subject: Comments on the prefix xf From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 14:56:39 +0900 In Line 1295, the QName xf:yearMonthDuration should be replaced by the correct URI. In Line 1345, the QName xf:yearMonthDuration should be replaced by the correct URI. Appendix A14.7: In Lines 3759, 3766, 3773, 3782, 3790, 3796, the QName xf:yearMonthDuration should be replaced by the correct URI. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved using full uri. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: In lines 1295 and 1345, use "
http://www.w3.org/TR/xquery-operators#yearMonthDuration" ; instead of "xf:yearMonthDuration" ========================================================================= 0025.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00047.html Subject: Line numbering is inconsistent From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 15:08:56 +0900 Line numbering is inconsistent between the PDF file and the Word file. I have downloaded them from:
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.doc http://www.oasis-open.org/committees/xacml/repository/cs-xacml-core-01.pdf An example: In the PDF file Line 43 is a blank line. In the Word file Line 43 is about the copyright. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Commenters should specify which version is being used. Accept comments from either version. In the future, Bill Parducci will generate both versions before we post either so that we can verify that numbers match. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None for now. ========================================================================= 0026.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00048.html Subject:The type of the RequestContextPath attribute From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 15:34:25 +0900 The current type of the RequestContextPath attribute is xs:anyURI. (Section 5.31) I don't think that a valid XPath expression is always a valid URI (according to RFC2396). So I think the type should be xs:string rather than xs:anyURI. Please correct me if I'm wrong. In the XML-Signature specification, the type of XPath expressions is xs:string. Follow-on:
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00068.html Date: Thu, 21 Nov 2002 15:36:40 +0900 For example, /xml[2] is not a valid URI. CATEGORY: Incorrect. STATUS: Resolved 11/21/02. RESPONSE: Approved changing DataType in line 2421 to xs:string. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Change line 2421 DataType from xs:anyURI to xs:string. ========================================================================= 0027.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00049.html Subject: Function Identifiers in Section 10.3.8 From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Tue, 19 Nov 2002 21:11:44 +0900 Section 10.3.8 uses QName as function identifiers. Don't use the namespace prefix "function" and replace all the qnames with the corresponding URIs. Remove line 3302 (xmlns:function="urn:oasis:names:tc:xacml:1.0:function"). CATEGORY: Inconsistent. SEE ALSO: #29,#30 STATUS: Resolved 11/21/02. RESPONSE: Approved. Use full urn; remove xmlns:function line. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:" throughout the specification rather than just "function:". Remove line 3302 that describes the xmlns:function. ========================================================================= 0028.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00050.html Subject: equality & set/bag functions From: Seth Proctor <
seth.proctor@sun.com> Date: Tue, 19 Nov 2002 17:34:32 -0500 The set and bag functions (along with others), are defined as type-[name] where this is expanded to include one function for each standard type. Presumably this includes the two duration attribute types. One of the bag functions and several of the set functions also specify that their definitions are based on using the type-equal function for the coresponding type. The equality functions, however, are defined individually for each type, and no equal functions are defined for the two duration types. So, the question: should there be equality functions defined for the two duration types, or should certain type-[name] functions not be able to handle the two duration types? It seems like one of those two must change to make this work. CATEGORY: Incomplete. STATUS: Resolved 11/21/02. RESPONSE: Approved. Add dayTimeDuration-equal and yearMonthDuration-equal functions. Use XQuery semantics. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add following text at end of Section A.14.1, following line pdf:3639: o dayTimeDuration-equal This function SHALL take two arguments of type "
http://www.w3.org/TR/xquery-operators#dayTimeDuration" ; and SHALL return an "
http://www.w3.org/2001/XMLSchema#boolean" ;. This function shall perform its evaluation according to the "op:dayTimeDuration-equal" function [XQO Section 8.3.5]. Note that the lexical representation of each argument is converted to a value expressed in fractional seconds [XQO Section 8.2.2]. o yearMonthDuration-equal This function SHALL take two arguments of type "
http://www.w3.org/TR/xquery-operators#yearMonthDuration" ; and SHALL return an "
http://www.w3.org/2001/XMLSchema#boolean" ;. This function shall perform its evaluation according to the "op:yearMonthDuration-equal" function [XQO Section 8.3.2]. Note that the lexical representation of each argument is converted to a value expressed in integer months [XQO Section 8.2.1]. ========================================================================= 0029.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00053.html Subject: The prefix "function:" is used in Section 4 Examples From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Wed, 20 Nov 2002 12:34:21 +0900 The namespace prefix "function:" is used in the explanation for the examples in Section 4. There are too many places where it is used and so I cannot list all here. All should be replaced with the correct URIs. E.g., function:string-equal Function:string-equal (Capital F is used) function:and function:string-one-and-only function:date-less-or-equal function:date-one-and-only CATEGORY: Inconsistent. SEE ALSO: #27,30 STATUS: Resolved 11/21/02. RESPONSE: Approved using full urn. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:" throughout the specification rather than just "function:". ========================================================================= 0030.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00054.html Subject: The prefix "function:" is used in Appendix A From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Wed, 20 Nov 2002 12:39:38 +0900 The namespace prefix "function:" is used in Appendix A. There are too many places where it is used and so I cannot list all here. All should be replaced with the correct URIs. CATEGORY: Inconsistent. SEE ALSO: #27,29 STATUS: Resolved 11/21/02. RESPONSE: Approved using full urn. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use full "urn:oasis:names:tc:xacml:1.0:function:" throughout the specification rather than just "function:". ========================================================================= 0031.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00055.html Subject: The default value of the MustBePresent attribute(Section 5.26) From: Satoshi Hada <
SATOSHIH@jp.ibm.com> Date: Wed, 20 Nov 2002 16:08:50 +0900 The default value "false" of the MustBePresent attribute is NOT specified in the schema in Section 5.26. It should be added. CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: Approved adding default="false". This is correct in the schema. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Add default="false" to line pdf:2203 ========================================================================= 0032.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00058.html Subject: Problems understanding XACML spec From: Graham Klyne <
GK@NineByNine.org> Date: Wed, 20 Nov 2002 13:40:25 +0000 I'm having a really hard time understanding what you're trying to say in the XACML spec:
http://www.oasis-open.org/committees/xacml/repository/draft-xacml-schema-policy-18d.doc ACTIONS: Anne Anderson sent Graham Klyne a message explaining that the public review is being held with respect to XACML 1.0, and not draft 18d.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00060.html Comments may still apply, since they are fairly general, so I have listed them below. ------------------------------------------------------------------------ 0032a. The description of a rule seems to be inadequately motivated. The description in section 2 (background) says "The <Rule> element contains a boolean expression that can be evaluated in isolation..." which doesn't do anything to prepare me for the description I find in section 3.3.1. I'm finding it particularly hard to see (a) what this Boolean expression is evaluated over (it seems to have something to do with the rule target), and (b) how the Boolean result relates to the evaluation of the rule. I can see that a Boolean true results in Permit or Deny depending on the value of the rule's effect field, but what happens if the Boolean value is false? As far as I can tell, understanding this is crucial to understanding all the other stuff about combining rules and policies. CATEGORY: Unclear. STATUS: Resolved 12/05/02. RESPONSE: Needs to be clarified. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use text that is in the draft attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ------------------------------------------------------------------------ 0032b. Under what circumstances is a rule found to be "NotApplicable"? CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: We believe this is specified clearly in Section 7.5 of XACML 1.0. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: No change. ------------------------------------------------------------------------ 0032c. I also find the reference to the fact that a rule may "inherit" target information from a policy is particularly obscure. It seems to me that the idea of a rule is fundamental to understanding this specification, but that vital idea is not adequately explained. It may be that the information is present somewhere in this document, but it is a big and complicated document and I can't tell what's important. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: This needs to be clarified. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Lines 631-632. Change wording to say "Rule uses the <Target> of its parent Policy element." ------------------------------------------------------------------------ 0032d. I think more attention needs to be paid to the order in which concepts are introduced. I would expect section 2 to deal with this, but it seems some important ideas are not being adequately explained. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: Please submit any specific important ideas that are not being adequately explained or are in the wrong order in Section 2 in the XACML 1.0 specification. Note that Section 2 only covers key concepts, with full detail in later sections. ACTIONS: None. ------------------------------------------------------------------------ 0032e - missing comment# in sequence ------------------------------------------------------------------------ 0032f. I also think there's an over-dependence in the text on abbreviations that are introduced in the glossary. There are many special terms, and ordinary words used with special meaning, and it's not reasonable to assume that someone not familiar with them to absorb them on one pass through the glossary. CATEGORY: Unclear. STATUS: Resolved 11/21/02. RESPONSE: We believe this has been improved in XACML 1.0: terms from the glossary are bolded in XACML 1.0 to indicate they have special meaning. This is a specialist area, and we expect people to refer to the glossary until they are acquainted with the terms. Please submit any specific places that are not clear in the 1.0 version. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. ========================================================================= 0033.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00061.html Subject: map function From: Seth Proctor <
seth.proctor@sun.com> Date: Wed, 20 Nov 2002 16:22:32 -0500 I'm a little concerned with the definition of the map function. Every other function and attribute in the spec has a well defined type associated with it, but the map function does not. Even things like the bag functions are defined as type-* so that each of the bag functions returns a well defined type (ie, there is a uniquely named function for each bag function that returns each attribute type). The map function, however, is simply defined as returning a bag of some type. For consistency, and to make sure that the strong typing present in the rest of the spec exists here too, I would suggest that the map function be redefined as type-map, such that there is a named map function for each type in the spec. I think the functionality being provided by map makes sense, I just think it should be clear what types of bags the map function returns. CATEGORY: Alternative. STATUS: Resolved 12/02/02. RESPONSE: Keep "map" function as is. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: None. DISCUSSION: [Polar Humenn] My vote is for "map". Rationale: The primitive functions, i.e. integer-equal, are named with their arguments' particular type, not their resultant type. If you named functions for their resultant type, as is suggested with "integer-map" returning a bag of integers regardless of what its argument type is, then to be consistent with that naming convention would mean the "equals" function between integers would be called really be called "boolean-equal" because equal returns a boolean. And that would lead to inconsistent, not to mention, nonsensical naming. The functionality of "map" is independent of the primitive type of the its arguments, where as "integer-equal" is not, "integer-equals" requires two integers as arguments. The function "map" only requires the supplied function and the supplied bag to agree on types, no matter what the type happens to be. It is truly polymorphic. I think naming "integer-map" is really confusing as it only states half the type story, the rest is left in the air. If you were to fully specify the type in the name, you'd have to say something like "integer-float-map" for functions that map bags of integers to floats (or visa versa depending on how you want it". That would cause an explosion of type names, which is unnecessary, because the <Function> argument really specifies the type. Also, for extension types, the function "map" can easily and with formal integrity, be used for any extension type and any other extension functions that do conversions or selections of that type. Furthermore, this "map" function didn't come out of nowhere, it is the most popular polymorphic function on the planet. :) [Daniel Engovatov] My vote is for <type>-map. I have explained some of my rational for this in a previous e-mail. Most important are - consistency and ease of expandability - for the cases when the function name is supplied as an argument that has its value determined during the evaluation time. Not specifying the return type of the enclosing "higher" order function would make it extremely cumbersome to define a consistent and optimized interface. [Seth Proctor] I think there's been too much emphasis in this conversation on comparing map and type-equal. The better comparison is between map and things like type-one-and-only. The one-and-only functions could have been defined like the map function, operating on any type and returning a single value of the same type, just like map is now defined [1]. Instead, it works on pre-defined types [2]. This is useful because we know specifically what type is being returned by the function, and what type we expect to work with inside the function. There are other type-* functions that are in the same position (think Bag and Set functions), which is why Daniel and I are talking about consistency. Arguably, it could be useful to change all of the type-* functions to be defined like map, so that the generic functionality could be used by any type, but it would require an overhaul of the entire spec, and therefore is inappropriate for now (maybe a 1.1 or 2.0 version) [1] In the map function the type it operates on is the return type of the function, and that is indeed the same type it returns. [2] It is relatively easy for an implementation to let new types be used in this system, so it's not hard to extend. [Polar Humenn, responding to Daniel Engovatov] > My vote is for <type>-map. > I have explained some of my rational for this in a previous e-mail. > > Most important are - consistency The proposed naming convention is NOT consistent with the other functions. The current function names contain the type of their arguments, whereas the proposed <type>-map names the resultant type. > and ease of expandability I really don't know what you mean by "expandability". > - for the cases when the function name is supplied as an argument that > has its value determined during the evaluation time. The function name is supplied EXPLICITLY in the FunctionId attribute of the <Function> element. It's value is already determined at compile time. That was the specific reason for the <Function> element. Now, of course, you can take any IMPLEMENTATION route you chose, such as using the "interpreter" approach where you might not know its value until evaluation time, but that is certainly not FORCED by the specification. [Polar Humenn, responding to Seth Proctor] > I think there's been too much emphasis in this conversation on > comparing map and type-equal. The better comparison is between > map and things like type-one-and-only. The one-and-only > functions could have been defined like the map function, > operating on any type and returning a single value of the same > type, just like map is now defined [1]. That is true. One-and-only can be polymorphic, and I certainly would NOT complain if it were. However, the name is consistent with the other naming convention is that the <type> in the name, names its argument. It is only coincidence that it also names its return type as well. > Instead, it works on pre-defined types [2]. This is useful because we > know specifically what type is being returned by the function, and what > type we expect to work with inside the function. There are other type-* > functions that are in the same position (think Bag and Set functions), > which is why Daniel and I are talking about consistency. The other functions, especially the set functions use an implicit "type-equal" function in the reduction of the set. That is why the set functions contain the type name. As for the "type-bag", "type-one-and-only", "type-bag-size" functions, I would be very happy if they were polymorphic as well. The type is pretty meaningless to their functionality. However, the function "type-is-in" calls an implicit function "type-equal" to handle the membership determination. So, it can be said that it is needed. > Arguably, it could be useful to change all of the type-* > functions to be defined like map, so that the generic > functionality could be used by any type, but it would require > an overhaul of the entire spec, and therefore is inappropriate > for now (maybe a 1.1 or 2.0 version) Arguably, we could eliminate most of the "typing" information because it could be deduced by the type system, especially since every attribute value and designator has a required DataType XML attribute, but we've already been down that route. > [1] In the map function the type it operates on is the return type of the > function, and that is indeed the same type it returns. Not so. In the map function, the "type" it "operates on" is the argument type of the given function not the resultant type. The given function takes an arguement of type "a" and returns an item of type "b". The map function converts every memeber of a bag of type "a" to a bag of type "b". It is only a coincidence if the resultant type is the same type as the argument type, i.e. a = b. > [2] It is relatively easy for an implementation to let new types be used in > this system, so it's not hard to extend. That is an implementation issue. I have a system for which "map" can operate on any type, old or newly introduced. I don't have to create a new map function for the new type. [Polar Humenn, responding to Daniel Engovatov] > >As for the "type-bag", "type-one-and-only", "type-bag-size" functions, I > >would be very happy if they were polymorphic as well. The type is pretty > >meaningless to their functionality. However, the function "type-is-in" > >calls an implicit function "type-equal" to handle the membership > >determination. So, it can be said that it is needed. > > Why would you be happy? Would it make for a simpler, faster and more > efficient implementation for a variety of languages and architectures? That depends on the capability of the implementors, and the languages and architectures chosen. > What is the reason for introducing polymorphic functions beyond it being a > "cool" feature? Use case? Sample implementation that we can see, how it > useful? I don't know what "cool" is. Use case: If I introduce a new type, say "FingerPrint", and I use an AttributeDesignator to retrieve attributes of that type, I don't have to create a new function "FingerPrint-bag-size" to find out how many I have when I do retrieve them, I can just use the same old function "bag-size". Likewise, if I create a function called "FignerPrint-to-Characteristic" I don't have to create a new function "FignerPrint-map" (or would it be "Characteristic-map"?) to convert a bag of FingerPrint values to a bag of Characteristic values. I would just use the same old "map". Now, how you implement it, is up to you. You certainly wouldn't be precluded from creating "FingerPrint-bag-size". or FingerPrint-map (or Characteristic-map?). Sample implementation: I've already gone over how you can do most of this with Java interfaces, of which you can do the analogous thing with C++. [Polar Humenn, responding to Seth Proctor, after resolution was posted] > > 33. Subject: map function > > RESOLUTION: keep "map" as is (un-typed) > > After all the discussion on this point, can we at least get an explination > of how this was decided? I'd like to hear the justification for making one > function different than all the others. I think it was decided to keep "map" the way it is for the following reasons: 1. First and foremost, it has been determined that the specification is not broken because "map" is polymorphic. 2. No change needs to be made to the spec, i.e. we do not have to introduce "integer-map", "string-map", etc., which further implies that we must make restrictions on the functions that can be applied to each <type>-map function. 3. Accepting <type>-map would enlarge our conformance test space. [Seth Proctor, responding to Polar Humenn] Thanks. That was what I was looking for. I would suggest that if anyone is keeping a list of next-generation XACML features, they add to it that someone should revisit this issue, not to change map, but to consider changing some of the other functions to act the same way. My issue with the map function is not how it works, merely that it's different than the other functions that should have the same kind of (useful) functionality. [Anne Anderson, responding to Seth Proctor] There was no consensus on the list, and it was not moving toward consensus. The default is to make no change to the existing specification unless it is actually broken and could not work. ========================================================================= 0034.
http://lists.oasis-open.org/archives/xacml-comment/200211/msg00062.html Subject: XCAML Spec version 1.0 - Example 2, Rule 1 From: Jahan Moreh <
jmoreh@sigaba.com> Date: Wed, 20 Nov 2002 14:09:54 -0800 Section 4.2.3. Rule 1, line 1027 states that: "A person may read any record for which he or she is the designated patient". Section 4.2.4.1., Line 1036 starts the XACML rule instance for rule 1, which I assumed is the rule expressed in English in line 1027. Line 1095-1111 (the condition) defines a condition for matching the policy-number attribute from the <Subject> with the policy-number in the patient record. This condition does not match the English statement (A person may read any record for which he or she is the designated patient) stated earlier. Am I missing something or is this an inconsistency? CATEGORY: Inconsistent. STATUS: Resolved 11/21/02. RESPONSE: In Rule 1, "person" in the text descriptions is referred to by "policy-number" in the <Condition>. "policy-number" is used as the patient ID. We agree this is unclear, since "policy" has other meanings. ACTIONS IMPLEMENTED IN: draft sent Fri. 29 Nov 2002 attached to
http://lists.oasis-open.org/archives/xacml-editors/200211/msg00000.html ACTIONS: Use "patient-number"