MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: [xacml] Errata errata (SubjectCategory comparison)
An additional comment:
If we want to use "string-equality" for subject category comparison,
the data type of the SubjectCategory attribute should be xs:string rather
than xs:anyURI.
Actually, there is no reason why the data type is xs:anyURI in that case,
However this could be unnatural because all the category identifiers listed
in Section 10.2.6
look like URIs.
My point is that the data type and the equality semantics
should be consistent.
Satoshi Hada
IBM Tokyo Research Laboratory
mailto:satoshih@jp.ibm.com
Satoshi
Hada/Japan/IBM@IB To: Anne.Anderson@Sun.com
MJP cc: XACML TC <xacml@lists.oasis-open.org>, XACML COMMENT
<xacml-comment@lists.oasis-open.org>
2003/02/07 10:07 Subject: Re: [xacml] Errata errata (SubjectCategory comparison)
>> Reported by: Satoshi Hada
>> Message:
http://lists.oasis-open.org/archives/xacml-comment/200301/msg00034.html
>> Description: Section 5.28 says that: The
>> SubjectAttributeDesignatorType extends the match semantics of
>> the AttributeDesignatorType such that it narrows the attribute
>> search space to the specific categorized subject such that the
>> value of this element's SubjectCategory attribute matches, by
>> string-equality, the value of the <Request> element's subject
>> category attribute.
>>
>> I think "by string-equality" should be "by URI-equality"
>> because the data type of the SubjectCategory attribute is "xs:anyURI".
>> Options:
>>
>> Anne: Use of "string-equality" was intentional. Once we
>> eliminated QNames, we made it possible for the SubjectCategory
>> attribute values to be compared as strings. We chose to
>> specify it that way since "string-equality" is simpler than
>> "URI-equality".
Yes, it's simpler because the equality of two URIs is up to the scheme like
"http:" and "urn:".
However, I still think it should be "URI-equality".
We already have a lot of use of URIs, i.e, the attribute identifiers,
data type identifiers, function identifiers, combining algorithm
identifiers, status code, and so on.
They all should be compared by URI-equality (although it's implicit in the
XACML spec).
I see no reason why we handle only the subject category in such a special
way (by string-equal).
Satoshi Hada
IBM Tokyo Research Laboratory
mailto:satoshih@jp.ibm.com
Anne Anderson
<Anne.Anderson@Su To: XACML TC
<xacml@lists.oasis-open.org>
n.com> cc: XACML COMMENT
<xacml-comment@lists.oasis-open.org>
Subject: [xacml] Errata
errata
2003/02/07 02:18
Please respond to
Anne.Anderson
Thanks, Simon, for the concise and readable errata list! This is
very helpful. And thanks too, to Satoshi, who has picked up a
number of inconsistencies our tired eyes would never have noticed
at this point!
Following are my comments on both the errata list (attached to
http://lists.oasis-open.org/archives/xacml/200302/msg00006.html)
and on the updated spec (in the same e-mail) that incorporated
them.
Typographical Errors.
=====================
Reported by: Satoshi Hada
Message:
http://lists.oasis-open.org/archives/xacml-comment/200212/msg00061.html
Description: On lines 3408 and 3413 DataType attribute is
incorrect.
Options: Replace DataType attribute value with
http://www.w3.org/2001/XMLSchema#string.
Anne: I agree with the Options, but the implementation of them
in the updated spec does not seem right: Line 3413 in the
updated spec seems OK, but line 3408 now has "xs:string" rather
than the correct value
"http://www.w3.org/2001/XMLSchema#string";.
Reported by: Satoshi Hada
Message:
http://lists.oasis-open.org/archives/xacml-comment/200301/msg00007.html
Description: Incorrect data type URI in section B.4, lines 4438, 4439
Options: Change "2002/08/xquery-functions" to "TR/xquery-operators".
Anne: We can't refer to
"http://www.w3.org/TR/xquery-operators/"; because that points to
the most recent Working Draft, and so changes under us.
I think the correct reference is
"http://www.w3.org/TR/2002/WD-xquery-operators-20020816/";,
since it was that snapshot of the Working Draft that we defined
our operators and types against. Someone check me on this,
please.
This should be made consistent throughout the document,
including in the References section.
Reported by: Satoshi Hada
Message:
http://lists.oasis-open.org/archives/xacml-comment/200301/msg00018.html
Description: At the end of C.1, C.2, and C.3, we have the
following description just after the explanation about
policy combining algorithms: "Obligations of the individual
policies shall be combined as described in Section 3.3.2.3".
However, Section 3.3.2.3 is about a policy rather than a set of
policies. So it should be Section 3.3.3.2 rather than 3.3.2.3.
Options: Update section references.
Anne: Section 3.3.3.2 does not describe how to combine
obligations. I recommend the section reference be to Section
7.11 Obligations, where combining obligations is discussed.
Tim, note that both 3.3.3.2 and 7.11 are titled "Obligations",
so your reference may be picking up one rather than the
intended other.
Reported by: Satoshi Hada
Message:
http://lists.oasis-open.org/archives/xacml-comment/200301/msg00019.html
Description: line 4314: [XF] section reference is incorrect
Options: Replace reference 6.3.15.1 with 6.3.15
Anne: I agree that the [XF] section reference is incorrect, and
should be 6.3.15. Note that this change MUST be made in
conjunction with the "unchange" I recommend for
http://lists.oasis-open.org/archives/xacml-comment/200301/msg00007.html
(two errata above): there is no Section 6.3.15 in the current
draft to which http://www.w3.org/TR/xquery-operators/ points!
Reported by: Satoshi Hada
Message:
http://lists.oasis-open.org/archives/xacml-comment/200301/msg00034.html
Description: Section 5.28 says that: The
SubjectAttributeDesignatorType extends the match semantics of
the AttributeDesignatorType such that it narrows the attribute
search space to the specific categorized subject such that the
value of this element's SubjectCategory attribute matches, by
string-equality, the value of the <Request> element's subject
category attribute.
I think "by string-equality" should be "by URI-equality"
because the data type of the SubjectCategory attribute is "xs:anyURI".
Options:
Anne: Use of "string-equality" was intentional. Once we
eliminated QNames, we made it possible for the SubjectCategory
attribute values to be compared as strings. We chose to
specify it that way since "string-equality" is simpler than
"URI-equality".
We could always change our minds, but this was intended at the
time.
Final erratum on Obligations.
Anne: This is clearly new functionality. I agree that
Obligations is underspecified, but I don't think we can make
these fixes without changing the document in non-trivial ways.
I recommend that IBM present us with a proposal for how Section
7.11 should be augmented to cover these cases, and the TC can
then discuss it for inclusion in the Errata document to be kept
on the TC web site.
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC