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

RPCTF: issue #45

From: Jacek Kopecky <jacek@idoox.com>
Date: Thu, 2 Aug 2001 15:38:14 +0200 (CEST)
To: <xml-dist-app@w3.org>
cc: <soapbuilders@yahoogroups.com>
Message-ID: <Pine.LNX.4.33.0108011735570.3356-100000@mail.idoox.com>
 Hello,

 on the RPC task force's telcon I agreed to post a summary
on how I would resolve the issue #45 [1].

 Folks on soapbuilders, please respond directly to
xml-dist-app@w3.org to minimize the crossposting.

 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, but for my
opinion on this please see my mail [4].

 My proposal for resolving the issue #45 is show below. In the
text I use the notation {namespace}local-part for writing
qualified names, the namespace is just an identifier that should
be obvious, not the whole URI.

--------- 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}MethodNotPresent fault MUST be generated when the
server cannot find the method 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.

 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 is 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 Thursday, 2 August 2001 09:38:21 GMT

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