

RE: Issue 182: Fault Code restriction: "At Most One Fault Proposa l"

From: Henrik Frystyk Nielsen <henrikn@microsoft.com>
Date: Sat, 23 Feb 2002 14:51:15 -0800
Message-ID: <79107D208BA38C45A4E45F62673A434D05A540E4@red-msg-07.redmond.corp.microsoft.com>
Cc: "Christopher Ferris" <chris.ferris@sun.com>, "Williams, Stuart" <skw@hplb.hpl.hp.com>, <xml-dist-app@w3.org>



>This is in response to several comments earlier in the thread.  I read 
>these to be generally along the lines of "why mandate exactly 
>one fault if 
>in certain MEPs it will be dropped on the floor anyway" and/or 
>the closely 
>related "it would be unwise to relay on it".  With respect, I 
>and see this as reasoning inappropriately from the converse. 
>There do indeed exist cases in which the fault is not reliably 
>to anyone, and in that sense of questionable value.  However, the 
>important point is that there are important cases in which the 
>of exactly one fault or successful response is important, and may be 
>relied upon.  Consider the HTTP binding for request response.  In 
>practice, we open a TCP connection for the request, and the 
>receiver keeps 
>that connection open.  Until when?  Until the node generates either a 
>successful response or a fault!  If there's any question that 
>one or the 
>other of these will surely be generated, then we get into the 
>business of 
>timeouts, which is a big mess IMO.    Note that this 
>requirement is indeed 
>at the message level, not per header or body. 
>So, I think on balance it's a useful model to say that every message 
>sooner or later reaches an endpoint in its processing.   That 
>endpoint is 
>formally demarcated by the availability of some sort of 
>result, which is 
>either success or failure.  Modeling this as a fault seems a 
>good idea to 
Received on Saturday, 23 February 2002 17:52:48 GMT
