[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Multiple Decison Request Proposal
Hi Erik,
I am now a little confused. The only reason that Attribute gets added to
DecisionList is to disambiguate multiple instances of the same Category.
I thought you said in previous email that CorrelationId could not be
used for this purpose and that we needed to use IncludeInResult:
http://lists.oasis-open.org/archives/xacml/200901/msg00053.html
Thanks,
Rich
Erik Rissanen wrote:
> Hi again Rich,
>
> There is one more problem. Not all XACML data types have a defined
> equality function. So it wouldn't work in all cases.
>
> Regards,
> Erik
>
> Erik Rissanen wrote:
>> Hi Rich,
>>
>> I still think that a ID reference is simpler than digging up the
>> datatype, attribute id and possibly issues, and going through all the
>> attributes in the request section looking for nested elements
>> containing matches for all two/three values.
>>
>> Also it's more verbose, making it more difficult to read by humans
>> (for debugging, development, audit, etc) and means less data to move
>> around.
>>
>> Regards,
>> erik
>>
>> Rich.Levinson wrote:
>>> Hi Erik,
>>>
>>> I see your point. How about if we constructed ListReference as follows:
>>>
>>> 1. Normal single element in category case:
>>> * <ListReference Category="cat1"/>
>>> 2. Multiple element in category case:
>>> * <ListReference Category="cat2">
>>> <Attribute AttributeId="xxx" Issuer="yyy"
>>> DataType="datatype">
>>> <AttributeValue>zzz</AttributeValue>
>>> </Attribute>
>>> </ListReference>
>>>
>>> With this approach typical case would be just match Category.
>>> Multi-case would be match Category and contained Attribute w value.
>>> Then Attr would only be synthetic in the extreme case as described in:
>>> http://lists.oasis-open.org/archives/xacml/200901/msg00049.html
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>>
>>> Erik Rissanen wrote:
>>>> Hi Rich and all,
>>>>
>>>> This sounds good to me, except that I don't like the use of the
>>>> synthetic id as the reference in the decision list. This forces all
>>>> requests to contain synthetic ids, which I think are not needed in
>>>> most cases, and is also more difficult to parse for a pre-processor
>>>> since the id is more deeply nested.
>>>>
>>>> Regards,
>>>> Erik
>>>>
>>>> Rich.Levinson wrote:
>>>>> Hi Erik, Hal, and TC,
>>>>>
>>>>> There have been a lot of emails on this issue so far, but I think
>>>>> we are at the point where all the ambiguities and potential
>>>>> missing pieces have been accounted for, so I will try to summarize
>>>>> where I think the proposal currently stands.
>>>>>
>>>>> First of all here are some reference emails that have examples
>>>>> that show different aspects of the proposed solution:
>>>>>
>>>>> * example request with XPath (in Erik's most recent email
>>>>> (below))
>>>>> which is purported to return multiple nodes (an example
>>>>> response
>>>>> would be helpful to augment this:
>>>>> o
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00053.html
>>>>> * example request with decision lists (Hal's most recent email)
>>>>> (ignore the CorrelationId, because as Erik showed, it will not
>>>>> work w XPath)
>>>>> o
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00051.html
>>>>> * example request showing multiple <Attributes> elements having
>>>>> same @Category and using "synthetic attribute" with
>>>>> "...multiple-request:unique-id" (would be useful to have
>>>>> corresponding response showing returned "disambiguated"
>>>>> <Attributes> elements
>>>>> o
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00049.html
>>>>> * example response showing 5 distinct results, not using
>>>>> synthetic
>>>>> attribute, but using "...resource:resource-id" for Result
>>>>> correlation. (This shows the important concept that not only is
>>>>> the <Attribute> with the @IncludeInResult returned, but also
>>>>> its
>>>>> parent <Attributes> element with the @Category.)
>>>>> o
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00045.html
>>>>> * original example request w DecisionList and w follow-up minor
>>>>> correction
>>>>> o
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00015.html
>>>>> o
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00035.html
>>>>>
>>>>> Based on the analysis that has been done, I have a few
>>>>> recommendations that, at least to me, appear to be important
>>>>> enough to itemize as suggestions for the specifications.
>>>>>
>>>>> For the 3.0 Core spec:
>>>>>
>>>>> 1. It became inferentially apparent that a fundamental "rule" is
>>>>> that a Request context that is processed by the PDP must
>>>>> have at
>>>>> most 1 <Attributes> element with a specific Category. I
>>>>> recommend that this be explicitly stated in section 5.35 in the
>>>>> description of the <Attributes> [One to Many] element. What is
>>>>> there now is not unambiguous in this regard, and I recommend it
>>>>> be tightened up.
>>>>> 2. Similarly, I think explicit text should be in Section 5.37 for
>>>>> the Category [Required] description. i.e. specify that while
>>>>> multiple <Attributes> elements with the same Category are
>>>>> allowed in the Request element, that for the purpose of making
>>>>> an authorization decision, only one <Attributes> element per
>>>>> Category is allowed.
>>>>> 3. Section 5.39 under explanation of IncludeInResult [Default
>>>>> false] I recommend that when included in Result the Attribute
>>>>> will be parented by its <Attributes w @Category> element. Also
>>>>> if multiple <Attribute> elements within one Category are
>>>>> tagged,
>>>>> then they will share the parent.
>>>>> 4. Section 5.41 under explanation of <Attributes> element, I
>>>>> recommend that it be explicitly stated that there will be one
>>>>> <Attributes> element for each @Category in the Request that
>>>>> contained an @IncludeInResult.
>>>>>
>>>>> For the 3.0 Multi-Decision spec:
>>>>>
>>>>> 1. I recommend that at least for the multi-Attributes @Category
>>>>> mechanism that a clear explanation be included that without
>>>>> DecisionLists, that there is an inferential n-dimensional
>>>>> cross-product applied, where n is the number of @Categories
>>>>> that have multiple <Attributes> elements within the Request.
>>>>> So, for example if there are 3 Category attrs, say cat1, cat2,
>>>>> cat3 that occur in multiple <Attributes> elements, for example
>>>>> let's say there are 4 <Attributes> elements w cat1, 4 with
>>>>> cat2,
>>>>> and 3 w cat3, then there will inferentially be 4x4x3 = 48
>>>>> individual Requests generated to the PDP, each of which will
>>>>> have a Result element in the Response. It would also be worth
>>>>> noting that if there are additional single element Category
>>>>> attrs, say cat4, cat5, and cat6, that the <Attributes> element
>>>>> for each of those Category attrs will be evaluated in all 48
>>>>> decisions. i.e. all 48 decisions will be based on
>>>>> cat1,cat2,cat3,cat4,cat5,cat6, where 4,5,6 remain constant thru
>>>>> the process and 1,2,3 are incremented as if to visit every cell
>>>>> in a 4x4x3 3-dimensional matrix in this particular example.
>>>>> 2. I recommend that the DecisionLists mechanism be introduced
>>>>> as an
>>>>> augmentation to the n-dimesional matrix in 1 above. i.e. given
>>>>> the 48 decisions above, I think that DecisionLists can be used
>>>>> to pare down the list so that the full n-dimensional cross
>>>>> product does not get evaluated. i.e. The DecisionLists would
>>>>> override the inferential processing if they were present.
>>>>> * For example, if we really didn't want the 4x4 portion
>>>>> above but were really interested in 2 2x2 portions, there
>>>>> could be 2 DecisionLists up front that contained the
>>>>> following elements:
>>>>> o
>>>>> cat11,cat12,cat21,cat22,cat31,cat32,cat33,cat4,cat5,cat6
>>>>> o
>>>>> cat33,cat34,cat43,cat44,cat31,cat32,cat33,cat4,cat5,cat6
>>>>> * Each of the above DecisionLists would produce 2x2x3 = 12
>>>>> results for a total of 24 results.
>>>>> * i.e. the suggestion is that the presence of DecisionLists
>>>>> simply override the inferential multiple effect of the
>>>>> <Attributes> elements themselves and transfer the
>>>>> inferential effect to the multiple category instances w
>>>>> same category to within each list.
>>>>> * i.e. the presence of the DecisionLists would effectively
>>>>> say: regard the actual <Attributes> elements as a pool of
>>>>> referencable entities and process the request as if
>>>>> multiple Request elements had come in with <Attributes>
>>>>> elements listed in the DecisionList, and process
>>>>> inferentially on that basis. Everything would be returned
>>>>> in a single response.
>>>>> 3. The only lingering "annoyance" is that the DecisionLists
>>>>> address
>>>>> the <Attributes> elements by the xml:id, whereas within the
>>>>> inferential processing we need to reference for correlation
>>>>> purposes based on an internal IncludeInResult attribute.
>>>>> This is
>>>>> not a show-stopper of any sort, but it does appear that there
>>>>> are 2 mechanisms effectively used to identify the same
>>>>> <Attributes> element. A couple of considerations:
>>>>> * It would seem that xml:id for <Attributes> elements that
>>>>> only had a single instance is more than is needed since
>>>>> one could theoretically simply identify these single
>>>>> instance elements by identifying their Category value.
>>>>> * It seems that what's needed for the DecisionLists that
>>>>> are
>>>>> going to use multiple <Attributes> elements with the same
>>>>> Category is something within the <Attributes> element
>>>>> that
>>>>> distinguishes it from the other <Attributes> elements of
>>>>> the same Category. This seems to be deja vu all over
>>>>> again
>>>>> (sic) wrt the analysis that left us with the "synthetic
>>>>> attributes" as the ultimate decider for those cases where
>>>>> nothing else would work
>>>>>
>>>>> http://lists.oasis-open.org/archives/xacml/200901/msg00049.html
>>>>> * Therefore, I am tentatively suggesting that a usable
>>>>> alternative to URI,xml:id might be
>>>>> @Category.value(index),
>>>>> where "index" would be the value of a synthetic attribute
>>>>> within the <Attributes @Category> element with
>>>>> AttributeId="...multiple-request:unique-id".
>>>>>
>>>>> I believe everything above, is essentially pretty much identifying
>>>>> what has already been decided and putting it all in one place, at
>>>>> least wrt 3.0 Core spec, plus I think that comment 1 for
>>>>> multi-decision is simply stating what has already been agreed,
>>>>> comment 2 is some clarification on how DecisionLists could be
>>>>> viewed and used, and comment 3 admittedly is something "new" to
>>>>> address what appears to me to be a lingering "rough spot" in what
>>>>> has been decided so far.
>>>>>
>>>>> Comments and suggestions are welcome.
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>
>>>>> Erik Rissanen wrote:
>>>>>> Hi Hal,
>>>>>>
>>>>>> I just realized that the CorrelationId will not work, and we need
>>>>>> the IncludeInResult.
>>>>>>
>>>>>> The existing 2.0 multiple resource profile defines a few more
>>>>>> modes of multiple requests than multiple <Resource> elements. For
>>>>>> instance, it is possible to specify multiple request in the form
>>>>>> of an xpath expression on the <ResourceContent>, where each node
>>>>>> the xpath matches will generate an individual request. Like this
>>>>>> for instance:
>>>>>>
>>>>>> 2 <Request
>>>>>> 3 xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
>>>>>> 4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>>>>>> 5 xmlns:md="http://www.medico.com/schemas/record";
>>>>>> 6
>>>>>> xmlns:xacml-context="urn:oasis:names:tc:xacml:2.0:context:schema:os"
>>>>>> 7
>>>>>> xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os
>>>>>> 8 access_control-xacml-2.0-context-schema-os.xsd">
>>>>>> 9 <Subject>
>>>>>> 10 <Attribute
>>>>>> 11
>>>>>> AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
>>>>>> 12
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string";>
>>>>>> 13 <AttributeValue>Julius Hibbert</AttributeValue>
>>>>>> 14 </Attribute>
>>>>>> 15 </Subject>
>>>>>> 16 <Resource>
>>>>>> 17 <ResourceContent>
>>>>>> 18 <md:record>
>>>>>> 19 <md:patient_info>
>>>>>> 20 <md:name>Bart Simpson</md:name>
>>>>>> 21 <md:age>60</md:age>
>>>>>> 22 <md:sex>male</md:sex>
>>>>>> 23
>>>>>> <md:health_insurance>123456</md:health_insurance>
>>>>>> 24 </md:patient_info>
>>>>>> 25 <md:diagnosis_info>
>>>>>> 26 <md:diagnosis>
>>>>>> 27 <md:item type="primary">Gastric
>>>>>> Cancer</md:item>
>>>>>> 28 <md:item type="secondary">Hyper
>>>>>> tension</md:item>
>>>>>> 29 </md:diagnosis>
>>>>>> 30 <md:pathological_diagnosis>
>>>>>> 31 <md:diagnosis>
>>>>>> 32 <md:item type="primary">Well
>>>>>> differentiated adeno carcinoma</md:item>
>>>>>> 33 </md:diagnosis>
>>>>>> 34 <md:date>2000-10-05</md:date>
>>>>>> 35 <md:malignancy type="yes"/>
>>>>>> 36 </md:pathological_diagnosis>
>>>>>> 37 </md:diagnosis_info>
>>>>>> 38 </md:record>
>>>>>> 39 </ResourceContent>
>>>>>> 40 <Attribute\r
>>>>>> 41
>>>>>> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
>>>>>> 42
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string";>
>>>>>> 43
>>>>>> <AttributeValue>*[local-name()='Resource'][namespace-uri()='urn:oasis:names:tc:xacml:2.0:context:schema:os']/*[local-name()='ResourceContent'][namespace-uri()='urn:oasis:names:tc:xacml:2.0:context:schema:os']/*[local-name()='record'][namespace-uri()='http://www.medico.com/schemas/record']/*[local-name()='patient_info'][namespace-uri()='http://www.medico.com/schemas/record']/*[self::*[local-name()='name'][namespace-uri()='http://www.medico.com/schemas/record']
>>>>>> or
>>>>>> self::*[local-name()='age'][namespace-uri()='http://www.medico.com/schemas/record']]/descendant-or-self::node()</AttributeValue>
>>>>>>
>>>>>> 44 </Attribute>
>>>>>> 45 <Attribute
>>>>>> 46
>>>>>> AttributeId="urn:oasis:names:tc:xacml:1.0:resource:scope"
>>>>>> 47
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string";>
>>>>>> 48 <AttributeValue>XPath-expression</AttributeValue>
>>>>>> 49 </Attribute>
>>>>>> 50 </Resource>
>>>>>> 51 <Action>
>>>>>> 52 <Attribute
>>>>>> 53
>>>>>> AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
>>>>>> 54
>>>>>> DataType="http://www.w3.org/2001/XMLSchema#string";>
>>>>>> 55 <AttributeValue>read</AttributeValue>
>>>>>> 56 </Attribute>
>>>>>> 57 </Action><Environment/></Request>
>>>>>>
>>>>>> From this request there will be multiple results, but there is
>>>>>> only one <Resource> element. Each result will contain a specific
>>>>>> ResourceId XML attribute for correlation purposes.
>>>>>>
>>>>>> In the corresponding 3.0 multiple request, it will be necessary
>>>>>> to use the IncludeInResult since there are not multiple Attribute
>>>>>> elements, which could be used for correlation, even if they had a
>>>>>> CorrelationId.
>>>>>>
>>>>>> So I think we should drop the CorrelationId proposal, and if
>>>>>> necessary, people will have to use a synthetic XACML attribute
>>>>>> for correlation.
>>>>>>
>>>>>> Best regards,
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> Hal Lockhart wrote:
>>>>>>> As of today's meeting I believe we are down to deciding how to
>>>>>>> do correlation. The alternative previously proposed is to use
>>>>>>> the IncludeInResponse mechanism. This may involve submitting
>>>>>>> synthetic attributes, not referenced by policy, simply to
>>>>>>> correlate requests and decisions.
>>>>>>>
>>>>>>> The new idea (at least to me) is to move my previously proposed
>>>>>>> XML Attribute - CorrelationID - to the <Attributes> element
>>>>>>> instead of having it in the <DecisionList> element.
>>>>>>>
>>>>>>> This seems clearer to me, but others should express their
>>>>>>> opinions. The new scheme would look something like this:
>>>>>>>
>>>>>>> <Request>
>>>>>>>
>>>>>>> <DecisionLists>
>>>>>>>
>>>>>>> <DecisionList>
>>>>>>>
>>>>>>> <ListReference URI="Sub1"/>
>>>>>>>
>>>>>>> <ListReference URI="Env"/>
>>>>>>>
>>>>>>> <ListReference URI="Res1"/>
>>>>>>>
>>>>>>> <ListReference URI="Act1"/>
>>>>>>>
>>>>>>>
>>>>>>> </DecisionList>
>>>>>>>
>>>>>>>
>>>>>>> <DecisionList>
>>>>>>>
>>>>>>> <ListReference URI="Sub1"/>
>>>>>>>
>>>>>>> <ListReference URI="Sub2"/>
>>>>>>>
>>>>>>> <ListReference URI="Env"/>
>>>>>>>
>>>>>>> <ListReference URI="Res2"/>
>>>>>>>
>>>>>>> <ListReference URI="Act2"/>
>>>>>>>
>>>>>>> </DecisionList>
>>>>>>>
>>>>>>>
>>>>>>> <DecisionList>
>>>>>>>
>>>>>>> <ListReference URI="Sub3"/>
>>>>>>>
>>>>>>> <ListReference URI="Env"/>
>>>>>>>
>>>>>>> <ListReference URI="Res1"/>
>>>>>>>
>>>>>>> <ListReference URI="Act2"/>
>>>>>>>
>>>>>>> </DecisionList>
>>>>>>>
>>>>>>>
>>>>>>> <DecisionList ... >
>>>>>>> ...
>>>>>>>
>>>>>>> </DecisionList>
>>>>>>>
>>>>>>>
>>>>>>> </DecisionLists>
>>>>>>>
>>>>>>>
>>>>>>> <Attributes Category="Access_Subject" XML:Id="Sub1"
>>>>>>> CorrelationId="FirstSubject">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>> <Attributes Category="Intemediary_Subject" XML:Id="Sub2"
>>>>>>> CorrelationId="SecondSubject">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>>
>>>>>>> <Attributes Category="Intemediary_Subject" XML:Id="Sub3"
>>>>>>> CorrelationId="ThirdSubject">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>> <Attributes Category="Environment" XML:Id="Env">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>> <Attributes Category="Resource" XML:Id="Res1"
>>>>>>> CorrelationId="FirstResource">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>>
>>>>>>> <Attributes Category="Resource" XML:Id="Res2"
>>>>>>> CorrelationId="Secondresource">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>> <Attributes Category="Action" XML:Id="Act1"
>>>>>>> CorrelationId="FirstAction">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>> <Attributes Category="Action" XML:Id="Act2"
>>>>>>> CorrelationId="SecondAction">
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> <Attribute>
>>>>>>> ...
>>>>>>> </Attribute>
>>>>>>>
>>>>>>> </Attributes>
>>>>>>>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>> </Request>
>>>>>>>
>>>>>>>
>>>>>>> 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
>>
>>
>> ---------------------------------------------------------------------
>> 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]