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

Re: Issues 12 & 192

From: Jacek Kopecky <jacek@systinet.com>
Date: Tue, 26 Mar 2002 23:39:01 +0100 (CET)
To: Highland M Mountain <highland.m.mountain@intel.com>
cc: xml-dist-app@w3.org
Message-ID: <Pine.LNX.4.44.0203262320180.20849-100000@mail.idoox.com>
 Highland,
 I agree with your concern, I would rephrase it though:
 What I see as directly contrary to R600 is not that we're 
escalating HTTP-specific issues to affect the whole transport 
binding framework, but the fact that we're trying here to imply 
additional features in transport to which SOAP can be bound, 
namely the ability to transfer the so-called faultHint out of 
the Envelope.
 What we really need from an underlying protocol is the ability 
to get the Envelope there. When a protocol has some more 
information that can be useful, it should be coordinated with the 
Envelope. I don't really like the idea of transports affecting 
the meaning of an Envelope because then you have to carry stuff 
like the faultHint with the Envelope all the way from the 
original transport to the SOAP Envelop processor implementation, 
possibly through layers of abstraction.
 I think it was Noah who proposed that HTTP status code not 
consistent with the presence (or absence) of a Fault in the 
Envelope should be dealt with as any other *transport-layer* 
breakage.
 I'll be sending an other message on the general topic of what 
SOAP is soon.

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/


---------- original message
From: "Mountain, Highland M"
To: "'Mark Baker'", xml-dist-app@w3.org
Date: Tue, 26 Mar 2002 12:23:22 -0800
Subject: RE: Issues 12 & 192 

Mark Baker's 192 proposal [1] is tagged more clearly, below.  
Sorry for any confusion generated by my previous email.....
============================================================

This proposal to 192 (especially the first point) and the
discussion surrounding it seem contrary to R600. True, we are
using the word should here, but additional discussions regarding
other transports are implying a MUST tone.

<Mark Baker's proposal for 192 (to be discussed at the 3/27
telecon)>

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.

</Mark Baker's proposal for 192 (to be discussed at the 3/27 
telecon)>

<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.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x192
Received on Tuesday, 26 March 2002 17:39:04 GMT

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