Subject: EDI and Message Disposition Notifications

From: "AMIT Y RAO" <[email-masked]>
Date: Wed, 3 Nov 1999 18:22:11 -0700

RFC 2298 defines a MIME content-type to report the disposition of a message
after it has been successfully delivered to a recipient. The purpose is to
extend Internet Mail to support functionality often found in other messaging
systems, such as X.400 and the proprietary "LAN-based" systems, and often
referred to as "read receipts","acknowledgements", "receipt notifications",
while respecting privacy concerns.
    Can anybody please tell me how EDI functionality that was assured by
VANS in the past will be assured by these MDNs when it is stated in this RFC
(i.e. 2298), that because of privacy concerns a user agent is always free to
ignore a request for a receipt. Doesn't this mean that a sender may expose
his business position without being informed whether or not the recipient
has become aware of this business position? Isn't this in fact a lower
standard of non-repudiation than that found in traditional EDI channels?

---

From: "Rik Drummond" <[email-masked]>
Date: Thu, 4 Nov 1999 06:35:25 -0600

we specify if the receipt is requested, it must be sent. best regards,rik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of AMIT Y RAO
Sent: Wednesday, November 03, 1999 7:22 PM
To: [email-masked]
Subject: EDI and Message Disposition Notifications

---

From: "Carl Hage" <[email-masked]>
Date: Thu, 4 Nov 1999 09:53:40 -0800

From:           	"AMIT Y RAO" <[email-masked]>

> VANS in the past will be assured by these MDNs when it is stated in this
> RFC (i.e. 2298), that because of privacy concerns a user agent is always
> free to ignore a request for a receipt. 

For purposes of EDI, failure to receive an MDN means the transaction
is incomplete. You are free to ignore a request to sign registered postal
mail, but it means you decline receiving it. Likewise for an EDI 
transaction.

The RFC does not prohibit trading partners to require receipts in order
to conduct business-- it means that just because I check the MDN
requested in my email program, that doesn't mean I'm guaranteed
to get one. Email readers are not required to respond to the MDN
in order to be compliant with the standards.

Besides legal non-repudiation, the MDN is a safety check to validate
that there was no problem with the message transmission. If an
MDN isn't received within a certain time, then the message would
normally be retransmitted. Repeated failures would need to be handled
manually, e.g. you call your trading partner and ask them why thier
system doesn't work. If MDNs aren't being issued, thir software isn't
configured properly and EDI transactions cannot be processed.

With DSL becoming economical for small businesses, I expect 99.9% 
of EDI trading partners will have dedicated internet access, so SMTP
messaging can take place in real-time, e.g. a few seconds, without
queuing. Any network problems can be diagnosed automatically using
the traceroute command. Other problems can be automatically 
isolated to the TP's server or EDI gateway&processing system.

Note that if HTTP were being used for transmission, the identical
error retry and diagnosis requirements would apply. (If your HTTP
transmission fails, the EDI interface needs to queue and 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