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