Re: Action item - lc129

I agree. I like David's suggestion to that a fault "SHOULD" be sent back.


                      Anish Karmarkar                                                                                                   
                      <Anish.Karmarkar@        To:       Francisco Curbera/Watson/IBM@IBMUS                                             
            >              cc:,               
                                               Subject:  Re: Action item - lc129                                                        
                      04/24/2006 01:14                                                                                                  


How does this solve the interop problem?

Wouldn't' you need a 'MUST' for the fault (or at least a 'SHOULD' as
suggested by David?) along with a specified fault?


Francisco Curbera wrote:
> This is my take on expanding "option 4" in Jonathan's mail [1] ("Remove
> default. Lack of wsaw:Anonymous means there are no claims about Anonymous
> support."). I am not proposing here the changes necessary to fully
> incorporate a resolution of the issue, only proposing a clarification of
> the assumptions clients would be able to make when no wsaw:Anonymous
> element is present.
> "A WSDL or policy based service description that includes the
> wsaw:UsingAddressing but no a wsaw:Anonymous marker makes no assertion
> regarding a requirement or a constraint in the use of the anonymous URI
> EPRs contained in messages sent to the endpoint. In this cases, endpoint
> service descriptions SHOULD use additional metadata, such as WSDL
> or additional policy assertions, to indicate any requirements or
> restrictions on the use of the anonymous URI by clients. However, in the
> absence of additional metadata, clients of the endpoint MAY assume that
> service endpoint follows the behavior indicated by the 'optional' value
> the wsaw:Anonymous marker. An endpoint MAY send a fault back to the
> if a message received uses the anonymous URI in a way that is unsupported
> by the endpoint."
> [1].

Received on Monday, 24 April 2006 17:20:15 UTC