mail-ng
[Top] [All Lists]

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

2004-01-29 16:53:49


On 1/29/2004 3:30 PM, Nathaniel Borenstein wrote:

[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.

I'd start from a different design point, which is that I think we need to
re-figure what it is that email networks are supposed to do.

For me, messaging networks should provide a process-to-process tranport
service between disconnected terminal nodes.

For example, in the current model we have <user(_at_)domain> acting as node
addresses for the distributed network, with different kinds of processes
exchanging different kinds of data between those terminal nodes. In the
common case, those nodes are humans exchanging textual data, but in the
broader and ultimately desirable case, we should be designing to
facilitate human-to-machine and even machine-to-machine communications
between those nodes. Moreover, trying to design features around the
current model isn't really useful in that context.

So starting from that position:

  - assume there are multiple listening 'processes' at each terminal
    address, one of whom might be a human but another of which might
    be something like a chess-by-mail game, or a mailing list manager,
    or numerous other 'processes', and that all of them might be
    running at the same time. so we need some sort of process
    identification mechanism. conversely, argue that each process
    should have its own terminal address as is mostly the case now
    by design default (I strongly feel that is a bad default).

  - extensible architecture with minimalist core is fundamental.
    this means, for example, avoiding "built-in" anti-spam stuff,
    but instead design extensiblity so that the market and/or
    processes can use protocol plug-ins that provide the most
    appropriate protection mechanisms to their need. as far as that
    goes, if any feature isn't needed or terribly beneficial for 99%
    of the base, it should be an option/extension, and we should be
    designing to support a very large number of options/extensions.
    if one node/process wants to use email postage or another wants
    to use vcard-based whitelisting (or whatever, sticking to the
    anti-spam example above), let them use whatever suits their
    need and design to facilitate a large number of options.

  - transport-layer authentication is critical to most nodes and
    processes. while any process can (and arguably should) *also*
    sign the content, there must be a way for routers, nodes and
    processes to reject messages based on sender/path identity.

  - separation between transport headers and the content headers is
    fundamental to the larger design. transport headers identify
    the node address as well as the process at that node, while the
    content headers are only relevant to the target process.
    transport issues such as routing, prioritization (ToS/QoS), and
    so forth should deal with the transport headers, while content
    issues (message formatting, etc.) should never have to deal
    with those headers.

Lots more that I don't have time for right now, but I wanted to make the
point that we shouldn't be looking to fix the existing model but instead
should be rethinking what mail is all about, or what it should be about,
or what we want it to be about.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/


<Prev in Thread] Current Thread [Next in Thread>