JSC-EV (richard.j.coles1@jsc.nasa.gov)
Mon, 24 Jan 2000 09:03:50 -0600
>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.
I have not posted to the FAX-WG in a VERY long time, but I must agree here,
that failure to deliver even the smallest part of a message is a failure,
period.
In fact, I thought this particular point was settled more than a year ago.
Maybe 2 years, I don't really recall any more.
Tnx/RJC
-----Original Message-----
From: Graham Klyne [mailto:GK@dial.pipex.com]
Sent: Monday, January 24, 2000 5:41 AM
To: Eric.Burger@centigram.com
Cc: IETF fax WG; IETF VPIM List
Subject: Re: [VPIM] Re: draft-ema-vpim-pndn-00.txt
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 - 17:03:12 IST