Re: Follow-up to Question on CR33

Are you suggesting an errata to ws-addr core and ws-addr soap binding / 
2nd edition?

-Anish
--

David Orchard wrote:
> Jonathan,
> 
> I do agree that the wsaw namespace is of concern for a message
> extension.
> 
> On first thought, why couldn't the isAnon be added to the wsa namespace?
> I think this is a backwards compatible change because:
> 1. any existing clients won't be sending any values that would be marked
> with isAnon, so they won't break any existing receivers
> 2. any eisting receivers that get an isAnon="true" will ALSO have to
> know about the new value, say a new RM spec.  So they are going to have
> to change anyways. 
> 
> Now, you could also do it as you say with a new SOAP header marked mU.
> This is what RM did as part of the security integration.  The similar
> thing would be to create a "isAnonTypeRequired" empty header block.  
> In that case, an existing receiver will return an mU fault, which is the
> desired behaviour.
> 
> Maybe I'm squinting a little to hard to find the no namespace change,
> but it seems plausible to me.
> 
> Cheers,
> Dave
> 
>> -----Original Message-----
>> From: public-ws-addressing-request@w3.org 
>> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>> Jonathan Marsh
>> Sent: Friday, September 22, 2006 2:57 PM
>> To: Anish Karmarkar; Francisco Curbera
>> Cc: Doug Davis; public-ws-addressing@w3.org
>> Subject: RE: Follow-up to Question on CR33
>>
>>
>> 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=550e8
>> 400-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-e29
>>>> b-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 20:01:07 UTC