W3C home > Mailing lists > Public > public-ws-addressing@w3.org > December 2005

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

From: <paul.downey@bt.com>
Date: Fri, 2 Dec 2005 10:38:50 -0000
Message-ID: <2A7793353757DB4392DF4DFBBC9522550276F096@I2KM11-UKBR.domain1.systemhost.net>
To: <jmarsh@microsoft.com>, <public-ws-addressing@w3.org>

This approach makes good sense given the momentum behind the 
WS-Policy set of languages, especially from vendors such as 
Microsoft, however:

- what in our specification prevents a service describing
a Web service in WSDL, and some other description, such as a
WS-Policy style document or extensions asserting that 
WS-Addressing is infact, required?

- why isn't a mapping from the lightweight wsaw: extensions 
into WS-Policy be sufficient for Microsoft's needs? After all,
it's my understanding that WS-Policy* which are being standardised,
are all domain specific languages which map into a common way 
of thinking. 

- The phrase "prior to standardization of the policy framework" 
worries me deeply. Is it desirable, or even possible for our 
W3C Recommendation to build upon, normatively referencing 
something which hasn't been standardised, and whose control 
and licensing isn't transparent and open? 

It would be helpful to point the WG at a specification for  
WS-Policy statements used by Microsoft to engage Addressing 
currently (I'm assuming such a thing exists). I'm assuming
you're considering submiting such a document to the 
Working Group?  

As said, I'm not adverse to this approach, and BT is very
interested in using an interoperable, standardised policy 
language ASAP [1]. I just need to better understand the 
reasons why Status Quo isn't good enough for WS-Addressing.



-----Original Message-----
From: public-ws-addressing-request@w3.org on behalf of Jonathan Marsh
Sent: Fri 12/2/2005 1:14 AM
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

Secondarily, we'd like the use as a policy assertion sanctioned as on
option in the spec alongside the WSDL extension.

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.
Received on Friday, 2 December 2005 10:39:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:12 UTC