RE: Issues 12 & 192

This proposal (element 1) and the discussion surrounding it seem contrary to
R600. True, we are using the word should here, but addition discussions
regarding other transports are implying a MUST tone.


R600 
The XMLP specification must not mandate any dependency on specific features
or mechanisms provided by a particular transport protocol beyond the basic
requirement that the transport protocol must have the ability to deliver the
XMLP envelope as a whole unit. This requirement does not preclude a mapping
or binding to a transport protocol taking advantages of such features. It is
intended to ensure that the basic XMLP specification will be transport
neutral



Proposal for 192....

What I suggest we do is;

1) update the binding framework to state that each binding should
declare that the authoritative determinant of whether a message is a
fault or not should be the underlying protocol

2) update the default HTTP binding to state that a SOAP Fault MUST
only be processed as a SOAP Fault if the response code is 4xx or 5xx.



IMO, deriving Transport Binding Framework fault handling directives from
HTTP binding specific issues(12 & 192) goes against R600.  



-----Original Message-----
From: Mark Baker [mailto:distobj@acm.org]
Sent: Saturday, March 23, 2002 4:53 PM
To: xml-dist-app@w3.org
Subject: Issues 12 & 192


All,

I've been thinking some more about issue 12 and its relationship to
issue 192.  Issue 12 says;

"A 2xx status code indicates that the request, including the SOAP message 
component, was successfully received, understood, and accepted by the
receiving SOAP processor."

This seems to me to exclude the possibility that faults (that are
supposed to be processed as faults) should be returned over 2xx
responses.

IMO, issue 192 is simply asking that we explicitly state what issue 12
already implicitly suggests.

Thanks.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Tuesday, 26 March 2002 14:46:03 UTC