- From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
- Date: Tue, 2 Apr 2002 13:57:24 -0800
- To: "Mark Baker" <distobj@acm.org>, <noah_mendelsohn@us.ibm.com>
- Cc: "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>
Sorry for jumping in here and maybe I am missing something but I think we may be able to define when a fault is a fault without compromising the integrity of our spec (maybe this according to Noah [1] is having our cake and eating it too). Would it not work to say the following: A) A SOAP processing failure results in the generation of a SOAP fault [2] B) An HTTP processing failure results in the generation of an HTTP status code describing the failure [3] C) The SOAP binding to HTTP defines the mapping between SOAP faults and HTTP status codes (the TBTF is currently discussing issue 196 [4] which is related) If any of these statements are not true then we have a broken implementation. >My view would be that if faultHint is really only a hint, then we >shouldn't have it. But this is all tied up in the resolution of 192, >which I believe is waiting for the group to decide which of Noah's >suggestions[1] it wants to proceed with. Henrik Frystyk Nielsen mailto:henrikn@microsoft.com [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Mar/0364.html [2] http://www.w3.org/2000/xp/Group/2/03/23/soap12-part1-1.37.html#procsoapm sgs [3] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10 [4] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x196
Received on Tuesday, 2 April 2002 16:58:08 UTC