RE: New LC Issue: Changes to wsaw:Anonymous

I think I would describe the options slightly differently.

 

1.	Replace Anonymous with 2 or more likely 3 separate (from a
conformance sense) assertions.  The default value when just using the
UsingAddressing assertion would make no design-time claims as to the
handling of anonymous.  We would likely support an AnonymousRequired
assertion in this release, less likely an AnonymousProhibited assertion
(we support this but not as an orthogonal option at this point), but
unlikely an AnonymousOptional assertion at this point.  AIUI out of the
box it requires separate endpoints to get optional support, and the
AnonymousOptional does not naturally span endpoints.
2.	Remove specification of anonymous altogether.  Make no
conformance statement that UsingAddressing necessarily implies full
support.
3.	Introduce a new value to Anonymous of "unspecified" as the
default.  Make sure one can use UsingAddressing without fully supporting
all values of wsaw:Anonymous.
4.	(From Anish).  Remove the default.  Lack of wsaw:Anonymous means
there are no claims about Anonymous support.

 

So, the essence of this issue is that, contrary to your gut feeling, we
need to make UsingAddressing orthogonal from Anonymous support so that
Anonymous can be specified separately, or left to run-time negotiation.

 

Our preference is (2), given our product schedule and the need for
interop testing, is to work towards the absolute minimum necessary and
get it done quickly.  Separating anonymous handling may also allow the
work to take a more explicit dependency on WS-Policy.  The other options
also seem workable in that they allow us to take a dependency on
UsingAddressing without support for wsaw:Anonymous, for which we will
have only limited non-standard capability.

 

________________________________

From: Katy Warr [mailto:katy_warr@uk.ibm.com] 
Sent: Monday, April 10, 2006 2:27 AM
To: Jonathan Marsh
Cc: public-ws-addressing@w3.org
Subject: 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
<mailto:jmarsh@microsoft.com>   ][  http://spaces.msn.com/auburnmarshes
<http://spaces.msn.com/auburnmarshes>   ]