----- Original Message -----
From: "Eric A. Hall" <ehall(_at_)ehsco(_dot_)com>
To: <mail-ng(_at_)imc(_dot_)org>
Sent: Sunday, February 01, 2004 6:09 PM
...
and all of that is so you can implement a distributed greylist extension
in your client that can talk to your local delivery server. All such
services would have the same sorts of demands -- we're really talking
about a generic process-to-process tranport service between disconnected
terminal nodes. We should be looking at the minimum stuff needed to
facilitate the development of these distributed applications, which means
data formats, protocols, routing, and so forth.
You have a very good insight, very similar to mine. Therefore I agree with
you. :-)
I allow me to provide some additional information about presentation layers.
We have a client/server mail server (BBS) design that offer multiple ways to
write, access and present the mail system. I like to think that many of the
issues being discussed have similar design issues we experienced since the
original version back in 1983-4 time frame. The internet transition during
the 90s was PAINFUL to say the least!
As you probably well know, the BBS inherently offered features such as:
- direct modem dial-up for connectivity.
- user database system login systems,
- bulletin/notice displays,
- online chatting,
- text based mail conferences,
- file upload/download library structures.
The original BBS systems did not offer:
- any idea or concept of anonymous access,
- any networking idea.
In other words, it was an inherently strong authentication system. It was
also a predominately a text based system.
As our BBS migrated to the Internet, many redesign issues were experienced
that I think it related to the discussion here. Allow me to outline them
here.
A single source mail server structure had two original access points:
- text based (dialup/telnet/console mode)
- a GUI frontend
The BBS traditionally had a separation of header, body and attachment
design. So it was very issue to do a text based presentation here, fast
lookups, no parsing, etc. More importantly, direct mail pointers for "You
got mail" notifications.
When the internet first started, only the bigger host (ISP) offer access
for users via direct dialup and they also began to offer internet email and
newsgroups. So the next design was to offer gateways, uucico, etc.
The immediate presentation issue was the RFC headers in the messages.
So now we had new user options:
[X] Hide Email Headers
[X] Preserve Mime
I'll talk about preserve mine later.
However, the biggest design issue was more that come about was fast mail
processing issues as the new ISPS were being to use new least expensive
feeds such as PC Satellite or ISDN. So we had to look for a super fast
mail storage and access format.
Ironically, we went we similar internet flat-file format but keeping
separate header, body and attachments.. The user's preserve mine option
defined if raw RFC 822 message was saved or it was converted to the BBS
format
This was necessary because we now had new type of presentation layers, POP3
and NNTP users. So users who used a POP3/NNTP client exclusively turned on
his Preserve Mime option. The text based users used the BBS converted
format. If the POP3 user happen to login into the BBS via text mode, he
might will see the "internet junk" in his mail.
Early on, that was a major issue until MIME came along. He was able to
hide the headers during text mode presentation, but server did not parse it
to present only the text part of the message, if any.
So for our WEB server mail client, its a smarter from that standpoint and
handles all modes.
Of course, we haven't updated our GUI frontend in years, so it is plagued
with the RFC junk in the text based views.
I guess what I am saying is that unless a "standard, flexible NG-MAIL"
format is defined, the NG-MAIL may also need to be smart enough to handle
the type of client describing its "presentation" or mail extraction needs.
A WEB client may ask NG-MAIL to extract the mail and reformat it for
HTML/XML presentation.
A Text client connects and request NG-MAIL to extract the mail and reformat
it for TEXT mode presentation.
A Chinese based client may ask to extract a compatible data presentation
etc.
or, as you suggest, a standard new data format is invented and all clients
handle it themselves.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com