I don’t recall about favoring several Boolean-valued attributes over a single attribute with a defined range of string values. I checked the minutes and did not see anything there.
I would prefer to see a defined range of string values for a single ‘agreement-type’ attribute. If an agreement fit into several categories there could be multiple values.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Tolbert, John W
Sent: Wednesday, 16 November, 2011 15:21
To: David Brossard
Subject: RE: [xacml] IPC profile proposed attribute list
Upon further consideration, we decided the *-registration values aren’t needed, so I have removed them from the forthcoming WD-06.
After the last TC call, I was under the impression that using Booleans for a constrained list was preferred over strings with defined values. I agreed to replace the former IP-Data string options with a series of Booleans. I decided to extend that method to agreement-type and affiliation-type as well, in the interest of consistency and in the hope that it would simplify policy authoring.
From: David Brossard [mailto:firstname.lastname@example.org]
Sent: Saturday, November 12, 2011 8:28 AM
To: Tolbert, John W
Subject: Re: [xacml] IPC profile proposed attribute list
I don't see how the following structure makes it easier than what you had before. Where's the catch to having too many string data-types attributes?
In the WD05 in section 2.1.5 you used multi-valued attributes so why the change to a list of boolean? It seemed cleaner in WD05.
Also with regards to copyright and a time attribute (for expiry), is copyright-registration the time at which registration was achieved? I couldn't find the attribute in WD05. I believe you introduced it in this email (http://lists.oasis-open.org/archives/xacml/201111/msg00005.html).
My question is: is having a boolean and a timestamp a bit redundant. Could we infer that no timestamp means false and the presence of a timestamp will help determine whether true or false depending on whether the timestamp has expired.
True the boolean will help simplify policy authoring. It could actually be a virtual attribute computed by a PIP rather than stored in an underlying attribute store. But of course that's an implementation discussion which is orthogonal to the profile discussion.
On Fri, Nov 11, 2011 at 7:18 PM, Tolbert, John W <email@example.com> wrote:
To reduce the number of string data-types, we've decided to expand the allowable strings for the "agreement-type" and "affiliation-type" attributes into separate Boolean attributes, as noted below. I plan on updating WD-06 with this new structure and more explanatory text.
Resource attribute Data Type
Subject attribute Data Type
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
David Brossard, M.Eng, SCEA, CSTP
VP Product Marketing & Customer Relations
+46(0)760 25 85 75
S-111 30 Stockholm, Sweden