Re: Are nested assertions part of the policy vocabulary?

see inline below

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>
>
no this means "only anonymousReplies" are allowed. This is a constraint. 
This does not intersect with "all replies allowed",
which is the meaning of the empty addressing assertion.

Tom
>
> 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.
>
> 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
>     > >
>     > >
>     > >
>     >
>     >
>     >
>     >
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Wednesday, 9 May 2007 14:07:42 UTC