Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt

From: [email-masked]
Date: Thu, 20 Jan 2000 20:02:15 -0600

How's this for a high-level description of the partial delivery mechanism:

PNDN is simply an extension to DSN.  The extension to DSN is that the
per-recipient-fields get a new, possibly repeating set of fields.  Those
fields are the per-part-fields of draft-ema-vpim-pndn-00.txt.  The
action-field and status-field for each part becomes part-action-field and
part-status-field.

This preserves the mechanisms of DSN.

Open questions:

1. A general principle for Internet protocols is field order doesn't
matter.  In the above proposal, all body parts belonging to a given
per-recipient-field block must be contiguous.  That is, we cannot use a
blank line to separate the per-part-fields, as proposed in
draft-ema-vpim-pndn-00.txt.  This is because existing DSN implementations
would interpret the blank line to be a separator for the
per-recipient-fields, not per-part-fields.  One solution is to require the
part-action-field precede any other per-part-fields.  The choice of
part-action-field is because it's one of the two required fields.  Is this
a reasonable solution?

2. What should we do for the action-field and status-field for the message
as a whole?  If we have a critical-part indicator, then it's easy: if the
critical part got delivered, then the PNDN is an informational message;
otherwise, the PNDN is a failure notice.  If there isn't a critical-part
indicator, then there are three choices:
   a)  Always return failure
   b)  Always return success
   c)  Let the developer choose what's best
As a developer with a marketing department, I know which result we'll
return :-)  Actually, given that reality, I'm leaning to have PNDN be a
success/informational message, unless there's a critical-part indicator.
How does this fly?

TIA for your input.

--
- Eric Burger
<mailto:[email-masked]>
+1 301 212 3320

---

From: Graham Klyne <[email-masked]>
Date: Mon, 24 Jan 2000 11:40:36 +0000

>part-action-field is because it's one of the two required fields.  Is this

I would like to avoid the position dependence if possible, but don't have a 
concrete proposal at this stage.  I would suggest retaining the standard 
DSN format of per-recipient groups, and incorporating per-part headers 
within these groups by indicating the part id (somehow) within each such 
header.

>success/informational message, unless there's a critical-part indicator.

In the absence of a critical part indicator, then I would suggest that 
failure to deliver any part should be regarded as failure to deliver the 
message.

#g

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