Re: Issue 192 & R803

Mark,

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.

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).

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.

e.g.

SOAP Fault as data extension module
	[namespace name] http://example.com/my/extensions
	[local name] ThisFaultIsNotReallyAFault
	[attributes]
		[namespace name] http://www.w3.org/.../soap-envelope
		[local name] mustUnderstand
		[normalized value] true
		[attribute type] xsi:boolean
		[specified] true

	Including this SOAP Header extension in a SOAP message
	changes the semantic meaning of a SOAP Fault EII carried
	as a child of the SOAP Body EII in a SOAP message such that
	the SOAP node operating in the role of .../ultimateReceiver
	MUST not treat it as a SOAP Fault, but as application data.

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:

  	"XMLP must not preclude the use of transport
          bindings that define transport intermediary
          roles such as store-and-forward, proxy and gateway."

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. 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:)

Cheers,

Chris

[1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0322.html

Mark Baker wrote:

>>Chapter 2 of the soap framework makes 
>>clear that a fault in such a successfully received message will be treated 
>>as a fault.
>>
> 
> I just re-read section 2, and didn't notice anything like that.  But if
> there was something in there that said what you claim, it would be a
> violation of R803.
> 
> 
>>So, I think it's quite legitimate for you to argue that my proposal would 
>>be the wrong one on the merits.  I don't see how it could be an R803 
>>violation.  Thank you.
>>
> 
> That's fair (modulo the above concern).  But I'd ask that we clearly
> label this binding as being one that will prevent some HTTP
> intermediaries from being used in the chain.
> 
> MB
>

Received on Friday, 29 March 2002 07:07:29 UTC