
Message-Id: <libSDtMail.9611120129.25729.toga@saki/saki>
Date: Tue, 12 Nov 1996 01:29:33 -0800 (PST)
Reply-To: John Togasaki <john.togasaki@eng.sun.com>
Sender: owner-ietf-822@list.cren.net
Precedence: bulk
From: John Togasaki <john.togasaki@eng.sun.com>
To: ietf-822@dimacs.rutgers.edu
Subject: Use of multipart/digest
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Pe4YnMIPUCybPUT9Ui5ekA==

I have a question about the use of multipart/digest and how other
mail user agents treat this content type.  There are a couple of
cases where we are considering using multipart/digest, and I was
wondering (1) how other mail clients out there would handle it
and (2) what people's opinions are about how to handle these cases.

The first case is when a user selects several messages from the
header list in the client and drags and drops them as a group
onto the attachment pane of the Compose window.  Since we are
on a Unix system, we package up the messages in the Unix mbox
format with "From " lines at the beginning of each message.  This
is so that if they are dropped on the file manager, they will
be saved as a Unix mailbox; otherwise, we would lose the ability
to type it as a mailbox.

But when the buffer is dropped on the attachment pane of our mail
client, we have control over how the data should be represented.
We could repackage the data and turn it into a multipart/digest,
where each of the dropped messages would be a message/rfc822, or
we could keep the data as it was dropped and create something like
a text/x-sun-mail-file.

On the receiving end, double-clicking on an attachment with the
type text/x-sun-mail-file would be just like opening up a mailbox
from the file system.  So if we were to send it out as multipart/
digest instead, then when the user double-clicked on the attachment
we would convert it to the mailbox format so that it could be
opened as a mailbox.  The disadvantage is that it might break the
ability of some older unix mailers to open these attachments as
mailboxes; but the advantage is that it might allow MIME-compliant
non-Unix mailers to have an easier time reading these messages.

Ideally, other MIME-compliant mailers would also open multipart/digest
messages as mailboxes (however they represent open mailboxes) and would
be able to save them as mailboxes in their native format.  What I would
like to know is how many mailers would handle multipart/digest in a
reasonable way?

The second (very similar) case is when adding a mailbox attachment from
the file system.  Again, in this case, each message has a Unix From line
at the beginning of each rfc822 message.  Should we convert it to a
multipart/digest or should we leave it alone and call it text/x-sun-mail-file?
If we made it a multipart/digest, then they would lose the information
contained in the From headers when they receive it on the other end, but
more mailer clients may be able to read the messages as messages.

On the one hand, we would like to interoperate with as many mail clients
as possible, but on the other we don't want to leave users of our older
mail clients dead in the water.  Are there any mail clients out there
that would treat a multipart/digest as a mailbox?  How do other mailers
handle the problem of sending around mailboxes, along with the associated
interoperability issues?


    Thanks,
    
     John Togasaki
     john.togasaki@sun.com
     SunSoft


Received: from cnri by ietf.org id aa04214; 12 Nov 96 9:41 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa10981; 12 Nov 96 9:41 EST
Received: from localhost (localhost.0.0.127.in-addr.arpa [127.0.0.1]) by list.cren.net (8.7.6/8.6.12) with SMTP id JAA23890; Tue, 12 Nov 1996 09:27:09 -0500 (EST)
Received: from dimacs.rutgers.edu (root@dimacs.rutgers.edu [128.6.75.16]) by list.cren.net (8.7.6/8.6.12) with SMTP id JAA23863 for <ietf-822@list.cren.net>; Tue, 12 Nov 1996 09:26:47 -0500 (EST)
Received: from glaucus.cso.uiuc.edu (glaucus.cso.uiuc.edu [128.174.81.2]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with ESMTP id JAA09237 for <ietf-822@dimacs.rutgers.edu>; Tue, 12 Nov 1996 09:26:35 -0500
Received: from resnick1.isdn.uiuc.edu (resnick1.isdn.uiuc.edu [192.17.16.67]) by glaucus.cso.uiuc.edu (AIX4.2/UCB 8.7/8.7) with ESMTP id IAA03380; Tue, 12 Nov 1996 08:27:20 -0600 (CST)
Message-Id: <v03100801aeae328f7f03@resnick1.isdn.uiuc.edu>
Date: Tue, 12 Nov 1996 08:14:06 -0600
Sender: owner-ietf-822@list.cren.net
Precedence: bulk
From: Pete Resnick <presnick@qualcomm.com>
To: John Togasaki <john.togasaki@eng.sun.com>
Cc: ietf-822@dimacs.rutgers.edu
Subject: Re: Use of multipart/digest
In-Reply-To: <libSDtMail.9611120129.25729.toga@saki/saki>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Sender: resnick@glaucus.cso.uiuc.edu
X-Mailer: Eudora [Macintosh version 3.1a8]
X-Listprocessor-Version: 8.1 -- ListProcessor(tm) by CREN

On 11/12/96 at 3:29 AM -0600, John Togasaki wrote:

>But when the buffer is dropped on the attachment pane of our mail
>client, we have control over how the data should be represented.
>We could repackage the data and turn it into a multipart/digest,
>where each of the dropped messages would be a message/rfc822
[...]
>Ideally, other MIME-compliant mailers would also open multipart/digest
>messages as mailboxes (however they represent open mailboxes) and would
>be able to save them as mailboxes in their native format.  What I would
>like to know is how many mailers would handle multipart/digest in a
>reasonable way?

This is exactly how we intend to implement this feature (it is not yet
done), and Eudora right now (at least on the Mac side; I forget whether the
Windows guys got this finished for 3.0), we handle it exactly as you
describe, with a mailbox attachment to the message, which the user can
double-click to open and look at all of the messages inside. I urge you to
implement it exactly this way.

>The second (very similar) case is when adding a mailbox attachment from
>the file system.  Again, in this case, each message has a Unix From line
>at the beginning of each rfc822 message.  Should we convert it to a
>multipart/digest or should we leave it alone and call it text/x-sun-mail-file?

Please, turn it into a multipart/digest. It is the perfect way to do this.

>If we made it a multipart/digest, then they would lose the information
>contained in the From headers when they receive it on the other end, but
>more mailer clients may be able to read the messages as messages.

The envelope return path in the "From" header should already be in the
"Return-Path:" header of the message and the delivery date-time should be
in the topmost "Received:" header if your local delivery agent did the
right thing. As far as mailers being able to read the messages: If they're
not MIME mailers, they'll be able to read them without a problem. If
they're MIME mailers, they should treat the message/rfc822 as text and
therefore should do reasonably. In any case, some of us will handle them
*much* better if they're in multipart/digest form.

pr

--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980