mail-ng
[Top] [All Lists]

Re: visions

2004-02-23 11:44:59

On 23-feb-04, at 16:29, Markus Stumpf wrote:

What I am really missing in this whole discussion are visions.
Don't/didn't you read/watch SciFi books/films?

Sure, but they're generally not about email. Maybe Kevin O'Donnel and Vernor Vinge (I forget the titles, look them up if anyone's interested) are exceptions to some degree, although it's more like Usenet there.

If you want something radical, a while ago I started thinking about a situation where there is no general connectivity, but people roam around with mobile clients. A way to distribute mail in such an environment would be to exchange copies with everyone you meet and then after some time the message should eventually be delivered.

Should a discussion not start at a more generic point? Maybe at a point
"what is email?" and "do we need something - like we now understand email -
any more?".

The basic idea is pretty simple: transmit a message of an arbitrary nature to zero or more people and/or automated systems. (Note the "and" possibility.) I think the thing that makes email email is that the sender gets to decide on when it's appropriate to send, and the receiver gets to decide when it's appropriate to look at the message, which can be as good as immediately or at a much later time. (Where obviously Tsend < Trecv.)

Another interesting aspect of email is that the messages that are sent and received are the same, so it's easy to file and subsequently reinterpret, retransmit or retarget a message. IMNSHO this makes email much more suitable for ecommerce and similar transactions than HTTP. Also, the fact that everyone provides their own favorite front-end with HTTP drastically lowers its usability in this regard. In fact, much of what we do over the web these days could be done just as well or even better by email or by a combination of email and web. Maybe that should be one of our targets: create a synthesis of email and web that is stronger than each individual protocol/concept.

Also IMHO it is very important to have an overview of how traditional email
is used today and would be used in the future.

I'd like to disagree with Piers here, as very little of my email is personal in nature. My job entails a lot of writing (book chapters, magazine or website articles, drafts, router configurations, explanations of any of these) and email is the perfect way to get this text to the people who need to read it. Don't let the fact that this isn't all that much in messages/day fool you: this type of email is VERY important and would alone be reason enough to keep a connection to the internet around (for me). Then there is the more mundane business-related stuff such as where, what time, look at this link and so on. And email discussions such as this very one are also an important use of email for me.

While a few years ago text/plain was THE encoding to send emails a lot
of companies start switching to text/html as the layout provides more
possibilities to make "official email" look like a written letter, with
logos and a letter head. Maybe in three or four years they like to send
MP3s or MPEGs,

Four years?? How about TODAY. My mail program will play movies embedded in messasges...

so IMHO discussions about ASCII/UTF-8 or whatever are pretty
useless and BINARY is the way to go ;-)

That's a transport issue. I think we all agree that base64 and similar hacks have to go and for all fields that are meant to be read by users and not machines Unicode is the only text encoding we want.

Email had a strong move towards a file/document transfer protocol the last years and the big advantage over FTP/HTTP is that it is asynchronous (for the sender and recipient) and that it is push and not pull. Sending a use
the information right to his box has a higher acceptance than sending
the user an URL and have him retrieve the information himself.

Actually the fact that the sender has to make this specific choice makes no sense. The system should be smart enough to choose behavior that is similar to one or the other automatically based on sender/receiver capabilities and preferences.


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