Subject: Re: draft-ema-vpim-pndn-00.txt

From: [email-masked]
Date: Tue, 11 Jan 2000 18:23:04 -0500

Thanks Graham and Keith for your comments.

You both hit on what was the hardest part for me to work out.  I dithered
back and forth, about whether partial-delivery was a special case of DSN or
something else.  In fact, my first write-up was simply an extension of DSN.
I'm not wed to it being something new.  In fact, one of the reasons I tried
to make partial-delivery an extension of DSN is that I expect a simple
extension would have a much easier time of getting IETF approval than a new
message type.

The big hint that PNDN's are an extension of DSN is that 70% of the PNDN
draft is cut-and-paste from DSN (including the ABNF bug -- good catch
Graham!).

However, the following issue made me fall into the camp that PNDN's are
something different.  DSN's deal with whole messages only.  There is no
mechanism for identifying parts of a message that fail yet having other
parts being delivered.  Either the system delivered the message or it
didn't.  If a sending system has a human reading the DSN, then we have some
flexibility with extending DSN.  However, we could have a sending system
that parses the DSN.  However, it doesn't understand the difference between
an RFC 1894 DSN (whole message failed) and a PNDN (part of the message
succeeded).  In this case, aren't we in the same situation as a system that
doesn't understand PNDN?

Keith, I'll defer to you as the DSN expert.  Is there an easy way of
extending DSN without breaking it?

Graham: I've incorporated all of your "nits".  Thanks for the close
reading.  The only thing I saw that was up for discussion is the change of
final-recipient from MUST to MAY.  I think (again, I'll defer to Keith,
since he was there) that final-recipient was mandatory because making it
available would greatly help the sender determine if the failure was an
addressing error.  My position on this is the security issue of hiding
telco resources is more important (and more likely) than the end user
debugging MX records.  If you think I'm being too paranoid, I can take out
this provision.  Otherwise, I can put in a NOTE describing why I made the
change.

Thanks again for your review.
--
- Eric

---

From: Graham Klyne <[email-masked]>
Date: Wed, 12 Jan 2000 10:43:01 +0000

At 06:23 PM 1/11/00 -0500, [email-masked] wrote:
>didn't.

Indeed.

And if the mechanism to be backwards compatible (with DSN), I believe this 
issue needs to be tackled head on.  Current DSN 'clients' will be able to 
recognize only 'delivered' or 'not-delivered' outcomes.

I think the key question, then, is:  does partial delivery constitute a 
'delivered' outcome or a 'not-delivered' outcome?

I believe a DSN response should reflect the outcome of this decision (for 
the benefit of current DSN clients), and then use additional DSN extension 
fields (ignored by current clients) to provide more detailed information 
for the benefit of PNDN clients.

#g

------------
Graham Klyne
([email-masked])

---

From: Keith Moore <[email-masked]>
Date: Wed, 12 Jan 2000 08:47:00 -0500

> However, we could have a sending system

For a sender that understands DSN but doesn't understand PNDN,
I think the choice is one of the following:

- sender understands that there was some sort of message delivery problem,
  and perhaps chooses to resend the entire message.  

- sender doesn't understand that there was a message delivery problem
  because he/she/it doesn't know how to parse the PNDN at all.

To me, the first choice sounds like the safer and more conservative one.

In general, anytime a delivery agent cannot deliver a message with
complete fidelity it has a choice - should this be reported as
"partial delivery" (thus a form of success) or delivery failure?  
There are lots of potential cases that could be labelled partial 
delivery - such as when the main portion of the message can be
delivered but some attachments cannot, or when all parts
can be transferred but there is likely to be some conversion loss
(say when a color image gets gatewayed via black-and-white fax),
or when some but not all pages of a fax can be delivered.

The choice of whether to label such an event (partial) success or  
failure seems like one which should be very dependent on the 
specific circumstances of the the message and its delivery or 
conversion.  Of course it would help to have some guidance from
the standards on when to label something a success and when
to label it a failure.

We grappled with this to some degree while working on DSNs,
which is why there are status codes for both 
'conversion required but not supported' (presumably a failure)
and 'conversion with loss performed' (presumably a success).

Also, I think it would be odd for us to use DSN to report 
delivery failure, and also to use DSN to report complete delivery 
success, but to use some other format for reporting partial success.
Seems like it is cleaner to use DSN for everything, to choose
a 2.x.x. or 4.x.x or 5.x.x status code as appropriate for
the overall message (new status codes could be defined for fax), 
and to add additional fields to the DSN to provide more detail 
about which parts of the message were undeliverable.  

Keith