[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Groups - EC-US WD-03 uploaded
I will change the data type to string or anyURI. I agree we need a discussion thread, so I will start that separately. Jurisdiction seems to be an accepted term for distinguishing between ITAR and EAR, or Dept. of State and Commerce. The term “classification” has a lot of loaded meaning in other circles, and I think it is best to use an attribute name that would be less likely to be confused with other interpretations. I agree with Paul that for now, these profiles would be best served by strings for organizations. Companies can easily work out attribute value agreements, and if a more standard way of representing organizational names arises, then we can adopt it later. From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Tyson, Paul H For “license”, I think the range should be either string or anyURI. For “jurisdiction”, I don’t know. As far as I can tell the overwhelming practice is to “classify” things as either “EAR” or “ITAR” (or “Commercial” or “Military”). Then we analyze it a bit further, and discover that the reason we classify things like that is because they fall under the jurisdiction of one governmental agency or another, or more specifically are controlled by a specific set of regulations known as “ITAR” and “EAR”. So if we think that “jurisdiction” points to either a government agency or a set of regulations, a URI might be better. However, just as a label for a classification, the strings “ITAR” and “EAR” work well and conform to current practice. Presumably as the egov initiative progresses the US government might create URIs for the ITAR and EAR regulations. But for this spec I think “ITAR” and “EAR” are suitable. Organization values pose a tougher problem. I’m all for reducing ambiguity, but I’m not sure that creating a new set of values in an OASIS namespace is the best way. I’d rather wait for the registering bodies themselves to define such identifiers. A few years back I tried to determine if Dun & Bradstreet endorsed some URL format that incorporated DUNS numbers, but could not find any evidence of that. I predict that as the web community work through all their “identity in the cloud” issues they will settle on a few reliable methods for unambiguously identifying people and organizations. In the meanwhile, cooperating parties will just have to work out something. The general issue of when to use strings and when to use anyURI for attribute values calls for some study. That is probably a subject for a different email thread, but since the issue has come up a few times recently it might be good to adopt some general guidelines. For example, I have seen an ontology in which countries were identified with a full URI built with “iso3166” in the path (instead of just bare 2-letter strings). But I would not be inclined to use such values for “nationality” and “location” in this profile. Regards, --Paul From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Erik Rissanen John, Submitter's message
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]