Subject: RE: AS2 Reliability Draft for "Once and Only Once" Delivery

From: "Dale Moberg" <[email-masked]>
Date: Mon, 15 Aug 2005 13:57:46 -0700

HI,

The terms "retry" and "resend" are used in different ways in this
Internet-Draft, and are not synonymous.

The idea is that a resend is sending the message again after it was
apparently successfully sent. 

The resend operation only really makes sense in the context of
"asynchronous" MDNs where you are waiting for a MDN and think the MDN
may have gotten dropped on the floor, was not created, or otherwise
failed somehow,  because no MDN has arrived _when_ you were expecting
one.

[The term "retry" is used when the message is not known to have been
sent (no 200 OK, the connection was refused, 503 server busy, and so
forth).

You can think of it as if the resend timers only start when waiting for
a MDN. If no MDN is requested, you are expected to not be waiting for
one. In other words, the operation of resending never even starts unless
a MDN had been requested, so there is no reason to say what would stop
it in the case,   "no MDN requested."

[In addition, the operation of resend never starts when a synchronous
MDN is requested. In that case, you can only retry if you don't get the
MDN in the HTTP reply. Of course, you don't retry if you get the MDN and
a 200 OK. One case we did not consider, come to think of it, is
requesting a synchronous MDN, getting a 200 OK, but no MDN! Should we
retry that one?]

Thanks for your comment and we will try to make it more clearly evident
that resend operations are very different from retry operations.

 

________________________________

From: Shan Harter [mailto:[email-masked]] 
Sent: Monday, August 15, 2005 11:41 AM
To: [email-masked]; [email-masked]
Cc: Dale Moberg
Subject: RE: AS2 Reliability Draft for "Once and Only Once" Delivery 

We really don't want to keep retrying if receiving party did receive AS2
message but NO MDN is required:

"message, with the same content and the same Message-ID value is sent 
again. This operation is referred to as a resend of the message. This 
document will suggest guidelines to prevent AS2 software 
implementations that receive duplicate messages from distributing 
that message to back-end business applications, as well as guidelines 
on resend intervals and resend counts for various modes of AS2 
operation. Resending ends when the MDN is received", when a HTTP 200 OK
is received when NO MDN is requested, "or the resend 
count is reached."

Shan

Regards,

Shan Harter
PEBS, Inc.

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Monday, August 15, 2005 7:45 AM
	To: [email-masked]
	Cc: [email-masked]
	Subject: AS2 Reliability Draft for "Once and Only Once" Delivery

	A new Internet Draft addressing reliable delivery of AS2
messages is available at: 
	
http://www.ietf.org/internet-drafts/draft-duker-as2-reliability-00.txt
for review and discussion. 
	
	The purpose of the draft is to define ways to ensure that AS2
messages are delivered "once and only once". One key aspect is to ensure
that AS2 implementations do not pass "Duplicate Messages" on to back-end
business applications. The ultimate goal is to gain agreement on
standard approaches so that all AS2 software implementations can deliver
this functionality. We look forward to comments and suggestions from all
interested parties. 
	
	John Duker                Dale Moberg 
	Procter & Gamble        Cyclone Commerce