Re: Random points plus a proposal for a format for notifications/acks.

Peter Cowen <p.cowen@nexor.co.uk> Mon, 28 June 1993 13:48 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24325; 28 Jun 93 9:48 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24321; 28 Jun 93 9:48 EDT
Received: from ics.uci.edu by CNRI.Reston.VA.US id aa29549; 28 Jun 93 9:48 EDT
Received: from ics.uci.edu by q2.ics.uci.edu id aa18244; 28 Jun 93 5:40 PDT
Received: from lancaster.nexor.co.uk by q2.ics.uci.edu id aa18238; 28 Jun 93 5:40 PDT
Received: from nexor.co.uk (actually lightning.nexor.co.uk) by lancaster.nexor.co.uk with SMTP (PP); Mon, 28 Jun 1993 13:39:52 +0100
To: Bob Smart <smart@mel.dit.csiro.au>
cc: ietf-ack@ics.uci.edu
Subject: Re: Random points plus a proposal for a format for notifications/acks.
In-reply-to: Your message of "Sun, 27 Jun 1993 23:12:20 +1000." <9306271312.AA29020@squid.mel.dit.CSIRO.AU>
Date: Mon, 28 Jun 1993 13:39:45 +0100
Message-ID: <9794.741271185@nexor.co.uk>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Peter Cowen <p.cowen@nexor.co.uk>

>     Proposed Format for Internet Mail Notifications
>     -----------------------------------------------
> 
> The Everhart/Borenstein draft adds the header "Ack: <msg-id>". I would
> like to make 2 changes to this.
> 
>   a. I would like to add the Ack-type as an extra parameter, with an
>      Ack-type of "error" for non-delivery notifications.
> 
>   b. I would like to change "Ack:" to "Notification:" because
> 
> 	Ack: error <msg-id>
> 
> So the first plank of my notification format is that it contains the header
> 
> 	Notification: <ack-type> <msg-id>
> 
> e.g.
> 	Notification: error <123@ics.uci.edu>
....
> A key question is how this will work with X.400 gateways. Given that the
> original message has been converted to rfc-822/MIME style with rfc987+ and 
> then later bounced: can an X.400 gateway convert a bounce message in the 
> above style into a legal X.400 NDN that clearly refers to the original 
> X.400 message? Similarly going the other way: can an X.400 NDN be converted 
> into a message in this format that refers to an original rfc-822 message 
> that went into x.400-land?

A few of things from the x400 view which may effect things

First somethiong to be aware of for naming purposes. X400 has both
reports and notifications They are different things.
Reports are generated when the message is actually delivered to a
mailbox or bounced through non delivery.
Notifications are generated when that message is actually read by the
user.
This is a possible area of confusion  because the notification above
seems to map the the X400 idea of a report and not the X400 idea of a
notification.

The Notification you define above is a permessage Notification.
It is unlikely that every recipient of a message will generate a
Notification for the same reason.
The X.400 model is more directed along the perrecipient path.
X400 delivery reports associate an error flag with each
individual recipient. Thus your DR/notification can carry information
for several different error conditions (unknown mailbox, unable to convert,
timed out etc).

The X400 model also has a perecipient Supplementary info string. In my
experience this is the most useful piece of information contained in a
DR. 

Peter