Re: ISSUE: Where do faults go?

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
> >