Re: [ebxml-msg] Comments on the 1.09 about Error Handling

[Doug Bunting <dougb62@yahoo.com>]

I'm in the midst of getting my many editorial comments together and don't
think I've got time to put words into enough of this.  I can make a few
relatively specific recommendations:

* Don't add the note I mentioned earlier and Shimamura-san inserted below.

* Use NotSupported to mean the MSH refuses to support a particular requested
feature (for example because it's not in the agreed-upon CPA).  That should
affect all CPA / instance differences such as line 819, 1408, 1630-1631,
1790-1791, 1899-1900, 2025 and 2049.

* Update the description of NotSupported to specifically include this
meaning ("at odds with the CPA").

** As an alternative to the two points above, could define a new error
meaning just "at odds with the CPA" but because a CPA shouldn't include
anything you don't support the difference should be moot.

* Leave Inconsistent alone -- meaning the instance is internally
inconsistent.

* Soften section 1.3.6 as I describe below (sorry, just in general terms).

* I've got some editorial comments on section 4.2.2.1.2.  In addition to
those, I'd recommend adding a new final sentence to the section recognising
OtherXML and Unknown as exceptions to this "MUST NOT" because they are so
general.  I still see problems with defining more specific error codes than
we've defined but am not sure how to describe letting people define such
codes.

** Separately, I'm recommending adding wildcard support to all ebXML SOAP
extension elements and those that can repeat, such as the Error element
(primarily because its a versioning mechanism we don't consistently
support).  This might be a good mechanism to point to for "subcode" support.
Implementers could define new elements that clarify specific classes of
inconsistencies (for example) or they could just define a new
foreign:SubCode element.

* Replace the third paragraph of B.2.4 with words recognising that SOAP
errors may come back synchronously (over HTTP) whether or not SyncReply was
true.  In fact, the words from the SOAP specification should mean soap:Fault
won't be returned asynchronously when using a synchronous communications
protocol.  Our choice in this paragraph contravenes SOAP, we should just
recognise the aspects of SOAP causing somewhat inconsistent "async over
sync" behaviour.  I'm not even sure it's inconsistent from our point of
view: SOAP is another communication protocol, like TCP/IP and we certainly
expect many TCP/IP failures to occur synchronously.

hope this helps,
    doug

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "Doug Bunting" <dougb62@yahoo.com>; <ebxml-msg@lists.oasis-open.org>
Sent: Thursday, 29 November 2001 15:21
Subject: RE: [ebxml-msg] Comments on the 1.09 about Error Handling


Doug, I agree.  Can you make specific recommendations for changes in the
spec?

On the Inconsistent vs. NotSupported, I see this as being a continually
evolving
problem.  Can we come up with one error which means both?

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Doug Bunting [mailto:dougb62@yahoo.com]
Sent: Thursday, November 29, 2001 3:16 PM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Comments on the 1.09 about Error Handling


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

----- Original Message -----
From: "SHIMAMURA Masayoshi" <shima.masa@jp.fujitsu.com>
To: <ebxml-msg@lists.oasis-open.org>
Sent: Thursday, 29 November 2001 01:25
Subject: [ebxml-msg] Comments on the 1.09 about Error Handling


Please add the note about SOAP Fault, Doug Bunting proposed. It is
important for interoperability.

> Date: Fri, 16 Nov 2001 10:24:08 -0500
> From: Christopher Ferris <chris.ferris@sun.com>
> Subject: Re: Fw: [ebxml-msg] Re: SOAP Fault location
> To: Doug Bunting <dougb62@yahoo.com>
> Cc: "ebXML Messaging (E-mail)" <ebxml-msg@lists.oasis-open.org>
> Message-id: <3BF52F98.9080007@sun.com>
>
> +1, we cannot mandate what happens at the SOAP processor level.
>
> Doug Bunting wrote:
>
>     How about a non-normative note:
>
>         Note: A SOAP Fault element on its own may not provide the
>         requesting MSH with the context necessary to identify the
>         message in error.  An MSH returning a SOAP Fault should include
>         ebXML MessageHeader and ErrorList SOAP extensions in the same
>         SOAP message.  This would be especially useful when the error is
>         returned asynchronously.
>
>     We can't require this because we can't mandate what errors are
>     caught by the SOAP processor prior to invocation of the ebXML
>     handler.
>
>     does this help?
>       doug


Regards,

--
SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
TEL:+81-45-476-4590(ext.7128-4241)  FAX:+81-45-476-4726(ext.7128-6783)
Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>