Re: ISSUE: Where do faults go?

If a wsa: header arrives mU=true, and I don't understand WSA, then,
well, I don't understand WSA.

So the question is what if I see a foo:SomeHeader mU=true, I don't
understand that, but I do understand WSA and there's a valid wsa:FaultTo?

In such a case, 2.4 of the SOAP 1.2 Messaging Framework says:

    Therefore, for every mandatory SOAP header block targeted to a node,
    that node MUST either process the header block or not process the
    SOAP message at all, and instead generate a fault (see *2.6
    Processing SOAP Messages*
    <http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#procsoapmsgs>
    and *5.4 SOAP Fault*
    <http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#soapfault>).

>From this I believe we have concluded that we can't use WSA information
-- as that would mean processing the SOAP message -- and instead have to
rely on whatever the binding would do without WSA.  For a SOAP
request-response MEP (regardless of how we got there), that would
generally mean use the response channel.  This is the same thing we
would get by defaulting to anonymous in WSA-land, but we get there
differently.  In a fire-and-forget case, this might generally mean
dropping the fault on the floor (or logging it, or whatever, but
generally not putting it on the wire).

To do anything different, it seems we would have to make a specific
exception to the usual SOAP processing model.  Presumably the usual
model is there for a reason.  For example, the not-understood foo:
header might say something important about disposition of faults in general.

At this point, it's probably more appropriate to look at this in the
context of the SOAP "one-way MEP".  The behavior in the request-response
case seems reasonable, and there's not much we can change here at this
point anyway.

Christopher B Ferris wrote:

>
> Dave,
>
> CIL below.
>
> 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 12:51:36 PM:
>
> > 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.
>
> por que? I can certainly appreciate that WS-A would not contradict SOAP
> but why do you claim that this is out of scope? I would have expected
> that
> the spec would be explicit in describing exactly how it composes with the
> SOAP processing model.
>
> > If there are no SOAP processing failures, then
> > 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.
> > If wsa:Action is present, even if it's mangled, or multiply present,
> > or whatever, WSA is engaged.
> > 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
> > >