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] 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; 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 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_expressi
on>  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
 "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 <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
<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
<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
> >
> > 
> >
> 
> 
> 
>