RE: user-visible goals

> -----Original Message-----
> From: Secretariat [mailto:[email protected]] 
> Sent: Tuesday, February 24, 2004 12:59 PM
> To: Victor Engmark
> Subject: RE: user-visible goals
> 
> Dear Victor,
> unless you HAVE an idea, I woud suggest you do not think we 
> are the son of God and can create something new - that in 
> addition people from the entire world will understand, accept 
> and adopt universally overnight.
> 
> E-Mail is mail. Either you want to stop mailing or you want 
> to keep mailing. Whatever the form. Mail consists in 
> exchanging personalized data at the inditiative of the sender 
> with the consent of the sendee. The transport is insured by 
> the sender, the sendee or a third party. 
> Personalization is usually protected through an enveloppe 
> which permits the sendee to reasonably check the origin and 
> that the mail was not read by a third party. Identification 
> is performed through the address of the sendee and possibly 
> of the sender on the envelope. Authentrification is performed 
> by a seal or by returning the mail with signature. Protection 
> of the content is assumed by encryption. I suppose this is it.
> 
> Now, you tarke each of these steps (layers) and try to see 
> where the flaws are, what can be changed/bettered. And what 
> is the impact on billions of senders,sendees and third party 
> people and systems.

Overnight understanding, acceptance, and adoption is, of course, not a
sensible goal. But I believe we should take only the basic ideas from
email (authentication, push/pull mechanisms, policies, tracking
information, etc.), and try to incorporate these into either the core or
"module" specifications of what such a messaging system should do.

I do not want to stop mailing, but I want to be able to:
- send & receive messages which look the same (or very similar) in every
client implemented according to the specification,
- read messages which do not use the almost completely broken "<special
sign><space>" indentation scheme to indicate threading,
- send a message to a person which is using traditional email, ICQ,
Messenger, IRC, or other client, with confirmation that the message has
been read, and without caring about which client the message is received
on,
- check & create signatures without having to worry about details such
as key length and scheme,
- encrypt and decrypt messages without having to use command-line tools
(ordinary users will _never_ learn it otherwise),
- convert traditional emails to the new system,
- define other ways than only hierarchical folders to put the messages
in,
- specify policies for how I want to receive (or discard) messages, and
- be sure that the structure of messages is so well-defined that I can
use advanced searching and machine processing on them without having to
take into account the ambiguities in the standard.

Among other things.

And I do not think patching the existing systems is the most effective
way to go.

IMNSHO, the way to go is to clearly define requirements for support of
mail-NG for all parts of the system involved in handling messages. It
should be possible to verify to which degree a mail-NG client complies
with the standard. The level of detail in the specification will of
course be an important issue to ensure the success of mail-NG.

By modularizing the specification, developers will also have an easier
time scheduling and prioritizing development of the different parts of a
mail-NG system.

Just some random thoughts.

Yours sincerely,
-- 
Victor Engmark
Quid quid latine dictum sit, altum viditar - What is said in latin,
sounds profound