Hi John, This is what I meant on the call: Agreement-Type classification values shall be designated with the following attribute identifier: urn:oasis:names:tc:xacml:3.0:ipc: resource:agreement-type The DataType of this attribute is
http://www.w3.org/2001/XMLSchema#anyURI . This attribute data may contain multiple values. This attribute can be used to indicate whether or not a specific resource is governed by a particular license arrangement. The range of values of the attribute SHALL be “urn:oasis:tc:xacml:ipr-profile:non-disclosure-agreement”, “urn:oasis:tc:xacml:ipr-profile:proprietary-information-agreement”, “urn:oasis:tc:xacml:ipr-profile:technical-data-grant”, “urn:oasis:tc:xacml:ipr-profile:copyright-grant”, “urn:oasis:tc:xacml:ipr-profile:patent-grant”, “urn:oasis:tc:xacml:ipr-profile:trademark-grant”, “urn:oasis:tc:xacml:ipr-profile:cross-licencing-grant”, and/or “urn:oasis:tc:xacml:ipr-profile:royalt-bearing”. /Erik On 11/17/2011 01:40 AM, Tolbert, John W wrote: How about this: Agreement-Type classification values shall be designated with the following attribute identifier: urn:oasis:names:tc:xacml:3.0:ipc: resource:agreement-type The DataType of this attribute is
http://www.w3.org/2001/XMLSchema#string . This attribute data may contain multiple values. This attribute can be used to indicate whether or not a specific resource is governed by a particular license arrangement. The range of values of the attribute SHALL be “NON-DISCLOSURE AGREEMENT”, “PROPRIETARY INFORMATION AGREEMENT”, “TECHNICAL DATA GRANT”, “COPYRIGHT GRANT”, “PATENT GRANT”, “TRADEMARK GRANT”, “CROSS LICENSING GRANT”, and/or “ROYALTY BEARING”. Affiliation-Type classification values shall be designated with the following attribute identifier: urn:oasis:names:tc:xacml:3.0:ipc:subject:affiliation-type The DataType of this attribute is
http://www.w3.org/2001/XMLSchema#string . This attribute data may contain multiple values. The range of values of the attribute SHALL be “CUSTOMER”, “SUPPLIER”, “PARTNER”, “NON-PROFIT”, “GOVERNMENT”, “PRIMARY CONTRACTOR”, “SUBCONTRACTOR”, “JOINT DEVELOPMENT”, and/or “AUTHORIZED SUB-LICENSOR”. IP-Type and IP-Data will still be replaced by the Copyright/Patent/Proprietary/Public Domain/Trademark Booleans. We can discuss tomorrow. Thanks From: Tyson, Paul H [ mailto:
PTyson@bellhelicopter.textron.com ] Sent: Wednesday, November 16, 2011 1:34 PM To: Tolbert, John W; David Brossard Cc:
xacml@lists.oasis-open.org Subject: RE: [xacml] IPC profile proposed attribute list 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. Regards, --Paul From:
xacml@lists.oasis-open.org [ mailto:
xacml@lists.oasis-open.org ] On Behalf Of Tolbert, John W Sent: Wednesday, 16 November, 2011 15:21 To: David Brossard Cc:
xacml@lists.oasis-open.org 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:
david.brossard@axiomatics.com ] Sent: Saturday, November 12, 2011 8:28 AM To: Tolbert, John W Cc:
xacml@lists.oasis-open.org Subject: Re: [xacml] IPC profile proposed attribute list Hi John, 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? Agreement-Type:non-disclosure-agreement Boolean Agreement-Type:proprietary-information-agreement Boolean Agreement-Type:technical-data-grant Boolean Agreement-Type:patent-grant Boolean Agreement-Type:trademark-grant Boolean Agreement-Type:cross-licensing-grant Boolean Agreement-Type:royalty-bearing Boolean 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. Thanks John, David. On Fri, Nov 11, 2011 at 7:18 PM, Tolbert, John W <
john.w.tolbert@boeing.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 Copyright Boolean Copyright-Registration String Patent Boolean Patent-Registration String Proprietary Boolean Public-Domain Boolean Trademark Boolean Trademark-Registration String IP-Owner String IP-Designee String Agreement-Type:non-disclosure-agreement Boolean Agreement-Type:proprietary-information-agreement Boolean Agreement-Type:technical-data-grant Boolean Agreement-Type:patent-grant Boolean Agreement-Type:trademark-grant Boolean Agreement-Type:cross-licensing-grant Boolean Agreement-Type:royalty-bearing Boolean Agreement-Id String Effective-Date Date Expiration-Date Date Subject attribute Data Type Organizational-Affiliation String Affiliation-Type:customer Boolean Affiliation-Type:supplier Boolean Affiliation-Type:partner Boolean Affiliation-Type:non-profit Boolean Affiliation-Type:government Boolean Affiliation-Type:primary-contractor Boolean Affiliation-Type:sub-contractor Boolean Affiliation-Type:joint-development Boolean Affiliation-Type:authorized-sub-licensor Boolean Agreement-Id String Thoughts? Thanks, John --------------------------------------------------------------------- To unsubscribe, e-mail:
xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
xacml-help@lists.oasis-open.org -- David Brossard, M.Eng, SCEA, CSTP VP Product Marketing & Customer Relations +46(0)760 25 85 75 Axiomatics AB Skeppsbron 40 S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082 http://www.axiomatics.com http://twitter.com/axiomatics