Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!smoke!Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
From: Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA
Newsgroups: net.mail.headers
Subject: Re: CONFIRM-DELIVERY
Message-ID: <4728@brl-smoke.ARPA>
Date: Sun, 19-Oct-86 16:17:53 EDT
Article-I.D.: brl-smok.4728
Posted: Sun Oct 19 16:17:53 1986
Date-Received: Tue, 21-Oct-86 22:26:53 EDT
Sender: news@brl-smoke.ARPA
Lines: 27

The problem of intelligent handling of confirmations can be split
into two parts:

(a) Formatting the text of the confirmation itself in such a
manner that it can be recognized and handled by a computer program.
You suggest an alternative for doing this in your message.

(b) Programming your local user agent to use this to provide
you with various features such as:
- Getting yourself reminded if a message has not been delivered
within a certain time interval.
- Providing you with a summary of the delivery-status of a multi-
recipient message when you ask for it, or automatically at a
certain future date.

(b) is of course a local matter, does not need standardization.
(a) does require a standardized format of confirmations. This
is already available in X.400. If we do wish to get this also
as an extension to RFC822, something like what you propose should
be used.

One problem is that more and more of messaging will be X.400,
and go via X.400<->RFC822 gateways, and the present proposal
for such gateways (RFC987) does not propose that confirmation
requests and confirmations should be passed across such gateways
(since RFC822 does not have a standard for confirmation formatting
in computer-readable form).