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

Re: Updated Table: wsaw:Anonymous Combinations

From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
Date: Mon, 14 Aug 2006 10:41:06 -0700
Message-ID: <44E0B5B2.5050201@oracle.com>
To: Arun Gupta <Arun.Gupta@Sun.COM>
CC: W3C WS-Addressing Public List <public-ws-addressing@w3.org>

Two comments inlined below.

-Anish
--

Arun Gupta wrote:
> Anish,
> 
> See in line ...
> 
> Anish Karmarkar wrote:
>> Arun,
>>
>> Thanks for generating this.
>>
>> Two comments:
>>
>> 1) We may have to update the table once we resolve issue CR32 which 
>> asks the question whether 'none' is ok when wsaw:Anonymous='required'.
> Do you want that to be mentioned in the table ?
> 

No.

>>
>> 2) The general principle that is being used is:
>> "If the receiver is going to generate a fault and FaultTo value is 
>> incorrect, then it may send the fault over the back-channel with the 
>> understanding that the sender may not receive or process this fault."
>>
>> but this rule is not used when faultTo='none', for example in 4E.
> Rule 3 already defines the meaning for none. Do you think this should be 
> explicitly mentioned as part of this rule as well ?
> 

Rule 3 defines what none means, which is fine.
But my issue is with the fact that when 'none' is used, rule 4 is not 
applied. 'none' should not be an exception to rule 4. Rule 4 should be 
used regardless of the value of FaultTo (when the value of FaultTo is 
incorrect per wsaw:Anonymous).
i.e. 4E would be the same as 1E.

> -Arun
> 
>>
>> -Anish
>> -- 
>>
>> Arun Gupta wrote:
>>> Attached is the updated set of rules and table based upon Anish's 
>>> recommendation. I've preserved the grey color of cells in the 
>>> original table [1] but updated the resolution.
>>>
>>> [1] 
>>> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/att-0001/anonymous-semantics.htm__charset_WINDOWS-1252 
>>>
>>>
>>> -Arun
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>   wsaw:Anonymous and ReplyTo/FaultTo Combinations
>>>
>>> *Purpose:*
>>>
>>> This document defines the behavior of an endpoint based upon the 
>>> combinations of ReplyTo/FaultTo EPRs in the message received and the 
>>> value of wsaw:Anonymous.
>>>
>>> *Rules:*
>>>
>>>    1. Columns A and B define a combination of ReplyTo and FaultTo
>>>       received at a receiver.
>>>    2. Each cell in columns D, E and F define outbound message flow from
>>>       receiver after the inbound message is processed.      3. "None" 
>>> URI is a special address whose semantics are defined in
>>>       WS-Addressing Core
>>>       <http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/#predefaddr>.
>>>    4. If the receiver is going to generate a fault and FaultTo value is
>>>       incorrect, then it may send the fault over the back-channel with
>>>       the understanding that the sender may not receive or process this
>>>       fault.
>>>
>>>  
>>>
>>>       *A*     *B*     *C*     *D*     *E*
>>> *ReplyTo*     *FaultTo*     *Anonymous=Optional*     
>>> *Anonymous=Required* *Anonymous=Prohibited*
>>> *1*     Anon     Not Specified     Normal or Fault response on 
>>> transport back channel.     Normal or Fault response on transport 
>>> back channel.     Generates a fault and may send the fault on 
>>> transport back channel.
>>> *2*     Anon     Anon     Normal or Fault response on transport back 
>>> channel. Normal or Fault response on transport back channel.     
>>> Generates a fault and may send the fault on transport back channel.
>>> *3*     Anon     Non-Anon     Normal response on transport back 
>>> channel, Fault response to FaultTo address.     Generates a fault and 
>>> may send the fault on transport back channel.     Generates a fault 
>>> and send Fault response to FaultTo address.
>>> *4*     Anon     None     Normal response on transport back channel, 
>>> Fault response is discarded.     Normal response on transport back 
>>> channel, Fault response is discarded.     Generates a fault and 
>>> discards it.
>>> *5*     Non-Anon     Not specified     Normal and Fault response to 
>>> ReplyTo address.     Generates a fault and may send the fault on 
>>> transport back channel.     Normal and Fault response to ReplyTo address
>>> *6*     Non-Anon     Anon     Normal response to ReplyTo address, 
>>> Fault response on transport back channel.     Generates a fault and 
>>> send Fault response on transport back channel.      Generates a fault 
>>> and may send the fault on transport back channel.
>>> *7*     Non-Anon     Non-Anon     Normal response to ReplyTo address, 
>>> Fault response to FaultTo address.     Generates a fault and may send 
>>> the fault on transport back channel.     Normal response to ReplyTo 
>>> address, Fault response to FaultTo address.
>>> *8*     Non-Anon     None     Normal response on transport back 
>>> channel, Fault response is discarded.     Generates a fault and 
>>> discards it.     Normal response to ReplyTo address, Fault response 
>>> is discarded.
>>> *9*     None     Not specified     Normal and Fault response are 
>>> discarded. Normal and Fault response are discarded.     Normal and 
>>> Fault response are discarded.
>>> *10*     None     Anon     Normal response is discarded, Fault 
>>> response sent on transport back channel.     Normal response is 
>>> discarded, Fault response sent on transport back channel.     
>>> Generates a fault and may send the fault on transport back channel.
>>> *11*     None     Non-Anon     Normal response is discarded, Fault 
>>> response sent to FaultTo address.     Generates a fault and may send 
>>> the fault on transport back channel.     Normal response is 
>>> discarded, Fault response sent to FaultTo address.
>>> *12*     None     None     Normal and Fault response are 
>>> discarded.     Normal and Fault response are discarded.     Normal 
>>> and Fault response are discarded.
>>>
>>>  
>>>
>>> Last Updated: /August 09, 2006 10:18 AM /
>>>
> 
Received on Monday, 14 August 2006 17:43:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:14 GMT