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

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.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Saturday, 23 February 2002 17:41:21 UTC