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 Thursday, 21 September 2006 23:13:55 UTC