Diana McMurtrey (dianamcm11@sprintmail.com)
Sun, 23 Jan 2000 21:14:19 -0700
OK.. I give... can someone please remove me from this mailing list...
-----Original Message-----
From: Graham Klyne <GK@dial.pipex.com>
To: Eric.Burger@centigram.com <Eric.Burger@centigram.com>
Cc: IETF fax WG <ietf-fax@imc.org>; IETF VPIM List <vpim@lists.neystadt.org>
Date: Thursday, January 06, 2000 13:02 PM
Subject: draft-ema-vpim-pndn-00.txt
>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 <MAILER-DAEMON@TELECNNCT.COM>
>> Message-Id: <199407072116.RAA14128@TELECNNCT>
>> Subject: WARNING: Could Not Delivery Body Part
>> To: <ericb@mtc.telecnnct.com>
>> 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 >> from root@localhost
>>
>> ----- The following addresses had delivery problems -----
>> <eric.burger@telecnnct.com> (warning)
>>
>> ----- Transcript of session follows -----
>> Could Not Deliver Text Part to < eric.burger@telecnnct.com >
>> 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
>(GK@ACM.ORG)
>
>
This archive was generated by hypermail 2.0b3 on Mon Jan 24 2000 - 06:03:10 IST