W3C home > Mailing lists > Public > xml-dist-app@w3.org > August 2001

issue #45 proposed resolution

From: Jacek Kopecky <jacek@idoox.com>
Date: Mon, 6 Aug 2001 19:23:58 +0200 (CEST)
To: <xml-dist-app@w3.org>
cc: David Fallside <fallside@us.ibm.com>
Message-ID: <Pine.LNX.4.33.0108061914400.20368-100000@mail.idoox.com>
 Hello,

 on behalf of the RPC task force I have this proposal on how to
resolve the issue #45 [1].

 The actual proposal is lower in this message, but first I'd like
to show how other RPC systems handle error states:

 ONC RPC [2] has a predefined set of fault codes, summarizable as
a) system error (like memory allocation failures)
b) target not found (program, version or procedure unavailable)
c) bad arguments (can't decode params)
d) authentication errors

 Please note that ONC RPC doesn't view application errors as RPC
faults, this is understandable in the context of this over a
decade old protocol modeled after local calls in languages
that didn't have exception handling.

 XML-RPC [3] has numeric fault codes whose meaning is
implementation-dependent. There has been criticism of this
because such an approach is bad for interoperability.

 SOAP has four fault codes, of which two could possibly be used
to signify RPC errors: Client and Server. SOAP allows extending
these fault codes by adding a identifier after a dot.

 In the proposal below I use the prefix soap-env: for the SOAP
Envelope namespace and the prefix rpc: for the new SOAP RPC
namespace.

--------- proposal begin

 1) A soap-env:Server fault SHOULD be generated when the server
cannot handle the message because of some temporary condition,
like when it is out of memory. This doesn't apply to temporary
conditions of the application, like database being down or a
record not present.
 [SHOULD because the server can lack the resources to even
generate a proper fault]

 2) An rpc:ProcedureNotPresent fault MUST be generated when the
server cannot find the procedure specified.

 3) An rpc:BadArguments fault MUST be generated when the server
cannot parse the arguments or when there is a mismatch between
what the server expects and what the client has sent.
 [This fault code doesn't cover the situation when the arguments
are encoded in a data encoding unknown to the server, it seems
that a specific soap-env:DataEncodingUnknown (just an idea) fault
should be generated in this case.]

 4) Either of the following two is true, a) is preferred:

  a) An rpc:Application fault is generated when the
application has failed for some reason.

  b) A successful response containing some application-dependent
indication of a fault is generated.
 [this 4a point allows for ONC-RPC-like handling of fault
conditions]

 In all these cases the <detail> and <faultstring> values would
depend on the implementation or could be specified by some
external document.

--------- proposal end

 This proposal aims to cover the most common situations while
remaining relatively simple. Comments very welcome and indeed
requested. 8-)

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x45
[2] http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/18xx/1831
[3] http://www.xml-rpc.org/spec
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0016.html
Received on Monday, 6 August 2001 13:24:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:03 GMT