RE: Are nested assertions part of the policy vocabulary?

The WS-Policy Spec simply defines a way to express and compare
(intersect, gosh I dislike that term) sets of metadata. It may imply a
bunch of other stuff, but I think that to the extent that it does it
oversteps.

It is mandatory that the adjunct specs which define assertions for a
particular protocol  define which behaviors are intended in conjunction
with the underlying protocol spec.

I might have preferred that WS-Policy define a wildcard policy
expression for readability, but it doesn't matter that much IMO since an
empty policy is a policy none the less and optional="true" reduces the
verbosity somewhat.  

How does one express "default" behavior?  Well, one way is to define an
assertion that connotes default, another is to express nothing which
might also connote default behavior.  

I really feel that it needs be up to the protocol writers to define what
that default behavior is and it cannot be subject to absence = negation
rules.  I think that if nothing is expressed, nothing is expressed and
nothing more.

To the absence equals negation faction, the absence of the default
assertion, should it be defined, means what?

Must there be an empty compatible policy for default behavior to be
exhibited?

I think not, since just because policy exists, it will be tough to
require policy at least foe awhile.  Protocol authors and implementers
will find it necessary to work with clients or servers that might be
policy naive.   We still are forced to define a fault mechanism and not
only for this.

The less that WS-Policy says about behavior, the better. Let it do the
simple and needed job of defining what a policy looks like and how they
might be compared in an optional application independent manner.

 

-bob

 

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Sergey
Beryozkin
Sent: Wednesday, May 09, 2007 4:40 AM
To: 'Daniel Roth'; 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 Dan

 

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

 

This is the point I've missed. It's the fact that a *single* message may
specify both types which makes an empty <Policy> expression a useful
alternative.

IMHO, highlighting it in the wsa-addressing policy profile would help.
Otherwise it's very tempting to use an empty <Policy> expression alone
to meet different client's

requirements for a more qualified support...

 

Thanks for the explanation

Sergey 

 

 

 

________________________________

From: Daniel Roth [mailto:Daniel.Roth@microsoft.com] 
Sent: 08 May 2007 21:26
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/WS
AddrPolicyAlgerntiveGprime.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 ; 
public-ws-addressing-request@w3.org ; public-ws-policy@w3.org ; 
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] 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
	> >
	> > 
	> >
	> 
	> 
	> 
	>