W3C home > Mailing lists > Public > public-ws-addressing@w3.org > September 2006

RE: Follow-up to Question on CR33

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Fri, 22 Sep 2006 14:57:24 -0700
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>, Francisco Curbera <curbera@us.ibm.com>
CC: Doug Davis <dug@us.ibm.com>, "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-ID: <1C40239E22E8594DA37395602FC7362F18FA673C@NA-EXMSG-C112.redmond.corp.microsoft.com>

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


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:Address wsaw:isAnon='true'>


   <wsa:Address wsaw:isAnon='true'>

   <wsa:Address wsaw:isAnon='true'>

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



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 Friday, 22 September 2006 21:57:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:14 UTC