Graham Klyne (GK@Dial.pipex.com)
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 <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 Thu Jan 06 2000 - 20:50:10 IST