Re: Issue: Problem with ProcedureNotPresent fault subcode

+1, this is exactly was I trying to point out earlier.

Jean-Jacques.

noah_mendelsohn@us.ibm.com wrote:

> Jacek Kopecky writes:
>
> >>  I believe you described below the case where you
> >> recognize the QName.
>
> I don't think so.  See below.
>
> >> In the other case - RPC as an application of SOAP, you
> >> just assume that what's come in is an RPC request.
> >> There's no mixing RPC with non-RPC on one endpoint then.
>
> I think this is the real point of confusion.  If I understand Henrik, and
> I think I agree with him, it's not SOAP's business to legislate that a
> given endpoint can't accept both RPC's and other SOAP messages.  WSDL may
> or may not go that way, but it's surely not required for SOAP.
> Furthermore, RPC is just a convention that makes certain things easy at
> the endpoint (I.e. mapping to commonly used programming languages).  There
> is no particular requirement for a responding endpoint to treat RPC's
> differently, at least in the success case.
>
> So the question is, what do we gain by requiring a different response for:
>
> * I was expecting and RPC, and I didnt' recognize the QName (so I claim rpc:ProcedureNotPresent)
> -vs-
> * I was expecting any old SOAP message and I didn't understand the body (I
> think in this case we allow more or less arbitrary sender fault, right?).
>
> Maybe the way to handle this is to clarify that an endpoint intending to
> intrepret a message as an RPC MAY or even SHOULD send
> rpc:ProcedureNotPresent for a mismatch on the body QName, however an RPC
> requestor MUST be prepared to deal with an arbitrary sender fault returned
> from the responder.
>
> In other words, an endpoint that was not expecting an RPC, or an endpoint
> that accepts both RPCs and other SOAP messages MAY return sender faults
> other than rpc:ProcedureNotPresent for an unexpected body QName.
>
> I agree with Henrik that this is an important restriction, and that we
> should not require separate endpoints (destination URI's) for processing
> of RPC and other SOAP message traffic.
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
> Jacek Kopecky <jacek@systinet.com>
> 05/03/02 11:21 AM
>
>
>         To:     noah_mendelsohn@us.ibm.com
>         cc:     moreau@crf.canon.fr, <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
>         Subject:        Re: Issue: Problem with ProcedureNotPresent fault subcode
>
>  Noah,
>  I believe you described below the case where you recognize the
> QName. In the other case - RPC as an application of SOAP, you
> just assume that what's come in is an RPC request. There's no
> mixing RPC with non-RPC on one endpoint then. So the fault is
> simple - it's supposed to be RPC but I don't recognize the method
> - ProcedureNotPresent is the fault.
>  Best regards,
>
>                    Jacek Kopecky
>
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
>
> On Fri, 3 May 2002 noah_mendelsohn@us.ibm.com wrote:
>
>  > The case where you do recognize the QName is easy, for the reason you
>  > state.  I think the questionnable case is:  the QName is a
> representation
>  > of the procedure name.  So a QName comes in.  Your code does the
>  > following:
>  >
>  > 1) Is it one of the QNames I process as a known body document type --
> NO
>  > 2) Does it correspond to one of the methods I process as RPC - NO
>  >
>  > OK, which fault do I return.
>  >
>  > ------------------------------------------------------------------
>  > Noah Mendelsohn                              Voice: 1-617-693-4036
>  > IBM Corporation                                Fax: 1-617-693-8676
>  > One Rogers Street
>  > Cambridge, MA 02142
>  > ------------------------------------------------------------------
>  >

Received on Monday, 6 May 2002 03:55:23 UTC