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

From: Dan Wing <[email-masked]>
Date: Mon, 14 Sep 1998 18:12:26 -0700

>>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>

Very true, thanks.  Updated.

>>   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.

Thanks.  

>>   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?]]

I hadn't caught that.  Thanks.  Ned?  (Voice might work better for
this question).

>>   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.

Well, the whole point of the I-D is to provide extensions - I 
could say MUST, even.  I don't think it makes much difference.

>(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)

Implementation choice.  I guess I should say that the recipient
should indicate which version is 'most preferred'.

>>   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 is already supported in the existing document, but only for 
a message a multipart message where more than one part contains
a multipart/alternative, like this (ignore indenting, which is
only to make it easier for people to read):

  multipart/mixed; boundary=123
  
  --123
  content-type: text/plain

  --123
  content-type: multipart/alternative; boundary=aaa

    --aaa
    content-type: text/plain
    content-id: <ejfke>

    --aaa
    content-type: text/html
    content-id: <ejfjekfejk>

    --aaa--
  --123
  content-type: multipart/alternative; boundary=bbb
  
    --bbb
    content-type: image/jpeg
    content-id: <ejfkejfkejfkjekfe>
  
    --bbb
    content-type: image/tiff
    content-id: <jekfejkfejjekfjekfjekfjef>

    --bbb--
  --123--

>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.)

That's implicit behavior.

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

Yes, it does.

>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?

Sure, but rfc1893's status codes aren't applicable (most deal with
only delivery, which makes sense becuase rfc1893 is related to 
delivery).

Note that with current email technology, the MUA usually doesn't
know that a launched application failed to successfully read an
attachment.  Thus, defining a bunch of codes isn't likely to cause
anything to happen with them (for failures).

>>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.)

I deleted the words "or simply ignoring the cryptographic signature." 
as the types of failures here aren't interesting.

Thanks for your comments!
-Dan Wing