RE: Follow-up to Question on CR33

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 19:37:41 UTC