Subject: draft-ietf-fax-mdn-multipart-01.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 09 Sep 1998 18:47:03 +0100

My comments are based on a reading of an earlier draft, but I apply them
here to the latest version I have.

#g

>1.  Abstract
>
>   This document describes how a Message Disposition Notification
............................<----

<PEDANT>
Strictly, I think it describes the format and when to generate such an MDN,
not "how to return" it.
</PEDANT>

>   can be returned which indicates which part(s) of a multipart/
>   alternative message the recipient processed.

[...]
>3.  Extension to Message Disposition Notifications
>
>   If a sender is interested in knowing which parts of a
>   multipart/alternative message were usable by the recipient's MUA, the
>   sender MUST include the "Disposition-Notification-To" field in the
>   RFC822 headers (as described in [RFC2298]), and MUST include
>   a "Content-ID" field on each part of the multipart/alternative so
..................^ Reference [RFC2045] might be helpful here.

>   the recipient can indicate which part of the multipart/alternative
>   was processed.

I note there is a possible conflict between this and the final paragraph of
RFC2046 section 5.1.4 (semantics of content-id).  To work, the scheme here
requires each part of multipart/alternate to have a separate content-id
value.  RFC2046 suggests that if different parts represent the same data
without loss then they should have the same content id.  As I see it, that
is only a recommendation;  but then this draft should at least make a
specific statement saying that each part MUST have a distinct content ID.

[[Ned: do you have any comment to make?]]

>   If the recipient's MUA decides to generate a Message Disposition
>   Notification, it may include the additional fields defined
.....................<-> MAY ?
>   below to indicate which part of the multipart/alternative
>   part(s) were processed.

(I think this section is a great improvement over the corresponding text in
-00)

>3.1.  Deciding when to generate an MDN
>
>   The recipient's MUA MUST NOT generate an MDN for parts which were not
>   used by the MUA.  For example, in a multipart/alternative only one of
>   the parts is displayed or processed; the other parts are not used and
>   are not included in the MDN.  Note this differs from a part that
>   failed processing after an attempt to process.

What if more than one part is used?  I note that while RFC2046 (section
5.1.4) suggests use of a single part, it does not prohibit use of multiple
parts.  (See also comments below)

>   If the recipient's MUA attempted to decode a media type it expected
>   to decode, such as an image/gif when the MUA includes an GIF viewer,
>   but the GIF was corrupted, the MUA should generate an MDN indicating
>   that an error occured while processing that part [MDN-ERROR].  If the
>   corrupted part is enclosed in multipart/alternative, the MUA may
>   attempt to process one of the alternatives, which may cause
>   generation of another MDN.
>   
>   XXX - how to prevent generation of multiple MDNs (which is illegal)?

I wonder if MDN might be extended using a framework similar for that used
with DSN, which has a single set of "per-message" fields, followed by one
or more "per-recipient" fields.  In this case, I am thinking of a
"per-message" field followed by zero or more "per-content-part" fields,
where each "per-content-part" group is introduced by an
"original-content-ID" and possibly content disposition status fields for
that part.

This approach would allow a single MDN response to carry information about
the disposition of multiple body parts.  And I think this would be in a way
that should not break existing UAs (I am assuming they ignore field with
unknown names, even though I could find no requirement for such behaviour
in RFC 2298.)

I believe the existing syntax allows multiple Original-content-ID fields in
this way.

I would expect the "Disposition" field to indicate overall disposition for
the message, with possible errors with specified parts indicated by
following "Original-content-ID" fields.

(More comments below...)

>3.2.  Original-Content-ID field
>
>   The Original-Content-ID indicates which part of a
>   multipart/alternative was processed.  The syntax for this field, per
>   the format described in [ABNF], is:
>
>        extension-field = 1*( ocid CRLF )
>        ocid            = "Original-Content-ID" ":" content-id 
>                          [ error-indicator ]
>                          
>        error-indicator = ";" "error" 
>
>   The <content-id> token is the Content-ID that was specified in the
>   part that was processed by the MUA.
>   
>   Multiple "Original-Content-ID" fields MUST NOT appear except when
>   there were multiple multipart/alternative content-types in the
>   message.
>   
>   A MUA that receives a message with more than one
>   multipart/alterntives content type may wish to indicate a Disposition
>   of "displayed" or "displayed / error" for various reasons.  To allow
>   this, the <ocid> field can indicate which parts of those
>   multipart/alternatives actually failed.  The <error-indicator> MUST
>   NOT be present unless the original message contained more than one
>   multipart/alternative content-type.  Note if the <error-indicator> is
>   present it MAY disagree with the "Disposition:" field of the MDN.

I note this -01 draft anticipates the comments I made above based on the
-00 draft.  This leaves me with a much smaller comment:  would it be useful
to allow some kind of status code to be provided to give more detailed
information about the reason for failure?

>4.  Security Considerations
>
>   In addition to the security considerations described in [MDN], this
>   extention provides additional information to the sender.  For
>   example, knowledge of the successful or unsuccessful processing of a
>   cryptographically signed message can tell a sender if the recipient
>   is authenticating messages or simply ignoring the cryptographic
>   signature.
.............^ or checking the signature but not checking the validity of
supplied certificates.

(e.g. in some situations self-signed certificates, or certificates signed
by a non-existent CA, provide no more than an integrity check on the message.)

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