RE: New LC Issue: Changes to wsaw:Anonymous

We're quickly locking down the minimum functionality necessary to ship.
Although two QNames (or three) provide the necessary primitives, it's
unlikely that we would be able to implement such an assertion in the
product at this point.  Hence my hesitance to ask!

 

Also, we're caught in a bit of a bind because we really want to expose
both UsingAddressing and eventually anonymous handling primarily as
WS-Policy assertions.  Yet it's hard to design for this sweet spot in
the WG given the current state of play of WS-Policy.  Some delay (which
won't impact our implementation) might allow us to define this
capability more directly in the fashion we'd eventually like it in.

 

________________________________

From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
Sent: Thursday, April 06, 2006 8:00 PM
To: Jonathan Marsh
Cc: public-ws-addressing@w3.org
Subject: RE: New LC Issue: Changes to wsaw:Anonymous

 

I need a clarification as I am not sure I followed all your reasoning
correctly. 

 

Why wouldn't two separate assertions (QNames) serve the purpose you
seek? i.e. Anonymous and NonAnonymous? You hint at that, but at the same
time propose that the functionality be removed completely. I fail to see
the need for this drastic measure. 

 

Wouldn't 2 QNames provide the composibility you want to achieve? If you
want to add more QNames, you are free to do so. 

 

Or is it one of the solutions you offer, such as ? 

 

-- Two QNames

-- Remove completely

-- Define "undefined" as default value

 

I am not sure what your proposal exactly is. 

 

Thanks. 

 

--umit

 

	 

	
________________________________


	From: public-ws-addressing-comments-request@w3.org
[mailto:public-ws-addressing-comments-request@w3.org] On Behalf Of
Jonathan Marsh
	Sent: Thursday, Apr 06, 2006 11:42 AM
	To: public-ws-addressing-comments@w3.org
	Subject: New LC Issue: Changes to wsaw:Anonymous

	Section 3.2: Anonymous Element.

	 

	wsaw:Anonymous does not correspond well with the features of
WCF.  Instead of providing a single SOAP binding that can be
parameterized at will to accept anonymous URIs, our implementation
provides separate SOAP bindings for anonymous and non-anonymous cases.
This makes direct support for the "optional" value impractical for us to
support during the CR testing phase.  For this reason we'd like to see
wsaw:Anonymous functionality deferred so it doesn't hold up the rest of
the specification.  However, the current design also places undesirable
limits on the evolution of anonymous handling in the future.

	 

	In general we are currently tending towards favoring sets of
composable assertions rather than a monolithic, though parameterized,
assertion or extension.  In WS-Policy generally, multiple assertions
with distinct QNames are preferably to a single assertion that uses
attributes and/or content to distinguish different cases. For example,
given two possible assertion designs;

	 

	1.         <A1/>

	<A2/>

	<A3/>

	 

	2.         <A Parameter='1' />

	<A Parameter='2' />

	<A Parameter='3' />

	 

	then design 1 would generally be preferred because it allows the
policy matching logic to provide more accurate matches between policies.
Anonymous handling currently feels more like design 2.

	 

	This results in a suboptimal expression of anonymous handling
when UsingAddressing appears as a policy assertion.  The lack of a
"ws-addressing engaged" primitive assertion prevents UsingAddressing
(used as a policy expression, a WSDL extension, or through the soap
module synonym) from composing well with other primitive (or composite)
extensions or assertions that govern the handling of anonymous.

	 

	For instance, we plan to develop and deploy policy assertions
which represent composite functionality, one aspect of which may be
constraints upon anonymous handling.  As far as WS-Addressing is
concerned, this represents out-of-band specification of
wsaw:Anonymous-like capability.  Unfortunately, the value space of
wsaw:Anonymous is not extensible, and forces one to make claims as to
the treatment of anonymous addresses.  Other assertions may contradict
the claims made in wsaw:Anonymous, impeding consistent and accurate
description and therefore interoperability.  Another bad effect of only
providing a composite design is that anonymous address handling cannot
be separately negotiated at runtime through trial and fault.

	 

	Because there is no way to say, "I'm using addressing, but
making no design-time claims here as to support for anonymous
addresses", wsaw:UsingAddressing is unsuitable as a universal mechanism
for engaging addressing.  Rather than a composite assertion covering
both engagement of WS-Addressing and anonymous handling, we'd prefer to
have composable primitives representing this orthogonal functionality.

	 

	We also note that some members of the WG have stated their
desire to use wsaw:Anonymous as a hint for code generation (sync,
async).  We don't think overloading anonymous is a good way to hint as
to how a programming model should be built, and would not support the
retention of wsaw:Anonymous solely for this purpose.

	 

	We therefore propose that wsaw:Anonymous be removed from this
spec and features to constrain anonymous or hint at programming models
be deferred to future specs.

	 

	Failing that, we ask that "unspecified" be added as a value for
wsaw:Anonymous, and that this value be treated as the default when no
wsaw:Anonymous element appears.  The addition of an "unspecified" value
enables the wsaw:UsingAddressing extension/assertion to act dually as a
primitive and composite assertion, and compose with other mechanisms of
indicating the handling of asynchronous messages as they are developed.


	 

	 [  Jonathan Marsh  ][  jmarsh@microsoft.com
<mailto:jmarsh@microsoft.com>   ][  http://spaces.msn.com/auburnmarshes
<http://spaces.msn.com/auburnmarshes>   ]