Subject: RE: [lemonade] Call for requirement consensus

From: Erev Ari <[email-masked]>
Date: Wed, 11 Jun 2003 18:08:34 +0300

I agree.

I think that the message part granularity is "good enough".

Maybe after getting some experience and better understand this level of
functionality, it could be extended (optionally?) to a full-blown
"composition server". Looks to me a bit premature at this time...

Ari 

> -----Original Message-----
> From: Vaudreuil, Greg M (Greg) [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2003 5:38 PM
> 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.
> 
> -----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
>