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

+1 

Henrik

>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 
>disagree, 
>and see this as reasoning inappropriately from the converse. 
>
>There do indeed exist cases in which the fault is not reliably 
>delivered 
>to anyone, and in that sense of questionable value.  However, the 
>important point is that there are important cases in which the 
>existence 
>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 
>me.