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

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.


Pete Appleton
Information Systems Controller, Bemis Packaging Limited

-----Original Message-----
From: Christopher Ferris []
Sent: 27 March 2002 19:39
Subject: Re: Issues 12 & 192 (long)

<snip />

Received on Thursday, 28 March 2002 03:20:52 UTC