RE: New LC Issue: Changes to wsaw:Anonymous

Jonathan

To clarify, you are suggesting 3 potential options in your original note 
(please correct if wrong):

1. Replace the Anonymous with 2 or 3 separate assertions (QNames).   The 
default value would be as present - full support for anonymous and 
non-anonymous.
2. Remove specification of anonymous altogether.  Once again, default 
value as present - full support for anonymous and non-anonymous.
3. Introduce a new value to Anonymous of 'unspecified' and use this as a 
default instead of full support for anonymous and non-anonymous.

Number 3 sounds like the semantically biggest change because it's 
introducing a new 'unspecified' value and then using this as the default.  
My gut feeling is that the default should always be 'full support' and we 
should provide a mechanism to narrow this support as required (e.g. to 
correspond to WCF features)?

thanks,
Katy



"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: public-ws-addressing-request@w3.org
07/04/2006 16:08

To
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
cc
<public-ws-addressing@w3.org>
Subject
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  ][  
http://spaces.msn.com/auburnmarshes  ]