- From: Felix Sasaki <fsasaki@w3.org>
- Date: Fri, 01 Jun 2007 22:54:22 +0900
- To: Ashok Malhotra <ashok.malhotra@oracle.com>
- CC: Dale Moberg <dmoberg@us.axway.com>, Paul Cotton <paul.cotton@microsoft.com>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Ashok Malhotra wrote: > Felix: > Dale's note suggests changes to the framework document. If you do not like the words "outside the scope of this document" we can change to "not defined in this document". > I don't think that would change anything about my concern, see below "I think you can't do both at the same time: ...". Felix > All the best, Ashok > > >> -----Original Message----- >> From: Felix Sasaki [mailto:fsasaki@w3.org] >> Sent: Thursday, May 31, 2007 5:16 PM >> To: Dale Moberg >> Cc: Ashok Malhotra; Paul Cotton; public-ws-policy@w3.org >> Subject: RE: New issue on duplicate assertions of a single type in an >> alternative: 4583 >> >> I think you can't do both at the same time: Saying "outside the scope of >> this document", and "If ... multiple assertions have the same meaning". >> There is also no means to test the statement "fail to specify what >> repetition ... means", since it implies domain specific information. >> >> A question to Ashok: your last mail in this thread did not ask for a >> change in any document. Neither did your initial description of bug 4583. >> Could you make a concrete proposal, or do you think that is not necessary >> (anymore)? >> >> Thank you, >> >> Felix >> >> >>> A modest proposal that does not impact the current policy intersection >>> procedure (I hope) >>> >>> >>> >>> Was: >>> >>> >>> >>> Section 3.2: A policy alternative MAY contain multiple assertions of the >>> same type. Mechanisms for determining the aggregate behavior indicated >>> by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See >>> XML Schema Part 1 [XML Schema Structures]) content, if any) are specific >>> to the assertion type and are outside the scope of this document. >>> >>> Suggested: >>> >>> Section 3.2: A policy alternative MAY contain multiple assertions of the >>> same type. Mechanisms for determining the aggregate behavior indicated >>> by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See >>> XML Schema Part 1 [XML Schema Structures]) content, if any) are specific >>> to the assertion type and are outside the scope of this document. If >>> domain policy assertion language authors fail to specify what repetition >>> of a policy assertion type (without parameters or subpolicies!) within a >>> policy alternative means, then repetition is simply redundancy, and >>> multiple assertions of a policy type have the same meaning as a single >>> assertion of the type within the policy alternative. >>> >>> >>> >>> An advantage is that the guidelines can present simplified burdens on >>> domain policy assertion language authors; the instruction can be to >>> specify what repetition of a policy assertion of a type means only when >>> repetition does _not_ have the same meaning as a single assertion of the >>> type within the policy alternative. >>> >>> >>> >>> ________________________________ >>> >>> From: public-ws-policy-request@w3.org >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra >>> Sent: Thursday, May 31, 2007 2:38 PM >>> To: Paul Cotton >>> Cc: public-ws-policy@w3.org >>> Subject: RE: New issue on duplicate assertions of a single type in an >>> alternative: 4583 >>> >>> >>> >>> I looked at the Policy assertions defined by WS-SX, WS-TX and >>> WS-Addressing. None of these assertions have parameters. >>> >>> I also looked at WS-SecurityPolicy. Parameters do appear in some of >>> these assertions but, as yesterday's discussion on issue i134 indicates, >>> these are considered "additional information" and not considered part of >>> the semantics of the assertion. Thus, matching assertions with >>> different values of these parameters is ok. AFAIK, these parameters >>> seem to be in the nature of comments. >>> >>> >>> >>> The word on the street is that parameters should not be used to convey >>> useful information in an assertion because of the WS-Policy intersection >>> algorithm which ignores parameters. >>> >>> >>> >>> If parameters are not used in assertions then the duplicate assertions >>> in the intersected policy are identical and can be removed. >>> >>> All the best, Ashok >>> >>> ________________________________ >>> >>> From: public-ws-policy-request@w3.org >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Paul Cotton >>> Sent: Thursday, May 24, 2007 1:52 PM >>> To: Ashok Malhotra >>> Cc: public-ws-policy@w3.org >>> Subject: RE: New issue on duplicate assertions of a single type in an >>> alternative: 4583 >>> >>> >>> >>> >>>> The framework document indicates that duplicate instances of an >>>> >>> assertion type are allowed in a policy alternative. >>> >>> >>> >>> You are correct. This is covered by the following two pieces of text in >>> the CR Framework document [1]: >>> >>> >>> >>> Section 3.2: A policy alternative MAY contain multiple assertions of the >>> same type. Mechanisms for determining the aggregate behavior indicated >>> by the assertions (and their Post-Schema-Validation Infoset (PSVI) (See >>> XML Schema Part 1 [XML Schema Structures]) content, if any) are specific >>> to the assertion type and are outside the scope of this document. >>> >>> Section 4.5: See Section 3.2 Policy Alternative for mechanisms for >>> determining the aggregate behavior indicated by multiple assertions of >>> the same policy assertion type. >>> >>> In fact the Section 3.2 text was in the member submission version of >>> WS-Policy [2]. >>> >>> >>>> 1. Should duplicate instances of the same type be allowed in a policy >>>> >>> alternative before and after intersection. >>> >>> Yes. In fact if we want to carry out our Charter which indicates we >>> should be as backwards as compatible as possible [3], then I think we >>> need a very strong reason to change this text. >>> >>> >>>> 2. Do we need to add guidance re. removing duplicate assertions from an >>>> >>> alternative. >>> >>> Personally, I think the Section 3.2 text covers what the Framework needs >>> to say about duplicate assertions. >>> >>> >>>> 2. What is the default semantic re. the resulting behavior if there is >>>> >>> more than one instance of an assertion in an alternative. >>> >>> Section 3.2 says that the semantics for duplicate assertions are covered >>> by domain specific semantics. >>> >>> For example, during the WG F2F meeting you asked what a >>> WS-SecurityPolicy implementer should do if they encountered duplicate >>> EncryptedPart assertions in a policy. I believe this is handled by the >>> following text in SecurityPolicy just as suggested in the Ws-Policy >>> Framework text [4]: >>> >>> There MAY be multiple EncryptedParts assertions present. Multiple >>> EncryptedParts assertions present within a policy alternative are >>> equivalent to a single EncryptedParts assertion containing the union of >>> all specified message parts. Note that this assertion does not require >>> that a given part appear in a message, just that if such a part appears, >>> it requires confidentiality protection. >>> >>> I hope this helps. >>> >>> >>> >>> /paulc >>> >>> >>> >>> [1] http://www.w3.org/TR/2007/CR-ws-policy-20070330/ >>> >>> [2] http://www.w3.org/Submission/WS-Policy/#Policy_Alternative >>> >>> [3] http://www.w3.org/2006/04/ws-policy-charter.html >>> >>> [4] >>> http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/23821/ws >>> -securitypolicy-1.2-spec-cs.pdf >>> >>> Paul Cotton, Microsoft Canada >>> 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 >>> Tel: (613) 225-5445 Fax: (425) 936-7329 >>> mailto:Paul.Cotton@microsoft.com <mailto:Paul.Cotton@microsoft.com> >>> >>> >>> >>> ________________________________ >>> >>> From: public-ws-policy-request@w3.org >>> [mailto:public-ws-policy-request@w3.org] On Behalf Of Ashok Malhotra >>> Sent: May 24, 2007 3:01 PM >>> To: public-ws-policy@w3.org >>> Subject: New issue on duplicate assertions of a single type in an >>> alternative: 4583 >>> >>> >>> >>> The framework document indicates that duplicate instances of an >>> assertion type are allowed in a policy alternative. During yesterday's >>> and today's discussion a number of questions arose about this situation. >>> >>> 1. Should duplicate instances of the same type be allowed in a policy >>> alternative before and after intersection. >>> >>> 2. Do we need to add guidance re. removing duplicate assertions from an >>> alternative. >>> >>> 2. What is the default semantic re. the resulting behavior if there is >>> more than one instance of an assertion in an alternative. >>> >>> All the best, Ashok >>> >>> >>> >> > > >
Received on Friday, 1 June 2007 13:54:33 UTC