Re: Issues 12 & 192

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 UTC