On Mon, 2004-02-23 at 10:14, Piers Chivers wrote:
Just because it is ubiquitous doesn't make it worthwhile. I think that
currently email can be divided into 3 kinds:
1) Personal email - I don't have official figures but I expect >95% of all
emails are personal. This email is personal even though I am using my
company's infrastructure to send it.
2) Organisational email - just occasionally I send an email that says "I'll
meet you in London at 9.00am for a very important meeting". This is my idea
of an organisational message, sent in my role as an employee.
3) Contractual email - maybe, once upon a time, somewhere, someone sent an
email saying "I'll buy 500 of your widgets and here's my credit card
details" - I've not met this person.
So, given the above, we should concentrate on getting point 1) right. This
means that issues such as authenticity and authorisation are lesser against
user-friendliness.
I really have to disagree with this. Just because a message may be
considered personal, does not mean that I do not want to know for sure
who it came from and if they are authorized to send me a message, send a
message on behalf of someone else etc.
To address the email this was responding to in regards to vision, I see
a future with one communications network, consisting of instant message
components, components like we have with SMTP email today, bulletin
board / web components, etc. I also see a future where much of a
persons communications needs are managed at a central agent for that
user, similar to the way active directory and ldap solutions work now.
I would essentially be able to communicate with my agent server via a
range of clients to access my communications data and methods. For
example, I could direct my communications agent to deny all messages
when I am not online with a client of some form. Or I could instruct it
to accept messages and hold them for delivery until I connect with a
client. I could direct it to forward messages under a given size to my
portable IM client (as well as IM's via yahoo, aol, msn, whatever) when
I'm connected that way, but hold other messages for when I connect with
a more heavyweight client like a traditional email client. If all this
information is stored at my communications agent, I can access the same
information from anywhere, using many different types of software. I
could use a web browser to connect and view the information that way
(probably read-only, unless browsers start sprouting features to reply,
send, etc. when talking to a messaging agent). I'm thinking the
messaging agents could communicate similarly to p2p networks when
actually transferring message data, and something like lightweight SMTP
for control/management messages. Control messages would be used to
determine things like, Is this user currently online (assuming no
privacy setting is enabled to hide this), and if so am I allowed to send
a message to her? Will the message be delivered immediately, or held
for delivery?
I see much of the discussions on this list falling back to the current
"email" methodology, and I really think we should be discussing the
high-level vision of the system.
--
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.
signature.asc
Description: This is a digitally signed message part