Victor Engmark wrote:
[mailto:owner-mail-ng(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Bruce Lilly
We should keep in mind the excellent suggestions
in RFC 1958. As this relates to user-visible
- users want a solution today, even if it is incomplete.
Conventional email with way too many "patches" to accommodate for
shifting user requirements is the solution today, and it is incomplete.
Users want a solution to today's problems with email as it currently is
implemented, especially spam and email-borne worms and viruses. They
want such a solution immediately. Other things, such as tie-ins with
instant messaging, etc. can wait. We already have a number of conflicting
goals; in order to produce something in a timely manner, we might well
have to defer resolving some of those conflicts, i.e. the solution
will be incomplete.
We should IMNSHO not let ourselves be held back by
the way email works today, because this will lead to further "patches",
and not the revolutionary new system this list is preparing goals and
One of the requirements I see emerging from the partly conflicting goals
is flexibility. The protocol should be extensible, and new extensions
should be formally expressed and approved.
Isn't one person's "extension" another person's "patch"? If not,
what is the distinction? Is ESMTP an "extension" or a "patch" to