[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Issue: Hierarchical profile appears ambiguous and inconsistent
Hi Erik,
To complete the picture, there is the case where there are multiple
logical paths to the same physical resource. For example:
State/City01/PostOffice01/MainStreet
State/City01/PostOffice02/MainStreet
In this case these are two normative identities for the same physical
resource, however from a logical protection perspective they are treated
as distinct logical resources, such as only allowing one type of mail
thru PostOffice01, and a second type of mail thru PostOffice02. However,
simply specifying the name "MainStreet" is obviously insufficient to
distinguish between the two logical resources.
As an analogy, one may think of a person having two inboxes on their
desk, one labeled PostOffice01, the other PostOffice02. Your mail gets
to the same person at the same desk, but is placed in different
containers at the desk.
The point is that there is no necessity in either case to break the
hierarchical naming structure. However, using the algorithms in section
3.2 will break the structure from an inheritance perspective, because it
allows unintended inheritance to automatically occur. Along with the
current algorithms in section 3.2 comes all the baggage of the multiple
inheritance problem, which can easily be avoided, by simply using the
URI naming structure already prescribed in section 2.2.
Thanks,
Rich
Rich.Levinson wrote:
> Hi Erik,
>
> The problem presented by the commenter is analagous to:
>
> State/City01/MainStreet
> State/City02/MainStreet
>
> Just because two separate cities have a street named MainStreet does
> not mean these are the same street. These are two distinct normative
> identifiers for two distinct resources.
>
> A forest is a DAG, but a DAG is not necessarily a forest. When you
> start using DAGs that are not forests or hierarchies, because the
> member trees are not disjoint, then you are no longer talking about a
> hierarchical profile.
>
> Possibly we can consider splitting the Hierarchical Profile into two
> profiles:
>
> * One called the Hierarchical Resource Profile, which deals with
> hierarchies and forests
> * One called the DAG Resource Profile, which deals with more general
> structures that are not necessarily hierarchies or forests, but
> may incidentally be in special cases.
>
> However, the current situation, where the profile named "Hierarchical"
> deals with structures that are explicitly non-hierarchical, and
> actually anti-hierarchical, in that they destroy the hierarchical
> properties is not an acceptable state of affairs.
>
> Labeling the profile "Hierarchical" and then representing it with
> anti-hierarchical algorithms is a misrepresentation of its content and
> a Severe Error, because it leads people to expect one thing and then
> delivers something which is exactly NOT what it is labeled to be, and
> has potential extreme severe unintended consequences when used as such.
>
> My recommendation is to correct the content so that the specification
> is no longer mislabeled, which is done by simple modifications to the
> algorithms in section 3.2, which simply changes the node collection
> algorithm to only collect *the one and only parent node of the
> requested node for each normative identity of the requested node* and
> then recursively for ancestors. (i.e. a node can have multiple parents
> but they must be in disjoint trees)
>
> Thanks,
> Rich
>
>
> Erik Rissanen wrote:
>> Hi Rich,
>>
>> I don't think I understand what you mean.
>>
>> The commenter's resources are not disjoint. They are a DAG. Therefore
>> he wants to use the "ancestor scheme" without URIs.
>>
>> Regards,
>> Erik
>>
>> Rich.Levinson wrote:
>>> Hi Erik,
>>>
>>> The commenter states the problem he is trying to solve as:
>>>
>>> * "I have a rule that says "permit if resource has ancestor
>>> 'path'"."
>>>
>>> It is only after he follows the erroneous directions in section 3.2
>>> that he runs into trouble, whereas if he used the suggestion in my
>>> previous email the problem would already be solved and we would have
>>> no issue.
>>>
>>> I have done further research into this and I think that I can now
>>> say unambiguously that section the bulleted algorithms in section
>>> 3.2 are simply wrong, because they are based on an erroneous premise.
>>>
>>> The erroneous premise is that it is assumed that a forest is the
>>> same as a DAG. In fact, they are not the same. In particular, a
>>> forest is generally defined as a *disjoint set of trees*. The
>>> important word in this phrase is "disjoint". There are many reasons
>>> why this problem must be modeled as a disjoint set, several of which
>>> have been covered in previous emails.
>>>
>>> The algorithms in section 3.2 are specifically not disjoint, which
>>> is why they are in error. This error is simply corrected by a minor
>>> modification to ensure disjointness.
>>>
>>> At this point I would like to raise this to a formal issue, which I
>>> would categorize as a recommendation to correct a SEVERE ERROR in
>>> the Hierarchical Profile Specification.
>>>
>>> We have already seen evidence as reported by this commenter that the
>>> errors in this specification are leading users to do wrong and
>>> irrelevant work, and we now have specific formal definitions of the
>>> terms that express exactly what the error is and how it can be
>>> corrected.
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>>
>>>
>>> Erik Rissanen wrote:
>>>> Hi Rich,
>>>>
>>>> My understanding is that the commenter does not want to use URIs at
>>>> all. Instead he wants to do it like this:
>>>>
>>>> resource-id=r1
>>>> resource-ancestor=path
>>>> resource-ancestor=to
>>>> resource-ancestor=one
>>>> resource-ancestor=another
>>>>
>>>> URI matching wouldn't help him.
>>>>
>>>> Regards,
>>>> Erik
>>>>
>>>>
>>>> Rich.Levinson wrote:
>>>>> Hi Erik,
>>>>>
>>>>> With regard to your 2nd point on the comments/users list, it
>>>>> appears to me that because the Hierarchical spec has the problems
>>>>> that I have described in earlier emails, that the user has posed
>>>>> his question in such a way that instead of advising the commenter
>>>>> on what appears to me to be a simple obvious way to solve his
>>>>> problem, you instead have been drawn into considering the user's
>>>>> suggestion that we change the specs from the current explicit
>>>>> description in section 2.2 to one that appears to me would
>>>>> significantly undermine the intent of the current section 2.2.
>>>>>
>>>>> Now that we have hammered away at the hierarchical profile for
>>>>> several emails, and if people have been reading the details, we
>>>>> can now take another look at the question the commenter raised,
>>>>> which I had previously said we should revisit in the context of my
>>>>> proposal (item 3 here:
>>>>> http://lists.oasis-open.org/archives/xacml/200902/msg00004.html).
>>>>>
>>>>> The commenter's question is here:
>>>>> http://lists.oasis-open.org/archives/xacml-comment/200901/msg00003.html
>>>>>
>>>>>
>>>>> Your reply to him, where you said you would bring the issue to the
>>>>> TC, is here:
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00056.html
>>>>>
>>>>> This example shows exactly why I believe it is NECESSARY to add
>>>>> the clarifying text that I have been talking about to section 3.2.
>>>>>
>>>>> It appears to me that this user has been clearly misled by the
>>>>> spec to attempt to do what seems to me to be a wasteful and
>>>>> pointless exercise of parsing URIs and then trying to make sense
>>>>> of the collection of artifacts that he has produced. It appears to
>>>>> me that this is totally unnecessary, and I would suggest that it
>>>>> has been a waste of his time for being led down this path by the
>>>>> specifications, which is the point I have repeatedly been making
>>>>> that the specs are insufficient in section 3.2 in this regard .
>>>>>
>>>>> I am concerned that instead of addressing this type of problem
>>>>> with the capabilities currently in the spec, that we are being
>>>>> drawn down a path, which will effectively dismantle the perfectly
>>>>> good functionality that is in the spec by removing the URI
>>>>> capability as it currently exists.
>>>>>
>>>>> I think this user should be told that since his nodes are
>>>>> currently identified by URIs that are in the form called for in
>>>>> section 2.2 that he does not need to worry about collecting
>>>>> ancestors etc. and all he needs to do is apply the XACML 2.0
>>>>> anyURI-regexp-match as described in section A.3.13 of the core
>>>>> spec and his problem is solved.
>>>>>
>>>>> As described in section 4.3 of the example doc in the archive
>>>>> (http://www.oasis-open.org/committees/download.php/7315/xacml-profile-hierarchical-resources-nonXML-1.0-draft01.pdf),
>>>>> this function is simply specified as:
>>>>> <Apply FunctionId="&anyURI-regexp-match;">
>>>>> <AttributeValue DataType="&string;"
>>>>> >http://example.com/path/*</AttributeValue>
>>>>> <Apply FunctionId="&string-one-and-only;">
>>>>> <ResourceAttributeDesignator AttributeId="&resource-id;"
>>>>> DataType="&string;">
>>>>> </Apply>
>>>>> </Apply>
>>>>>
>>>>> This is the kind of guidance I am recommending that we add to
>>>>> section 3.2 of the Hierarchical Profile.
>>>>>
>>>>> As I understand your email, an alternative suggestion to address
>>>>> this user situation is to recommend that the user parse his URIs
>>>>> into components, and that we change the spec to alter the
>>>>> currently defined URI capability (to no longer be a URI
>>>>> capability, with all the inherent capabilities of a URI) in order
>>>>> that the customer be able to do this?
>>>>>
>>>>> Let me further point out that I don't think there is any need to
>>>>> change the spec, because it already says in section 2 that governs
>>>>> 2.2 that:
>>>>>
>>>>> "The following sections describe RECOMMENDED representations for
>>>>> nodes in hierarchical resources. Alternative representations of
>>>>> nodes in a given resource are permitted so long as all Policy
>>>>> Administration Points and all Policy Enforcement Points that deal
>>>>> with that resource have contracted to use the alternative
>>>>> representation."
>>>>>
>>>>> Therefore, if for some reason we advise against using what appears
>>>>> to me to be an obvious standard capability described above with
>>>>> anyURI-regexp-match, and would like users instead to parse their
>>>>> URIs into components so that they can supply the components as a
>>>>> collection of ancestors, I believe we are still able to do this
>>>>> because the statement above appears to explicitly allows for
>>>>> nonURI representations, in which case we would not have to do
>>>>> anything to section 2.2.
>>>>>
>>>>> However, to be perfectly honest, I still see no advantage to
>>>>> applying the bulleted capability procedure of section 3.2 to nodes
>>>>> that are already identified by URIs.
>>>>>
>>>>> Comments welcome. I would really like to understand if there is a
>>>>> legitimate reason for not using the URIs as is and replacing them
>>>>> by collections of components.
>>>>>
>>>>> Thanks, Rich
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Erik Rissanen wrote:
>>>>>> All,
>>>>>>
>>>>>> I've been in a rush today, so I haven't followed every detail in
>>>>>> the discussion, but basically, here is how it appears to me:
>>>>>>
>>>>>> * The profile, as it stands today, does specify the limited URI
>>>>>> scheme which Rich describes. It says in section 2.2 that:
>>>>>>
>>>>>> --8<--
>>>>>> The <pathname> portion of the URI SHALL be of the form
>>>>>>
>>>>>> <root name> [ “/” <node name> ]*
>>>>>>
>>>>>> The sequence of <root name> and <node name> values SHALL
>>>>>> correspond to the individual hierarchical component names of
>>>>>> ancestors of the represented node along the path from a <root>
>>>>>> node to the represented node.
>>>>>> --8<--
>>>>>>
>>>>>> So it in fact says that the identifiers must consists of paths
>>>>>> with the names of the ancestors.
>>>>>>
>>>>>> * If I understand Daniel correctly, he says that each node should
>>>>>> be allowed to have a name which is entirely independent of the
>>>>>> other nodes in the hierarchy. Relations between the nodes are
>>>>>> maintained in a manner not specified by XACML and are expressed
>>>>>> in XACML Requests and policies in the form of the attributes
>>>>>> resource-parent, resource-ancestor, etc. I think that the more
>>>>>> general approach advocated by Daniel would be the correct way to
>>>>>> go, so I agree with him (and Seth I believe. :-))
>>>>>>
>>>>>> * I also think as suggested on the XACML comments/users list that
>>>>>> the data type of the node identifier should not be limited to
>>>>>> URIs only.
>>>>>>
>>>>>> But I would prefer to leave major changes to the hierarchical
>>>>>> profile out of the first batch of CD documents.
>>>>>>
>>>>>> Best regards,
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> Rich.Levinson wrote:
>>>>>>> Hi Daniel and TC,
>>>>>>>
>>>>>>> Hopefully, those who have followed the details of these emails
>>>>>>> recognize that each step in the sequence has advanced the
>>>>>>> discussion in a consistent manner and as a result we have done a
>>>>>>> fairly thorough job of mapping out the problem space that is
>>>>>>> under discussion. In any event I believe my comments in this
>>>>>>> email continue to advance the discussion in a worthwhile manner,
>>>>>>> and I think will describe the complete problem space as well as
>>>>>>> give a clear description of the options available, all of which
>>>>>>> offer full functionality.
>>>>>>>
>>>>>>> In the current phase, if I am not mistaken, it is a
>>>>>>> straight-forward matter to apply definitions to the distinct
>>>>>>> categories of problems and simply observe that we have two sets
>>>>>>> of tools which are equally effective at solving each category of
>>>>>>> problem, where
>>>>>>>
>>>>>>> * one set of tools (let's call it the "ancestor method") is
>>>>>>> most
>>>>>>> effective when one is dealing with resources where it is not
>>>>>>> possible or desirable to apply URIs as normative identifiers
>>>>>>> * a second set of tools (let's call it the "URI method")
>>>>>>> which is
>>>>>>> available when one is dealing with resources where URIs
>>>>>>> can be
>>>>>>> applied as normative identifiers, and the designers want
>>>>>>> to take
>>>>>>> advantage of the powerful features inherent in URI
>>>>>>> objects, esp
>>>>>>> when applied to hierarchical problems.
>>>>>>>
>>>>>>> Let me address Daniel's points below, then try to summarize the
>>>>>>> present state of the discussion:
>>>>>>>
>>>>>>> Daniel Engovatov wrote:
>>>>>>>>
>>>>>>>> On Feb 18, 2009, at 3:05 PM, Rich.Levinson wrote:
>>>>>>>>
>>>>>>>>> Daniel, Seth, Erik, and TC,
>>>>>>>>>
>>>>>>>>> If we stick to the generally accepted definition that an
>>>>>>>>> object in a hierarchy can have at most one parent, then a URI
>>>>>>>>> solves the problem without having to look beyond the URI itself
>>>>>>>>
>>>>>>>> It is NOT a generally accepted definition and we did not stick
>>>>>>>> to it on purpose.
>>>>>>>>
>>>>>>> Whether it is generally accepted or not is probably not
>>>>>>> important here, however, it is consistent with the structure of
>>>>>>> XML documents, such that when we are talking about a "single
>>>>>>> hierarchy" of nonXML resources that if we assert that this
>>>>>>> implies a structural relationship equivalent to the structural
>>>>>>> relationship of the nodes of a well-formed XML document, which
>>>>>>> is that each element can have at most one parent, and the top
>>>>>>> element or node has zero parents.
>>>>>>>
>>>>>>> This gives us a crisp unambiguous definition of the term
>>>>>>> "hierarchy" which can be applied both to the XML and nonXML
>>>>>>> resources, and it totally avoids trying to determine whether it
>>>>>>> is an "accepted" definition or not, since that property is no
>>>>>>> longer relevant.
>>>>>>>
>>>>>>> The point of this definition is to give us a conceptual
>>>>>>> framework within which to evaluate the two primary use cases of
>>>>>>> the DAG, which as will be explained are also clear and
>>>>>>> unambiguous well-defined use cases.
>>>>>>>>
>>>>>>>>> However, if we allow the hierarchies to break down and lose
>>>>>>>>> their inherent hierarchical properties, then more complicated
>>>>>>>>> approaches, such as going outside the initial request context
>>>>>>>>> to get more nodes, although still solvable w URIs as demo'd
>>>>>>>>> below, are needed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It is NOT "broken down"
>>>>>>> True, in an absolute sense nothing is "broken", however, what
>>>>>>> has happened is that we have allowed one class of DAG
>>>>>>> representation to be impacted in such a way that we have allowed
>>>>>>> it to become the second class of DAG representation because we
>>>>>>> did not clearly define the distinction and what was to be
>>>>>>> allowed and not allowed. This has nothing to with whether the
>>>>>>> ancestor or URI method is used. It has only to do with the
>>>>>>> relationships that are allowed to be represented when two
>>>>>>> resources are "connected" by virtue of their hierarchical
>>>>>>> relationship being established.
>>>>>>>
>>>>>>> Specifically, one has a choice of:
>>>>>>>
>>>>>>> 1. only allowing the relationship that is being established
>>>>>>> to be
>>>>>>> active. For example if my boss is assigned to be
>>>>>>> subordinate to
>>>>>>> a task force leader when a cross functional team is being set
>>>>>>> up, this case would say that has no impact on my relationship
>>>>>>> with the task force leader unless I am a member of the task
>>>>>>> force. i.e. the task force leader has control over my boss's
>>>>>>> resources to whatever degree is implied by the task force
>>>>>>> situation, however the task force leader has zero direct
>>>>>>> control
>>>>>>> over my resources as a result of this assignment. In this
>>>>>>> model,
>>>>>>> that direct control could be simply be established by either
>>>>>>> assigning me directly to the task force leader, or
>>>>>>> assigning me
>>>>>>> a second subordinate relationship to my boss in the
>>>>>>> context of
>>>>>>> the task force relationship.
>>>>>>> This is a clearly defined process, where there is no
>>>>>>> ambiguity
>>>>>>> about relationships between the resources. If you want the
>>>>>>> relationship, you explicitly establish it, if not, you don't.
>>>>>>>
>>>>>>> 2. the other choice is the exact opposite, namely allowing
>>>>>>> incidental relationships to be established simply because
>>>>>>> they
>>>>>>> connect to a node with direct relationships. To take an
>>>>>>> extreme
>>>>>>> light-spirited example, for the purpose of showing how
>>>>>>> "extraneous" relations are introduced, if the company CEO
>>>>>>> was a
>>>>>>> member of a company bowling team, where the captain of the
>>>>>>> bowling team happened to be a junior software engineer who
>>>>>>> just
>>>>>>> joined the company, then everyone in the company would
>>>>>>> suddenly
>>>>>>> have this junior engineer as their ancestor. Possibly this
>>>>>>> would
>>>>>>> be disallowed by acyclic graph rules, but a similar situation
>>>>>>> would occur if the VP of engineering was on a bowling team
>>>>>>> captained by the junior sales trainee, who would now be
>>>>>>> ancestor
>>>>>>> to everyone in engineering organization.
>>>>>>>
>>>>>>> Both methods are acceptable for assigning relationships, but one
>>>>>>> or the other may be more effective for one or another type of
>>>>>>> organization. Personally, I think most enterprise security
>>>>>>> departments would favor the first approach, because it appears
>>>>>>> to offer more direct control and less chance of unintended
>>>>>>> consequences resulting from the assignment of a direct
>>>>>>> relationship.
>>>>>>>
>>>>>>> However, either choice can be used with either the "ancestor
>>>>>>> method" or the "URI method". Which choice is made is a function
>>>>>>> of the node collecting algorithm that is used for policy
>>>>>>> evaluation. i.e. when you collect the parent nodes of the
>>>>>>> requested node,
>>>>>>>
>>>>>>> * choice 1 above means only collect those nodes to which the
>>>>>>> parent has a direct relationship with the requested node,
>>>>>>> * and choice 2 means collect all the nodes of choice 1 plus all
>>>>>>> other nodes where the parent has a hierarchical relationship
>>>>>>> that does not directly involve the requested node.
>>>>>>>
>>>>>>> These are the two primary use cases of the DAG, which were
>>>>>>> mentioned above. Which use case is chosen depends only on the
>>>>>>> node collection algorithm and not how the nodes are represented.
>>>>>>> i.e. parents and ancestors exist whether or not they are
>>>>>>> incorporated for handy access within a URI or not.
>>>>>>> When the URI can be used, the URI collection within the
>>>>>>> requested node itself contains all the nodes that will be
>>>>>>> collected with method 1 and there is no need to access any
>>>>>>> additional information.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Again, I am not trying to add or change any of the existing
>>>>>>>>> functionality,
>>>>>>>>
>>>>>>>> You are proposing an addition that is a subset of the more
>>>>>>>> general approach.
>>>>>>> Hopefully, the description above satisfactorily demonstrates
>>>>>>> that the URIs are simply a concrete mechanism to implement the
>>>>>>> general solution. It is also a mechanism that, if used
>>>>>>> effectively, appears to be much more efficient since all nodes
>>>>>>> that need to be collected in method 1 actually are already
>>>>>>> contained in the URI collection of the requested node.
>>>>>>> Therefore it is a concrete representation of the general
>>>>>>> approach, however it is a concrete representation that
>>>>>>> capitalizes on the fact that the object used to represent the
>>>>>>> node (the URI) has an equivalent structure to the spatial
>>>>>>> relationships of the nodes in the DAG that need to be collected
>>>>>>> in method 1, and so those nodes do not need to collected at all
>>>>>>> since they are already present.
>>>>>>> The same structural relationship exists in method 2, however,
>>>>>>> method 2 fans out so far so fast that collection outside the
>>>>>>> requested node will be required to fulfill the needs of method 2.
>>>>>>> It is functionally equivalent to the general approach, however,
>>>>>>> it has the advantage that a single URI contains the normative
>>>>>>> identity of all the required nodes for method 1 and some for
>>>>>>> method 2.
>>>>>>>>
>>>>>>>> I understand that you favor a different approach to this
>>>>>>>> problem. It may be worth our while to create a separate profile
>>>>>>>> for such an approach, but I do not see any reason to muddy the
>>>>>>>> existing one.
>>>>>>>>
>>>>>>> It should be clear from the above discussion that showing how
>>>>>>> URIs address the same problem is not a "different approach". It
>>>>>>> is the same approach, except the work required to collect the
>>>>>>> nodes is a lot less, and can be eliminated almost completely
>>>>>>> depending on what node collection strategy is chosen, method 1
>>>>>>> or method 2.
>>>>>>>
>>>>>>> Finally, it should be clear that the bulleted algorithms in
>>>>>>> section 3.2 of the spec represent a nonURI approach using a
>>>>>>> method 2 collection algorithm.
>>>>>>>
>>>>>>> Now that the problem is clearly defined, I expect it will take
>>>>>>> much fewer words than have been exchanged in these emails to
>>>>>>> explain the available options in section 3.2, which are:
>>>>>>>
>>>>>>> 1. method 1 node collection, URI method (all nodes required
>>>>>>> are in
>>>>>>> requested node)
>>>>>>> 2. method 1 node collection, ancestor method: (requested node
>>>>>>> has
>>>>>>> pointers to parents, but need to recursively navigate to
>>>>>>> parent
>>>>>>> to advance up the hierarchy, but does not navigate thru
>>>>>>> nodes of
>>>>>>> which the requested node is not a hierarchy member)
>>>>>>> 3. method 2 node collection, URI method (subset of nodes
>>>>>>> required
>>>>>>> are in requested node, the rest must be obtained by
>>>>>>> recursively
>>>>>>> navigating based on parent hierarchy nodes of which requested
>>>>>>> node is not a member)
>>>>>>> 4. method 2 node collection, ancestor method (this is the
>>>>>>> algorithm
>>>>>>> currently in section 3.2 bullets and need to recursively
>>>>>>> navigate thru all parent nodes regardless of whether
>>>>>>> requested
>>>>>>> node is a member of the hierarchy or not.)
>>>>>>>
>>>>>>> These 2 choices of node collection are implicit in the DAG
>>>>>>> problem definition and are not currently explained in the
>>>>>>> document and I believe need to be. i.e. a DAG is the result of a
>>>>>>> set of hierarchies (as defined above) being layed across a set
>>>>>>> of resources. i.e. it is the result of a set of explicit
>>>>>>> relations being applied between pairs of nodes. The "choice" is
>>>>>>> whether to retain the "history" of why those relations were
>>>>>>> applied (i.e. the direct relations) or not. If you don't then
>>>>>>> additional, indirect, extraneous relations automatically appear
>>>>>>> and there is no way distinguish between them and the direct
>>>>>>> relations, at least in the "general" or "ancestor" case. In the
>>>>>>> URI case, the direct and indirect relations are always present
>>>>>>> and may be used or not as a matter of choice.
>>>>>>>
>>>>>>> The choice of ancestor or URI method for node identification is
>>>>>>> simply whether URI "can" be used and whether URI is "desired" to
>>>>>>> be used. Functionally, URI will produce the same results.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Rich
>>>>>>>
>>>>>>>>
>>>>>>>> Daniel;
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]