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

Re: wsaw:Anonymous combinations

From: Mark Little <mark.little@jboss.com>
Date: Thu, 3 Aug 2006 11:52:39 +0100
Message-Id: <B044A4F5-1AD8-4928-B9C5-14C57694A4DD@jboss.com>
Cc: Arun Gupta <Arun.Gupta@Sun.COM>, W3C WS-Addressing Public List <public-ws-addressing@w3.org>
To: Katy Warr <katy_warr@uk.ibm.com>
Katy, my preference would be to not simplify the table and keep  
things explicit in each cell. I suppose it is arguable, but I feel  
the explicit table (Arun's) is more readable.

Mark.


On 3 Aug 2006, at 10:34, Katy Warr wrote:

>
> Hi Arun
>
> I like the table too. :o)
> Is it possible to simplify though, according to the following rules?
>
> Column D: ANON REQ:
> If non-anonymous is not in replyTo of fault To: as column C
> else
> If a backchannel is available: InvalidAddressingHeader fault  on  
> back channel
> else
> else behaviour unspecified*
>
> Column E: ANON PROHIBITED:
> If anon is not in replyTo or fault to: as column C
> else
> If a non-anon endpoint is available for faults:   
> InvalidAddressingHeader fault to non-anon endpoint
> else
> else behaviour unspecified*
>
> *See Core section 3.4, (1) Bullet 2.
>
> This results in the table below.
>
> Thanks
> Katy
>
>
>  	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	As column C	Behaviour unspecified (non-anon channel  
> unavailable)
> 2	Anon	Anon	Normal or Fault response on transport back channel	As  
> column C	Behaviour unspecified (non-anon channel unavailable)
> 3	Anon	Non-Anon	Normal response on transport back channel, Fault  
> response to FaultTo address	InvalidAddressingHeader fault  on back  
> channel	InvalidAddressingHeader to non-anon URI
> 4	Anon	None	Normal response on transport back channel, discards the  
> Fault response 	As column C	Behaviour unspecified (non-anon channel  
> unavailable)
> 5	Non-Anon 	Not specified	Normal and Fault response to ReplyTo  
> address	 InvalidAddressingHeader fault  on back channel	As column C
> 6	Non-Anon 	Anon	Normal response to ReplyTo address, Fault response  
> on transport back channel	InvalidAddressingHeader fault  on back  
> channel	InvalidAddressingHeader to non-anon URI
> 7	Non-Anon 	Non-Anon	Normal response to ReplyTo address, Fault  
> response to FaultTo address	 InvalidAddressingHeader fault  on back  
> channel	As column C
> 8	Non-Anon 	None	Normal response to ReplyTo address, discards the  
> Fault response	Behaviour unspecified (backchannel not available)	As  
> column C
> 9	None	Not specified	Normal and Fault response are discarded	As  
> column C	As column C
> 10 	None	Anon	Normal response is discarded, Fault response sent on  
> transport back channel	As column C	Behviour unspecified (non-anon  
> channel unavailable)
> 11 	None	Non-Anon	Normal response is discarded, Fault response sent  
> to FaultTo address	Behaviour unspecified (backchannel not  
> available)	As column C
> 12 	None	None	Normal and Fault response are discarded	As column C	 
> As column C
>
>
> ----- Forwarded by Katy Warr/UK/IBM on 03/08/2006 10:30 -----
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> Sent by: public-ws-addressing-request@w3.org
> 03/08/2006 04:01
>
> To
> Arun Gupta <Arun.Gupta@Sun.COM>
> cc
> W3C WS-Addressing Public List <public-ws-addressing@w3.org>
> Subject
> Re: wsaw:Anonymous combinations
>
>
>
>
>
>
> Very nice table!
> -Anish
> --
>
> Arun Gupta wrote:
> > I've attached the table listing the combinations, and endpoint  
> behavior,
> > using different ReplyTo/FaultTo and wsaw:Anonymous values.
> >
> > Thanks,
> > -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 an endpoint.
> >    2. Each cell in columns D, E and F define outbound message  
> flow after
> >       the inbound message is processed at the endpoint.
> >          1. Some cells have two possible outcomes. The first option
> >             ignores the invalid EPR and a default value (ReplyTo if
> >             FaultTo is ignored, anonymous if ReplyTo is ignored) is
> >             used. The second option uses the intended EPR for the  
> message.
> >    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. Grey cells indicate undefined behavior in the spec or a  
> choice to
> >       be made between the two options.
> >
> >
> >
> >                    *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, uses ReplyTo but does not honor anonymous semantics and so is
> > unable to deliver it.
> > *2*                  Anon                  Anon                   
> Normal or Fault response on transport back channel
> > Normal or Fault response on transport back  
> channel                  Generates a fault,
> > uses FaultTo but does not honor anonymous semantics and so is  
> unable to
> > deliver it.
> > *3*                  Anon                  Non- 
> Anon                  Normal response on transport back channel, Fault
> > response to FaultTo address
> >
> >    1. Generates a fault, ignores FaultTo, defaults to ReplyTo and  
> send
> >       Fault response on transport back channel.
> >    2. Generates a fault but does not honor non-anon semantics and  
> so is
> >       unable to deliver it.
> >
> >                  Generates a fault and send Fault response to  
> FaultTo address.
> > *4*                  Anon                  None                   
> Normal response on transport back channel, discards the
> > Fault response                  Normal on transport back channel,  
> discards the Fault
> > response                  Generates a fault and discards it.
> > *5*                  Non-Anon                  Not  
> specified                  Normal and Fault response to ReplyTo  
> address
> >
> >    1. Generates a fault, ignores ReplyTo, defaults to ReplyTo and  
> send
> >       Fault response on transport back channel.
> >    2. Generates a fault, uses ReplyTo but does not honor non-anon
> >       semantics and so is unable to deliver it.
> >
> >                  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.
> >
> >    1. Generates a fault, ignores FaultTo, defaults to ReplyTo and  
> send
> >       fault to ReplyTo address.
> >    2. Generates a fault, uses FaultTo but does not honor anon  
> semantics
> >       and so is unable to deliver it.
> >
> > *7*                  Non-Anon                  Non- 
> Anon                  Normal response to ReplyTo address, Fault
> > response to FaultTo address
> >
> >    1. Generates a fault, ignores FaultTo and ReplyTo, defaults to
> >       FaultTo and send Fault response on transport back channel.
> >    2. Generates a fault, uses FaultTo but does not honor non-anon
> >       semantics and so is unable to deliver it.
> >
> >                  Normal response to ReplyTo address, Fault  
> response to FaultTo address
> > *8*                  Non-Anon                   
> None                  Normal response to ReplyTo address, discards the
> > Fault response                   Generates a fault and discards  
> it.                  Normal response to
> > ReplyTo address, discards the Fault response
> > *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
> >
> >    1. Generates a fault, ignores FaultTo, defaults to ReplyTo and
> >       discards it.
> >    2. Generates a fault, uses FaultTo but does not honor anon  
> semantics
> >       and so is unable to deliver it.
> >
> > *11*                  None                  Non- 
> Anon                  Normal response is discarded, Fault response  
> sent
> > to FaultTo address
> >
> >    1. Generates a fault, ignores FaultTo, defaults to ReplyTo and
> >       discards it.
> >    2. Generates a fault, uses FaultTo but does not honor non-anon
> >       semantics and so is unable to deliver it.
> >
> >                  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 02, 2006 02:28 PM /
> >
>
Received on Thursday, 3 August 2006 10:52:23 GMT

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