Re: Issue: Problem with ProcedureNotPresent fault subcode

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


 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 Monday, 6 May 2002 10:42:47 UTC