Re: Issue: Problem with ProcedureNotPresent fault subcode

 Noah,
 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 
altogether.
 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)
                   http://www.systinet.com/

[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, 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
 > ------------------------------------------------------------------
 > 
 >

Received on Friday, 3 May 2002 17:20:51 UTC