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

From: Graham Klyne <[email-masked]>
Date: Thu, 06 Jan 2000 18:47:37 +0000

I've finally got around to reviewing the partial NDN draft, and have a few 
comments for your consideration...

My biggest single question with this draft is that it uses a new report 
type, rather than just extending the DSN report format (which is, after 
all, an extensible format).  I fear the consequence of this may be that 
interoperability between voicemail systems (and any other systems that 
implement PNDN) and traditional e-mail systems may be harmed.

Specifically, what is a traditional e-mail agent to make of a response 
message of the form:

     Content-type: multipart/report;report-type=partial-delivery-status

I think it would be much easier to achieve clean interoperability with 
existing e-mail systems if the existing DSN report format were to be used, 
with extension fields (as permitted by the DSN spec) used to convey the 
additional information about partial delivery, but which can be ignored by 
sending systems that have no concept of partial delivery, but which may 
still usefully receive some indication of successful delivery.

I recognize this approach raises some questions and challenges.  Some are:
- for a sender that does not recognize partial delivery, should this 
condition be prresented as "delivered" or some other status?
- how to handle multiple recipients without causing unreasonable growth in 
the size of the status report?  (I think that the idea of eliding multiple 
recipients into a single "per-recipient" part might be a useful extension 
to the DSN report form, but if that causes compatibility problems then it's 
not really an option.)
- resolving privacy concerns regarding recipient fields.

The rest of my comments are mostly nits and presentational issues related 
to specific parts of tyhe text, as noted below...

>3.
>   Introduction

[...]
>    This Internet draft addresses the need to allow desktop e-mail
>    client applications to send arbitrary multi-part multimedia messages
>    to voice messaging systems, retaining the semantics of delivery
>    notification, taking into account the limitations of the voice
>    messaging system rendering limitations.  The method described by
>    this Internet draft is applicable to any interface between a full-
>    featured user agent and a recipient mail transfer agent that has
>    less rendering and media type storage capabilities than the sender
>    has.
>
>    Ideally, the voice mail system would notify the recipient of the
>    undeliverable body parts.  Such behavior would satisfy the essential
>    requirements of [8].  In fact, if the voice mail system can notify
>    the recipient there were undeliverable body parts, then there would
>    be no need for this RFC.  However, many voice mail systems are not
>    capable of making this notification.

References above to "this Internet draft" and "this RFC" -- I suggest are 
changed to "this document"

>    NOTE: An alternative method of handling partial delivery is to
>    determine what parts of the message the sender considers to be
>    critical.  If the voice mail system could not deliver the critical
>    parts, then the voice mail system would reject the entire message.
>    If the voice mail system could deliver the critical parts, but there
>    were other parts the voice mail system could not deliver, it would
>    silently delete the parts from the 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 decided to deliver as much of the message
>    as possible, notifying the sender of any parts that the voice mail
>    system fails to deliver.

While I do not disagree with this assessment, I'd also note that it does 
not completely eliminate the possible use of a "critical content" indicator 
-- with the intent that if indicated critical content cannot be delivered 
then nothing should be delivered.  (In the absence of such indication, no 
part being regarded as critical.)

>4.
>   Operation

[...]

>    If the recipient system is capable of only delivering part(s) of the

Nit:  "only delivering part(s) ..." --> "delivering only part ..."

>    message, it will return a partial non-delivery notification (PNDN)
>    as described below.

[...]

>    NOTE:  We chose Delivery Status Notification (DSN) [3] over Message
>    Disposition Notification (MDN) [8] as a model for PNDN.  There was
>    some discussion on this point because an Internet Voice Mail system
>    acts as both a UA and a MTA.  The Message Disposition Notification
>    deals with things such as return receipt.  The generation of the
>    return receipt can occur long after the receiving system has
>    received the message.  On the other hand, the receiving system can
>    know on receipt whether it has the capabilities to deliver all parts
>    of the message.  In this case, the recipient acts more like an MTA a

Nit: insert "than" after "MTA"

>    UA.  In addition, we decided it was more important for the sender to
>    know the system would never deliver some parts of the message.  It
>    would not be desirable to wait for the recipient to attempt to read
>    the message and only at that point generate a notification that the
>    system could not deliver parts of the message.

While I do not disagree with this assessment, I'd also note that there is 
still possible use for a partial processing indication (especially in the 
context of Internet fax, where I understand that per-page processing 
indications are perceived by some to be useful).  I think it would be good 
if the mechanisms introduced could be easily adapted to MDNs as well as DSNs

>5.
>   Contents of the PNDN

[...]

>5.1. The message/partial-delivery-status content-type

