Re: Follow-up to Question on CR33

I view the wsaw:Anonymous marker as a way to specify whether the service 
can send messages to a different place (at least in the soap/http case); 
i.e., does the service allow/require/disallow callback addresses for 
replies/faults or not. So, it is the description of the service's behavior.

Given this, I don't see how throwing this flag would circumvent the WSDL 
description. If the WSDL description describes the capabilities of the 
service, the presence of the flag on any old address will not change the 
service's capabilities.

I guess the question we should answer is: do we want ws-addr wsdl 
binding to be composable with WSRM. If not, then we can close this issue 
with no action and we are done. I thought we were trying to make our 
wsdl marker compatible with what WSRM wants to do. Which is quite 
useful. I should not have to change the wsdl because WSRM is enabled. 
When WSRM is enabled I just change the policy and I'm done. With the 
current state of specs (WSRM and WS-A), WSRM anon template is 
incompatible with wsaw:Anonymous. Either we say:

1) no change to wsaw:Anonymous
   a) wsrm defines its own WSDL marker and is incompatible with 
wsaw:Anonymous

   b) wsrm changes their anonymous template and uses refps or extensions 
or whatever -- which they did consider and reject. One question to 
consider in this regard is that ws-a 'anon' marker refers to the 
http-response of the *same* http connection. WSRM anon refers to the 
http-response of the same http connection + any http-backchannel that 
contains the same UUID value (as sent in the MakeConnection message).

2) change wsaw:Anonymous marker to accommodate wsrm anon template (one 
of the two proposals that have been sent on this ML).

I'm fine with either 1b or 2. 1a is quite bad for specifications that 
are meant to be composable.

-Anish
--

Jonathan Marsh wrote:
> Your examples highlight my concern.  WSDL extensions describing WS-A headers has morphed into a WS-A run-time extension (wsaw:isAnon) in order to make our description work.  This extension could take two forms: behavioral or merely descriptive.
> 
> If merely descriptive, wsaw:Anonymous would depend upon wsaw:isAnon in the message, while wsaw:isAnon has no utility outside enabling wsaw:Anonymous description.  This is a bit too circular for my tastes.  Our WSDL Binding should be describing WS-A Core, not describing artifacts it introduces itself.  It's also subject to abuse because I could throw this flag on any old address and use it to circumvent the WSDL description, even though the WS-A layer may still attempt to send the reply to the address (an unextended WS-A layer doesn't know it's supposed to use the backchannel).
> 
> If behavioral (e.g. the addressing layer understands the flag and uses it to send responses on the backchannel), it looks like a fundamental extension to WS-Addressing, which would impact interoperability if not flagged with an appropriate mustUnderstand-style mechanism - the closest available mechanism is I imagine an entirely new wsa namespace.
> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org [mailto:public-ws-addressing-request@w3.org] On Behalf Of Anish Karmarkar
> Sent: Thursday, September 21, 2006 4:13 PM
> To: Francisco Curbera
> Cc: Doug Davis; public-ws-addressing@w3.org
> Subject: Re: Follow-up to Question on CR33
> 
> 
> Paco,
> 
> During this week's call when we discussed the isAnon proposal, you
> expressed a doubt about whether WS-Addressing Core spec would have to
> change to incorporate the proposal. I believe that it doesn't. Here is why:
> 
> The WS-Addressing WSDL binding defines an extension element
> wsaw:Anonymous. The presence of this element and it's value places
> restriction on the MAPs wsa:ReplyTo and wsa:FaultTo. Currently the
> restriction is specified in terms of WSA anon. This has been extended to
> include WSA none (as a result of a recent issue resolution).
> 
> The isAnon proposal modifies this restriction to allow any value for the
> URI as long as it is explicitly marked as "anonymous" using the
> attribute wsaw:isAnon='true' (in addition to WSA anon and WSA none).
> 
> This provides the necessary framework for other specs to define their
> own 'anonymous' or 'none' address(es), as WSRX has, and be compatible
> with the wsaw:Anonymous marker. So, ReplyTo values:
> 
> <wsa:ReplyTo>
>    <wsa:Address wsaw:isAnon='true'>
> http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000
> 
>    </wsa:Address>
> <wsa:ReplyTo>
> 
> <wsa:ReplyTo>
>    <wsa:Address wsaw:isAnon='true'>
>      urn:unix:/dev/null
>    </wsa:Address>
> </wsa:ReplyTo>
> 
> <wsa:ReplyTo>
>    <wsa:Address wsaw:isAnon='true'>
>      http://auburnmarshes.spaces.live.com/anonymous/
>    </wsa:Address>
> </wsa:ReplyTo>
> 
> are compatible with <wsaw:Anonymous>required</wsaw:Anonymous> marker
> when the above ReplyTos are present in the request message. The first
> ReplyTo is defined by WS-ReliableMessaging. The second one is a
> fictitious URI for a unix-style 'none'. The third URL is a made up URL
> that Jonathan might invent for his special anonymous needs.
> 
> WS-Addressing Core defines the EPR structure including extensibility via
> attribute. That means it is acceptable for other specifications to add
> additional attributes to EPRs. The isAnon proposal does exactly that. It
> specifies an EPR extensibility attribute and what it means. It also
> connects this extensibility attribute to the wsaw:Anonymous element
> (both the wsaw:Anonymous and wsaw:isAnon are defined in the same spec).
> I don't see any reason for the Core spec to change to accept the isAnon
> proposal.
> 
> Comments?
> 
> -Anish
> --
> 
> Anish Karmarkar wrote:
>> Attached is a proposal for isAnon attribute.
>> It show the modifications necessary for section 3.2 of the wsdl binding.
>>
>> It does not make wsaw:Anonymous a policy assertion/parameter or split it
>> into three parameters/assertions. That would require additional changes.
>>
>> -Anish
>> --
>>
>> Anish Karmarkar wrote:
>>> One of the main objections I've heard about the previous proposal that
>>> Doug sent out was the fact that what is 'addressable' or not, is not
>>> defined in a machine verifiable way and certainly not defined by WSA.
>>>
>>> During the discussion within WSRM there was another solution that was
>>> proposed (I think by Gil) which I think would be more acceptable to
>>> the ornery (as characterized by Jonathan ;-) ) WSA WG.
>>>
>>> Introduce a new attribute called wsaw:isAnon whose type is boolean.
>>> This attribute can occur on wsa:Address as follows:
>>>
>>> <wsa:ReplyTo>
>>>   <wsa:Address wsaw:isAnon='true'>
>>>
>>> http://docs.oasis-open.org/wsrx/wsrm/200608/anonymous?id=550e8400-e29b-11d4-a716-446655440000
>>>
>>>   </wsa:Address>
>>> <wsa:ReplyTo>
>>>
>>> The semantics of wsaw:Anonymous='required' would mean that either the
>>> ReplyTo/FaultTo wsa:Address is wsa 'none', wsa 'anon' or any other
>>> value if the wsaw:isAnon='true'.
>>>
>>> This would allow the wsaw:Anonymous marker to be enforced
>>> unambiguously and without the requirement to understand some other
>>> specification that may define another "anonymous" URI.
>>>
>>> WSRM (or any other spec) now can define their own "anonymous" URI, as
>>> they already have, but add the requirement that any use of that URI
>>> requires the wsaw:isAnon='true' to be present.
>>>
>>> -Anish
>>> --
>>>
>

Received on Monday, 25 September 2006 18:52:31 UTC