W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2002

Re: Issue: Problem with ProcedureNotPresent fault subcode

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 6 May 2002 10:25:49 -0400
To: Jacek Kopecky <jacek@systinet.com>
Cc: moreau@crf.canon.fr, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
Message-ID: <OF525089AB.C7A2B9D6-ON85256BB1.005024A1@lotus.com>
Jacek Kopecky writes:

>> OK, you've converted me to MAY. 8-)

Good, I think that's a good compromise, if others agree.  I could probably 
live without the subcode entirely, or maybe better yet, a subcode that's 
not specific to RPC.  Why not have a general subcode: "bodyNotRecognized", 
which would apply uniformly to RPC and non-RPC responses.  Again, I can 
live with ProcedureNotPresent as a MAY.  Many thanks!

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/2002 05:20 PM

        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

 I think I understand your points, and I don't view any of the
two options I presented in [1] as being particularly better, it's 
just two possible views at our RPC.
 What I said is that I always assumed (b), while you are still
assuming (a), and I have a feeling you prefer (a) a lot. I can go 
either way, and obviously in (a) the MAY for ProcedureNotPresent 
is perfectly appropriate, if we don't remove the fault subcode 
 In fact, I believe removing it would reinforce (a), while 
keeping it allows application designers to choose. 
 OK, you've converted me to MAY. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002May/0024.html

On Fri, 3 May 2002 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, 
 > 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 
 > 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). 
 > 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 
 > * I was expecting and RPC, and I didnt' recognize the QName (so I claim 
 > -vs-
 > * I was expecting any old SOAP message and I didn't understand the body 
 > think in this case we allow more or less arbitrary sender fault, 
 > Maybe the way to handle this is to clarify that an endpoint intending 
 > intrepret a message as an RPC MAY or even SHOULD send 
 > rpc:ProcedureNotPresent for a mismatch on the body QName, however an 
 > requestor MUST be prepared to deal with an arbitrary sender fault 
 > from the responder. 
 > In other words, an endpoint that was not expecting an RPC, or an 
 > 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 
 > 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
 > ------------------------------------------------------------------
Received on Monday, 6 May 2002 10:42:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:50 UTC