Subject: [lemonade] Call for requirement consensus

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Wed, 11 Jun 2003 09:37:30 -0500

Do we all agree that lemonade requirements should specify a basic forward of message or atomic message part without download and not a remote composition service?

I am interested in hearing objections and reasons or examples of where a remote composition service would be of material benefit in scope of the lemonade charter goals.

Greg V.

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

Hi Cyrus,

At 12:36 PM -0400 6/10/03, Cyrus Daboo wrote:

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

This is what has been discussed to date, as far as I recall.

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

I don't recall hearing of this before the most recent series of 
emails.  As far as I know this type of detailed composition server is 
not a requirement, because presumably the client would be capable of 
at least this level of composition.

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

If this type of composition service is required, then I'd tend to 
agree with you that it goes far beyond current IMAP or Submission 
capabilities and would need a new server, part of a full-blown split 
client mode.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
There once was a hacker named Ken
Who inherited truckloads of Yen
        So he built him some chicks
        Of silicon chips
And hasn't been heard from since then.
_______________________________________________
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: "Milt Roselinsky" <[email-masked]>
Date: Wed, 11 Jun 2003 08:43:20 -0700

Greg,

My recollection from our discussions during the lemonade meeting in SF
was that basic forwarding of messages and message parts is the requirement.

In any case, that's my vote for the requirement.  Remote composition
isn't needed.

Milt

> From: [email-masked] [mailto:[email-masked]]On Behalf
> Of Vaudreuil, Greg M (Greg)
> Sent: Wednesday, June 11, 2003 7:38 AM
> To: IETF LEMONADE (E-mail)
> Subject: [lemonade] Call for requirement consensus
> 
> 
> 
> Do we all agree that lemonade requirements should specify a basic 
> forward of message or atomic message part without download and 
> not a remote composition service?
> 
> I am interested in hearing objections and reasons or examples of 
> where a remote composition service would be of material benefit 
> in scope of the lemonade charter goals.
> 
> Greg V.
> 
>

---

From: Mark Crispin <[email-masked]>
Date: Wed, 11 Jun 2003 10:10:51 -0700 (PDT)

On Wed, 11 Jun 2003, Vaudreuil, Greg M (Greg) wrote:
> forward of message or atomic message part without download and not a
> remote composition service?

I would delete the phrase "and not a remote composition service".

I agree that a remote composition service is not necessary for the
requirements list.  However, it *is* one of the possible solutions and
thus should not be precluded by the requirements.

In other words, it is a requirement that there be a basic forward of
message or atomic message part without download.  Precise mechanism to be
determined.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Pete Resnick <[email-masked]>
Date: Wed, 11 Jun 2003 14:55:54 -0500

On 6/11/03 at 10:10 AM -0700, Mark Crispin wrote:

>message or atomic message part without download.  Precise mechanism 
>to be determined.

Something with which I wholeheartedly agree.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Jun 2003 19:58:08 -0700

ditto.

d/

>>message or atomic message part without download.  Precise mechanism 

PR> Something with which I wholeheartedly agree.

--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>