Subject: [lemonade] Non-Client Compose and Forward Without Download

From: "Eric Burger" <[email-masked]>
Date: Wed, 28 Jan 2004 08:15:56 -0500

I think Ted hit the nail on the head with this one.  I didn't see any further discussion on the topic.  I think we need to tackle the issue of choosing Forward Without Download versus Non-Client Compose first.  Once we know the problem to solve, we can solve it.

At this time, I am only opening up a DISCUSSION on the lemonade charter scope.  What I am asking for is consensus that the charter is (or is not) appropriately scoped.

In particular, I am looking for discussion as to the need (technical and market) for Non-Client Compose.

Things I can think of, off the top of my head (where my hair used to be) are:

Pro:

- People tend to naturally gravitate to solve it.  Many Forward Without Download proposals artificially limit themselves to NOT address Non-Client Compose.

- Forward Without Download comes for free if we solve Non-Client Compose, as it is a proper subset.

- This is an interesting problem that keeps coming up.  There is the potential that a Forward Without Download solution can become obsolete in the very near future.

Con:

- The security issues of Non-Client Compose appear to be more complex than for Forward Without Download.

- Will we ever finish?

> -----Original Message-----
> From: Ted Hardie [mailto:[email-masked]]
> Sent: Monday, January 05, 2004 8:02 PM

[snip]

> There is a very critical scope question here, from my point of view.
> If the working group sees this task as developing what we might call
> "non-client compose", in which the client can direct some server
> (be it Submit or IMAP) to assemble a message from multiple
> data sources without downloading the parts, then the "compose
> from a single, local data source" would be a degenerate case of the
> "non-client compose".    Using the same mechanism for the
> degenerate case as the full functionality makes lots of sense.
[snip]
> Again speaking personally, if the consensus of the working group
> is that the task is "non-client compose", rather than "forward without
> download", then I am not really sure that either a Submit server or
> an IMAP server would be the right place to do the work.  Revisiting
> the use of a multi-function proxy might be appropriate in that
> case, because the core functionality may be beyond what are
> safe and sane ways to extend IMAP or Submit servers.  I am nagged,
> though, by the idea that we will end up re-inventing the remote shell,
> as that is what I and many others use to handle this problem
> (I sometimes use ssh to reach a remote server with better connectivity
> when I need to handle email over a very poor link; sometimes, though,
> I take it as a sign to take a day or two away from email.  This is the
> source of the delay in my reply to this message.  Apologies for any
> inconvenience).

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