Re: Issue: Problem with ProcedureNotPresent fault subcode

+1! I was thinking along these very lines.

noah_mendelsohn@us.ibm.com wrote:

> 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:48:24 UTC