[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Comments for discussion tomorrow
A list of all comments received to date against the 1.0 specification is attached. I suggest using this as the basis for our deliberations at tomorrow's meeting. 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
Title: Comments on XACML 1.0 Committee Specification Maintainer: Anne Anderson Version: 1.1, 02/11/13 (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 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/200211/msg00010.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. 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: Not yet discussed. RESPONSE: ACTIONS: DISCUSSION: Affects "B.1.XACML namespaces", PDF lines 4332-4333 ============================================================================= 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 (Primative 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: 0004 STATUS: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 0003d. line 3278: 'xacml:Policy:PolicySet' there seems to be an extraneous border line above the row in the table CATEGORY: Editorial. STATUS: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 0003f. line 3385: '<AttributeValue' snippet font (should be 'courier') CATEGORY: Editorial. STATUS: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 0003h. line 4277: 'first argument of Anderson@sun.com?' question mark should be quotation mark CATEGORY: Editorial. STATUS: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 0003i. line 4434: ' urn:oasis:names:tc:xacml:1.0:resource:scope' leading spaces or indentation (should be left margin aligned) CATEGORY: Editorial. STATUS: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 0003j. finally, there seems to be some squooshing going on with lines 2618, 2742, 2778 in the pdf. can others confirm? CATEGORY: Editorial. STATUS: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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: 0002 STATUS: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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. Unclear. STATUS: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 0007b. 10.3.8: function:rfc822Name-equal is listed as rfc822name-equal (lower case 'n' in 'name') CATEGORY: Editorial. STATUS: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: --------------------------------------------------------------------------- 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: Not yet discussed. RESPONSE: ACTIONS: ====================================================================== 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: Not yet discussed. RESPONSE: ACTIONS: ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC