Re: Proposal for closing editorial issue 193

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