I agree Eric.
If the scope is to be this wide, then we have not done enough yet. Paul
did provide what I personally feel is among the top two categories, "message
transport" and "message format", but the "message display" begins to muddy
the water of the first two and changes the "target market," hence the
required design.
What needs to be consider here to two related concepts in large scope
product design:
o Target market or audience, and
o Specialization
o Target Market
The beauty and part of the success of the Internet was that it offered
simplistic mail protocols (SMTP/POP3) and mail format (RFC 822) as the
common ground for all markets, such as, but not exclusive to:
- Company/corporate market
- ISP market
- Hobbiest market
- Spammer (Direct Marketing) market
- End user market
I believe MAIL-NG needs to be in that "common ground" category again to
facilitates faster deployment by enhancing acceptability that doesn't
dictate or require extensive change in backend integration. The reality is
that most implementations will most likely "integrate" mail-ng into a
current framework. They will have a "harder time" accepting the idea that
mail-ng should or could replace current systems or more than what is
feasibly possibly.
With the scope thus far laid out, unless we intend go to threw a
filtering/removing of requirement process, it begins to isolate the
intended market.
o Specialization
There is also another major real market issue with the larger scope design -
specialization. Typically the "all-in-one" system will suffer in powerful
and flexibility in its sub-features, i.e., mail-ng's "mailing list"
concepts will not be able to cover the entire full-feature scopy of a
specialized "list server" product, etc.
We are a prime example of this. Our system design was originally designed
to be an all encompassing system. This has limited our potential market
place and also put re-design market pressures to have a more flexible
framework or improve specific parts to be more competitive with specialty
products. We had to compromise market demands vs strategic market targets.
Of course, this is commercial view point, but the principles are the same
just as well for a new mail-ng "open system/user supported" product design.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Eric A. Hall" <ehall(_at_)ehsco(_dot_)com>
To: <mail-ng(_at_)imc(_dot_)org>
Sent: Friday, February 06, 2004 2:24 AM
Subject: taxonomies
On 2/5/2004 12:26 PM, Paul Hoffman / IMC wrote:
In specific, I would love to see the lists broken down into
mostly-separable parts of the next-generation protocol (such as
"message transport", "message format", "message display", and so on).
Doing so will help those who are new to designing systems from
scratch to see that it isn't all one hunk, even though it may appear
to be.
I agree that taxonomies are useful discussion tools, to the point that I
think we should spend some time on the subject here.
The simple cut is that mail is about:
+ transport - the global network of disconnected mailboxes and
processes, and how the mail is moved between them
+ applications - the content that is moved across the network
There are a bunch of sub-areas in each of those major hierarchies:
- transport
+ node addressing (mailbox format)
+ process addressing (app-specific process at destination mailbox)
+ routing
+ transport authentication
+ transport 'headers' (XML versus [...])
+ protocol syntax (verbs, parameters, options, [...])
+ error-reporting mechanisms
+ extension registries
+ hop-by-hop transfer-extension negotiation mechanics
+ end-to-end application-extension negotiation mechanics
+ [...]
- applications
+ human-to-human comms (presentation format, encodings, etc.)
+ machine-to-machine application $a (eg, ~syslog writes via email)
+ machine-to-machine application $b (eg, ~chess-by-mail)
+ machine-to-machine application $[...] (whatever)
+ extension $e mechanics (eg, greylist update mechanics)
+ extension $f mechanics (eg, e-postage mechanics)
+ extension $[...] (whatever)
+ [...]
Each of those could be debated and discussed for months by teams of very
smart people, but you really need cross-pollenation to drive any one area
very far. For example, it is absolutely critical to design the common
applications and extensions in order to fully grok what the transport
requirements are going to look like. From that PoV, taxonomy helps folks
to think about the related areas of impact.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/