Re: Issue 192 & R803

Chris, thanks for putting this together.

> Unless there's been a drastic change to SOAP in the last
> couple of days, the contents of the SOAP Body element are
> targetted implicitly at the ultimate SOAP receiver node,
> not at intermediaries. An intermediary can peek at the
> contents, but it is NOT supposed to "process" the contents
> in the SOAP sense.

Well, the SOAP processing model only applies to SOAP intermediaries, no?
We can't retroactively go about saying that non-SOAP HTTP intermediaries
have to follow these rules.

> An intermediary SOAP node by definition MUST NOT assume
> the role of http://www.w3.org/.../role/ultimateReceiver.
> 
>  From section 2.2 of SOAP 1.2 Part 1[1]:
> 
>      "http://www.w3.org/2001/12/soap-envelope/role/ultimateReceiver"
>         To establish itself as an ultimate SOAP receiver a SOAP node MUST
>         act in this role. SOAP intermediaries MUST NOT act in this role.
> 
>  From section 2.3 of SOAP 1.2 Part 1:
> 
>      The ultimate SOAP receiver MUST process the message body. The SOAP
>      message path for that message ends at its ultimate SOAP receiver.
> 
>  From section 2.4 of SOAP 1.2 Part 1:
>      Mandatory blocks MUST be presumed to somehow modify the semantics of
>      other headers or body elements. Therefore, for every mandatory SOAP
>      header block targeted to a node, that node MUST either process the
>      block or not process the SOAP message at all, and instead generate a
>      fault (see 2.6 Processing SOAP Messages and 5.4 SOAP Fault).
> 
>  From section 2.5 of SOAP 1.2 Part 1:
> 
>      An ultimate SOAP receiver MUST correctly process the immediate
>      children of the SOAP body (see 5.3 SOAP Body).

Right, all that looks fine to me.

> Thus, if you want to modify the semantics of SOAP Fault EII as
> child of the SOAP Body EII, you must then include a SOAP Header
> extension (block) that changes its semantic meaning to be
> something other than a SOAP Fault and target that SOAP Header
> extension at the SOAP node operating in the .../ultimateReceiver
> role.

I don't follow.  The processing model doesn't care whether the received
envelope contains a fault or not.  This is consistent with the
chameleon use.

> I honestly don't understand how you can claim that the semantics
> of a SOAP Fault EII as child of the SOAP Body EII is somehow
> a violation of R803. To restate R803:

It would be a violation of R803 if the processing model said something
like "if the envelope contains a fault, then do such-and-such".

This is because, in the chameleon view, the presence of a fault on the
wire is insufficient information to know whether it is to be processed
as a fault.  The outermost containing context for the fault, in this
case the envelope of the application protocol, is authoritative, in
roughly the same way that;

<not>
  <banana/>
</not>

means "not a banana", and you wouldn't want an intermediary that counts
bananas to count that as a banana.

> As I have pointed out, a SOAP intermediary doesn't "process"
> in the SOAP sense the contents of the SOAP Body EII. An intermediary
> that processes the SOAP message (in the SOAP sense) is by definition
> a SOAP node and MUST abide by the SOAP processing rules as defined
> in section 2.6 of SOAP 1.2 Part 1.

But an HTTP intermediary doesn't "process" the SOAP message; it knows
nothing of SOAP.  But it does know about success and failure.

> Anything else is simply not
> a SOAP intermediary, but that doesn't preclude a non SOAP intermediary
> at the transport level (routers, switches, proxies, etc.)
>
> Additionally, in a side thread on this list[2], you are arguing
> that HTTP is NOT a 'transport' and R803 is about 'transport'
> intermediaries;) (couldn't resist that:)

I knew this would come back to haunt me! 8-)

http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0022.html

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 29 March 2002 10:21:23 UTC