Re: RPCTF: issue #45

+1 to Jacek's proposal below.

Cheers,

Chris

Jacek Kopecky wrote:
> 
>  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 Monday, 6 August 2001 11:54:38 UTC