As already indicated, my preference would be for introducing this 
functionality as an extension to message/delivery-status, rather than a new 
report type.

[...]
>    The body of a message/partial-delivery-status consists of one or
>    more "fields" formatted according to the ABNF [10].

Nit:  RFC2234 [10] does not define "fields".  Irt defines a notation for 
describing fields.  The field formats are described in [DSN] and later 
in  this document.

[...]

>5.3. Per-Part PNDN Fields
>
>    A PNDN contains information about attempts to deliver a message's
>    parts to one or more recipients.  A group of contiguous per-message
>    body-part content partial non-delivery notification fields contains
>    delivery information for that body-part.  A blank line precedes each
>    group of per-part fields.

Partly because I would prefer extension to the DSN format, I also think it 
would be better to develop from the DSN concept of "per-recipient" fields, 
possibly having "per-recipient+part" fields.  I would view collapsing these 
into a single group when the same information applies to more than one 
recipient as a possibly useful optimization.

In any case, I think the text here should be clearer about the handling of 
responses dealing with multiple recipients and multiple message parts.

>5.3.2. Action Field
>
>    The action field reflects the disposition of the message.  Since the
>    receiving system can deliver at least part of the message, the
>    action value is "delivered".  If the recipient system did not
>    deliver any parts of the message, then it would perform the normal
>    undeliverable message processing described by DSN [3].

I was thinking that it would be nice if the concept of partial delivery 
could be noted in the "action" field.  But it seems that this is not an 
extensible value set per [DSN], so I guess that's not an option.

>5.3.3. Final Recipient Field
>
>    The Final-Recipient field indicates the recipient for which this set
>    of per-part fields applies.  The definition of the final recipient
>    field is as described by DSN [3].  However, for security reasons,
>    the PNDN relaxes the imperative for including this field.  That is,
>    the per-part data MAY include the final recipient field
>
>    NOTE:  The change in imperative, from MUST to MAY, comes from the
>    Internet Voice Mail environment.  One can envision Internet Voice
>    Mail implementations where the service provider wishes to keep the
>    actual host name of the voice mail system hidden yet in the Internet
>    name space.  Reporting the final recipient field may include the
>    actual host name of a voice mail node.  Making that information
>    public through a PNDN may enable attacks on that node.

Why is this not an issue with traditional e-mail?

Also, why is the "original-recipient" field only optional for DSN, while 
final-recipient is mandatory?

>6.1. PNDN With One Failed Body Part
>
>    This example shows a PNDN for a system that does not handle text,
>    but does handle voice and fax.
>
>
>
>    Date: Thu, 22 Nov 1999 09:05:15 -0800
>    From: Mail Delivery Subsystem <[email-masked]>
>    Message-Id: <199407072116.RAA14128@TELECNNCT>
>    Subject: WARNING: Could Not Delivery Body Part
>    To: <[email-masked]>
>    MIME-Version: 1.0
>    Content-Type: multipart/report; report-type=delivery-status;
>          boundary="RAA14128.773615765/TELECNNCT.COM"

Report type inconsistent?

(Similarly for examples in sections 6.2, 6.3, 6.4)

>    --RAA14128.773615765/TELECNNCT.COM
>
>    The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
>    from root@localhost
>
>       ----- The following addresses had delivery problems -----
>    <[email-masked]>  (warning)
>
>       ----- Transcript of session follows -----
>    Could Not Deliver Text Part to < [email-masked] >
>    Body part will be deleted from queue
>
>    --RAA14128.773615765/TELECNNCT.COM
>    content-type: message/partial-delivery-status

[...]

>7.
>   Formal Syntax

[...]

>    original-content-id-field =
>              "Original-Content-ID" ":" content-id
>
>    original-content-description-field =
>              "Original-Content-Description" ":" content-description
>
>    original-content-disposition-field =
>              "Original-Content-Disposition" ":" content-disposition
>
>    original-content-type-field =
>              "Original-Content-Type" ":" content-type

Where are the syntax terms content-id, content-description, 
content-disposition and content-type defined?

---

That's my lot.

Thanks for your efforts in preparing this.

#g

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 06 Jan 2000 16:01:23 -0500

offhand, I believe the best indication of partial delivery would be
a nondelivery report (DSN with failure status) with an appropriate 
status code indicating inability to decode the message or some such.  
It could have additional fields explaining which pages were printed etc.

that way, a system that didn't understand partial delivery would
see a delivery failure notice  and perhaps notify the sender of
the failure (along with the error message indicating partial failure); 
while one that did understand partial delivery could examine the
additional fields.  

this seems to me better than having a separate kind of delivery report 
for partial delivery. 

Keith