Subject: Re: AS2, HL7,GISB, E5, others?

From: "Dale Moberg" <[email-masked]>
Date: Thu, 25 Feb 1999 16:11:14 -0500

>In any case, some mention of error recovery is important,
>particularly with HTTP.

Hi Carl,

The subsection you posted on this looks promising to me. I need just
a little more clarification on the kind of error recovery we are talking
about so that what is being requested is unambiguous to a potential
implementor:

1. One basic gotcha of exception handling is that there is sometimes
a handler that when retried will just lead to an endless series of retries.
(So a retry limit will be added.) In particular, cases in which the
'unsuccessful
read or processing of the REPLY data stream" need to be marked into
classes that are intemittent and recoverable and indefinitely bad and need
to be fixed before proceeding. I welcome some help in sorting these out
and making a completely unambiguous statement of the retry policy and
the caveats.

2. There can be socket level read errors, HTTP non-200 values, malformed
MDNs from a renegade application, MDNs that just report failure. I read your
statement as mainly pertaining to a network problem (that shows up as a
socket error after TCP gives up--times out, gets some ICMP msg,etc,etc).
Is this the error class you are most concerned with? Should we have a backoff
retry? Retry limits? A time out ("after 5 days of HTTP POSTS msg
undeliverable:-)
Sometimes you really want to just give up and get an administrator...

Thanks
Dale

---

From: "Carl Hage" <[email-masked]>
Date: Thu, 25 Feb 1999 14:02:46 -0800

From:           	"Dale Moberg" <[email-masked]>

>  I need just

There are a few different types of errors:
 - Something went wrong in the post operation and the reply data 
could not be retrieved correctly, e.g. timeout, socket closed, etc.
- There is a problem with the format of the post/reply, e.g. the MDN
has unknown headers or points to a nonexistant message.
- There is an authentication error
- The MDN indicates an error.

The first case is normally corrected by retrying the operation, 
possibly deferring until later. (This is more-or-less what SMTP
servers do when a connect fails.)

The other cases are normally handled by reporting the problem for 
human intervention. If a valid MDN was received, then normally a 
retransmission would not correct the problem. Retransmitting the 
message would normally just cause the prior MDN to be resent.

There is a slight possibility that a message could be corrupted
in transit (though TCP is expected to fix corruptions), and 
retransmitting could fix it, but I think it's not useful for automated 
retries.

Infinite loops must be avoided, of course, so retries should be 
limited. The details on error recovery are implementation specific.

The standard need only mention the significance of a repeated 
message-ID, i.e. a repeated ID normally indicates error retry.

--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086