Re: ISSUE: Where do faults go?

How we handle faults, according to the current Editor's draft (I
double-checked :-):

    * SOAP processing failures (e.g. mU), are out of scope as always.
    * If there are no SOAP processing failures, then
          o If wsa:Action is absent, we don't say what happens.  (We
            only state the converse).  If WSA isn't engaged, disposition
            is out of scope.  If it is, for whatever reason, see below.
          o If wsa:Action is present, even if it's mangled, or multiply
            present, or whatever, WSA is engaged.
          o If WSA is engaged
                + If wsa:FaultTo is absent, multiply present, or present
                  but invalid, [fault endpoint] will be empty. 
                  Otherwise it will have the given value.  I'm inferring
                  this, but I don't see what else one could infer. 
                  Perhaps we should state more sharply that getting two
                  of something you can only have one of leaves it undefined.
                + Likewise for wsa:ReplyTo.
                + And the rules in 3.4 of the core apply.  If [fault
                  endpoint] is empty, as it would be in Glen's case, we
                  revert to [reply endpoint].  If wsa:ReplyTo had been
                  missing, [reply endpoint] would be anon.  If
                  wsa:ReplyTo is also erroneous, [reply endpoint] is
                  /empty/ and behavior is undefined.

IMHO, this is good enough.  If both wsa:FaultTo and wsa:ReplyTo are
present and mucked up, we can't really guarantee your safety.  In any
case, the spec as it stands seems unambiguous, given that duplicating
wsa:FaultTo leaves [fault endpoint] undefined.  I can see cases where
the left hand might add one wsa:FaultTo and the right hand add another,
but this seems like a fairly basic failure in implementation that
shouldn't make its way into production.  Famous last words.

Working from a clean slate, I might want to handle this differently, but
at this stage I think we've done what we can.  As with other cases, we
might want to make a few editorial changes to clarify what's going on.


Christopher B Ferris wrote:

>
> Glen,
>
> I would put this in the same class as "where do SOAP mU faults get
> delivered". I believe that that
> should be a function of the binding, not of WS-A because it is pretty
> clear to me that in the face
> of a SOAP mU (or VersionMismatch) fault, that WS-A processing cannot
> be presumed to have
> been performed (per the SOAP1.2 spec anyway).
>
> Thus, I think that an endpoint that includes a non-anonymous [fault
> to] endpoint SHOULD expect
> that it MAY receive SOAP faults in a manner defined as the default for
> the relevant SOAP
> binding. In the case of the SOAP Req/Resp MEP and SOAP HTTP binding,
> that would be
> the anonymous endpoint.
>
> IMO, if a SOAP message contains WS-A headers that are inconsistent
> with the spec in any way
> that the generated fault SHOULD be sent to the endpoint identified by
> the relevant SOAP
> MEP/binding.
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> public-ws-addressing-request@w3.org wrote on 03/13/2006 10:51:09 AM:
>
> >
> > Hi folks:
> >
> > Sorry for the last-minute issue, but this just came up as a result of
> > testing....
> >
> > In the test suite, we have a test [1] for generating a fault when a
> > request message contains 2 <wsa:FaultTo> headers.  Imagine a message
> > like:
> >
> > <soap:Header>
> >  <wsa:FaultTo>
> >  
> > <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address
> > >
> >  </wsa:FaultTo>
> >  <wsa:FaultTo>
> >   <wsa:Address>http://some-other-address</wsa:Address>
> >  </wsa:FaultTo>
> >  ...
> > </soap:Header>
> >
> > The question is - where should the InvalidAddressingHeader fault go?  I
> > see three possible choices:
> >
> > 1) to the first <FaultTo>
> > 2) to the second <FaultTo>
> > 3) to the default (anonymous? see below)
> >
> > The test assumes that the fault will be delivered via the HTTP
> > backchannel, i.e. to anonymous.  But I can't find anything in the spec
> > that would constrain an implementation to do so - in other words, it
> > might be just as valid to try to send it to http://some-other-address.
> > Therefore either the test is wrong to make the assumption, or the spec
> > should be clarified.
> >
> > I do think that in the case where we cannot correctly convert SOAP
> > headers into an appropriate MAP, the value for that MAP should not be
> > set (and in this case would therefore default to anonymous) - perhaps
> > this is the intent, but we should really be explicit about this if
> > that's what we mean.
> >
> > Another question also arises - in the case where we have a problem
> > generating the [FaultTo] MAP from the headers, should the generated
> > fault be delivered to the [ReplyTo] address if there is one, or always
> > to anonymous?  I'd guess the former, but again we should make sure we're
> > clear and explicit about it.
> >
> > I'd propose we fix this by adding something like the following at the
> > end of the last paragraph in section 3.2: "In that case, any duplicated
> > headers MUST NOT be used to populate the appropriate MAPs - the MAPs
> > should be interpreted as if no such headers were present."  I *think*
> > this should do it, and since we're already clear about the lack of an
> > explicit FaultTo causing faults to go to ReplyTo, I think we're covered
> > there.
> >
> > I'd also like to add, for clarity, section headings for the last two
> > paragraphs of section 3.2:
> >
> > 3.2.1 Sending Messages
> >
> > 3.2.2 Receiving Messages
> >
> > Thanks,
> > --Glen
> >
> > [1] http://www.w3.org/2002/ws/addr/testsuite/testcases/#test1242
> >