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

Re: Issues 12 & 192

From: Mark Baker <distobj@acm.org>
Date: Tue, 26 Mar 2002 20:59:47 -0500 (EST)
Message-Id: <200203270159.UAA19529@markbaker.ca>
To: highland.m.mountain@intel.com (Mountain, Highland M)
Cc: xml-dist-app@w3.org
Hi Highland,

> <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
> </R600>
> 
> 
> IMO, deriving Transport Binding Framework fault handling directives from
> HTTP binding specific issues(12 & 192) goes against R600.  

Well, nothing in my proposal suggests that SOAP do anything
HTTP-specific, which is what I understand R600 to be saying.  My
proposal just *suggests* that it be a feature of all application
protocol bindings that the fault mechanism of the underlying protocol be
authoritative in determining whether a SOAP fault be processed as a
fault or not.

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.

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 20:54:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT