RE: Updated proposal for WS-Policy assertions

+1


________________________________

	From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
	Sent: Wednesday, Nov 15, 2006 6:21 AM
	To: Rogers, Tony
	Cc: Marc Hadley; public-ws-addressing@w3.org;
public-ws-addressing-request@w3.org; Yalcinalp, Umit
	Subject: RE: Updated proposal for WS-Policy assertions
	
	

	The way that WS-Policy works is that you can have an assertion
that means "you MUST do/use X" and you want to 
	make its use optional,  you can either offer two alternatives,
one with and one without that assertion, or you can use
wsp:Optional="true" 
	as a short-hand for a normalized policy that has both
alternatives, one with and one without that assertion. 
	
	Thus, an endpoint can either require its use or permit the other
endpoint to make a choice between the two alternatives. 
	
	In the case where you want to support clients that may not even
understand the assertion type, you can use the 
	wsp:Ignorable="true" attribute that we recently added to
WS-Policy 1.5 - Framework. This would allow the policy 
	consumer the option of omitting the assertion from the policy
intersection algorithm (when "lax" intersection mode is 
	engaged by that consumer). 
	
	The default behavior in policy intersection remains unchanged.
If the wsp:Ignorable attribute is omitted, then 
	everything remains the same. if the wsp:Ignorable attribute with
a value of "true" is specified, then the consumer 
	can choose to ignore it at its discretion. 
	
	Personally, I don't think that the semantics of the assertion
are different in either case (WSDL or Policy). What is different 
	is the framework/context in which it is used. 
	
	Just because the WSDL framework provides a wsdl:required="true"
to ensure that the consumer of the WSDL understands 
	the extension does not change the semantics of that extension
mean "you MAY use WS-Addressing". The assertion means 
	that you MUST use WS-Addressing, but the WSDL author can choose
to either permit the consumer to ignore that in the 
	case that it doesn't recognize the extension. 
	
	WS-Policy now has roughly the same semantic. You can have an
assertion that means "you MUST do X" and you can 
	either choose to use wsp:Optional or wsp:Ignorable. 
	
	If you want to have wsaw:UsingAddressing mean, "you MAY use
WS-Addressing", you can accord the same semantic 
	to a policy assertion. If you want to provide an assertion
parameter (either an attribute or a child element) that tweaks the 
	semantic of the assertion depending on the value (or presence)
of that parameter, then that is a domain-specific 
	aspect of that assertion and can be interpretted consistently
between both the policy assertion context and the WSDL 
	extension context. If you want to add a wsaw:mustUse attribute,
then it can apply in both contexts. 
	
	I guess I don't see a compelling reason why you need to have two
things when one will suffice. 
	
	Cheers, 
	
	Christopher Ferris
	STSM, Software Group Standards Strategy
	email: chrisfer@us.ibm.com
	blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
	phone: +1 508 377 9295 
	
	public-ws-addressing-request@w3.org wrote on 11/14/2006 09:24:40
PM:
	
	> 
	> 
	> My take (and I am NOT stating the official position of the
WS-A WG here)
	> is that we want to retain compatibility with those who have
implemented
	> WS-A already, so we continue with UsingAddressing in WSDL,
where the
	> presence of UsingAddressing means that WS-Addressing is
supported, but
	> not required. We add mustUnderstand to make it required (this
has the
	> advantage of being backwards compatible - if the other end
doesn't
	> understand UsingAddressing then they clearly won't support it.
	> 
	> The problem is that for Policy, an assertion that "I support
	> WS-Addressing but do not require it" cannot be readily
converted into "I
	> require WS-Addressing" by use of Policy constructs (there's no
	> "mustUnderstand" option). We could have said that the
UsingAddressing
	> assertion meant "I REQUIRE WS-Addressing", but then the
meaning of the
	> assertion and the WSDL marker would be different, even though
the name
	> was the same - that would be a BAD IDEA. So the assertion is
	> AddressingRequired, which can be converted to optional through
the use
	> of WS-Policy constructs.
	> 
	> In other words, the WSDL marker is optional, add a (WSDL
familiar)
	> construct to make it required; the Policy assertion is
required, add a
	> (Policy familiar) construct to make it optional.
	> 
	> Hence the position we have reached, where we use different
