Eric.Burger@centigram.com
Mon, 24 Jan 2000 12:42:15 -0800
The driver for PNDN's is the voice mail community. However, it should be
able to cover fax or any other gateway situation where one exchanges
documents between two systems with different rendering capabilities. The
approach was entirely from the "permanent failure" point of view (e.g. my
voice mail doesn't do images or my fax doesn't do voice), not the
"transient failure" point of view (e.g. someone picked up the phone when I
was sending a fax).
The PNDN draft purposely does not try to categorize which failures are
"serious".
All failures get noted, which addresses the "failure to deliver even the
smallest part of a message is a failure" issue. However, not all failures
constitute a failed delivery. A common UM message is "Part 1: 'Here is a
spreadsheet from Fred'" "Part 2: <a binary attachment>". The recipient has
enough information to call Fred. The sender gets notified the recipient
didn't receive the entire message; Part 2 didn't make it. I agree with
Ned's experience: the subscriber would get ticked off if he got "delivery
failed" notifications. The recipient got the message! However, they just
didn't get the whole thing.
Moreover, the recipient immediately knows something odd has happened: they
received a PNDN. Unless they requested return-receipt, they don't expect
to receive any messages from a mailer-daemon :-)
This is why I'm leaning towards PNDN's being informational (warning)
messages, unless there is an indication to the contrary. Again, contrary
indications would be a critical-content indicator or an "obvious" (to the
developer) condition that indicates failure.
From: ned.freed@innosoft.com on 01/24/2000 07:40 PM GMT
To: "Herman R. Silbiger" <hsilbiger@home.com>
cc: Graham Klyne <GK@dial.pipex.com>, ned.freed@innosoft.com, IETF fax
WG
<ietf-fax@imc.org>, IETF VPIM List <vpim@lists.neystadt.org> (bcc: Eric
Burger/US/Centigram)
Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt
> We seem to be ascribing different meanings to partial delivery. If we
fail to
> deliver all the pages in a fax, returning this information to the sender
will allow
> the sender to retransmit the missing pages. The same is true for a
multipart
> message when on or more of the parts were not successfully delivered.
Actually, the differences are even greater than this. The FAX world's
issues
with partial delivery have to do with the analog lines used and the
resulting
possibility that some portions of a transmission can be garbled. In such
cases there is a reasonable expectation that retransmitting will help.
This is not the case in the email world. Partial losses due to garbling of
message content on analog lines are extremely rare. Losses in the email
world
generally are the result of some system being incapable of handling some
particular media type. And in such cases retransmitting the same message
to the
same address is a total waste of time.
However, at least one of the goals here is to standardize a way to report
tranditional FAX errors when gatewaying from email to FAX. So I basically
see the issues of describing FAX errors as a subset of a much larger and
more complicated problem this proposal is attempting to address.
> It is true that the criteria for declaring a particular page not to be
successful
> in fax are not defined in the standard and thus each manufacturer has
defined their
> own. This accounts for the variability noticed by earlier commenters.
In any case,
> we are dependent on the interpretation of the particular manufacturer
for the
> decision as to whether it was successful or not.
Then perhaps we should carry this over to the present case and allow some
leeway in what constitutes an error when gatewaying.
> My personal take on this is that the delivery information to be returned
should be
> useful and allow appropriate action to be taken. Sometimes we may have
to
> retransmit the entire message even when we know where the error occurred
because it
> is not feasible to only retransmit that part of the message.
Perhaps this argues for focusing on reporting more about how to deal with
the
error than the specifics of the error itself. In the FAX case there should
be
something to indicate retransmission would help. In the case of a dropped
part
because the system cannot deal with it an alternate address would perhaps
make
sense. (SMTP used to have some redirect facilities, but they have fallen
into
disuse.)
Ned
This archive was generated by hypermail 2.0b3 on Tue Jan 25 2000 - 17:14:07 IST