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

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

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Mon, 5 Dec 2005 09:47:57 -0800
Message-ID: <37D0366A39A9044286B2783EB4C3C4E8E9C603@RED-MSG-10.redmond.corp.microsoft.com>
To: <paul.downey@bt.com>, <public-ws-addressing@w3.org>


> -----Original Message-----
> From: paul.downey@bt.com [mailto:paul.downey@bt.com]
> Sent: Friday, December 02, 2005 2:39 AM
> To: Jonathan Marsh; public-ws-addressing@w3.org
> Subject: RE: New Issue: wsaw:UsingAddressing as a policy assertion
> 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?

Nothing.  In fact there are theoretically infinite ways to describe the
engagement of Addressing, which makes the interop problem complex.

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

That is what I'm asking for, specified use of the wsaw: extensions as
policy assertions.  There's nothing that prevents one from using them as
such today, but there also is nothing that encourages vendors to interop
on such usage.  Today that's not such a problem, but it will be as time
goes on.

> - 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?

Clearly we can't have a normative reference, but I think it is possible
to describe the use generically enough that it could be used in various
policy framework versions.  I think it might be as simple as providing a
QName identifier for the spec as well as a URI.  (The QName
wsaw:UsingAddressing comes to mind. ;-)

> 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?

We haven't defined an assertion that engages the W3C version of

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

Our technical preference for this type of descriptive capability relies
on WS-Policy and its successors.  Many other standards groups are
describing the engagement of their SOAP headers using policy assertions,
for instance the specs in the WS-RX, WS-TX, and WS-SX OASIS TCs.  In
this company, having a WSDL extension for Addressing will stand out like
an iceberg in Miami, and complicate processing of complete capabilities
of a service.  Having a unified mechanism is beneficial from user
experience, interop, and implementation perspectives.

The problem I'm highlighting isn't simple, but the point it raises -
that the Recommendation track we're on is likely to be an interim
measure rather than a permanent solution - is I believe essential for
the WG to discuss.

> Paul
> http://www.w3.org/2004/09/ws-cc-program.html#tuesday
> -----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
> 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
> 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
> 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,
> than relying on external groups to define such policy assertions after
> the fact.
> Ideally, we would like to see the wsaw:UsingAddressing element
> to a policy assertion rather than a WSDL extension.  The semantics of
> this assertion/extension should be virtually identical to what we'd
> (although it's currently more complicated than we'd prefer),
> the engagement of Addressing, the setting of the action values, and
> 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
> 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.
> We recognize this request poses some timeline challenges, in
> a version-neutral policy assertion prior to standardization of the
> policy framework, but feel these issues are tractable.
Received on Monday, 5 December 2005 17:53:29 UTC

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