- From: Felix Sasaki <fsasaki@w3.org>
- Date: Wed, 09 May 2007 13:47:18 +0900
- To: Ashok Malhotra <ashok.malhotra@oracle.com>
- CC: Daniel Roth <Daniel.Roth@microsoft.com>, Sergey Beryozkin <sergey.beryozkin@iona.com>, Bob Freund <bob@freunds.com>, Maryann Hondo <mhondo@us.ibm.com>, Anthony Nadalin <drsecure@us.ibm.com>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>, "public-ws-policy@w3.org" <public-ws-policy@w3.org>
Ashok Malhotra wrote: > > Hi Dan: > > You made a very important point that I want to highlight. You said: > > “In some cases a single message may specify both an anonymous ReplyTo > EPR and a non-anonymous FaultsTo EPR. To satisfy this scenario you > need to have some way of saying that addressing is fully supported > without qualifications.” > > By your final sentence I presume you are saying that > > <policy> > > <wsp:Addressing> > > <policy/> > > </wsp:Addressing> > > </policy> > > means that addressing is fully supported without qualifications. Is > this correct? If so, then the above policy should intersect > successfully with, for example: > > <policy> > > <wsp:Addressing> > > <policy> > > <wsp:AnonymousReplies/> > > <policy/> > > </wsp:Addressing> > > </policy> > > Do you agree? We understand that this is not what the spec says but > this seems to be the behavior that WS-Addressing folks want. > I don't think that they want that. As Monica wrote at http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0049.html : [[<wsp:Policy> <wsam:Addressing> <wsp:Policy/> </wsam:Addressing> </wsp:Policy> The wsam:Addressing policy assertion is inclusive - you can support WS-Addressing and the SOAP binding without qualification (not constraints on the support for either).]] This does not imply that this policy should intersect with what you gave as an example above, but just no constraints on support of WS-Addressing. Dan explained at http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0009.html the different roles of requesters and providers in this scenario, and the +1 from Bob at http://lists.w3.org/Archives/Public/public-ws-policy/2007May/0053.html looks to me that at least some addressing people are fine with that explanation. Felix > All the best, Ashok > > ------------------------------------------------------------------------ > > *From:* public-ws-addressing-request@w3.org > [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *Daniel Roth > *Sent:* Tuesday, May 08, 2007 1:26 PM > *To:* Sergey Beryozkin; Bob Freund; Ashok Malhotra; Maryann Hondo; > Anthony Nadalin > *Cc:* public-ws-addressing@w3.org; public-ws-policy@w3.org > *Subject:* RE: Are nested assertions part of the policy vocabulary? > > Hi Sergey, > > > According to [1] If the provider uses <Policy/> then it means this > provider will work with consumers using either anonymous or > non-anonymous WSA qualifications. > > > And yet, the requester saying, by using > <ws-addressing><Policy><AnonymousResponses/></Policy></ws-addressing>, > that it wishes a provider to support > > > <AnonymousResponses/> will fail to intersect with the provider using > <Policy/> which says that all types of responses are supported > > A client that requires a service that supports anonymous responses > will work with a service that supports all of addressing or just > anonymous responses. This means, the client should reflect that by > including both alternatives in its policy. The client policy with both > alternatives intersects with the service policy and is specifically > recommended in section 3.6.1 of the WS-Addressing Metadata spec. > > > I'd even say that the empty nested ws-adressing <Policy> should be > prohibited > > In some cases a single message may specify both an anonymous ReplyTo > EPR and a non-anonymous FaultsTo EPR. To satisfy this scenario you > need to have some way of saying that addressing is fully supported > without qualifications. > > I hope this helps. > > Daniel Roth > > *From:* Sergey Beryozkin [mailto:sergey.beryozkin@iona.com] > *Sent:* Tuesday, May 08, 2007 2:25 AM > *To:* Bob Freund; Daniel Roth; Ashok Malhotra; Maryann Hondo; Anthony > Nadalin > *Cc:* public-ws-addressing@w3.org; > public-ws-addressing-request@w3.org; public-ws-policy@w3.org; > public-ws-policy-request@w3.org > *Subject:* Re: Are nested assertions part of the policy vocabulary? > > Hi > > What confuses me is that it appears to be some inconsistency in the > definition of what the empty nested Policy means in the scope of > ws-addressing (see [1]), <ws-addressing><Policy/></ws-addressing> and > the fact that this nested <Policy> does not intersect with a more > qualified nested Policy such as > <ws-addressing><Policy><AnonymousResponses/></Policy></ws-addressing>. > > According to [1] If the provider uses <Policy/> then it means this > provider will work with consumers using either anonymous or > non-anonymous WSA qualifications. And yet, the requester saying, by > using > <ws-addressing><Policy><AnonymousResponses/></Policy></ws-addressing>, > that it wishes a provider to support <AnonymousResponses/> will fail > to intersect with the provider using <Policy/> which says that all > types of responses are supported... > > I think what this means is using an all inclusive <Policy> alternative > alone on the server is just not safe as it will cause compliant > clients (say those wishing a provider to support > <AnonymousResponses/>) to break...I'd even say that the empty nested > ws-adressing <Policy> should be prohibited...Just have two nested > policies, one allowing anonymous responses, another one allowing > non-anonymous ones...That way a provider supporting all types of > responses can list two alternatives and it will match all clients.... > > Thanks, Sergey > > [1] > _http://lists.w3.org/Archives/Public/public-ws-policy/2007Apr/att-0094/WSAddrPolicyAlgerntiveGprime.htm_ > > ----- Original Message ----- > > *From:* Bob Freund <mailto:bob@freunds.com> > > *To:* Daniel Roth <mailto:Daniel.Roth@microsoft.com> ; Ashok > Malhotra <mailto:ashok.malhotra@oracle.com> ; Maryann Hondo > <mailto:mhondo@us.ibm.com> ; Anthony Nadalin > <mailto:drsecure@us.ibm.com> > > *Cc:* public-ws-addressing@w3.org > <mailto:public-ws-addressing@w3.org> ; > public-ws-addressing-request@w3.org > <mailto:public-ws-addressing-request@w3.org> ; > public-ws-policy@w3.org <mailto:public-ws-policy@w3.org> ; > public-ws-policy-request@w3.org > <mailto:public-ws-policy-request@w3.org> > > *Sent:* Tuesday, May 08, 2007 12:22 AM > > *Subject:* RE: Are nested assertions part of the policy vocabulary? > > +1 > > From a plain reading of the WS-Policy intersection algorithm, > these policies indeed are not compatible per the WS-Policy 1.5 > framework CR spec. > > -bob > > *From:* public-ws-addressing-request@w3.org > <mailto:public-ws-addressing-request@w3.org> > [mailto:public-ws-addressing-request@w3.org] *On Behalf Of *Daniel > Roth > *Sent:* Tuesday, May 01, 2007 4:52 PM > *To:* Ashok Malhotra; Maryann Hondo; Anthony Nadalin > *Cc:* public-ws-addressing@w3.org > <mailto:public-ws-addressing@w3.org>; > public-ws-addressing-request@w3.org > <mailto:public-ws-addressing-request@w3.org>; > public-ws-policy@w3.org <mailto:public-ws-policy@w3.org>; > public-ws-policy-request@w3.org > <mailto:public-ws-policy-request@w3.org> > *Subject:* RE: Are nested assertions part of the policy vocabulary? > > Hi Ashok, > > These two policies do not intersect and we believe this is > verified in the test cases. If Policy 2 is the policy for a > requester then this intersection result may at first seem > incorrect, so let me explain: > > It is incumbent on the Addressing authors to specify the semantics > of the assertions. The Addressing assertion expresses a > requirement that WS-Addressing be used to exchange messages > without qualifications. The nested addressing assertions (which > indicate additional characteristics of the base WS-Addressing > assertion) qualify this semantic to say that either only > non-anonymous responses are supported or that only anonymous > responses are supported. In the WS-Addressing protocol it’s the > requester’s message that requests a specific kind of response – > anonymous, non-anonymous, or maybe even a mixture of the two. > > The thing to recognize is that if Policy 2 is a requester policy > then it is incomplete in that it is not acknowledging that the > base assertion also reflects support for anonymous responses. The > requester determines what response type should be used. So, a > client that needs non-anonymous responses will also work with a > service that supports all of addressing. The client’s policy > should reflect that it is compatible with an endpoint that > supports all of addressing by adding a second alternative. This > can be easily done using the Optional attribute as is shown in > section 3.1.6 in the WS-Addressing Metadata spec: > > <Policy><Addressing ><Policy><AnonymousResponses > wsp:Optional=”true” > </Policy></Addressing ></Policy> > > Note that if Policy 2 is a provider policy and Policy 1 is the > requester policy – where the requester wants unqualified support > for addressing, but the provider only supports a specific response > type – then there is no issue. These policies should not intersect > and they don’t. > > We hope this helps. > > Daniel Roth > > *From:* public-ws-policy-request@w3.org > [mailto:public-ws-policy-request@w3.org] *On Behalf Of *Ashok Malhotra > *Sent:* Thursday, April 19, 2007 12:33 PM > *To:* Maryann Hondo; Anthony Nadalin > *Cc:* public-ws-addressing@w3.org; > public-ws-addressing-request@w3.org; public-ws-policy@w3.org; > public-ws-policy-request@w3.org > *Subject:* RE: Are nested assertions part of the policy vocabulary? > > Hi Maryann: > > Perhaps I misunderstood. Let me rephrase my comments as questions. > > Since Policy 1 > > <Policy> > <ws-addressing> > <Policy/> > </ws-addressing> > </Policy> > was intended to mean that ALL options ( anonymous, non-anonymous) > are supported. > > And Policy 2 > > <Policy> > <ws-addressing> > <Policy> > <ws-addressing: Anonymous> > </Policy> > </ws-addressing> > </Policy> > was intended to mean that ONLY anonymous was supported. > > Should Policy 1 match Policy 2 in the intersection algorithm? > > All the best, Ashok > > ------------------------------------------------------------------------ > > *From:* public-ws-addressing-request@w3.org > [mailto:public-ws-addressing-request@w3.org] *On Behalf Of > *Maryann Hondo > *Sent:* Thursday, April 19, 2007 5:55 AM > *To:* Ashok Malhotra; Anthony Nadalin > *Cc:* Ashok Malhotra; public-ws-addressing@w3.org; > public-ws-addressing-request@w3.org; public-ws-policy@w3.org; > public-ws-policy-request@w3.org > *Subject:* RE: Are nested assertions part of the policy vocabulary? > > > Ashok, > I would like to clarify my comments. > > I was trying to say, that the WS-Addressing group seemed to be > trying to use nested assertions to indicate a "constraint". > My understanding of the semantics are the following: > <Policy> > <ws-addressing> > <Policy/> > </ws-addressing> > </Policy> > was intended to mean that ALL options ( anonymous, non-anonymous) > are supported. > > and > <Policy> > <ws-addressing> > <Policy> > <ws-addressing: Anonymous> > </Policy> > </ws-addressing> > </Policy> > was intended to mean that ONLY anonymous was supported. > > This to me, ths meant that the "intent" of the base assertion was > being "constrained" by the presence off a nested assertion > and that was ok if the working group understood the semantics they > were expressing ( i.e. the "absence" of a nested assertion > means "no constraints" or "all options are supported") > > and I thought the language of the ws-policy spec allowed this > interpretation since a nested assertion could be seen to be > qualifying the base assertion with a constraint rather than a > capability. > > Authors MAY define that an assertion contains a policy expression > <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_expression> > (as defined in *4. Policy Expression* > <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#rPolicy_Expression>) > as one of its *[children]*. Nested policy expression(s) > <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#nested_policy_expression> > are used by authors to further qualify one or more specific > aspects of the original assertion. > > > The spec already says the following so I don't think alternative 1 > really adds anything, unless I'm missing something, like Tony, I > need more of an explanation of what you are suggesting you want > the intersection to do: > > Because the set of behaviors indicated by a policy alternative > <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_alternative> > depends on the domain-specific semantics of the collected > assertions, determining whether two policy alternatives are > compatible generally involves domain-specific processing. > > Maryann > > *Anthony Nadalin**/Austin/IBM@IBMUS* > Sent by: public-ws-addressing-request@w3.org > > 04/19/2007 03:41 AM > > > > To > > > > "Ashok Malhotra" <ashok.malhotra@oracle.com> > > cc > > > > "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>, > "public-ws-policy@w3.org" <public-ws-policy@w3.org>, > public-ws-policy-request@w3.org > > Subject > > > > RE: Are nested assertions part of the policy vocabulary? > > > > > > > #1 " dependent on the semantics of the parent assertion." not sure > what this would mean can you give some guidance here ? > #2 is real dangerous as you have no idea what you are matching on, > one day it could be XYZ and another day it could be ABC. > > Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 > Inactive hide details for "Ashok Malhotra" > <ashok.malhotra@oracle.com>"Ashok Malhotra" > <ashok.malhotra@oracle.com> > > *"Ashok Malhotra" <ashok.malhotra@oracle.com>* > Sent by: public-ws-policy-request@w3.org > > 04/16/2007 04:23 PM > > > > > To > > > > > "public-ws-policy@w3.org" <public-ws-policy@w3.org>, > "public-ws-addressing@w3.org" <public-ws-addressing@w3.org> > > > cc > > > > > Subject > > > > > RE: Are nested assertions part of the policy vocabulary? > > > > > > I’m at the OASIS Symposium and have had extensive discussions with > the WS-Addressing folks re. the problems they are having in using > WS-Policy to express their requirements. > > As I see it, the sticky usecase is where the provider wants to say > this it supports WS-Addressing in all its manifestations and the > requester specifies that it supports a particular variation of > WS-Addressing. These two policies must match. Thus, the provider says: > > <Policy> > <ws-addressing> > <Policy/> > </ws-addressing> > </Policy> > > And the requester says: > > <Policy> > <ws-addressing> > <Policy> > <ws-addressing-specific-assertions> > </Policy> > </ws-addressing> > </Policy> > > These two policies must match in the intersection algorithm. The > text that prevents them from matching says: > > “If either assertion contains a nested policy expression > <http://www.w3.org/TR/2007/CR-ws-policy-20070330/#policy_expression>, > the two assertions are compatible if they both have a nested > policy expression and the alternative in the nested policy > expression of one is compatible with the alternative in the nested > policy expression of the other.” > > In the note below (which Glen +1ed), Maryann suggests that a > Policy with just the <ws-addressing> assertion is expressing a > constraint which can be met in several ways – at least that’s how > I read her note. She does not, however, suggest concrete wording. > Here are a couple of suggestions: > 1. Change the quoted text above to say that matching of nested > policy assertions is dependent on the semantics of the parent > assertion. This way, WS-Addressing could define its own semantics > for matching and solving their usecase. > 2. Bob Freund suggested a wildcard assertion that could be > included within a nested Policy that would match any other nested > policy. > > All the best, Ashok > > ------------------------------------------------------------------------ > > > *From:* Maryann Hondo [mailto:mhondo@us.ibm.com] * > Sent:* Wednesday, April 04, 2007 7:37 AM* > To:* Glen Daniels* > Cc:* Ashok Malhotra; Monica J. Martin; public-ws-policy@w3.org; > public-ws-policy-request@w3.org* > Subject:* RE: Are nested assertions part of the policy vocabulary? > > > Glen, > I think the problem is that the assertions are really trying to > express a constraint .....and should be something > like "nonAnonymousONLY". so the absence, is not the absence of > support but rather the absence of the constraint. > > And in this case I think the " no constraints" is sufficient for > your use case > The client has no constraints on what the provider will do. > That should intersect with all the provider options. > > I hope we can talk this through on the call. > Maryann > > *"Glen Daniels" <gdaniels@progress.com>* > Sent by: public-ws-policy-request@w3.org > > 04/04/2007 09:59 AM > > > > To > > > > "Monica J. Martin" <Monica.Martin@Sun.COM>, "Ashok Malhotra" > <ashok.malhotra@oracle.com> > > cc > > > > <public-ws-policy@w3.org> > > Subject > > > > RE: Are nested assertions part of the policy vocabulary? > > > > > > > > Hi Monica: > > I'm a little confused here. Are you and MaryAnn indeed saying that > selecting the first alternative in Ashok's (and indeed > WS-Addressing's) > example means that neither anonymous nor non-anonymous responses are > allowed? That certainly isn't the goal of the policy, and indeed this > interpretation would seem to disallow ANY kind of response. > > How would you write a consumer policy which was meant to successfully > intersect with endpoint policies which either a) express nothing about > anonymous responses, b) express a requirement for anonymous responses, > or c) express a requirement for non-anonymous responses? > > --Glen > > > -----Original Message----- > > From: public-ws-policy-request@w3.org > > [mailto:public-ws-policy-request@w3.org] On Behalf Of Monica J. > Martin > > Sent: Tuesday, April 03, 2007 5:30 PM > > To: Ashok Malhotra > > Cc: public-ws-policy@w3.org > > Subject: Re: Are nested assertions part of the policy vocabulary? > > > > > > > > hondo: Ashok, > > My response is yes. > > Maryann > > > > >>mm1: Ashok, agree with MaryAnn on question one answer - this point > > has been made that the nested assertions are part of the policy > > vocabulary. Yet, an important point associated with this surrounds > > whether or not the guiding conformance [1] requires support for > those > > response types - that provides substance on your second > > question and its > > disposition.. [2] > > > > We also state in Section 3.2 Framework before the statement you cite: > > > > An alternative with zero assertions indicates no behaviors. An > > alternative with one or more assertions indicates > > behaviors implied > > by those, and only those assertions. > > > > Remember: (no position just stating the action-result), we augmented > > this text in > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=3602 Issue 3602. > > > > [1] WS-A specification(s) referenced > > [2] Related to empty and the base assumptions of WS-Addressing. > > > > >Ashok Malhotra wrote: Section 3.2 of Framework says "When an > > assertion whose type is part of the policy's vocabulary is > > not included in a policy alternative, the policy alternative > > without the assertion type indicates that the assertion will > > not be applied in the context of the attached policy > > subject." Are nested assertions included in the policy's > > vocabulary? > > > > > >Consider the following example: > > > > > > <wsp:ExactlyOne> > > > <wsp:All> > > > <wsam:Addressing> <-- supports all response > > types --> Alternative 1 > > > <wsp:Policy> > > > </wsp:Policy> > > > </wsam:Addressing> > > > </wsp:All> > > > <wsp:All> > > > <wsam:Addressing> <-- requires Anonymous > > responses --> Alternative 2 > > > <wsp:Policy> > > > <AnonymousResponses /> > > > </wsp:Policy> > > > </wsam:Addressing> > > > </wsp:All> > > > <wsp:All> > > > <wsam:Addressing> <- requires nonAnonymous > > responses --> Alternative 3 > > > <wsp:Policy> > > > <NonAnonymousResponses /> > > > </wsp:Policy> > > > </wsam:Addressing> > > > </wsp:All> > > > </wsp:ExactlyOne> > > ></wsp:Policy> > > > > > >If Alternative 1 is selected, does this mean that neither > > Anonymous responses nor NonAnonymous responses are allowed as > > both are part of the policy vocabulary but not included in > > the alternative. > > > > > >All the best, Ashok > > > > > > > > > > > > > > > > > >
Received on Wednesday, 9 May 2007 04:47:29 UTC