- From: <noah_mendelsohn@us.ibm.com>
- Date: Sun, 14 Apr 2002 08:02:12 -0400
- To: Mark Baker <distobj@acm.org>
- Cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, xml-dist-app@w3.org
Mark Baker suggests: >> In the case of a SOAP intermediary, and where the >> SOAP message exchange pattern and results of >> processing (e.g. no fault generated, as determined by >> the underlying protocol binding in use on the incoming >> hop) require that the SOAP message be sent further >> along the SOAP message path, relay the message as >> described in section 2.7 Relaying SOAP Messages. No, no, no! Even a chameleon view must admit that applications have semantics. The application may fail before the underlying protocol even has a chance to see, or after the protocol has succeeded. Let's say I send a request using SOAP, over HTTP, to a SOAP intermediary. In the message is a header with a digital signature. Consider two cases: * Request transmitted successfully over HTTP to the intermediary, mustUnderstand dsig header is checked, signature is correct. As a result of this successful "result of the processing" (no fault generated), the message is relayed by the intermediary. * Same request transmitted successfully over HTTP to the intermediary, mustUnderstand dsig header is checked, signature is incorrect. As a result of this "result of the processing" (fault generated by handler for dsig check), the request message is not relayed by the intermediary. Henrik's original proposal covers this just fine. Yours does not IMO. Furthermore, we have have been clear that bindings are part of the node, so failures at the underlying protocol level can be considered an aspect of processing. Presumably, a case you would be interested in would be: * Request transmitted over HTTP to the intermediary. Binding at receiver discovers poorly formed HTTP header. As a result of this "result of the processing" (fault generated), the message is not relayed by the intermediary. I really think Henrik's proposal covers this. We can reflect SOAP faults due to failure at the binding level (though I note that our HTTP binding chooses not to.) If you really aren't comfortable that bindings are part of the node, maybe we could try something like: In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated, underlying protocol binding reports success) require that the SOAP message be sent further along the SOAP message path, relay the message as described in section 2.7 Relaying SOAP Messages. I don't actually think this is necessary, but I don't strongly object. I do have a serious concern with your formulation, as I don't think it covers the usual case in which the issue is at the application level. ------------------------------------------------------------------ Noah Mendelsohn Voice: 1-617-693-4036 IBM Corporation Fax: 1-617-693-8676 One Rogers Street Cambridge, MA 02142 ------------------------------------------------------------------ Mark Baker <distobj@acm.org> Sent by: xml-dist-app-request@w3.org 04/12/2002 04:23 PM To: Henrik Frystyk Nielsen <henrikn@microsoft.com> cc: xml-dist-app@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM) Subject: Re: Proposal for closing editorial issue 193 Henrik, On Fri, Apr 12, 2002 at 12:20:51PM -0700, Henrik Frystyk Nielsen wrote: > > The SOAP 1.2 editors intend to use the following proposed wording for > resolving the editorial issue 193 as replacement text for bullet 5 in > soap 1.2 part 1 [2]: > > In the case of a SOAP intermediary, and where the > SOAP message exchange pattern and results of > processing (e.g. no fault generated) require that > the SOAP message be sent further along the SOAP > message path, relay the message as described in > section 2.7 Relaying SOAP Messages. > > Any reason not to? We have to be careful not to violate R803 here, as we previously discussed in regards to issue 192. The SOAP core specification cannot know the "results of processing". One way to fix this would be to say; In the case of a SOAP intermediary, and where the SOAP message exchange pattern and results of processing (e.g. no fault generated, as determined by the underlying protocol binding in use on the incoming hop) require that the SOAP message be sent further along the SOAP message path, relay the message as described in section 2.7 Relaying SOAP Messages. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Sunday, 14 April 2002 08:18:27 UTC