mail-ng
[Top] [All Lists]

RE: user-visible goals

2004-02-24 07:50:59

I think we all agree. But that such specifications are full of unnecessary layers violations - as the whole Internet system. My proposition is simple.

- downgrade the usage to the lowest common level in every system, ie SMS size

- use that mailing as smart signaling differentiating the header for the signaling transport from the mail header

- the mail header is the payload of the signal (SMS sizein most of the cases)

- that mail header can have any format accepted between the sende and the sendee with a minimum global constraint. That constraintis that every line of the header starts by "weeXXX" whee XXX can be URL, CLASS, GROUP, ID, FORMAT etc "wee" comming from the name the project I picked as "weemail" standing for web-e-mail , like in web-services. Everything else is tripped off. There is no attachement nor viruses in SMS.

- new servces are trivial. They work for you fine. They do not work, forget about them. One basic is Group and Class : names of the group of authors you want to be considered from and the class of readers you want to be in. This filters out spam and permits you to prioritize your readings.

- retrieval from the storing server is no part of the mail standard.

- compatibilty with the existing system is obvious : the mail server you use to send your mail will be used to receive and will serve as a proxy for your non weemail incomming weemails. Compatibility of existing systems with weemail is built-in: you click the weemail URL. But you have no added sevice and delays : you will want to upgrade your agent.

The mail system design is immediate : a Postfix module.
The mail server is a web-sevice you can refine as you want
The main work is on the mail agent. If Huitema does not want to change outlook, it will be a good occasion to propose a better one.

I wish I have time and a mail C developper as I have a test community for it as a small TLD Manager....
Take care.
jfc


At 14:50 24/02/04, Victor Engmark wrote:


> -----Original Message-----
> From: Secretariat [mailto:info(_at_)netnat(_dot_)org]
> 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


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