After long discussions with Cliff Collins about this note and later
re-reading the specification, I've come to the conclusion this note goes
beyond our purview. It attempts to recommend the behaviour of a SOAP
processor (possibly in a way that makes interoperability more difficult for
the sender). While a soap:Fault element has problems on its own (lack of
context in particular), we can't recommend MSH handling of a problem
detected by the SOAP processor. We should recognise an MSH is likely to be
implemented on top of a SOAP processor and leave it to the XMLp working
group to "fix" soap:Fault.
In our document, we should be removing requirements for the MSH to cause
soap:Fault handling. The mustUnderstand faults when a receiving MSH doesn't
support the Message Status or Ping/Pong services are particularly poor. We
should use ebXML error handling whenever the ebXML handler is successfully
invoked. That probably leaves out errors in the outermost envelope,
problems with other SOAP extensions and inability to dispatch to the ebXML
handler. Note: "errors in the outermost envelope" is not as comprehensive
as the requirement in section 1.3.6 that "all MIME errors" be reported using
soap:Fault. I'd soften that section to remind a sending MSH that the
receiving MSH might be layered on a compliant SOAP processor and thus it
should expect soap:Fault for some errors.
An example: The SOAP processor checks the outermost envelope and passes
things over to the handler for the ebXML-msh namespace. That handler does
additional unwinding of the (multipart) payload wrappers and encounters a
problem in that MIME information. The handler has the context to return an
ErrorList and MessageHeader. If it's required to return a soap:Fault (as it
is today), the sending MSH may learn only that there was some problem
because that element will be handled by the sending SOAP processor layer.
It doesn't really matter whether or not the MessageHeader and ErrorList
elements are returned along with the soap:Fault.
By the way, my other problem with the note below is that it seems to
recommend adding a soap:Fault to error messages that would otherwise contain
the useful MessageHeader and ErrorList elements, reducing their utility.
A few other problems with error handling:
* I have seen no discussion of the inconsistent error handling the document
requires (raised in my
http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00242.html email).
We need to choose between NotSupported and Inconsistent when we describe
errors such as rejecting a request for a signed acknowledgment. We also
need to describe these errors much better and make the distinction clear.
* Nobody has responded to my "More on errors" email
(http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00243.html) which
described how the current text prevents anyone adding private error codes.
* B.2.4 requires all SOAP:Fault errors to be returned separately from the
initial HTTP exchange if operating in an asynchronous mode. This goes
beyond our purview and impinges on the workings of the SOAP processor.
thanx,
doug