RE: Issues 12 & 192 (long)

<Pete wrote>
If we try to make the SOAP fault (or lack of) mirror (or respect) the HTTP
status codes, then we are making SOAP tied into HTTP, and *not* protocol
independent. 
</Pete wrote>

+1


Mark,

The SOAP application layer is interested in the SOAP fault.  Ultimately, it
is the sender of the SOAP request/msg that needs to be notified of the SOAP
fault.  Pardon my ignorance of Transport Intermediary processing, but please
describe a scenario where a SOAP processing fault, wrapped in a 200 HTTP
message, would hinder a transport intermediary from assuming such roles as
proxy, gateway or store and forward node.  

Highland


<Mark Baker wrote>

While we're talking about requirements, I'd point out R803;

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

IMO, sending faults intended to be processed as faults, with a
successful response code from the application protocol, goes against
R803, because these intermediaries are unaware of the fault.

</Mark Baker wrote>



-----Original Message-----
From: Appleton, Pete M [mailto:PMAppleton@bemis.com]
Sent: Thursday, March 28, 2002 1:20 AM
To: xml-dist-app@w3.org
Subject: RE: Issues 12 & 192 (long)


Surely the HTTP and SOAP status codes / fault codes are *completely
independent*, and should be treated as such by the end application.

In other words -
HTTP, as a transport layer, can happily return '200, I'm happy' whilst the
SOAP processor living on top of it can return <soap:Fault>I got the message
transferred to me but it made no sense</soap:Fault> or alternately the HTTP
layer could return '404 There isn't a SOAP consumer that I know about at
that URL', in which case by definition there is going to be any SOAP
returned at all unless the HTTP layer knows about SOAP (which IMO is a Bad
Thing).

If we try to make the SOAP fault (or lack of) mirror (or respect) the HTTP
status codes, then we are making SOAP tied into HTTP, and *not* protocol
independent.  It seems to me that in order to permit SOAP to be truly
transport-independent, it must know nothing about (and care nothing) about
the underlying transport.  Then, building a new MEP becomes a relatively
simple issue of leveraging the transports as is.  In the same way that HTTP
doesn't know (or care) about whether the incoming message came over IP, or
IPX, or DLC, or anything else, the SOAP processor shouldn't know or care
about how it received a SOAP message - purely that it did.

Regards,

Pete Appleton
Information Systems Controller, Bemis Packaging Limited
pmappleton@bemis.com

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: 27 March 2002 19:39
To: xml-dist-app@w3.org
Subject: Re: Issues 12 & 192 (long)

<snip />

Received on Thursday, 28 March 2002 09:40:57 UTC