Subject: RE: [lemonade] Re: Just 'ATTACH'

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 10 Jun 2003 19:23:31 -0500

I understand the requirements to be (1) below, the ability to forward one or more atomic messages, or for bonus points, to forward a single atomic body-part of a message.  Richer composition including inline quotation should be done on the client.   After all, download of text for re-composition is not generally expensive, and the client is likely to need the content anyway for the user to determine what needs to be quoted.

I don't see the requirement for submit server resolution of external documents and the like...  Maybe others have a need for that, but I see the resolution of an external URL as the obligation of the recipient UA.   

Greg V.

-----Original Message-----
From: Cyrus Daboo [mailto:[email-masked]]
Sent: Tuesday, June 10, 2003 11:37 AM
To: Randall Gellens; IETF LEMONADE (E-mail)
Cc: Doug Royer
Subject: Re: [lemonade] Re: Just 'ATTACH'

Hi Randall,

--On Monday, June 9, 2003 11:24 PM -0400 Randall Gellens 
<[email-masked]> wrote:

|>  SMTP commands can not be embedded into the DATA stream. So I do not
|>  think an ATTACH SMTP command will work. Although most MUAs display
|>  'attachments' in a separate pane, they are inline in just about any
|>  random order.
|
| We would be creating a new Submit extension mechanism.  Such a mechanism
| could be as simple as saying 'expand references external body parts that
| have the "expand" flag set'.  Note that during the discussions on
| developing a separate SMTP submit service from the SMTP relay service, it
| was suggested that future Submit extensions that were only useful for
| message submission should perhaps look quite different from SMTP
| extensions, to prevent them from leaking into SMTP relay.  One example
| would be a kind of envelope wrapping the transaction.  At the time, there
| was discussion of using a Submit service for various sorts of helpful
| things, including transcoding of voice attachments, creating a proper
| message, etc.

Can we have a clear statement of what exactly needs to be expanded for this 
application? The two possibilities I see right now are:

1) Expand entire MIME parts by substituting data from an outside source: 
external-body expansion.

2) Expand inline data (e.g. quotations in a reply or forward).

The former is relatively easy to do - just substituting one MIME part for 
another.

The later is much more complicated as it requires detailed knowledge of the 
data itself. This really requires a full-blown 'composition agent' that 
knows how to deal with character set and encoding issues for all components 
of the data being expanded, as well as data format issues (e.g. knows how 
to put together HTML fragments in a consistent manner). That definitely 
goes beyond anything that either SMTP or IMAP has had to do up till now.

If (2) is a requirement then I'd be more inclined to go with a third server 
option that has not been discussed much - namely having a new type of 
server a 'message composition server' that has all the logic and capability 
of a typical desktop MUA in terms of building rfc2822/MIME messages as well 
as the ability to pull in data from external sources (with an appropriate 
security model). As well as providing pointers to the source components of 
the message, the client of this server would also be able to specify the 
destination, which might be an IMAP server or an SMTP server or some other 
destination in a similar manner to IMAP CHANNEL. Has this third server 
option been ruled out for any reason?

-- 
Cyrus Daboo
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Rick Block <[email-masked]>
Date: Tue, 10 Jun 2003 19:23:00 -0600

Vaudreuil, Greg M (Greg) wrote:
> I don't see the requirement for submit server resolution
 > of external documents and the like...  Maybe others have
 > a need for that, but I see the resolution of an external
 > URL as the obligation of the recipient UA.

Obligation of the recipient UA?  I have a message from
[email-masked], I reply from my wireless device (with
original attached) and my friend anyone's UA is responsible
for putting the message together again (using pieces
of the original message sent to me obtained from my imap4
server)?  I must be misunderstanding this since it would
seem to require upgrading every UA everywhere in the world
and even if this could happen then requires my imap4 server
be accessible from anywhere.

Rick Block
Avaya Inc.