Hi Rich,
See my previous email for an explanation why it will not be possible to
define the profile in terms of multiple hierarchies. We must have a
single consistent hierarchy to work on. The 2.0 profile talks about
multiple parents, so it works on a DAG or forest in addition to a plain
tree.
Anyway, I've completely lost track of the various proposals for how to
proceed with the profile text. :-) Maybe it's time for a new working
draft after today's call? It would be so much easier to talk about a
specific document, rather than lots of "imaginary" proposals from
several people. :-)
Regards,
Erik
Rich.Levinson wrote:
> Hi Erik,
>
> Previous email was simply to respond to what I believe was the
> inaccurate premise about on which you started your email.
>
> That aside, let me respond to the content of your email. You say:
>
> "if we define the profile in terms of the ancestor attributes.
> This corresponds to that for the purposes of the profile, there is
> an already defined, _single_ "hierarchy" (if we allow a general
> interpretation of the term), which is "flattened" to ancestor
> attributes. The profile does not have to deal with inconsistencies
> in multiple hierarchies."
>
> The assumption you are making here appears to be that the resources
> are simply part of a predefined hierarchy. *There is a big problem
> with this assumption, when you consider it in terms of the algorithms
> defined in section 3.2.*
>
> * These algorithms (3.2) presume that the requested node can have
> multiple parents and those parents also can have multiple
> parents etc.
> * If we are also to take as a given, that this "hierarchy" has
> already been "flattened" in terms of ancestor attributes, then
> that assumes we have already erased any original hierarchical
> relationships.
>
> That is the problem: the prescription in section 3.2 essentially tells
> customers that they must turn their multiple hierarchically arranged
> forest of resources into a DAG in order to use this profile.
>
> My proposal allows you to do exactly that, and if that's what you want
> to do, use section 3.2.1 of my proposed revision which is exactly what
> is in the existing profile.
>
> However, if as I believe is perfectly reasonable, that customers do
> not want to do a preprocessing step that effectively destroys their
> existing hierarchies in order to create a DAG with all of its
> problems, then I am offering section 3.2.2, which saves them the
> trouble of having to do this DAG pre-processing, and allows them to
> work with their pre-existing forest as is, instead.
>
> And, finally, once again, if they have their resources hierarchically
> named, as prescribed in section 2.2, they can use the forest model
> from section 3.2.2 without the need to create the ancestors, because
> they already have them in the URIs.
>
> The issue here seems to be the ancestor model for forest. The existing
> algorithms basically suggest that the customer cut down their original
> forest and replace it with a DAG.
>
> Section 3.2.2 says that instead of replacing the forest with a DAG,
> determine the ancestors by following the original hierarchies
> directly, which of course you can't do if you have already replaced
> your forest with a DAG.
>
> Or if you didn't replace your forest and just created a DAG in front
> of it, section 3.2.2 says disregard this DAG and process the forest
> directly.
>
> One final note: you made the following point twice in your email, so I
> want to clarify that I do not believe what you are claiming is, in
> general, a problem:
>
> * "Once you start adding a resource to multiple, independently
> defined hierarchies, *you can get inconsistencies.* Two nodes
> may have reverse ancestor relationships in two different
> hierarchies."
>
> * "for the purposes of the profile, there is an already defined,
> _single_ "hierarchy" (if we allow a general interpretation of
> the term), which is "flattened" to ancestor attributes. The
> profile does not have to *deal with inconsistencies* in multiple
> hierarchies"
>
> These "inconsistencies" you are referring to, only exist if you want
> to create a DAG. If you just work on the forest, they are not
> inconsistencies and do not create any problems. It is only when you
> map the forest into the highly constrained DAG that you find that by
> forcing a DAG on the forest, you effectively force rules on the forest
> that only need to be there if you want to create a DAG.
>
> As has been discussed, not everyone believes that transforming a set
> of hierarchies into a DAG is a good idea. It may be for some
> applications, like creating dictionaries of resources, but that is not
> an access control application. It is an inventory-type application.
> For access control there is no requirement to create a DAG, and little
> incentive to do so, if it will force rules on assignment of relations
> for resources that are not needed and prevent creation of
> organizational resource relations that are considered desirable.
>
> On the one hand, technically, this issue boils down to:
>
> * How to define the ancestors (DAG or forest)
>
> On the other hand, operationally, the issue boils down to:
>
> * Do customers want to represent their resources in the form of a
> DAG, which will effectively make it impossible for them to
> manage multiple hierarchies independently.
>
> For the first technical point, my proposal offers both options.
> For the second operational point, my proposal offers 3.2.2, 3.2.2.1 if
> they find the DAG too restrictive.
>
> All this is done with no change in functionality, but simply be
> explaining the problem being solved by the profile more clearly, which
> makes obvious the alternate set of algorithm in section 3.2.2.
>
> Thanks,
> Rich
>
>
>
>
> Rich.Levinson wrote:
>> Hi Erik,
>>
>> I think that you are misinterpreting what I said in the previous
>> email. Let me try to be more explicit:
>>
>> 1. Start with an unnamed collection of resources. Let's say there are
>> N individual identical resources.
>> 2. On a laptop, using a program, create an array of N variables, for
>> example
>> int parent[] = new parent[N];
>> 3. Now I can start creating my hierarchy by assigning a value to
>> these parent ints which somehow identifies another of the
>> resources in the collection. I believe at this point that I must
>> pick some method to identify the elements of the collection,
>> otherwise there is no meaning to this value.
>> 4. For the sake of discussion, let me choose to use the index of the
>> element in the array as the way to identify the parent. Therefore,
>> I can pick any element in the array and assign it a value in the
>> range 0->N-1. For example, I can say:
>> parent[i] = j;
>> 5. Using this technique I can create a hierarchy of these resources.
>>
>> This is basically an implementation of the example I gave in this
>> email I was asked to prepare to help the TC understand the issue by
>> example:
>> http://lists.oasis-open.org/archives/xacml/200902/msg00058.html
>>
>> The bottom line is that in order to assign parent child
>> relationships, you need to have something to hold the assignment
>> artifact. There will be one artifact holder for each resource. When
>> you assign an artifact to a holder, this artifact must somehow
>> identify another resource in the collection in order for it to have
>> any meaning in terms of this operation of assigning a parent child
>> relationship.
>>
>> So, in the example I gave in the email, each of the 2 customers
>> assigned parent child relations to the empty boxes on the piece of
>> paper they were each handed.
>>
>> When customer 1 handed the paper to the collection manager, the
>> manager did the equivalent of the above.
>>
>> The fact that I had id-numbers painted on the box was just to help
>> people understand the problem. The example works equally well if you
>> paint the numbers on the boxes later after the customers have handed
>> in their papers and the manager entered their data into 2 arrays.
>>
>> The manager would then create a 3rd array and assign these painted
>> numbers then.
>>
>> This is totally consistent with what you are calling "Way A":
>>
>> "In way A, one first defines the parent-child relations on the
>> resources themselves, independent of anything with names. After that
>> is done, one can give name to the nodes. There is no risks of
>> inconsistencies."
>>
>> So, I do not understand, what you are trying to indicate in your
>> email, since it appears to premised on an assumption you are making
>> that appears to be inconsistent with what I have been saying in these
>> emails. Since I believe I have been totally consistent in my
>> representation of the problem, we should be able to unambiguously
>> resolve this "Way A", "Way B" discussion, and possibly come up with
>> some terminology on which we agree so that we may continue this
>> analysis without having to continually re-explain what we are talking
>> about.
>>
>> Thanks,
>> Rich
>>
>>
>>
>>
>> Erik Rissanen wrote:
>>> Hi Rich,
>>>
>>> What you describe is what I meant with "Way B".
>>>
>>> In way A, one first defines the parent-child relations on the
>>> resources themselves, independent of anything with names. After that
>>> is done, one can give name to the nodes. There is no risks of
>>> inconsistencies.
>>>
>>> In contrast, in Way B, you initially have a set of hierarchies. Once
>>> you start adding a resource to multiple, independently defined
>>> hierarchies, you can get inconsistencies. Two nodes may have reverse
>>> ancestor relationships in two different hierarchies. This is
>>> inherent in this model, and has nothing to do with how we formulate
>>> the profile.
>>>
>>> Anyway, all this is outside the scope of the profile itself if we
>>> define the profile in terms of the ancestor attributes. This
>>> corresponds to that for the purposes of the profile, there is an
>>> already defined, _single_ "hierarchy" (if we allow a general
>>> interpretation of the term), which is "flattened" to ancestor
>>> attributes. The profile does not have to deal with inconsistencies
>>> in multiple hierarchies.
>>>
>>> The single "hierarchy" which the profile works on, may be a the
>>> result from a preprocessing step where a number of independent
>>> hierarchies have been merged. But not, it's not always possible to
>>> merge hierarchies consistently.
>>>
>>> Best regards,
>>> Erik
>>>
>>>
>>> Rich.Levinson wrote:
>>>> Hi Erik,
>>>>
>>>> In fact, my view has always been "Way A". My conceptualization is
>>>> that there is a collection of physical resources and that an
>>>> organization organizes the resources in various ways, and, in
>>>> particular, as hierarchies. Every time someone adds a resource to a
>>>> hierarchy, the resource gets a new name and parent attached to it.
>>>> After this has been done for a while the net result is that the
>>>> collection of physical resources can be viewed as having one or
>>>> more hierarchies "draped" over it. For every hierarchy a resource
>>>> belongs to, it, in general can be assumed to be assigned a name and
>>>> a parent. Hopefully, we agree that is "Way A" and based on that
>>>> assumption, it should be fairly straight forward to understand the
>>>> issue:
>>>>
>>>> Ok, so, based on your formula, what I do is:
>>>>
>>>> * follow the parent-child relations
>>>> * this is fine at the requested resource, I find all my parents
>>>> * now I go to each parent and collect all of its parents ***
>>>>
>>>> This is where the problem is introduced. As soon as I collect a
>>>> parent of my parent that is not a member of a hierarchy I am in, we
>>>> have defined a DAG.
>>>>
>>>> If I stick to parents of parents that are members of hierarchies I
>>>> am in, then I am in a forest.
>>>>
>>>> The diff in these 2 methods is that the DAG method doesn't bother
>>>> to look at whether the requested node is a member of the hierarchy
>>>> that it is following from the requested node's parent.
>>>>
>>>> The problem compounds as you follow each generation.
>>>>
>>>> Thanks,
>>>> Rich
>>>>
>>>>
>>>>
>>>>
>>>> Erik Rissanen wrote:
>>>>> Rich, Hal and All,
>>>>>
>>>>> Just a quick comment. I don't think that just because a resource,
>>>>> or an ancestor, has multiple normative names, the hierarchy would
>>>>> become a DAG. We need to differentiate between resources and names
>>>>> of resources.
>>>>>
>>>>> One way ("Way A") to think of the problem is that the parent-child
>>>>> relations are bound to resources, not the resource names. To
>>>>> collect the ancestors to the request, one has to follow the
>>>>> parent-child relations, and then include all names of all ancestor
>>>>> resources. That is what the profile tries to say. (I think.) And
>>>>> that would be correct in my opinion. And would not necessarily
>>>>> mean that the profile was made to support a DAG.
>>>>>
>>>>> An alternative way ("Way B") is to think that the parent-child
>>>>> relations are tied to the resource names, not the resources
>>>>> themselves (or that there are no resources independent of names).
>>>>> I get the feeling that at least Rich looks at it like this.
>>>>>
>>>>> I think way B is problematic since it opens up the possibility
>>>>> that parent-child relations between different names for the same
>>>>> resources conflict with each other. This is what I meant with
>>>>> "consistency" in my post last week. By adopting way A, we avoid
>>>>> the problem.
>>>>>
>>>>> Best regards,
>>>>> Erik
>>>>>
>>>>>
>>>>> Rich.Levinson wrote:
>>>>>> / /I agree with that. However, it is the algorithms that allow
>>>>>> and appear to encourage collection of non-member ancestors. Here
>>>>>> is the text:
>>>>>>
>>>>>> For each ancestor of the node specified in the “resource-id”
>>>>>> attribute or attributes, *and for each normative
>>>>>> representation of
>>>>>> that ancestor node*, an <Attribute> element with AttributeId
>>>>>> “urn:oasis::names:tc:xacml:2.0:resource:resource-ancestor”.
>>>>>>
>>>>>> The <AttributeValue> of this <Attribute> SHALL be the normative
>>>>>> identity of the ancestor node.
>>>>>> The DataType of this <Attribute> SHALL depend on the
>>>>>> representation chosen for the identity of nodes in this
>>>>>> particular
>>>>>> resource.
>>>>>> This <Attribute> MAY specify an Issuer.
>>>>>> For each “resource-parent” attribute, there SHALL be a
>>>>>> corresponding “resource-ancestor” attribute.
>>>>>> If the requested node is part of a forest rather than part of a
>>>>>> single tree, *or if the ancestor node has more than one
>>>>>> normative
>>>>>> representation*, there SHALL be at least one instance of this
>>>>>> attribute for each ancestor along each path to the multiple
>>>>>> roots
>>>>>> of which the requested node is a descendant, *and for each
>>>>>> normative representation of each such ancestor*.
>>>>>>
>>>>>> It is the addition of all the "...each normative representation
>>>>>> of each such ancestor" which clearly opens up these algorithms to
>>>>>> imply a DAG. Without these phrases, it is still not particularly
>>>>>> tight, but alone they could be interpreted to imply a forest.
>>>>>> With the phrases DAG is inescapable.
>>>>>>
>>>>>> The point is that these are ancestor nodes and nothing ties their
>>>>>> normative representations to be those that are in the hierarchies
>>>>>> of which the requested node is a member.
>>>>>>
>>>>>> This IS the problem. It is these specific algorithms and what
>>>>>> they say about ancestors that forces you into a DAG. It clearly
>>>>>> includes hierarchies of which the requested node is not a member.
>>>>>>
>>>>>> Therefore, it sounds like we are in agreement. That there is a
>>>>>> problem that needs to be fixed.
>>>>>>
>>>>>> Thanks,
>>>>>> Rich
>>>>>>
>>>>>>
>>>>>> Hal Lockhart wrote:
>>>>>>> As I have said repeatedly, the only problem with combining the
>>>>>>> initial hierarchies into a DAG arises if the original
>>>>>>> hierarchies include hierarchies of which the Resource is NOT A
>>>>>>> MEMBER.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hal
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ________________________________
>>>>>>>
>>>>>>> From: Rich.Levinson [mailto:] Sent:
>>>>>>> Tuesday, March 10, 2009 8:56 AM
>>>>>>> To:
>>>>>>> Cc: Erik Rissanen;
>>>>>>> Subject: Re: [xacml] Summary of what I think I said on the call
>>>>>>> about the hierarchical profile
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hi Hal,
>>>>>>>
>>>>>>> The fact is that it is the algorithms in section 3.2 that imply
>>>>>>> that the hierarchies are combined as a DAG. There is no problem,
>>>>>>> in general, if the one or more of the original "hierarchies"
>>>>>>> happens to be a DAG. The problem is that the algorithms force
>>>>>>> the combination of the originals, DAG or forest.
>>>>>>>
>>>>>>> The recommended changes to the spec that I have proposed is to
>>>>>>> have a choice of algorithms for combining the hierarchies. That
>>>>>>> way customers can decide for themselves which is appropriate for
>>>>>>> their resource collections.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>
>>>>>>>
>>>>>>> Hal Lockhart wrote:
>>>>>>> I think the source of confusion was this. Daniel's point was
>>>>>>> that the initial representation of each hierarchy could be a
>>>>>>> DAG, since it is a generalization of a tree. Rich's point was
>>>>>>> that if you start out with all the hierarchies in whatever form,
>>>>>>> and you include defined hierarchies which do not include the
>>>>>>> Resource in question as a member, even though ancestors of the
>>>>>>> Resource are members of the hierarchy, if you combine all the
>>>>>>> hierarchies you lose the information about the original
>>>>>>> hierarchies necessary to be able to distinguish whether the
>>>>>>> nodes above the Resource are true ancestors or not.
>>>>>>>
>>>>>>> My comments on the call and below on the DAG were based on the
>>>>>>> premise that we started out with one or more hierarchies merged
>>>>>>> them into a DAG and then determined the parents and ancestors.
>>>>>>> Under this premise, the use of a DAG seemed like a intermediate
>>>>>>> step of no particular interest. I now see that Daniel was trying
>>>>>>> to say that at the very beginning, any of the distinct
>>>>>>> hierarchies may be multi-rooted and thus represented as a DAG.
>>>>>>>
>>>>>>> My feeling now is to make minimal changes to the document. I
>>>>>>> think if we make it clear that the starting point is one or more
>>>>>>> hierarchy each of which may be singly or multiply rooted, but
>>>>>>> only hierarchies which contain the resource. I don't object to
>>>>>>> the individual hierarchies or their union as being described as
>>>>>>> a DAG, but the ancestors could also be computed by examining
>>>>>>> each hierarchy in turn.
>>>>>>>
>>>>>>> I have some concerns about the URI part, which I will put in a
>>>>>>> separate email.
>>>>>>>
>>>>>>> Hal
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Erik Rissanen [mailto:]
>>>>>>> Sent: Monday, March 09, 2009 7:43 AM
>>>>>>> To:
>>>>>>> Cc:
>>>>>>> Subject: Re: [xacml] Summary of what I think I said on the
>>>>>>> call about the
>>>>>>> hierarchical profile
>>>>>>> Hi Hal and all,
>>>>>>> If I understand you correctly, then what you propose is
>>>>>>> the exact same
>>>>>>> thing as I proposed, except I used the DAG term because I
>>>>>>> thought we
>>>>>>> wanted to specify how you would get the list of ancestors
>>>>>>> from a graph.
>>>>>>> If that is not the case, then we can drop the terms DAG,
>>>>>>> forest and so on.
>>>>>>> So, basically we just say that you have one or more
>>>>>>> hierarchies in which
>>>>>>> the resource is part of and for the request context you send
>>>>>>> in the
>>>>>>> resource itself, and its ancestors.
>>>>>>> The only thing which I am still uncertain about in your
>>>>>>> email is whether
>>>>>>> you are trying to ban the use of a DAG. Sending a list of
>>>>>>> ancestors this
>>>>>>> way would work for a DAG, which I think is ok.
>>>>>>> Best regards,
>>>>>>> Erik
>>>>>>> Hal Lockhart wrote:
>>>>>>> This is an attempt to summarize what I said on
>>>>>>> the call today. I have
>>>>>>> changed the order a little and added a few
>>>>>>> extra comments.
>>>>>>> First, let us agree that the hierarchical profile
>>>>>>> assumes that some
>>>>>>> party needs an AZ decision about a resource
>>>>>>> that is part of one or more
>>>>>>> hierarchy. The profile does not define what the hierarchy
>>>>>>> is, the
>>>>>>> semantics of the relationships among its members or anything
>>>>>>> like that. It
>>>>>>> does define how to extract a small subset of the information
>>>>>>> and put it in
>>>>>>> the Request Context.
>>>>>>> Now let us consider the two modes of operation in
>>>>>>> the draft Rich created.
>>>>>>> He called them DAG and Forest mode. If we look
>>>>>>> at my msg from Tuesday I
>>>>>>> give a small example of some hierarchies and a case where
>>>>>>> the two methods
>>>>>>> produce different information in the request context. Note
>>>>>>> that they will
>>>>>>> never differ in their parents, but the DAG mode can include
>>>>>>> ancestors
>>>>>>> which are not actually in the same hierarchy as the
>>>>>>> resource. In the
>>>>>>> example, Z is an ancestor of an ancestor (parent actually).
>>>>>>> Another way to express this is that in the DAG
>>>>>>> model, the "is an
>>>>>>> ancestor" relationship is transitive. Every
>>>>>>> ancestor of an ancestor is an
>>>>>>> ancestor. In the forest model, it is only transitive within
>>>>>>> a given
>>>>>>> hierarchy.
>>>>>>> It is my opinion that the intent of the 2.0
>>>>>>> profile, although it is
>>>>>>> certainly not clear and definitely contains
>>>>>>> mistakes, was that the
>>>>>>> information put in the request context only include
>>>>>>> hierarchies of which
>>>>>>> the resource is a member. In my example, the Z-A hierarchy
>>>>>>> would not even
>>>>>>> be considered. Therefore the issue of transitivity does not
>>>>>>> arise. In
>>>>>>> effect, we are always using the forest model.
>>>>>>> Therefore I do not believe it is necessary to
>>>>>>> have the forest and DAG
>>>>>>> modes. I do not see any valid usecases for the
>>>>>>> transitivity property and I
>>>>>>> do not think it was intended in the 2.0 version of the
>>>>>>> profile. As an
>>>>>>> example, my father is a navy officer. I am below him in a
>>>>>>> family hierarchy,
>>>>>>> but that does not make navy admirals my ancestors in any
>>>>>>> way. If my father
>>>>>>> was the resource, the navy hierarchy would be relevant, but
>>>>>>> if I am the
>>>>>>> resource, it is not. I think all that is required is to
>>>>>>> clarify that only
>>>>>>> hierarchies of which the resource is a member will be given any
>>>>>>> consideration in computing parents and ancestors.
>>>>>>> Next I talked about loosening the requirement
>>>>>>> that resources be named
>>>>>>> using a hierarchical URI. We previously agreed
>>>>>>> to allow strings. My only
>>>>>>> concern was to allow strings or URIs, not URIs carried in
>>>>>>> strings. This
>>>>>>> allows URI typed operations to be used when the name
>>>>>>> actually is a URI.
>>>>>>> Eric proposed that we allow any XACML datatype, and I agree.
>>>>>>> People who
>>>>>>> want the functionality of parsing a hierarchical URI can use
>>>>>>> a URI and
>>>>>>> others can use whatever is convenient for them. Of course it
>>>>>>> is possible
>>>>>>> that the information on ancestors and parents might be
>>>>>>> inconsistent with
>>>>>>> the structure of the hierarchical URI, but that was true in
>>>>>>> the 2.0
>>>>>>> profile and there are lots of other legal ways for the
>>>>>>> request context to
>>>>>>> contain inconsistent information. If you put sand in your
>>>>>>> car's gas tank,
>>>>>>> it will not run, an XACML PDP is the same. In other words,
>>>>>>> GIGO.
>>>>>>> Finally I said I generally supported Erik's
>>>>>>> proposed plan of action with
>>>>>>> one exception. Thinking about the problem
>>>>>>> independently, I had come to the
>>>>>>> conclusion we should totally eliminate mention of a DAG,
>>>>>>> before reading
>>>>>>> Erik's email. Here is my reasoning. As I said above, we
>>>>>>> start out with a
>>>>>>> rich set of information about the various hierarchies, at
>>>>>>> the end we end
>>>>>>> up with a request context which contains nothing but an
>>>>>>> unordered list of
>>>>>>> parents and an unordered list of ancestors. A DAG is simply
>>>>>>> a possible
>>>>>>> intermediate step. It contains more information than the
>>>>>>> request context,
>>>>>>> but less than the original set of multiple hierarchies.
>>>>>>> Talking about a
>>>>>>> DAG doesn't seem to me to help in explaining what the
>>>>>>> context handler must
>>>>>>> do, because it represents neither the starting point nor the
>>>>>>> ending point,
>>>>>>> just one possible intermediate step.
>>>>>>> What I did not say on the call.
>>>>>>> During the call I was thinking of the distinct
>>>>>>> hierarchies as being
>>>>>>> singly rooted as in my simple example. However,
>>>>>>> after the call I realized
>>>>>>> that the algorithm I mentioned completely eliminates the
>>>>>>> problem of
>>>>>>> transitivity regardless of whether the initial, distinct
>>>>>>> hierarchies are
>>>>>>> singly or multiply rooted. Therefore it doesn't matter
>>>>>>> whether the
>>>>>>> individual hierarchies or their union is represented as a
>>>>>>> forest, dag,
>>>>>>> polyarchy or database table.
>>>>>>> To be explicit here is what I mean:
>>>>>>> 1. Start with all hierarchies in the space of resources
>>>>>>> of the type of
>>>>>>> interest.
>>>>>>> 2. discard all descendants of the resource.
>>>>>>> 3. discard all resource hierarchies (and their members)
>>>>>>> which do not
>>>>>>> contain the resource.
>>>>>>> Now, however you represent the information, any
>>>>>>> reasonable algorithm to
>>>>>>> enumerate the parents and ancestors, discarding
>>>>>>> duplicates will produce
>>>>>>> the same results, ignoring order. The issue of transitivity
>>>>>>> will not arise,
>>>>>>> thus Rich's concern is satisfied.
>>>>>>> Hal
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this mail list, you must leave the
>>>>>>> OASIS TC that
>>>>>>> generates this mail. Follow this link to all your TCs
>>>>>>> in OASIS at:
>>>>>>>
>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe from this mail list, you must leave the OASIS TC
>>>>>>> that
>>>>>>> generates this mail. Follow this link to all your TCs in OASIS at:
>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail. Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
