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

Re: wsaw:Anonymous combinations - another slight update

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Thu, 03 Aug 2006 10:16:57 -0400
To: Katy Warr <katy_warr@uk.ibm.com>
Cc: Arun Gupta <Arun.Gupta@Sun.COM>, W3C WS-Addressing Public List <public-ws-addressing@w3.org>
Message-id: <D104A7A2-B8D4-420E-A06D-237B8F899619@Sun.COM>
I think its worth keeping the two options in rows 10 and 11 even  
though the end result is essentially the same: the message is either  
delivered to None or can't be delivered. Once we solve the more  
interesting cases we can use the same logic to decide which choice to  
adopt.

Marc.

On Aug 3, 2006, at 5:57 AM, Katy Warr wrote:

>
> Arun
> David has pointed out that some of the 'behaviour unspecified'  
> cells are specified according to the none URI semantics.
> This makes the table (I've updated in green):
>   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 InvalidAddressingHeader fault discarded
> 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 InvalidAddressingHeader fault discarded 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 InvalidAddressingHeader fault  
> discarded
> 11 None Non-Anon Normal response is discarded, Fault response sent  
> to FaultTo address InvalidAddressingHeader fault discarded As column C
> 12 None None Normal and Fault response are discarded As column C As  
> column C
>
>
>
> Thanks
> Katy
>
> ----- Forwarded by Katy Warr/UK/IBM on 03/08/2006 10:48 -----
> Katy Warr/UK/IBM@IBMGB
> Sent by: public-ws-addressing-request@w3.org
> 03/08/2006 10:34
>
> To
> Arun Gupta <Arun.Gupta@Sun.COM>
> cc
> W3C WS-Addressing Public List <public-ws-addressing@w3.org>
> Subject
> Fw: wsaw:Anonymous combinations
>
>
>
>
>
>
> 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 /
> >

---
Marc Hadley <marc.hadley at sun.com>
Business Alliances, CTO Office, Sun Microsystems.




Received on Thursday, 3 August 2006 14:17:12 GMT

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