Re: Why are we here? What are our goals?

----- Original Message ----- 
From: "Nathaniel Borenstein" <[email protected]>
To: <[email protected]>
Sent: Thursday, January 29, 2004 4:30 PM
Subject: Why are we here? What are our goals?


>
> [Sincere thanks to Paul for starting this list.]
>
> As I stated on another mailing list, I'd like to see our email-ng
> efforts start with requirements analysis.  However, I've always found
> it useful to start by compiling a wishlist,  as raw data for
> requirements abstraction and tradeoff analysis.  So I'd like to start a
> wish list of "plausible stuff it would be cool to include in email-ng."
>   Here's what I've got so far (I don't actually advocate all of these):
>
>  -- internationalization, esp. of addresses
>  -- enhanced tracing mechanisms
>  -- generalized challenge/response mechanisms
>  -- transport-level authentication
>  -- binary transport  (phasing out C-T-E's)
>  -- Cleaner separation of header, envelope, and body
>  -- structured local-part syntax
>  -- economic mechanisms (postage, attention bonds)
>
> I suggest that we try to grow this into a highly inclusive list of
> "desirable things" and then attempt to determine a sensible subset to
> work on.    -- Nathaniel

Why are we here? What are we goals?

These questions is best answered by first answering or outlining the
"Problems."  What are the industry probllems?  I am still from the school of
thought that the best solutions are those that address real problems.  Best
means, that it foremost solves the problem, has major benefits,  and most of
all, it is acceptable by all (majority) of the industry.

Maybe I am too much of a generalist, but in my view the basic problem we
have today is:

- anonymous access" control issues.

This is the main reason, I believe, most of us are here now.  This is why
there is major industry cry for change.  So the most obvious FOCAL POINT for
a new system is to first address this basic fundamental issue of anonymous
access control.

Of course,  once we have the opportunity to address the main problems, it
also offers us the opportunity to consider other design ideas that might be
viewed as equally or less important.   But I would like to stress that these
additional ideas SHOULD not remove the main focus of addressing the MAIN
problem.  IMO, we need to have a concensus on this design goal because
otherwise, in my view, this will be a complete waste of time.

With that said,  my input to your list is to add Keith's input, re-order
them by priority, consolidating some of them and addng my own:



Anonymous/Access Control issues


*-- Frontend based Network Bandwidth Reduction Ideas (NEW) (Keith, this can
be part of enhanced reliability, see below on DNS ideas)

 -- transport-level authentication

 -- enhanced tracing mechanisms

 -- improving error reporting (see below)


 -- generalized challenge/response mechanisms  (Not to be confused with
poorly titled C/R sender validation concepts).

 -- economic mechanisms (postage, attention bonds)


Data format issues

 -- internationalization, esp. of addresses
 -- Cleaner separation of header, envelope, and body
 -- structured local-part syntax

DTP (Data Transfer Mechanism)

 -- binary transport  (phasing out C-T-E's)
*-- client/server,  server/client (State Phrase Change) (NEW)
 -- improving transparency of the MTS (which is a broader topic than  binary
transport)
 -- clean separation between submission and relaying

Gateway Ideas

 -- better support for "integration" between various messaging services

Common, Setup, Configuration Ideas

-- improve configuration (for both users and admins) so it is less
error-prone
*-- DNS-based setup, Signup Ideas (NEW) (Keith, probably goes under basic
improvement line item, just wanted to highlight the DNS setup should be part
of software,  see below)

In regards to DNS setup,  I think part of the solution is improving DNS in
terms of "adding more value" to the require queries a system might have to
do which can offer ideas of reducung network bandwidth.

DNS Improvement Ideas

-- New MX domain naming format can be used to provide additional system
information.

-- Alternative MX record lookup that provide important attribues that
enhances frontend reliability and lowers network bandwidth using policy
concepts such as "System Hours"  "Allow Spam, No Spam"

That's my input for now.  I just want to make sure that we focus of solving
the key industry problem with whatever new solution is considered - that is
anonymous access.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com