Graham Klyne (GK@dial.pipex.com)
Mon, 24 Jan 2000 11:40:36 +0000
At 08:02 PM 1/20/00 -0600, Eric.Burger@centigram.com wrote:
>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?
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.
>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.
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
(GK@ACM.ORG)
This archive was generated by hypermail 2.0b3 on Mon Jan 24 2000 - 14:13:34 IST