names,
	> because they are different meanings.
	> 
	> Does that explain that bit more clearly? (I'm not talking
about the
	> other assertions here - that's another discussion...).
	> 
	> As I said, this is my understanding of the situation - I'm
sure others
	> will chime in if I'm misrepresenting things :-)
	> 
	> Tony Rogers
	> tony.rogers@ca.com
	> 
	> -----Original Message-----
	> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
	> Sent: Wednesday, 15 November 2006 12:58
	> To: Rogers, Tony; Marc Hadley; public-ws-addressing@w3.org
	> Subject: RE: Updated proposal for WS-Policy assertions
	> 
	> Thanks Tony, but this does not answer my question. See below. 
	> 
	> As a policy wonk, I look at it and scratch my head. In my
opinion, you
	> could easily move wsaw:UsingAddressing as a policy assertion
with
	> wsp:optional if the capability was not required. However, if
the spec
	> does not explain this well and most importantly the
interaction between
	> the new assertions and the existing marker, it would not be
useful. 
	> 
	> For example, 
	> 
	> (a) should I be able to indicate the capability of addressing
	> independent of WSDL?
	> (b) If addressing is not enabled, should I be able to attach a
policy
	> expression with WS-A assertions on top? 
	> C)If my intersection algorithm understands the 3 policy
assertions, do I
	> still have to look at WSDL to make sense of the complete
picture?  
	> (d) How does WS-Policy intersection algorithm work depending
on how you
	> answer question 2? 
	> 
	> I am trying to answer these myself, so I do not think that the
fat lady
	> has started to sing yet although the necessary steps were made
in the
	> right direction. 
	> 
	> Cheers, 
	> 
	> --umit
	> 
	> 
	> > -----Original Message-----
	> > From: Rogers, Tony [mailto:Tony.Rogers@ca.com]
	> > Sent: Tuesday, Nov 14, 2006 5:51 PM
	> > To: Yalcinalp, Umit; Marc Hadley;
public-ws-addressing@w3.org
	> > Subject: RE: Updated proposal for WS-Policy assertions
	> > 
	> > 
	> > UsingAddressing will be used as a WSDL marker, but not as an

	> > assertion.
	> > That is because the semantics in WSDL are different from the
semantics
	> 
	> > in policy (this was discussed at length on the most recent 
	> > WS-Addressing call). Thus the assertion is
AddressingRequired, with 
	> > optionality conveyed by WS-Policy constructs - it is
straightforward 
	> > to interconvert between the WSDL marker and the Policy form,
but 
	> > neither is really suited for use in place of the other.
Giving them 
	> > different names helps make it clear that they are different
(albeit 
	> > related).
	> > 
	> > wsaw:Anonymous will be removed as an assertion, replaced by
two new 
	> > assertions (two options here). One of the reasons for the
removal is 
	> > the desire to avoid parameterised assertions, per WS-Policy.
	> > 
	> > Tony Rogers
	> > tony.rogers@ca.com
	> > 
	> > -----Original Message-----
	> > From: public-ws-addressing-request@w3.org
	> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
Yalcinalp, 
	> > Umit
	> > Sent: Wednesday, 15 November 2006 12:18
	> > To: Marc Hadley; public-ws-addressing@w3.org
	> > Subject: RE: Updated proposal for WS-Policy assertions
	> > 
	> > 
	> > What am I missing? Probably I am a bit out of sync, so
apologies in 
	> > advance for this question.
	> > 
	> > What is not clear to me regardless of the decision on
opt-in/opt-out 
	> > is that the relationship with the wsaw:UsingAddressing. The
other 
	> > aspect is more easily resolvable.
	> > 
	> > I did not see the marker being removed to be proposed. I did
not also 
	> > see whether the proposed new markers were children (nested
assertions)
	> 
	> > within the marker.
	> > 
	> > This is a very important aspect of assertion design. 
	> > 
	> > Marc/Dave? Could you clarify where you were heading with
respect to 
	> > the existing element in Section 3.1?
	> > 
	> > Is UsingAddressing become an assertion too? BTW, there is no
as stated
	> 
	> > to the use of UsingAddressing as an assertion, except
modifying the 
	> > @wsdl:required attribute . Thus it is very conceivable that
the 
	> > proposed
	> > 3 assertions will have to be clarified and used with the 
	> > wsaw:UsingAddressing anyway as Anonymous element was trying
to 
	> > attempt.
	> > 
	> > --umit
	> >  
	> > 
	> > > -----Original Message-----
	> > > From: public-ws-addressing-request@w3.org
	> > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
	> > Marc Hadley
	> > > Sent: Tuesday, Nov 14, 2006 5:55 AM
	> > > To: public-ws-addressing@w3.org List
	> > > Subject: Re: Updated proposal for WS-Policy assertions
	> > > 
	> > > In the examples, s/Replies/Responses/.
	> > > 
	> > > Marc.
	> > > 
	> > > On Nov 13, 2006, at 6:40 PM, Marc Hadley wrote:
	> > > 
	> > > > The first part of the proposal is to remove the current 
	> > > > wsaw:Anonymous WSDL marker. I think we might need to
