- From: Appleton, Pete M <PMAppleton@bemis.com>
- Date: Thu, 28 Mar 2002 02:20:22 -0600
- 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 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 03:20:52 UTC