RE: New Issue: wsaw:UsingAddressing as a policy assertion

I agree with all you say.  The other concern that I have is that
although wsaw:UsingAddressing appears to be appropriate for use as a
policy assertion, not having that scenario documented will discourage
that appropriate (and we believe beneficial) use.

IOW, if we had separate wsdl extension and policy assertion specs, there
would be calls for a profile to use only one of these mechanisms.  In
our view, there are long-term benefits in a policy assertion, although
there are short-term difficulties in defining just a policy assertion at
this time.

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Yalcinalp, Umit
> Sent: Friday, December 02, 2005 12:35 PM
> To: public-ws-addressing@w3.org
> Subject: RE: New Issue: wsaw:UsingAddressing as a policy assertion
> 
> 
> Apologies if you get this twice. Somehow the email will not appear in
> the archives.
> 
> -----Original Message-----
> From: Yalcinalp, Umit
> Sent: Friday, Dec 02, 2005 12:17 PM
> To: 'Jonathan Marsh'; public-ws-addressing@w3.org
> Subject: RE: New Issue: wsaw:UsingAddressing as a policy assertion
> 
> 
> 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > Jonathan Marsh
> > Sent: Thursday, Dec 01, 2005 5:15 PM
> > To: public-ws-addressing@w3.org
> > Subject: New Issue: wsaw:UsingAddressing as a policy assertion
> >
> >
> > The WSDL Binding specification defines both a WSDL extension
> > and a SOAP
> > module for indicating the use of WS-Addressing.  Other WS specs that
> > Microsoft is implementing such as WS-ReliableMessaging,
> > WS-AtomicTransactions, and the various security
> > specifications all rely
> > on policy assertions to indicate the use of their respective
features.
> > In the long term, we'd like to use policy assertions consistently to
> > represent all these SOAP extensions.
> >
> > As a result, Microsoft sees a need for a policy assertion indicating
> > WS-Addressing is in use.  Our preference is to use this marker as
the
> > primary flag rather than either the WSDL extension or the SOAP
module
> > even within our short-term products.
> >
> 
> > In other standards groups like the OASIS WS-RX TC, the policy
> > assertions
> > are developed alongside the spec, by the same experts and on the
same
> > timeline.  If we were starting WS-Addressing today, I believe we
would
> > push for a similar ownership regime within the WS-Addressing
> > WG, rather
> > than relying on external groups to define such policy assertions
after
> > the fact.
> 
> >
> > Ideally, we would like to see the wsaw:UsingAddressing
> > element converted
> > to a policy assertion rather than a WSDL extension.  The semantics
of
> > this assertion/extension should be virtually identical to
> > what we'd need
> > (although it's currently more complicated than we'd prefer),
> > describing
> > the engagement of Addressing, the setting of the action
> > values, and the
> > consequences on the MEPs.  The main change would be to explicitly
> > describe the element as a policy extension.  Some simplification
might
> > be obtained since the WS-Policy framework defines
> > wsp:Optional through a
> > mechanical transformation, reducing the amount of prose needed to
> > describe the optional behavior currently defined for
> > wsdl:required="false".
> 
> >
> > Secondarily, we'd like the use as a policy assertion sanctioned as
on
> > option in the spec alongside the WSDL extension.
> >
> 
> Jonathan,
> 
> I am trying to understand why you are positioning this as a mutually
> exclusive decision, WS-Policy assertions vs. WS-Addressing element
> extension and speaking of a need for a conversion.
> 
> As one of the editor's of the WS-RX tc, let me make the observation
that
> after all WS-Policy assertions are global elements. UsingAddressing
> element/Anonymous element (which we are currently discussing in the
wg)
> are elements as well. In my opinion, whether we call them
> UsingAddressing element vs. WSAddressingAssertion element does not
> really change the technical definition of these elements. It would be
a
> technical fallacy to  present them as two separate beasts. If the
> concern is the usage SOAP module, that is a separate debate in my
> opinion. Policy assertions for a specific domain are not defined
within
> the WS-Policy namespace, they are defined within a specific domain's
> namespace. We already have that with WS-Addressing.
> 
> Therefore, definition of these extensions can be easily used as Policy
> assertions. The only thing that is of concern is the expression of
> optionality as you have observed, but it seems to me that that could
be
> easily handled by careful editorial handling without derailing the
> timeline.
> 
> 
> 
> > We recognize this request poses some timeline challenges, in
> > developing
> > a version-neutral policy assertion prior to standardization of the
> > policy framework, but feel these issues are tractable.
> >
> 
> I feel that we should not position the task of the wg to define markup
> to indicate that WS-Addressing is engaged as a WS-Policy assertion vs
> WSDL extension. Then this boils down to whether your concern is more
> related to labelling the document where this element and its semantics
> is described as a WSDL binding document instead of a Policy assertion
> document. IMO, the contents would be pretty darn similar anyway,
> wouldn't they?
> 
> I have illustrated, and I am sure you are well knowledgeable in this
as
> well, that using the same elements as Policy assertions is NOT really
an
> issue here. Therefore, I am trying to understand what you are really
> asking the wg to consider at this point in concrete terms. Not define
> the markup or define the markup so that there is no conflict and there
> is potential to use it with WS-Policy? ...Change the slant of the WSDL
> binding document so it is interpreted as a WSAddressing Policy
Assertion
> document and its implications when attached to WSDL?
> 
> Thanks for the clarification in advance,
> 
> --umit
> 
> 
> 
> 
> 
> >
> >

Received on Monday, 5 December 2005 17:54:22 UTC