tweak the 
	> > > > section describing the UsingAddressing marker to include
the 
	> > > > following text (modified to remove mentions of policy
and
	> > > > anonymous) from the section describing the
wsaw:Anonymous marker:
	> > > >
	> > > > "A WSDL-based service description that includes the 
	> > > > wsaw:UsingAddressing makes no assertion regarding a
	> > requirement or a
	> > 
	> > > > constraint in the use of the anonymous URI in EPRs
contained in 
	> > > > messages sent to the endpoint."
	> > > >
	> > > > The current text for UsingAddressing could be taken to
imply that 
	> > > > endpoints using it explicitly support anon and non-anon
addresses 
	> > > > but I think the intent is that UsingAddressing makes no
	> > > claim about
	> > > > the types of address supported.
	> > > >
	> > > > The second part of the proposal is to define three new
	> > > elements for
	> > > > use in WS-Policy.
	> > > >
	> > > > (i) <wsaw:AddressingRequired/> - the endpoint requires
WS- 
	> > > > Addressing, optionality can be conveyed using WS-Policy
	> > constructs.
	> > > >
	> > > > (ii) <wsaw:AnonymousResponses/> (a child element of
	> > > > <wsaw:AddressingRequired>) - the endpoint can send
replies
	> > > using WS-
	> > > > A anonymous; the endpoint can't send to anon if not
present.
	> > > >
	> > > > (iii) <wsaw:NonAnonymousResponses/> (a child element of
	> > > > <wsaw:AddressingRequired>) - the endpoint can send
replies using 
	> > > > other addresses; the endpoint can't send to other
	> > addresses if not
	> > > > present (unless some other assertion adds a class of
supported 
	> > > > addresses).
	> > > >
	> > > > Element (iii) is deliberately vague, its presence means
	> > that a non-
	> > > > anon address might work but doesn't constrain what such
	> > an address
	> > > > might look like - a receiver can still reject an address
that it 
	> > > > doesn't grok or that requires a binding it doesn't
	> > support. The WG
	> > > > decided against specifying things like available
response
	> > bindings
	> > > > so I think this is in line with that decision.
	> > > >
	> > > > Here are some examples:
	> > > >
	> > > > <wsp:Policy>
	> > > >   <wsaw:AddressingRequired>
	> > > >     <wsaw:AnonymousReplies/>
	> > > >   </wsaw:AddressingRequired>
	> > > > </wsp:Policy>
	> > > >
	> > > > Means that addressing is required and only anonymous
replies are 
	> > > > supported.
	> > > >
	> > > > <wsp:Policy>
	> > > >   <wsaw:AddressingRequired>
	> > > >     <wsaw:NonAnonymousReplies/>
	> > > >   </wsaw:AddressingRequired>
	> > > > </wsp:Policy>
	> > > >
	> > > > Means that addressing is required and only non-anonymous
	> > replies are
	> > 
	> > > > supported.
	> > > >
	> > > > <wsp:Policy>
	> > > >   <wsaw:AddressingRequired>
	> > > >     <wsaw:AnonymousReplies/>
	> > > >     <wsaw:NonAnonymousReplies/>
	> > > >   </wsaw:AddressingRequired>
	> > > > </wsp:Policy>
	> > > >
	> > > > Means that addressing is required and both anonymous and
	> > > non-anonymous
	> > > > replies are supported.
	> > > >
	> > > > <wsp:Policy>
	> > > >   <wsaw:AddressingRequired/>
	> > > > </wsp:Policy>
	> > > >
	> > > > Wouldn't be too useful for anything other than a one-way
message 
	> > > > since neither anonymous nor non-anonymouse replies are
supported.
	> > > >
	> > > > <wsp:Policy>
	> > > >   <wsaw:AddressingRequired>
	> > > >     <wsaw:AnonymousReplies/>
	> > > >     <wsfoo:AnonReplies/>
	> > > >   </wsaw:AddressingRequired>
	> > > > </wsp:Policy>
	> > > >
	> > > > Means that addressing is required and that anon replies
	> > as defined
	> > > > by WS-Addr or WS-Foo are supported.
	> > > >
	> > > > Marc.
	> > > >
	> > > > ---
	> > > > Marc Hadley <marc.hadley at sun.com> CTO Office, Sun
Microsystems.
	> > > >
	> > > >
	> > > 
	> > > ---
	> > > Marc Hadley <marc.hadley at sun.com> CTO Office, Sun
Microsystems.
	> > > 
	> > > 
	> > > 
	> > 
	> > 
	> > 
	> 
	>