Eric.Burger@centigram.com
Wed, 1 Mar 2000 13:23:01 -0800
Comments in-line.
Graham Klyne <GK@Dial.pipex.com> on 02/17/2000 02:39 PM GMT wrote:
> At 02:55 PM 2/15/00 -0800, Eric.Burger@centigram.com wrote:
> >Document: draft-ema-vpim-pndn-01.txt February 15,
> >2000
> >
> > Partial Non-Delivery Notification
>
> Eric,
>
> I thought this read very well. Even the bits I would have been inclined
to
> disagree with, I found to be well-justified.
>
> I have a few minor comments.
>
> Firstly: a process matter: this was announced by the IETF as draft
> version -00? Is this really correct? Was the -00 version never
published
> as an I-D?
You are absolutely correct. The RFC editors changed the -01 to -00. I'm
submitting a new draft incorporating the following changes, as well as a
few formatting bug fixes, as -01.
> [Page 4:]
>
> > NOTE: An alternative method of handling partial delivery is to
> > determine what parts of the message the sender considers critical.
>
> "alternative" here seems to imply mutual exclusion. I would prefer,
say,
> "An additional method ...".
How about "NOTE: Another method..."
[snip]
> > delivered message. The VPIM work group determined this method, in
> > practice, would be too complex to implement and would have the
> > drawback of the voice mail system silently deleting message
> > components. In light of the limitations of voice mail systems, we
[snip]
> You say "The VPIM work group determined ...". Is this true? I don't
> recall seeing this particular point discussed on the mailing list; did
I
> miss someting?
We didn't discuss this on the list. I'll take the hit for that. We
discussed it at the EMA VPIM meeting in November. That was my
interpretation of the discussion. However, it's not that clear looking at
the meeting minutes. How about this language:
the delivered message. However, currently there is no method to
identify critical parts. In light of the limitations of voice
mail ...
What I'm really saying is that until there is a critical-part mechanism,
there's nothing available to us other than PNDN's.
>
> [...]
> >5.3.4. Original Content ID Field
> >5.3.5. Original Content Description Field
> >5.3.6. Original Content Disposition Field
> >5.3.7. Original Content Type Field
> >
> > This field, if present in the original message, MUST be present in
> > the PNDN.
>
> Similarly: "... if a 'Content-type' field is present in the original
message."
Excellent English. I've incorporated the re-organized sentence structure.
Note I've expanded the Original-Content-Disposition paragraph to be more
clear, as well:
# The Original-Content-Disposition field MAY be present in the PNDN
# if a Content-Disposition field is present in the original message.
# If the original message does not have a Content-Type field, the
# Original-Content-Disposition field MUST be present in the PNDN
# if a Content-Disposition field is present in the original message.
# The Original-Content-Disposition field aids the sender in
# understanding exactly which body part the receiving system is
# not capable of delivering. This field will be more useful than
# the Original-Content-ID field to a human sender. It will let the
# human know the file name of the part the receiving system is
# not capable of handling.
>
> >5.3.8. Status Field
> >
>
> [...]
>
> Define status values here (or put in placeholders for them)?
>
> (I think the approach of defining the status value(s) in the formal
syntax
> is not so helpful.)
I put it in 5.3.8, and took it out of 7.2.
A new draft will be out under separate cover.
-- - Eric
This archive was generated by hypermail 2.0b3 on Wed Mar 01 2000 - 23:20:36 IST