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

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 2 Feb 2004 12:04:40 -0600

I believe in cutting down the problem to the minimum we can all agree to.  The minimum we agreed we needed at chartering time is forward without download.  That is still enough for me to make standards-based compelling products and services.  I note that the emerging wireless messaging market is demanding, and industry is providing, products that perform forward without download. I see no such pressure for generalized client composition.

The question on whether to upscope already has prevented a decision on the planned timeframe and threatens to delay this key decision well past Korea.  I fear that the more "speculative" work towards a general client composition extension will unnecessarily delay our work and entrench the growing base of proprietary HTTP or WAP-based solutions. 

We are blocked on this decision... many lemonade-required protocol elements can't be designed until we know whether we are push or pull.  

Greg V.

-----Original Message-----
From: Eric Burger [mailto:[email-masked]]
Sent: Wednesday, January 28, 2004 7:16 AM
To: IETF LEMONADE (E-mail)
Subject: [lemonade] Non-Client Compose and Forward Without Download

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

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 2 Feb 2004 11:34:54 -0800 (PST)

I am very distressed by the implication that a final decision must be made
in Seoul.  Many of us don't have the luxury of employers who will pay for
unlimited junkets around the world, and will not be in Seoul.

The argument of "we have to do something now, otherwise our competition
will overwhelm us" has been used many times to cover many sins.  In our
own field of email, we are being overwhelmed by viruses brought about by
email software which had to display pretty pictures and sounds "now"
without waiting for proper engineering.  We should learn from this lesson
and repeat the same mistake.

We are the Internet *Engineering* Task Force, and should keep that word
"engineering" in mind.

Both the pull and push strategies include composition.  Indeed, one of the
variants of pull strategies outlined in
 draft-crispin-lemonade-pull-00.txt
uses the same composition facility that has been advanced for pull.

Push requires composition, as does two of the three variants of pull.  If
you reject composition as a task, then the *only* choice is pull with the
embedded URI variant, as described in
 draft-crispin-lemonade-pull-00.txt

Although the embedded URI variant of pull is the simplest of all choices
from a client submission protocol standpoint, it doesn't address all the
problems.  In particular, a solution to the fcc problem is needed.  I have
some ideas on how to do this, but I didn't want to waste too much time
working on it given that two of the other three choices solve the fcc
problem.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.