W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

RE: Issues 12 & 192 (long)

From: Appleton, Pete M <PMAppleton@bemis.com>
Date: Thu, 28 Mar 2002 02:20:22 -0600
Message-ID: <D9860668E25BA24B93D14DE111B47597705A@NT160_MAIL.bemisltduk.local>
To: xml-dist-app@w3.org
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 [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 03:20:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:48 UTC