- From: Felix Sasaki <fsasaki@w3.org>
- Date: Fri, 01 Jun 2007 11:14:21 +0900
- To: Dale Moberg <dmoberg@us.axway.com>
- CC: Ashok Malhotra <ashok.malhotra@oracle.com>, Paul Cotton <paul.cotton@microsoft.com>, public-ws-policy@w3.org
Dale Moberg wrote: > Response to Felix > > >>> 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". > > It is outside the framework scope to specify domain specific semantics > for repetition of policy assertions of a type in a policy alternative. > That remains true. This says what is the default interpretation of > repetition if domain specific authors fail to specify what repetition > [of policy assertions of a type that have no parameters or subpolicies] > means. [I wish we had a term like "simple policy assertion" to refer to > this class of policy assertions.] I don't see what is inconsistent about > having a default and also saying that it can be overridden. You will > need to fill that part in for me. > I am just saying that it is different than saying "this is out of scope" and IMO it reads contradictory. But other people might read it different. > > >>> There is also no means to test the statement "fail to specify what >>> repetition ... means", since it implies domain specific information. >>> > > There is also no means to test whether an application does the right > thing for repetition when a special domain meaning is specified. I am > not sure what you are driving at here or why you think this is a > difficulty. A framework may have some assertions (like definitions) that > are not testable. That does not mean that definitions (and other > informative ideas) do not belong in the framework. > my point was not mainly the testability, but the need for domain specific information. Again I think we cannot talk both on a framework-independent level *and* requiring domain-specific information. Felix > > 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 02:14:32 UTC