Loading ...
Sorry, an error occurred while loading the content.

RPCTF: issue #45

Expand Messages
  • Jacek Kopecky
    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
    Message 1 of 1 , Aug 2, 2001
    • 0 Attachment
      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@... 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
    Your message has been successfully submitted and would be delivered to recipients shortly.