[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Comments discussed at 14 November 2002 TC Meeting
The attached file contains the results of our decisions at the 14 November 2002 XACML TC Meeting regarding comments received. Anne Anderson, comments editor -- 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.2, 02/11/14 (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/msg00016.html
ACTION ITEM: [Anne Anderson, due 21 November 2002] Submit a
proposed re-wording of Section A.12 to make it more clear, but
without changing existing schema or semantics.
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: Resolved 14 November 2002.
RESPONSE: Approved.
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 (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: Resolved 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
ACTIONS: Remove border lines between urns in table following
line 3291.
---------------------------------------------------------------------------
0003f. line 3385:
'<AttributeValue'
snippet font (should be 'courier')
CATEGORY: Editorial.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: "squooshing" confirmed.
ACTIONS: Unsquoosh lines 2618, 2742, 2778.
======================================================================
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.
STATUS: Resolved 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Rejected. While the wording of Appendix A.12 needs
improvement to be more clear, and while it is confusing to have
the order of function arguments mean one thing in a Target and
another thing in an Apply, the specification and semantics are
consistent. Since several implementations are already
successfully handling the varying argument order, we feel it is
better to leave the argument order as currently specified. We
encourage you to submit a proposed re-wording of Appendix A.12
that would make the current semantics more clear, however.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Rejected. The *AttributeIsPresent" elements were
removed from the specification in XACML 1.0, which is the version
being reviewed.
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 14 November 2002.
RESPONSE: Rejected. The "QualifiedSubjectAttributeDesignator"
element is named "SubjectAttributeDesignator" in the XACML 1.0
version of the specification, which is the version being reviewed.
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 14 November 2002.
RESPONSE: Approved.
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 14 November 2002.
RESPONSE: Approved.
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".
======================================================================
0011. 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 14 November 2002.
RESPONSE: Approved.
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.
======================================================================
0011. 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 14 November 2002.
RESPONSE: Approved.
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: Discussed 14 November 2002.
RESPONSE: Approved. We agreed that this section is unclear and
needs to be re-worded.
ACTION ITEM: [Anne Anderson, due 21 November 2002] Submit a
proposed re-wording of Section A.12 to make it more clear, but
without changing existing schema or semantics.
ACTIONS:
=========================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC